Embedded Industrial Control Systems and the Year 2000 Problem

Technical Report TR97/11

David Collins


Department of Computer Science

Keele University

May, 1997


This paper examines the Year 2000 (Y2K) problem from the perspective of users of distributed industrial control systems. The diverse nature of such systems makes compliance testing difficult and increases the likelihood that time and date anomalies will occur. The author provides guidance on checking for Y2K compliance and indicates likely problem areas.

1. Introduction

The year 2000 (Y2K) problem as it applies to industrial control is a complex one. The author has approached a number of leading manufacturers of control equipment seeking information regarding Y2K compliance. The initial response was generally a reassuring one, typical responses including "Yes our equipment is Y2K compliant", "Yes we have four digit dates" and "There is no rollover problem". However, more probing questions produced answers which were more vague and less reassuring. For example, "We provided the option of two or four digit dates" and "The Real Time Clock card may need resetting". To obtain useful information about industrial control equipment it is essential to ask focused questions of the manufacturers responsible for the different elements of the system. This paper seeks to assist the end-user of industrial control equipment to phrase and direct such questions.

2. The Architecture of Industrial Control Systems

Industrial control systems have a number of different elements which may produce date anomalies as we approach the year 2000. The controller itself is generally but a small part of the overall system.

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.

2.1 Controller Firmware

The term 'firmware' is used here to represent the logic placed in the controller by the manufacturer. Firmware programs are stored within a memory device (typically an EPROM chip) and for most purposes are regarded as an integral part of the machine. Such firmware may make use of date and time information, but such use is likely to be limited. In general, the statements that manufacturers make about their controllers will encompass all firmware within the equipment, but clarification should be sought. The version/revision number of firmware often appears printed on a label adhered to the exposed surface of the EPROM chip.

2.2 Controller Software

I refer to 'software' within the controller as the element of the controller's logic which has been programmed by a commissioner, the customer, or by an OEM who is using the controller as part of a product (an industrial mixer or temperature control system, for example). Software is generally placed into a memory device known as an EEPROM or into battery supported RAM. A controller that supports 4 digit dates with proper rollover behavior may contain software which fails to make use of these capabilities. Controllers typically have scarce resources with respect to storage and processing. Controllers can be used more efficiently if storage and processing requirements are minimised. This provides a strong motivation to use two digit rather than four digit dates and the practice is quite widespread. Users concerned about controller software should determine which organisation was responsible for its production and then seek the requisite assurances regarding compliance. This is likely to be a considerable problem, not least because such assurances may only relate to specific revisions of the software. The author is aware of systems which have used one byte to store month/year data !

2.3 The SCADA Supervisor

Most controllers installed over the last decade will have SCADA (Supervisory Control and Data Acquisition) software effectively acting as a 'client' application to provide input, scheduling, monitoring and logging functionality. This software is sometimes provided by the manufacturer of the controller but it is often provided by an OEM supplying a particular control product. More often, it is provided by a third party specialising in the production of such software.

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.

3. The Nature of Y2K Problems

The date and time problems associated with the year 2000 are trivial and can be exemplified in just a few statements:

(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.

3.1 Ascertaining the Problem

To ascertain whether a problem exists, the following steps will need to be taken:

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 ?

3.2 Remedying Problems

Where problems are identified, remedy must be considered. For systems purchased between 1995 and 2000 it is reasonably clear that UK law would require suppliers to ensure compliance without cost to the customer. Where original system specifications stated an expected system life to and beyond the year 2000, similar expectations would apply. Where such specification was not provided, the customer would have to show that it was reasonable to anticipate a product life-expectancy in excess of five years.

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.

4. Conclusion

A methodical approach to the Y2K issue should permit most problems to be resolved with the assistance of equipment suppliers in advance of the year 2000. Where compliance assurance cannot be obtained, organisations should prioritise capital replacement with respect to the criticality of systems to their successful operation. Most organisations will need to commit resources to the requisite audit processes and capital replacement requirements. Authoritative commentators suggest 20% of annual IT budget over the next three years.


BCS, 'The Year 2000: A Practical Guide for Professionals and Business Managers', British Computer Society, 1996 (ISBN 0 901865 97 4)

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

Web Sites






[Year 2000 Date Problem - Index Page]