Automation and Process Control Data

📍 Where we are: We move one rung up from the instruments themselves to the automation layer that reads them, runs the process, and turns their signals into structured records.

In the previous chapter, Instruments and Sensors as Data Sources, we met the physical devices that sit closest to the process stream — the in-line and on-line probes and spectrometers that measure temperature, pH, dissolved oxygen, or the chemical fingerprint of a culture. But a sensor on its own is just a voltage. Something has to read it many times a second, decide what to do about it, push a pump or a valve in response, and write down what happened. That "something" is the automation and control layer, and it is one of the busiest data factories in the entire plant.

This is the silent machinery between the sensor and the database. It does not just observe the process — it runs it, and in doing so it emits a continuous stream of numbers, alarms, operator actions, and recipe values that will later become the official record of how the batch was made.

The simple version

Think of an aircraft autopilot. Sensors report the plane's altitude and speed; the autopilot compares them against the flight plan and nudges the controls to stay on course; and a flight data recorder logs every reading and every adjustment. A modern bioreactor works the same way. Controllers hold each condition on its target, and a "flight recorder" captures the whole run — the data that proves the medicine was made correctly.

What this chapter covers

We will climb the control hierarchy from sensor to controller to the screens operators watch; meet the ISA-88 standard that gives batch recipes their shape; catalog the four kinds of data this layer emits; touch on the modern equipment and interfaces it runs on; and see why all of this becomes the backbone of the electronic batch record.

From sensor to setpoint: the control hierarchy

Automation in a process plant is organized as a layered stack, often called the Purdue model — the same layered model formalized, under different names, in the ISA-95 standard (internationally identical to IEC 62264) as Levels 0 through 4 [2][3]. For this chapter we only need the bottom of that stack: Level 0 is the physical process with its sensors and actuators, Level 1 is the controllers, and Level 2 is supervision; Level 3 is the MES (Manufacturing Execution System), which schedules and tracks batches, and Level 4 is enterprise planning and business systems. The chapter Architecture and Integration: ISA-95 lays out all five levels in full, so here we stay close to the equipment.

Closed-loop control: the feedback heartbeat

At Level 1 sit the workhorses: the PLC (Programmable Logic Controller), a rugged industrial computer, and the DCS (Distributed Control System), a network of controllers that work together to run an entire process or plant in a coordinated way. A PLC lives squarely at Level 1 (basic control). A DCS is broader: it provides Level 1 basic control and the Level 2 supervisory functions above it, so it spans Levels 1-2 rather than sitting on one rung — the Architecture and Integration: ISA-95 chapter details exactly where each lands. In a real biopharm plant these are recognizable products: a Siemens SIMATIC S7-1500 PLC driving a skid, or an Emerson DeltaV, Yokogawa CENTUM, or ABB Ability System 800xA DCS coordinating a whole suite. These devices read sensors and drive actuators dozens of times per second. The logic they run is itself standardized: IEC 61131-3 defines the programming languages — such as Structured Text, Ladder Diagram, Function Block Diagram, and Sequential Function Chart (well suited to the step sequences of the ISA-88 batch standard, introduced below) — in which control engineers write that logic [6].

The core job of a controller is closed-loop control. It compares the process value (the live measurement — say, the broth at 36.4 °C) against the setpoint (the target — 37.0 °C) and acts to close the gap, adjusting a heater until the two match. The difference between them, the error, is what the controller works to drive toward zero. This single idea — measure, compare to target, correct, repeat — is the heartbeat of the plant. It runs continuously through every physical step the first book describes: the same loop holds the production bioreactor at temperature for two weeks, ramps the seed train vessels through their splits, and steers the gradient on a capture chromatography column. Each loop reads from the instruments of the previous chapter and writes back a setpoint.

