Operation Phase

In the ISA‑88 Procedural Model, a Process Cell Procedure is decomposed into Unit Procedures, which contain Operations, and Operations are realized by one or more Phases. A Phase is the smallest, executable, state‑driven unit of automated work (e.g., Charge Material, Heat to Setpoint, Agitate, Transfer). An Operation is a logical grouping of Phases to achieve a unit‑level objective (e.g., Heat and Hold, Wash, Granulate). When practitioners say “Operation Phase,” they typically mean a concrete Phase instance invoked by a given Operation, with the Operation supplying context, parameters, and inter‑phase sequencing.

Operation Phases are where MES (ISA‑95 Level 3) meets control (Levels 2/1): MES commands a Phase start with parameter sets, observes its state machine (Running/Hold/Abort/Complete), logs quality‑critical data, and reacts to exceptions. Control systems (SCADA/PLC/DCS) implement the Phase logic in an equipment module, enforce permissives and interlocks, and report status and results. This boundary is central to electronic batch record (eBMR/eDHR) completeness, data integrity, and recipe portability across equipment.

ISA‑88 defines the procedural hierarchy and the concept of an executable Phase hosted in an equipment module; the Phase State Model formalizes run/hold/stop/abort behavior with defined entry/exit conditions. ISA‑95 locates MES at Level 3 and specifies interfaces for production operations management, including how production rules, schedules, and performance are exchanged with Level 2 control. Together, they prescribe a clean partition: recipes and orchestration at Level 3; deterministic execution at Levels 2/1.

Regulatory overlays require that Operation Phases be versioned, parameterized, and audit‑trailed. 21 CFR 211.188 requires complete batch production and control records; 21 CFR Part 11 and EU GMP Annex 11 expect controls for electronic records/signatures, audit trails, validation, and data integrity. ISPE GAMP 5 advocates a risk‑based, lifecycle approach, typically treating MES configurations as Category 4 and custom control logic (PLC/phase code) as Category 5, with commensurate verification and change control.

• ISA‑88: defines Operations vs. Phases and the Phase State Model
• ISA‑95: defines Level 3–Level 2 integration responsibilities
• 21 CFR Part 11 / Annex 11: electronic records, audit trails, validation
• 21 CFR 211.188: batch/eDHR requires complete, contemporaneous records

Choosing the right granularity is the core architectural decision. Phases should encapsulate atomic, equipment‑bound actions with a clear state model and deterministic I/O (e.g., a Charge Phase that opens a specific valve to a weighed hopper, verifies flow, reconciles mass, and closes). Operations sequence such phases to fulfill a unit objective. Parameterize Phases (targets, tolerances, materials, routes, times, PID setpoints) rather than proliferating near‑duplicate phase code; establish a Phase Class Library with strict versioning and backward compatibility rules.

Names must reflect intent and constraints (Charge_LIQ_V1; HeatToSP_PIDv2; Transfer_Filtered). Inputs/outputs should be typed, with units and limits enforced at the interface. Explicitly model manual sub‑steps (e.g., visual verification) either as MES electronic work instructions linked between Phases or as separate Manual Phases with their own state machines and e-signatures where required. This modularity supports recipe portability and lowers the cost of change control.

Each Operation Phase must implement a robust state machine: Idle → Starting → Running → (Hold/Restart) → Complete, with Abort, Stop, and Failure paths. Entry to Running should validate permissives (e.g., valve closed, path verified, correct tool installed, environmental limits, material available), and interlocks must be energized to safely block conflicting actions. Hold should be bumpless where possible (e.g., hold agitation without losing PID context). Abort must force a defined safe state and preserve diagnostic data for root cause analysis.

MES should expose operator‑driven state transitions with appropriate authorization, reason codes, and two‑person e-signatures when risk‑justified. Exception flow is best designed as structured outcomes (Complete_OK, Complete_Warn, Failed_Sensor, Aborted_Operator, Aborted_Interlock) to drive conditional recipe branches and post‑processing (e.g., deviation initiation). Clearly distinguish retriable vs. non‑retriable faults to avoid unsafe cycling.

• Permissives: preconditions required before Phase start
• Interlocks: safeguards against hazardous or conflicting actions
• Hold/Resume: controlled pause with context retention
• Abort: forced termination to a safe state with preservation of evidence

An Operation Phase is the natural unit for GMP data capture: parameter sets (who/when set), start/stop timestamps, actuals (e.g., achieved temperature profile, delivered mass/volume), alarm and interlock history, operator interventions, signatures, and equipment IDs/states. Record data with context keys: Batch/Order ID, Unit, Operation/Phase IDs and versions, Material Lots, Asset/Tooling IDs, and environmental qualifiers. Time‑sync to a trusted time source to make chronological reconstruction reliable across Level 3/2/1 systems.

21 CFR 211.188 requires complete batch production and control records; Part 11/Annex 11 require validated systems, secure audit trails, and e-signature controls. Ensure the audit trail covers parameter changes, state transitions, exception handling, and recipe/phase version selection. When Phases include sampling or in‑process testing, integrate LIMS results to close the loop before the next phase proceeds, or enforce holds until acceptance criteria are met.

