This post was authored by Bill Wray, an engineering consultant and first chairman of the ISA95 committee.

I have many years of experience in process control engineering, starting with continuous processes and later with automating batch processes. I find batch automation to be largely about sequential operations and states. To a lesser extent, sequential operations and changing states exist in many continuous processes as well.

Extending the lessons learned in automating batch processes to continuous processes seemed like a natural progression, and I recall discussing this concept with colleagues at technical conferences. In 1999, I got the opportunity to put this idea into practice. When a new technology was commercialized, we converted a batch reactor system at our plant to a continuous process. The operations staff had more than 10 years of experience operating highly automated batch processes. They realized the benefit of sequential automation for managing state changes and transitions, so they strongly supported implementing procedure automation for the new continuous process.

Once the decision was made to design for multiple products, as well as campaigning on the new process, procedure automation made sense. The original batch programming was also a strong basis for automating the new continuous process. The plant started up in late 2000 and used procedure automation for startup, shutdown, restart, and rate changes. We added an automated deinventory procedure and a rate optimizer later, as well as other functions and corresponding procedures. Adding a second product manufactured in the process ushered in additional changes.

That experience made me a firm believer in the value of procedure automation, and in the following paragraphs I will share my experiences as a long-time user. I hope to encourage you to implement procedure automation on your process to benefit as we did.

Why procedure automation?

Procedure automation is not new, nor is it some theoretical concept. It has existed for many years, mostly in batch and semibatch processes, but also in continuous processes by some forward-thinking users. It is all about automating specific tasks in a process that typically require a lot of manual intervention from operators, because many problems originate in manual intervention (figure 1).

Figure 1. A report by the Energy Practice of Marsh Ltd., a division of insurer Marsh McLennan, examines the five-year loss rate (adjusted for inflation) from 1972 to 2011 in the refinery industry. Incidents during startups and shutdowns continue to be a significant factor.

There are real benefits in its application to continuous processes, and even a casual examination shows all sorts of opportunities. Procedure automation is beneficial not only in chemical and petroleum processing, but in any process with sequential operations. Procedure automation has been applied to a wide range of processes from offshore platform operation to cracking furnaces to processing nuclear materials.

Procedures exist in all processes. Sometimes they are written down on paper, sometimes kept in digital form in a document control system, and sometimes they are in somebody’s head (tribal knowledge). Well-written procedures enable safe, consistent operations. In fact, in some industries, written procedures are a legal requirement. However, having procedures and following them are often different things. To maximize the benefit of any procedure, it must be faithfully followed day in and day out. Thus, the basis for the main benefit of procedure automation: it enforces adherence to the procedure.

Benefits of procedure automation

Automating procedures enforces consistent operation of the process, resulting in improved quality and higher throughput. Operators are able to operate with fewer errors and delays, creating maximum utilization. This translates into real dollars to the bottom line—something any manager can appreciate!

More importantly, procedure automation contributes to safe operations. As previously mentioned, it reduces the opportunity for operator error. In one study, the ASM Consortium found that approximately one-third of incidents were caused by procedures being used incorrectly or not at all. Further, procedures performed less frequently are less familiar to operators and more subject to failure, and these situations generally occur in abnormal operations where the risk of a safety incident (and likely the consequences) is larger. Procedure automation also provides a means for a controlled shutdown, which is less hazardous than an emergency “crash” shutdown.

• When procedures are performed manually, there is usually large variability in how they are performed.
• Tribal knowledge among experienced operators often makes up for inadequate documentation, but this is being lost to demographic changes.
• Procedure automation is a key mechanism for capturing and preserving operator knowledge.
• The process of collecting and compiling operator knowledge is an excellent opportunity to analyze and institute sound but undocumented procedures.
• Automated procedures, functioning correctly, can ensure more consistent and reliable plant performance with fewer upsets and safety incidents.   

