ISA-88 Batch Control: Recipe Management, the Physical and Procedural Models, and MES/Digital Twin Integration (2026)

Every batch plant eventually meets the same quiet disaster: the recipe lives inside the control code. A change to a hold temperature means a PLC download, a revalidation, and a prayer that the next product on the same reactor still behaves. Multiply that by forty products and three sites and the plant is no longer a factory, it is a software maintenance contract. ISA-88 batch control exists to break that coupling. It separates what to make (the recipe) from what can make it (the equipment) and gives both a shared vocabulary of models, so a recipe can be authored, versioned, simulated and executed without rewriting control logic.

In 2026 that separation matters more, not less. Digital twins, virtual commissioning and MES-driven scheduling all assume that process knowledge is a data structure rather than a code path. ISA-88 is the oldest and most battle-tested way to make it one.

What this covers: the physical and procedural models, the four recipe types, equipment phases and their state machine, arbitration, batch records, the ISA-95 and B2MML interface, digital twin use, runnable Python and YAML sketches, and the failure modes that actually hurt.

Context and Background

ANSI/ISA-88, usually shortened to S88, was approved by ISA in 1995 and updated in 2010. The original Part 1 was adopted by the IEC in 1997 as IEC 61512-1, and the IEC 61512 series tracks the ANSI/ISA parts closely. As the Wikipedia summary puts it, it is a design philosophy for describing equipment and procedures rather than a software standard, and it applies equally to manual processes. That framing is the first thing practitioners misread. There is no S88 runtime, no S88 protocol, and no certification that makes a product “S88 compliant” in a binding sense. What you get is a set of models and a terminology you can implement on any platform.

The standard family, per ISA’s own listing, has four published parts: ISA-88.00.01 (Part 1, Models and Terminology, 2010), ISA-88.00.02 (Part 2, Data Structures and Guidelines for Languages, 2001), ISA-88.00.03 (Part 3, General and Site Recipe Models and Representation, 2003) and ISA-88.00.04 (Part 4, Batch Production Records, 2006). A related technical report, ISA-TR88.00.02, describes machine and unit states as an implementation example; it is the lineage behind PackML. Part 1 gives you the models. Part 2 gives you data structures for the information exchanged. Parts 3 and 4 deal with recipe representation and the production record.

The problems S88 set out to solve are still the problems on the floor: no universal batch control model, difficulty communicating user requirements, poor integration between batch automation suppliers, and painful batch-control configuration. Before S88, every DCS vendor had its own idea of a “sequence”, and a recipe written for one system was a rewrite on another. Today the incumbents are the large DCS and MES suites, plus a long tail of PLC-based batch engines and in-house frameworks. They differ in tooling, but the good ones all expose the same shapes: a recipe editor, a batch engine, equipment arbitration, and a batch record.

Where S88 sits relative to its neighbours is worth pinning down. ISA-95 describes the interface between enterprise systems and manufacturing control, the “what is scheduled, what was produced” layer. S88 describes the control and recipe layer underneath it. PackML, an OPC Foundation-published state model for packaging machines, extends S88 ideas into discrete machinery: per the OPC 30050 PackML overview, it assumes a machine can represent the ISA-88 unit level. The three standards are complementary, and a modern plant design uses all of them without confusing their jobs.

The thesis of this article is narrow and practical. S88 is best understood not as a modelling exercise but as a set of contracts: between recipe author and equipment engineer, between batch engine and controller, between MES and plant, and between plant and its digital twin. Where the contract is crisp, changes are cheap. Where it is vague, the plant leaks risk. The rest of this article walks the contracts one at a time.

The ISA-88 Reference Architecture: Two Models and Four Recipes

In short: ISA-88 batch control splits a plant into a physical model (enterprise down to control module) and a procedural model (procedure down to phase). Recipes, in four flavours from general to control, reference equipment by requirement, not by tag. A batch engine binds recipe to equipment at run time, so the same recipe can run on any capable unit.

