[ ENTERPRISE PILLAR 09 ]
Control physical processes predictably through governed instrumentation, control logic, recipes, alarms, infrastructure, and lifecycle support.
This pillar owns industrial control and OT operation. Digital enterprise systems, cybersecurity controls, and validation evidence remain connected but distinct.
The capability framing below, its failure modes and the boundary with neighbouring pillars are SPEQ’s practitioner reading — not a regulatory requirement, and not an assessment of any organization.
THE CAPABILITY
This is the layer at which an intention becomes a physical action. Above it, a control strategy, a recipe and a limit are statements about what should happen; here something actually heats, opens, doses or stops. The defining feature of the capability is that one set of equipment does two jobs at once: the instrument that regulates a condition is the instrument that testifies to it, and the system that runs the sequence is the system that records it. That is why instruments, controllers, supervisory systems, historians and the networks beneath them form one capability rather than several adjacent ones. A fault anywhere along that chain produces one of two outcomes and often both — the process does something other than what was intended, or the record says something other than what occurred.
This capability cannot be fully exercised anywhere except the place where exercising it is most expensive. An interlock, a trip, a failure sequence and a recovery path only show their real behaviour under the conditions they exist to handle, and those conditions arrive during production, in a plant nobody wants to disturb. Verification is therefore a permanent choice between two unattractive options: prove it live and risk what is running, or prove it away from the process and accept that the test rig is not the plant. Competence inside each branch does not remove that choice; it only executes each option better. The second structural problem is that the capability ages on two clocks that do not agree. The physical process may run unchanged for twenty-five years; the computing platform underneath it leaves support in seven. An end-of-support notice is a live operational event for an asset in perfect physical condition, and the upgrade that restores supportability is itself the largest single threat to a process that has been stable for a decade — so doing nothing and doing something are both risks, and the decision falls to people rewarded for the process not moving. The third is that what goes wrong here is silent. A wrong scaling factor, an alarm suppressed for a good reason six years ago, a logic branch never reached in service: the system keeps running, keeps reporting normally, and gives no sign that it has stopped being what its documentation describes.
Each of these happens with the individual branches below being run competently. That is what makes them capability failures rather than performance problems.
Every incident adds an alarm and no process removes one, so the operator faces a standing rate that cannot be acted on and learns to work through it. The one that mattered arrives inside a burst of two hundred and is acknowledged with the rest. Suppression and shelving lists grow to manage the noise and then go unreviewed, which means the plant has quietly redefined which conditions it announces.
Baselines exist on paper but drift from what is loaded, so the truth becomes whatever the controller currently holds. Recovery then depends on the memory of whoever last touched it, and a restore returns the plant to a configuration nobody can attest to. It is discovered at the worst possible moment, because the moment the backup is needed is the moment the system is already down.
A force, a jumper or a maintenance override goes in for one shift and is authorized properly. What nobody holds is the aggregate: how many are active now, which of them stand between the process and something serious, and which were meant to expire. The design documentation continues to describe the plant as drawn, while the plant as running has a different protective envelope.
Clocks on controllers, the historian, the execution system and the building drift apart; tags are renamed during a project; compression settings average away the excursion that was the whole point of recording. Nothing fails and nothing alarms. It surfaces during an event reconstruction, when two systems disagree about the order in which things happened and the sequence cannot be established from either.
WHERE THIS STOPS
This pillar owns the systems that act on the process and the state those systems are in. It does not own what the process is trying to do: which conditions matter, what the sequence must achieve and where the limits sit come from the process and product owners, and an automation group that sets them has absorbed the decision it exists to implement. The boundary that produces the most Friday-afternoon argument is with enterprise IT and security, because the same control applied to an office asset and to a controller has different consequences — a patch window that is routine upstairs is a production stoppage down here, and a remote-access standard written for laptops meets a vendor who needs to reach a running skid tonight. The workable line is that the security requirement is set once for the enterprise while implementation and timing are negotiated per zone, with the operational consequence owned here rather than argued case by case. Upstream, the project capability specifies, procures and installs the control system and proves it works; this capability owns its configured state from the moment it starts controlling product. The instrument is the other contested object: a signal source to automation and a measuring device to metrology, so calibration ownership has to be named rather than assumed to sit with the other party.
Not at a device type but at a consequence. The practical test is whether a change to the thing can alter, halt or misreport a physical process — if it can, it is governed on operational terms regardless of how ordinary the hardware looks. Historians, interface servers and engineering workstations sit in the contested middle, which is exactly why each needs an explicit owner rather than an inferred one.
Because availability, safety and assurance constraints bind at the same time. A patch may require a process stop, may fall outside a supplier compatibility statement, and may alter behaviour that was verified against a defined configuration. None of those are reasons to leave a system unpatched; they are reasons the decision needs an assessment and a window, and why a cadence measured in quarters can be a considered position rather than neglect.
It has to be assigned rather than assumed, because both have a real claim: metrology owns measurement traceability and the standards chain, automation owns the range, scaling and diagnostic behaviour that decide whether a correct value arrives correctly at the controller. Leaving it implicit produces the transmitter that is calibrated accurately and scaled wrongly, where every downstream record is consistently and invisibly off.
CAPABILITY BRANCH MAP
The shape of the control estate: control philosophy, the layering of equipment, supervisory and operations systems, platform and vendor choices, integration approach and who owns each layer.
Architecture decides what can be changed independently later. A tightly coupled estate means every upgrade is a site-wide project, which is why obsolete control systems stay in service long past the point where they can be patched or supported.
The measurement layer: sensors, transmitters and analysers, their ranges and accuracy, diagnostics, calibration interface and how they physically connect to the process.
Every control action and every recorded value begins at an instrument. An instrument that is correctly calibrated but wrongly installed or badly ranged produces credible numbers that do not describe the process.
The control systems themselves: controllers and input/output, control modules, operator interfaces, supervisory functions and the boundaries between one system and the next.
These systems execute the process, and the operator interface is where a human forms their understanding of what the plant is doing. A display that shows values without context produces confident wrong decisions during upsets.
Procedural control: master recipes, phases and unit procedures, parameter sets, versioning and the execution record the batch leaves behind.
The recipe is the executable form of the approved process. When recipe versioning is weak, the question "which version made this batch" has no reliable answer, and the batch record cannot be tied to the process that was validated.
The layer that tells people something is wrong and the layer that acts without them: alarm rationalisation and priority, limits, interlocks, bypass control, testing and defined response.
Alarm floods are a documented cause of major industrial incidents. An operator receiving hundreds of alarms in an upset cannot prioritise, and the alarm that mattered is indistinguishable from the ones that did not.
The operational data layer: time-series collection, tag naming and context, time synchronisation, retention, interfaces to analytics and whether the stored data are fit for the decisions taken on them.
Historian data are used for investigations, trending and increasingly for models. Data compressed for storage efficiency or stamped by unsynchronised clocks will support a confident conclusion about a sequence of events that did not happen in that order.
What the control systems run on: network zones and conduits, time services, virtualisation, remote access, backup and restore, availability and the obsolescence of the infrastructure layer.
Operational technology cannot be patched or rebooted on an IT schedule, so it accumulates exposure that ordinary IT practice would have removed. Remote access is the highest-value control here, and it is the one most often granted informally to a vendor and never revoked.
Everything that defines behaviour: controller logic, code, parameter sets, libraries, baselines and versions, plus the testing, deployment and rollback around each change.
Control logic is software that usually escapes software discipline. Where the authoritative copy is whatever is loaded in the controller, a failure means recovering from an engineer’s laptop and hoping it is current.
The automation system across its life: requirements, design, factory and site acceptance testing, commissioning, assurance, ongoing support, patching, change and eventual retirement.
Automation systems outlive the projects that install them and the people who configured them. Support arrangements made at handover determine whether the system can be safely changed in year eight, when the original integrator is gone.
Control beyond fixed set points: real-time process measurement, multivariate models, optimisation and closed-loop control — with the human oversight and fallback that must remain around them.
Real-time release and advanced control move the quality decision from the laboratory to the model. That is a genuine gain and a transfer of risk: the model becomes a critical control, and its degradation is silent in a way an out-of-specification result is not.
CONNECTED OPERATING MODEL
MATURITY ORIENTATION · SPEQ SYNTHESIS
HIGH-VALUE INTERSECTIONS
SOURCE BASIS
REGULATORY BASIS
The 10 standards SPEQ maps to this pillar, and the 7 regulatory bodies behind them. Which standards belong to a pillar is a SPEQ judgement; the bodies, disciplines and industries below are read from the standards themselves.
EMA · FDA · ICH · IEC · ISPE · MHRA · PIC/S
Ranked by how many of this pillar’s standards each one cites — showing 10 of 49.
These 12 standards govern the system classes this pillar depends on rather than the pillar itself. The distinction matters: a standard that governs a system is not thereby a standard of every capability that uses it.
21 CFR Part 211ASTM E2500ISPE Baseline Guide Vol. 5 (2019)EU GMP Annex 15PIC/S PE 009-16ICH Q10ICH Q8(R2)ICH Q9(R1)ICH Q14ICH Q2(R2)FDA Process Validation Guidance (2011)USP <1058>
PROFESSIONAL · READINESS ORIENTATION
Rate observable operation from 0 (not established) to 4 (adaptive). The protected output prioritizes operating dimensions and evidence—not a compliance score.