ISA-88 defines two linked models, equipment and procedure, so batch logic can be modular, reusable, and auditable within a modern MES architecture [S1][S6].
The framework applies to finite production runs in pharmaceuticals, biotechnology, specialty chemicals, food and beverage, electronics, and other manufacturing environments [S2][S3].
Two Models Define the Batch Control Boundary
ISA-88 establishes a common structure for describing equipment, procedures, recipes, and their interactions rather than prescribing a particular PLC, DCS, PAC, or MES configuration [S1][S2]. Its equipment model represents physical assets and reusable capabilities, while its procedural model organizes the steps used to make a product [S5][S8].
The ISA-88 procedural model comprises procedures, unit procedures, operations, and phases, while a separate recipe model defines product requirements and the equipment model describes how equipment is organized. A recipe describes what should be produced, an equipment model describes where and with what capability it can be produced, and a procedure connects the two [S7][S9].
This separation is the standard's defining engineering choice: product knowledge, equipment knowledge, and control execution remain distinct but connected [S1]. It supports reusable equipment definitions, clearer change ownership, and a common terminology for control engineers, MES teams, operators, and management [S2].
ISA-88 and ISA-95 Place Batch Control Below MES
ISA-88 provides models and terminology for batch control, including procedures, unit procedures, operations, phases, recipes, and equipment organization, while its relationship with ISA-95 concerns the integration of batch systems with enterprise and control systems.
That hierarchy gives modern MES stacks a precise role for batch control. The MES can schedule work, allocate resources, manage materials, issue production instructions, and collect results, while the Level 2 batch application executes procedural sequences against physical equipment [S3][S4]. The detailed interface depends on the selected integration architecture and installed automation platform.
The distinction also prevents a common architecture error: treating a full recipe as a single uncontrolled block of PLC code. An ISA-88 design exposes named phases and unit procedures, allowing MES-level status, production data, and reporting functions to remain associated with batch execution [S3][S4]. The wider hierarchy is explained in ISA-95 and IIoT: Why the Automation Pyramid Still Matters.
Recipe Portability Depends on Equipment Mapping
A master recipe is portable only when the target site can map its product requirements to available equipment modules and their capabilities. ISA-88 does not make every recipe automatically transferable; it provides the structure needed to identify missing equipment, incompatible parameters, and site-specific constraints [S2][S7].
For pharmaceutical and biotechnology production, this architecture supports controlled transfer from pilot equipment to commercial-scale equipment without redesigning the procedural model around each control system [S3]. Chemical processors use the same structure for formulations running through shared reactors and separators, while food plants apply it to finite runs of different products on shared filling and packaging lines [S2].
The procedure-to-equipment mapping is therefore a design review, not a clerical exercise. Engineers must compare required operations, available units, material-transfer constraints, control capabilities, and acceptance criteria before approving a recipe for a specific line. ISA-88 supplies common object names for that review, but it does not define the plant's process design or prove that two assets are equivalent [S2][S7].
Equipment, Procedure, and Process Options Compared
ISA-88 separates three concerns that are often conflated in batch projects: what the plant can do, what the product requires, and how the batch will be executed. The equipment model defines reusable plant capabilities, the recipe defines product targets, and the procedure model sequences the required work [S2][S7].
Equipment modules are appropriate for reusable physical capabilities such as mixing, heating, reaction, transfer, or discharge. Unit procedures are appropriate when a process step must coordinate several equipment modules and control states. Procedural phases are appropriate for bounded stages within an operation where equipment actions and process logic are tightly coupled [S5][S9].
This choice also clarifies an ownership boundary: changing an asset's internal control implementation does not necessarily require rewriting the product recipe, while changing a product requirement may require revising the procedure and its equipment mapping [S1][S7]. That separation reduces unnecessary configuration churn and makes deviations easier to identify during review and production execution.
Phase Execution Carries the Operational Audit Trail
Batch operations commonly include charging, heating, holding, reacting, cooling, and discharging, and ISA-88 represents these bounded activities through phases and their associated equipment procedures [S2].
In pharmaceutical manufacturing, every defined lot must be traceable through these execution stages. ISA-88 structures the batch documentation and operating records so that procedural results can be associated with the corresponding lot, equipment, recipe version, and phase [S2][S3]. MES integration adds visibility across production schedules, resource allocation, material consumption, inventory, and reporting [S4].
The audit trail remains useful only if phase boundaries are meaningful. A phase should represent a process state with identifiable start criteria, operating commands, equipment states, and completion conditions. Splitting a long operation into unnamed code fragments erodes the ISA-88 benefit even if the physical process still runs successfully [S2][S7].
Use ISA-88 for Modular Batch Logic, Not Every Workflow
ISA-88 is suited to finite quantities processed through defined sequences on shared or reusable equipment, including charge, mix, heat, react, cool, transfer, and discharge operations [S2]. It is also applicable beyond conventional process plants, such as composite curing, surface-treatment baths, heat-treatment cycles, and finite roll production [S2][S3].
It is not the right abstraction for continuous material flow with no discrete batch boundary, such as a large refinery or paper mill, or for one-off discrete fabrication where each item follows a unique route [S2]. ISA-88 also does not prescribe control algorithms, software architecture, programming languages, cybersecurity controls, or a particular plant-wide data model [S1][S2].
For MES projects, ISA-88 should therefore be used where procedural reuse and equipment mapping create measurable design value. Workflows such as laboratory scheduling, general document routing, and non-repeating administrative approvals belong elsewhere unless they directly govern a repeatable batch procedure. The batch controller is the natural execution boundary when procedural structure and PLC-level equipment control must remain coordinated.
Standards Coverage and Implementation Boundaries
ISA-88, also identified as ANSI/ISA-88.01-1995 and IEC 61512, provides models and terminology for batch control rather than a ready-made MES specification [S2]. ISA-95 supplies the broader automation hierarchy, and its Level 2, Level 3, and Level 4 divisions connect process control, manufacturing execution, and enterprise planning or logistics [S3][S4].
The equipment model and procedural model are the two principal standards-based structures for implementing batch process automation [S5][S8]. Their intended value is a consistent data structure that simplifies programming, configuration, and communication among components [S1]. MES implementations can extend that structure with production planning, real-time material tracking, inventory variance detection, production data, and batch reporting [S4].
Implementation specifications must still define the actual interfaces, responsibility matrix, master-data controls, recipe version rules, exception handling, electronic-record retention, and equipment allocation logic. ISA-88 does not remove those engineering tasks. It provides the shared model that makes those tasks explicit and reviewable across MES, automation, operations, and quality teams [S2][S7].
A verifiable next step is to map one production recipe against one target equipment line, naming every equipment module, unit procedure, operation, and phase. If that mapping can be reviewed without reading PLC code, the ISA-88 structure is doing useful engineering work; any undefined capability or orphaned phase identifies a concrete design gap.