Pharma Engineering Insights

Designing a GMP Automation Architecture: PLC, DCS, SCADA, Historian and MES

Allocate PLC/DCS, SCADA, historian and MES functions around process needs, record ownership, interfaces, availability and recovery.

G GuideGxP 9 min read
✓ Official sources and references ✓ Practical approach ✓ For pharmaceutical professionals
GUIDEGXP · PRACTICAL GMP INSIGHTS
Layered pharmaceutical automation architecture with process equipment and control systems

A production unit can keep controlling temperature while its historian is unavailable, yet still become unusable for the next batch because the required record cannot be reconstructed. That distinction belongs in the architecture before procurement. A drawing that connects PLC, SCADA, historian and MES boxes is incomplete until it explains who controls the process, who owns each record, and what happens when a dependency disappears.

This article develops a decision method for pharmaceutical automation architecture. It addresses equipment, supervisory and manufacturing layers without assuming that every facility needs every layer. The appropriate solution depends on process behaviour, intended use, record requirements, operational capability and the consequences of failure.

Begin with the process boundary, not the software catalogue

Define the physical scope first: a standalone packaging machine, a production suite, shared utilities, or an integrated site. Identify material movements, equipment states and decisions requiring coordinated control. A utility distribution loop and a multiproduct batch suite may share infrastructure but have different needs for response, sequencing and records. Document interfaces to existing systems as constraints, including interfaces that cannot be changed during the project.

Then separate three boundaries. The control boundary describes where commands and protective actions execute. The information boundary describes where observations acquire context and become records. The responsibility boundary identifies the people accountable for operation, configuration, maintenance and review. These boundaries can cross vendor packages. One contract does not necessarily mean one system; several contracts do not remove the need for a single accountable integration owner.

[GUIDEGXP RECOMMENDATION] Review the architecture against real operating stories: start a batch, change a recipe, hold a unit, lose a server, restore communications and investigate a deviation. Each story should identify decisions, dependencies and evidence.

Assign functions to layers deliberately

Equipment control executes functions close to sensors and actuators. Unit control coordinates equipment modules and procedural states. Supervisory functions present the process, manage authorized commands and may coordinate activities across units. Historians collect time-related information; MES applications typically manage manufacturing execution, material context and electronic production workflows. Enterprise systems supply business information and receive agreed manufacturing results. Products can combine these functions, so a product name alone does not establish a boundary.

[STANDARD] ISA-88 and ISA-95 provide useful models and terminology for batch control and enterprise-control integration. They are reference frameworks, not a requirement to purchase a fixed stack of applications. The ISA catalogue identifies ISA-88.00.01-2010 and ISA-95.00.01-2025; detailed application requires access to the relevant licensed documents. The functional allocation here is original engineering guidance, not a reproduction of their models.

Time-sensitive control should have a justified execution location and response capability. Do not make a critical loop depend on an enterprise transaction merely because a platform supports the connection. Conversely, avoid duplicating production workflow in controller logic when a maintained manufacturing application owns that workflow.

Describe ownership for commands, recipes and records

Use an ownership register alongside the network drawing. For each object, identify the authoritative source, permitted writers, consumers, approval status, version and reconciliation rule. A recipe may have approved master parameters in one application and an executable control recipe in another. Define how those versions relate, how transfer is confirmed, and how the actual executed values are retained with the batch.

A historian storing a parameter does not automatically make it the authoritative production record. Determine which records support disposition, investigation, maintenance and business reporting. A calculated MES result must remain traceable to its inputs and calculation version where that context is necessary. Establish whether a report is a controlled record, a faithful copy or a convenient view. These distinctions affect retention, review, access and migration.

Commands also need ownership. If a local HMI and central SCADA can both change a setpoint, define authority, arbitration and visible status. Loss of central supervision must not silently create contradictory operators or leave local changes absent from the relevant history.

Compare architectural options against the intended use

