Batch Sequencing on a PLC
— ISA-88 in Practice

Why ISA-88 Matters for Pharma Validation

ISA-88 (IEC 61512) is a batch control standard originally written for the chemical and food industries. It became the de facto standard for pharmaceutical batch automation because it solves a specific problem that regulators care about: how do you separate what the process requires (the recipe) from what the equipment does (the control programme), so that a recipe change can be assessed independently from an equipment change?

Without this separation, every recipe variation — a different active ingredient concentration, a different hold time, a different addition sequence — is a potential software change on a validated system. With ISA-88, the recipe is a data set. The equipment control programme is validated once. Recipe changes are managed through a separate recipe management procedure, not change control on the PLC code. This is one of the most significant risk reduction benefits ISA-88 provides on a pharma project.

GAMP 5 does not mandate ISA-88, but the validation framework maps naturally onto it. The URS process description maps to the ISA-88 procedural model. The FDS equipment design maps to the ISA-88 physical model. The recipe management requirement maps to ISA-88 recipe structure. Validating a batch system that does not follow ISA-88 structure is significantly harder — the traceability chain from URS to code becomes tangled.

The Three Models — Physical, Procedural, Recipe

ISA-88 describes a batch system using three models that operate at different levels of abstraction. Understanding what belongs in each model — and what does not — is the foundation of a correct implementation.

The Physical Model — Equipment Hierarchy in the PLC

The physical model maps directly to the FDS equipment design. A Process Cell contains one or more Units. Each Unit contains Equipment Modules and Control Modules. In the PLC, this hierarchy is reflected in the function block structure: the Unit function block (FB_Unit_Reactor01) calls Equipment Module function blocks (FB_EM_TIC101 for temperature control, FB_EM_LIC201 for level control), which in turn call Control Module function blocks (FB_CM_TT101 for the individual temperature transmitter).

The critical rule is that an Equipment Module has exclusive control of its Control Modules during a batch phase. The temperature control Equipment Module owns TT-101 and TIC-101 when the unit is running. Manual control from the HMI overrides this only through a defined mode structure — not by bypassing the Equipment Module. This exclusive control pattern is what allows each phase to be validated independently: you know exactly what is being controlled, by what, and under what conditions.

The Procedural Model — Operations and Phases in SFC

The procedural hierarchy — Procedure → Unit Procedure → Operation → Phase — maps to the SFC structure in the PLC. The Phase is the lowest-level procedural element and is the primary unit of validation. Each Phase is an SFC that implements a specific process action: Ramp (increase temperature from current value to setpoint at a defined rate), Hold (maintain temperature at setpoint for a defined duration), Cool (reduce temperature to defined endpoint), Add (execute a material addition at a defined rate and volume).

The Phase does not contain recipe parameters. It receives them as inputs. FB_Phase_Ramp takes as inputs: r_TargetTemp (the setpoint to ramp to), r_RampRate (degrees per minute), and r_TimeoutMin (abort if ramp not achieved within this time). All three values come from the recipe data block — they are not hardcoded in the Phase SFC. This is the implementation of the core ISA-88 principle.

Phase SFC Structure — States and Transitions

Each Phase SFC must implement the ISA-88 standard phase states to ensure consistent behaviour across all phases and consistent testability during OQ. The standard states are not optional — they are what makes phases interchangeable within an operation and what gives the batch system its hold, restart, and abort capabilities.

The HOLD state is frequently misunderstood. PAUSE is an operator-initiated suspension — the operator decides to pause a running sequence. HOLD is a system-initiated suspension triggered by a process exception, typically a GxP alarm that indicates an out-of-specification condition. The distinction matters for the OQ test cases: testing HOLD requires simulating an alarm condition that triggers the transition, not just pressing a pause button. The batch audit trail must record both transitions with the trigger reason.

Recipe Structure — Master Recipe and Control Recipe

The Master Recipe is the validated, version-controlled definition of a product's manufacturing process. It contains the procedural logic (the sequence of operations and phases), the formula (the process parameters that each phase receives), and the equipment requirements (which Process Cell and Units the recipe requires). The Master Recipe is a controlled document — it has a version number, it is approved before use, and changes to it go through a recipe change control procedure.

The Control Recipe is an instance of the Master Recipe that is created for a specific batch. When Batch B00247 starts, the system creates Control Recipe CR-B00247 from Master Recipe MR-API-003-v2.1. The Control Recipe captures the actual parameter values used, the actual start and end times of each phase, any deviations from expected parameter values, and the batch disposition outcome. The Control Recipe is the batch record — it is what the QA reviewer signs to release the batch.

Traceability — URS to Phase to OQ

The traceability chain for a batch phase runs: URS process requirement → FDS sequence description → SDS phase state machine design → PLC SFC implementation → OQ phase test case. This is the same traceability chain that applies to all GxP-critical PLC functions, but for batch systems it has an additional layer: the recipe parameter traceability.

Each recipe parameter — hold time, temperature setpoint, ramp rate, addition volume — must trace to a URS requirement that defines its valid range. The FDS process description specifies the nominal value and valid range. The Master Recipe stores the value within that range. The OQ verifies that the phase executes correctly with parameters at the nominal value and at the boundaries of the valid range. This boundary-value approach is the standard OQ methodology for recipe-driven phases.

The URS-to-FDS traceability for batch systems is often where gaps appear. The URS says "the system shall heat the product to 75°C ± 2°C." The FDS should translate this into: target setpoint 75°C, acceptable range 73–77°C, alarm at 77°C (H), alarm at 79°C (HH with interlock). If the FDS only says "temperature control" without specifying the setpoint range and alarm structure, the traceability from URS to validated alarm limits is broken.

OQ Approach for Batch Sequences

Testing a batch sequence in the OQ requires a different approach from testing a steady-state control loop. The OQ must verify the sequence under three conditions: normal execution (all phases complete successfully to COMPLETE state), exception handling (a simulated process alarm drives a phase to HELD and the resume and abort paths both work correctly), and boundary values (key recipe parameters set at the minimum and maximum of the validated range).

• Execute the full sequence with nominal recipe parameters — verify all phases reach COMPLETE state in correct order, all phase audit trail events generated with correct timestamps and recipe version reference
• Simulate a process alarm during a running phase — verify phase transitions to HELD, system executes safe-state actions (defined in FDS), audit trail records HELD transition with alarm ID as trigger reason
• From HELD state: test RESTART path — verify phase re-enters RUNNING correctly from the correct step, not from the beginning
• From HELD state: test ABORT path — verify phase reaches ABORTED state, safe-state actions complete, batch record flags phase as aborted with reason
• Execute critical phases with recipe parameters at validated minimum — verify phase completes within expected time with correct process behaviour
• Execute critical phases with recipe parameters at validated maximum — same verification
• Verify Master Recipe version is locked into the Control Recipe at batch start and cannot be modified during execution
• Verify batch record (Control Recipe) contains all required fields: actual parameter values, phase start/end times, operator IDs, any deviations