Procedure automation improves safety through automated management of shutdown and alarm systems in the process. Procedure automation also helps coordination between the basic process control system (BPCS) and the safety instrumented system (SIS), ensuring functions specific to a given operating state are recognized by both. This is especially important during transients or processes where steady-state conditions change due to factors such as different product grades or feedstock. Using procedure automation combined with appropriate SIS programming can eliminate manual startup bypasses of interlocks.

Alarm management is as an important contributor to operator awareness and hence safe operation. Here as well, procedure automation can be used to help manage alarms (e.g., determining which alarms are active or inactive at appropriate times and avoiding “chaff” that confuses operators), especially during severely abnormal conditions, such as an emergency shutdown.

The benefit of improved safety is often difficult to quantify in dollars, but the cost of unsafe operation is painfully obvious. Losses from safety incidents in the U.S. alone are estimated at $10 billion annually. Single events can cost companies upwards of $2 billion, not to mention many lives lost.

Earlier we considered the issue of operator familiarity with procedures and the effects on operators’ abilities to properly execute those procedures. As we all know, our workforces are changing, as senior operators with 30 or more years operating experience are retiring and new blood is entering our control rooms. Senior operators that I have worked with generally do a good job mentoring the new hands, but the knowledge transfer is never complete. Procedure automation is a great tool for knowledge retention, and having well-documented procedures and automating those procedures greatly improves personnel transitions (figure 2).

Figure 2. Many procedures are not well documented, and different operators may practice them differently. Part of automating such procedures is determining the best practices and incorporating those approaches, so they will be followed consistently.

There are other benefits to procedure automation, which have been outlined by the ISA106 committee, and an extensive list can be found in Section 5 of ISA-TR106.00.01-2013.

Implementation step one: planning

As with any engineering project, time spent up front defining the scope will pay benefits later in the project. But there is another detail to cover first, as it is vitally important for all operational areas to be involved in this activity. You must have your operations staff buy in to make the project successful. After all, you will not be running the plant, but they will. Unless they perceive a benefit from procedure automation, it will not be used to the extent it should be. At a minimum, get an experienced operator assigned to the project team.

To succeed as you automate procedures, you must first identify the appropriate procedures for conversion to automation. If well-documented and verified procedures exist for the process, you have a solid foundation. If not, you must create the procedures, and this is no trivial task. It has the benefit of establishing a single correct way to run the plant, however, and often this alone is a huge step forward. Even if well-documented procedures exist, a detailed review to ensure they are actually the correct procedures is recommended.

A team knowledgeable in process operation should review existing procedures for completeness and correctness. The team should solicit ideas for improving the procedures as well. Focus on procedures for non-steady-state operations, as these will be most beneficial for automation. In fact, it may be wise to review existing procedures with a discussion of what areas to automate. The choice of what to automate depends on several factors, including operation frequency, complexity, and the consequences of incorrect execution. These factors will also likely affect the priority of execution.

You might be tempted to embark on a complete automation of the process, from startup to shutdown and all possibilities in between. Although this might be the ultimate goal, your chances of success will be better if you start smaller.

Choose a high-frequency operation of moderate complexity for your first automation. This combination will offer you the best opportunity to demonstrate the capabilities and benefits of procedure automation. You do not want to bite off too much at first, and it will likely take a few executions to work out the bugs.

On the other hand, you also do not want to solve a trivial problem, as the combination of frequency and complexity will give you ample opportunity for debugging and later demonstrating the usefulness of procedure automation. Another factor to consider is the opportunity to apply the first procedure to multiple operations or operating units.

Another major decision is the degree to automate a given procedure. There is a wide spectrum, from a system that merely instructs the operators at each step and perhaps confirms its completion to another that an operator initiates by pushing the start button and then lets the system execute unaided, reporting back when complete.

Available hardware in the process will affect this decision because some operations likely have components (block valves, pumps) that cannot be remotely activated. In these cases, the automation system will need to guide the operator on what and how to manipulate at the appropriate time.

