Automation systems in pharmaceutical manufacturing generate GxP process data that directly supports batch release decisions. A bioreactor controller that records temperature, pH, and dissolved oxygen during a cell culture run generates the evidence that the process was executed within specification. If that data is unreliable, because the system wasn’t validated, the audit trail is disabled, or the alarm configuration was changed without change control, the quality of the batch decision rests on a broken foundation.

This article covers validation of process automation systems: PLCs, SCADA, DCS, batch control systems, and the interfaces between them. It is aimed at automation engineers, CSV specialists, and quality professionals working in pharmaceutical or biotech manufacturing.

The regulatory basis

Automation systems in GxP manufacturing are subject to the same regulatory framework as other computerized systems:

  • 21 CFR Part 211.68, Requirements for automatic, mechanical, and electronic equipment used in pharmaceutical manufacturing. Equipment must be calibrated, inspected, and checked according to a written program. Data generated by automated equipment must meet the same integrity standards as any other GxP record.
  • 21 CFR Part 211.188, Batch production records must include a complete documentation of the manufacturing process. For automated systems, the electronic batch record and automation system outputs are part of this record.
  • EU GMP Annex 11, Computerised systems (including process control systems) must be validated, and their audit trails enabled and reviewed.
  • GAMP 5 Second Edition (2022), The industry framework for automation system validation, including guidance on PLCs, SCADA, DCS, and their integration with MES.

Understanding the automation hierarchy

Before designing a validation strategy, understand which layer of automation you’re dealing with. The ISA-95 standard defines a hierarchy:

Level 0, Physical process (sensors, actuators, instruments) Level 1, Basic control (PLCs, DCS controllers, instrument transmitters) Level 2, Supervisory control (SCADA, HMI, process historians) Level 3, Manufacturing operations (MES, EBR, batch management) Level 4, Business systems (ERP, planning systems)

Each level has different validation requirements. The data flows between levels are particularly high risk for data integrity, a value that passes from a Level 1 PLC through a Level 2 historian and into a Level 3 MES must maintain its integrity at every transfer.

PLCs (Programmable Logic Controllers)

PLCs are the workhorses of pharmaceutical automation, they execute the fundamental control logic: opening valves, controlling temperatures, managing sequences. Common vendors: Allen-Bradley (Rockwell), Siemens S7, Schneider Modicon.

Why PLCs need validation

A PLC that controls a pharmaceutical process is a GxP computerized system. Its ladder logic, function blocks, or structured text programs determine whether the process executes correctly. If the logic is wrong or has been changed without control, the process output cannot be trusted.

GAMP 5 categorizes PLC software as:

  • Category 3: Firmware and non-configurable embedded software (most PLC OS components)
  • Category 4: Configurable PLC applications (standard function blocks configured by the user)
  • Category 5: Custom-developed PLC programs (bespoke ladder logic or function blocks written from scratch)

Most pharmaceutical PLC applications fall in Category 4 or 5. The validation scope depends on category and risk.

What PLC validation covers

Hardware qualification (IQ):

  • Correct hardware installed (model, firmware version, I/O module configuration)
  • Power supply and environmental conditions meet specifications
  • Network connections and communication protocols documented

Software/configuration qualification (OQ):

  • PLC program version control: the validated program version must be locked, and any change must go through change control
  • I/O loop checks: each input (sensor) and output (actuator) connected to the PLC tested for correct signal path and response
  • Alarm configuration: each alarm setpoint verified against the batch record or process specification
  • Interlock testing: safety and process interlocks tested under simulated trip conditions
  • Sequence control: for batch operations, the entire sequence logic tested end-to-end

Performance qualification (PQ):

  • Process operation under actual conditions (not simulated) with documented results
  • For critical parameters (temperature, pressure, pH, agitation), statistical confirmation that the control system maintains the parameter within specification over a realistic batch duration

PLC-specific data integrity requirements

