Standard Automation Methodology Improves Operations and Prevents Incidents by Enabling the Sharing of Best Practices Among Operators

Fractionation Research Inc. (FRI) has been studying distillation and distillation equipment for almost 60 years on behalf of its 70 members, each of whom pay an annual subscription fee for services. FRI possesses two industrial-size distillation columns (Figure 1) which are located on the Oklahoma State University campus in Stillwater, Okla.

Typically one of the following three binary separation tests is run within those two columns:

p- and o-xylenes from 75 mm Hga to atmospheric pressure

cyclohexane and n-heptane near atmospheric pressure

isobutane and n-butane from 100 psia to 500 psia.

Figure 1: These columns are used by FRI to test
and study distillation on behalf of
member companies.

During test runs, the trays and packings within the columns are subjected to a very wide range of liquid/vapor and mass transfer regimes. All of the runs are logged at steady-state conditions, but steady state is maintained only long enough to collect the relevant data. The process conditions are then modified for the next test. Tests conducted include start-up, transitions within and between various modes of operations, flooding, un-flooding, setpoint changes and shutdowns.

Unsteady state procedures at the FRI distillation units are now implemented semi-automatically using a solution called modular procedural automation (MPA). MPA was first pioneered by Yokogawa, and it was initially based on ISA88 principles. It's now being deployed using the guidelines under consideration in the ISA-106 working group. MPA is a methodology that can be implemented with virtually any modern automation system, and it is effective across a wide range of processes and industries.

As implemented by FRI using Yokogawa hardware and software, MPA provides specific on-screen instructions and information for our control room operators and technicians in areas listed in Table 1.

Table 1: MPA On-Screen Operator Instructions and Information

1. Step-by-step listing of the procedure

Prompting regarding next steps

Warnings regarding next steps, if applicable

Actual opening and closing of valves, changes in controller setpoints and other important events

History of completed steps

Status monitoring of process changes

By having our operators follow these instructions and use the supplied information, MPA has produced safer operations at our test facility. Based on our experience, we believe that an MPA or similar solution might have prevented some of the largest chemical plant accidents of the last decade, as we'll detail later in this article.

Implementing MPA

During 2011, the FRI control room was augmented with a data historian and MPA supervisory software supplied by Yokogawa. These tools were loaded onto the existing Yokogawa DCS, which has been in place for several years. Figure 2 depicts our control system architecture.

The historian, which collects data every second and stores it in a database, has allowed FRI to analyze unsteady data and data from operating modes other than total reflux. FRI engineers, with assistance from Yokogawa, have used the MPA software to build and execute electronic, semi-automated procedures for star-ups, transitions and shutdowns.

Semi-automated procedures based on operational experience were initially implemented using MPA, but none of the procedure algorithms were completely satisfactory when first tested in the control room. Some of the algorithms required additional process checks, some a faster or slower rate of execution, and some others needed increased flexibility.

Figure 2: This is a typical control system architecture for a
Yokogawa-based automation system that can control
and monitor the operation of distillation columns.

To improve these procedures, the MPA software was run in parallel with actual operations, but in an offline mode. The procedures were then adjusted to closely mimic operators' actions. This step allowed the system to pass validation tests, and at the same time, increased operator understanding and trust.

FRI's best board operators were in the control room during these trial runs, and their experience was used to modify and improve the initial MPA instructions. Our aim was to use MPA to capture the knowledge of our best operators, so that this knowledge could then be used by other operators to reproduce our best practices time after time.

Specifically, our best operating procedures were captured and disseminated to other operators via various software screens. Figure 3, for example, is a screen that the FRI board operators now see during start-ups. The left pane of the screen shows the macro start-up steps. The lower right portion shows the current micro step. The upper-right pane shows the steps that were already completed. The software allows the operator/engineer to override certain steps in the procedure if such a need should arise.

FRI's board operators are well-trained, but we find that different operators can start, change and shutdown operations in various ways. All of our operators are encouraged to fully understand the units and their operation and to think on their own. But with MPA, there is now a uniformity of starts, changes and stops. This yields improved operations, while still allowing operators to act independently if unforeseen conditions should arise.

MPA Goals at FRI

As implemented at FRI, manpower reduction is not one of the goals of the MPA methodology. In too many global control rooms, manpower reductions have already occurred, and many senior technicians have retired over the last ten years. We believe that experienced operators are a valuable asset, and thus we use MPA to assist, not eliminate, our operators. This assistance is provided by using MPA to share best practices among our operators, allowing the present generation of technicians to learn from our best operators even after they have retired.

We find that our operators appreciate the assistance provided by our MPA software. It helps them to corroborate their judgments and decisions regarding next steps. Our operators say that using MPA is "like having our best operator alongside them in the control room all of the time."

