ISA-106 and Concepts of Procedural Automation

For all the sophisticated automation in process manufacturing environments, there is one area where operatorsstill take manual control in many facilities: procedures to deal with infrequent operations. When it's time to start up a unit, make a grade change, adjust to a new feedstock, or make any number of specific adjustments to the process—operators often resort to manual operations out of necessity. Once the condition is addressed and everything is stabilized, the process is typically returned to automated operation.

This kind of thing happens in all sorts of plants, so why is it a problem? Here are three reasons:

1. The plant often depends on the skill of a single human being, or perhaps a small group for the execution of the manual procedures. Success depends on those key individuals doing a good job, which may not be a problem as long as the key men or women are around and know how to perform the procedure. However, given the demographic problems with aging workers, this type of dependence is becoming ever more perilous.

2. Few plants have procedures adequately documented. Many plants depend on the knowledge of those few skilled operators who know how procedures are to be performed, sometimes in accordance with documented instructions (assuming they exist), and sometimes following the "right way" in spite of what the instructions say.

3. Safety statistics show the majority of incidents not related to outright mechanical failures happen during abnormal situations, primarily unit startups and shutdowns. Lest we forget, the Kern Oil Refinery fire in January, 2005 occurred during a crude unit startup. The BP Texas City disaster in March, 2005 took place during a raffinate splitting tower startup. Unfortunately, there are many more examples.

The recipe for disaster is when an infrequent operation has to take place, but the key individuals are not available, leaving inexperienced operators to follow inadequate or incorrect instructions. Something can get out of control leading to an abnormal condition with undesirable outcomes of equipment damage, environmental release, injuries and/or fatalities.

Challenges of Automating Procedures

Infrequent operation procedures can be automated, but as already discussed, they often aren't. Why? There are several reasons, some technical, while others relate to human nature.

• Some companies simply don't consider it worth the effort when some operations happen so infrequently. Is it necessary to automate something that happens once a year and can be handled by a qualified operator? While the answer might seem simple, as already mentioned, it is becoming more complicated every day. Will key operators be available next time?
• Programming tools for old control systems do not make the process easy. If writing the code to automate a procedure is a complex and expensive undertaking because of the specialized skills required, it probably won't happen.
• If a given procedure is not well documented, how will the engineer responsible for writing the code program it? Without a clear sequence of steps, there is no possibility of creating the right code. Moreover, if the engineer designing the procedure is not available to work with the programmer, there is little chance for anything to be implemented correctly.
• If operators are not fully convinced of the accuracy and reliablity of an automated procedure, they tend to put everything in manual and do it themselves. It's not hard to find examples of operators taking matters into their own hands, and it's a reason why control strategy improvement programs in a variety of areas fail.

Creating a Solution

In spite of the problems, arguments supporting procedure automation are compelling enough to cause many companies to launch such efforts. ISA joined in by creating the ISA-106 committee in 2010. Much has been drawn from ISA-88 based on parallels drawn between procedures in continuous processes and batch processes. Other elements from ISA-84, ISA-95 and ISA-101 have also been incorporated in the effort.

Groups like NAMUR, the Center for Operator Performance (COP), and the Abnormal Situation Management Consortium (ASM) have provided resources and input. A variety of vendors and end-user companies have also pitched in including Dow, Bayer, Chevron and many others. The committee published its first technical report in 2013, covering models and terminology. It is working on the second technical report about work processes. Work on a standard is planned to start in 2015, using industry feedback from the technical reports to create the standard.

Models and Terminology

Any new standard has to begin by establishing basic definitions so discussions can proceed in a way everyone understands. Some of these are terms, and others are models reflecting how systems and equipment are deployed in actual process plant environments.

ISA-106 uses three key models: physical, procedure requirements and procedure implementation. These help organize various elements of the process to simplify analysis and create steps. Each begins at the highest level and drills down from the enterprise to an individual field device (Figure 1). Moving down the list, each level grows in numbers, so the lowest level invariably has the largest number of individual elements.

Figure 1. The three types of models operate in parallel, but each has a specific function.  

Physical Model: Organizes physical equipment according to a hierarchy from the enterprise level down to an individual device. Moving from the top level down, each level grows in numbers (Figure 2). This provides a common set of terms and equipment levels so different companies and even different industries can establish uniform reference points, enabling direct comparisons more easily. Looking at the list, it shows the possibility for any level to have procedures. There can be a procedure to start up an entire production site, just as there can be one for using an individual analyzer.

 

Figure 2. The physical model illustrates how each area of a plant is made up of different levels of equipment and components down to individual devices.

 

Procedure Requirements Model: This parallels the physical model by designating the same seven levels from enterprise to device. Its objective is to define a procedure by describing exactly what must be done to accomplish it. In so doing, it establishes the functional requirement for the automated procedure and ties these requirements directly to objects in the physical model. The lower the level, the more detailed the association between procedures and objects.