Figure 1: The ISA-88 physical model, drawn with one process cell holding two units, their equipment modules and control modules.

Figure 1 shows the hierarchy. The long description: an enterprise contains sites, sites contain areas, an area contains process cells, a process cell contains units, a unit contains equipment modules, and an equipment module contains control modules. In the example, the cell holds a reactor and a blender; the reactor owns a dosing module and a jacket-temperature module; each of those owns the valves and instruments that implement it.

The physical model: who can do what

The physical model runs enterprise, site, area, process cell, unit, equipment module, control module. The standard allows some levels to be omitted, but not the unit. That asymmetry is deliberate. The unit is the pivot of the whole architecture: it is the thing a batch occupies. A reactor, a blender, a filling vessel and a centrifuge are units. A unit is a collection of equipment and control that can carry out one or more major processing activities, and, crucially, it processes one batch at a time. That single-occupancy rule is what makes allocation and arbitration tractable later.

Below the unit sit equipment modules (EMs), which carry out a finite set of minor activities: dosing a charge, controlling jacket temperature, running agitation. An EM is a functional grouping with its own control, and it is where reusable control code concentrates. Control modules (CMs) are the lowest level that does basic control, such as one valve with its feedback, one PID loop, one motor. If you have ever written a valve function block with open and closed limit switches, interlocks and a manual override, you have written a control module.

A practical design heuristic: draw unit boundaries around the equipment that must be allocated as a whole, and draw EM boundaries around what you want to reuse across units. If two reactors dose through the same skid, the skid is a shared resource and not part of either unit, which pushes you towards a shared-resource arbitration design rather than copy-pasted modules.

The procedural model: how a batch proceeds

The procedural control model nests four levels: procedure, unit procedure, operation, phase. A procedure is the strategy for a whole batch, spanning units. A unit procedure is a sequence of operations on one unit. An operation is an independent processing activity within a unit, such as “charge and heat”. A phase is the smallest element of procedural control that accomplishes a process-oriented task, such as “add ingredient” or “agitate”. Levels can be left out when they add nothing, so a small plant may run procedures that go directly from unit procedure to phase.

The relationship between the two models is the key architectural idea, and it is worth saying slowly. The procedural model is recipe-side: it lives in the recipe and says what steps to perform. The physical model is equipment-side: it lives in the controller and says what can be done. The bridge is the phase. A recipe phase is a request, “add ingredient A, 500 kg, at 40 kg per minute”. The equipment phase is the controller-side implementation of that request, usually code that drives one or more equipment modules. Recipe says what; equipment phase says how. The recipe never touches a valve.

The four recipe types

S88 defines four recipe types that form a refinement chain, drawn in Figure 2.

Figure 2: The four S88 recipe types and the procedural hierarchy that every recipe carries, ending in the batch record.

A general recipe is enterprise-level and equipment-independent. It expresses process knowledge in terms of materials and process stages, often written by R&D or corporate process engineering, and it can be shared across sites. A site recipe adapts the general recipe to a specific site, accounting for local raw materials, regulations and the site’s equipment classes. A master recipe is targeted at a process cell or a class of equipment within it; it is the first recipe type that is directly executable in principle, and it is what most people mean by “the recipe” in day-to-day batch work. A control recipe is a copy of the master recipe, instantiated for one specific batch, with the formula values and equipment bound for that run. It is created at batch start and it is the thing the batch engine actually executes. Think of the master recipe as a class and the control recipe as an object.

Every recipe, whatever its type, carries the same content blocks: a header (identification, version, status, author, approval), a formula (process inputs, parameters and outputs), equipment requirements (the constraints on equipment that can run it), the procedure (the sequence of steps), and other required information. The formula-versus-procedure split is one of the most useful ideas in the standard. The procedure is the shape of the process; the formula carries the numbers. Two products that differ only in quantities and setpoints can share one procedure with two formulas, which is why a mature plant has far fewer procedures than products.

Why recipes reference equipment by requirement

