Buying Decisions for ISA-88 Batching Solutions

October 15, 2015
Featured image for “Buying Decisions for ISA-88 Batching Solutions”

Buying Decisions for ISA-88 Batching Solutions



PAC:  Programmable Automation Controller
Phase:  The lowest level of procedural element in the procedural control model.  It provides an interface to basic control.
Physical Model:  A representation within the ISA-88 product of the physical assets that comprise the batching system.
Procedural Model:  A representation within the ISA-88 product that describes a set of activities to be
performed by the Physical model to produce a product or type of product.
Unit:  A collection of associated control modules and/or equipment modules that can carry out one or more major processing activities.


This paper intends to address the decision making around formal ISA-88 batching products such as Rockwell Automation’s FactoryTalk® Batch. Going forward we will simply use “products” as the expression for formal products that embrace the full ISA-88 standard. There are elements of the ISA-88 standard that have migrated into well- structured applications that don’t use a formal product. Such structure can prove to be helpful and has even gained acceptance outside of the batching industry. This paper, however, intends to help guide the thought process through the evaluation of whether or not you actually need and would benefit from such formal products– and in many cases you would indeed benefit, but not in all.


ISA-88 batch process management allows you to reuse programming code, recipes, phases and units for processes with similar procedures which allows for an abbreviated effort when expanding a system or in systems where there are multiple instances of like equipment such as mixers, reactors, scales, storage tanks, etc. Refer to “WORK REUSE & SCALABILITY” later in this document.
There is also a feature in an ISA-88 product called “Dynamic Unit Allocation” which allows the batching system to automatically optimize the utilization of the assets included in the physical model based on the rule set you give it. This can result in very large increases in system throughput. Refer to “DYNAMIC UNIT ALLOCATION” later in this document.

Extensive batch logging is included in an ISA-88 product. It not only records both the target and actual weights, but also logs each event associated with the subject batch. In short, if you have any of the following you should strongly consider an ISA-88 product:

  • multiple products that require different sequences to produce
  • a system that can utilize multiple paths to make the same product (networked)
  • expansion plans in the future
  • a need for highly structured batch recording


There are some very significant points to be made here. As each ISA-88 recipe (procedure) is created, it can by its very nature mix and match the order of equipment that it needs to complete a batch. Those recipes are built through the graphical interface which does not require any special programming to change the sequence of events. Each ISA-88 recipe can be loaded with different parameters that allow different products to be produced with a common Procedure Model (recipe). Another point that adds value to the overall line eficiencies is a feature called “Dynamic Unit Allocation”. An example would be a recipe that can utilize various items of equipment that are in parallel. Let’s assume you have a couple of scales in parallel and a couple of mixers in parallel. The recipe will look for any piece of equipment that ts the description of the “unit class” that it needs to complete that step. As soon as it nds one that is available, it will allocate that specic unit and proceed with the batching. All of these allocation algorithms are native to the formal ISA-88 product. All the user has to do is identify the unit class that is required for the step that is being developed in the recipe builder and the ISA-88 product will do the rest.


The physical system is represented graphically to describe the physical assets of an enterprise in terms of enterprises, sites, areas, process cells, units, equipment modules, and control modules. This graphical representation is referred to as the Physical Model or sometimes Equipment Model. It is the mechanical system that the Procedure Model has available to it to perform the necessary tasks to produce the batched products. The recipes are also represented graphically in the software as Procedure Models (referenced in the above paragraph). The recipe then points to the “units” defined in the equipment model that it will need in order to produce the desired batch. The ISA-88 product is typically server based and will interrogate the programmable automation controller (PAC) to find out what required units are available. As soon as it determines that a required piece of equipment is available, the ISA-88 engine will first “allocate” that “unit” and then pass the “phase” parameters down to the PAC for the controller to perform that specic portion of the complete batch recipe.

From the above explanation it can be seen how the scalability factors into the economic evaluation. Adding an additional item of equipment to the system can be completed in as little as a couple of hours by modifying the program. The equipment is then immediately available to the system. The ideal addition would be adding another piece of equipment in parallel where it would be of a similar “unit class”. You can see where it simply gets included as the “unit class” and the ISA-88 engine is solely looking for that unit class when it runs the recipe so nothing at all has to be done to the recipe to include this added piece of equipment. True, the PAC has to manage the I/O of the item, but if it is very similar to another piece of equipment then that code can be copied and new addresses assigned. Utilizing a modular programming methodology makes incorporating a new piece of equipment rudimentary. Both the inclusion into the recipes and the arbitration of the new item are automatically handled by the ISA-88 batch product.


Another important point is that all this information is logged into a major database platform such as Microsoft SQL Server. It is an open architecture and can be accessed by a variety of readily accessible tools – if security permissions are set to allow the access.

We feel that by utilizing both Microsoft for the database and Rockwell for the PAC and HMI platforms, you will have a system that is widely supported both now and well into the future.


Another typical feature of an ISA-88 product is the extensive batch history logging. The batch archiver not only records both the target and actual weights of each consumed ingredient, but it also logs each event that is associated with that particular batch. The resulting batch record provides an excellent history of both consumption and activities for any batch. BCI can offer reporting for campaigns and orders as appropriate.


In a standard ISA-88 product such as those listed at the beginning of this document, there are additional features that are normally desired, but are not included in the standard product such as:

  • Campaign Management (a family of related batches – e.g. perhaps a single work order for 200,000 lbs of a product would require a quantity of batches in order to complete that work order).
  • ERP interface (receive work orders, report usage, report rework or setback, retrieve Lot data from enterprise business system, do batch campaign reports, etc.
  • Lot Tracking (ingredient genealogy) is not included in all ISA-88 products and even when it is included it may have constraints. With FSMA requirements on the horizon, ingredient genealogy is an important consideration.
  • Bar Coding is commonly used for ingredient and Lot identification as well as the synchronization of pre-assembled hand-add kits with their appropriate batch components.


As we all recognize, some batching systems can be very complex, others quite simple. Typically they fall somewhere in between and deciding on the best solution for your system is not an easy task. In some cases a high end ISA-88 based batching solution is the best solution, in others it is not. Bachelor Controls has experienced professionals who can walk through the decision making process with you. We have been involved with some of the most complex solutions in the industry, as well as some of the simplest. We encourage you to contact us and we look forward to assisting you with your decision.