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.

By Staff February 1, 1998

KEY WORDS

Software for control

Year 2000

Industrial personal computers

Progammable logic controllers

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.