It is worth following one loop all the way downstream, because the data this layer emits is not only an upstream-bioreactor story — every purification step is automated the same way. On a Protein A capture column (the affinity step that grabs the antibody out of the clarified harvest), the controller runs the load-wash-elute-clean cycle as an ISA-88 sequence, but the moment that defines the batch is pooling: a UV-A280 sensor watches the eluate, and when the absorbance climbs past a start threshold the controller opens the collect valve, then closes it at the trailing cut point, so the operator keeps only the slice of the elution peak between the two cuts. That decision is a closed loop on a measured value just like temperature control, and it throws off the same four streams — the UV trace as a tag time-series, the pooling start and stop as operator-or-controller events, an alarm if breakthrough rises during load, and the cut-point setpoints as as-executed recipe values. The same pattern recurs across the downstream train: a setpoint and a sensor steer the low-pH viral-inactivation hold (a controller holds the pool near pH 3.5 for a timed inactivation window), the salt gradient on a polishing ion-exchange column, the transmembrane-pressure loop and the integrity-test result on a viral filter, and the concentration-and-diafiltration endpoint of UF/DF. Downstream control is, if anything, richer in batch-defining decisions than upstream, because each pooling window and each endpoint is a one-shot quality call captured forever in the record.

The workhorse algorithm inside that loop is the PID controller — proportional-integral-derivative. Rather than slamming the heater fully on whenever the broth is cold, a PID controller blends three terms: a proportional response sized to the current error, an integral term that accumulates past error to erase any stubborn offset (a small gap that lingers and will not close on its own), and a derivative term that anticipates where the error is heading and damps overshoot (shooting past the target before settling back). Tuned well, the result is a temperature that settles onto setpoint smoothly and holds there. Real bioreactor conditions, though, are rarely held by a single loop. Two patterns recur. Cascade control nests one loop inside another: a "master" loop on the broth temperature does not drive the heater directly — it computes a setpoint for a faster "slave" loop on the jacket-water temperature, which in turn drives the valve. The fast inner loop rejects disturbances (a swing in cooling-water supply) long before they reach the broth, so the slow outer loop sees a steadier process. Split-range control lets one controlled variable command two opposing actuators: a single temperature loop opens a heating valve over the lower half of its output range and a cooling valve over the upper half, so one setpoint smoothly governs both warming and chilling. Dissolved-oxygen control is the classic biopharma split-range case — one DO loop cascades through a ranked sequence of agitation, then gas-flow, then oxygen-enrichment actuators to hold the cells supplied as their demand climbs. Each of these structures multiplies the data the loop emits: a cascade loop logs two setpoints and two process values where a naive reading expects one.

Closed-loop control is also exactly the capability the FDA's 2004 Guidance for Industry — PAT: A Framework for Innovative Pharmaceutical Development, Manufacturing, and Quality Assurance set out to encourage [12]: real-time process control, built on continuous sensing and the PLC/DCS automation that acts on it, as the preferred path to building quality into a process rather than testing for it afterward. Which parameters get a controller and a setpoint in the first place is not arbitrary either: that control strategy is shaped by the ICH (International Council for Harmonisation) quality guidelines — notably Q8(R2) (Pharmaceutical Development), which frames quality-by-design and the link from critical process parameters to product quality, and Q9 (Quality Risk Management) and Q10 (Pharmaceutical Quality System), which steer attention toward the parameters that actually drive that quality [13][14][15]. For continuous and perfusion processes, the more recent Q13 (Continuous Manufacturing) extends the same control-strategy thinking to a steady-state run rather than a discrete batch [16].

Above the controllers, at Level 2, sits SCADA (Supervisory Control and Data Acquisition) and its visible face, the HMI (Human-Machine Interface) — the screens through which operators watch trends, change setpoints, and respond to problems [2]. The operator rarely touches a sensor directly; they act through the HMI, and every action they take is a data point in its own right.

The automation layer doesn't just act on data — it manufactures a new class of it: setpoints, alarms, and as-executed recipes. Original diagram by the authors, created with AI assistance.

ISA-88: the grammar of a batch

Most biologics today are still made as a batch process — a defined quantity of product run as a sequence of ordered steps (continuous/perfusion processing, which we meet later, is the growing exception). To keep batch automation consistent and portable across vendors and sites, the industry uses ISA-88 — specifically Part 1 (ANSI/ISA-88.00.01-2010; its 1995 predecessor was adopted internationally as IEC 61512-1:1997), which defines the models and terminology for batch control — a standard that gives batch control a shared vocabulary and a layered set of models [1]. Its roots reach back to NAMUR's earlier recommendation NE 33, which laid out the first requirements for recipe-based operation and directly informed ISA-88 [4].