PLCs typically don’t generate user-readable audit trails in the way that LIMS or EBR systems do, but they generate process data that must meet integrity requirements:

Timestamp accuracy: Process data timestamps must be synchronized with a reliable time source. PLC clock drift is a real issue and can create discrepancies between the PLC data record and external records (SCADA historian, operator log). Time synchronization validation is required.

Data retention at the PLC level: PLC memory is not permanent storage. Process data recorded in PLC registers must be transferred to a higher-level historian or MES before it is overwritten. The data transfer mechanism must be validated.

Program change control: Once a PLC program is validated, any change (logic modification, setpoint change, I/O reassignment) is a change to the validated state and must go through change control. A common gap: maintenance technicians modify a setpoint or sequence timing “temporarily” without change control documentation.

Unauthorized access to PLC programming: PLC programming interfaces (RSLogix, TIA Portal, Unity Pro) must be restricted to authorized personnel only. USB access to the PLC programming port is a data integrity risk, it provides a path for unauthorized program modification.

SCADA (Supervisory Control and Data Acquisition)

SCADA systems provide the human-machine interface (HMI) layer above PLCs and DCS controllers. They display real-time process data, allow operator interactions, manage alarms, and typically interface with a process historian.

SCADA in a validated GxP context

SCADA systems are GAMP Category 4 or 5 depending on how they are configured. Key validation activities:

Configuration qualification:

  • All display screens verified against PID (piping and instrumentation diagram) and process description
  • Alarm set points on the SCADA HMI match the PLC/DCS configuration and the batch record specification
  • Historian tag list verified, each process variable recorded in the historian must be mapped to the correct instrument signal

Operator interaction audit trail:

  • SCADA must record every manual setpoint override, alarm acknowledgment, and mode change (auto/manual/cascade) with operator ID, timestamp, and new value
  • Regulators expect that audit trail to be reviewed as part of batch review, not just the process data, but who changed what during the batch

Alarm management:

  • Alarm configuration: setpoints, priorities, and suppression rules must be documented and change-controlled
  • Alarm rationalization: the pharmaceutical industry has a poor history of alarm flood, thousands of alarms configured for a process with most never acknowledged or investigated. GAMP 5 and ISA 18.2 guidance recommend alarm rationalization as part of validation
  • Alarm acknowledgment records: a record of unacknowledged critical alarms during a batch is a data integrity-relevant document

The process historian

SCADA systems typically write to a process historian (OSIsoft PI, Aveva, Ignition, etc.), a time-series database that stores every tagged process variable at defined intervals.

The historian is a GxP system when:

  • Data it stores is used to demonstrate process compliance (in-spec temperature, pressure, pH across a batch)
  • Data it stores feeds into the batch record or electronic batch record

Historian validation covers:

  • Tag mapping validation: each historian tag verified to the correct instrument source
  • Timestamp accuracy: historian timestamps synchronized with an authoritative time source
  • Data compression settings: historians use compression algorithms to reduce storage, these settings must be validated to confirm they don’t alter process data beyond acceptable tolerances
  • Backup and recovery: historian data must be backed up and restore must be tested

DCS (Distributed Control Systems)

DCS are used for continuous and complex batch processes, fermentation, chromatography, fill-finish operations. Common platforms: DeltaV (Emerson), CENTUM VP (Yokogawa), PCS 7 (Siemens), ABB System 800xA.

DCS and batch control

DCS systems in pharmaceutical manufacturing often implement ISA S88 batch control standards: equipment phases, operations, procedures, and procedures coordinated by a batch manager. The S88 model separates the recipe (what to make) from the equipment (how to make it).

Under S88:

  • Master recipe: the defined manufacturing procedure, controlled at the recipe level
  • Site recipe: the master recipe adapted for a specific site or process train
  • Control recipe: the recipe as executed for a specific batch, this is the GxP record

Recipe management requires validation:

  • Recipe versions must be controlled (version control, approval before use)
  • Recipe changes must go through change control
  • The control recipe executed for a batch must be retained as part of the batch record

