I am new to the Y2K field, but am writing our NERC contingency plan, so I am forced to learn fast. I do have a lot of experience in operations. At a recent meeting one of the Maintenance people took the position that embedded chips that we don't know are there probably had their timers/clocks set at a factory and they will not all time out to 1/1/2000 at once. They are not really a Y2K problem, just a defective component problem. They will fail, if they do, at odd times after 1/1/2000, but not all at once. I think I have read that in other sources too. If this is the case, why worry about them ahead of time. Just fix the problems as they show up just like we do with all of our other component failures. When I heard this, it made sense. What am I missing? What is the problem with this position?

-- Anonymous, November 23, 1998

Answers

Chuck:

Gartner Group presented a paper at their Symposium in Orlando eariler this fall on Embedded Systems. They recommended to focus on systems that have a battery on-board or communications to a higher level system that pushes down date/time.

If there is no battery or communications then the system could care less about date/time. It's going to come up with some default date/time everytime the power is cycled and Y2K won't be an issue. Most of these systems only care about incremental time between events.

Gartner said to focus in the larger systems like DCS and SCADA etc.

Jim

-- Anonymous, November 25, 1998

Part of our testing is to determine presence of an onboard battery. If you turn power off, the date should default to some date other than the testing date. If the system returns that day's date, a battery is present and should be noted.

The transfer of data is probably most important thing to examine. We've found devices will work properly when the date is 01/01/00, but the data they pass might be tagged 01/01/00 and might be interpreted incorrectly by a connected device.

One other thing to consider. Will your devices take action or go to sleep? We're considering failure modes; those few devices that have a problem might go to sleep and fail to do something when needed. How do you find them before problems occur? Something to think about...

-- Anonymous, November 25, 1998