System Integrators

Designing an equipment model

System integrator offers expert advice on designing equipment and procedural batch models.
By John Parraga December 19, 2019
Courtesy: ECS Solutions

According to ISA/S88 guidelines, a manufacturing process can be represented in terms of two models: A procedural model and an equipment model. The equipment model includes a functional group of equipment that can perform a finite number of specific, minor, processing activities. It is important the equipment model is well-designed and provides flexibility and modularity as well as impacting the equipment’s overall performance. One approach to equipment model design is based on the use of phases, which is where the phase is regarded as a building block for the process or as a specific activity. Questions to consider include:

  • How does the phase interact with operators and automation control system?
  • What information is recorded and made available to an operator and journals?
  • How does a phase respond to failure of a component in the equipment?

In considering the design phases, it may be useful to equate a phase to an ideal operator, who approaches a unit or selects a module of interest, e.g., water addition, or temperature control, and using the human-machine interface (HMI) pop-up inserts the values required for the process.

Those actions are some of the phase’s functions. In addition, it is important the phase should establish the status of the equipment to be used and inform the operator of conditions of exceptions before any actions are taken. Any abnormal conditions will be logged, and the operator can obtain specific information about the equipment, such as:

  • Is any component faulted?
  • What and where is the fault?
  • Are any components in manual mode?

Phases should not automatically change the mode of their subordinate equipment, but they should prompt an operator if such changes are desired. For example, if it is logged that a component of the equipment is in manual mode, the phase should only inform the operator of this condition and not change it to auto in order to run the equipment. All changes in parameter setpoints, changes that may be carried out by an operator or code, must be logged by the phase.

If phase failure occurs (typically an equipment failure), the phase should be commanded to go into “HOLD” and specific information regarding the cause of failure should be logged. It is preferable that a phase does not depend on a parallel phase be required to complete a task unless it is required by the functionality. In such instances, the recipe author must know the logic involved, which is not desirable. Furthermore, the absence of such dependence can simplify the design.

There are situations where coordinating phases is necessary. An example is the “Transfer IN” and “Transfer OUT” activities that occur between units. In a material addition activity, the phase should identify if a dosing error occurred, informing the operator of the error showing it as “out of tolerance high” or “out of tolerance low” and allow to adjust to that condition. Another situation that requires the coordination of phases is the use of multiple phases requiring common resources. For example, providing water addition to multiple locations when totalized with a common flowmeter, this will require arbitration. This means the coordination control that becomes necessary to determine how a resource should be allocated when the demands for that resource are many at one time.

Using a phase can minimize arbitration and it is preferred one phase is shared by multiple units. However, it may be necessary to use multiple phases where different units and their phases are controlled by different programmable logic controllers (PLCs). In such cases, a resource is created that is arbitrated among the multiple phases.

In the design of the equipment model, advantage should be taken of the availability of material manager, a component of FactoryTalkBatch from Rockwell Automation. The material manager has the capability to:

  • Identify the location of the resources and determine whether they are stored in tanks, silos, supersacks, barrels, drums or on pallets
  • Define and control the type of material allowed in each
  • Prioritize the usage of the materials when found in various storage locations
  • Define material properties such as density, moisture content, concentration, potency, humidity, pH, etc. This allows the phase to compensate for variations in material properties such as, moisture content and potency.

It is recommended individual documents are developed for each phase or phase class in which all relevant design information is captured, specifically phase logic, phase failures that may occur, interactions with operators and the equipment model design. The creation of documents for each phase reduces the time spent waiting for all documents to be completed before programming activities can be initiated. Some phases such as agitation or prompting the operator are well established so programming those phases can be undertaken before all documents are complete. This allows an earlier completion of the project as well as staggering of tasks. The terms used in naming parameter and reports (tags) must be meaningful and not rather obscure engineering terms that make little or no sense to the recipe authors or the audience of this data.

Diagram of a procedural batch process. Courtesy: ECS Solutions

Diagram of a procedural batch process. Courtesy: ECS Solutions

Phases can take advantage of the availability of high order functions on today’s controllers, mathematical derivatives and integrals or possibly the use of fuzzy logic or advanced process control. This capability may allow the determination of the efficiency of a single phase, which may be designated as the phase overall equipment effectiveness (OEE). Information is collected for individual phases and these calculations to calculate a flowrate in the absence of a flowmeter e.g., the change in weight of a tank with time during the addition of material, defines the flow rate which in turn allows prediction of the total time required to complete the dosing activity.

Integration of temperature-time profiles during a heating process will indicate the amount of heat impinged on the product. This can give indication of the amount of cooking as well as the sterilization of the equipment during the clean-in-place (CIP) and sterilize-in-place (SIP) tasks. Integrals also allow the determination of the total power used in the agitation activity. Generic timer phases can be used to determine recipe activities OEE, by placing count-up timers in parallel with the recipe activities, allows us to use this data and information to determine the OEE of each activity of the recipe and not just the overall time it took to complete a recipe.

With these requirements in mind, consider the seven steps to the design of an equipment model.