ISA-88 separates two things that plants used to tangle together: the equipment (what you have) and the procedure (what you do with it) [1][7]. The physical model breaks the plant into a hierarchy — site, area, process cell, unit (for example, one bioreactor), equipment module, control module. The procedural model mirrors it with procedures, unit procedures, operations, and phases (the smallest reusable action, such as "transfer" or "inoculate"). Keeping the two apart is what lets a recipe be written once and reused on different equipment [7].

ISA-88 recipe types: from general to control

The recipe is the heart of it. ISA-88 defines a recipe as it travels and is refined through four forms [1]:

• A general recipe is equipment-independent — the product's essential know-how, the science of how to make it.
• A site recipe adapts that to a particular plant.
• A master recipe binds the procedure to specific equipment and becomes the template a batch is run from.
• A control recipe is a single live instance of the master recipe for one actual batch — and, once the batch finishes, it carries the as-executed values: what really happened, not just what was planned.

The master-vs-control gap: plan versus reality

When a recipe has to leave the control system and travel to other software — an MES, a scheduler, an analytics platform — it is commonly serialized (written out into a transmittable file format) in BatchML (Batch Markup Language), the XML implementation of ISA-88 maintained by MESA International alongside B2MML (the ISA-95 implementation), which the Connectivity and Interoperability Standards chapter discusses. A control-recipe parameter then looks roughly like this:

<RecipeElement>
  <ID>INOCULATE.Temperature.Setpoint</ID>
  <Parameter>
    <Value><ValueString>37.0</ValueString><UnitOfMeasure>degC</UnitOfMeasure></Value>
  </Parameter>
</RecipeElement>

note

The gap between the master recipe (the plan) and the control recipe (the reality) is exactly where the most valuable manufacturing data lives. The plan says "hold 37.0 °C for 14 days." The as-executed record says "held 36.8 to 37.1 °C, with two brief excursions on day 6." Quality is judged on the second story, not the first.

Anatomy of a control-recipe parameter

Strip away the XML and a recipe parameter is just one structured row. It is worth dissecting, because this is the exact shape the data carries from the control system, through the historian, into analysis — and the shape the third book implements as a concrete database row. A single setpoint is never a bare number; it is a small identity card.

A control-recipe parameter is a dated, sourced, related row — a recipe_id, a setpoint name, a value and its unit, and the effective dating (valid_from / valid_to) that records exactly when each target was in force. Original diagram by the authors, created with AI assistance.

Two fields do the quiet work. The name carries the ISA-88 structure — INOCULATE.Temperature.Setpoint names the phase, the variable, and the role in one string, so the parameter is self-describing rather than a loose number bolted onto a comment. The effective dating — valid_from and valid_to — is what turns a setpoint into history: when an operator raises the target mid-run, the old row is closed (its valid_to is stamped) and a new row opens, so the record can later answer not just "what was the setpoint?" but "what was the setpoint at 10:42 on day 6?" Without effective dating, an as-executed reconstruction is impossible. This is precisely the artifact the third book builds in The Batch and Equipment Model, where the ISA-88 recipe parameter becomes an s88.recipe_parameter row with valid_from / valid_to columns — the physical setpoint of the production bioreactor, captured here as a data record, lands there as a literal SQL row.

The same parameter as a semantic triple

A SQL row makes the parameter queryable inside one database; making it mean the same thing across systems takes one more step, and it is worth seeing because it is exactly what the fourth book formalizes. The self-describing name string and the typed value are already most of the way to a semantic triple — an RDF statement of the form subject — predicate — object — where the tag and its setpoint carry a global identity rather than a local key. Rendered in Turtle (the standard text notation for RDF triples), the INOCULATE.Temperature.Setpoint parameter becomes:

# the inoculation temperature setpoint as a globally identified, unit-bearing triple
bp:BR101-INOCULATE-TempSP a bp:RecipeParameter ;
    qudt:numericValue "37.0"^^xsd:float ;   # the value, typed as a number, not text
    qudt:hasUnit unit:DEG_C ;               # the unit as an IRI, so 37.0 can never be misread as Fahrenheit
    bp:validFrom "2024-06-14T10:42:00Z"^^xsd:dateTime .