GAMP 5 Category: A DCS with configured batch recipes is Category 4. Custom recipe logic or custom equipment phases written in proprietary scripting is Category 5.

Electronic batch record integration

The interface between DCS and MES/EBR is one of the highest DI risk points in pharmaceutical automation:

  • Data flows from DCS (process execution records) into the EBR (batch documentation system)
  • Interface failures can result in missing data, corrupted values, or out-of-sequence records
  • Each interface transfer must be validated: data mapping, format conversion, error handling, and reconciliation

Specific requirements:

  • Data mapping validation: every DCS parameter that appears in the EBR must be verified to map correctly
  • Interface error handling: what happens if the interface fails mid-batch? Does the EBR show a gap? Is there an alarm? Is there a fallback procedure?
  • Timestamp alignment: DCS timestamps and EBR timestamps must be consistent, discrepancies suggest either clock drift or data manipulation

Recipes, methods, and scripts in automation

The recipe or method used by an automated system is as much a validated document as any paper SOP. Key principles:

Version control is mandatory. A recipe that can be modified by any operator without a change number and approval is not controlled. The version of the recipe executed for each batch must be traceable.

Approved recipes only. No unauthorized recipe modifications in production. This includes “temporary” modifications, test runs using production-scale equipment, and parameter adjustments that have become de facto standard practice.

Recipe change control applies to minor changes. A setpoint change that improves yield is still a change to the validated state. It requires assessment, approval, documentation, and may require process qualification activities depending on the critical nature of the parameter.

Interface validation and middleware

Complex manufacturing environments have many systems exchanging data: DCS ↔ MES, MES ↔ LIMS, LIMS ↔ ERP, EBR ↔ Document Management. Each interface is a validation obligation.

What interface validation must cover:

  • Data mapping: source field to target field, including units of measure, rounding, and format conversions
  • Error handling: what happens when the interface fails? Is data lost? Is there a notification? Is there a manual fallback?
  • Transaction integrity: for bi-directional interfaces, if a write fails halfway through, is data left in an inconsistent state? The interface must handle partial failures gracefully.
  • Performance testing: interfaces that fail under high load are a production risk, test at expected peak transaction volume
  • Security: network architecture, authentication between systems, encryption for data in transit

Middleware validation: Middleware platforms (MuleSoft, iBus, custom message queues) that translate and route data between systems are GAMP Category 4 or 5. The middleware configuration and routing logic must be validated.

Alarm and event records in GxP manufacturing

Process alarms and events are GxP records when they:

  • Document critical process excursions (temperature out of range during a critical step)
  • Record operator interventions (manual override of an automated setpoint)
  • Capture equipment fault conditions that affected process execution

What regulators look for:

  • Alarms that fired but were not acknowledged, this is a potential indicator that the alarm wasn’t reviewed
  • Alarms that were suppressed, suppression is legitimate (planned maintenance, startup periods) but must be documented and authorized
  • Alarm flood conditions, if thousands of alarms fired in a batch, meaningful review is impossible and the alarm management program is deficient
  • Missing alarm records, if alarms that should have fired (based on process data) don’t appear in the record, that’s a data integrity question

Alarm review as part of batch review: In a mature manufacturing environment, the batch review process includes review of alarm events, not just confirmation that all parameters were in spec, but confirmation that any alarm conditions were investigated and resolved before the batch was released.

Time synchronization, a hidden validation gap

Time synchronization is one of the most commonly overlooked automation validation requirements. The issue: when multiple systems record timestamps independently, clock drift creates discrepancies. A PLC that gained 47 seconds over three months will show timestamps that don’t align with the SCADA historian, which don’t align with the EBR.

Time discrepancies are a data integrity finding because they raise questions about data authenticity, when there are two records of the same event with different timestamps, it looks like one of them was modified.

Minimum controls:

  • All GxP automation systems synchronized to a common NTP (Network Time Protocol) server
  • Time synchronization status logged and monitored
  • Maximum allowable clock drift defined and enforced
  • Time synchronization failures trigger an alert

