Making a platform selection to implement a batch automation solution should start with the evaluation of the end user's short- and long-term requirements. Unfortunately, end users sometimes make decisions solely based on the short-term objective of cost. This is not always compatible with meeting long-term requirements.

Here are some aspects to consider before building a solution:

1. Number of recipes that need to be maintained. Controller-based solutions are limited in the number of recipes they may store, whereas PC-based solutions are not.

2. Complexity of each of these recipes. Some controller-based solutions are not capable of automatically looping back or allowing decision branching in the recipe based on process conditions. In addition, their transition conditions are simplistic and may not be able to evaluate expressions.

3. Ability to make adjustments using parameters and report values. Can the parameters and report values of the running recipe be used dynamically to adjust other set points within the same batch?

4. Multi-unit recipe coordination. This requires all levels of recipe definition: the ISA-88 standards define procedures, unit procedures, and operations. The communication and exchange of information between recipes running in different units is handled as part of the functionality of PC-based solutions. In controller-based solutions, custom code needs to be implemented to coordinate the interunit activities.

5. Distribution of necessary logic. Is the logic required to perform different tasks (pertinent to ISA-88 phases) programmed in a single controller, or is it distributed among multiple controllers? With controller-based sequencers, all phases required by the recipe must reside in the same controller. A PC-based solution can create recipes whose phases reside in multiple controllers and can even be distributed among assorted controller brands and models.

An integrated architecture deploys a PC-based solution to communicate with the controller-based firmware solution, creating a distributed batch solution.

6. Use of class-based recipes minimizes the number of recipes, as well as the complexity of multi-unit routing options. They are only possible with a PC-based solution, though. Controller-based solutions require building the same recipe for each unit.

7. Rules regulating recipes. Kosher recipes or recipes with allergens cannot run against specific units. Controller-based recipes manage these requirements by simply specifying the requirements or preferences.

8.Protection of the recipe as intellectual property. Encapsulating the best practices regarding how to make a product, intellectual property (IP) can typically be accessed by any programmer or user of a controller-based solution. PC-based solutions isolate the know-how of the product IP from the controller program. System integrators and developers are only exposed to the capabilities of the equipment, which can be designed, implemented, and tested without exposing how the products are made.

9. Recipe versioning. It can be useful to recall how a product was made using a previous version of the recipe, without having to go to databases to rebuild the procedure.

10. Approval process. Managing the approval process for releasing recipes to production limits who can make changes to recipes and may enforce a consensus before it can be run. This functionality is only available in PC-based solutions.

11. Network infrastructure. Some believe that, despite poor network communication, a recipe can continue running through its steps until completion using a controller-based solution. Consider, however, the need for human-machine interface control, as well as what happens to the batch data.

Controller-based solutions can be applications developed to run as controller code. This approach uses a significant amount of controller memory. Another approach uses the sequencing engine built into the firmware of the controller. Using off-the-shelf functionality and not custom code, this approach also has limitations, but has more versatility. A PC-based solution offers much of the short- and long-term functionality required by most end users, but requires licensing the product.

Recently, an automation vendor released functionality that allows the PC-based solution to communicate with the controller-based firmware solution, creating a distributed batch solution that maximizes the benefits of each option. With the distributed batch solution, parameters and report information can be communicated between the controller-based and PC-based solutions.

A version of this article also was published at InTech magazine.