Equipment requirements deserve emphasis because they are what makes a master recipe portable. A well-formed master recipe does not say “use R-101”. It says “needs a jacketed vessel of at least 8,000 litres, agitated, rated for 6 bar”, and the batch engine finds a unit that satisfies that at run time. This is the same idea as a Kubernetes pod requesting CPU and memory rather than a named node. It buys you load balancing across identical reactors, graceful degradation when one is down for maintenance, and the ability to qualify a new unit by proving it meets the requirement set. It costs you a discipline: the equipment model must be accurate enough that “capable of” is a computable predicate.

Phases, States and Arbitration: The Runtime Mechanics

An equipment phase is where S88 stops being a diagram and becomes a state machine. The batch engine does not call a phase like a function. It sends commands, and the phase answers with states, because a phase can take minutes or hours and must remain controllable the whole time. The recurring design question is who owns the state: the answer is that the equipment phase owns it, and the batch engine only requests transitions.

The phase state model

Part 1 of the standard describes a state model for procedural elements, and the commonly used set is: idle, running, complete, pausing, paused, holding, held, restarting, stopping, stopped, aborting and aborted. Acting states (names ending in -ing) are transient: the phase is actively doing something, such as ramping a valve closed, and will move on by itself when that finishes. Waiting states (idle, complete, held, stopped, aborted) are stable: the phase stays put until a command arrives. Figure 3 shows the core of it.

Figure 3: The core S88 equipment phase state model. Acting states move on by themselves; waiting states need a command. Pausing and paused are omitted for clarity.

The commands are small in number: start, hold, restart, stop, abort and reset. They are deliberately severity-ordered. Hold means “stop adding value but be ready to continue”: the phase brings the equipment to a safe, resumable condition and waits. Stop means “finish in an orderly way and do not continue”; the phase winds down to a known state. Abort means “get safe now, I accept the consequences”, and it may be issued from nearly any state, including from held and from stopping. The abort path is the one operators reach for in an emergency, so it must never depend on anything fragile.

Hold deserves particular attention because it is where batch automation earns its keep. A hold is not a failure state. A feed pump trips, a sample result is late, a downstream tank is full: the right response is to freeze the batch at a defined point, keep agitation and temperature safe, and let a person or the MES decide. Good phase designs define hold behaviour per phase: what stays on, what closes, and what restart means. A heating phase restarts by re-evaluating temperature; a timed phase has to decide whether elapsed time is preserved. The restart logic is the part most often left as an afterthought and most often wrong.

Relation to PackML

PackML’s state model is a close cousin, which is no accident: PackML grew from S88 ideas. The OPC 30050 specification states its goals as a standard state-based model for automated machines, a common terminology, and a common tag structure that supports interoperability and consistent connections to MES and enterprise systems. It treats a machine as the S88 unit level. The practical differences: PackML names include starting, execute, completing, resetting and suspending states and is tuned for continuously running machines with throughput targets, while the S88 phase model is tuned for finite tasks that complete. In a hybrid plant, for instance a batch syrup process feeding a packaging line, you will see both: S88 phases upstream, PackML machines downstream, and an MES that must translate between the two vocabularies. Treat the exact state lists as a detail to confirm against the edition your vendors implement. The structure, not the spelling, is what transfers.

A runnable phase state machine in Python

The following sketch implements an equipment phase as an explicit state machine with a transition table. It is deliberately small, but it captures the two properties that matter: illegal commands are rejected loudly, and acting states complete via an explicit tick, which in a real controller is your scan cycle or an event from the equipment module.

from enum import Enum, auto

class State(Enum):
    IDLE = auto(); RUNNING = auto(); COMPLETE = auto()
    HOLDING = auto(); HELD = auto(); RESTARTING = auto()
    STOPPING = auto(); STOPPED = auto()
    ABORTING = auto(); ABORTED = auto()

class Cmd(Enum):
    START = auto(); HOLD = auto(); RESTART = auto()
    STOP = auto(); ABORT = auto(); RESET = auto()

