When The Millennium Arrives, Will Your Control Systems Be Ready?
Any instrument or control system that has a computer chip and software may be affected by what has come to be known as the “Year 2000 Problem.” Included here is any microprocessor-based application ranging from field instruments to control systems that uses a date function. Even less obvious items such as weigh scales and data loggers may feel the impact. Only instruments and systems that operate independently of a date are not of concern.
Many computer-based control systems, implemented years ago, used only two digits to designate a year. This entry method was intended to improve the efficiency of the system: the first two digits of the year were always “19.” As the year 2000 approaches, systems based on this system will encounter problems when the two-digit entry becomes “00.”
For example, when calculations are performed, if the year 99 is subtracted from the 90, the correct result of 9 yr is obtained. However, if 00 is subtracted from 90, an incorrect answer of 90 yr is provided instead of the correct 10 yr. At the beginning of the year 2000, computers still equipped with low-level BIOS software will revert back to the last date entered.
Matters are more complicated if the software program includes a year-ahead calculation. For individual units working fine in a standalone system there is no guarantee they will work properly when linked to other systems. Extensive testing is required to ensure accurate operation of systems.
Because the deadline for change (December 31, 1999) is absolute, the need for solutions becomes more pressing and difficult with every passing month. The specialized personnel needed to implement testing, corrections, or replacement systems become harder to locate and more expensive to procure. Having a competent project manager, preferably with technological knowledge about the Year 2000 problem, is essential.
Defining the solution
The solution is basically to identify any problem areas and correct them before the deadline. To be in Year 2000 compliance, a system must follow four basic rules.
1. No value for the current date must cause any interruption in the operation of the program. This rule means the roll-over between time demarcations must be performed correctly.
2. Date-based functions must behave consistently for dates prior to, during, and after the year 2000. In other words, the manipulation of dates is correct for the purpose for which they were intended.
3. In all interfaces and for all data storage, the century in any date must be specified, either explicitly or by unambiguous algorithms or inferencing rules. The year must have four digits. Or, if two digits are used, a century indicator must be included.
4. The year 2000 must be recognized as a leap year.
Developing a plan
A plan of action must be developed. The plan will vary from plant-to-plant, but typically every plan should contain five common activities.
1. Appoint a responsible person to oversee each site.
2. Generate a list of all computer-based control systems.
3. Have the list audited and checked by an indedendent assessor.
4. Develop a test schedule and test procedures for every system.
5. Assess the millennium compliance of each system. Even systems deemed compliant by the original system vendor should be tested to ensure accuracy. Noncompliant systems should be classified according to priority and the best solution developed for each.
Coping with noncompliant systems
Noncompliant systems typically fall into three categories: top, medium, and low priority. For example, failure of a system that has a high impact on production or violates legislated regulations requires top priority. The remaining systems can then be grouped into medium and low-priority tasks, depending on the severity of the impact. Once noncompliant systems have been prioritized, there are several solutions that can be applied. (See accompanying section on “Handling noncompliant systems.”)
In addition, a budget must be allocated for handling noncompliant systems. Full compliance should be achieved by the summer of 1999 at the latest. Those that wait until December 1999 to consider Year 2000 compliance issues may be in for some unpleasant surprises. The delivery pressure on system vendors and shortage of qualified technicians to implement the needed modifications will be significant. The scarcity will be especially severe in situations where older programming languages, such as Cobol and Fortran, were used.
Initiating test procedures
System testing is undoubtedly one of the most difficult activities surrounding ensuring Year 2000 compliance. Ideally, plant control systems should be tested off-line (that is, when the plant is not operating). Even when a system appears to have accepted a Year 2000 entry, some side effects may still occur. For example, software that has a time limit on it may expire and be permanently nonfunctional.
Before any testing begins, the system should be backed up. In case of a failure, the system then can be restored back to normal operation. The ability to back up the system and restart it again should be checked before any testing begins. It is possible for a system to crash so that it cannot be restarted.
Test criteria should be developed to meet Year 2000 compliance following the four basic rules outlined earlier. For most instrument and control systems, the following guidelines may be used.
1. Test for high-risk dates in both powered-up and powered-down states to determine that system dates roll over correctly. These rollovers should include:
– From September 9, 1999, to September 10, 1999
– From December 31, 1999, to January 1, 2000
– From February 28, 2000, to February 29, 2000, and to March 1, 2000 (leap year dates)
– From March 31, 2000, to April 1, 2000 (the first 31-day month after February 29)
– From April 30, 2000, to May 1, 2000 (the first 30-day month after February 29).
2. Conduct tests on date-dependent functions such as those used for alarms, trends, reports, historical data, and file time stamps. Selected inputs should be simulated.
3. Special testing procedures should be followed for database management systems and LANs.
Time is running short. To be in compliance by mid-1999, all systems must be identified for action (compliant vs noncompliant) and budgets approved for upgrades by the end of 1998. And be sure that any device or program purchased today is Year 2000 compliant. Some products marketed today still are not!
— Edited by Jeanine Katzel, Senior Editor,
Any microprocessor-based instrument and control system that uses a date may be affected by the century date change.
Time is running short: A solution must be implemented by mid-1999.
Plants have four choices: work around the problem, modify the system, replace the system, or do nothing and take a chance.
A budget must be established to handle noncompliant systems.
Test procedures must be initiated to ensure system performance.
Handling noncompliant systems
There are four possible solutions that can be applied to noncompliant systems.
1. Work around the problem
This approach is acceptable as long as the system does not fail, but instead continues to operate with its erroneous dates. On January 1, 2000, the year may need to be manually re-entered, making possible a loss of all historical data. If the day of the week is important to the data, additional problems may occur because in 1900 January 1 was a Monday; in 2000, January 1 will be a Saturday. The year 2000 is also a leap year.
2. Modify the control system
This solution involves modifying all fields that hold a year to accommodate the four-digit definition (for example, 2012 instead of just 12). Once this type of modification is made, the system should be fully tested. Some software vendors offer upgrades to bring their noncompliant systems into full compliance.
3. Replace the control system
In most cases, this option is the best, especially if extensive modifications would otherwise be required.
4. Do nothing and take a chance
This approach obviously carries some serious risks. If failure of the system could be catastrophic or could shut down the plant, doing nothing is a very dangerous move. If the impact of a failure is minimal (an example might be a PC-based word processing program), this option may be acceptable. Choosing to do nothing should be considered very carefully.
A number of websites offer additional Year 2000 information. Here are a few:
* Microsoft’s Year 2000 home page: www.microsoft.com/cio/year.asp
* List of vendors offering Year 2000 information: www.year2000.com
* Computer Software and Services Association: www.cssa.co.uk/cssa/new/ millen.htm * Information Technology Association of America: www.itaa.org/
The author will answer technical questions about this article. He may be reached by phone at 905-305-0370 or by fax at 905-305-9574.