Y2000 ACADEMIC WHITE PAPER: Wonderware Corporation
=================================================================
Year 2000 Issues In Industrial Applications
Date: 9/18/1997
Author: Michael Brost
Copyright 1996, 1997 Wonderware Corporation
100 Technology Dr.
Irvine, CA 92618
All Rights Reserved
This document contains information of a proprietary nature. ALL
INFORMATION CONTAINED HEREIN SHALL BE KEPT IN CONFIDENCE
(NOTE: Retreived with permission from the Wonderware. SEE END OF THIS POST.)
The document summary information is used to control the project name
(title), document name (subject), and author. The date and revision are manually edited on the title page and in the first header. After updating the document summary information, select the document (use the menu command Edit/Select All or the Ctrl-A) and then update all fields using the F9 function.
_____________________________________________________________________
Year 2000: An Equal Opportunity Disaster
Year 2000 problems have been widely publicized with respect to software applications running on "old" computers. However, most of the attention given to these problems has centered around business applications such as finance, banking, payroll, purchasing etc. These have received the majority of the attention since they have an obvious link to date-time manipulation and have been more concerned with IS applications and organizations. But plant floor applications may be just as vulnerable to the millenium problem, so Year 2000 might potentially be an equal opportunity disaster on an enterprise-wide basis.
Unlike office or corporate level computing applicatins, plant floor systems have traditionally been the domain of the engineering groups. They usually are purchased and deployed without the assistance of an IS group, therefore these systems have been largely overlooked in the first pass of Y2K committees when addressing the organizational impact of Y2K.
Plant floor systems are largely composed of distributed applications running on a variety of platforms. The majority of these installations involve programmable logic controllers (PLCs), human-machine interfaces (HMIs) and a variety of I/O devices (sensors, bar-code scanners, scales,flow meters, instruments, etc.) of varying intelligence. On the surface, most of these components can appear to have little relationship to Y2K - but it's important to understand the real scope of the problem before accepting a blanket compliance.
To understand the broader issues, this paper will focus on three areas where problems can surface. The first is the operating system, where the system's date is maintained. This will be followed by application development software and finally by the individual user-developed programs that run the plant. The risk for Y2K compliance dramatically increases through each level.
PC-based control and information systems have been deployed widely in manufacturing plants, process industries and utilities. These applications usually include HMI, historical real-time database, statistical process control (SPC), supervisory control and data acquisition (SCADA), real-time control, and production management. Most of these systems have been deployed on MS-DOS, Windows 3.x, Windows 95 and Windows NT operating systems. Many systems that were deployed on early versions of these operating systems are still in operation today - for good reasons. These systems have been commissioned and validated and have offered stable operation for the tasks they are asked to perform.
Previous changes to these older systems have in many cases been delayed or rejected due to the potential for process or manufacturing disruption, whether real or imagined.
These systems however rely on correct date and time to function correctly. Historical data is time-based, alarms are logged with a time reference and events are recorded by time. Simply put: having the correct time is critical to prevent loss of data and system errors.
How Do Computers Keep Time?
To understand the Year 2000 problem and how it impacts industriall systems we need to analyze the method of keeping time in the PC. It's usually maintained in two places: in the CMOS real-time clock (RTC) and in the software operating system. This serve two purposes. The first keeps track of the time while the computer is turned off; the second keeps track of time while the computer is turned on.
When a computer is turned on the basic input/output system (BIOS), which manages the computer's operation, gets its date-time reference from the RTC. This is used to initialize the operating system to reflect the current date-time. From this point forward the OS then manages the system date-time. But what about the date reference?
Storage of the year portion of the date in the RTC is maintained in two memory locations. The first stores the century (19, 20, 21 etc.) and the second stores the year (0-99). In most PCs produced to date (and even those in current production) the century location is not updated by the RTC. This location remains fixed until it is changed by the OS via a SET DATE command or similar function. Currently the century number is set to 19 which represent 19xx. The year location contains the remaining 2 digits of the 4 digit year and will be continually incremented by the RTC until 99 whereupon it will rollover back to 00.
On December 31, 1999 at 23:59 hours, the date-time in the RTC will change to January 1, 1900 00:00. This will occur because no user or program has incremented the century location of the RTC. TheOS date-time will also be incremented, if the computer is running during the transition, to January 1, 2000 00:00. This is because the OS keeps track of the date-time independent of the RTC when running. The date-time of the RTC and OS are now out of sync and will remain that way until corrected.
On reboot of the computer the RTC will report to the BIOS a date-time with a year of 1900. This will be recognized by the OS as an invalid year and set the date-time to January 4, 1980. This is the oldest acceptable date-time for the OS. MS-DOS, Windows 3.x and Windows 95 will behave this way. Windows NT has been designed to automatically detect the transition and correct the problem. Within Windows NT you can set the correct date using a DOS DATE command and this will in turn correctly adjust the RTC.
If the computer was left running during the transition, the RTC and OS will have incorrect and correct date-time values. The RTC can then be corrected with a DATE or TIME command before powering down and rebooting. There are also third party programs from web sites such as rightime.com which will monitor the transition and correct the system date in the RTC when the century changes.
No matter how it's reset, there is an upper limit on the date for each OS which is dependent on the method used to calculate the current date.
The following table shows these limits:
Operating SystemDate Limit Date FormatMS-DOS
Windows
WFW
Windows/95
Windows/NT (FAT)
Windows/NT (NTFS)
2108
2108
2108
2108
2108
29,601 16 Bit
16 Bit
16 Bit
16 or 32 Bit
16 Bit
64 Bit
With the exception of Windows NT-based systems, most PCs and operating systems will have a problem with the transition to the year 2000. That problem lies within the hardware RTC and its inability to increment the century memory location. This can be corrected by adjusting this value via some external means. Then, after the date-time of the RTC has been set correctly, the system should continue to provide reliable date-time information until the next rollover occurs at the next millenium, or until the date limit for the OS is reached (which occurs in the year 2108, except for Windows NT.
What About Application Development Tools?
Application development tools are used for configuring the specific applications that run a factory. Handling the date-time in the year 2000 presents several areas of concern for most application development software programs:
1.What century is implied with a two-digit year?
2.Is the correct day of the week returned?
3.Year 2000 is a leap year. All years ending in 00 are leap years when divisible by 400.
4.Can the application accept a four - digit year reference and what is the maximum year allowed?
5.Are there special meanings for dates such as 9/9/99?
6.Are dates used in the generation of unique filename?.
Date manipulation in most PC application software is not provided by the operating system. There are no standard mechanisms for interpreting and handling date functions. The date function is usually relegated to compilers and custom code provided by the vendor. As a result, very few applications (even those developed by the same vendor) handle dates in the same way. Looking at several application development tools from Microsoft itself can illustrate this problem.
Product Name2-Digit YearMaximum YearMS Access 95 and earlier1900-1999
9999MS Access 97 ( 1900-19999999MS Access 97 (Win95, NT4.0)1930-20299999
MS Excel V4, 5, and 71920-20192078MS Excel 971930-20299999Visual C++ 4.x
N/A2049Visual Basic (4.0 16-bit)Current Century of System Date9999Visual
Basic (4.0 32-bit)1930-20299999MS Project 95N/A 2049
If an OS, networking and application software powerhouse has this many variariations, how can anyone expect the typical industrial application program to respond with a 2000 year in the date? Can a date-time be entered with a 20xx year? Is February 29, 2000 a valid date? There are no simple answers to these questions.
Many applications produced before 1996 - and even some current software - do not have provisions for accepting a four-digit year reference. Instead, when entering a two-digit year, the century part is implicit. A windowing technique is used so that, for example, if the year reference is smaller than 30, then the year falls between 2000 - 2029. A reference of 30 or greater translates to 1930 - 1999. There is no standard for this century interpolation, however. Each application program sets the break point differently. Some will always utilize a 19xx century and not be able to access any dates in the 20xx range.
In the 32-bit Windows 95 and Windows NT operating systems from
Microsoft, an "OLE Automation Library" has been provided with functions that convert two-digit year references to four-digit years. This is intended to provide a common method of performing this conversion. The functions can then be easily modified to account for different windows by updating the library. Current versions of this library on Windows 95 and Windows NT 4.0 translate two-digit years to 1930 - 2029. Older versions of the library translated to 1900 - 1999. Application developers who use this library should be able to standardize on date conversion. There is one caveat, however. While this is a great benefit to new and current software, it offers no benefit to a "legacy system" on an older OS or with application tools in which the OLE library has not been used.
This is the issue that presents a potentially serious problem with industrial applications.
Unlike an office PC, most of these systems will be running continuously though the Year 2000 transition. They will be performing control calculations; logging data, alarms, and events; performing SPC tasks; and tracking production and batch history. When the year rolls over from 1999 to 2000 no one knows how the application will handle these functions. Even if the operating system date is managed correctly, the application software will fail unless the year 2000 transition was included in the software design. Obviosly, this can present serious consequences to an industrial application. The scope of these applications can be far-reaching and their full effect probably won't be realized until the event happens - and then it will simply be too late.
Knowing that date failures in industrial applications can range from a benign nuisance to a serious interruption of production or even result in hazardous situations, it's critical for users to understand the
implications of a date-time failure within their application development tools.
The Nits & Grits of User-Created Applications
Once you've resolved the date problems with your operating system and application development tools, you can breathe a little easier - but you can't relax yet. While these systems form the core of our industrial automation solution, they aren't the software that does the actual control of your production processes. Your factory is controlled by application-specific programs that were built using the various tools referred to earlier. Date problems in the application area can be even more numerous, complex and difficult to diagnose than the problems encountered in the OS and development tools.
In plant-floor systems that are used to schedule, track and manage production the reliance on correct date is fairly obvious. Within this environment dates are used directly to predict completion dates. To
determine the history and genealogy of material as it flows through the process. To account for labor and resource consumption. Even customer orders are future-dated, based on production rates, to synchronize different processes within a plant. Documents are dated to be valid within a certain time window. Maintenance systems take equipment off-line. Work orders are scheduled and issued. Any of these subsystems can be a source of confusion and downtime if they begin to behave erratically from misinterpreting a year 2000 date.
As you get more granular within the factory, the problems associated with Year 2000 dates become more application-specific and harder to
isolate. Control systems can be summarizing information for archival
storage based on shifts, days, months etc. Specific control functions
may be implemented based on day of the week. Tasks such as turning on or off HVAC equipment or adjusting temperature set points on the weekends are time and date dependent. Security access programs might deny access to buildings on the same premise. Or worse, they might provide unauthorized access. Even many PLCs are set up to provide date functions within their instruction sets. These have been used to trigger various control actions for a variety of situations.
Diagnosing all these potential variations in date/time implementation can be difficult, especially when documentation of plant floor systems can be difficult to obtain. Many of the tools used on the plant floor
allow editing and programming while systems are in-process. This means systems evolve over time and are adapted to changing needs in manufacturing plants. While these features provide tremendous benefits in terms of allowing continuous improvement efforts, their continual
modification usually means documentation is an after thought at best.
Obtaining source code for some of these applications can also be
difficult. Through computer upgrades and development platform changes,
many existing systems are no longer "fixable" since they were deployed
under an old platform. They were never kept up date with software
revisions, so these application programs may not function under the
latest release of the development tools provided by the vendor. Nor will the old tools function under current OS releases. These items often are no longer commercially available and have to be special-ordered from the vendor (if they exist at all). In the worst case, the logic contained within these systems cannot even be analyzed after having been compiled and downloaded. Options at this point will be limited to "wait and see what happens" or redeployment under a newer version of the tools.
One last consideration: a significant percentage of a plant's resources will be consumed in certifying Year 2000 compliance. This will probably draw resources away from all the important projects that are being planned to improve the factory applications. Development of new products and processes may be delayed.
The Year 2000 problem may actually be a bigger problem for the factory floor than it is for the front office. It's imperative that users begin to deal with it now.
_____________________________________________________________________
Y2K ARTICLE BY WONDERWARE
Date: Fri, Oct 3, 1997 09:45 EDT
From: CaptJackl (AOL Motley Fool)
Message-id: <19971003134501.JAA24112@ladder02.news.aol.com>
I retreived this with permission from the Wonderware web site. |