Two disciplines from the ontology book are doing the load-bearing work here. The first is the IRI (Internationalized Resource Identifier — a globally unique web name): bp:BR101.Temp.SP resolves to one tag and one tag only, so the Reactor2_TI-versus-BR101.Temp.PV clash that turned every downstream join into a manual reconciliation simply cannot arise — the Identifiers and Units chapter shows why a persistent IRI beats a local primary key, and why a unit must travel as data (via QUDT, the Quantities, Units, Dimensions and Types vocabulary) rather than as a column header or a comment. The second is that "a value never travels bare" is not just good advice — it can be a gate. A SHACL shape (the Shapes Constraint Language validates that graph data has a required structure) rejects any recipe parameter that arrives without a unit or with a missing setpoint, the closed-world check the release-gate chapter turns into a release decision; the corresponding competency question (a question the model must be able to answer, the executable acceptance test of the specification) is simply "does every stored setpoint carry a unit — no bare numbers?"

The master-vs-control gap maps just as cleanly onto PROV-O (the W3C provenance ontology). The planned value is one claim, attributed to the master recipe; the as-executed value is a second claim, attributed to the control system that ran the batch; and an operator's mid-run change is a third, attributed to the person who signed it. Modeling them as three prov:Entity claims with their own prov:wasAttributedTo edges — rather than silently overwriting the plan with reality — is the provenance discipline that keeps the audit trail intact, and it is exactly why the as-executed record can answer who set this target, and on what evidence and not merely what the target was. The deeper ontological point is the one BFO and the upper spine draws: the temperature quality of the broth is a continuant that inheres in the material and exists only in that one vessel, while the setpoint record is an information artifact you can copy, log, and email without moving the broth — keeping the thing and the record-about-the-thing distinct is what lets the same 37.0 live as a physical control action, a historian sample, and a release-record line without the model ever claiming the number is the temperature.

What the automation layer actually emits

Running the process generates four broad streams of data, and understanding their shapes is essential to managing them downstream. None of them is the final record on its own; the MES (next chapter) braids all four into the electronic batch record.

The four streams the control layer emits converge in the MES to form the EBR; the lower panel shows why the as-executed trace, not the flat plan, is the data that matters. Original diagram by the authors, created with AI assistance.

Four data streams: tags, alarms, operator actions, recipe parameters

Tag time-series. A tag is a single named, addressable variable in the control system — BR101.Temp.PV for bioreactor 101's temperature process value. A single bioreactor exposes dozens of such tags, following a consistent naming convention: BR101.pH.PV, BR101.DO.PV (dissolved oxygen), BR101.Agit.PV (agitation speed), BR101.Temp.SP (the temperature setpoint), BR101.AcidPump.OUT (the controller's output command to the acid pump), and so on. It is worth being precise about how fast these numbers move, because three different rates are easy to conflate. The scan rate is how often the controller itself reads the sensor and updates the loop — often many times a second (sub-second cycle times are routine inside a PLC or DCS). The log rate is how often the historian above it is asked to record a value — frequently once per second or once every few seconds, because storing every controller scan for thousands of tags over weeks is rarely worth the cost. And the compression rate is the effective rate that survives after the historian's deadband filter discards points that fall on a predictable trend (the swinging-door algorithm discussed later), so a flat signal may write only a handful of points an hour while a moving one writes many. The loop runs fast; the historian logs slower; compression thins it further. Even after all three, the result is a dense high-frequency archive — thousands of tags, each a long column of timestamped numbers. Written out, a few rows of one tag's history are about as plain as data gets:

timestamp,            tag,            value, unit
2024-06-14T10:05:23Z, BR101.Temp.PV,  36.95, degC
2024-06-14T10:05:24Z, BR101.Temp.PV,  36.96, degC
2024-06-14T10:05:25Z, BR101.Temp.PV,  37.01, degC

This is the raw, dense material that the process historian (next chapter) is built to store, and that later multivariate analysis (modeling many process variables together, Part V) depends on.

Tagging strategy: naming conventions and consistency

The naming convention is not cosmetic — it is the first and cheapest layer of data management, and the easiest to get wrong. A disciplined scheme like BR101.Temp.PV reads as unit . measurement . role, so a human or a query can immediately tell that this is the temperature process value on bioreactor 101, distinct from BR101.Temp.SP, the setpoint. When a site enforces one convention across every unit, a query for "all temperature PVs" is trivial and a model can line up the same variable across batches. When two units name the same thing differently — BR101.Temp.PV here, Reactor2_TI there — every downstream join becomes a manual reconciliation, and the inconsistency propagates into the historian, the plant information systems, and every analysis built on top — and even a perfectly consistent naming scheme only postpones the deeper question of what a tag means across systems, which Why Numbers Don't Connect and Ontologies and FAIR Data take up. The discipline matters most at the boundary where tags cross into other software: the third book shows how an OPC UA / MQTT connectivity layer carries each tag with its identity intact, so nothing downstream has to guess what BR101.Temp.PV means.

