Thank You Sponsors!

















Managing Infrequent Operational Procedures Is Critical to Safe Process Manufacturing

The post Managing Infrequent Operational Procedures Is Critical to Safe Process Manufacturing first appeared on the ISA Interchange blog site.

This excerpt from InTech magazine is authored by Maurice Wilkins and Marcus Tennant, of Yokogawa Corporation.

For all the sophisticated automation in process manufacturing environments, there is one area where operators still take manual control in many facilities: procedures for infrequent operations. When it is 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.


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

This 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 person or small group to execute 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 happens 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 gets out of control, leading to an abnormal condition with undesirable outcomes of equipment damage, environmental release, injuries, or fatalities.

Challenges of automating procedures

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

  • Some companies simply do not 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? Although the answer might seem simple, 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 will not 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 reliability of an automated procedure, they tend to put everything in manual and do it themselves. It is not hard to find examples of operators taking matters into their own hands, and it is 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 ISA106 committee in 2010. Much has been drawn from the ISA-88 standards based on parallels between procedures in continuous processes and batch processes. Other elements from the ISA-84, ISA-95, and ISA-101 standards have also been incorporated in the effort.

Such groups as NAMUR, the Center for Operator Performance, and the Abnormal Situation Management Consortium have provided resources and input. A variety of vendors and end-user companies, including Dow, Bayer, and Chevron, have also pitched in. 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 definitions 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. The models 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 number, so the lowest level invariably has the largest number of individual elements.

Each implementation module includes a set of ordered tasks, and those tasks may have their own subtasks. 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: Do the actions themselves.
  • Verify: Check if each action was performed successfully, or if there was 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 the models are not thought through carefully, the procedure will not deliver the desired results, and the effort will likely fail.

Click here to read the complete article on continuous process manufacturing and ISA-106 at InTech magazine.

About the Authors
Maurice WilkinsMaurice Wilkins is ISA101 co-chair, an ISA Fellow, and vice president of the Yokogawa Global Strategic Marketing Center in Carrollton, Tex.
Connect with Maurice:



Marcus-TennantMarcus Tennant has been with Yokogawa Corporation since December 2008 as a senior principal technology specialist. Before Yokogawa, Tennant worked at Rockwell Automation for 10 years as a product manager and application engineer. Before that, he was with Morton International for 10 years, holding various positions in process development, project engineering, and quality assurance and with Jones-Blair Company for five years as a research and development chemist and process engineer. Tennant has a B.S. in chemical engineering from Michigan State University and an M.S. in operations and technology management from the Stuart School of Business at Illinois Institute of Technology. He has been a member of AIChE since 1984 and is also a member of ACS and ISA.
Connect with Marcus :


Source: ISA News