Recipe Management
in a Pharma SCADA
— Design and Validation

What Recipe Management Actually Means in a GMP SCADA

Recipe management is the capability to define, store, version, select, execute, and record the use of process recipes in a way that the executed parameters are unambiguously traceable to the approved master recipe. In a pharmaceutical context, that traceability has a direct product quality implication: if the wrong recipe was used, or if a recipe parameter was modified outside the approved change control process, the batch is potentially compromised.

The distinction that matters most in a GMP context is between the master recipe and the control recipe. The master recipe is the approved, version-controlled specification for a product — defined, reviewed, and released by QA. The control recipe is the run-time instance derived from the master recipe and issued to the SCADA or batch management system for a specific execution. Any system that allows operators to modify control recipe parameters at runtime without audit trail — even if it generates a batch record — does not have compliant recipe management.

The ISA-88 Model — What the Standard Actually Requires

ISA-88 (IEC 61512) defines a hierarchical model for batch process control. Most engineers know the equipment hierarchy — Enterprise, Site, Area, Process Cell, Unit, Equipment Module, Control Module. Less well understood is the recipe structure, which maps directly onto the equipment hierarchy and defines what your SCADA needs to implement.

For most system integrators on a pharma project, the relevant scope is the master recipe and control recipe layers. You're not writing a general recipe (that's R&D). You're building the system that stores the approved master recipe, generates control recipe instances, executes them, and produces a batch record that traces every executed parameter back to the approved master.

ISA-88 also defines a procedure model for how recipes execute: Procedure → Unit Procedure → Operation → Phase. Each level maps to a piece of equipment or a control module. The PLC phase logic is the lowest level — individual operations like "fill tank," "heat to setpoint," or "mix for duration." Understanding this hierarchy is essential when writing the URS and FDS for a batch system, because QA will expect your functional requirements to align with this model.

The GMP Requirements That Drive Your Design

Recipe management in a GMP environment is subject to three overlapping regulatory frameworks, and the intersection of all three defines your minimum design requirements.

21 CFR Part 11 — Electronic Records and Signatures

Any master recipe stored electronically and subject to an electronic approval process falls under 21 CFR Part 11. This means the recipe record must be attributable, legible, contemporaneous, original, and accurate (ALCOA+). The practical implications: the SCADA must enforce unique user authentication before recipe approval, each recipe approval must carry the meaning of the signature (reviewed, approved), and the record must be protected against modification after approval. See the audit trail checklist for the specific fields required on every recipe modification event.

EU GMP Annex 11 — Computerised Systems

Annex 11 clause 4.8 requires that data entered into a computerised system manually should be subject to an additional check. For recipe parameters, this means a second-person verification step — either a second electronic signature or a review-and-approve workflow before a recipe is released for production use. Clause 5 requires that the audit trail captures all changes to recipes, including the old value, the new value, the reason for change, and the user who made the change. This is not optional in an Annex 11 environment.

GAMP 5 Category 4 and Category 5

A SCADA with recipe management is typically Category 4 (configured software) if the recipe engine is a standard vendor module, or Category 5 if the recipe logic is custom-coded in a PLC. The GAMP 5 category determines the depth of your V-model documentation. Category 5 custom recipe logic requires an SDS with the state machine design documented — including all state transitions, parameter validation logic, and abort conditions.

Designing the Master Recipe — What It Must Contain

The master recipe definition in your FDS must specify the data structure the SCADA stores for each recipe. This is what QA will review during the FDS review, and what the OQ will test. At minimum, a GMP master recipe record must contain the following fields:

• Recipe ID and Name — unique identifier, human-readable product name
• Version number — sequential, never reused, incremented on each approved change
• Status — Draft / Under Review / Approved / Superseded / Obsolete
• Approval record — approver ID, timestamp, e-signature meaning
• Product and process parameters — all setpoints, durations, quantities, and tolerances required by the procedure
• Parameter limits — hard limits enforced by the SCADA that cannot be overridden at runtime
• Applicable equipment — which process cell or unit the recipe is valid for
• Change history — audit trail of every modification from recipe creation

The parameter limits deserve special attention. The master recipe defines the nominal setpoint. The hard limits are the outer boundary beyond which the system will not execute, regardless of what is entered. These limits must be defined in the FDS and verified in the OQ — they are a critical Part 11 control. A recipe management system that allows operators to enter any value during execution with no enforcement limit is not a compliant system.

Runtime Controls — What Happens During Batch Execution

Once a control recipe is instantiated from the master recipe, the question is: what can operators modify during execution, and what happens when they do? This is the area where most system integrators underdesign on their first batch project.

