Year 2000: Where Do You Stand?

Year 2000 bug (aka Y2K or millennium bug) is touted as modern automation's biggest glitch. Financial impact is being bantered well into the high billions of dollars—all because two little numbers should have been four.In the late 60s and early 70s, computer systems were new and very costly.

By Eugene C. Jacobsen, TAVA Technologies February 1, 1998


Software for control

Year 2000

Industrial personal computers

Progammable logic controllers

Sidebars: Y2K Nightmare COMMON Y2K TIMEBOMBS

Year 2000 bug (aka Y2K or millennium bug) is touted as modern automation’s biggest glitch. Financial impact is being bantered well into the high billions of dollars—all because two little numbers should have been four.

In the late 60s and early 70s, computer systems were new and very costly. Programmers were forced to compromise among data accuracy, system speed, and cost. Many began programming dates such as 07/30/1990 as 073090, saving 4 precious character spaces. This compromise eventually became the industry standard date format “MM/DD/YY.” Even as new computer languages emerged and as memory became plentiful, the standard remained. And now year 2000 is upon us. All components, software, firmware, and hardware could bring the industry to its knees.

“Why not just put two digits back in?” This easiest of fixes assumes we know where the dates are. Over the years, there have been few, if any, naming standards. Not all dates in computer systems are prefaced by the word “DATE.” Some may be “BDATE” for “batch date,” or “QTIP” for a reason only known by the original programmer.

“Why we weren’t warned?” one might ask. We were. Some very astute people started bringing this to the news front back in the early 1990s. But instead of being embraced for their wisdom and forward thinking, they were shunned. Some media labeled them doomsayers, blowing a little inconvenience way out of proportion for publicity.

People most proactively addressing the issue are those associated with the upper level business systems—mainframes, the micros, and just about anything programmed in COBOL.

But what about the plant floor? Many people do not associate software programming with plant-floor control systems. Often, systems that track business data are the priority, even though without products from the plants, there would be no financials to track. In addition, many engineering staffs have been right-sized, downsized, and reengineered, so that even everyday operations require 60-hour work weeks. Even so, Jan. 1, 2000, is a deadline that won’t bend.

Manufacturing facilities need to get moving, and quickly. The Y2K issue goes much deeper than upper-level business systems. Have you assigned plant-floor project teams to identify the depth of the problem? Do you have a firm list of what exists on your plant floor?

The process can be organized into assessment, analysis, conversion planning, and implementation.

Stage 1—assessment

Setup project: Defining project scope requires determining necessary re-sources and a staffing plan. A typical complement would include a project manager, technical manager, contract manager, technical leads, analysts, and technicians. With most team members being “borrowed” from their full-time projects, this could take longer than expected. Check out any lists that already exist at your facility. Check financial asset lists, floor plans or process flow diagrams.

System inventory: This is one of the most time-consuming activities. Amount of time required depends on the type and size of the facility. A good rule of thumb is approximately one man-day per single story building. Obviously, the more complex the operation, the more time will be required. Note any duplicate equipment so that it is only added once. Use common spreadsheet or database packages to compile your inventory. You’ll find the sorting capabilities invaluable.

Stage 2—analysis

Suspect analysis: All items compiled in your inventory list must be researched for compliance. Vendors can be queried or individual items can be tested onsite. Beware, however. Testing must be done in extremely controlled situations. At times, simply setting the date forward to see the result can result in lost data due to archival configuration settings.

In some instances, this test could even invalidate system licenses. The result of this phase would be to identify which systems are compliant or noncompliant. The time required for this phase is determined by size of the inventory list, the amount of cooperation received from the vendors, and the testing capabilities of your facility. Develop standard forms, such as vendor questionnaires, so that the workload can be spread across multiple resources without risk of data loss.

Impact analysis: The goal of this phase is to analyze known failures in terms of their relative impact on the systems and plant operations they support. Once again, the complexity of your operation will dictate the amount of time needed. Identify which systems are mission-critical and therefore need to be addressed immediately. Minor systems that have no direct impact can be put off to later, if addressed at all.

Stage 3—conversion planning

Project planning: As with any systems integration, this phase is extremely important. Depending on the size of the systems being modified or replaced, the time spent here will impact the time spent in the Implementation Stage. More in-depth upfront planning translates to smoother (and quicker) implementation. All the recommended Y2K projects are ranked on the basis of importance to the system, ease of correction, cost, and time involved.

