Automation Strategy & Architecture
The shape of a control estate — control philosophy, the layering of equipment, supervisory and operations systems, platform choices, integration approach and who owns each layer — determines what can be changed independently a decade later. A tightly coupled estate makes every upgrade a site-wide project, and that is the mechanism by which unsupported control systems stay in production long after anyone wanted them there.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSAutomation architecture is bought one project at a time and lived with for decades: each system arrives justified on its own, and the integration debt only becomes visible when someone asks a question that spans two of them.
06 · QUALITY MATURITY — AUTOMATION STRATEGY & ARCHITECTURE, REACTIVE TO ADAPTIVE
Systems arrive with projects. Each was the right choice at the time, and nobody holds a picture of how they fit together.
An architecture diagram exists, drawn once at a transformation programme and now several projects out of date.
A maintained target architecture states which layer owns which function, so a new system is assessed against it rather than added beside it.
Interfaces are designed rather than bridged, data has one owning system per attribute, and obsolescence is planned against rather than discovered.
The architecture is an asset that absorbs new capability cheaply: adding a line, a product or a measurement is configuration rather than a project.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: EMA, ISPE, ASTM, IEC.
RECORDS & OBJECTIVE EVIDENCE
- The current architecture, showing systems, layers and the interfaces between them
- The owning system for each critical data attribute
- Assessment records where a new system was placed against the target architecture
- Interface specifications, with what is verified about the data crossing each
- The obsolescence and lifecycle position of each platform
COMMON INSPECTION FINDINGS
- Two systems holding the same attribute with no defined owner, so they disagree and nobody can say which is right
- An architecture diagram that predates several installed systems
- Point-to-point interfaces added per project, with no specification of what is verified
- Platforms past vendor support with no replacement or extension plan
- A new system procured on function alone with no assessment of where it fits
Layering is the decision that ages well or badly
Control estates are conventionally described in layers: field instrumentation, basic process control, supervisory and batch management, manufacturing execution, and enterprise systems above. The layering matters less as a taxonomy than as a statement of coupling — what has to change together. Where a recipe change requires touching the historian schema and a report, three systems are one system, and their obsolescence dates are now the same date.
The architectural discipline is to make the interfaces between layers explicit and stable, so a layer can be replaced without the ones above and below being renegotiated. This is unglamorous at design time and is the single largest determinant of what an upgrade costs in year ten.
Platform choice buys a support horizon
Choosing an automation platform is choosing a vendor relationship measured in decades, and the relevant question at selection is rarely the feature comparison. It is the supported lifetime of the version being installed, the upgrade path from it, whether the integrator’s configuration will be portable or proprietary, and whether spare parts and engineering competence will exist in fifteen years.
The regulated dimension compounds this. Because the operating system underneath an HMI is part of a qualified configuration, an unsupported platform is not merely a security exposure — it is one whose remediation carries a requalification burden. Sites therefore run out-of-support software not through neglect but because the supported replacement exists only as a control-system upgrade project nobody has funded.
Ownership per layer, stated rather than assumed
Control estates sit on a boundary between engineering, IT and quality, and the boundary is usually undefined. Engineering owns the process function, IT owns the servers and the network, quality owns the validated state, and the layer everyone assumes another owns — typically the supervisory layer, the historian, or the interfaces — is the one that goes unpatched, unmonitored and unreviewed.
The remedy is a written allocation per layer: who specifies, who changes, who approves, who supports out of hours, and who is accountable for the validated state. It is a governance artefact rather than a technical one, and its absence produces the recurring finding that the interface between two well-run systems is run by nobody.
SPEQ interpretation — architecture is a data-integrity decision
Automation architecture is evaluated on availability, capability and cost, and rarely on where the regulated record lives. But the architecture determines which system is the originating record for a critical process parameter, whether that record can be altered downstream of its creation, and whether the audit trail spans the whole path from sensor to batch record or stops at a boundary between two systems.
The useful question to ask at design review is: for each GxP-critical value, where is it created, what could change it before it reaches the batch record, and is that path covered by an audit trail the organisation controls. Asked at design it costs a conversation. Asked during an investigation it costs the batch.
FREQUENTLY ASKED
Why do unsupported control systems stay in production so long?
Because the supported replacement usually exists only as a control-system upgrade with its own qualification burden and capital case, not as a patch. Tight coupling makes it worse: if the layers cannot be replaced independently, the upgrade is a site-wide project, and site-wide projects wait for a budget cycle that keeps not arriving.
Who should own the supervisory layer — engineering, IT or quality?
Whoever is named in a written allocation. The specific answer varies by site; what does not vary is that the layer everyone assumes someone else owns goes unpatched, unmonitored and unreviewed. Allocate specification, change, approval, out-of-hours support and validated-state accountability per layer explicitly.
What should be asked about architecture at design review?
For each GxP-critical value: where is it created, what could alter it before it reaches the batch record, and does an audit trail the organisation controls cover that whole path? Architecture decides where the originating record lives, and that is a data-integrity determination made long before anyone frames it as one.