Will the millennium bug give your operations the flu?

Don't take the head-in-the-sand approach toward potential computer strangling of production operations. Time-contingent process controllers must be evaluated for year 2000 date stamp limitations and their implications for safety, the environment and operations

Scott M. Shemwell, Jerry Dake and Bruce Friedman, MCI Systemhouse, Houston, Texas

uman history is replete with mystical and religious concerns over the end of a millennium. Armageddon or end-of-the-world scenarios are typical refrains. This time, oil and gas producers may face a more identifiable plague. Then again, Jan. 1, 2000, may come uneventfully — as has every thousand-year transition of the past.

For more than 15 years, the oil and gas industry has expended a massive effort to re-invent itself. We all know that none of our firms would be competitive in today's market, if we had not made these hard decisions. A linchpin of the industry's success has been the reduction of the corporate cost structure through the use of technology and process re-engineering, much of it computerized. All of this work is potentially at risk, if serious loss of production is sustained as a result of unplanned computer shutdowns in many segments of the business, all at the same time.

THE MILLENNIUM BUG

As we close on the first 100 years of the "information age," we are faced with a legacy from the medieval computer past. In the computing dark ages, processing power, memory and hard disk space were an expensive premium. Like the wizard Merlin, programmers of that bygone era concocted software brews, the recipes of which now are, more often than not, non-existing. They certainly did not take one important fact into consideration.

No one expected that some legacy software, with roots often over 30 years old, still would be in general use today. Further, as these recipes or programming techniques were taught to modern-day wizards, they, too, adopted the same incantations. Therefore, even new software programs may have the same limitations.

How the problem started. Today, we live in a world in which computer software is fundamental to our very way of life. Computers are everywhere — from mighty mainframes, high-performance workstations and PCs, to games, toys and even automobiles and household appliances. Many software programs driving our business functions have one thing in common — limitations of the past dictated that the variable calendar year be represented by two digits instead of four, e.g., 1966 would be expressed as 66 and 1998 would be 98. This was an efficient method and did not present any problems initially. This date stamp limitation is the so-called "millennium bug."

A simple example. As one example, consider a simple problem. An oil and gas market researcher is interested in the buying patterns of his forecourt customers. He commissions a survey and asks 100,000 individuals a series of questions, one of which is their date of birth. In his analysis, he correlates age to a number of other variables, builds a profile of his customers and uses this profile as part of his next-generation product planning. Sound familiar? Well it should, because it happens every day.

What if our hypothetical researcher conducts the same survey in January 2000? If his statistical software calculated the year by the last two digits (00), he may find three types of error:

1. He will discover that individuals born in 1960 are not 40 years old, but minus 60, e.g., 00- 60= - 60. The astute researcher will see this problem immediately and adjust accordingly to this inconvenience.
2. Any calculations involving the age of respondents such as "percentage of population over 30 years old" will be incorrect. This mistake may be more difficult to find and rectify, because age may be a variable in several processes. However, this is still largely a further inconvenience.
3. Age, or calculations made from age, may be the basis for more sophisticated analyses errors that may not be readily apparent to the researcher, such as what might occur with matrix algebra. When multiplied by 100,000 samples, this error may impact the validity of the analysis seriously. Business decisions made on the basis of these analyses are likely to be inaccurate and fail.

A serious problem. Our example is straightforward, relatively simple, and most errors can be detected and compensated for easily. The real world is seldom simple, and the stakes may be a good deal higher. What if, instead of an off-line market research project, our system was one or all of the thousands of embedded or "computer on a chip" process controllers on an offshore platform, Supervisory Control and Data Acquisition (SCADA) system or distribution pipeline? What is the impact of these three error types cascading throughout multiple-intertwined and mutually dependent on-line systems?

An offshore platform may have 10,000 or more embedded silicon chips governing all automated and even some manual processes. Many of these systems are subsurface or underwater and physically difficult to access.

PROCESS CONTROLLER CONCERNS

Unlike the software of a marketing system, the embedded logic on a silicon chip is entombed deep in the system and not easily ascertained. Any given Distributed Control System (DCS) or Process Logic Controller (PLC) computer board has many chips, and their interdependencies on each other, and on other system components, make them difficult to analyze and repair, Fig. 1.

	Fig. 1. Computer boards may require upgrading or replacement for year 2000 compliance.

Methods for analyzing this equipment are only now emerging. Compliance information coming from manufacturers has been sketchy and sometimes inaccurate. In some cases, the chips are no longer made. In others, the controller is manufactured in such a way that the entire unit must be replaced. Upgraded chips and new controllers also would have to be tested to ensure that their insertion will not impact drilling and production processes negatively. Some studies suggest that there may not be enough manufacturing capacity to just replace all affected chips in less than two years.

Few organizations have recognized the full potential for possible failure in embedded systems. Moreover, the supply of talent qualified to identify and correct these problems is being consumed quickly by other year 2000 projects. The longer that production managers wait, the less the likelihood that they will be able to affect the outcome pragmatically.

It is estimated that the average oil and gas firm, starting today, can expect to remediate less than 30% of the overall potential failure points in the production environment. This reality shifts the focus of the solution away from trying to fix the problem, to planning strategies that would minimize potential damage and mitigate potential safety hazards.