This may be especially likely on your first project, as management may be initially unconvinced of the value of automation and therefore unwilling to invest in remotely operated block valves, or it may have prejudices against remotely starting pumps.

A related consideration is what degree of operator action will be allowed during execution of the automated procedure. Can an operator override the procedure without disabling it? Can he or she change set points or controller modes? In my experience, the answer to both these questions should be “no,” because procedure automation largely relies on conditions being followed as written. However, the operator must be able to take control away from the automation should something go wrong. In this case, be sure the operator gains access to all controllers, so he or she can do what needs to be done.

Implementation step two: design

I typically advocate for a system automated to the highest degree possible within the physical capabilities of the process. If necessary, you can initially trade off overall scope for degree of automation, i.e., fully automating some operations, which can later be incorporated into a larger overall automation system.

If you successfully automate small portions, demonstrating especially to the operations staff the usefulness of procedure automation, you will gain important allies in support of future automation projects. These smaller modules, if properly designed, can be combined into a larger overall procedure. Early victories, even if small, are strategic in the overall effort.

The existing hardware in your plant might also be a factor in your choice. Although automated block valves and pumps can more comprehensively automate your procedure, it may be difficult to justify adding these on your first project. Keep in mind that the lack of these does not preclude automation, it merely affects the scope.

Whatever degree of automation you choose, it is vitally important that the system informs and involves the operator. The potential problem of unaware operators is more likely with a fully automated system. Messages displayed on the operators’ consoles to convey status are useful. A prompt or guide message requiring operator acknowledgement or confirmation is also useful, especially at major transitions, such as the beginning and end of a procedure. Details of implementation depend on the capabilities of your automation system.

Operator awareness can also be improved through training. If the operator knows what to expect, it is easier to follow the automation procedures. If your automation is part of a system replacement or migration project, make sure to train in both the new system as well as your specific application. Timing of the training is also important. Ideally, an operator should be able to put new training into practice as soon as possible after its completion.

As with batch automation, modularity is a powerful tool. If you pull the overall procedure apart into smaller procedure modules, you can develop less complex programming than it would be for the larger operation. Eventually you can combine these into an overall implementation. In this manner, you can build to your ultimate goal of total automation of all operations. You will also find that debugging small modules is much easier than debugging monolithic programs.

Depending on your process, modules should be designed to be reusable. Typically, certain design features are repeated throughout the process, and the procedure for operation is also repeated. This can be as simple as starting or stopping a pump, or as complex as operating a cracker or still.

For example, in an olefins plant there are typically multiple cracking furnaces of the same design. Automation written for one furnace and its components can be reused on all furnaces if properly written (e.g., use of generic logic). This consideration also applies for different plants and sites across the enterprise.

Finally, you must consider exception management. What do you do when a valve does not go to its commanded position? What is the response to an unexpected process condition or an operator overriding the automation? How do you detect these exceptions? How do you recover from an exception? Exception management, especially recovery logic, is a major part of any automation project. Procedures can be written for exceptions, but these may be vague and difficult to automate because you simply cannot anticipate everything that may occur during such abnormal states.

You may opt to “soft fail” the automation and turn the process back to the operator—but only if it is made clear that the operator has control. In this case, you must also decide if reentrant logic for the procedure is desirable, and if so you must consider how the automation will resynchronize with the process.

If the exception is critical, a process shutdown may be required, either an SIS-actuated shutdown, or perhaps a more controlled shutdown. Again, you need to consider synchronization of the SIS and BPCS. The correct answer to these questions depends upon your process and automation capabilities.

Implementation step three: startup

Debugging your procedure automation programming is certainly necessary. While you can accomplish much of this offline, such as during a factory acceptance test, debugging in the field during startup will be required as well. Using a high-integrity process simulation during testing can minimize debugging in the field, but it will not eliminate it entirely. In many cases your process will not care what the simulation says and will have its own ideas. Modular and reusable automation components can reduce debugging time and should be used whenever possible.

