Updated December 3, 1998

By Bruce Kratofil

Y2K, Embedded Systems and You

THE GOOD news: the Year 2000 problem won’t cause your personal computer to crash. The bad news: you may not be able to turn it on because there is no electricity.

In the April issue of BugNet, Bruce Brown looked at the Year 2000 problem, in an article subtitled "Be Still My Beating Heart." As far as the PC industry goes, Y2K is a minor issue that shouldn’t cause too many problems.

Yet the Y2K problem transcends the PC industry and has broad ramifications for the economy. For in addition to PCs, it also affects the world of mainframe programming and, most seriously, devices called embedded processors or embedded systems.

Getting a good estimate for the cost of fixing Y2K is difficult since many people doing the estimates, the Y2K consultants, have a vested interest in making the problem look worse. By far the most widely reported figure comes from the Gartner Group, an Information Technology (IT) industry analyst organization. Their rather imprecise estimate is that it will cost between $300-600 billion worldwide to fix this problem. At the Federal level, the Office of Management and Budget (OMB) is now predicting it will cost $5.4 billion, even though estimates made by individual agencies sum to a much higher number.

According to Congressional testimony, General Motors estimates their costs at $565 million, Citicorp plans on $600 million, and MCI thinks their costs will be $400 million. That number is for the successful fixes. It does not count the costs of economic disruption from Y2K errors that don’t get fixed. It also does not count the cost of litigation. Information Week, in the October 26, 1998 issue, says that estimates of Y2K legal damages may run as much as two or three times the cost of the actual fix, as high as $1 trillion. Check out BugNet’s page of Y2K links for more background information.

Fixing the problem in mainframe computers is slightly more difficult than in PCs, but most indications show that the private sector is well on its way towards solving the problem. The large mainframe government systems may be a different matter. A Congressional oversight committee has graded most government agencies with Ds and F’s in their compliance efforts. The real crucial problem, however, may be in embedded systems.

Embedded Systems

All the 30-year-old bugs in COBOL programs may get fixed in time, and all PCs can be checked for compliance. But it won’t mean a thing if the computer won’t turn on because there is no electricity on January 1, 2000. That is the Doomsday Scenario of a small but significant group of pessimists who worry most about the problem of embedded systems.

Devices throughout the industrial world often have a microprocessor system embedded in them, often linked to a controller that manages some process like fluid flow, temperature, or a machine tool. The functions of some of these systems are to tell time. As trivial examples, look at a digital wristwatch or a VCR, which have embedded processors with time functions. It should be easy to see if they are Y2K-compliant by setting their clocks ahead to December31, 1999 and seeing what happens at midnight. In many cases, it doesn’t matter, because the watch or VCR may not track the year. Some of them do, but only with the last two digits. If this is the case, but you can independently set the date and the day of the week, it really won’t matter. They will keep on running, not caring whether the 00 stands for 1900 or 2000. And even if it does matter, there is probably a wind-up watch sitting around that can be used as a substitute, and many VCRs go their whole lives not showing the correct time.

But in electrical generation plants, nuclear reactors, natural gas pipelines, hospitals and factories around the world, there are countless embedded systems. No one is really sure how many there are, where they are, or exactly what their programming logic is. Many of these systems merely keep track of elapsed time, and do not consider the year at all. Others use a four-digit year, and are also safe. That leaves systems that use a two-digit year. When these controllers suddenly find themselves thrust back into the past, on 1/1/00, do they keep on running or do they shut themselves down in confusion? And will that cause a shut down in whatever process they were controlling? Will the rollover to the new century will cause a one-time error that can be cured by re-calibration, or will it permanently disable the system? In some test cases, a particular system may work correctly as the date changes, but after it is turned off and then turned back on, it exhibits errors. Another complicating factor with many of these controls is that they cannot be reprogrammed. Their particular functions are "burned-in" during manufacturing. If they are non-compliant, they will have to be replaced, not repaired or reprogrammed.