Some systems are experiencing failures, already. In a recent case, that resulted in litigation, a point-of-sale retail system installed in 1996 rejected credit cards with year 2000 expiration dates. Other lawsuits are likely. The legal profession expects to earn billions of dollars contesting millennium bug failures. The Securities and Exchange Commission (SEC) also is getting involved in this crux, requiring corporations to establish financial reserves to cover year 2000 exposure.

CONTINGENCY PLANNING

The recognition of issues surrounding embedded systems is a relatively late entrant into the year 2000 discussion. Companies only now are becoming aware that the most likely threat to the revenue stream, environment and safety is more likely to come from an offshore platform or refinery, than from a mainframe accounting system.

The reasons for this oversight are straightforward. The year 2000 problem has been characterized as an information technology problem and delegated to each organization's Information Services (IS) department. However, IS departments typically do not manage on-line, process control systems. The embedded systems issue is a process or business problem affecting all types of "intelligent" equipment throughout all business units, not just those computer systems for which IS departments are accountable.

Consultants and corporate IS departments have developed methodologies and automated software tools to address year 2000 issues in most segments of the computer industry. Some components of these approaches are applicable to embedded systems. However, there are three major issues that oil field asset managers face that are not as relevant for IS:

1. Process controllers and associated "intelligent" devices are integral components of real-time systems, Fig 2.
2. These systems may have component parts that are not the property of the operator, such as rented compressors.
3. IS personnel may not understand the process linkages and cannot take the computer systems down for maintenance, e.g., office computer systems are often taken off-line late Saturday night for maintenance and upgrades, with minimal business disruption.

Addressing these issues will require a cross-functional team. It should comprise individuals who are knowledgeable about the engineering processes in question and their relationship to other processes, the equipment involved and its level of automation, process control systems, and year 2000 hardware and software issues. Reporting to an oversight committee and the executive sponsor, this team will inventory the functional processes and control systems associated with those operations. It will then contact the control system manufacturer (or access commercially available databases) to attempt to ascertain year 2000 compliance for the devices in question.

With this baseline assessment, management can determine which systems are mission-critical from the standpoint of safety, environment and business operations. Systems that are deemed to be critical will require action plans to ensure that those processes are dealt with appropriately. This may require switching to manual operation or a planned shutdown. Plans also can be implemented for systems that are determined to be non-mission-critical but may malfunction, too.

Large organizations should prototype each process, so that this knowledge can be distributed to global operations in a cost-effective, timely manner. Multiple parallel teams can be used as required, since it is unlikely that a single team can physically assess all systems in less than 24 months. Moreover, local engineering knowledge will be required, because many processes, while similar, are not exactly the same worldwide.

Some remediation can be accomplished during planned maintenance. But operators must expect that due to work volumes and time shortages, the contingency planning process probably will drive millennium bug resolution. Complex systems that include equipment belonging to multiple organizations further complicate the problem, because it is important to completely understand what signal is sent by each electronic device. For example, a smelting plant in New Zealand lost several months of production, because one of its controllers did not recognize the leap year and shut down when it received an electronic signal that was different than the expected date, March 1.

Computer chips are becoming ubiquitous, with over 7 billion manufactured in 1996, alone. The millennium bug not only can infect production processes, but also every on- and off-line process in the oil and gas value chain, from seismic acquisition to the pumps at the gas station.

TIME TO ACT NOW

The year 2000 software problem is real. Many computer industry pundits estimate that fixing the problem will require hundreds of billions of dollars, and a few place that figure substantially higher. This is an important issue, but it need not be Armageddon. As with our market research example, many failures will be just an inconvenience; others may be more serious. There are many uncertainties, but what we do know is that failures in process control and monitoring systems can shut down facilities, damage the environment and jeopardize safety. Management's fiduciary responsibility to corporate stakeholders suggests that we develop an understanding of our situation, initiate a remediation strategy with contingency plans, and implement those plans that are relevant to our specific situation.

On a Friday night less than two years from now, a tsunami will build in the Pacific and roll westward through all major hydrocarbon producing fields before reaching Prudhoe Bay, Alaska. We know the exact date, not to mention the hour, minute and second. We do not know its size. As with all tidal waves, it is safer to take precautions and move out to sea, where its arrival may not even be noticed. Disaster strikes those who are unprepared and caught near shore. There is little time left to mobilize, so to speak, and move the world's huge oil and gas fleet to the safety of the sea.

The authors

Scott M. Shemwell is director of Oil and Gas at MCI Systemhouse. He has more than 20 years of experience in executive management, information management and international business within the petroleum industry. He has written extensively on a variety of management subjects. Mr. Shemwell holds a BS degree in physics, an MBA degree, and a doctorate in business administration.

Jerry Dake is director of Systems Integration at MCI Systemhouse. He has more than 30 years of experience in operations management, information management and finance in the process industries, both internationally and domestically. Mr. Dake holds a BS degree in civil engineering, an MBA degree, and doctorate in industrial administration.
 

Bruce Friedman is manager of Systems Integration for the Process Industries Business Unit at MCI Systemhouse. He has more than 15 years of experience in client server computing and information technology management. Mr. Friedman has written several articles on lowering the total cost of technology ownership.
 

Copyright © 1999 World Oil
Copyright © 1999 Gulf Publishing Company