Alarms and events (A&E). When a process value crosses a configured limit, the system raises an alarm — an audible or visual signal demanding operator attention. ISA-18.2 is the authoritative standard for managing these: it defines an alarm's full lifecycle and insists on rationalization (deciding which alarms are genuinely necessary) and prioritization so operators are not buried in noise [5]. Each alarm and each routine event is a timestamped record of something the process did or that an operator was told — typically carrying a timestamp, a source tag, an alarm identifier, a human-readable message, and a priority, like this:

timestamp,            tag,           alarm_id, message,            priority
2024-06-14T10:42:11Z, BR101.Temp.PV, TI-101-HI, Temperature High,  HIGH

Operator actions. Every setpoint change, manual override, batch start or hold, and acknowledgment made through the HMI is logged. Under U.S. regulation 21 CFR Part 11 and the EU's GMP (Good Manufacturing Practice) Annex 11 (EudraLex Volume 4, "Computerised Systems"), electronic records like these must be trustworthy and, where required, tied to electronic signatures identifying who did what and when [8][10].

Recipe parameters and their as-executed values. Finally, the layer records the recipe parameters it was given and the values it actually achieved — the marriage of plan and reality described above, and dissected in the anatomy card.

ISA-18.2 alarms: rationalization and noise

Of the four streams, alarms are the one most often left to rot. A control system can raise an alarm on almost any limit, and the path of least resistance is to enable many of them — which buries the operator in a flood where the one alarm that matters is lost among hundreds that do not. ISA-18.2 answers this with rationalization: a deliberate review of every configured alarm to decide whether it is genuinely necessary, what priority it deserves, and what response it demands. A rationalized system is quieter and, paradoxically, safer — when an alarm fires, it means something. For data management the payoff is downstream: an alarm log that has been rationalized is a clean, interpretable event stream, while an un-rationalized one is mostly noise that swamps any attempt to correlate alarms with process excursions. The standard also defines an alarm's full lifecycle — normal, raised, acknowledged, returned-to-normal, shelved — so that each state change is itself a timestamped, analyzable event [5].

Audit trails and trustworthiness

A critical thread runs through all four: the audit trail. The FDA defines it as a secure, computer-generated, time-stamped record that lets a reviewer reconstruct the course of events, and it expects these trails to be reviewed [9]. Tags, alarms, and operator actions only become trustworthy records when the layer captures them in a way no one can silently alter.

The standard a reviewer holds these records to has a name: ALCOA+, the data-integrity expectation that every record be Attributable, Legible, Contemporaneous, Original, and Accurate, plus the later additions Complete, Consistent, Enduring, and Available. Read against this chapter, the four streams are an ALCOA+ checklist: a contemporaneous timestamp is exactly what NTP/PTP clock discipline protects; complete and original are precisely what an over-aggressive compression deadband destroys when it erases a real excursion; and attributable is what an operator's electronic signature on a setpoint change supplies. The point is not that the automation layer happens to satisfy ALCOA+ — it is that the layer's design decisions (which deadband, which clock source, whether actions are signed) are the data-integrity controls, made years before any inspector reads the record.

There is a second, quieter consequence: a record is only as trustworthy as the system that produced it, and under 21 CFR Part 11 and EU GMP Annex 11 that system must itself be validated before its records may be relied on. For a DCS or MES that means IQ/OQ/PQ — Installation, Operational, and Performance Qualification, the proof that the system was installed right, operates right, and performs right for its real workload — and increasingly the lighter, risk-based posture of CSA (Computer Software Assurance), the FDA's shift from documenting every test identically toward spending assurance effort where patient risk actually lives. The Validating Computerized Systems: GAMP 5 and CSA chapter develops this in full; what matters here is that the critical functions of this layer — the pooling-window cut points, the as-executed recipe values, the alarm logic, the audit-trail capture — sit at the high-risk end of that scale and earn the most rigorous proof, while a non-critical display field earns a lighter check.

