Time traveling beyond 2000

greenspun.com : LUSENET : Electric Utilities and Y2K : One Thread

I got this message from the EEI Public Information List for Y2K Information.

PACIFICORP PLANTS PRODUCING YEAR 2000 ELECTRICITY

PacifiCorp has announced that its electric utilities Pacific Power and Utah Power are advancing the control system clocks ahead and operating all its thermal generating units in the Year 2000 from now until the end of the first quarter of the year 2000. The same is taking place in its transmission and distribution systems and is one of the final steps to having all critical systems ready for the Year 2000 by July 1, 1999. "These are the systems that affect all stages of electric production from generation to delivery at the point of service for each of our customers," said David Register, Year 2000 project manager, PacifiCorp. "Making the transition now will help our customers and the public to have the same confidence we have about the extent and reliability of our preparations."

Register explained the plants have already gone through months of inventory, assessment, remediation and testing and all have operated successfully during critical date rollover tests.

"More than 25 percent of our thermal generation units are already operating and producing power dated in the year 2000," said Bob Augenstein, generation Y2K project manager. "Our commitment to be ready for Y2K is now nearing reality."

Augenstein went on to say the critical systems clocks at all these facilities have been tested through a multitude of troublesome dates associated with Year 2000 and the equipment has passed each test. The formal program of setting the dating systems and clocks ahead and leaving them ahead began early in March and will continue through June. Each unit will have the date advanced while it is off line for regular maintenance or during off-peak hours this spring. Next year, the clocks will be reset to the correct calendar date.

___________________________________________________________________

My question is about time traveling. In my opinion it is enough to test the critical dates and go back to the correct calendar date. Why are these clocks ticking a long time on the incorrect calendar date after the tests ?

-- Anonymous, April 08, 1999

Answers

2 reasons, really. 1) There are certain risks involved in changing the clocks, no matter which direction you go, and setting them back to 1999 possibly could cause problems even in compliant equipment, so why take chances? 2) Certain segments of the Y2K community will not believe that PacifiCorp actually did those tests, or that they were successful. Leaving the clocks running in 2000 makes it harder for those types to say "You're lying to us."

-- Anonymous, April 08, 1999

Menno,

It is also possible (though I have never seen it) for a rollover test to set a century flag, and then create problems if the date is reset and then the device tries to set a century flag that is already set. Our test procedure calls for the rollover to be repeated several times while checking various potential problem modes.

I doubt this has anything to do with the decision to keep rolling in post 2000 though. I think the previous response hit the nail on the head. There are some that would doubt the truthfulness of a utility person claiming the sun rises in the east. (Y2K impact on this is unknown).

-- Anonymous, April 08, 1999


But Art...

You just think the sun rises in the east. What the sun appears to be doing is different than what it is actually doing. Appearance and actuality are frequently disparate concepts, not unlike the current problem of reporting compliance and actually being compliant, much less knowing with certainty that compliance has been achieved.

-- Anonymous, April 08, 1999


A device date is quite often a piece of computer data. Data is used by computers to solve problems, and automate processes. Some processes that use data use it on one day. Others only run once a week, a month, a quarter, a year. Processes also take different sets of data to perform operations on. Sometimes the set of data is the previous day, sometimes the previous year, sometimes the next year. Some processes that run once a day, may be connected to processes that run once a month or even once a second.

Understanding this can help you see why testing takes so much time and effort. It may also help you to begin to understand why developers like myself are shaking our heads.

I know right off that it is most likely that a power plant has many computer clocks and processes that would have to be rolled forward in order to truely be operating in the year 2000.

A simple question that a reporter could ask a company like this is, "How many clocks have been rolled forward?" It would ease my mind a great deal if it could be proven that the vast majority of clocks at a plant have been rolled forward.

Until then, I have a big ?

-- Anonymous, April 08, 1999


I still have some questions:

1) When it is a matter of risk resetting the clock, why not set the clock right during the test instead of someday in 2000 ?

2) What are the risks of ticking at an incorrect calendar date ?

3) Is it not better to ask if a whole system is doing a time travel than to ask how many clocks have been rolled forward ?

4) Is it true that in case of setting a century flag or something like that the system will have problems with this century ? So problems can be introduced during y2k-tests ?

-- Anonymous, April 09, 1999



Menno,

Answers to 2 & 4 first. Apparently the risks are minimal or non-existant otherwise the systems would not be operating as they are right now. 3) The entire plant is made up of many systems, some interact some do not. It is not accurate to say that all systems within the plant need to be set forward, at the same time, in order to verify that a particular system works in 2000.

-- Anonymous, April 09, 1999


I think it is a moot point how many computer clocks they set for whatever time they want. If they can change the clocks inside each and every chip then I will be VERY impressed. To just look at software, test that by rolling the clocks forward and ignore the timing in the embedded chips - is meaningless.

-- Anonymous, April 11, 1999

MYOB-

Thanks for your post. I agree, please see the article in the thread titled "More Information From WebPal on Embedded Systems"....

-- Anonymous, April 11, 1999


In these date roll-over stories, responsible reporters should find out and indicate how much of a system has been remediated (time, money spent, etc) before the roll-over. Many articles I have read of this nature make it sound as though no testing or remediation other then setting the date forward has occured.

-- Anonymous, April 11, 1999

Moderation questions? read the FAQ