# command-driven transitions: (state, command) -> next state
CMD = {
    (State.IDLE, Cmd.START): State.RUNNING,
    (State.RUNNING, Cmd.HOLD): State.HOLDING,
    (State.HELD, Cmd.RESTART): State.RESTARTING,
    (State.COMPLETE, Cmd.RESET): State.IDLE,
    (State.STOPPED, Cmd.RESET): State.IDLE,
    (State.ABORTED, Cmd.RESET): State.IDLE,
}
for s in (State.RUNNING, State.HOLDING, State.HELD, State.RESTARTING):
    CMD[(s, Cmd.STOP)] = State.STOPPING
for s in State:
    if s not in (State.ABORTING, State.ABORTED, State.IDLE):
        CMD[(s, Cmd.ABORT)] = State.ABORTING

# automatic transitions out of acting states, taken on tick()
AUTO = {
    State.HOLDING: State.HELD,
    State.RESTARTING: State.RUNNING,
    State.STOPPING: State.STOPPED,
    State.ABORTING: State.ABORTED,
}

class EquipmentPhase:
    def __init__(self, name, work_ticks):
        self.name, self.state = name, State.IDLE
        self.work_left, self.work_total = work_ticks, work_ticks
        self.log = []

    def command(self, cmd: Cmd):
        nxt = CMD.get((self.state, cmd))
        if nxt is None:
            raise ValueError(f"{cmd.name} illegal in {self.state.name}")
        self._go(nxt)

    def tick(self):
        if self.state in AUTO:                 # acting state finishes
            self._go(AUTO[self.state])
        elif self.state is State.RUNNING:      # do the actual work
            self.work_left -= 1
            if self.work_left <= 0:
                self._go(State.COMPLETE)

    def _go(self, nxt):
        self.log.append((self.state.name, nxt.name))
        self.state = nxt

if __name__ == "__main__":
    p = EquipmentPhase("ADD_INGREDIENT_A", work_ticks=3)
    p.command(Cmd.START); p.tick()
    p.command(Cmd.HOLD);  p.tick()        # HOLDING -> HELD
    p.command(Cmd.RESTART); p.tick()      # RESTARTING -> RUNNING
    p.tick(); p.tick()                    # finish work
    print(p.state.name, p.log)

Note the design decisions. Work progress (work_left) survives a hold, so restart resumes rather than repeats; a phase that must restart from scratch would reset it. Abort is allowed from every state except the ones already aborting, aborted or idle, which mirrors the standard’s intent that abort is globally available. In production, the same table would live in the controller, typically as a PLC function block with an enumerated state tag, and the batch engine would write command bits and read state values.

Recipe Data Model and Equipment Arbitration

Recipes are data, so they deserve a schema. A defensible minimum for a master recipe is shown below as dataclasses; the equivalent YAML follows. The intent is to show the separation of procedure, formula and equipment requirements, not to prescribe a vendor format. Part 2 of the standard defines data structures and guidelines for recipe languages, and the MESA BatchML schemas are an XML implementation of ISA-88 for exchange, but most plants keep an internal model like this one and map to the standard format at the boundary.

from dataclasses import dataclass, field
from typing import Literal

@dataclass(frozen=True)
class Parameter:
    name: str
    value: float
    unit: str
    low: float | None = None     # allowed range, enforced at batch creation
    high: float | None = None

@dataclass(frozen=True)
class Requirement:
    equipment_class: str          # e.g. "JacketedReactor"
    min_volume_l: float | None = None
    properties: tuple[str, ...] = ()   # e.g. ("agitated", "6bar")

@dataclass(frozen=True)
class PhaseStep:
    id: str
    equipment_phase: str          # name of controller-side phase class
    parameters: tuple[Parameter, ...] = ()

@dataclass(frozen=True)
class Operation:
    id: str
    steps: tuple[PhaseStep, ...]

@dataclass(frozen=True)
class UnitProcedure:
    id: str
    requirement: Requirement
    operations: tuple[Operation, ...]

