Batch Process Automation – Risks and Planning
Published on : Wednesday 02-06-2021
Batch Automation is not a fix a patch, recover and run process. The key to implementation is planning, says Jagadish Naik.
Batch Process Automation might be a commonly used term, but many people still aren’t fully familiar. So, this article is designed to provide the background on batch process to suit beginners and initial programmers using a relatable real-life example.
The article explores the following areas:
a. Introduction: What is a Batch Process?
b. Implementing Batch Process Automation and understanding its challenges.
c. Ways to meet this challenge and implement Batch Automation successfully.
What is a Batch Process?
At a high level, one can divide processes (and controls) into main three types.
1. Continuous Processes: Example would be a three-element drum level control, lead lag combustion controls in power or utility boilers
2. Sequencing Processes/Operations: dehydrator, LPG treater sequence in LNG plants
3. Batch Processes: Grease (lubricants) preparation plant automations, edible oil plants, epoxy resins and other specialty chemicals.
Let’s start with an example we’re all familiar. Cooking is a batch process. When cooking, you have a recipe that specifies the components (grains, salt, sugar, oil, etc). The word ‘recipe’ is synonymous with all batch processes.
Cooking has a sequence of operations that is conducted in a specific order and often uses different equipment. For example, if you are preparing a favourite meat dish, you would first marinate the meat in one container, then transfer it to a frying pan where further processing take place like adding oil or spices and cooking it further. The entire process from addition of raw ingredients, cooking stages to serving the food on the table is called a Procedure in Batch Standard Terminology. In the section below, the highlighted words describe key aspects of the batch process.
Cooking may use various containers, e.g., when you marinate the meat in one container for a specific time, it is analogous to a Unit Procedure. Cooking the marinated meat in a different frying pan is a different Unit Procedure.
Unit Procedure can be broken down to sub elements. Heating the frying pan is a specific Unit Operation. To heat the pan, you need to adequately open the burner gas valve. Operating the burner gas valve is called a phase.
So, to execute the batch processing of cooking, the whole procedure consists of different Unit Procedures which in turn consists of an ordered set of Unit Operations, which in turn consists of an ordered set of Phases.
Whether it is cooking or an industrial process, to produce specialty chemicals, the same approach applies. (Refer to the ANSI diagram and Procedural Control Model.)
Any batch process can be described in three different ways: Process model, Physical model and a Procedural control model, which are mapped to each other in every step that executes in each of the models. Let’s map our cooking process into these three models.
Describing cooking via a Process Model
The Procedure (whole meat dish preparation) consists an ordered set of Unit procedures (marinating, cooking, dressing, etc.), which in turn consist of an ordered set of operations (heating, simmering, mixing, stirring, etc.), which in turn consist of an ordered set of Process actions (opening the burner valve, using a spoon to stir the contents, etc.), and so on.
Describing cooking via a Physical Model
Cooking is completed in various stages with multiple pieces of equipment. First, you put a few components in one vessel to do a stage one processing (i.e., marinating the meat), then shift the materials into another vessel (frying pan), add more components and cook further and then finally finish the product elsewhere such as served on a plate with additional dressing additions.
A complete set of all the infrastructure including storage equipment for storing raw materials stored in the kitchen along with vessels used for cooking, burner, stove and serving dishes is called a Process Cell.
Each piece of equipment (e.g., kettle, frying pan, etc.), are called Units. The gas valve will be a Control Module.
Describing cooking via a Procedural Model
Preparing a meat dish is a procedure consisting of several unit procedures including marinating, cooking, dressing and serving which in turn consist of various unit operations such as applying spices, and heating up for adequate quality cooking which in turn consist of phases like add spices or draining excess oil.
What is a Recipe and what is a Batch?
When we change the ingredients while we cook or use the same materials in a different composition and through a different procedure, the end product, i.e., the food dish can change completely. So instead of a stir-fried chicken, you may have a chicken curry. The recipe is defined by the raw material contents and the procedure or process to prepare the food into different forms.
You can have different batches for the same recipe. For example, you could prepare the meal (stir-fried chicken) for three people and then prepare it again for three more people because the capacity of the pan used for marination was only large enough to prepare a meal for just three people at a time.
In such cases, you would call each of these instances of preparations a separate batch.
Similarly, in real industrial scenarios, often there are limited manufacturing equipment in each plant. Therefore, to use the recipe (procedure) and to manufacture a large throughput, you must prepare the product in several sets (batches). The batches must be consistent in quality with each other to be able to be sold in the market as a quality output.
Industrial batch processes
Next, we’ll look at processes in an Industrial Batch Plant. In this scenario we’ll use an example where we’re making Grease as a product. Grease is a lubricant that in its production may require several pieces of equipment such as reactors, kettles, and homogenisers to manufacture. (Please refer to the sketch in Figure 3.)
To maximise production, usually several batches run in parallel. To achieve this, a plant needs multiple sets of equipment to process raw materials. As shown in Figure 3, you may have several reactors, several kettles and several homogenisers in the process path arranged in layers. A given batch may have to work through several units. The first step being in a reactor, followed by operations in a kettle, and then into homogenisers.
The availability of the equipment is key for the various operations. For example, you may complete reactor operations and are ready to transfer into a kettle. But as shown in the diagram there are three choices to transfer the batch in the reactor to. The Batch Automation scheduler must automatically detect which of the reactors is at a given moment.
The available status for a kettle is flagged once operations in that particular kettle are finished from the prior step or batch. The batch scheduler must keep track of these availability flags and provide a path for the batches to transfer. Ditto is the case with reactors for material transfers of raw materials and homogenisers for material transfers from kettles.
The complexity here is that if there are three reactors, three kettles and three homogenisers through a process path of a bath, there are 27 possible ways a batch path can be executed. Therefore, the batch scheduler needs to be able to automatically resolve the path conflicts and availability.
To facilitate this and manage the complexity in the process automation systems, batch standards were created.
A batch operation is defined in a hierarchy of ProcedureàUnit ProcedureàUnit OperationsàPhasesàDevices.
We learned these terms in our cooking example. To understand it in the revised context, here is how we describe it using the procedural model.
The entire set of operations starting in the reactors, followed by kettles and subsequently in the homogeniser so that a finished product is achieved is called a procedure.
A procedure is divided into Unit Procedures, e.g., the entire set of process operations which run in a reactor and complete a stage of a product are called a reactor unit procedure. Similarly, the complete set of operations in kettle are called kettle unit procedure.
The unit procedure is broken down in component modules called unit operations. Example operations may include heating, mixing, and cooling. When you code the software implementations, you must code these into independent standalone software modules that handle these operations. The unit operation program completes its tasks and then seamlessly moves to the next unit operation in line. This continues until all the unit operations are finished and the unit procedure is completed. The same order follows for unit procedures. Once all the unit procedures are complete, the procedure is complete, and the batch is complete.
Whether batch automations are complex or not depend on whether they execute in single path or multi-path operations. Here are examples of each.
Multi Path Batch travel – Figure 3 (please follow the Green or Red arrows)
Two batches are scheduled in Homogeniser 1. They will be scheduled one after another. Homogeniser 1 will be allocated to that batch (Batch 1 or 2) which travelled first to Homogeniser H1.
Figure 3: Legends: RE = Reactor, H1/H2/H3 =Homogenisers, KE = Kettle Bolded Green path = Batch 1 travel path, Bolded Red path = Batch 2 travel path
Implementation approaches and architectures
Of the three types of process control automations, i.e., Continuous, Sequencing and Batch, the specifications for the first two types of controls or Loops and sequencers are usually written by OEM manufacturers or process licensors. DCS or process control operators implement the control loops based on the P&ID diagrams or through a dialogue with the design engineers of the equipment manufacturers such as boilers or Residual Fluid Cat Cracking (RFCC) unit manufacturers.
In case of batch process implementation, a DCS implementation engineer must organise the full automation architecture working closely with the process engineer at a customer site or a consultant office. It can take several sessions to complete this process. There is a framework of ISA 88 standards available today which acts as a guidance. In 1994 when I implemented my first batch implementation, the standard was not available. The process controllers were several generations behind in their capabilities compared to what’s possible today both in processing capacities and the algorithms they support. The Windows environment and applications framework that today’s programmers use, did not exist. This means recipe definitions had to be implemented inside the supervisory process controllers themselves. These constraints meant that if you erred in the architecture even marginally, there was perhaps no safe return path.
Batch Automation is not a fix a patch, recover and run process.
The key to implementation is planning. Start from the top and work down – be sure to define and construct process control modules in a modular fashion so that they do not occupy and obstruct other automation block in operation. An ideal sequence is, occupy the module- operate the module and release the modules so that it is available for the next batch that is progressing behind the current running batch. The efficiency of the code writing in phases to meet the required process objective is achieved in each phase needs is done so that another batch operation is completed without any unnecessary waiting time.
This requires precise planning and execution. It also means accounting for potential cycle time failures that could seriously compromise the batch or create a worst scenario, such as batches that don’t execute or get stuck. Be cautious of considerable code revamping before you reorganise.
If you are not able to directionally develop the architecture as described in the ANSI standards, you may face issues. The Batch Standards ISA 88 are not optimisation standards; they are implementation guidelines/instructions. Using them – or not using them – is a difference between a success and a potential failure.
It is important to make a good choice on the types of process controllers you will use to implement batch control automation. Usually all the control modules executing unit procedures, procedures, operations, and phase will run inside the subsystems or process controllers. The recipe structures being implemented and managed at the supervisory, higher level applications.
To illustrate further, the recipe configurations and batch initiations, tracking the progress, uploading, and recording parameters would all happen at the supervisory levels. Alternative organisation is likely to lead to inefficient or impossible-to-execute automation.
PLCs were once considered the ideal devices to implement all the sequential operations. Many control engineers have confused sequential operations with batching operations and considered PLCs for batching operations. I really do not recommend this. Early PLCs did not provide the stepping structures required for batching operations and you needed to build the step structures via your own independent efforts before you coded the process logic. The volume of complexity makes it difficult, almost approaching the impossibility for multipath batches. It may work for single path batches.
Ideally you need systems with stepping structures that are available via standard, out-of-the-box modules and supported with interrupts structures. Many, if not most, industrial controllers now feature this, helping to simplify the effort of a process control engineer or programmer.
I programmed my first batch in 1994. Through a year’s struggle, I learned that the only way a batch could be organised well was through an organised structure, as outlined above. In 1995, the batch standards were published which exactly documented the process that I had discovered the previous year. It was a confirmation of my own earlier hypothesis on how batch automation needs to be implemented.
This discovery has remained one of the greatest professional satisfactions for me to this day.
Jagdish Naik works for Honeywell International and has worked in key leadership positions in Engineering, Services P&L, R&D, Product and Offering Management, Customer experience. His customer base is Global spanning from Far East to Latin America and he has worked hands-on in US, UK, Japan, South Korea and India. Jagdish has extensively worked both in Industrial Automation and Building Automations throughout his 30 years of International Career.