A typical contemporary system consists of multiple controllers (sometimes confusingly termed instruments) connected to a supervisory/monitoring machine by a network communications system. The nature of individual controllers varies. At their most simple, they will be closed-loop devices controlling one piece of plant. At their most complex they could be complete industrial microcomputers with programmable logic controlling a range of plant.
The controllers themselves will often have the capability of compliance. That is, they may be capable of representing dates in DD/MM/YYYY or similar format, and the underlying Real Time Clock or RTC (if present) will 'rollover' correctly at 31/12/1999, 23:59:59 + 1 second. This will not be the case for all controllers, but manufactures should be able to provide clear guidance on the capabilities of their equipment. Where the controller itself is not compliant, this need not have implications for the correct functioning of the system. Controllers, particularly the less complex controllers, are generally concerned with relatively short duration interval timing. Any 'rollover' problems are unlikely to be associated with the year 2000 and have other than transient affects on system behavior.
The SCADA application may have been developed using one of a range of purpose built development products or, less frequently, through use of a conventional programming language and development environment. Variants of Basic, Pascal, C and C++ are all in common use.
The SCADA software itself is designed to run on a specific machine and operating system platform. There are a myriad of industrial microcomputers that have been used for such purposes over the past few decades, although larger installations still use dedicated mainframe machines. Similarly, there are a range of operating systems in use, many providing specialised services for this kind of application. In recent years, for a broad range of mundane applications, the platform is likely to have been IBM PC 'compatible' systems running DOS, Concurrent DOS, Windows or Windows NT operating systems. The microcomputer may not look like a conventional desktop PC. There are credit-card sized 'embedded', rack-mounted, daughterboard and other varieties. PC based systems will usually be identified by the presence of one of the Intel family of processors (80186, 80286, 80386, 80486 or Pentium). Naturally other processor families and architectures are also in common use.
It is within the operation of the SCADA software that most problems are likely to occur at Y2K. These problems may show at one or more of the machine, operating system, SCADA runtime or application software levels.
Within the operation of the SCADA software, the areas likely to cause most problems are those which are concerned with scheduling or logging functionality. Such operations are intrinsically founded upon specific date and time representations which could be erroneous at any of the aforementioned levels. The application will depend upon accuracy of date/times held within the runtime environment which are dependent upon date/times held within the operating system which are dependent upon date/times held within the SCADA machine firmware and hardware.
Any control system could fail to deal with the year 2000 transition at any of the above levels. In fact, even this is a simplification. For example, the SCADA machine often has some firmware in the form of a BIOS which is a built-in portion of the operating system. Otherwise identical machines may have different BIOS's with variable ability to cope with Y2K date changes. Most of these problems have been identified in the 'mainstream' debate on the Y2K issue.
(i) 31/12/2023 23:59:59 + 1 second = Undefined date and time
(ii) 31/12/2023 23:59:59 + 1 second = 1/1/2024 00:00:00
(ii) 31/12/2023 23:59:59 + 1 second = Default Date 00:00:00
The above transitions could produce the following problems:
Undefined Date Time. An undefined date and/or time would affect all scheduled activities undertaken by the system. Should the date and time resulting from the transition to the year 2000 be earlier than that which existed before the transition, date comparisons intended to produce positive results could yield negative results which produce runtime errors and consequent system failures. Systems which are reliant on 'day of week' information will also malfunction.
Transition to 01/01/00. Such a transition could produce errors of the kind discussed in (i). Any operation performing date comparisons (typical of scheduling and logging functions) could fail. Additionally, there is a slight risk that date manipulation routines could suffer from a potentially fatal 'division by zero' problem.
Transition to a default date and time. Such a transition could produce any of the problems mentioned in (i) and (ii) above.
Produce an inventory of all control equipment, identifying machine serial numbers, firmware revision numbers, software revision numbers etc.
Identify suppliers of all elements of systems identified in (i) above.
Ask the appropriate compliance questions of the suppliers identified in (ii) above. That is:
Machine Suppliers
Does the RTC represent dates and time beyond 2000 and handle the transition correctly ?
Does the specific firmware revision represent dates and time beyond the year 2000 and handle the transition correctly ?
How can I test compliance of this specific machine with a stated firmware version number ?
Software Suppliers
Do ALL aspects of the software represent dates beyond 2000 and handle the year 2000 transition correctly ?
Will the specific scheduling and logging functions utilised be in any respect adversely affected by the year 2000 transition ?
How can software compliance be tested ?
If achieving remedial action through suppliers proves to be a problem and replacement of systems is not possible, owners of control equipment should consider the following. Note, however, that ANY of the actions indicated could (a) fail to remedy the problem, and (b) produce further, potentially more serious problems.
Where absolute date and time information is not required, failure in proper date rollover is unlikely to cause lasting problems. A re-boot of the system should remove any erroneous time offsets introduced by the faulty transition. Many machine manufactures are recommending that systems be turned off prior to 23:59 and turned on after 00:01 at the millenium. If using electronic timers to perform this task ensure that they have been compliance tested !
Systems reliant upon absolute date and time information will require their clocks to be reset at the appropriate hardware/firmware/software level. This must be anticipated in advance as often specialist hardware and/or software is required to perform such an operation. Some system clocks will not permit setting of the correct date and time. Where systems are not reliant upon the correct date and time for their fundamental operation, it may be possible to reset clocks to some arbitrary date and time which will permit continued operations (possibly with some consequent faulty date and time reporting).
Where facilities for resetting date and time do not exist, and the system will not function, temporary removal of batteries from real-time clocks may produce a reset which will permit some level of functioning. It would be most unwise to rely on such remedial measures however.
Bohner S A, Arnold R S, 'Software Change Impact Analysis', IEEE, 1996
Bullock Peter., 'The Millennium Time Bomb', Computers and Law Oct / Nov 1996, pp 3-4)
XEPHON, 'The Millennium: Problems and Solutions', Xephon , 1996
Zvegintov Nicholas, 'A Resource Guide to Year 2000 tools', Computer (IEEE), March 1997 vol 30, no 3 pp 58-63
http://www.iee.org.uk/2000Risk
http://www.ccta.gov.uk/mill/mbhome.htm
http://www.cssa.co.uk/cssa/new/millen.htm
http://www.weblaw.co.uk