We feel that the MPA methodology might prevent future accidents at FRI and elsewhere. To verify this contention, we examined how MPA might have been used to prevent past accidents.

Could MPA Have Averted These Accidents?

The U.S. Chemical Safety Board was formed in 1998 to study major accidents, write reports and produce instructional videos. For several years, FRI has used those videos as focal points for our safety meetings.

At these meetings, one or two CSB videos are typically shown, and the attending engineers and technicians then determine relevance to the FRI operations. After discussion, a list of FRI-related action items is created, with documentation and follow-up to assure that lessons learned are correctly applied.

There were three CSB videos where we concluded that the MPA methodology might have prevented accidents: T2 Laboratories, BP Texas City and Sterigenics.

T2 Laboratories

T2 Laboratories was located in Jacksonville, Fla. T2 produced MCMT, a gasoline additive. The primary production step was an exothermic reaction in a 2500-gal. reactor that included a water jacket. In 2007, the water supply failed, and a runaway reaction resulted. At some point, the pressure build-up caused the relief valve to blow, but the relief system was too undersized and the reactor exploded.

Details regarding the accident can be found in a CSB video (Reference 1) or the associated report (Reference 2). The video describes a lone board operator who did not know what to do when the water jacket water supply failed. He called off-site engineers for help, and they rushed to the plant, but reached it too late.

If the T2 control room had used an MPA solution, the following would have been possible:

Prompts could have been provided to the board operator regarding the back-up water supply.

Corrective action steps for this type of a condition could have been programmed as screen prompts or as automated flow rate and valve changes.

The software could have set off evacuation alarms.

The knowledge of the plant's most-experienced people could have been provided to the board operator via MPA, particularly as temperature excursions had occurred with the reactor before. The previous excursions could have been studied using an historian, and the lessons learned could have been implemented within MPA and made available to the operator.

BP Texas City Isomerization Unit

Details regarding this accident can be found in a CSB video (Reference 3) or the associated report (Reference 4). This accident was similar to the T2 Laboratories incident in that a very large burden seemed to fall upon a single operator. Regarding BP Texas City, the report stated, "Restructuring following the merger resulted in a significant loss of people, expertise and experience." In retrospect, some of that experience could have been captured using MPA and then made available to the operator.

The BP accident occurred in 2005 in an isomerization unit. When the lone operator came on shift, he had just a single line of input in the log book from the previous operator: "Starting up the Isom Unit." Unfortunately, the supervisor of the newly arrived operator had been called out of the control room for an extended period to attend to a family emergency.

The newly arrived operator needed to continue to start the isomerization unit and control two other units, all with virtually no input and assistance. Due to a malfunctioning liquid level alarm, he had no idea whether he was starting with six feet or 175 feet of liquid in the bottom of the raffinate splitter tower. The truth proved to be closer to the latter, and the tower overflowed into the blow-down drum, and the hot gasoline then overflowed and ignited.

If the BP control room had used MPA, the following would have been possible:

The newly arrived operator would have had on-screen information regarding all of the steps that the previous shifts had taken, including the exact times of those steps.

A safety warning could have been provided on-screen regarding the over-flowing of the raffinate splitter tower (which had already happened a few times in the past).

Out-of-date procedures would have been necessarily updated for the sake of the programming of the new software.

The MPA software could have shut the unit down in time to avoid the explosion. If MPA had been correctly implemented, the lone operator of the three units would not have been alone.

Sterigenics Oxidizer Accident

This accident was described in a CSB video (Reference 5) and in the associated report (Reference 6). This accident did not occur because an operator was alone, but because a standardized procedure was not obeyed, and because the operators did not understand the ramifications of diverting from that procedure.

The Sterigenics plant was located in Ontario, Calif. Medical equipment was sterilized in large chambers using ethylene oxide gas. Subsequent to the sterilization, according to procedure, the ethylene oxide gas was purged from the chambers using a three-step process. On the day of the accident, one of those steps was purposely skipped. As a result, a concentrated ethylene oxide gas stream was sent to the oxidizer, and the chamber exploded.

If the Sterigenics control room had used MPA, the software could have provided a message to the operators along these lines, "If Step 2 is skipped, a concentrated ethylene oxide gas stream will flow to the oxidizer and an explosion might result." Upon seeing this message, the operators may very well have taken corrective action.

With MPA, Operators Are Never Alone

Regardless of the reasons, the control rooms of the western world do not seem to be as well-manned as those of 20 or 40 years ago. To address this situation, MPA can be used to transfer the knowledge and experience of the best remaining operators, engineers and technicians to new operators. This makes new operators more effective and efficient. When MPA is correctly implemented, no operator needs to start, run or stop an operating unit alone.