GPS Control Software Update Shows Glitch

GPS Control Software Update Shows Glitch
http://www.gpsworld.com/gnss-system/news/gps-control-software-update-shows-glitch-9414?print=1
January 21, 2010

The GPS AEP Command and Control operational software update previously
reported enables new capabilities for the warfighter. The new
capabilities are not something we can discuss in this venue. They are
considerable, but require absolute compliance with the published GPS
Interface Control Document (ICD). Some of the new features that are
incorporated only work with authorized military receivers that have
successfully passed security tests. However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

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.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle — as yet unlaunched -- and
more robust security for the military M-code signal.

GPS Interface Control Document (ICD)
http://www.navcen.uscg.gov/pubs/gps/icd200/

em/news/gps-control-software-update-...

IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero. Customer programs crash and
the screams could be heard all the way in Armonk. The amount of
testing that IBM would have to do on a new OS release was simply
enormous.

I am sure that some legacy GPS receivers were built to depend on some
side effect that the latest AEP software (Version 2?) no longer
exhibits. We should all welcome Boeing to the world of legacy
software maintenance. Boeing should figure out which field the legacy
receivers are counting on and change the uploads to set the
"undefined" field (or fields if they are really unlucky) to their
previously undefined values.

--Mike Jr.

Mike Jr wrote:
Glitchhttp://www.gpsworld.com/gnss-system/news/gps-control-software-update- ...

this was common. We got around a lot of it by defining a range
of values reserved for customers in all aspects of computing.
We (DEC) promised to never use those values and also promised to
use the values that were reserved for DEC. Seemed to work well.

Side effects, as you describe above, is another story. We picked
field test sites who had previously demonstrated that they
exercised the code and aspects as much as possible.

/BAH

On Sat, 23 Jan 2010 09:38:14 -0800 (PST), Mike Jr


Early S/360 Fortran compilers (nothing to do with Principles Of
Operation, a hardware manual, or the OS) would create code that would
do this under certain circumstances. If a complicated formula
generated code that required the use of more than the available 4
floating-point hardware registers, the machine code would store the
4th register, use it for temporary results, then zero it in
preparation to reload the previous temp result, but "forget" to reload
the saved value in the register before continuing the operation.

Whoever coded the compiler left the reload instruction out of the
resulting code, and it took such a long, complicated formula written
all in a single statement to cause the error that it rarely happened.

I was doing actuarial calcs for a life insurance company at the time,
and tracked down the problem - it took me a couple of days because I
was not an assembler programmer at the time and I was working from a
listing of the generated machine code. The formula that caused it was
such that a multiply-by-zero-or-by-one was used to include or exclude
a fairly complex term from the result, which helped to identify the
code error. A multiply by the erroneous zero was the giveaway.

I informed IBM about this obscure bug in their compiler around 1967/8,
but I don't know if they ever took it seriously coming from an
actuarial student at the time.