Bill, you had some questions on the GPS problem. Here is a description of the problem and of the consequences. Please indicate in detailed technical terms what is and what is not correct in this description (from your derogatory remarks about apparent lack of Mrs. Houston's technical know-how, I conclude that you must be technologically well-versed).
Waiting.... but probably not substantial answer will follow.
John
_______________
From: erols.com
'
Embedded System Technical Issues
From: "Jack K. Horner
Subject: Risks Associated with the Year 2000 Problem
This is message sent to Rick Light in response to a forwarding of a comment on the appended
message from the U.S. House Science Committee, particularly relating to those Y2K problems
resulting from the omission of the "19" in the calendar year. It is reproduced with the permission of the
author.
The problem is potentially much messier than just the occurrences of the literal value "19" in date
types. ANYTHING in software that merely _acts as if_ the first two digits of the date are "19" will
have insidious effects. About a year ago, I worked on an analysis of the Global Positioning System
(GPS) ground station code to try to characterize the Y2K problem. We found no less than ten types
of manifestations of the problem in a survey of a randomly selected sample of 10% of the code.The
occurrence of the literal value "19" was only one of these ten types. Other types included type
overflow problems at various dates throughout 1999, Y2K arithmetic that implicitly assumed no dates
later than 31 Dec 99 were possible, and implicit module-interface date-type conversions. These
problems are potentially infinite in their variety, and not all can be detected with tools. Furthermore, in
GPS it is not possible to construct good test cases to see what will happen at the millennium start,
because the future (time-) states of the system depend on physical values (orbital elements, pole
wander, Jovian gravitational force) that can be determined with sufficient accuracy only from the
actual operation of the system within about three months of the time of interest. Approximately 1% of
the total GPS code is affected by this class of problems, or affected it.
The GPS user-equipment code is in even deeper trouble because of the Y2K problem, and the
breakage will occur well before Jan 1, 2000. Date, in the GPS signal standard, uses exactly thirteen
bits (these bits represent a time-unit offset from a conventional epoch date). This allocation is burned
into proms on all existing GPS user equipment. On about August 20, 1999, the actual date value will
overflow this 13-bit type, and the equipment will fail to produce correct time or position information.
Best estimate is that there are ~10^6 pieces of user equipment that will be immediately affected.
Everybody who depends indirectly on those pieces of equipment (meaning all the rest of us) will also
be affected. The GPS standards committee is desperately trying to figure out what to do with the
problem.
Various well-calibrated software estimation models (SLAM, REVIC, > PRICE-S) predict that fixing
the Y2K problem in systems of about 500,000 lines of code or larger will take more time than is
available between now and the year 2000, regardless of how many programmers are thrown at the
job. Most of the US's military command-and-control systems contain more than 500,000 lines of
code.
GPS is now the primary means of distributing time standards throughout the US, and throughout much
of the world. (The accuracy of the atomic clocks on board the GPS satellites is second only to those
maintained by the primary standards clocks in Washington.) Thousands of large financial computers
ultimately take their time calibration from GPS, every day. Interest on overnight multi-billion-dollar
short-term electronic-funds transactions is computed at millisecond granularity, derived from the GPS
standard.
Place your bets.
Jack Horner, CIC-8
|
