May/June 2013
Process Automation

Considerations for selecting a controller- or server-based batch sequencer

Selecting the right solution when designing your batch-sequencing system saves valuable design time and validation effort and simplifies maintenance

By John Párraga

Fast Forward

  • Complexity - not size - matters when choosing the appropriate batch-sequencing solution.
  • While identifying the best batch solution, consider the pros and cons of all three commonly used batch-sequencing systems: hard-coded, controller-based, and server-based.
  • Selecting the appropriate batch-sequencing solution will save valuable design, validation, and maintenance time.

The new server-based solution has given PZ Cussons a level of process visibility and control far beyond what its older plant had. The company has also been able to simplify processes that took operators many years to learn.

When designing a batch system, engineers often select the control solution based on the size of a system and not the complexity of its procedures. It is traditionally thought that small batch systems require a controller-based sequencing solution, while large systems require a server-based solution. Despite tradition, the size of a system is not the best indicator of an appropriate solution; a small application or single-unit may have complex requirements. For example, a unit may have hundreds of recipes, making the batch and sequencing extremely complicated when using a hard-coded or controller-based system.

To identify the right solution, users can consider three commonly used types of batch and sequencing solutions: 1) hard-coded, 2) controller-based, and 3) server-based (often referred to as comprehensive).

Very few systems can leverage a custom, hard-coded solution, as it typically only allows for formula values (set points) to be downloaded to a fixed sequence. As a result, when the sequence must change, users are forced to change the code. This adds risk to the process and can add significant cost in terms of retesting and validating the system.

To combat the rigidity of a hard-coded solution, engineers often turn to a pre-developed controller-based sequencer solution for their small, non-complex batching needs. This is appropriate if the application requires sequence-management capabilities, but the complexity of the process may not be great enough to warrant a server-based software package.

The server-based solution provides the ability to manage a larger amount of equipment with more complex requirements. This solution provides validation advantages that come from class-based equipment and recipe definitions, greatly reducing the amount of validation required compared to the other solutions.

But how does one know if the complexity of the process calls for a server-based solution? While a small system usually requires a small amount of equipment, it can be accompanied by simple or complex requirements (see Figure 1). To determine whether or not a system has simple or complex requirements, one must answer the following questions:

  • Does your system have fewer than 32 recipes?
  • Is the complete batch built in a single (ISA-88) unit?
  • Can you define your batch procedure without branches or loop backs?
  • Does your system capture fewer than four report values (real type) per phase instance?
  • Does your system have four or fewer recipe parameters (real type) per phase instance?
  • Does your system have enough controller memory for the application?

If every answer is yes, then controller-based batch and sequencing may be sufficient. If only some - or none - of the answers to these questions are yes, a server-based solution is the more suitable choice.

After considering the technical requirements of the system, engineers should also evaluate the pros and cons of each solution, starting with total cost of ownership. The real cost of a system must figure into the decision, whether the solution is long term or short term. A short-term solution may only consider the need to sequence phases in a controller, while a long-term solution may consider the capture of extensive batch activity data, traceability, and interactions with other systems.


Figure 1: The size of a batch system is not always the best indicator of an appropriate solution. A small system usually requires a relatively small amount of equipment but can be accompanied by simple or complex requirements.

A controller-based solution


Controller-based solutions typically require no additional up-front licensing investment beyond the human-machine interface and controller. In addition, a controller-based solution solves simple batching needs; it allows for flexible recipe management and enables local, single-unit supervision and control. And if using a controller-based solution that is not hard-coded, the solution will require less validation effort.


This approach typically requires more recipe upkeep in maintaining consistency among similar units. A controller-based solution may cost nothing up front, but if the system requirements change - for example, requiring in-depth reporting - you will need to develop and test reports that are not part of the controller-based solution. Recipes deployed in a controller-based solution require validation for every product and each piece of equipment.

A server-based solution


This approach enables maximum flexibility for the most demanding batch requirements. Server-based solutions solve higher-level requirements, such as class-based recipes, audit/diagnostics, extensive data collection and reporting, analysis and optimization, equipment arbitration, integration with MES/ERP systems, manual work instructions, recipe safe-keeping isolated from the controller code, one-time validation, and active material management - all while supporting multiunit coordination across multiple controllers, if required.


These types of systems are more expensive up front because they require the purchase of a license to activate the software, as well as a healthy network to abstract the sequencing engine from the controller code. The server-based solutions also require additional validation effort up front due to the increased functionality designed into the phase logic of the systems.


Pharmaceutical manufacturer implements new batch and sequence management


