To: Bill Wexler who wrote (21766 ) 8/6/1998 6:33:00 PM From: John Mansfield Read Replies (1) | Respond to of 31646
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