1 June 2007
Think of batch standard as design philosophy
By Frede Vinther
ISA-88.01 has been available for more than 10 years and has provided a good methodology and definition of how to model and breakdown a process into procedural and equipment entities. While ISA-88 Part 1 gives the foundation for batch, and while control systems suppliers' interpretations and implementation have guided the majority of the standard's functionality, it still doesn't cover some functionality and isn't included as general functionality in batch software packages. It's important for end users to be aware ISA-88 does not guarantee their process will be fully functional when batch-automated. The standard should be a way of thinking about a design philosophy. It's not a software implementation standard.
The standard defines the term batch as material produced by executing a batch process. The physical model defines the physical assets used for batch production. It is a hierarchical model that, starting at the higher level, consists of a process cell, units, equipment modules and control modules. The procedural model is also hierarchical and consists of procedure, unit procedure, operation, and phase.
Limitations in ISA-88.01
Although ISA-88.01 says in the introduction it doesn't intend to restrict development in the area of batch control, it still contains a number of constraints:
One batch cannot exceed the boundaries of a process cell.
One process cell may contain one or more batches simultaneously.
One unit can only operate on one batch at a time (always exclusive use).
A maximum of four procedural levels are allowed (or promoted by ISA-88.01) (procedure, unit procedure, operation, phase).
Only one operation can be active in a unit at any time.
Equipment modules may execute equipment phases, but they do not have the capability of executing higher level procedural elements.
Equipment entities are defined as: process cells, units, equipment modules, and control modules.
Modes and states may be defined for procedural and equipment entities (not required and no rules described).
Modes and states may be propagated upwards/downwards (not required and no rules described).
With a control recipe in manual or semi-automatic mode, procedural entities may be skipped, re-executed or even driven manually. The standard does not define any rules for the mode or state behavior of the entity that was previously running (i.e. if this entity should stop, complete, hold or abort).
Coordination between procedural entities and between equipment entities is described as they have to be compatible but not defined further (unit-to-unit or phase-to-phase coordination).
In one control recipe, the recipe procedure can only be linked to the equipment control at one specific level, such as recipe phase to equipment phase, recipe operation to equipment operation etc.
Batch software packages
We can divide batch software packages into two groups defined by their functional capabilities. The first group contains functionality for procedural and equipment control (these are normally defined as DCS or PCS systems). The second contains functionality for either procedural control or equipment control (these are normally defined as batch execution systems combined with PLC type systems).
The main difference between the two groups is, in Group 1, the interface and linking between the procedural control (control recipe entities) and the equipment control (equipment entities) is an integrated part of the overall software package. In Group 2, you must engineer the interface and linking between the two software packages, specifically for the two involved systems. You should especially engineer the equipment control to implement in the PLC almost totally as these normally don't contain libraries, including the equipment control functionalities.
But after proper engineering, design and commissioning, the batch functionality the end user sees should not differ much between the two groups of systems.
Regarding the system architecture of the batch software packages for both groups, systems and packages execute the procedural controls on a single PC node and the equipment control on dedicated field controllers. From an integration point of view the systems in Group 1 can normally only interface to systems of the same brand, whereas the systems in Group 2 can normally interface to a large count of different system brands. You can interface a dedicated PLC with a different procedural control system and vice versa. This latter case thus requires the linking between the batch engine, and you have to customize the PLC for the specific batch engine This is called the phase, logic, interface (PLI).
Software packages differences, similarities
Generally, the batch software packages provide similar ISA-88 functionalities, such as recipe management, including formula management procedural control, by using procedure function chart (PFC) technology only; equipment control by using equipment phases with sequential function chart (SFC) technology; and modes and states for procedural entities and for equipment phases. Linking between control recipe procedure and equipment control occurs on recipe phase to equipment phase level only. It defines recipe phase and equipment phase as one entity and one-to-one linking between recipe phase and equipment phase as one object. There is no or poor recipe management of combined automated process actions and human process actions. In providing some interface between control recipe and unit (equipment) for transfer of specific data values, there is no use of states or other coordination protocol, and it is normally intended to transfer unit capabilities or unit attributes used to enable the control recipe to arbitrate and acquire units. Unit supervision is limited to acquire, execute and collect data.
There are some batch software package functionalities not described or defined in ISA-88. Recipe unit procedure to equipment unit procedure interface comes in handy when you're using highly automated skid equipment in a fully automated batch plant. Allowing more than the four defined levels for procedural control in ISA-88 is an option. This feature is useful for increasing process understanding when doing highly modularized implementations. Allowing the equipment phase to continue during recipe phase step change or transfer of control helps prevent equipment from stopping during phase-to-phase transitions. Including propagation of states in the context and boundaries of a unit enables unit-wide state management and control. Being able to define specific exception procedures in the recipe helps recipe creators define product/procedure-related exception handling (this is not the same as low-level interlocks). It would be handy to have the capability of defining failure monitoring on the equipment phase driving the states as a placeholder for exception control related to the procedural execution. Defining synchronization points and links between procedural elements in the recipe is helpful for procedural synchronization in a multi-path plant when using equipment arbitration in the recipe. Having an infrastructure for equipment modules and linking of these to equipment phases helps ease implementation and modularizes software. The ability to define procedural elements for executing human process actions is helpful in almost any process. And finally, being able to execute the control recipe in the controllers or PLCs, helps when the recipe contains time-critical phase-to-phase transitions.
About the Author
Frede Vinther is a senior automation specialist at NNE Pharmaplan A/S, a consultant and engineering services provider to the pharmaceutical industry in Soeborg, Denmark.