@dataclass(frozen=True)
class MasterRecipe:
    recipe_id: str
    version: str
    status: Literal["draft", "approved", "retired"]
    approved_by: str | None
    product_id: str
    unit_procedures: tuple[UnitProcedure, ...]

recipe_id: SYRUP-A
version: "4.2"
status: approved
approved_by: qa.lead
product_id: P-1042
unit_procedures:
  - id: UP-REACT
    requirement: {equipment_class: JacketedReactor, min_volume_l: 8000,
                  properties: [agitated]}
    operations:
      - id: OP-CHARGE-HEAT
        steps:
          - id: PH-ADD-A
            equipment_phase: AddIngredient
            parameters:
              - {name: mass, value: 500, unit: kg, low: 480, high: 520}
              - {name: rate, value: 40, unit: kg/min}
          - id: PH-HEAT
            equipment_phase: HeatToTemp
            parameters:
              - {name: setpoint, value: 72, unit: degC, low: 70, high: 75}

Three details here carry real weight. Records are immutable (frozen=True) because an approved recipe version must never change; edits create a new version. Parameter ranges are part of the recipe, so a control recipe can be validated at creation time, before any equipment is committed. And the equipment phase is referenced by name, never by code, which is exactly the contract between recipe and controller: the controller must publish a phase library with typed parameter interfaces, and recipes may only call what exists.

Creating a control recipe

When an order arrives, the batch engine copies the master recipe into a control recipe, binds the formula values (scaled to batch size, for instance), and checks every parameter against its range. Scaling is a useful worked example. Illustrative numbers: a master recipe defined for a 10,000-litre batch adds 500 kg of ingredient A. An order for 8,000 litres gives a scale factor of 0.8 and a target of 400 kg, which falls below the 480 kg lower bound in the YAML above. The engine must reject or flag it, because the range was set for a validated process window; the right fix is a new, separately validated formula rather than a looser range. This is the sort of check that keeps scale-up arithmetic from becoming a quality deviation.

Equipment arbitration and allocation

A single batch rarely owns equipment for its whole life, and a plant rarely runs a single batch. Arbitration is the mechanism by which the batch engine claims and releases units and shared resources. S88 treats the relationships between a batch and its equipment as allocations: a batch acquires a unit, either for a unit procedure or for a longer period, and no other batch may use it while it is held. Equipment may be allocated in two common ways: dynamic allocation by capability at run time (as described earlier) or static allocation where the order names the unit.

Shared resources are where the trouble starts. Consider a charge skid used by reactors R-101 and R-102, and a transfer line from either reactor to a blender V-201. If batch 1 holds R-101 and waits for the skid while batch 2 holds the skid and waits for R-101, you have a classic deadlock. The cure is not a smarter engine but a rule: acquire resources in a global order, or acquire all of a unit procedure’s resources atomically, or use a timeout that releases and retries. Atomic acquisition costs utilisation, because resources sit reserved while the batch waits for the last one; ordered acquisition costs flexibility. Most plants pick atomic acquisition per unit procedure and accept the utilisation hit as the price of predictability.

A second subtlety is the lifetime of an allocation. A unit may need to stay reserved through a hold, because releasing a half-processed reactor to another batch is nonsense. So allocation must be tied to the batch, not to the phase’s running state. A hold must keep its equipment; an abort must release it only after the equipment has reached a safe state and been cleaned or marked dirty. That last step ties arbitration to the equipment’s own status model, such as clean, in use, dirty and cleaning. Plants that skip this end up with mislabeled equipment and cross-contamination in the genealogy.

Batch Records, Genealogy and the MES/Digital Twin Integration

The execution side of S88 produces a second artefact besides product: evidence. Part 4 of the standard concerns batch production records, and in regulated industries the record is as important as the product, because a batch that cannot be documented cannot be released.

What a batch record contains

