Instead the clocks on those machines will read the date as January 1, 1900. Software that depends on correctly processing dates may give erroneous results or simply cease to function. These potential catastrophes, and the measures required to cope with them, have come to be known as the Year 2000 or Y2K problem. Some survivalists think that modern economies have become so complex and so dependent on technology that the Y2K problem could have consequences that are far more drastic than those from an earthquake or hurricane. They foresee global disruptions in the flow of goods and services necessary to maintain a modicum of comfort and civilization. Others see it as a minor nuisance that is fueling a booming and profitable Y2K panic economy. The Y2K issue will turn out to be a significant engineering challenge because the scope and extent of the problem can be difficult to define. Outside the federal government, military installations and large Fortune 500 corporations, there is a "wait-and-see" attitude characterized by curiosity, amusement and even contempt. Y2K jokes are becoming quite fashionable.
This article attempts to examine the nature and origins of the Y2K "bug" and how governments and engineers have responded to
the problem. The section on "embedded systems" demonstrates that the Y2K problem presents engineers with an insidious and
challenging dimension. The final section deals with taking a diagnostic pulse of Y2K readiness by industry and country.
The Origins Of The Problem
The problem can be traced directly from the way in which dates are stored and incremented on computers and embedded systems. In the early days of software development programmers tried to conserve memory resources by saving year dates as 2-digit numbers, e.g. 98 became a shortcut for the year 1998. So, after 1999, the year will change to 1900 instead of 2000 and we are provided with yet another thorny route to operating systems that are known to be Year 2000 compliant. Early versions of leading spreadsheet packages would interpret two-digit year entries such as 01 as 1901.A computer keeps track of time using a battery-operated, real-time clock (RTC). The computer's basic input-output system (BIOS) reads the date and time from the RTC and retains a copy that can be retrieved by software applications such as DOS and Windows. However the RTC only returns the year date as a 2-digit number and allows for a 4-digit year by incrementing a byte called the "century byte" in the system's CMOS RAM (a special segment of memory that is saved even after the computer is turned off). DOS computes the current year as (century byte x 100) + year. However, some BIOS do not increment the century byte. When the year goes from 99 to 00, and the century byte does not change, DOS's year goes from 1999 to 1900 and this date is passed to Microsoft Windows. Systems with a VESA local Bus or ISA-based systems will need a third party BIOS.
Many plant and industrial processes use the dates that are stored and processed by date chips that are "embedded" in
programmable logic controllers (PLCs). The embedded date chips may fail to recognize the year 2000 and prematurely shut down
plant process control systems. If these are large power plants serving very large markets the resulting disruption could spread across
regional and national boundaries.
Year 2000 Compliance Guidelines
Year 2000 compliance means that computer systems and software correctly interpret and process data that represents the year 2000 and beyond. The guidelines presented here were originally developed by the United States Air Force and are being widely adopted in both military and civilian agencies in the United States and abroad. They are intended as a checklist for analyzing date-related issues that need to be addressed in existing and future computer hardware, software and operating systems. The checklist covers the following issues:The 1900-2000 Millennium Transition
Dates in the 20th Century (1900s), dates in the 21st century (2000s), dates across century boundaries (mix 1900s and 2000s); crosses 1999 to 2000 successfully; and crosses Fiscal Year 2000 successfully.Leap Years
February 29, 2000 is recognized as a valid date; Julian date 00060 is recognized as February 29, 2000; Julian date 00366 is recognized as December 31, 2000; and arithmetic operations recognize Year 2000 has 366 days.Internal Dates
Display of dates is clear and unambiguous (the ability to correctly determine to which century a date belongs either by explicit display, i.e. 4-digit year, or system or user inference); printing of dates is clear and unambiguous; input of dates is clear and unambiguous; and storage of dates is clear and unambiguous.Other Date Related Issues
Dates embedded as parts of other fields; dates used as part of a sort key; usage of values in date fields for special purposes that are not dates (e.g. using 9999 or 99 to mean "never expire"); date dependent activation/deactivation of passwords, accounts and commercial licenses; date representation in the operating system's file system (creation dates and modification dates of files and directories); date dependent audit information; date dependencies in encryption/decryption algorithms; date dependent random number generators; date dependencies in firmware; and personal Computer BIOS and RTC do not reset the year to 1980 or 1984 on reboots after 31 December 1999 (corrections by operating system utilities allowed).The McAfee 2000 Toolbox is a software utility designed to solve the problem by replacing the DOS date and time services. When DOS programs or Windows ask for the date, and the Toolbox sees the year 1900, it assumes the year as being 2000. This makes sense since computers did not exist in 1900. This capability is built into Windows 98 that will return the year 2000 if it sees the date as being 1900. Windows NT 4.0 goes straight to the RTC and assumes that year 00 is year 2000. These tricks will work through the year 2099 after which the problem will emerge all over again.
Unfortunately, there are no simple solutions to the Y2K problem in the "embedded systems" of the billions of the PLCs in
mechanical control systems. One of the world's leading PLCs loses accuracy on leap days of leap years. The problem can produce
a 2.5% loss of time in time-based functions. This affects fixed scans, time-based instructions and cyclic analog task activities.
The Embedded Systems Problem
The main problem with the dates in embedded systems is that they are difficult to locate and to fix. What constitutes an embedded system? How many of these systems exist? Some analysts have estimated that there are 25-40 billion around, but experts at PC Week Labs found that number to be too high. So far about 70 billion chips have been made, and only a small portion are microprocessors and micro-controllers that end up in an embedded system. The vast majority of embedded systems are used in relatively dumb systems that are not vulnerable to Y2K problems. The paradox of embedded systems is that most of them are dumb and therefore pose minimal Y2K risks. However, by virtue of their simplicity, they tend to be hard-coded and simply cannot be changed in times of trouble. The less numerous and more complex truly embedded systems contain some software. While these systems can be easily upgraded it also means that they are more likely to use a date function and therefore more susceptible to Y2K problems. PC Week Labs has estimated a failure rate of 5% for embedded systems. However, this seemingly low percentage could translate into a sizable financial expenditure for many companies due to the intricacies of testing and fixing embedded systems.Another problem with embedded systems is that they do not use dates in the traditional manner. In embedded systems, dates are not as important as time intervals or cycles. Interval timing does not use an absolute date, but only a date relative to another date. Dates are measured as the time period elapsed after a specific event. For example, a date of zero is written when maintenance is done on a system. The system then counts days until another maintenance cycle is due. It gets complicated when this interval timing uses specific dates. In the previous example, an elevator could be the device performing the maintenance logging. Elevators provide a perfect example because by law they cannot operate outside of their maintenance cycle. If an elevator must be inspected every six months, when the date rolls over for 2000, the elevator will "think" the inspection is 99 years and six months overdue and stop working.
Why do engineers get anxious about fixing a non-compliant embedded system? Because they know the amount of work involved in such an endeavor can be quite staggering. The problems can be traced to analyzing input and output. Input involves getting the remedied code into the embedded system, while output refers to measuring the result of the code changes and determining if the affected system can now recognize dates and data to function in the year 2000 and beyond?
n embedded systems the code must be extracted from ROM and then simulated on another system. Engineers hope that the code is written in a widely known language that is still supported by compilers. Editing and installing embedded code is only the beginning. There is no simple run button on an embedded system for testing the code. These systems are often parts of much larger systems that accept input directly from data acquisition systems. Next comes the testing nightmare. Since computers are not being used in the input stream and since these embedded systems cannot usually be put into production without extensive regression testing, input data simulation is the only approach. A custom probe is developed for in-circuit simulation of the data point. This probe may provide, for example, a simple signal to a temperature-control embedded system, which then logs the event. However, different custom probes may be necessary for the variety of a company's embedded systems. Some systems may require 1 volt to signal an event while another might require 5 volts. Output analysis offers significant challenges to embedded-system engineers since the event output of an event could range from something as benign as setting off an alarm to something as drastic as shutting down an entire production system. The engineers must go beyond simple full-regression testing to simulating both the input and output signal streams.
The ubiquity of these chips, and the fact that many are hidden, makes it challenging enough to find all these systems, let alone to
test them. The Public Service Electric & Gas Company is a unit of the Public Service Enterprise Group and New Jersey's dominant
utility. It took Year 2000 team members a year to walk through 250 locations, from power plants to substations, hunting down
hidden processors. Just when they thought they had found everything, they realized they had forgotten to check a reservoir that the
utility had built to release water into the Delaware River for environmental purposes. Could it possibly contain hidden processors?
When the team members checked, they discovered that a technician walked the dam twice a day with a hand-held device to
check for creepage. The device contained a processor that was not Y2K compliant. At the foot of the dam was a control system
that monitored water releases. It, too, failed to meet Y2K compliance.
Y2K Readiness Assessments
Gartner Group, an information technology marketing firm, is surveying the status of Year 2000 compliance for 15,000 companies located in 87 countries. Their results, compiled every three months, indicate that only 23% of the companies have begun to deal with Year 2000 issues. Gartner classifies countries by "Levels of Readiness." Level 1 is the most ready with only 15% of companies expected to suffer a mission critical failure due to a Year 2000 problem. Level 4 is the least ready with at least 66% of companies expected to experience a failure. Readiness by Country
Level 1 (15%): Australia, Belgium, Bermuda, Canada, Denmark, Holland, Ireland, Israel, Switzerland, Sweden, United Kingdom
and U.S.
Level 2 (33%): Brazil, Chile, Finland, France, Hungary, Italy, Mexico, New Zealand, Norway, Peru, Portugal, Singapore, South
Korea, Spain and Taiwan.
Level 3 (50%): Argentina, Armenia, Austria, Bulgaria, Colombia, Czech Republic, Egypt, Germany, Guatemala, India, Japan,
Jordan, Kenya, Kuwait, Malaysia, North Korea, Poland, Puerto Rico, Saudi Arabia, South Africa, Sri Lanka, Turkey, United Arab
Emirates, Venezuela and Yugoslavia.
Level 4 (66%): Afghanistan, Bahrain, Bangladesh, Cambodia, Chad, China, Costa Rica, Ecuador, Egypt, El Salvador, Ethiopia,
Fiji, Indonesia, Kenya, Laos, Lithuania, Morocco, Mozambique, Nepal, Nigeria, Pakistan, Philippines, Romania, Russia, Somalia,
Sudan, Thailand, Uruguay, Vietnam, Zaire and Zimbabwe.
Readiness by Industry
Level 1 (15%): Insurance, Investment Services, Banking, Pharmaceuticals and Computer Manufacturing
Level 2 (33%): Heavy Equipment, Aerospace, Medical Equipment, Software, Semiconductors, Telecom, Retail, Discrete
Manufacturing, Publishing, Biotechnology, and Consulting
Level 3 (50%): Chemical Processing, Transportation, Power, Natural Gas, Water, Oil, Law Practices, Medical Practices,
Construction, Transportation, Pulp & Paper, Ocean Shipping, Hospitality, Broadcast News, Television and Law Enforcement.
Level 4 (66%): Education, Health Care, Government Agencies, Agriculture, Food Processing, Construction and City & Town
Municipal Services.
Summary and Conclusion
The Y2K "bug" is not a computer bug in the real sense of the word. It was actually an orchestrated attempt to save on precious computer memory by representing the 4-digit year date as 2 digits. This myopic practice persisted even after computer memory became cheaper. Those who had the foresight to warn about the problem were ignored or ridiculed. Most discussions about the Y2K problem have focused on its impacts on personal and mainframe computers. This problem can be quite easily identified and solved by upgrading to newer hardware and software capable of correctly handling the millennium date transition. There is much less discussion of the Y2K date problem that will manifest itself through the widespread use of PLCs in commercial and industrial process control systems. These "hidden computers" are far more ubiquitous than personal and mainframe computers. They will pose major re-programming and testing challenges.There is also the challenge of keeping the computer repair work going and simultaneously making prudent preparations for calming the most nervous citizens. Although surveys have shown that most Americans do not expect their lives to be severely disrupted, some are planning to protect themselves through large investments of time and money. The American Red Cross advises the public to stock up on enough cash, food and other provisions to endure disruptions that could last for several days to a week. Surveys by the Gartner Group indicate that there are major disparities in Y2K readiness between countries and between industries in the same country. There is thus a definite potential for national and international economic disruption if Y2K compliance is not attained by January 1, 2000.
