For Bill Wray, PE, spreading the good news about procedure automation is about more than simply generating hundreds of hours of productivity at Bayer MaterialScience in Channelview, Texas. It’s also how the Bayer engineering consultant is giving back to his profession. For he found that the benefits of borrowing from batch control to improve continuous processes were just too great for him to keep the news to himself.
“I’d like to see more people adopt this method because it can offer real benefits in many places where people rarely think about batch programming,” he explains. So, he joined a small band of evangelists on the ISA-106 standards committee on Procedure Automation for Continuous Process Operations, formed in 2010 by the International Society of Automation (ISA, www.isa.org) in Research Triangle Park, N.C. Since joining, he has become one of the committee’s co-chairs.
The mission of this committee was to formalize a set of closely related methods that Bayer and other operators had developed over a few decades to accommodate change. Going by such names as procedural control and state-based control, these methods break continuous processes into operating states and automate the procedures for moving from one state to another. The committee hopes to develop cross-industry standards for this form of automation, replicating the success that ISA has enjoyed in the batch industry with the ISA-88 and ISA-95 standards.
>> ISA-95: Integrating Manufacturing’s Future: How top companies in discrete manufacturing industries are benefiting from ISA-95. http://bit.ly/AWfeat116
Even without the standards in place yet, procedure automation is already streamlining operational changes in continuous processes, such as the responses that a refinery might make to accommodate a shipload of a different grade of crude. Another example is the adjustments to a reactor to allow it to produce a different grade of polymer. “Anything in a plant that requires you to change the steady state and go from Point A to Point B can be done more effectively, more efficiently, and safer with well written code,” notes Wray.
About 13 years ago at Bayer’s Channelview facility, Wray and his colleagues developed a form of procedure automation to make two polyols, a triol based on glycerin and a diol based on propylene glycol. A breakthrough in catalyst technology had permitted them to convert a batch reactor to produce the two polyols in a continuous mode. Because the two products are in different families, they are incompatible enough that operations must de-inventory the system and restart to switch from one product to the other twice a month.
Engineers wrote procedural scripts for such transitional phases of the reactor as cold starts, restarts after a trip, shutdowns, de-inventory procedures, and rate changes. “We even have one that runs an optimizer [on the multi-constraint controller to optimize feed rates] on the reactor,” says Wray. “At the time, though, nobody was calling it procedural automation, but that’s what it turned out to be.”
A smooth transition
As is often the case for users who already have experience with automating batch procedures, developing and automating the procedures on the continuous reactor was a natural next step for Bayer’s engineering and operations team in Channelview. “With a dozen or so years of experience, we had developed some well-tested approaches to automating batches,” says Wray. “We had a good, strong talent pool of people who knew how to do automation in the style that we like to do it. It made doing the procedural control a piece of cake.”
Even so, the team found that finishing the programming took longer than it had in the past when the process was batch. Because the reactor had been running anywhere from one to four batches a day, depending upon the product that it was making, the batch process had given the team more opportunities to identify and debug programs. “With the continuous operation, we get about two startups and two shutdowns a month,” says Wray. “Because the continuous process does not exercise the code as much, it took a little longer to work out the bugs.”
>> Vendors Help with Automating Procedures: Read how automation vendors have been introducing a variety of tools for helping users to automate procedures in their control systems.
Despite the longer debugging period, startup was short because the team could draw upon its experience with automating the batch process and could deploy proven techniques. For example, the programmers wrote a script that permitted aborting a procedure if the operator encountered a problem. After being reloaded, the script would return to the place in the sequence where it left off.
“We also modularized the programs as much as we could to allow us to plug in changes easily,” says Wray. “When we would run into coding errors and other problems, we tried to fix them right away. If you write them down with the intent to fix them later, sure enough, you’ll forget about them.”
Since going continuous about 13 years ago, the reactor has never made off-spec product and has been more productive. Although it was the catalyst technology that had made converting from batch to continuous processing possible, the procedure automation has allowed Bayer to take full advantage of it. The automation, for example, expedites changeovers. “By automating the de-inventory procedure, we cut about 12 hours off our downtime,” reports Wray. “And 12 hours of production is quite a bit when you change over 24 times a year.”
Another benefit has been better coordination between the distributed control system (DCS) and the safety instrumented system (SIS). “The automation communicates with the SIS, telling it what recipe we’re making and confirming that all the values and trip settings are correct,” says Wray. “So, it enhances safety as well.”
Multiplying the benefits
The ISA-106 committee hopes to multiply these kinds of benefits in continuous applications by adapting the equipment and control modules defined in the ISA-88 batch standard. “What the 88 standard did for batch systems was to specify a structure for organizing the different parts of control code for flexibility and reusability,” says Dennis Brandl, president of BR&L Consulting Inc. in Cary, N.C. (www.brlconsulting.com) and one of Wray’s fellow evangelists on the ISA-106 committee. Before promulgation of the standard, batch control programs had a much less uniform structure.
A similar situation exists for control systems governing continuous processes. “There really is no well-defined structure for procedures in function blocks, ladder logic, or other programming method that you might be using,” notes Brandl. “So, the 106 committee is adapting the design patterns and structures in 88 for procedures used in continuous processes.” The adaptations will account for the differences between batch and continuous processing.
>> ISA-106 TR1 Terminology: Click here to read some of the definitions being proposed by the ISA-106 committee as groundwork for developing standards for Procedure Automation for Continuous Process Operations.
Both users and vendors on the committee expect similar benefits from control architectures built with these models and structures. Not only should the ability to reuse modules of code reduce the time to write, debug, validate, and install programs, but it should also cut development and installation costs correspondingly. “People using 88 saw about a 30 percent decrease in either the time or the cost to do their first projects,” reports Brandl. “On future implementations, they were getting 50-70 percent savings.”
Another advantage to the industry-standard structures is that programmers can develop their code in layers and therefore separate operating procedures from the control loops that run pumps and other basic equipment. By not having to worry about the details for running each device, the operator can focus on just the procedure for a particular layer. At startup, for example, the operator can concentrate on starting the reboiler, filling a column to the right level, and bringing the system to temperature, while the software takes care of the valves, pumps, and other devices behind the scene.
The layered structure also allows nesting so that programmers can automate procedures at the various levels within the production hierarchy, such as coordinating the various pieces of equipment within a particular unit. “For heating a reboiler to 180 degrees C, the lower-level procedures take care of opening whatever steam valves and setting whatever control loops are necessary to do that,” says Dale Reed, senior project engineer at Rockwell Automation Inc. (www.rockwellautomation.com) “Then, I can build a unit procedure for the distillation column on those lower level procedures. Likewise, I may have a plant start-up procedure that builds on top of that unit level.”
Take an incremental approach
Yet another advantage of the standard structure is that programming can be done in increments, allowing an engineering team to do the automation over time. “You may do some of it at one shutdown and some more at the next one, as opposed to just automating everything at once, which is often the case in batch operations,” says Reed. “You may automate only pieces, and use the software to prompt to the operator to do other pieces.”
For him, the keys to identifying which tasks to automate and which to keep in the capable hands of operators are risk and bang for the buck. “If you have an exothermic process that requires keeping a close eye on some variables, managing that risk might be a good place to spend your money on automation,” Reed says. Other candidates are repetitive, low-level tasks, such as daily filter flushes, that occupy an operator’s time.
“Start small and work your way up to progressively bigger things” is the advice offered by Dave Huffman, OGP business development for process automation at ABB Inc. (www.abb.us) For him, a good place to start is at the bottom, equipment-module level, which includes such devices as pump stations, heaters, coolers, and compressors. “This will give operators small improvements to work with,” he says. “It will also give them a vision of what the final product will look like as more individual items become grouped into larger control elements.”
As an advocate of the form of procedure automation known as state-based control, Huffman recommends that process engineers and senior operators also discuss in the initial stages how the process may be partitioned into states.
“Continuous processes really operate in a series of definable states, rather than truly being continuous,” Huffman notes. Perhaps the most fundamental of these states are startup, shutdown, and normal running.
Huffman adds that the term “shutdown” usually describes at least two distinct states. “The first is a full-maintenance, multi-week shutdown where everything really is shutdown,” he says. The other is better described as a process interruption or a state of waiting. In this case, some parts of the process may still be running, such as the systems for maintaining measurements, alarms, or other forms of monitoring.
Even “normal running” is rarely one process state. “For example, a power-generation boiler usually operates at three basic conditions: full, three-quarters, and half,” notes Huffman. “Also, look for different products, minor product additives, and changes in equipment, such as the switching of cracking furnaces in an ethylene process.” Because of variations like these, he recommends that process engineers and senior operators include throughput conditions in their discussions about state.
As you identify each state, says Huffman, “Create a functional specification that completely describes the state, including alarming and visualization requirements.” Once you define your states, you are in a position to begin looking at the interactions between units.