OptionPotential fitDecision riskEvidence to request
Standalone equipment control with managed record exportLimited equipment scope and bounded workflowsManual transfer, fragmented identity and weak contextExport completeness, review workflow and recovery demonstration
Multiple PLCs with common SCADA and historianModular equipment and site supervisionInconsistent libraries and interface ownershipCommon object behaviour, integration contracts and outage tests
Integrated DCS with batch functionsCoordinated process units and shared operational conventionsPlatform dependency and costly boundary changesBatch execution, failover and maintainability demonstrations
Control platform integrated with MESManaged execution, genealogy and production recordsDuplicated workflow or unclear record ownershipEnd-to-end transaction, exception and reconciliation evidence

These are alternatives to evaluate, not a maturity ladder. A smaller architecture can satisfy the intended use better than a larger one with poorly controlled dependencies. Hybrid solutions are common; their interfaces require explicit engineering rather than assumptions that one platform will absorb the gaps.

Engineer data acquisition around the process question

Sampling, event capture and compression determine what can later be known about the process. Start with the decision the data must support: proving that a phase condition was maintained, investigating a short excursion, or calculating consumption. Consider sensor dynamics, controller execution, acquisition latency, buffering and storage behaviour together. A rapid controller scan does not guarantee an equally detailed historical record.

Define source timestamps, collection timestamps, time synchronization and quality indicators. A value with bad communication quality must not appear as an ordinary current measurement. Decide how missing, repeated, late and out-of-order observations are represented. Trend displays should reveal gaps and distinguish interpolated presentation from actual acquired values where this matters to interpretation.

[QRM] Select and justify acquisition settings through process risk and intended use. There is no universal GMP historian sampling rate. Demonstrate that the chosen configuration captures the events and durations relevant to the specific process, including realistic communication interruptions and buffering limits.

Separate availability from recoverability

Availability concerns continued service; recoverability concerns returning to an acceptable state after loss. Redundant servers may improve availability while sharing storage, identity, power or configuration failures. A second controller does not remove a single network path or an erroneous download. Identify common dependencies and common-cause failures before assigning credit to redundancy.

For every important service, define the consequence of interruption, the permitted degraded operation and the conditions that require a hold or stop. Derive recovery time and acceptable data loss from process needs, record obligations and business continuity assessment. Establish how local buffers, batch state and pending transactions survive an outage. Recovery must address reconciliation, not simply restarting services.

Keep backup, replication and archive distinct. Replication can propagate corruption; a backup may require software, configuration and keys to restore; an archive must remain retrievable and interpretable for its intended retention period. Test the assembled recovery procedure against a representative system state and record the prerequisites that made it successful.

Treat integration as a contract between owners

For each interface, specify the business or process event, payload meaning, units, identifiers, permitted states and confirmation mechanism. A delivered message is not necessarily an accepted manufacturing transaction. An ERP order can arrive while its material revision is unknown to MES; a completed phase can reach MES before its associated record is available.

Define retry, duplicate handling, ordering, timeout, quarantine and reconciliation rules. Assign responsibility for queues and rejected messages, including outside normal support hours. A protocol can transport data reliably while the applications disagree about its meaning. Confirm semantic compatibility with real scenarios rather than checking only that two endpoints connect.

The GMP system integration article develops these transaction controls. At architecture stage, reserve capacity and operational ownership for them; they are not optional commissioning details to discover after procurement.

Design security and administration into the boundary

Map assets and trusted communications before defining network zones and conduits. Separate justified data flows from convenient unrestricted access. Consider engineering workstations, portable service devices, remote support, infrastructure management and backups as part of the architecture. A production network can be exposed through a maintenance route that never appears on the process diagram.

Identity services require the same dependency analysis as control services. Define how authentication loss affects running operations, privileged work and new logins. Assign unique accountability where required, manage service accounts deliberately, and provide controlled emergency access. Security logging and GMP audit trails can support related investigations but serve different purposes and should not be treated as interchangeable records.