The equipment underneath

Modern biomanufacturing increasingly runs on single-use systems — sterile, disposable plastic assemblies — and skids, which are pre-assembled, self-contained units (a chromatography skid, a buffer-prep skid) that arrive with their own local controllers and tags. Single-use platforms from vendors like Sartorius (the BIOSTAT STR stirred-tank bioreactor, or the ambr bench-scale system) and Cytiva (the Xcellerex XDR series) ship with controllers embedded in the skid hardware, each carrying its own tag namespace. Each skid is thus a small island of automation that the site must integrate into the larger whole.

The bridge that carries a skid's data to the rest of the plant is most often OPC (Open Platform Communications) — a family of open interface standards (the older OPC is now largely superseded by OPC UA, for Unified Architecture) that lets controllers and software from different vendors exchange tags and events using a standard protocol, reducing the custom point-to-point wiring every pairing used to require. It does not erase integration work entirely: both ends must support the OPC UA specification, and the meaning of each tag — what BR101.Temp.PV actually represents — still has to be mapped between systems. OPC lives at the edge between the control layer and the information systems above it. (We treat OPC UA and the broader connectivity standards in depth in Connectivity and Interoperability Standards.)

A newer answer to the "island of automation" problem goes one step further than OPC. The MTP (Module Type Package) standard — VDI/VDE/NAMUR 2658, born in the process industries and increasingly applied to single-use bioprocess skids — describes a module's services, its tags, its HMI screens, and its alarms in a single vendor-neutral package that travels with the skid. Instead of an integrator hand-mapping each new skid's tags into the site's orchestration layer, a process-orchestration system reads the MTP file and the module becomes "plug-and-produce." The promise for data management is precise: a skid that arrives with a well-formed MTP arrives with its tag semantics already declared, so the meaning that OPC UA alone leaves to manual mapping is carried in the package itself. Adoption is still early in biopharma, but it is the clearest current attempt to make modular skids integrate themselves rather than waiting on a custom engineering project. Declaring a tag's meaning, not just its address, is the deeper problem this book takes up in Why Numbers Don't Connect and the Ontologies and FAIR Data chapter, where shared vocabularies replace hand-mapping for good.

Why it matters

Here is the payoff for data management: the streams this layer emits are not a byproduct of manufacturing — they are the official manufacturing record. The electronic batch record (EBR), the legal document attesting that a batch was made correctly, is one the MES (next chapter) assembles largely from this control and recipe data: the as-executed parameters, the operator signatures, the alarm history, and the tag trends [8][9]. Carrying that data cleanly from the control floor up to the MES and ERP is itself an engineering problem — the third book devotes a chapter to bridging the DCS, MES, and ERP without losing the structure the streams arrived with.

Because that record carries regulatory weight, the way the automation layer structures its data has consequences far downstream. If tags are named inconsistently across units, if alarms are not rationalized, if operator actions are not signed, or if the audit trail can be edited, then the EBR — and every analysis built on top of it — inherits those flaws [5][9]. Conversely, a clean, ISA-88-structured, well-tagged control system is what makes later multivariate analysis possible at all: you can only model a process whose data is consistently labeled, time-aligned, and trustworthy.

What is still hard: timestamps and compression artifacts

For all the structure ISA-88 and ISA-18.2 impose, two quietly corrosive problems remain genuinely open in this data flow, and both attack the as-executed record that quality depends on.

The first is timestamp misalignment. Tags, alarms, operator actions, and recipe values are stamped by different clocks — a skid's local controller, the DCS, the SCADA server, the historian — and those clocks drift. When the streams are later merged into one EBR, a setpoint change logged at 10:42:03 by the HMI and the temperature excursion it caused, stamped 10:41:58 by the bioreactor, can appear in the wrong order. The cause looks like it follows the effect. The fix in principle is to discipline every clock to one common time source: NTP (Network Time Protocol) synchronizes networked devices to within milliseconds and is the usual baseline, while PTP (Precision Time Protocol, IEEE 1588) reaches sub-microsecond accuracy where the sequence of fast events truly matters. Reconstructing the true sequence of events — which the FDA's data-integrity guidance treats as a core function of the audit trail [9] — becomes guesswork unless every clock is held to such a source, and in practice many sites run a patchwork of unsynchronized or loosely synchronized clocks instead.

