The year 2000 problem is all about how dates are stored in computers. You’d think it’s simple enough – but it’s evolved into a dilemma on a grand scale. And, it has its origins in the early days of computing – when storage capacity was much more of an issue, and programmers scrabbled to save every bit and byte. Minimising resources meant calling 19 a constant. So the date was abbreviated to two digits.
Although the programmer’s assumption that systems would be replaced well before the year 2000 was correct, unfortunately many of the original code fragments were reused in new systems. Thus, the two digit year remains in many of today’s applications.
So at its most basic, the problem can be viewed as the inability of the system to consider a move from the year `99 to `00 as a transition. In some cases, people born in 1964 will go from 36 to 64 years old overnight!
Is this just industry hype? No; although some are cynical of the publicity, the statistics are really alarming. One of the leading consultants, Peter de Jager, has estimated the cost world-wide at some $1,300 billion. And, given the time necessary to implement changes, it’s debatable whether there are enough software engineers alive!
If you’re not sure whether you have a problem, ask your supplier. You may be surprised – very few guarantee compliance. And, the point is that this is not just a business IT concern. If your systems have a real time clock, or do any form of scheduling or date-related processing, you may have a problem. Although most systems will almost certainty run without significant problems in the year 2000, some will not. The issue, of course, is identifying which ones!
Systems that may require conversion fall into three categories – primary (mission critical), secondary (those that can be converted at a later date) and tertiary (which can be managed without). The process control industry’s systems almost all fall into the primary category. And, while blue-chip companies now have IT task forces tackling year 2000 compliance, the danger is that many SCADA applications, bespoke process controls and PLC code, will be ignored.
Is this a hardware or software issue? It’s both. All hardware with real time clocks is at stake, and any software that uses the hardware time or does any form of date-related processing is also vulnerable. While some hardware could provide year 2000 compliance, as could software, interaction between the two may not function.
Even comms between hardware platforms does not escape. Network clients that synchronise their system clocks with a network server based on a different operating system and/or hardware platform, may find that their clients cannot cope with the date information.
Operating systems are dependent on the hardware platform, and applications are dependent on the operating systems. Earlier SCADA systems and DCSs that provided their own real time operating shells have an additional layer which can compound the problem further.
If you’re thinking `it’s just my older computers and applications that may have problems’, think again. True, the problems are inherently more complex with legacy systems. First-line support on these platforms can be thin or non-existent. Often the hardware is no longer produced and the suppliers have moved on – or out. Older systems still in place are usually there because the application runs successfully with little or no maintenance. So experience on these systems has probably dwindled away.
But, platforms as current as the PC are not without problems. Many PCs produced as late as the early `90s have BIOS problems preventing them from successfully making the transition to the year 2000. One example is the recent power save facility, which may see the transition of 1999 to 2000 as a 99 year lapse of no activity – and shutdown all motherboard operations on the stroke of midnight!
Operating systems such as the UNIX variants and server software will have a range of OEM and third party `patches’ available, and many are available now. However, not all shrink-wrapped applications are year 2000 compliant – and this even includes Microsoft Office. Certain versions of Microsoft Access will have defined problems beyond 1999. This alone could have serious implications for SCADA systems with MIS-based relational database links – even on systems fitted as recently as the last two or three years.
Bespoke applications will undoubtedly cause the biggest headaches, regardless of the age of platform – especially when this is combined with non-generic hardware. Testing becomes a real issue here; altering the date alone may require expertise! A further not uncommon problem is that the date modification renders the system unusable, without any method of returning to the previous operable state. Here, professional risk analysis must be sought long before any testing programme is embarked upon.
How long have you got? As of 1st January 1997, there were only 783 working days left. And it’s not clear cut that your problems would start then. Think-ahead systems that use the system date a month, three months, or even a year ahead will start much earlier. A batch operating system that uses production forecasts to calculate future stock and ingredient usage four months in advance may well cease functioning long before the end of 1999.
On legacy systems, the best option may be a system upgrade. As this solution must be the result of a risk and impact analysis, which would have to proceed long before testing, on medium to large systems the contingency is fast becoming almost non-existent. Remember; this project has a non-negotiable deadline!
Incidentally, there are also some problems with the move from the year 2000 to 2001. Many two-digit date systems would re-interpret this as a return to a 20th century period. Also, many systems incorrectly state that the year 2000 is not a leap year – it is!
What should you do? Knowing where to start is the biggest problem. Ultimately, regardless of your projected upgrade path, retained knowledge is crucial. A site-wide evaluation will help pin-point those systems most likely to be at risk. And, don’t dismiss some systems; chances are that if your PLCs talk to other PLCs, which all talk to your SCADA – and your SCADA talks to your MIS, then the process will be as strong as the weakest link.
Some PLC hardware types may require a full qualified date for telemetry and data logging, and year 2000 operation may be out of its scope. A change here may produce a knock-on, necessitating changes to a connected SCADA system, even if that part is 100% year 2000 compliant.
There’s no easy solution. If your supplier can’t guarantee that your system will work in the Year 2000, you’ve no choice.