A preferred approach to the design of an equipment model is a sequence of seven steps:

  1. Determine the process boundaries.
  2. Determine the units and containers involved.
  3. Follow the flow of materials.
  4. What is done to the materials in a unit?
  5. Identify unit tags.
  6. Determine equipment arbitration.
  7. Determine the parameter and report values.

1. Determine the process boundaries.

The upstream boundary covers incoming materials whereas the downstream boundary refers to all finished product storage activities, usually storage of the products of the process. The vertical boundary indicates integration with the enterprise resource planning (ERP) to receive orders and to report materials produced and consumed. The fourth boundary covers reports to be generated, particularly any reports specifically requested by customers as well as the programing standards to be used.

2. Determine the units and containers involved.

This is a very important activity. The FactoryTalkBatch program is priced per unit. Consequently, poor definition of the number of units in the model can result in high costs rendering the project not viable. Containers are typically tanks, drums and pallets, supper sacks, etc.

The traditional definition of a unit is a piece of equipment that combines and/or transforms ingredients to add value to an interim product or to the final product. This can be misinterpreted and therefore recommend thinking about the unit as “any location, whether equipment related, or non-equipment related in which a sequence or procedure is performed.”

Based on this definition, an empty room or area in which manual pre-weighing of materials is conducted is a unit, even though no automated equipment is involved or required. CIP equipment that requires a sequence or recipe to make up the cleaning solutions will also be defined as a unit. This approach extends to the parts of the CIP equipment that require cleaning independently of a tank or vessel.

What is not a unit? Typically, heat exchangers are not units unless an independent procedure is performed in it. An example is the heat exchanger used only to control the temperature of the water is not counted as a unit.

The Equipment Editor (a component of FactoryTalkBatch) is used in the development of the equipment model and is an excellent place to document units and containers.

3. Follow the flow of materials.

This step requires the identification of the phases that bring materials into the process system, move materials within the system and transfer materials (usually the products) out of the system and into storage. A straightforward approach is to begin at the top and center of the units in the piping and instrumentation diagram (P&ID) and follow the perimeter of the diagram identifying what actions are taken at each piece of equipment interacting with the unit. For example, the action of adding water, oil, transferring material to another tank, unloading the tank.

4. What is done to the materials in a unit?

This is a continuation of the previous step, following the P&ID to identify the actions that occur. For example, an action may be to agitate the mixture or possibly to heat/cool to a specific temperature. Some phases could be used to control pressure, or to prompt an operator to perform manual tasks, such as submit a sample to the laboratory or prompt closure of a lid of a vessel.

Not all phases to be identified in the equipment model are reflected in the P&ID; these will indicate what the equipment can do. The model will include tasks performed by operators, these tasks are also defined as phases.

5. Identify unit tags.

Unit tags can be values of weight, temperature, level or pH that are displayed at each unit in the equipment model. They allow the recipe author to make decisions to be made in the recipe based on process conditions. For example: “Start adding a second material after the tank has reached a desired weight” or “add material after the temperature drops below or exceeds a target temperature.”

The equipment editor can be used to document the phases for each unit.

6. Determine equipment arbitration.

An example is the need for arbitration applied only to recirculation at tanks 301 and 302. The actions will occur one at a time using the shared resource. If the units were programmed in different controllers it will be necessary to create two phases, one for 301 and one for 302, and to provide a recirculation loop as a resource to allow arbitration.

7. Determine the parameter and report values.

This is where the bulk of the project work is defined. Keep in mind the engineers building the project may not be the user creating recipes or operating the batch system. It is important to use meaningful names for parameter and report names and be consistent with naming conventions. For example, the representation of a parameter might be:


And the corresponding report should be:


Setpoints for given parameters may be changed by an operator and it is very important all changes be documented in the phase reports.

It is convenient to use parameters to prompt operators. If equipment has faulted or is in manual mode, then the action cannot be completed. To counteract this, a phase parameter can be created to prompt the operator to check the equipment. This is shown as:


The OO, indicating “operator origin,” specifies how the phase is to be configured. Since the recipe author does not need to know how equipment is configured, a parameter should relate to the basic functions and allow the logic to adapt for equipment differences.

Parameters originate at all levels. The control module may have a parameter that addresses the question: “How long should a valve take to open before it is considered faulty?” On the procedural side, parameters may originate at all levels such as the procedure, unit procedure, operation and recipe phase. Most of the parameters will be at the recipe and equipment phase levels. On the procedural side, some parameters at the recipe phase level may be deferred to the procedural level to create an interface with the ERP. Parameters at the equipment phase also may be deferred to lower levels. Not all parameters required to perform a task need be in the recipe.

Batching activities are recorded in the event journal. Report values need to be useful in determining the product quality as well as providing an understanding of what occurred during the execution of the recipe.

John Parraga is a batch process specialist at ECS Solutions. He is an experienced batch process engineer with career stops at Sequentia and Rockwell Automation.

ECS Solutions is a certified member of the Control System Integrators Association (CSIA).

John Parraga
Author Bio: John Parraga is a batch process specialist at ECS Solutions. He is an experienced batch process engineer with career stops at Sequentia and Rockwell Automation.