The second is more insidious: compression artifacts. Historians do not store every sample; to keep decades of thousands of tags affordable, they apply swinging-door (deadband) compression, discarding points that fall within a tolerance band around a straight-line interpolation and keeping only the points that define the shape of the trend. Tuned well, this is lossless for any change that matters. Tuned too aggressively — a deadband set wide to save space — it silently erases brief but real excursions: the two-minute temperature spike on day 6, the kind of event quality review most needs to see, is compressed out of existence because it never moved far enough or long enough to survive the filter. The data looks clean precisely because the evidence was thrown away. PIC/S (Pharmaceutical Inspection Co-operation Scheme) guidance on data management and integrity is explicit that records must remain complete and the original activity reconstructable [11]; a compression setting that cannot reproduce a real excursion violates both, yet the setting is buried in historian configuration that few reviewers ever audit. There is no clean technical fix that satisfies cost and completeness at once — only a deliberate, documented, risk-based choice of deadband per tag, revisited as the process is understood. It is one of the places where good intentions about storage efficiency quietly undermine the trustworthiness of the record.

Why this matters for modeling: leakage, splits, and drift

These two artifacts are not only regulatory liabilities — they decide whether a model built on this data can be trusted at all, which is why the fifth book treats the control layer as the fuel for machine learning. Three connections are worth naming. First, timestamp misalignment is a data-leakage trap. If a model is trained to predict a quality outcome and the merged record places an effect before its cause, the model can "learn" to use information that was not actually available at prediction time — the kind of leakage the Models and Validation chapter warns silently inflates a score until it fails in production. Second, compression shapes what a model can even see: a soft sensor trained on a tag whose brief excursions were compressed out is being shown a smoother, tamer process than the real one, so it is most wrong exactly during the events that matter most. Third — and most consequential — the right way to test a bioprocess model is a leave-one-batch-out (or batch-grouped) cross-validation: hold out whole batches, never random rows, because rows within one batch are not independent. A random-row split lets the same batch's neighbouring samples sit in both the training and the test set, which flatters the score the way a leaked timestamp does; the Data, the Fuel chapter argues the binding constraint is the number of independent batches, not the number of dense rows. The naming discipline this chapter pressed for is the precondition for all of it: only a consistently tagged, time-aligned archive can be split by batch and grouped by variable in the first place.

There is also a clean parallel between this layer's two hazards and two ideas the ML book builds. Process drift — the living cell line and its hardware wandering campaign to campaign — is the physical cousin of model drift, the silent decay of a deployed model as the world moves away from what it was trained on; the MLOps and Lifecycle chapter shows that a model watching a drifting process must itself be monitored, because a static model implicitly assumes a stationary process this layer can never guarantee. And the applicability domain — the envelope of inputs a model was validated over, outside which its prediction is not to be trusted — is the modeling counterpart of the qualified operating range a control loop runs inside; both say the same thing, that a number is only trustworthy where the evidence behind it actually reaches.

In the real world

ISA-88 and ISA-95 are not academic ideals; they are the lingua franca of vendor batch software — products like Siemens Opcenter Execution Pharma, Körber's PAS-X, and Emerson Syncade — and the way real plants describe their processes to an MES (Manufacturing Execution System), the Level 3 system that orchestrates batch execution [2][3]. A modern facility running intensified single-use perfusion processes relies on the same language: its skids, controllers, and historians speak it too — tags flowing up through OPC, recipes phrased in ISA-88 terms, alarms managed against ISA-18.2 expectations, and audit trails kept to Part 11 standards [1][5][8]. The standards are what let a process developed in one facility be transferred to another and still produce data that looks the same.

Key terms