At the MES–control boundary, use stable, versioned interfaces. MES dispatches a Phase Start command with a Phase ID and a parameter block; control acknowledges, publishes state changes, and returns results on completion. Interfaces can be SCADA tags/OPC UA nodes, message queues, or vendor APIs, but all should be specified with strict typing, units, and enumerations for states and outcomes. Align message correlation with Batch/Order and Phase Instance IDs to ensure deterministic genealogy.

ISA‑95 recommends separating What (Level 3 orchestration) from How (Level 2 execution). Consider a thin translation layer to decouple MES recipe semantics from control tag naming. Harden the interface per NIST SP 800‑82: authenticate endpoints, authorize by least privilege, encrypt as feasible, monitor for anomalous patterns, and design for fail‑safe behavior (e.g., command idempotency and timeouts).

Following GAMP 5, treat MES recipe configurations (Operations, parameter sets, inter‑phase logic) as Category 4 and custom control logic implementing Phases as Category 5. Establish a traceable chain from URS through risk assessment to test protocols (IQ/OQ/PQ). Verify Phase State Model behavior under normal and exception conditions, including Hold/Resume timing, Abort safe states, alarm handling, and data logging completeness. Negative tests (e.g., missing permissive) must demonstrate safe rejection and clear operator guidance.

Change control should explicitly version Phase Class Library objects and their interfaces. Any change to a Phase’s parameters or outcome codes must trigger impact assessment across all Operations that consume it. Maintain retired versions for read‑only replay of historical batches/eDHR. Re‑qualification triggers include logic changes, safety interlock modifications, new equipment modules, and cybersecurity‑relevant interface changes. Ensure audit trails capture who approved recipe/phase versions and the effective dates by site/unit.

• Traceability: URS → Risk → Test → Evidence linked to Phase IDs
• Regression testing on shared Phase classes
• Read‑only preservation of historical versions for record review
• Supplier assessment for control platform patches affecting Phases

Many Operation Phases consume or produce material movements (e.g., Charge, Transfer Out/In, Filtered Transfer). Bind material lots to the Phase instance with weigh/measure verification, tare and net capture, and reconciliation tolerances. Tie in equipment/tooling IDs (filters, hoses) and their status (clean, calibrated, expiry) to maintain chain‑of‑control. When Phases create intermediate lots, immediately allocate identifiers and record forward/backward genealogy.

In‑process controls (temperature ramps, torque, pH, mass flow) must be sampled at time‑resolution appropriate to quality risk; store raw traces or summary statistics with integrity checks. When acceptance criteria are Phase outcomes, enforce automated pass/fail decisions where possible; where manual review is needed, require contemporaneous comments and controlled holds before the next Phase can start. Integrate LIMS for sample events to prevent premature progression.

Phase‑level metrics enable bottleneck analysis and continuous improvement. Track scheduled vs. actual durations, waiting/hold time, first‑pass yield, intervention counts, alarm rate, and mean time to recover from faults. Aggregate across batches to detect drift (e.g., heating to setpoint taking longer indicates fouling or sensor bias). Correlate Phase KPIs with maintenance events and calibration to inform predictive actions.

Time synchronization across MES and control is foundational; drift undermines KPI integrity and record review. Define data retention horizons for raw traces vs. summarized data and document compression/aggregation methods. Ensure KPI dashboards are traceable to source records so that quality decisions can be substantiated during inspections.

• Planned vs. Actual Phase duration
• Hold time distribution and causes
• Alarm density per runtime hour
• Intervention frequency by operator shift
• Yield and reconciliation loss per Charge/Transfer Phase

Frequent issues include conflating Operations and Phases, causing bloated phase logic that is hard to validate; embedding manual tasks inside automated Phases without proper e-signatures; inconsistent parameter naming/units across equipment; and weak exception modeling that forces ad‑hoc operator workarounds. Another trap is failing to version the Phase Class Library, breaking historical replay and complicating investigations.

Mitigations: enforce a design pattern where Operations orchestrate and Phases execute; constrain Phases to equipment‑bound, testable logic; externalize manual checks to MES steps with approvals; create a canonical parameter dictionary with units and limits; and define a finite set of outcome codes tied to deviation workflows. Treat interface contracts as controlled documents and test for backward compatibility before deployment.

• Do not hide manual actions inside control code
• Keep phase parameters typed and unit‑safe
• Use a small, stable set of outcome codes with reason catalogs
• Version everything: class, instance, parameters, and interface schema

V5 models Operation Phases as first‑class, versioned objects with typed parameter schemas, state transitions, and outcome codes. MES orchestration binds a Phase instance to Batch/Order, Unit, and Equipment Module, and tracks provenance for parameters (who/when/why), runtime states, alarms, and interventions. Interfaces to Level 2 control are specified via declarative maps (OPC UA/topic/tag), with correlation identifiers for deterministic genealogy and time‑synced event frames for record reconstruction.

Because V5 ships MES + QMS + eBMR/eDHR + LIMS + WMS + Maintenance on a single data model, a Phase can gate on QMS holds, trigger deviations/CAPA on specific outcomes, request LIMS samples and block progression on out‑of‑trend, verify tool/asset status via Maintenance, and transact materials via WMS with lot/expiry checks. Review by exception leverages Phase outcome and KPI thresholds to route targeted eBMR/eDHR review.