The focal point of the fears of the pessimists is the electric utility industry. An electrical generating plant (conventional as well as nuclear) is an extremely complex system monitored by computers and controllers. It is connected to an equally complex electric distribution system that sends power to its own customers. Even if an individual utility has worked very hard to become 100 percent Y2K compliant, it is still interconnected with other utilities across North America and is partly at their mercy. This interconnection is supposed to be a safety factor. If a catastrophe causes a major loss of power generation in one area, power can be transmitted in from other areas through the electrical grid. The utility industry relies on systems referred to as SCADA (Supervisory Control and Data Acquisition Systems) and EMS (Energy Management Systems) for much of the co-ordination, and the Y2K compliance of SCADA has been debated.

Testimony by utility executives before a special U.S. Senate Y2K committee indicates that utilities may not be as far along in their testing and remediation for embedded systems as other industries, saying "…we conclude that while these utilities are proceeding in the right direction, the pace of remedial efforts is too slow and the associated milestone dates are so distant that there is significant cause for concern."

There are also experts who say that while there may be problems with SCADA, the consequences are exaggerated. For instance, a recent article by a leading designer of software for the electric utility industry, Dick Mills, relates this anecdote from an engineer who works for a major SCADA and EMS vendor: "…told me that their systems have always had trouble with daylight savings time, so on those two evenings per year when daylight savings changes, they just leave the SCADA and EMS computers turned off for the night or for the hours near 2 am. No power customers ever noticed that the computers were off. No blackouts occurred." Another mitigating factor may be that it won’t be a surprise. While no one will say that utilities will be fully compliant on January 1, 2000, they won’t be unaware. One would imagine that control rooms and repair crews will be fully staffed and on alert during this time period.

Economic Shutdown?

There are a certain number of survivalists who think that the modern economy has become so complex and so reliant on technology, that the Y2K problem will be far worse than any earthquake or hurricane. They fear a supply chain only as strong as its weakest link. "I’ve always known that the economy is complex and that we live on the end of a long chain of ships, planes, and 18-wheelers," one such survivalist told Wired Magazine.

Consider some recent examples of how small events cause big consequences. General Motors has learned that the closure of just a few key facilities can cause the almost total shutdown of their manufacturing operations. The failure of one communications satellite caused a massive disruption in pager networks, some broadcast news operations, and credit card verification systems. And complications caused by the merger of two railroads snarled train traffic in the Southwest for months. Now multiply these events ten or twenty-fold, mix in disruptions in utilities, have them all happen at once, and one can see why some people are stockpiling food in the basement. (While it may be easy to write off the survivalists as kooks, it is somewhat disconcerting to see that a number of them are programmers with lots of Y2K experience.)

To dispel some of the doom and gloom that accompanies this topic, it may be appropriate to end with a story that has been circulating around the Internet:

A COBOL programmer had been putting in tremendous hours working to solve the Y2K problem. The combination of long hours and the stress of listening to all the doomsday talk caused a major anxiety attack. He went to a cryogenics company, and arranged to have himself frozen for a year, in an expensive and totally automated process. His last thoughts as he fell asleep were that, when he woke up, he was sure the problems would be solved.

The next thing he knew, he was in a very modern room filled with excited people and equipment right out of a Star Trek episode. They were amazed he was still alive. The cryogenics company he picked, they explained, was not Year 2000 compliant, and there had been a problem. Instead of being asleep a year, he had been asleep almost eight thousand years.

One of the technicians came forward with a viewing screen and said that the Prime Minister of Earth wished to speak to him. The Prime Minister told the programmer not to be afraid, he was waking in a far better world. There was world peace and no more hunger. Disease had been eradicated, and space travel a reality. "That’s terrific," said the programmer, "but why are you so interested in me?"

The Prime Minister, who looked very much like Bill Gates, replied "Well, your files say that you know COBOL, and we’ve got this thing called the Year 10,000 bug….."


Click here for a list of Y2K links.

© BugNet material copyright 1994-1999 by BugNet.
® BugNet is a Registered Trademark of KeyLabs.
Astonisher.com material is

© Copyright 1973 - 2015 by Bruce Brown and BF Communications Inc.
Astonisher.com is a trademark of BF Communications Inc.

This historic replica of BugNet from the period 1994-1999
is presented by astonisher.com with the permission of BugNet.

BF Communications Inc.
P.O. Box 393
Sumas, WA 98295 USA
(360) 927-3234

Website by Running Dog

* Here's Bruce Brown's BugNet Memoir...
* Here's the free BugNet from 1999...