Year 2000: No Surprises
Software in your enterprise will start to reach into year 2000 and beyond well before the first day of business in the new millennium—Monday, Jan. 3. People at all levels in your operation are probably already assessing, converting, and testing. Ideally, by the time 2000 rolls around, there won't be any unpleasant surprises, especially on the plant floor.
Software in your enterprise will start to reach into year 2000 and beyond well before the first day of business in the new millennium—Monday, Jan. 3. People at all levels in your operation are probably already assessing, converting, and testing. Ideally, by the time 2000 rolls around, there won't be any unpleasant surprises, especially on the plant floor. That's the plan, anyway.
However, unlike production planning and scheduling applications that already reach into the next century, year 2000 problems in process control and factory automation may not manifest themselves until at or very near the year 2000. In addition, the complexity and evolving nature of many plant or process automation systems can make year 2000 diagnosis difficult.
Discrete, process automation
Year 2000 projects often don't touch the plant level, except for financial, communications, or network applications, according to Ken Owen, a principal consultant for Fluor Daniel (Greenville, S.C.). At hundreds of plants his company has encountered, millennium compliance has been an unattended situation. Fluor Daniel is a systems integration, software, and engineering services company.
Millennium compliance problems can exist in any application at planning, execution, and control levels that use 2-digit year data structures. At 2000, the 2-digit structures may treat "00'' as 1900 rather than 2000, causing incorrect calculations, system shutdowns, or malfunctions.
The problem exists in software applications, operating systems, hardware, and firmware, including programmable logic controllers (PLCs), various embedded computing systems, smart instruments with real-time clocks, robots, human-machine interfaces to controls, and data historians for plant-floor processes. Systems such as materials management, execution, or maintenance applications, automated tool cribs, and production process modeling tools also need to be assessed. Data acquisition and data-historian applications are date-aware and prone to year 2000 problems, as well, says Mr. Owen. Also, heavily automated systems often rely on local-area networks for dates and times, so network compliance may come into play.
Mr. Owen says an inventory of automation systems should focus on high-risk applications. Some bad time stamps may not threaten operations, but corrupted quality control data or missed machine alarms could wreak havoc. Time is short. Assessments can take one to two months per plant; replacing complex automation systems can take much longer. "Most projects are in a triage mode, where you identify high impact exposures, plan contingencies, and keep moving forward, while documenting the project so you can come back and hit any problem areas you've missed," says Mr. Owen.
PLCs, VAXs, PDP 11s
Bob Brown, vp with Bluegrass Year 2000 (a Lexington, Ky., group of IS and industrial engineering professionals), says most PLCs will be unaffected since they work on the concept of elapsed time rather than dates. System functions are more important since some PLCs are involved in date coding, he says.
Dan Miklovic, a senior analyst for Gartner Group market research firm (Stamford, Conn.), adds that most embedded-systems problems are "with smart instruments or sophisticated gaging systems that use real-time clock chips to calculate date-dependent recalibration intervals or other maintenance routines. Most PLCs, up until recently, didn't use real-time clocks."
Upstream points in systems may have problems. For instance, Mr. Miklovic says, most PCs installed prior to mid-1996 have basic input/output systems (BIOS) that append "19'' to the front of the 2-digit information during reboot operations. A reboot after 2000 will tell affected PCs it's 1900; since these PCs usually run Microsoft DOS or Windows operating systems, they will default to 1980 or 1984, causing application malfunctions. (See related article.)
Prior to PCs, computers such as Digital VAXs and PDP 11s were used with PLCs, and may still be in use, Mr. Miklovic says. Older computers may be more vulnerable, depending on operating system age. Control-level computers perform a specific task that may not change for decades, as long as they work, he says.
Mr. Owen says any assumptions are dangerous. "You have to ask how controllers are being used and how they function in larger systems." He recommends contacting the vendors.
Help from vendors
Automation vendors have been bringing product lines into compliance for several years; most software vendors recommend upgrades to year-2000 compliant versions.
At Fisher-Rosemount Systems (Austin, Tex.), the minor year 2000 issues that do exist are being addressed by version upgrades and plant-specific service programs. The company identified the products of concern, then folded a fix into upcoming product revisions, or scheduled a fix if the product wasn't up for revisions. For customer installations, Fisher-Rosemount is folding any year 2000 analysis into ongoing work.
The Foxboro Co. (Foxboro, Mass.) says it is working with customers to ensure any fixes necessary will be in place well before problems occur. Newer client/server systems for "soft control" of process automation also are being assessed—and any application that uses dates has to be examined. The company says work is easier within an off-line testing environment for open client/server systems than with automation systems that rely on proprietary hardware or embedded logic.
Rockwell Automation (Milwaukee, Wis.) is reviewing all its industrial automation products for year 2000 compliance; some older PLC models have two-digit date structures, but most are free of problems. Difficulties could arise if customers' programmers masked out two digits of the date structure to conserve memory.
Schneider Automation (North Andover, Mass.) says users with 2-digit Modicon products should ensure their applications do not use subtract or divide functions, which might negatively impact the process. Test results are available.
Roberto Michel of Manufacturing Systems magazine (Carol Stream, Ill.) and Mark T. Hoske of Control Engineering contributed to this article.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.