Three principles govern runtime recipe control in a GMP SCADA. First, hard limits are absolute — they are engineered controls, not administrative ones. No role, including administrator, can enter a value outside the hard limit. This is tested adversarially in the OQ. Second, every parameter change has a reason — the system must require the operator to enter a reason before accepting any mid-execution modification. Blank reason fields are not acceptable in a GMP system. Third, the approved master recipe cannot be modified while a batch is active — the SCADA must lock the master recipe for the duration of execution. If a new version is needed, it takes effect on the next batch, not the current one.

What the Batch Record Must Contain

The batch record — whether an Electronic Batch Record (EBR) generated by the SCADA, or a paper record completed alongside — must allow a QA reviewer to reconstruct exactly what happened during the batch. In a SCADA-driven batch system, the electronic batch record is generated from the data captured during execution. The key fields are not optional.

• Recipe ID and version used — not the current version, but the version that was active at batch start. If a new version was approved mid-campaign, the batch record must show which version executed this specific batch.
• Batch ID and start/end timestamps — with NTP-synchronised timestamps. Time source must be traceable and verified. See the audit trail implementation guide for NTP requirements.
• All executed parameters with planned vs actual — nominal setpoint from master recipe, actual executed value. Any deviation between planned and actual must be clearly flagged, not buried in a data table.
• Operator and supervisor identities — for every critical operation, who performed it and when. These must be real user IDs from authenticated sessions, not generic "Operator" accounts.
• All parameter changes during execution — with old value, new value, reason, user, and timestamp. If a parameter was changed mid-batch for any reason, it appears here, not just in a separate audit trail query.
• Any process deviations — alarms triggered, their response, and resolution. An alarm that fired and was acknowledged without corrective action is a process deviation, and the batch record should make this visible.
• Electronic signatures — batch initiation, critical process steps, and batch release, each with meaning text and timestamp.

The key test for a well-designed electronic batch record: a QA reviewer who was not present during the batch should be able to determine whether the batch was executed correctly, using only the batch record, without needing to query separate historian or audit trail databases. If answers require separate database queries to reconstruct, the batch record is incomplete.

How to Validate Recipe Management — The Test Strategy

Recipe management validation follows the same V-model structure as any other system function, but there are specific test cases that are mandatory regardless of system type. The OQ protocol must include all of the following.

Master Recipe Version Control Tests

Verify that version increments correctly on approved change, that the previous version is retained and accessible, and that an expired version cannot be selected for batch execution. These are positive tests. The adversarial test is attempting to select an obsolete recipe for execution — the system must reject it with a clear message, and the attempt must be logged.

Electronic Signature Tests

Verify that recipe approval requires an authenticated electronic signature from a user with the correct role. Test the negative: an operator role (without recipe approval permission) attempting to approve a recipe must be rejected. Test the signature record: the batch record must show the approver ID, timestamp, and meaning text — not just a checkbox.

Parameter Limit Enforcement Tests

These are boundary tests. For each critical recipe parameter, attempt to enter the value exactly at the hard limit (should be accepted) and one unit outside the hard limit (must be rejected). This is the most important adversarial test in recipe management validation. Platforms like Ignition, WinCC, FactoryTalk View, and HistoriAN handle this enforcement differently — the test must verify the actual enforcement, not just that the FDS states limits exist.

Mid-Execution Modification Tests

With a batch in execution, attempt to modify a recipe parameter as an Operator role (should be blocked or require Supervisor override), then successfully modify it as a Supervisor with a valid reason. Verify the audit trail entry contains old value, new value, user, timestamp, and reason. Verify the modification appears in the batch record.

Recipe Lock Tests

With a batch in active execution, attempt to approve a new version of the master recipe currently in use. The system must reject this or queue the new version for post-completion activation. The current batch must complete using the version it started with.

What the FDS Must Document for Recipe Management

Recipe management must be fully specified in the FDS before any coding begins. QA will review the FDS recipe management sections before approving it for development. The FDS must define — not just describe — the following elements.

The recipe data model: every field in the master recipe record, with data type, allowed values, and edit permissions per role. This is not a narrative description — it is a table. The FDS reviewer needs to see that every compliance requirement has a corresponding data field.

The state machine for recipe lifecycle: Draft → Under Review → Approved → Active → Superseded → Obsolete. Each transition must have a defined trigger, required role, and audit trail requirement. Systems that skip states (Draft → Active in one step with no review) are non-compliant, regardless of how small the organisation is.

The runtime enforcement logic: which parameters can be modified at runtime, by which roles, with which controls. The FDS must be explicit. "Parameters can be modified within limits" is not sufficient — the FDS must state which parameters, what the hard limits are, and what the SCADA does when a limit is exceeded.

The batch record structure: a field-level description of what the electronic batch record contains. If the batch record is generated by the SCADA, its format must be approved before FAT. You cannot execute a FAT and then decide what the batch record looks like — the batch record format is part of what the FAT verifies.