A batch record is the history of one control recipe’s execution. At minimum it captures which recipe version ran, which unit and equipment modules were allocated, the actual parameter values achieved against their targets, the material lots consumed and produced, every operator action and acknowledgement, every state transition of every phase (including holds and their durations), alarms and deviations, and timestamps tied to a trusted clock. The records exist at three levels of resolution: a summary suitable for release review, a phase-level log, and the underlying historian time series for process variables.

Genealogy is the derived structure. If batch B consumed lot L1 of ingredient A and produced lot P1, genealogy links L1 to P1 through B. Forward traceability answers “which finished lots contain this suspect raw material lot”; backward traceability answers “what went into this complaint lot”. Both queries are graph traversals, and a recall exercise that takes hours instead of days is almost always the result of recording lot IDs at the phase level, when material is actually charged, rather than reconstructing them from the order afterwards. Capture the lot at the moment of the phase event, with the scale or flow meter totaliser value, and genealogy becomes a join rather than an investigation.

The ISA-95 and B2MML interface

Batch execution rarely stands alone. The MES above it schedules, dispatches and collects, and ISA-95 defines the vocabulary of that exchange. The ISA-95 and ISA-99 guide covers the level model in detail; for batch the important point is the division of labour. The MES owns orders, schedules, material definitions and results. The batch engine owns recipe execution and equipment sequencing. Neither should reach into the other’s domain.

The common exchange format is B2MML, an XML implementation of the ISA-95 family (also standardised internationally as IEC/ISO 62264), published by MESA International alongside BatchML, the XML implementation of ISA-88 (IEC 61512). Both ship as XML schema (XSD) files, per the MESA B2MML-BatchML repository. The repository page does not state a version number or name the licence in the text I could retrieve, so check the current release and terms before building on it. A typical flow: ERP creates a production order; the MES converts it to a production request in B2MML with a product, quantity and due time; the batch engine accepts it, selects the master recipe, creates a control recipe and reports back production performance, including consumed and produced material lots and actual quantities. B2MML is a format, not a protocol, so it travels over whatever transport you already run, whether web services, message queues or file drops.

The pragmatic gotcha is semantic drift. B2MML gives you a place to put a “segment” or a “material lot”, but it does not decide whether your MES “operation” is the same thing as an S88 operation. In practice they often are not: an ISA-95 production segment tends to be coarser than an S88 phase. Write down the mapping explicitly, one page, and put it under version control. Most integration bugs I have seen in batch MES projects were vocabulary mismatches that survived design review because everyone used the same words.

OPC UA and the machine boundary

Between the batch engine and the controller the interface is typically either a vendor-native link or OPC UA. S88 itself prescribes no transport, so any claim that a particular OPC UA companion specification “is” the S88 interface should be checked against its text. What I could verify is narrower: the OPC Foundation’s PackML specification (OPC 30050, version 1.01 shown on the reference site) defines a standard state-based model and tag structure for machines, mapped to the S88 unit level, for connection to MES. For batch process units I did not find a dedicated OPC UA companion specification for S88 phases in this research, so I will not name one. A sound pattern regardless of vendor is to expose each equipment phase as a small information-model object with a command input, a state output, typed parameters and a status structure, and to subscribe to state changes instead of polling.

Where the digital twin fits

An ISA-88 digital twin is useful precisely because S88 already separates recipe from equipment. That separation turns the twin from a bespoke simulation into a swap-in: replace the physical equipment-phase layer with simulated phases that speak the same interface, and the same recipes and batch engine run unchanged. Figure 4 shows the architecture.

Figure 4: A vendor-neutral architecture in which the batch engine drives either real equipment phases or a digital twin through the same phase interface.

Three use cases justify the effort. First, virtual commissioning: before the plant is built or modified, the real phase code runs against a simulated equipment model, exposing interlock errors, missing hold behaviour and bad sequencing while changes are still cheap. The value is highest for hold, restart and abort paths, which are tedious to test on a live plant and are exactly where defects hide. Second, recipe simulation: new or changed master recipes run against the twin to check timing, utilisation and parameter feasibility before a trial batch consumes real material. For a campaign, that means estimating cycle time and unit utilisation to see whether a schedule is achievable. Third, operator training and what-if analysis, such as testing how a 20 minute hold on a reactor ripples through downstream allocations.

