TABLE 3: Twelve common problems (and possible solutions) encountered during computer Y2K rollover tests conducted by Raytheon at various plant and mill sites. |
Problem |
Description |
Solution |
Date code equipment failure |
Equipment stamps/prints the production date or a date code on every end item; it fails to work completely when it hits 00 in the year field |
Vendor will supply firmware/software update to fix the problem |
Control system ceases to function completely |
Distributed control system (some PLCs also) fails to operate after the 2000 date |
Vendor supplied firmware and/or software/operating system update that fixes the problem |
Data is collected and stored but never found again |
Quality management system stores data after the rollover but the same program fails to find it because the search range it uses cannot deal with 00; all data appears lost and the QC system ceases to function. |
Relatively minor adjustments to make it compliant |
Production or scheduling thinks it is late or far behind |
Production system reacts to test by ramping system up production to 2.5x the correct rate (believing it has to catch up); system also stores meaningless data about production because of 1900 date |
Modify programs and production control algorithms |
New version of program or new data can't be accepted |
Control system (PLC based) will not accept new version of the control programs or new batch instructions and will not accept the last ones available with 1999 dates |
Relatively minor program modifications and operating system update from the vendor |
Alarms and notifications don't appear |
Production control system will accept alarm conditions and create alarms, but the alarm messages are moved to the bottom of the queue/log because of date, and operator can't get correct message |
New and compliant version of application software required |
License expiration with no recovery mode |
PC based application license incorrectly goes into expiration mode on 00 date; when date is reset, software still doesn't work because vendor's license paradigm is once expired always expired; no system reset or reload possible |
Get updated version of vendor product that corrects the problem |
System or equipment fails and the vendor doesn't know why |
Vendor of system cannot explain why system fails test; reason is because the system has imbedded control components from an OEM vendor that are not compliant |
Get the correct fix in the form of firmware/software/os update from the OEM equipment supplier |
Two compliant systems that depend on each other fail |
Mill has two independent systems that are compliant and pass all tests, but the interface between them is not compliant and causes one or both to fail on date rollover test |
Fix or update the interface link or driver software |
System works fine before and after |
Controllers and control system on OEM equipment works fine until date rollover and works fine afterwards, but will lockup on the rollover and leap year date events |
Don't modify the system in any way; put operations procedures in place to deal with the rollover and leap year day events |
Automatic reset response/reflex |
Control system resets itself to the default startup date (1980) in its firmware when it reaches the rollover point |
Date was not critical to the operation; ignore the problem and let the date remain incorrect; notify operators and maintenance |