The ISA88 standard is primarily aimed at batch process manufacturing, often referred to as the “bible” of batch process manufacturing. However, the concepts and models it presents have also had a profound impact on other manufacturing modes. As a PLC design engineer in a non-batch process manufacturing industry, I believe the greatest value of the ISA88 standard lies not in the well-known state machine model, but in its physical model and procedural control model. It has changed the way we design and build automation systems, helping us elevate our code from “usable” to an industrial-grade level that is “professional, maintainable, and scalable”.
Before introducing these two models, we must understand the core concept of ISA88: “separating the process (what to do) from the equipment (how to do it)“, which is the essence of separation and abstraction.
- Physical Model: Describes “how to do it” — your hardware device hierarchy.
- Procedural Control Model: Describes “what to do” — your production process flow.
Physical Model: Defining Your Device Hierarchy
The physical model is a hierarchical and modular description of the physical devices in a factory, organizing all hardware assets in a structured manner. The hierarchy from top to bottom is:
Enterprise -> Plant -> Production Area -> Process Cell -> Unit -> Equipment Module -> Control Module
Where the focus for PLC engineers is:
- Control Module: The most basic device components at the lowest level, such as a cylinder, photoelectric sensor, or servo.
- Equipment Module: Composed of multiple control modules, capable of completing a specific small function group, belonging to a Unit. (e.g., a loading and unloading module that includes a six-axis robot, a gripper cylinder, and a photoelectric sensor)
- Unit: Refers to a device or group of devices that can independently perform major process operations. (e.g., mobile phone screen assembly station, mobile phone camera testing station)
My Understanding:
- Control Module: Create a standard function block (FB) for each control module. For example, CM_Valve, CM_Servo, CM_PID. These FBs encapsulate all control, interlocking, status, and fault diagnosis of the device.
- Equipment Module: Combine multiple control modules serving the same purpose into an equipment module. For example, create an EM_Loader that internally calls CM_Robot, CM_Cylinder, etc., and implements the complete loading and unloading process logic.
- Unit: The unit is the core of the entire program. For example, create a top-level Unit_CameraInstallation module. This module does not directly control a cylinder or servo but calls and manages encapsulated equipment modules like EM_Loader and EM_Feeder.
When you need to add a timeout detection feature for a valve, you only need to modify CM_Valve in one place, and all Units using that valve will automatically update. This exemplifies high cohesion and low coupling.
Procedural Control Model: Defining Your Production Process
The core of the procedural control model is to separate “production processes” from “physical devices”. It describes the procedural control required to produce a product, i.e., the “recipe” or “workflow”, which is completely independent of physical devices. The hierarchical structure from top to bottom is:
Procedure -> Unit Procedure -> Operation -> Phase
- Procedure: The highest level, describing the complete process required to produce a product. For example, “Procedure for producing ABC beer”.
- Unit Procedure: The main stages completed on a specific Unit. A Procedure consists of multiple Unit Procedures executed sequentially or in parallel. For example, “the mashing process in the mashing Unit”, “the fermentation process in the fermentation tank Unit”.
- Operation: A major step under a Unit Procedure. It describes “what to do” but does not specify the specific equipment. For example, “heat to 85°C and hold for 30 minutes”, “transfer to the fermentation tank”.
- Phase: The most critical and executable layer in the procedural control model. It is a reusable, independent control logic module that directly commands physical devices to perform actions, serving as the bridge between the procedural control model and the physical model. This is typically implemented in PLCs.
My Understanding:
- Create a Reusable Phase Library: As a PLC engineer, one of the main tasks is to write these generic, robust Phases. A Phase is a standard module that receives parameters (such as target temperature, hold time, target device) and contains complete logic (e.g., first open the steam valve, then control with PID, start timing after reaching the temperature, close the valve after timing ends, and report completion).
- Interaction of Phase with the Physical Model: A Phase does not directly know about the existence of control modules or equipment modules like P101, V201. The Phase sends abstract “commands” to the physical model (Unit), which translates them into specific “device actions”. This is the essence of “separation”.
- Building Recipes: Process engineers use the visual tools of Batch software to drag and drop these predefined Phases, combining different Phases to construct Operations and Unit Procedures, thus forming a complete production recipe (Procedure). They set parameters (such as temperature, weight, time) but do not need to write any control code; they focus on “what to do” (What).
The Interaction Mechanism Between the Two Models
The key to effectively combining the procedural control model and the physical model lies in establishing a clear and standardized interaction interface. The core idea of this interface is that the procedural control model (Phase) sends abstract “commands” to the physical model (Unit), which translates them into specific “device actions”.
The dialogue between the two models is accomplished through “commands” and “status”. This is a typical “request-response” pattern.
- Procedure → Physical (Command Flow): The Phase issues a high-level, device-independent command to the Unit (e.g., Start, Hold, Stop, Abort, Reset, HeatToTemp(85.0)).
- Physical → Procedure (Status Flow): The Unit feeds back its current status to the Phase (e.g., Idle, Running, Held, Complete, Aborted), along with any necessary information (e.g., current temperature, flow rate, etc.).
This interaction is entirely based on abstract logic; the Phase does not know or care how the HeatToTemp command is implemented within the Unit; it only cares whether the command was successfully executed and completed.
Like it to let more people see it