Illustrative numbers: suppose a reactor cycle is 6 hours, of which heating is 90 minutes. A twin that models the jacket with a first-order lag can show that a revised heating setpoint shortens the phase by perhaps 10 minutes, but also that it pushes the cooling phase start into a window where the shared chilled-water loop is saturated. The gain disappears unless the twin includes the shared utility, which is why twin scope should follow allocation boundaries, not just unit boundaries. These figures are for illustration only; they are not measurements.

The fidelity question is the honest limit of the approach. A twin that reproduces sequencing and timing is cheap and very valuable. A twin that predicts reaction yield needs validated process models, and those are a research programme, not an integration task. State which one you are building. The digital twin and MES reference architecture discusses the broader layering, and the same discipline applies: keep the twin’s interface identical to the plant’s so that confidence transfers.

Closing the loop matters as much as the forward path. Batch records and historian data are the training and calibration set for the twin, and the twin’s predictions are only trustworthy where they have been compared with real batches. The OEE architecture article describes how to derive availability and performance from the same state transitions; for batch plants, hold durations and unit idle time in the phase log are the raw material for it.

Trade-offs, Gotchas, and What Goes Wrong

S88 is not free, and some of its costs are rarely admitted in vendor material.

Over-modelling. The standard permits omitting levels, and small plants should use that. A single-unit plant with six products does not need a general-to-control recipe chain, an arbitration engine and a full genealogy graph. Adopting the whole stack for a simple process yields engineering cost without flexibility benefit. The honest test: will you ever run the same recipe on a different unit, or the same unit under a different recipe? If neither, a well-structured sequence may be enough.

Recipe versioning. The most common serious failure is a recipe that changes underneath a running batch, or an approved version that is silently edited. The control recipe must be an immutable snapshot taken at batch start, referencing recipe ID and version, so that a batch always finishes on the logic it began with. The opposite error is as bad: pinning a batch to an old equipment phase library after the controller code was updated. Version the phase library with the same rigour as recipes and record both in the batch record. A recipe approved against phase library 3 and executed against library 4 is a validation gap.

Allocation deadlock and starvation. Described above, but it deserves a second warning: deadlock appears only under concurrency, so a plant that tests one batch at a time will commission cleanly and deadlock in its first busy week. Test with concurrent synthetic batches, ideally on the twin.

Hold handling. Three recurring mistakes. Phases that treat hold as stop, losing process state. Phases whose restart logic is untested, since restart is rarely exercised. And holds that outlive their safety envelope: a held reactor with a degrading product needs a maximum hold time, after which the engine escalates automatically. Without a timeout, “held” quietly becomes “abandoned”.

State-model mismatch. A batch engine and a controller from different vendors may implement slightly different state sets or different meanings for “complete”. If the engine sees “stopped” where the controller means “aborted”, the batch record is wrong and the recovery action may be unsafe. Contract tests against the phase interface catch this early.

Boundary pollution. Control code that quietly implements recipe logic (hard-coded quantities, product-specific branches inside an equipment phase) defeats the entire architecture. A code-review rule helps: an equipment phase may contain no product names and no magic numbers beyond safety limits.

Data volume and clock issues. Phase-level logging is cheap; high-rate process data is not. Decide up front which signals go into the batch record and which stay in the historian with a pointer, and synchronise clocks across engine, controllers and historian, otherwise reconstructed timelines contradict each other.

Practical Recommendations

Start from the boundary, not the diagram. Before drawing any recipe, write the phase library as an interface: names, typed parameters, states, hold and restart semantics, and the faults each phase can report. Everything else, recipes, simulation, MES mapping, depends on that contract being stable. Treat it as a versioned API, with a changelog and compatibility rules.

Then model only what you will use. Define units first and make them accurate, since they determine allocation. Add equipment modules where reuse is real. Add recipe levels when a second site or product family demands them. Keep formula and procedure separate from day one; it is cheap now and very expensive to retrofit.

