Why is it not possible to turn all the clocks in power plants back to say 1980? I understand that this can't be done in other industries because of database corruption and interrelated systems with external computers. Is this the same reason for the electric industry? Do power plant computers send their own RTC information over the power grid or to any other external computers?

-- Anonymous, November 20, 1998

Answers

There are some subsystems where it is possible to do this.

However, you still need to do full testing to make sure you didn't inadvertantly break something. Since testing is a good 50% to 75% of the job anyway. You may as well do it right the first time.

I'm sure it will be used a lot as a contingency plan as we near the end of next year.

--AJ

-- Anonymous, November 20, 1998

As AJ indicated, turning back the clocks (a strategy known as "encapsulation") is a valid approach for some applications and systems. The trouble is, it will only work in some cases (not all), it's only a temporary bandaid at best (the problem still has to be fixed at some point in the future), and at worst, if the system exchanges date related data with other systems, potentially disasterous. However, properly applied, it's one piece of a big remediation puzzle.

-- Anonymous, November 20, 1998

I think it's important to recognize an important potential problem with the approach of 'setting the clock/time to some prior date'. The problem arises because many enterprises depend on the fact that all clocks/dates, across the enterprise, are exactly (or almost exactly) identical. If such an approach is attempted and not all clocks/dates are instantaneously updated to the new 'time', then there is the potential for individual systems within an enterprise to improperly interact with each other. In order to figure out the challenges to implement any sort of method to update all of the clocks/dates at the same time, think about just what kind of coordinated effort it would take to update all of the clocks in your own home at exactly the same time. In a large enterprise, it would not be unreasonable to multiply this 'do it at home' complexity by a factor of 100 or 1000 or 1,000,000, depending on a lot of TBD factors!!!

-- Anonymous, November 22, 1998

Ron,

You are correct in the general sense. However, typically every box is not talking to every other box. Large systems are broken down into control "cells", so with careful analysis different cells can be remediated with individual solutions. Some of the control loops in the Canadian Candu reactors were remediated by setting the clocks back. Of course it was all fully tested too.

One other caveat about setting the clocks back. If the control system being remediated with this method does communicate date and time outside of its loop you have to be careful that you pick a year that will be a leap year in 2000. Also, if the system relies on day-of-the-week information you also have to pick a year where January 1st is a Saturday. It turns out that 1972 fits both criteria. Large collars, wide ties, bell-bottoms and platform shoes anyone?

And, in yet another example of how nothing is as easy as it first seems with this whole Y2K problem, some IBM PC based systems won't let you use the 1972 date because it's prior to 1980/84 and the PC "knows" that's not a valid date.

--AJ

-- Anonymous, November 23, 1998

In a nutshell, the problem with "turning back the clock(s)" in a complex system, with many indivdual computing elements, is that none of these elements were procured or specified to be capable of a coordinated "turn back the clock" operation. This was of course not foreseen as a requirement. Thus if it is performed, there is a great risk of unpredictable behavior within the system. And most of these systems have at a minimum been specified to "fail safe" when unexpected behavior occurs. JP

-- Anonymous, December 01, 1998