A bioreactor control system is not the controller box on the skid. It is the whole chain that turns a condition inside the vessel into a recorded, corrected number: the probe, the transmitter, the loop that acts on it, the layer that decides what the setpoint should be, and the database that remembers all of it. Vendor pages sell one link of that chain. This article draws the full stack, layer by layer, so you can see what you are actually specifying and where a learned controller can sit without breaking anything underneath it.
One scoping note first. Which control strategy to run (open loop, cascade, model predictive, learned) is its own decision, covered in choosing a bioreactor control strategy. Here the question is the system that has to host whichever strategy you pick.
What a bioreactor control system actually is
The honest starting point is that most of these systems are simple. A review of bioreactor control systems in the biopharmaceutical industry puts classical control at over 90% of the industrial controls used in bioprocessing. The same review argues that flexible, multi-product facilities now need control systems that can be reprogrammed and reconfigured quickly, which is a statement about architecture, not about any single algorithm.
So the useful mental model is four layers, each with a different job and a different failure mode:
- Measurement chain: sensors, transmitters, actuators.
- Regulatory control: the fast loops that hold pH, dissolved oxygen, temperature and agitation.
- Supervisory control: the layer that sequences phases and decides setpoints.
- Data plane: how every value is moved, stored and made available to people and models.
A learned controller, if you add one, belongs to layer 3. It never replaces layers 1 and 2.
Layer 1: the measurement chain
What sits inside the boundary
A validation reference on bioreactor sensors and automation lists what the system boundary can include: process sensors and probes, housings and process connections, transmitters and signal converters, mass-flow controllers, pumps and variable-frequency drives, valve actuators with position feedback, the PLC or DCS, the HMI, recipe management, alarm and event handling, local and remote storage, a historian, and the network and time-service interfaces. That list is the real bill of materials of a control system. If a quote only covers the controller and the HMI, the rest is still your problem.
The same source makes a point worth taking into any specification meeting: instrumentation requirements should be set during bioreactor design, not added after the mechanical selection. Range, accuracy, response time, drift, calibration strategy and data-recording frequency all follow from the process you intend to run.
Why each link adds error
A measurement does not originate at the screen. It passes through eight steps: the process acts on the sensing element, the sensor responds, a transmitter converts the signal, the signal reaches a controller input, scaling is applied, control logic compares it with the setpoint, the controller moves an output, and the result is displayed and recorded. Each step can add error, delay, noise, lost resolution or a configuration mistake.
Criticality depends on intended use, not instrument type. A temperature sensor used for product control is a different object, for validation purposes, from a temperature indicator used only for maintenance. Tag every measurement with what it is used for before you decide how much it has to cost.
Layer 2: the regulatory controller
This is the layer most people mean when they say "bioreactor controller". It runs the loops that keep the culture inside its window, second by second, whatever the layers above it are doing.
A published Raman-assisted cell culture platform shows what that looks like on a real lab system. The control system was a G3Lab controller with TruBio DeltaV software on a 3 L glass bench-top bioreactor. Dissolved oxygen was held at 40% of air saturation using oxygen gas; pH was held within a band of 6.85 ± 0.25 for one clone using CO2 gas and 1 mol/L sodium carbonate; agitation ran at 250 rpm; initial temperature was 36.5 C. The automatic control algorithm the researchers were testing was deployed through separate process control software on top of that base.
That split is the pattern. The regulatory layer is deliberately boring: well tuned loops with alarms and interlocks. Anything clever is added above it, so that if the clever part fails, the culture is still held by loops that have been working for decades. If you are weighing whether a learned policy should replace one of these loops outright, the comparison belongs in reinforcement learning against PID, and in most bioreactors the answer is that it should not.
Layer 3: supervisory control
The supervisory layer decides what the regulatory loops should be aiming at, and when. It runs recipes and phase logic (sterilisation, inoculation, batch, feed, harvest), and it is where feed profiles, setpoint trajectories and any model-based or learned control live.
Genentech's microbial pilot plant is the clearest industrial case on record. When the plant's automation was replaced with a DeltaV architecture communicating with existing process controllers over OPC, DeltaV took over loop monitoring and automated sequences such as sterilisation and clean-in-place. Reliability and data monitoring improved, but a gap opened: process researchers could no longer implement and debug their own supervisory algorithms without close help from automation engineers. Genentech's answer was a separate, researcher-serviceable supervisory layer that interfaced transparently with the DeltaV network.
The lesson for a buyer: ask how new control logic gets deployed, and by whom. A system that only automation engineers can change will be safe and slow. A system with a defined supervisory interface lets the people who understand the biology iterate on control without touching the validated loops underneath.
Layer 4: the data plane
Every layer above depends on data moving reliably, with context, to wherever it is needed. This is the layer most often left to chance.
The Technical University of Denmark documented how it built the digital infrastructure for its pilot plant. Standardised OPC UA gateways make encrypted connections to a mix of legacy and modern unit operations. A web-based SCADA system talks to those gateways directly, while an intermediate broker organises each tag by unit operation and type and publishes all real-time data over MQTT. Containerised Python applications subscribe to the streams during experiments and write them to an SQL database. New units or sensors can be added without changing the schema or the code, and version-controlled CI/CD pipelines deploy every service reproducibly. The authors state the goal plainly: open protocols so that components can be replaced without vendor lock-in. The same infrastructure now underpins hybrid modelling and digital twin work at the university, which is the direction covered in digital twin for process control.
For a bioreactor buyer this is the test that separates a control system from a controller: can a model you have not written yet read live data and write a setpoint back through a documented, open interface?
Where a learned controller fits, and what it needs
A learned controller is a model fitted to process data, not derived by hand, that proposes actions for the supervisory layer. It earns its place when the process is too nonlinear or too variable for a fixed recipe. It also brings three requirements the classical stack never had.
A safety layer that can veto it. A learned policy is a statistical fit, so something deterministic must check each proposed action before it reaches an actuator. That is the job of a barrier-function safety filter: the policy proposes, the filter enforces the constraint set, and the regulatory loops below still hold the culture if both fail.
Inference at the process, not in a cloud. A round trip over the internet is not a control loop. The model has to be compressed and run on hardware at the reactor, which is what an edge AI deployment pipeline is for.
A validation record instead of a derivation. A mechanistic model justifies itself through physics; a learned one justifies itself through evidence. Because a culture cannot be reset the way a robot can, most of that evidence has to come from simulation, through sim-to-real validation, before the controller touches anything alive. In a GMP setting the validation reference above notes that computerized-system validation and Part 11 assessment remain separate but connected activities, so the learned layer joins that scope rather than escaping it.
Here is what that looked like in our own stack, as published on equation-labs.co. The growth model reaches an accuracy of R-squared above 0.95. The safety layer answers in under 2 ms. End-to-end edge latency, from sensor reading to actuator command, is 285 ms, down from an earlier 1.2 s. The controller was validated on a 500 L pilot basin with zero safety violations across 400 simulated years, where simulated years mean coverage of the operating envelope, not elapsed time. Structurally it sits exactly where this article places it: in the supervisory layer, behind a safety filter, above regulatory loops it never bypasses.
A checklist for specifying a bioreactor control system
Use this before you sign a quote, whichever vendor you pick.
- Boundary drawing. Which sensors, transmitters, pumps, mass-flow controllers and valves are in scope, and which belong to shared automation or facility utilities?
- Measurement requirements per tag. Range (including cleaning, sterilisation and excursion conditions), accuracy against process tolerance, response time, drift over the run, calibration strategy.
- Criticality per tag. Product control, batch release, sterile boundary, safety interlock or troubleshooting only.
- Regulatory loops. Which loops, which actuators, and what happens to each on sensor failure.
- Supervisory interface. How new recipes and control logic are deployed, by whom, and whether researchers can do it without editing validated loops.
- Data plane. Open protocols (OPC UA, MQTT) or a proprietary bus; can an external model read live data and write a setpoint?
- Data retention. Recording frequency, historian, electronic records and time synchronisation.
- Room for learned control. Latency budget from sensor to actuator, where a safety filter would sit, and how simulation evidence enters your validation package.
If the last item is where your project is stuck, that is the work we do under contract: deriving the model, building the safety layer, and taking it to edge hardware with a validation record.
FAQ
What parameters does a bioreactor control system regulate?
The usual set is pH, dissolved oxygen, temperature, agitation, pressure and feed rate. Which of them are critical depends on the organism and the product, so they should be ranked by intended use before instruments are chosen.
What is the difference between a bioreactor controller and a SCADA or DCS?
The controller runs the regulatory loops on one vessel. A DCS or SCADA coordinates many units, executes sequences such as sterilisation and clean-in-place, and records the batch. In the Genentech case above, the DCS handled loops and sequences, and a separate supervisory layer was added for research control algorithms.
Can I add advanced control to an existing bioreactor control system?
Usually yes, as a supervisory layer that reads measurements and writes setpoints through an open interface such as OPC UA, leaving the validated regulatory loops untouched. Check first that the system exposes live tags and accepts external setpoints.
Does a learned controller need GMP validation?
In a GMP facility it becomes part of the computerized system that influences the batch, so it falls inside computerized-system validation and electronic-record requirements. Simulation evidence and a deterministic safety layer are what make that case arguable.