With the new system, plant operators at AFC enjoy decreased reliance on manual, paper-based batch sheets, thanks to an automated solution embedded directly into the control system.


AMPAC Fine Chemicals required an updated process control system to meet regulatory requirements and increased security demands associated with controlled substances.

AMPAC Fine Chemicals (AFC), one of North America's largest custom, small-molecule manufacturers of active pharmaceutical ingredients (API), weighed its batch configuration options and migrated its hard-coded control system to a controller-based solution. "AFC really needed a flexible control solution that offered easier system updates to accommodate their highly-varied manufacturing schedule," said Neal Yates, senior project engineer at Banks Integration, AFC's long-time automation partner.

"The project was originally scoped only for the control-equipment upgrade, so there was no funding available for the addition of batch capabilities," Yates explained. After considering several alternatives, AFC decided that a controller-based solution would be an ideal alternative to a traditional server-based batch solution.

AMPAC Fine Chemicals implemented the Rockwell Automation PlantPAx Logix Batch & Sequence Manager, which is a controller-based batch and sequencing solution that runs independent of application servers. As a result, Yates and the Banks Integration Group team were able to deliver a flexible, controller-based solution without the need for costly, engineering-intensive custom code or additional server infrastructure associated with large-scale batch solutions. In addition, the AFC team can now configure recipes and formulas directly in the controller using dedicated software that does not require code changes to the system. This important advancement helps users streamline the implementation of approved changes.

With the new system, plant operators at AFC have reduced their use of manual, paper-based batch sheets for detailed processing instructions, thanks to an automated solution embedded directly into the control system. "Many of our production processes require a high level of detail - for example, if we remove a kill solution that deactivates a volatile chemical too soon, it could significantly impact the entire process," said Mike Ryan, director of automation systems and calibration at AFC. "With the automated batch solution, we're improving the quality and consistency of our APIs and avoiding the delays that naturally occur during manual operations."


Personal-wash company improves performance while meeting stringent quality standards

Although a controller-based solution was an option for a batch-configuration solution for AFC, PZ Cussons, a leading personal wash company based in the U.K., had a successful experience implementing a server-based solution into its high-speed liquid manufacturing facility.

As part of a complete overhaul and modernization of its U.K. supply chain, PZ Cussons decided to take advantage of the control and visibility capabilities offered by a modern process-capable automation infrastructure. While establishing the justification for a new U.K. manufacturing facility, the company realized that much of its existing process equipment at its old site was not meeting demands of a modern manufacturing environment.

Starting from a clean slate, PZ Cussons recognized many areas where savings could be made and unnecessary costs removed. The company also wanted to adopt leaner manufacturing procedures to enable further savings in stock holding and deliveries. The primary challenge was to obtain visibility into all steps of the process and keep parameters within operational tolerances. This required extremely accurate batching, mixing, and metering systems that could not only communicate with each other, but also communicate with the master control system within the offices, and with external suppliers, via a secure extranet.

An entirely new processing and production operation was developed with their automation system and instrumentation suppliers. Instrumentation supplier Endress+Hauser engineered, designed, and commissioned the instruments and fieldbus networks. The implementation of the project made full use of the diagnostic data that the fieldbus devices provide. This has given PZ Cussons a level of process visibility and control far beyond what its older plant had. The new approach is helping the company attain many of the savings it envisaged, while also removing many of the process variables, which introduced unwanted costs.

PZ Cussons has effectively been able to simplify some processes that took operators many years to learn. Even then, each operator had his own way of doing things on each of the machines, which led to some of the process variability.

With the old approach, all the recipes were hard-coded into the programmable logic controllers (PLCs), so there was no easy way to test new recipes and mixes without a significant recoding exercise. The new technology has allowed the company to pilot test new recipes on a small scale prior to mass production. Using the old approach, there was a need for specialist operators, but, due to the scalability and portability of the software, any operator can now run any line. This allows operators to become much more multi-skilled - adding value to the areas where their intervention really counts.


The selection of a batch-sequencing system should not be based only on the amount of process equipment; the level of complexity, flexibility, and system requirements should all weigh into the decision. Selecting the right solution when designing your batch-sequencing system will save valuable design time, validation effort, and simplify its maintenance.