Validation of time synchronization: Document the NTP server hierarchy, validate that each system syncs correctly, test what happens when the NTP server is unavailable (does the system maintain time accurately? For how long?).

Change control for automation systems

Automation change control is an area where GxP and engineering cultures frequently conflict. Engineering change management is often informal and fast (“the process needed that setpoint adjusted”); GxP change control is formal and documented.

The resolution: the GxP change control process must be designed to be fast enough that automation engineers don’t route around it.

What requires change control:

  • Any modification to validated PLC, DCS, or SCADA software
  • Setpoint changes for critical process parameters
  • Alarm setpoint changes for critical alarms
  • Recipe modifications (master, site, or control)
  • Network or communication configuration changes
  • Hardware replacement that affects validated performance

What may not require formal change control (with a risk-based justification):

  • Non-GxP infrastructure changes with documented impact assessment showing no GxP system effect
  • Cosmetic display changes on SCADA HMIs (font color, screen layout) where the underlying logic is unchanged, depending on the program’s change control procedure

The impact assessment for automation changes must specifically consider: does this change affect any parameter that appears in the batch record? If yes, the assessment must address whether re-qualification testing is needed.

Common failures in pharmaceutical automation validation

1. Validated PLC program replaced without change control. The validated program is overwritten during a support call, a firmware upgrade, or a “restore from backup” that was actually a different version. The next batch is run on an unvalidated program.

2. Historian compression settings never validated. All process data is stored in a compressed format. The compression algorithm filters out “insignificant” changes. A brief temperature excursion falls below the compression threshold and disappears from the historian record.

3. Interface mapping not validated. A DCS value for pH is in pH units; the MES expects the value in the same units but the mapping has an offset error. Batches are released with a systematic pH offset that nobody noticed because the batch record showed the MES value, not the DCS raw data.

4. Recipe changes treated as minor without assessment. An agitation speed is increased for a fermentation process. No formal change control. Process performance deteriorates three batches later. Because the change wasn’t documented, the investigation takes months to connect the dots.

5. Alarm suppression not documented. During a planned equipment shutdown, all alarms were suppressed. The suppression wasn’t documented. An inspector sees an 8-hour window in the alarm log with no alarms during what should have been active process time.

Minimum compliant baseline for a small biotech

For a pre-commercial biotech with a limited number of automated processes:

  1. System inventory with GxP impact assessment for each automation system
  2. IQ/OQ documentation for all GxP-impacted systems (even simplified, risk-based approach)
  3. PLC program version control: validated versions locked, access to programming tools restricted
  4. Change control procedure that covers automation systems explicitly
  5. Alarm configuration documented and change-controlled
  6. Audit trail enabled and accessible on all GxP systems
  7. Time synchronization protocol, all systems synchronized to a common time source
  8. Interface validation for any data transfer that feeds the batch record

Better maturity state

For a commercial-stage company with multiple process trains:

  • Full S88 batch control framework with validated recipe management
  • Formal alarm rationalization study per ISA 18.2
  • Automated alarm review as part of batch review (not manual log checking)
  • Interface validation including automated reconciliation between systems
  • Process historian validated with compression tolerance testing
  • DCS/SCADA performance qualification with statistical demonstration of parameter control
  • Business continuity plan tested for automation system failures

References

  • 21 CFR Part 211.68, Automatic, mechanical, and electronic equipment
  • 21 CFR Part 211.188, Batch production and control records
  • EU GMP Annex 11, Computerised systems
  • GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022), Chapters on automation, SCADA, and process control
  • ISA-95: Enterprise-Control System Integration
  • ISA S88: Batch Control Systems
  • ISA 18.2: Management of Alarm Systems for the Process Industries
  • ISPE GAMP Good Practice Guide: Manufacturing Execution Systems (MES)
  • FDA: Process Validation Guidance, 2011