Procedure Implementation Model: This also parallels the physical model, but it begins one level lower, at the site rather than the enterprise (Figure 3). Things get more interesting here because now the actual procedure gets outlined in detail. With the equipment and the needs of the procedure defined—it's possible to construct the program, function blocks and sequential function chart. These must begin with the procedure requirements model as the specification, but there may not necessarily be a one-to-one mapping with the procedure requirements.

 

Figure 3. Implementation modules consist of ordered tasks that perform step-by-step actions. Each module has three execution work items: command, perform, and verify.

 

Each implementation module includes a set of ordered tasks, and those tasks may have their own sub tasks. Each task performs step-by-step actions in a defined order. There are three elements contained within each task:

• Command: Each task has to have something to trigger the individual action
• Perform: The actions themselves, and,
• Verify: Was each action performed successfully, or was there some sort of failure?

Each command-perform-verify sequence can include a mix of automated and human operations as appropriate for the specific task. For example, a human may need to verify if an automated task has been performed correctly, or vice versa. Once each command has been performed and verified, notification is sent to the next task in sequence.

The procedure requirement and implementation models must be accurate, or to put it another way, the automated procedures will only be as good as the models. If these are not thought through carefully, the procedure will not deliver the desired results and the effort will likely fail.

Delivering Value

Companies implementing the kind of program outlined above realize value in a number of ways:

• Improved safety—When automating procedures and using state awareness for alarm management, the operational staff's workload is reduced during infrequent operations. This enables faster and more effective responses to abnormal conditions while reducing the probability of human error.
• Better reliability—Automated procedures can aid in maintaining maximum production rates, minimizing recovery time and avoiding shutdowns.
• Reduced loss from operator errors—Automation helps standardize operating procedures, reducing the likelihood for human error, and also shortening the time required to recover from abnormal conditions.
• Increased production by improving startups and shutdowns—Operations can achieve faster, safer and more consistent startup and shutdown operations by automating procedural steps.
• Increased production and quality via efficient transitions—Most processes have to make transitions from one condition to another at various intervals during normal operation. Automating these procedures can make such transitions faster and with reduced variability.
• Reduced losses through improved disturbance recovery—Automated procedures can include responses for different types of typical disturbances, reducing the time necessary to bring the process back to a stable condition.Improved operator effectiveness—When operators don't have to perform complex or repetitive manual operations, they can focus more on process optimization.
• Capture and retention of "tribal" knowledge—Automating procedures is an excellent method for capturing the skills of a plant's best operators before they retire. When these operators are involved in formulation of procedure implementation models, their knowledge becomes part of the system and can remain after they've gone. This is especially important for infrequent procedures.
• Improved training—As operator knowledge and best practices are captured in automated procedures, the resulting documentation can be used as material for training new operators.
• Improved insight into the process—Undertaking the kind of in-depth analysis of the process necessary to create automated processes provides an opportunity to review and analyze data from every startup, shutdown, process transition and abnormal condition recovery.
• More efficient change control—A structured, modular approach to procedural automation minimizes costs associated with production changes.
• Reduced costs of broader enterprise adoption—Once procedure requirements and procedure implementation models are established, they can be modularized into libraries of procedures, control code and documentation to allow easy cloning from one area or site to another.
• Common definitions and terminology—When potentially complex operations are characterized using consistent and common terminology, communication with engineering firms, system integrators, automation suppliers and internal company departments becomes easier, clearer and less costly.

Conclusion

Manufacturers understand how successful management of infrequent operational procedures combined with flawless execution every time is critical to safe and efficient operation of continuous process manufacturing. The ISA-106 committee has released a technical report to help process industry firms document best practices and incorporate them into automated control systems. By applying the practices found in the technical report, a single process plant, a complete facility or even an entire company can achieve significant improvements in operational efficiency.

Reducing Startup Time and Variability

Evonik Inudstries is one of the world's major specialty chemical producers, with many plant sites in Europe and around the globe. One acrylic acid production site operates a unit with two reactors, four distillation columns, and a crystallizer. This unit runs as a continuous process, but shuts down frequently for cleaning and maintenance.

Restarting the unit can be time consuming, wasting feedstocks and leaving the plant vulnerable to safety incidents. Although some very skilled operators can get the plant back into operation and stabilized in less than three hours, their availability is not consistent. As a result, startups often take more than four hours.

Since implementing procedure automation, the unit is able to duplicate or beat the startup time of the best operators every time (Figure 4). Compared to an average of times realized by operators, the automated approach shortened distillation column startup time by 30 percent and reactor startup time by 70 percent.

Because startup procedures are now documented, they are consistent and repeatable, resulting in safer operations not dependent on the presence of a few key operators.

 

Figure 4. Each time Evonik restarted the unit, operators charted the time necessary to reach stable production, which ranged from 2.5 to almost 5 hours. Once the procedure was automated, quick and consistent startups became routine.