Archive for January, 2010

GPS Control Segment software “Glitch”

January 24th, 2010 | Category: General Navigation
Technorati Tags: ,,,

There was an interesting NANU sent out by 2SOPs on January 24th: NANU 2010011:

On 11 January 2010, the GPS Master Control Station loaded new
operational control system software to support future GPS modernization
capabilities and signals.  The software has been in operational soak and
the GPS Master Control Station has received a few user concerns related
to the software update.  Military users can find additional information
at the GPSOC SIPRNet website at  The GPS
Master Control Station is preparing to complete soak of the new software
in preparation for final install.  In support of the final install
decision, the GPS Master Control Station requests that operational
military and civil users provide any impacts encountered that are
believed to be related to the new software or started after the 11
January 2010 install.   Military or civil users please contact the GPSOC
(military) or NAVCEN (civil) at the numbers listed below no later than
29 January 2010.  Any user impacts will be presented at the decision
brief for final install of the new GPS Master Control Station software.

We all know that “glitch” is the term applied when you really have no clue what’s going on with the software.  In this case they just can’t talk about what’s going on.  I believe they do know though, because GPS World is printing that the software changes…

…require absolute compliance with the published GPS Interface Control Document (ICD).”

So some receivers in the field (read military GPS receivers) are having trouble doing their job because of the new software upgrade in the Control Segment.  Let’s talk about Interface Control Documents (ICDs) for a moment.

If you develop software you’re probably aware of ICDs – you know they describe an interface – beyond which you have no control, to which you can write code and expect that it will perform correctly.  My house has an ICD – when the designer laid down the plans for my house, he knew that if he drew the plan for a door in one room, that plan should have a door on the other side as well – so I could actually get from one room to the other.  Sounds simple.  In software we do the same thing – for AGI components we write what’s typically called an API (Application Programming Interface) that allows you, the user of our software, to confidently use our libraries and return results.  An API is something sacrosanct  to a developer – you do not change it unless there is a VERY good reason – many, many developers have written their code expecting the API to work the way it’s written – if it changes in the future, the user of the API can never upgrade to a new version - hurting them and the developer of the API.

Now, if you’re a military GPS user, you have a receiver that must use the GPS Space Segment, which is controlled by the GPS Control Segment.  When either of those are upgraded you don’t have a choice – you’re upgraded too.  So what happens when someone doesn’t follow the ICD and you don’t have a choice about upgrading?  Let’s go back to my house.  Suppose the designer didn’t follow the “ICD” and put doors wherever he liked in my house.  In some rooms, my doors might lead to the back of the stove, or into the back wall of the shower.  I’d be stuck in my room, or worse yet not even be able to use my house.  We expect the designer to adhere to the API of the house so it’d be useable.

So, who didn’t adhere the the GPS ICD?  From the tone of the GPS World article, GPS World thinks the GPS Receiver manufacturers are to blame:

Corrective action could encompass either the Air Force rolling back the update or revising its software, or the manufacturers modifying GPS software within the receivers to be totally compliant with the ICD.

This has happened before – 2SOPs has written papers explaining why adhering to the ICD is critically important.  If you don’t – your receivers don’t work. It doesn’t get much simpler than that.

No comments