• Control hierarchy (Purdue / ISA-95 levels) — the layered stack from sensors (Level 0) through controllers (Level 1) and supervision (Level 2) to plant and business systems (Levels 3-4).
• PLC / DCS — a Programmable Logic Controller (Level 1 basic control) and a Distributed Control System (spanning Levels 1-2, basic plus supervisory); the industrial computers that run closed-loop control.
• SCADA / HMI — the supervisory layer and its operator screens.
• Closed-loop control — continuously comparing the process value to the setpoint and correcting the difference.
• PID controller — the proportional-integral-derivative algorithm most loops use; blends present, accumulated, and predicted error to settle on setpoint without overshoot.
• Cascade / split-range control — a master loop driving a faster slave loop's setpoint (cascade), and one loop commanding two opposing actuators such as heating and cooling, or the agitation-gas-oxygen sequence for dissolved oxygen (split-range).
• Setpoint vs. process value — the target a controller aims for vs. the live measurement it reads.
• ISA-88 (IEC 61512) — the batch control standard separating equipment from procedure and defining recipe types.
• Recipe types — general, site, master, and control recipes; the last carries the as-executed values.
• Phase — the smallest reusable procedural action in ISA-88.
• Tag — a single named variable in the control system, sampled into high-frequency time-series.
• Scan vs. log vs. compression rate — the rate the controller reads a sensor (fast), the rate the historian records a value (slower), and the effective rate that survives deadband compression (thinner still).
• Alarms and events (A&E) — timestamped signals (governed by ISA-18.2) that something needs attention or was logged.
• Audit trail — a secure, time-stamped record letting a reviewer reconstruct what happened.
• ALCOA+ — the data-integrity expectation that records be Attributable, Legible, Contemporaneous, Original, and Accurate, plus Complete, Consistent, Enduring, and Available; the standard a reviewer holds the four streams to.
• IQ/OQ/PQ vs CSA — the traditional Installation/Operational/Performance Qualification proof that a control system works, and the FDA's risk-based Computer Software Assurance posture that scales that proof to patient risk rather than testing every function identically.
• Pooling window (downstream control) — the slice of a chromatography elution peak, between two UV-threshold cut points, that a controller collects as product; a one-shot, batch-defining closed-loop decision captured in the record.
• Semantic triple / IRI — an RDF subject — predicate — object statement that gives a tag and its setpoint a globally unique web name (IRI), so the same parameter means the same thing across systems rather than being a local key.
• SHACL gate / competency question — a closed-world shape that rejects a recipe parameter arriving without a unit or with a missing setpoint, and the executable acceptance question ("no bare numbers?") it answers.
• PROV-O provenance — modeling the planned, as-executed, and operator-changed values as separately attributed claims rather than overwriting the plan, so the record answers who set this and on what evidence.
• Leave-one-batch-out cross-validation — testing a model by holding out whole batches, never random rows, because rows within one batch are not independent; random-row splits leak and flatter the score.
• Process drift vs model drift; applicability domain — the living process wandering campaign to campaign (process drift), its silent counterpart in a deployed model (model drift), and the input envelope outside which a model's prediction is not trustworthy (applicability domain), the modeling cousin of a control loop's qualified operating range.
• Electronic batch record (EBR) — the legal record that a batch was made correctly, assembled largely from control data.
• Single-use / skid — disposable plastic process assemblies and pre-built self-contained units with their own controllers.
• OPC — an open interface standard for exchanging tags and events between vendors' systems.
• MTP (Module Type Package) — VDI/VDE/NAMUR 2658; a vendor-neutral package describing a skid's services, tags, screens, and alarms so a module integrates "plug-and-produce" rather than by custom mapping.
• NTP / PTP — Network Time Protocol (millisecond) and Precision Time Protocol, IEEE 1588 (sub-microsecond); the clock-synchronization standards that let separate systems' timestamps be reconciled into one trustworthy sequence.
• Effective dating (valid_from / valid_to) — the timestamps that record exactly when a recipe parameter was in force, turning a setpoint into a reconstructable history.
• Master-vs-control gap — the difference between the planned recipe and the as-executed control recipe; the gap is where the most valuable manufacturing data lives.
• Swinging-door compression — a deadband algorithm historians use to discard samples within a tolerance band; tuned too aggressively, it can erase brief but real excursions.

Where this leads

The automation layer produces the raw streams; it does not, by itself, store, organize, or reconcile them for the long term. That job belongs to a constellation of plant information systems sitting above the control layer — each owning a different slice of the data. The next chapter, The Plant Information Systems: Historian, MES, LIMS, and ELN, introduces them in turn: the process historian that swallows the tag time-series, the MES that executes the batch and assembles the EBR, the LIMS that holds laboratory results, and the ELN that records experiments — and the integration seams and data silos that open up between them.