Stage 4—implementation

Project execution: Depending on whether a system is being upgraded or replaced, this phase varies. Older systems are usually replaced as the cost can be capitalized. Costs associated with upgrading systems for compliance usually must be expensed. As most engineers know, systems implementation schedules have a tendency to drag on well beyond there original completion dates. This cannot be allowed for Y2K projects.

Testing/commissioning: Type, size, and industry for an upgraded or replaced system will dictate the amount of time required for this phase. The standard time estimates for systems in your plant should prevail. FDA validation regulations could impact this tremendously.

The most important rule is to start now, if you haven’t already! Procrastination could ruin productivity, as well as careers. Jan. 1, 2000, will come, ready or not.

For more information, visit .

Author Information

Eugene C. Jacobsen is director of operations for TAVA Technologies/ACS in West Chester, Pa. TAVA Technologies (Denver, Colo.). is among the largest U.S. independent information and control systems integration companies, with more than 350 personnel.

TAVA Technologies’ PlantY2kOne package of product and services addresses year 2000 compliance.

Y2K Nightmare

It’s early Monday morning, Jan. 3, 2000, at Acme Drug Co. So far, the new millenium looks a lot like the old one. The first shift is clocking in, prepared to restart the plant after the New Year’s holiday weekend. Everyone is energized for the new year.

By 7:30 a.m., the lines are set up, supply feeds are stacked and ready, batching tanks are topped off, and operators are at their stations. All appears ready. Production supervisors check readiness and begin restarting equipment.

The plant manager is busy organizing and checking scheduled meetings. It appears there should be no problem meeting production orders. Orders are up and production efficiency is at an all time high. Piece of cake, the plant has been running great.

Plant engineering is easing into the day. Equipment has been tuned up and serviced over the holidays to eliminate downtime.

Conveying systems’ blowers come to life. Temperature control loops start pulling steam into long winding coils surrounding batch tanks, slowly heating up vessels. Operators key in the day’s first batch data. Batch validation documentation, that favorite of all operations people in any FDA-regulated manufacturing facility, is opened and recorded for this year’s first batch. All information is recorded for the batch. Operators are keying the batch information into the supervisory control and data acquisition (SCADA) system. This information is to follow the product from batching unit to batching unit, clear to the shipping dock. It is key data that will become the life story for that batch. Everything appears to be fine, until…

Batching area operators notice a 1980 date on the screen, automatically pulled up by the computer. “Oh,” an operator says. “I’ll just enter the correct year.” After repeated attempts, it becomes obvious the system will not accept “00” as a valid date.

Simultaneously, operators in the raw ingredient storage area notice system alarms while checking inventories. Alarms indicate PLC communications errors. PLCs pass batch data to each other while the product passes through the process. These operators call plant engineering.

Plant engineers try to remedy the situation. Management demands an explanation as well as a quick fix. Official production start time has long passed—production is at a standstill.

In the plant manager’s office, the situation appears bleak. Lost production costs big bucks by the minute.

If only someone had an idea where they should even start looking…

Hopefully, enough will have been said and done about year 2000 so this nightmare doesn’t invade anyone’s plant.


According to a website statement from Gateway 2000, “If you purchased your system before July 1, 1994, or you have a VESA Local Bus or ISA-based system, then you will need a third-party BIOS [basic input/output systems] upgrade to become century compliant.”

Early versions of the leading spreadsheet packages will interpret two digit year entries such as “01”as 1901.

Earlier versions of leading operator interface systems are recommending upgrades prior to year 2000 due to noncompliance.

Some gas analyzer models by a leading vendor are not compliant as they do not recognize the year 2000 as a leap year. The vendor is discontinuing the model.

One of the world’s leading PLCs loses accuracy on leap day of leap year. The problem can produce a 2.5% loss of time in time-based functions. This affects fixed scans, time-based instructions and cyclic analog task activities.

All PLC and SCADA application code allows for user control. Any date-related programming could impact trending and archiving of data required for FDA regulations.

A small issue such as a BIOS upgrade could have a substantial ripple effect. Since most plant floor operator stations are computer based and contain earlier BIOS versions, problems are identified with just scratching the surface.

Source: TAVA Technologies, Denver, Colo.