Using FEED for a Successful Batch Implementation


Batch implementation projects are much more likely to be successful when a thorough front end engineering design (FEED) is performed and if several questions are addressed during the implementation process.

A batch (ANSI/ISA-88) implementation is appropriate for many types of process and industries. If it is appropriate for your project, there are many different choices and decisions that need to be made during the planning stages that can dramatically alter the complexity, cost, and final implementation utility. As with many projects, batch projects are much more likely to be successful when a thorough front end engineering design (FEED) is performed. There are several key questions that FEED should address during the project.

The physical model describes the process and the equipment used to implement the process

The ANSI/ISA-88 standard includes guidelines on how to represent and model the physical assets and operational functions of the system, using a hierarchical representation. Depending on the size of the process, enterprises, sites, and areas may be defined. All implementations will include process cells, units, equipment modules, and control modules.

Defining the units and equipment modules tends to be the most challenging part of the exercise. Many commercial batch engines are priced according to the number of units, so minimizing this count can be a design goal. Units are often tied to the physical tanks, reactors, or other physical locations where products are transformed. Equipment modules are frequently tied to the systems that perform transformations on products.

Equipment phases are the key building blocks of the process model. They define how the product is made on the physical equipment. Some batch implementations are unit-centric with the equipment phases defined on the units. Other batch implementations are equipment module-centric with the equipment phases defined on the equipment modules. Deciding which of these two approaches will work best on a particular process is a key output of the FEED. There are some implementations that blend the two approaches, but that is relatively uncommon.

The recipe model describes how the physical model is used to produce product

Recipes describe how and with what materials a product will be produced. Like the physical model, a hierarchical structure is used, breaking recipes into procedures, unit procedures, operations, and recipe phases. Procedures are recipe types that can span across multiple units and equipment modules. They tend to hold the complete methodology for producing a product. Recipe phases are tied directly to equipment phases whether they are defined on units or on equipment modules. The unit procedure and operation levels of the hierarchy can be used however is appropriate to further the organizational needs of the process.

Recipes are made up of a sequence of tasks to be implemented combined with data parameters that describe the quantities and setpoints required by the tasks. A key feature of recipes is their scalability. Some parameters, such as raw material quantities, may scale linearly with batch size while others, such as pressure setpoints, may remain fixed. Non-linear relationships between batch size and parameters, such as a pH profile, may require a specific software platform or custom development.

In most organizations, there exists some separate system that maintains the product formulae and manufacturing instructions. The FEED process should evaluate how the existing formulae can be translated from the current tracking routine into the batch recipe model, both at commissioning and during continuing operations.

As recipes are modified over time, a change management methodology is crucial. An automatic method should be in place to track edits, allow rollbacks to previous versions, and control edit access to recipes.

Reusability is a key feature

Unique units, equipment modules, equipment phases, and recipes could be created for every individual component of the process, but that would be a waste of time and resources. Planning for efficiency in development by leveraging reuse and replication should be a component of the FEED process. Physical model objects can organized as classes of objects which share attributes. Unit classes and equipment phase classes can be designed to allow for rapid replication of similar objects, and changes to the class definitions can be easily propagated to all members of the class.

Recipes are designed to be constructed modularly out of smaller building blocks. A few dozen unique recipe phases could be organized into millions of distinct recipes. Changes to any recipe object can propagate to all higher-level recipes that make use of the changed object.

Collect and report data on batch activities

All commercial batch engines record their activities, some in simple text files and others in relational databases. These records are valuable on their own, but they start to create true business intelligence when they are combined with other enterprise records. Integrating batch records with process and equipment performance data, alarm data, and enterprise resource planning (ERP) data should be part of the FEED evaluation.

Batch is a complex process

Whether it’s called a FEED study, an initial engineering assessment, or something else, the success of a batch project is dependent on the planning and decisions made during the initial design. Many batch projects fail because developers jump into the development work and later realize that the chosen platform does not meet all their needs. They may have to go back to the drawing board because some decision about the physical model turns out to hamper production rates or product flexibility. A thorough evaluation of all the project needs, paired with all the software and hardware capabilities to meet those needs, will greatly improve the chances of project success.