DCS migration: Batch or S88 style application?
Deciding between a dedicated batch application and building an S88 style application really comes down to the level of sophistication required to make the system user-friendly and supportable by the plant.
I just finished supporting a batch process startup where the client chose to not continue using the same batch application as the rest of their facility. This plant area had previously been controlled by a programmable logic controller (PLC) using some basic sequencing. The project was to migrate it to a distributed control system (DCS) that has already been used in other parts of the plant. Some of the other areas that have been migrated are using the batch software application, but because this process is rather basic it was decided that using the DCS batch software was overkill. Therefore, the migration was done using Sequential function chart-based equipment modules (EM) to operate control modules (CM). It seemed like a logical approach, though as the checkout progressed we kept running into its limitations: the lack a structured recipe/formula management system, the need to create multiple identical equipment modules, a somewhat clunky operator interface, etc. All of which would have been addressed by batch software.
Using the batch application, we would have created one unit procedure, one operation, one recipe with 11 different formulas, and two or three phases, depending on whether or not we’d considered the unloading of raw materials. The batch application would have also allowed the operators to queue up several batches, rather than having to wait on one batch to finish so they can start the next one. Modifications to the phases would only have to be done once; while the non-batch approach means modifying all 14 sequences in the EMs (there were 11 product sequences in one EM and three reactor sequences in another). In hindsight, it seems to have been a bad idea not to use batch, but was it really?
The decision between using a dedicated batch application and just building an S88 style application from scratch really comes down to the level of sophistication required to make the system user-friendly and supportable by the plant. The S88 structure is designed to extend all the way up to the manufacturing execution system (MES)/enterprise resource planning (ERP) level while the actual plant area may struggle to go as high as the unit level. However, at the very bottom of its structure is the EM/CM relationship, and that’s all that is present in our example plant area. You only start to gain real measurable benefits from a full S88 compliant batch application when you have multiple trains of similar equipment. The benefits involve the ability to use aliasing to minimize the amount of code that has to be written during development—reduced code also equals reduced testing effort—and then operationally effective arbitration to allow those trains that can, to operate in parallel. A full batch system also brings things like batch reporting, lot tracking, rapid deployment of new parallel trains, robust recipe/formula management, and a full featured operator interface with prompting and confirmation/verification.
The key to making the decision of batch or not batch is to understand what you’re giving up by not using it and determining if that is acceptable. The amount of effort to implement is a consideration, but up to a certain size it’s not really that big of a consideration. Yes, we had to write multiple sequences using the non-batch approach, but we really only had to write one, copy it, and make small edits. With the batch application you’d have to resolve all the aliases, so have you really saved that much time and effort? Without batch we had to create parameters to hold all of our formulas, and then we had to create a way to find and load the correct values into the correct product sequence. With batch we would have built that structure as part of defining the formulas used by a recipe which may have been a little less effort, but possibly not. And the list goes on: control module style interface versus a dedicated batch operator’s interface, continuous style history collection versus a SQL-based batch history system, etc.
So how do you decide to or not to use batch? Is there any one feature that automatically makes you use a batch application regardless of system size?
This post was written by Bruce Brandt. Bruce is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.