Make safety and hold behaviour a design review item, with per-phase documentation of what each phase does on hold, stop and abort, and test those paths first on the twin. Capture lots and quantities at the phase event. Keep the MES-to-batch vocabulary mapping in one reviewed document. Finally, make the twin a first-class tenant of the architecture rather than a project: if the batch engine cannot target simulated phases through the same interface, you will never get the benefits.

Checklist:

• [ ] Units are defined and each is allocated to one batch at a time.
• [ ] Phase library published as a versioned interface with typed parameters.
• [ ] Each phase documents hold, restart, stop and abort behaviour, with a maximum hold time.
• [ ] Formula and procedure are separate; approved recipes are immutable and versioned.
• [ ] Control recipe snapshots recipe and phase library versions at batch start.
• [ ] Parameter ranges validated at control recipe creation, including scale-up.
• [ ] Resource acquisition rule defined (atomic or ordered) and tested with concurrent batches.
• [ ] Lots captured at phase event; forward and backward genealogy queries rehearsed.
• [ ] ISA-95/B2MML vocabulary mapping written and under version control.
• [ ] Twin targets the same phase interface as the plant, and is calibrated on batch records.

Frequently Asked Questions

What is ISA-88 batch control?

ISA-88 batch control is a family of standards, adopted internationally as IEC 61512, that defines models and terminology for batch manufacturing. It describes a physical model of equipment, a procedural model of process steps, and recipe types that link them. Its central idea is separating recipes from equipment, so process knowledge is reusable data and control code implements generic equipment capabilities. It is a design philosophy, not a software product or protocol.

What is the difference between a master recipe and a control recipe?

A master recipe targets a process cell or class of equipment and defines the procedure, formula and equipment requirements for a product. A control recipe is a copy of the master recipe created for one specific batch, with the formula values, scaling and equipment bound for that run. The batch engine executes the control recipe. The master is like a class; the control recipe is an instance, and it should be an immutable snapshot.

What is an equipment phase in S88?

An equipment phase is the controller-side implementation of a recipe phase. The recipe phase says what to do, such as adding 500 kg of an ingredient; the equipment phase contains the control logic, usually driving one or more equipment modules, that does it. It exposes commands and states such as start, hold, restart and abort, so the batch engine can control it without knowing about individual valves or instruments.

How does ISA-88 relate to ISA-95 and B2MML?

ISA-95 defines the interface between enterprise systems and manufacturing control, covering orders, schedules, materials and results. ISA-88 defines recipe and batch execution inside the control layer. B2MML is MESA’s XML implementation of ISA-95, and BatchML is its XML implementation of ISA-88. In a typical flow the MES sends a production request in B2MML, and the batch engine executes the recipe and returns production performance, including material lots.

How does ISA-88 differ from PackML?

PackML extends ISA-88 ideas to discrete packaging machines, treating a machine as the S88 unit level and defining a standard state model and tag structure, now also published as an OPC UA specification (OPC 30050). S88 phase models are designed for finite batch tasks that complete, while PackML targets continuously running machines with throughput goals. Hybrid plants often use S88 upstream and PackML downstream, with the MES translating between them.

How do you use a digital twin with ISA-88?

Because S88 separates recipe from equipment, a twin can replace the real equipment phases with simulated ones behind the same interface. The same batch engine and recipes then run unchanged. This supports virtual commissioning of hold and abort logic, recipe simulation for timing and utilisation, concurrency testing for deadlocks and operator training. Fidelity is the limit: sequencing twins are cheap, while yield-predicting twins require validated process models.

Further Reading

• ISA-95 and ISA-99 standards: complete technical guide
• Digital twin and MES: manufacturing execution reference architecture (2026)
• OEE architecture: MES, IIoT and the data model (2026)
• ISA-88 standards listing, ISA
• OPC 30050 PackML, OPC Foundation reference
• B2MML and BatchML, MESA International

By Riju — about