Because operating state changes occur less frequently in a continuous process than in a batch process, there may be fewer opportunities to execute and debug some of the automation. This factor can cause the complete commissioning of the automation to take longer than some might expect. Be sure to communicate this clearly to management so nobody expects miracles on the first day.

Debugging activities also include coordinating and synchronizing interactions among various automation system components, such as your BPCS and SIS. This is where timing issues can raise their ugly heads, and you should be prepared to solve them.

Lastly, plan for additional operator training during startup, as no training is more effective than that done on the live system. This is also a good time to remind the operators of points they covered in formal training completed earlier.

Resources

Most major control system vendors are participating in the ISA106 standards committee to varying degrees, as are some system integrators familiar with the concepts of procedure automation. Participants identified as voting members are the most active and aware of the techniques. Some also have experience applying the technology.

Of course, the ultimate resource is the ISA106 committee output. The first technical report, ISA-TR106.00.01-2013, is available from ISA. It covers models and terminology and introduces procedure automation concepts. The committee is currently drafting a second technical report on work processes.

Committee membership is open to all interested parties, so you can participate in the standard development. This has two major benefits: first, you can participate in discussions with many acknowledged experts in the field, even if only as a listener; and second, you will have the opportunity to review and comment on the committee’s work before publication.

To join the committee as an information member, click this link and request membership, or email crobinson@isa.org. ISA membership is not required to participate on an ISA standards committee.

The value of procedure automation is well proven. Properly designed and programmed, it will improve the repeatability, utilization, and safety of your process. My many years of experience operating a continuous process controlled by procedure automation validates this. I am a believer, because I have seen firsthand what procedure automation can do, and I believe you will experience similar benefits with your processes.

By Dave Emerson

A significant group of process control system suppliers has been deeply involved in creating ISA-106 technical reports and the standard for many reasons. One of the major discussion points of the “great shift change,” as older engineers are being replaced by younger workers, is the idea of capturing the knowledge of those experienced engineers and operators before they leave a facility. This has been widely discussed, but preserving the tribal knowledge of automation system and process operations is truly a challenge.

Procedure automation standards facilitate this process. They provide a platform for building tribal knowledge into automated procedures. This is especially important for dealing with procedures such as those involved with plant startup, shutdown, product grade change, and similar operations, since many studies have shown that plants are particularly vulnerable to safety incidents caused by inexperienced operators performing unfamiliar manual functions during those times.

The ISA-106 standard will provide a framework to build correct procedures in the automation system based on accumulated operator knowledge. Careful automation can make such procedures much simpler, more consistent, and safer—avoiding problems resulting from inexperienced operators making poor choices.

There is still much to do in writing all the parts of the ISA-106 series, so we welcome your participation. The committee co-chairs are Yahya Nazer, Ph.D., and Bill Wray, and my colleague and ISA Fellow Maurice Wilkins, Ph.D., is managing director. Wilkins is vice president over Yokogawa’s Global Strategic Technology Marketing Center. Come join this critical work and let your voice be heard in the process.

Dave Emerson served as the ISA106 committee editor and is vice president of Yokogawa's U.S. Development Center.

About the Author
Bill Wray, PE, began his career as a process engineer, later discovering his passion for process control, a field he entered in the early 1980s. Beginning with automation of large continuous petrochemical processes, he later moved to batch automation and is recognized among his peers for his expertise. Wray was a founding member of World Batch Forum (WBF) and served in various leadership roles. Since the merger of WBF and MESA, he has joined the international board of MESA. He was the first chairman of the ISA95 committee, leading this effort to publication of the ISA95 Part 1 standard, and is currently co-chair of ISA106. Wray is employed by Bayer Material Science as a senior engineering consultant and holds a B.S. in chemical engineering from Virginia Polytechnic Institute.

Connect with Bill

A version of this article also was published at InTech magazine.