John Párraga ( is a product manager at Rockwell Automation. He spent his early professional career working on machine design, with an emphasis on rotating machinery, such as turbo chargers for locomotive engines and aircraft engines. For the past 16 years he has been focused on batch process automation in industry sectors throughout the consumer packaged goods, pharmaceutical, and chemical process industries. Párraga holds a B.S. in mechanical engineering from the University of South Florida.

Considerations for batch and sequencing system selection












Equipment cost

  • Low-cost or free sequencing engine HMI and controller application code
  • Requires HMI software
  • Requires a controller


  • Sequencer engine
  • Operator electronic work instructions
  • Material management
  • Batch campaigning
  • Formulation management
  • Electronic journal
  • Web-based reporting
  • No controller required for manual processes
  • No HMI required
  • Higher up front investment due to the required purchase of batch software








  • Does not require a server operating system
  • Requires a controller
  • Requires HMI software and operating system


  • Works with a variety of user interfaces
  • Does not require a controller for recipe manuals operating instructions
  • Multi-controller interface and coordination
  • Requires a server operating system to run batch service








  • Recipe will continue to run in the controller without an HMI or network
  • Recipe will continue to run without HMI or network; no operation view if loss of network
  • Loss of power will cause loss of current or sequence state


  • Components detect loss of network or server and bring recipe and phases to held safe state
  • Upon system restore, the recipes reconstruct and recipes continue where they left off after an operator restart
  • Requires the PC and the network in order to continue sequencing
  • No built-in redundancy; relies on third party like virtualization







Reporting capabilities

  • Reporting available on certain data types
  • Custom reporting required
  • High cost of implementation
  • Only some valued data is captured


  • Comprehensive data collection performed by batch service
  • Ability to move data to multiple data bases
  • Free predefined reports
  • Interaction with historical data-tracking software provides the ability to correlate batches with historical trend data
  • Requires an operating system







Equipment definition and specification

  • All equipment model configuration performed via HMI
  • Ability to add equipment phases to definition without affecting running recipes
  • Simple to understand and deploy
  • Controller memory usage tool available
  • Ability to add or remove units, phases, parameters and report values on-the-go
  • Only requires HMI and controller know-how to maintain
  • Limited parameters and report values
  • Typically no strings or enumerations parameters or report values
  • All equipment definitions require the same controller memory overhead to be reserved, whether it is in use or not
  • Maximum of 32 phases per unit
  • Consumes controller processor memory (estimating tool available)


  • Extensive number of parameters and report values
  • Each equipment definition can be different for units, phases, parameters and reports
  • Parameters and report data types: integer, real, strings, enumerations
  • Unit attributes allow equipment to be automatically selected based on equipment conditions
  • Phases have the ability to acquire shared resources
  • Equipment allocation and arbitration is performed by batch server not in controller code
  • Does not require controller to run if manual process.
  • Equipment phase logic can be distributed among multiple controllers or varying types
  • Unit and phase class definition
  • Addition of new equipment requires stopping and restarting batch service; no online equipment definition changes allowed







Recipe definition and usability

  • Intuitive user interface for operator and formulators
  • Ability to modify existing running recipes on the go
  • Ability to save running recipe as master recipe
  • Simple to step forward or backward to predefined pausing points
  • All recipe definition is performed via HMI
  • All recipe definitions reside in the controller
  • Single-unit recipes
  • No class-based recipes; each one needs to be maintained individually
  • One (ISA-88) operation per recipe
  • No recipe structure reusability
  • Maximum of 32 steps per recipe
  • Maximum of 32 recipes per unit
  • All recipes reserve the same amount of controller memory regardless of number of steps or recipes per unit
  • Recipe step transitions are solely based on phase completion
  • No looping or branching in recipe; always performs the same steps of a sequence
  • Risk of losing recipe intellectual property by exposing controller code to anyone working in the controller


  • Multiple-unit recipe coordination
  • Recipe operations and unit procedures can be reused by other recipes
  • Ease of creating, saving, and replicating recipes
  • Class-based recipes allow one recipe to run in multiple units at the same time, simplifying recipe management and control
  • Number of recipes virtually unlimited; recipes may contain many steps
  • Recipes do not reside in the controller and do not consume controller memory
  • Recipes are transportable (copy/paste)
  • Recipe changes are audited
  • Phase parameters and reports can be calculations that reference other parameters and report values, unit tags, etc.
  • Recipe step transitions can be configured to be the result of calculated values, unit conditions, recipe conditions, reported values, parameters, equipment states, etc., or simply phase complete
  • Looping and branching can be performed
  • Changes made to running recipe cannot be stored as the master recipe
  • Steps cannot be added or removed from running control recipes








  • Non-hard-coded controller-based solutions require less validation effort than hard-coded solutions.
  • Recipes need to be validated for each product and for all equipment


  • The sequencing engine allows class-based recipes to be deployed on class-based equipment which only requires one-time recipe validation
  • Network performance needs to be reliable
  • Typically, more functionality is designed into the phase logic of these systems, requiring additional effort