Greg: Batch operations are often used for high value-added products. Research labs for new products are batch operations. The most direct and fastest way to market and straight forward implementation for plant production is a batch operation. Processes tend to move to continuous operation after products have matured and production rate becomes more important than yield. Continuous processes have a discharge flow in the unit operation, which translates into some of the feed components not being fully processed before exiting the unit operation. Recovered feed components are recycled to increase yield increasing complexity in terms of need for purification and to avoid instability. For bioreactors, continuous processes called perfusion processes are rare because of concern of loss of live cells in discharge and recycle of contaminants and deadly organisms.
Zero discharge flow until the batch is complete causes an integrating response in temperature and composition. In some cases, the response is unidirectional (e.g., increasing product concentration for a non-reversable reaction). The computation of a batch profile with a simple dead time block with a dead time to provide a high signal to noise ratio offers a controlled variable that is a slope to provide a bidirectional response and a pseudo steady state. A future value block that that takes the difference between the dead time block output and input multiplied by process dead time and added to the block output can provide a future value one dead time into the future for predicting batch end points.
Batch control sequences are used to automatically meet the many other challenges of batch operations especially in terms of meeting unexpected changes in feed and equipment conditions without causing an interruption or loss in efficiency. The last thing you want is for the operator to have to make decisions on how to recover and resume an operation. We are fortunate to have Michael Taube of S&D Consulting discuss what to do and what not to do to achieve robust batch control applications to elevate the operator role into one of observation and offering future improvements.
How do you get started on the best path?
Michael: The first step is to understand the “why” for process control, particularly for batch processes. The definition I use is that a batch sequence program monitors and controls a non-continuous (an event or state-based) process to produce predictable product(s) with robust performance. While that sounds simple enough, the “devil is in the details and so is salvation,” as said by Admiral Hyman George Rickover, the “father” of the Nuclear Navy. By that I mean that, to be “robust,, a sequence program must:
- Be tolerant of perturbations or Abnormal Conditions (ACs)
- Generate predictable and repeatable behavior even (especially) when encountering errors and/or ACs
- Require no manual intervention (with “engineering access”) to reset or restart the program after encountering an error
Greg: Why do you describe “robust” like that?
Michael: In many control systems, when a sequence program encounters an “error” (i.e., a system tag is in the wrong mode or state), the sequence program simply stops or halts and then requires manual (human) intervention to rest or restart it. So, to be “robust,” a program must be designed such that it checks for and compensates for potential “error conditions.”
Greg: Is there anything else that should be considered to make sequence program robust?
Michael: “Initialization” is a concept widely recognized in continuous control, but sometimes overlooked with sequence programs. That is, a robust sequence program is designed to recognize the current state of the process and then jump to the portion of the sequence program that monitors and controls that specific state. This is how a sequence program initializes, but this behavior is often overlooked by sequence designers. As a result, they often assume that the sequence program will always run the process, therefore there’s no need to assess the current process state. This assumption is what often leads to trouble when a program unexpectedly halts: getting it back in synch with the process is wholly dependent upon how the program is structured.
Greg: Is this different from continuous control?
Michael: Yes. When continuous control functions encounter an error during execution, they get processed again from the beginning during the next execution cycle. In other words, they get another chance to execute to completion, whereas sequence programs don’t: they just halt. That’s why having an externally generated source of the process state is so important.
Greg: How does this translate to the design and implementation of batch sequences?
Michael: There are several interlocking and mutually required factors the process engineer (or sequence designer) has to consider when designing the program, some of which follow object-oriented programming (OOP) principles.
- The program scope should include only a single piece (or limited set) of equipment or unit operation. This is part of the OOP design principle of encapsulation. This often means that there could be multiple programs covering an entire “process.”
- A second OOP principle related to encapsulation is that there should be control system tags, external to the program, which indicates and/or commands the equipment’s state (e.g., standby, off, run, regen, heat, cool, etc.) This means that the program does not have to adjust multiple instruments (valves, motors, controllers, etc.) to achieve a particular process state: the external tags “command” the specific state and the external logic handles the details.
- The sequence designer should avoid iterative loops and parallel branches in the sequence program. That is, the program should have a simple “once-through” execution path. The reason for this design approach is that most current control systems utilize a function block (FB) programming “language” for sequence programs. While this is touted to make the program easier to understand by most casual observers, it also hides the fact that, during execution, one cannot predict, a priori, which part of the program is being executed. Also, while parallel branches of FBs appear to be executed in parallel, the reality is that they are processed serially–one after the other and not necessarily in the expected order. This may result in unexpected behavior during runtime. Thus, if there is indeed a requirement for some parallel processing, then the parallel logic should be “broken out” into separate sequence programs or system tags that are processed or executed at the appropriate time in the overall sequence. This also requires that any “hand shaking” or coordination between programs be very robust and predictable, but doing so is easier when the designer has explicit control over the parallel programs.
- Complex and/or iterative calculations should be configured in external control system tags or blocks. The reason for this was explained above when describing robust behavior.
- The program should behave like a very attentive and conscientious operator. That is, it should do only those actions that a human operator would take, such as advancing the sequence (e.g., move on to the next step or equipment state). It should also do nothing more than a human operator would do. So, if a human operator is to “press a button” on the control system to perform some action (e.g., advance to the next sequence step), then the sequence program will do the exact same thing.
- A consequence of 4 and 5 is that the program and external control functions should be designed such that the human operator is able to operate the process (using the same control function tags as the sequence program) without using the sequence program. In other words, if the sequence program is required to operate the process, then the program and control functions have not been properly designed.
- A consequence of 6 is that the sequence program can be started (and stopped) even while the process is already running without altering the process’ state. This is where “initialization” (described previously) and the caveat from 6 comes into play.
Greg: Is there anything else the designer needs to consider?
Michael: The “easy part” of sequence design is defining the sequence steps when everything works properly. The real challenge is identifying and then defining the proper response(s) to abnormal conditions (AC). The sequence program must know when equipment doesn’t function as required (i.e., a valve fails to move to the commanded position, a motor fails to start or stop, etc.) and then respond appropriately. In many, perhaps most, situations the human operator must perform some action which corrects the AC and then return control back to the sequence program. In the most severe cases, the operator must take full control of the process or equipment, even to the point of shutting it down so that repairs may be performed. Thus, the abnormal condition handler (ACH) the sequence code that traps and responds to AC–is the most vital part of the program that produces robust and reliable operation of the process.
Greg: that’s a very extensive list of requirements. How is the sequence logic documented?
Michael: I’ve seen various form of sequence documentation, including running verbiage, cause-and-effect matrices, and logic diagrams. All these forms of documentation have their place, but as to quickly conveying the sequence requirements to the control system programmer (who is frequently a different person than the program designer and has little, if any, understanding of the process), all these forms require a great deal of time to digest. Therefore, the most efficient and visually understandable form of documentation is a sequence step table.
The sequence step table lists all of the equipment, instrumentation and controls relevant to the sequence behavior. It also includes the conditions (e.g., process measurements, timers, sequence state, etc.) which dictate when the equipment goes into the indicated state (i.e., open, closed, auto, manual, running, stopped, etc.). Thus, each row of the table clearly indicates the state of the equipment and controls and the requirements to go into that state. If there are multiple steps which comprise different phases of operations (e.g., filling, heating, cooling, draining, etc.), then these rows can be color-coded to visually designate the steps of that operational phase.
Greg: How are the ACH documented?
Michael: Exactly the same way. The only caveat is that, as there may be multiple steps involved with the AC it addresses, it’s often best to have them documented in a separate table. Also, certain ACH may be required only during certain phases or steps, whereas others may apply for the entire sequence. Therefore, there should be a column (or multiple columns) in the main sequence table for the ACHs to indicate whether it is enabled (active) during that step or phase.
One thing to keep in mind with ACH is that many control system’s sequence language may allow only one ACH to be active at any given time during the sequence execution. Thus, it may be necessary to implement All of the ACH logic in a single ACH and then have additional logic within it to check which step, state or other qualifying conditions exist. In this case, it becomes vitally important that the programmer clearly document in the code or FB which AC that portion of the program is addressing. A FB sequence also demands that the step and transition blocks be laid out visually such that the logical flow (and AC being addressed) are easily comprehended, especially by the person who will be responsible for the on-going “care and feeding” of the program who, again, will likely be different than the original programmer.
Greg: Are the any other implementation hints you suggest?
Michael: Earlier I mentioned that a timer is sometimes used as a trigger or condition to transition to the next phase or step. In some control systems, when a timer (i.e., a timer function block) reaches its target value, it just stops. However, in some instances, it is very helpful to have the timer continue to count up/down. This functionality is very useful for tracking progress of certain phases or steps that depend upon other conditions, such as equipment availability, before proceeding to the next step and, if the equipment isn’t available or other conditions are not satisfied, then it gives the human operator (and the sequence) an indication of how long “overdue” the transition is. If a timer FB doesn’t meet such needs, then I’ve used an accumulator (totalizer) FB to implement this functionality. Even after reaching the target time value, it continues to accumulate until stopped by external logic.
Greg: What kinds of mistakes or misapplications have you seen with sequences?
Michael: One of the most common issues I’ve seen is control system programmers “rolling their own” functions or algorithms. Modern control systems have been designed to include a large and varied function block library. The available native functionality is far greater than previous generations of control systems, often far greater than many designers and programmers realize! Thus, the onus is on both designers and programmers to learn and, most important, use the built-in function blocks to their maximum potential. This ensures the best and, presumably, the most robust sequence implementations. Whereas the “rolling your own” approach are far more difficult to understand and especially to maintain, particularly in the context of a control system upgrade, even if it’s just the next release of the system vendor’s software.
Another issue I’ve seen is designers treating the sequence program as if it’s a safety system, thus requiring the application to be implemented on a SIS-rated platform. While it’s true that the sequence has ACH, the AC to which they are responding are (usually) not safe-limit excursions: they are merely unexpected conditions which fall outside the normal equipment behavior, thus requiring some alternative, but “normal” alternative action on the part of the sequence program and/or human operator.
Lastly, there’s the question of the type of platform on which to implement sequence programs. Many smaller facilities or companies take the route of SCADA/PLC systems. For very basic regulatory control of small packaged systems, PLCs are notionally acceptable as long as the application isn’t expected to be changed or enhanced. However, a PLC’s real strength is based on two facets: very high-speed IO processing and very high-speed logic solving.
Due to these features, PLCs are best suited for high-speed machine protection and control (e.g., compressor or turbine safety shutdown and surge protection, high-speed bottling/canning machines, etc.). Furthermore, as indicated above, if/when any part of a typical PLC application must be revised or updated, it requires that the entire configuration be uploaded into the CPU. Whereas, with a typical “full featured DCS,” only the affected tag’s configuration is loaded into the runtime environment. This minimizes the potential risk exposure when sequence program and control function updates and enhancements are implemented while the remainder of the plant or affected unit operations are running.
While many traditional PLC Vendors have attempted to break-into the DCS market, their offerings amount to a SCADA system, which lacks most, if not all, of the integration, security and maintenance features found in current Distributed control Systems (DCSs). Furthermore, the PLC/SCADA Vendors lack the full scope of functionality found in “full featured DCSs”. Lastly, in terms of true process control research and development, the PLC Vendors just don’t have the breadth or depth of expertise that exists (or existed) with the traditional DCS Vendors, especially regarding continuous control functions (i.e., PI, override/constraint, analog switches, etc.)
Greg: Any parting words of wisdom?
Michael: Modern control systems are very capable and have lots of underutilized function blocks. Robust sequence controls require that the sequence designer and programmer learn and use them.