[GUIDANCE] NIST SP 800-82 Revision 3 provides OT security guidance; Revision 4 was an initial public draft at the review date. The ISA/IEC 62443 series supplies complementary industrial security standards. Neither establishes a universal network design for every GMP site.

Make standardisation maintainable

Standardise behaviours that reduce operational variation: equipment objects, state names, alarm conventions, interface patterns, user roles and change procedures. Control the versions of reusable libraries and identify which installations use each version. A library correction needs an impact assessment across those installations; “standard code” is not automatically correct for every process context.

Evaluate scalability through credible expansion scenarios. Adding another skid may require historian licences, storage, engineering capacity, network changes and additional review workload. Check capacity under expected peak demand and failure conditions, not just the average production load. Retain margin justified by the project rather than adding arbitrary percentages.

Assess vendor dependency through exportability, source-code access, configuration ownership, available skills and support arrangements. Open protocols can reduce some interface constraints while proprietary application models still create dependency. Record the practical exit route, including how historical data and executable recipes would remain understandable after a platform change.

Worked example: modular bioprocess suite

Consider an illustrative suite with independently supplied bioreactor skids, a common historian and a proposed MES connection. Each skid already controls its own process. The architecture team identifies approved recipe parameters, phase status and selected process observations as required exchanges. It keeps real-time control local and assigns manufacturing order context and material genealogy to MES.

A failure review finds that the initial concept would let MES close an operation after receiving a completion message even when historian transfer was incomplete. The team adds a distinct record-completeness status and reconciliation workflow. Communication restoration transfers buffered observations with original source time and quality information; duplicate completion messages cannot create duplicate operations.

Acceptance evidence includes a controlled interruption during a representative phase, confirmation that local control follows its approved strategy, visible degraded status, recovery of the required observations and reconciliation before record review. The precise buffer duration and recovery objectives are derived from this suite's assessed needs. They are not generalized as requirements for all bioprocess systems.

Release the architecture as a controlled engineering decision

[REGULATORY REQUIREMENT] Apply the relevant GMP framework to the intended use and jurisdiction. EU GMP Annex 11 addresses computerized systems, Chapter 4 documentation and Annex 15 qualification and validation. At the review date, the operative Annex 11 and Chapter 4 texts remained the 2011 versions; the 2025 consultation proposals were not operative replacements. US Part 11 applicability depends on the electronic records and signatures concerned and their predicate-rule context.

[GEP] The architecture package should make design decisions inspectable: functional allocation, system boundaries, data ownership, interfaces, failure responses, security dependencies and lifecycle responsibilities. Trace critical decisions to the automation URS and to acceptance evidence. Record unresolved assumptions with an owner and closure condition before they become purchase-order commitments.

  • Can operators and reviewers identify the authoritative state and record?
  • Does each failure scenario have an approved operational response?
  • Are interface exceptions detectable and assigned to an owner?
  • Can the site restore the complete system and reconcile its records?
  • Can the architecture be supported, changed and eventually retired?

For equipment context, connect this assessment with Single-Use & Bioprocess Systems, Critical Utilities Systems and the Automation & Digital Systems hub.

Distinguish BMS, EMS and SCADA responsibilities

A building management system commonly controls building services; an environmental monitoring system supports the defined environmental monitoring programme; SCADA supervises industrial functions. Their capabilities can overlap without making their intended uses interchangeable. Identify which system controls HVAC, which retains observations used for GMP decisions, and who reviews alarms and excursions. Sharing a sensor or dashboard does not by itself establish independence, record ownership or review responsibility. Assess those relationships explicitly within the process and monitoring strategy.

Primary references and status

Reviewed 23 September 2026. European Commission: EudraLex Volume 4; 21 CFR Part 11; ISA standards catalogue; NIST SP 800-82 Revision 3. Standards are summarized through their scope and publisher information; no proprietary standard tables are reproduced.

THE PRAGMATIC GMP · EVERY MONDAY

The GMP topics that matter, in 7 minutes.

One GMP topic, one real-world example and one practical action, based on official sources and inspection trends.
Discover The Pragmatic GMP