Delivered, Not Commanded: Ten Challenges in Bioreactor Feeding Control

QB SYSTEMS WHITEPAPER

The industry spent a decade making bioprocess measurement smarter and left feed delivery on a rubber tube whose calibration expires in the autoclave. This paper maps ten places where fed-batch and perfusion feeding control breaks down, and describes what changes when the control layer is configurable while the run continues.

QB Systems | Version 1.0 | August 2026

Flexible. Innovative. Limitless.

About this document

This whitepaper describes ten recurring problems in fed-batch and perfusion feeding control, and the capabilities in QB Control and QB Modules that address each one. It rests on publicly available information: peer-reviewed literature, conference and consortium publications, regulatory documents, manufacturers’ public product documentation, and the QB Systems product catalogs and the QB Control User Manual. Every figure is attributed and labelled by source type, because a vendor case study and a peer-reviewed measurement are not the same kind of evidence and should not be presented as though they were. This paper contains no cost, price, or engineering-effort estimates of any kind. Where QB Control does not yet do something, the paper says so. Read the Methodology, Assumptions and Legal Disclaimer at the end before drawing conclusions for your own facility.

Two terms, before the numbers

If you are not familiar with the platform, two words in this paper mean something specific.

QB Control is a software-defined control platform. The logic that runs a process lives in software you configure through a browser, not in controller code that has to be written, compiled and downloaded to a device. QB Modules are the hardware that logic drives.

Term used here	Traditional automation equivalent
QB Module	a field device plus its I/O channel, wiring, I/O configuration and the controller code that drives it: a pump, mass-flow sparger, heating mat, probe, mixing drive or pressure sensor, delivered as one self-contained unit with a standard interface
Control service	a control loop: PID plus its logic, alarm limits and interlock hooks. Closed-loop pH, dissolved oxygen and temperature control; setpoint services for pump flow, gas mass flow and mixing speed; one sequenced volume transfer

So when Section 4.1 below describes two feed lines on one vessel, each a QB Module sitting on a balance, one running the Set Pump Flow Rate service and the other running Liquid Transfer Mass by Pump, that reads in traditional terms as:

two field devices running two different control loops on the same vessel, one closing on commanded pump speed and the other closing on the mass actually delivered.

Services are instantiated from templates, so the same control function can be placed more than once. The four-stream perfusion use case in Section 4.5 runs four independent loops of that kind, with no code and no download.

Two more words, to avoid a collision. A recipe is the executable procedure that starts, stops, monitors and reconfigures those services while the process runs. It is a graph of blocks rather than a script, and it is what this paper means whenever it says a change happens “in the running recipe”. Separately, the capitalised names used throughout, including Inventory, Recipe Designer, Graphs, Alarms, Notifications, Reports, Runs, Calibration, Audit Trail, and Users and Roles, are modules of the QB Control web portal: software screens, not hardware. Only “QB Module” refers to a physical device.

Executive Summary

Feeding is the one part of a bioprocess where the control system is routinely trusted to be right without ever being checked. A pump commanded to deliver 10 mL/min is assumed to have delivered 10 mL/min. A feed profile designed before inoculation is assumed to still suit the culture on day six. A control loop that turns out to be wrong on day three is assumed to be something you live with until the next run. None of those assumptions survive contact with a real campaign, and the batch record does not record that they failed.

Look across the verified 2024 to 2026 programmes of Cell Culture Engineering XIX, the ECI Integrated Continuous Biomanufacturing meetings, BPI, the Bioprocessing Summit and ESACT, and a pattern is hard to miss. Almost every dynamic feed-control presentation from large pharma is a measurement talk: Raman, capacitance, mass spectrometry, soft sensors. Almost none of them are actuation talks. Whether the feed you calculated actually reached the vessel, and whether the delivered mass matched the calculation, is largely absent from the peer conference record. Gravimetric feed control appears almost exclusively in vendor channels. That asymmetry, between a measurement layer that has become sophisticated and a delivery layer that has not, is the subject of this paper.

The deciding factor is not the quality of anyone’s pump, probe or analyzer. It is the architecture of the control layer: whether the logic that decides what to feed is a compiled schedule fixed at deploy time, or a graph you can read, edit and re-route while the vessel is running.

The challenge	The target	The approach
Feed control closes on pump command, not on delivered mass. Feed strategy is fixed before inoculation. Changing the loop structure mid-run means stopping. And every mid-run change is a compliance event before it is a software event.	A feeding strategy that can be measured against delivered mass, reshaped while the culture is running, degraded safely when an instrument drops out, and defended in an audit without a special procedure.	Gravimetric feed as a catalogue service rather than a custom integration. Feed profiles as formulas over live signals rather than compiled schedules. Strategy changes as execution-path decisions inside a running recipe. Every change captured with user, role, old value, new value, timestamp and reason.

At a glance

Ten challenges, what goes wrong today, and the use case that demonstrates the QB Systems answer on real hardware.

#	Challenge	What goes wrong today	Demonstrable use case
1	The pump lies, and the record repeats it	Rate-based feed closes the loop on pump revolutions. In-run error is silent and cumulative	Two feed lines, one vessel, rate control against gravimetric control, divergence computed by the recipe itself
2	The profile is fixed before inoculation	The feed trajectory is a compiled schedule. Reshaping it means a new version the running batch cannot pick up	An exponential profile driven by a formula over the run clock, reshaped mid-run without leaving EXECUTE
3	Changing a setpoint is easy, changing the loop is not	Platforms support value changes. Structural changes, which is where feeding strategy lives, are not runtime operations	Two feeding strategies in parallel lanes, live handover, guarded on the service’s own state machine
4	Adding hardware to a running process	Wiring, driver and binding are three stacked problems. Automation sits on the critical path for reconfiguration	A pump module and a balance plugged into a PoE switch and discovered while the process executes
5	Five pumps, one vessel weight, two degrees of freedom	Each stream gets its own single-loop controller and nobody computes mass-balance closure	Four parallel stream lanes plus a fifth lane computing live mass-balance residual against vessel weight
6	The bleed loop oscillates	A polling controller on a noisy, biased soft sensor. The standard fix trades oscillation for lag	An event-driven bleed lane with a deadband, against a polled implementation, on the same signal
7	The filter fouls and the intuitive response makes it worse	Transmembrane pressure is a derived value, rarely a first-class control signal, and often ships with no threshold	Three pressure devices, TMP computed as a recipe signal with its own alarm and a coordinated response branch
8	The analyzer is the clock, and it drops out	The feed loop has a single point of failure with no explicit, tested degradation path	A feedback lane that falls through to a documented time-based fallback when the analyte signal dies, then hands back
9	Nights, weekends, and the unwatched run	Automation covers the actuators but not the decisions. Decisions cluster into working hours	An unattended run whose decision logic executes at 03:00 and whose report is the handover the next morning
10	Mid-run flexibility is a compliance problem first	A system that can change a loop but cannot produce the audit record has moved the problem, not solved it	The same setpoint change followed through Audit Trail, role enforcement and the generated batch report

Why this is hard even with modern equipment

Feeding a culture well is not one problem. It is a chain of four, and a modern facility can be excellent at three of them and still lose the run on the fourth.

Decide what the culture needs. This is where the industry has invested: Raman, capacitance, in-line and at-line analytics, hybrid models, soft sensors.
Compute the setpoint from that measurement. Also well served, by controllers, chemometric models and increasingly by model-based schedules.
Deliver the commanded amount into the vessel. Almost entirely unexamined in the peer literature.
Prove that all three happened, in a record an inspector will accept. Governed by regulation that is getting stricter, not looser.

The gap sits in the third link, and it is not a small one. Peristaltic pumps tested open loop reached approximately 99% accuracy from beaker to beaker, yet the same pumps on the same rig showed errors of 15 to 20% during actual cultivation runs, attributed to back-pressure effects and long-term deformation of the pump tubing under continuous operation. Switching to gravimetric correction of integrated delivered mass brought the deviation to 0.5% or less. That comparison comes from a vendor case study rather than a peer-reviewed paper. It remains the best-quantified public comparison of volumetric against gravimetric feed control that exists, which is itself part of the finding.

Calibration does not survive the process either. Autoclaving pump tubing connected to a bioreactor changes the properties of the tubing significantly. Once the pump runs, liquid displacement decreases over time as the tubing stretches, and new tubing needs 15 to 30 minutes of run-in at operating speed before it can be calibrated at all.

The four architecture patterns

Feeding control is implemented in one of four broad patterns. Each reaches a working process. They differ in what happens when the process turns out to need something different from what was configured.

Pattern	How feed is controlled	What a mid-run change requires	Representative implementations
Rate-based open loop	Pump speed against a calibration curve, commanded volume recorded as delivered	Change a speed setpoint. Structural change is out of scope	Integrated bioreactor controller pumps; most benchtop and pilot rigs
Batch executive with a fixed recipe manifest	An ISA-88 style recipe compiled and deployed, devices and services resolved at deploy	A new recipe version, which the running batch generally cannot adopt	Classical DCS and batch execution environments
Supervisory software over multi-vendor hardware	A supervisory layer drives third-party pumps and balances, often with gravimetric correction	Setpoint and often parameter changes. Structural changes depend on the layer	Bioprocess supervisory and PAT platforms
Configurable recipe graph with runtime writes	Control logic is a graph of blocks over live signals, with service inputs writable during execution	An edit to the executing path or to a variable the path reads	QB Control

Scope note

This is a description of integration and control architecture. It says nothing about the measurement accuracy, reliability, or build quality of any pump, probe, analyzer or controller referenced here. The equipment cited throughout this paper is industry-standard and works as documented. The differences described come from how control logic is structured and when it can be changed, not from any shortcoming in the hardware.

The evidence that mid-run change is a real requirement

Mid-run change is not an exotic demand from unusually ambitious teams. It is what competent process development looks like, and the published record shows the cost of not having it.

In an in-line Raman glucose control study, the first six days of the cultivation were spent identifying settings for a newly implemented glucose controller, with the authors reporting that no robust glucose control could be achieved during that timeframe. A robustness test on days 5 and 6 applied a fixed pump rate and glucose rose to 9 g/L. (Peer-reviewed.)
The same team then changed the glucose setpoint from 4 g/L to 1.5 g/L on day 10 for product-quality reasons, reached it within 24 hours, and held 1.5 ± 0.4 g/L to day 16. They also stepped the perfusion rate from 1 VVD to 1.25 VVD mid-run. (Peer-reviewed.)
A US patent filing on online recipe synchronisation in a real-time batch executive environment states in its Background that the batch executive can only execute the originally received recipe and does not react to the potential changes to the control recipe in real time, and that the current state of the industry demands that batch execution environments become responsive to sudden and frequent changes in recipe even for batches that take weeks or months to complete. (Public patent document, US 9,008,814. Attribution in References.)
On the same limitation, the filing notes that the batch runner could not pick up a new version of the recipe until execution of the original version completed, even if execution had not progressed past the point to which the changes applied.

The last two points matter because they are not a criticism from a competitor. They are a vendor stating the problem in a legal filing, as the premise for their own invention.

2. Target Outcome and Success Criteria

Everything that follows is measured against one definition of done, applied identically to all ten challenges.

The target

A feeding strategy whose delivered mass is measured, not inferred; whose shape can be changed while the culture is running; which degrades to a documented fallback rather than freezing or faulting when an instrument fails; and where every change made mid-run produces an audit record that satisfies a regulated-lab inspection without a special procedure.

A capability counts as meeting the target when all of the following hold.

The controlled variable is the one that matters. For feed, that means grams delivered into the vessel, not pump revolutions commanded.
The change happens without leaving execution. No service stop, no recipe redeploy, no batch restart. If the process has to pause, the capability has not been demonstrated.
The change is guarded, not merely fast. A write into a service whose state another path may be changing must be tested before it is attempted, not timed and hoped for.
The degraded path is explicit and tested. “What the loop does when the analyzer dies” is a branch someone designed and verified, not an exception handler nobody has exercised.
The record is generated, not assembled. User, role, old value, new value, timestamp and the reason for the change appear in the audit trail as default behaviour.
The limit is stated. Where a capability stops, the paper says where, so nobody discovers it in month three.

What is excluded

The following are outside the scope of this paper, and are excluded equally from every architecture described.

Mechanical fabrication, vessel design, sterilisation and CIP or SIP validation.
Formal GMP IQ, OQ and PQ documentation and execution.
Calibration SOP authorship and execution, beyond noting where a calibration record is held.
Cell line, media and process-science decisions. This paper is about executing a feeding decision correctly and provably. Choosing the right decision remains process science.
Qualification of any model, soft sensor or digital twin used to generate a setpoint.

3. The QB Systems Architecture

Three layers, and the reason each one matters for feeding control specifically.

QB Modules: hardware that joins the system with one cable

PoE auto-discovery. Plug a QB Module into the switch and it appears in Inventory. So the wiring problem and the driver problem collapse into a cable: no marshalling cabinet, no I/O card, no driver install, no controller download.
Multi-sensor input per module. QB Multisensor supports up to six sensors per unit with native Hamilton and Mettler Toledo support, and the module range uses standard LAN PoE connectivity. So a vessel’s sensor set does not require a transmitter per probe and the cabinet does not grow with the experiment.
Third-party devices over MQTT, REST and SQL natively, and over OPC UA through a dedicated software connector. So an existing Raman, capacitance probe or balance drives a QB service without becoming a QB module first, and the integration layer is a supplied component rather than a gateway you specify, build and maintain.
Native MTP object semantics. Device conditions address equipment as MTP objects rather than as raw tags. So the recipe speaks the same object model the modular-automation standards are converging on.

QB Control: control logic as an editable graph

A services catalogue rather than custom code. Gravimetric transfer, volumetric transfer, rate control, foam control by antifoam reagent, automated sampling by syringe pump and selector valve, and the rest are catalogue selections. So switching from rate-based to gravimetric feed is a service choice, not a re-engineering project.
Recipes are graphs, not scripts. Timers, formulas, variables, conditionals, event-driven waits, parallel split and merge lanes, and service-input writes. So the feed profile is a function over live signals that you can read on a canvas and edit, rather than a schedule compiled before the run.
Service inputs are writable during execution. A service-input write carries no service state transition. So a setpoint or a parameter can be changed on a running loop and the service never leaves EXECUTE.
Conditions are event-driven. A blocking wait releases when its condition becomes true, rather than on the next turn of a polling loop. A polled equivalent pays for every block in the loop on every pass, plus its wait, and detects a change no sooner than the next pass. So the response budget goes into the process rather than into loop overhead.
The recipe can read its own state machine. Service state, including IDLE, STARTING, EXECUTE, PAUSED, STOPPING and ABORTED, is readable in a condition block in the current release. So a recipe can test whether a service is actually running before it writes into it, which turns the central hazard of live change from something you design around into something you check for.
Clamping instead of stopping. Disabling a loop does not require stopping its service: a pump flow setpoint of zero, an oxygen level of zero, a temperature setpoint below ambient. One write, reversible, no state race. Stopping a service instead takes it through its full state machine, and stopping several runs them one after another rather than together. So a strategy change does not have to pass through the riskiest operation in the system.

QB Data and the compliance layer

Audit Trail with real operational depth. Recipe step started and completed pairs give true block durations. A paused execution event carries the reason and the offending service identifier. Service state series give exact state-machine timing. So a run that misbehaved overnight is read, not reconstructed.
Recipe versioning as a lifecycle. Draft, Verified, Validated, Archived. So “which version of the strategy was executing” is a first-class fact rather than an investigation.
Users and Roles with per-module permissions. Five predefined roles covering administration, operation, management, basic access and system access. So separation of duties is enforced by the system rather than promised by an SOP.
Reports generated automatically with batch metadata and audit-trail integration. So the deviation that occurred is in the batch record without anyone deciding to put it there.

The net effect. Every capability described in this paper lands inside a GAMP 5 Category 4 configurable system rather than a Category 5 custom one. That is the point that makes mid-run flexibility affordable to validate rather than merely technically available. On electronic records, the accurate statement is 21 CFR Part 11 conformance in the audit trail and access-control layers, with electronic signatures not yet covered. Where a workflow requires an executed electronic signature today, that remains a gap, and it is listed with the others in Section 5.

4. The Ten Challenges

Each challenge below follows the same structure: the premise, what the published evidence shows, why current practice breaks, what QB Control changes and why that matters, and a use case that can be built and run on real hardware. Each use case is stated as an objective, the concrete end state to be reached. The build details behind them are held back for a later publication, and are available sooner on request for a specific case. Where each capability stops is collected in Section 5 rather than repeated ten times.

Source types are labelled throughout. [PR] peer-reviewed, [V] vendor-published, [C] conference or consortium, [R] regulatory, [T] trade press, [P] patent, [SIM] simulation study.

4.1 The pump lies, and the process record repeats the lie

The premise: a feed pump commanded to deliver 10 mL/min is trusted to have delivered 10 mL/min. Over a multi-day run it did not, and the batch record says it did.

What the evidence shows

Peristaltic pumps at approximately 99% accuracy beaker to beaker showed 15 to 20% error during actual cultivation runs, from back-pressure and long-term tubing deformation. Gravimetric correction of integrated delivered mass brought this to 0.5% or less. [V]
Calibration does not survive sterilisation. Autoclaving changes tubing properties significantly, displacement decays as the tubing stretches, and new tubing needs 15 to 30 minutes of run-in before it can be calibrated. [V]
Single-point calibration is structurally wrong, not merely imprecise. A linear rpm to flow model showed deviations exceeding 15 mL/min at reference points where a polynomial fit gave RMSE 0.9193 mL/min. Steady-state speed itself wobbles ±2 rpm from roller compression and release. [PR]
Channels on one pump head are not interchangeable. Flow fluctuations of about 0.5 mL/min between two cartridges on a single head under identical tubing and back-pressure, with the rear cartridge highly non-linear while the front cartridge’s error stayed near constant. One calibration cannot be shared across channels. [T]
Tubing life ratings are not flow-accuracy ratings. Watson-Marlow measured mean peristaltic life at 220 rpm and 2 bar of 293 h for PureWeld XL against 119 h and 10 h for two competitor tubes, with Weibull minimum life at 90% confidence of 173, 21 and 3.5 h. Those figures were measured by running to catastrophic failure. A separate source uses the harsher industry convention of time to failure or a 50% reduction in flow rate, whichever comes first. The two definitions should not be merged, and under either one a tube inside its rated life can be well outside its calibration. [V]
Low feeds become pulsed. Below roughly 300 µL/min a peristaltic pump cannot deliver continuously, and a typical integrated bioreactor pump floors at 0.3 mL/min. An occlusive roller pump’s instantaneous flow swings enormously: a measured 184.6% variation at about 300 mL/min mean flow, against 28.1% for a non-occlusive pump under identical conditions. [PR]

Why it breaks today

Every rate-based feed controller is an open-loop actuator dressed as a closed loop. It closes on pump command, not on delivered mass. Tubing creep, autoclave-induced property change, back-pressure from a fouling filter, feed viscosity drift and channel-to-channel variance all sit downstream of the only variable being controlled. The error is cumulative and silent. Nothing alarms, the trend looks clean, and the batch record faithfully reports the commanded volume.

What QB Control changes

Gravimetric transfer is a catalogue service. Liquid Transfer Mass by Pump closes the loop on delivered mass. So the pump becomes the actuator, the balance becomes the sensor, and the setpoint is grams. Rate and volume services remain available for the cases that call for them, and the choice is a service selection rather than a re-engineering project.
Divergence becomes a first-class recipe signal. A formula block computes cumulative commanded volume against cumulative delivered mass and exposes the difference as a value the recipe can act on. So the drift is a number the system holds, not a shape a human might notice on a chart.
The trip is event-driven. A blocking wait with a two-row OR raises the flag at the moment divergence crosses a threshold or a deadline passes, rather than at the next poll. So detection lag is not the thing that determines how far the run drifts before anyone acts.
The deviation lands in the batch record. The Calibration module holds the pump calibration record, Audit Trail timestamps every recalibration, and Reports puts commanded against delivered into the GMP record rather than commanded only. So the run that drifted says so afterwards, in the document that matters.
Alarms and Notifications route it to a person. So a silent 15 to 20% drift becomes an alert with a named recipient instead of a discovery at harvest.

Use case: parallel volumetric and gravimetric feed on one vessel

What is to be achieved

Two feed lines deliver the same fluid at the same nominal rate into one vessel over a four-hour run. Line A runs rate control, Line B runs gravimetric control, and both bottles sit on balances. By the end of the run, the difference between what each line was told to deliver and what it actually delivered is visible on one graph, has been computed by the recipe itself in grams, has crossed a threshold that fired an alarm to a named recipient, and appears in the exported batch report.

Implementation details for this use case, including the rig, the recipe graph and the pass criteria, will be published separately. If this particular case is relevant to a process you are running, QB Systems can share them sooner: ask us directly and describe the case.

4.2 The feed profile is fixed before inoculation, and the culture never agreed to it

The premise: the feed trajectory is designed in advance from an assumed growth rate. When the culture grows differently, the profile is still executing.

What the evidence shows

The failure mode is stated plainly in the literature: a pre-defined perfusion ramp may result in inefficient medium use or nutrient deficiency in cultures where cell growth deviates from expectations and CSPR fluctuations occur. [PR]
The assumption is usually invisible and often wrong. One study doubled the perfusion rate daily, a factor chosen under the assumption of a 24 h cell-count doubling time. Testing increase factors of 1.4, 1.7 and 2.0 gave final viable cell densities of 53, 48 and 70 × 10⁶ cells/mL respectively. The result is non-monotonic: profile shape sets the outcome, not just integrated medium volume. [PR]
Shape is worth more than level. Hybrid-model-optimised dynamic media exchange rate schedules delivered a 50% increase in volumetric productivity across six Ambr 250 perfusion runs extrapolated to 5 L. [PR]
Published practice is a hand-simplified approximation. A target CSPR averaging 0.12 nL/cell/day was implemented as a simplified daily-adjusted step profile ranging from 0.04 to 0.19 nL/cell/day rather than exponential control. That is a 4.75-fold swing in specific rate to hit one average. [PR]
Even a mathematically optimal profile cannot be executed. A hybrid-model and Design-of-Dynamic-Experiments study concedes the nutrient profile cannot precisely follow the one proposed, because feeding happens in daily boluses with a ±10% control band, producing sawtooth rather than smooth trajectories. [PR]
The metabolic response has a multi-day time constant. Specific metabolic rates are driven by the CSPR after a metabolic adaptation until day 2.5, so in a six-day N-1 the settling transient consumes roughly 40% of the run. Deciding to reshape on day four is already late. [PR]

Why it breaks today

Most systems can change a setpoint mid-run. Very few can change the function generating the setpoint. A ramp configured as “double daily” is not a curve you can bend, it is a fixed schedule compiled at deploy time. Reshaping it means editing the recipe, which means a new version, which in most batch executives means the running batch cannot pick it up.

What QB Control changes

The profile is graph structure, not a hard-coded schedule. A timer supplies the run clock, a formula block computes the profile function, variables hold the scaling constants, and a service-input write pushes the computed setpoint into the running pump service. So the shape lives in objects you can open and change rather than in a compiled table.
Changing the shape means changing a value or an expression. A variable’s value can be updated during execution, and a conditional on measured growth rate can switch the recipe between two profile branches while the run continues. So reshaping a profile is an edit, not a redeployment.
The write carries no service state transition. So the profile bends without a restart and without a race.
Slope and MaxDiff parameters rate-limit the delivered profile. So a reshaped setpoint ramps instead of stepping. A pump commanded from zero to full in a single step has aborted a batch on deviation limit in QB’s own run history; two steps a minute apart plus a gentler service slope removes it.

Use case: reshaping an exponential feed profile mid-run

What is to be achieved

A running fed-batch recipe executes an exponential feed profile computed from the run clock, with the assumed growth rate held in a variable. Partway through, the operator concludes the culture is growing more slowly than assumed and reshapes the profile. The commanded curve visibly changes shape within one control interval, the pump ramps rather than steps to the new trajectory, the batch never leaves EXECUTE, and the Audit Trail records who changed what, from which value to which value, when, and why.

4.3 Changing a setpoint is easy. Changing the control loop is not.

The premise: the run is executing, the loop structure is wrong, and fixing the structure means stopping.

What the evidence shows

A public patent filing on online recipe synchronisation states in its Background that the batch executive can only execute the originally received recipe and does not react to the potential changes to the control recipe in real time, and that the industry demands batch execution environments become responsive to sudden and frequent changes in recipe even for batches taking weeks or months. On the existing operator tool, it notes that a force-transition function lets operators force transitions between recipe steps but does not grant operators control over the actual steps or logic of the recipe. [P]
Commissioning a new feed loop cannot be done offline, and the literature documents the cost. Six days of a live culture spent identifying settings for a newly implemented glucose controller, with no robust control achieved in that window, and a robustness test that drove glucose to 9 g/L. [PR]
Once tuned, the same team made structural mid-run changes as normal practice: glucose setpoint from 4 g/L to 1.5 g/L on day 10, held at 1.5 ± 0.4 g/L to day 16, and a perfusion-rate step from 1 VVD to 1.25 VVD. [PR]
Published PI gains for a bleed loop were hand tuned (Kp = −0.2, TI = 0.5), with the authors conceding such discrepancies could be reduced by further optimising the controller parameters. [PR]
On dynamic control as a system capability, one supervisory-software vendor states that many control and SCADA systems are not capable of implementing dynamic control. [V]
Classical control still dominates: over 90% of industrial controls used in bioprocessing are classical control approaches. [PR]

Why it breaks today

There are three distinct things people call “changing the control loop”, and most platforms handle exactly one of them.

Change	Typical platform support
A setpoint value	Broadly supported
A loop parameter such as gain, slope, deadband or limit	Sometimes, often only via the engineering tool, sometimes requiring a download
The loop structure: which sensor drives which actuator, cascade topology, branch logic	Effectively unsupported at runtime

Feeding strategy lives in the third row. “Switch from time-based to glucose-feedback feeding” is a structural change, not a value change.

What QB Control changes

Value and parameter changes are runtime writes. A service-input write carries no state transition, so the service stays in EXECUTE. So rows one and two of that table are covered without ceremony.
Structural change is handled at the graph level rather than the controller level. A conditional re-routes the live execution path, parallel split lanes can hold two alternative control strategies with only one armed, and an event-driven wait gates a branch on a plant signal. So switching strategy is a path decision the running recipe takes, not a redeployment.
Clamp rather than stop. Disabling a loop is one write of a zero setpoint, reversible, with no state race. So you avoid the most expensive operation available: a service stop walks the service through its full state machine, and stopping several serialises them.
The recipe reads its own state machine. Service state is readable in a condition block, so a write can be gated on the target service actually being in EXECUTE. So the central hazard of live structural change becomes a test rather than a timing assumption. This matters more than it sounds: a service-input write aimed at a service not in EXECUTE pauses the whole batch, and one extra condition row prevents it at zero block cost.
Versioning and Audit Trail make it a governed event. Draft, Verified, Validated, Archived plus a complete change record. So a structural change is documented rather than undocumented intervention.

Use case: live handover between two feeding strategies

What is to be achieved

One recipe holds two feeding strategies in parallel lanes: Lane A a time-based profile, Lane B feedback on a glucose signal from a third-party analyzer over OPC UA. The run starts with Lane A armed. Mid-run, control hands over to Lane B and then back again. Each handover completes without any service leaving EXECUTE, the batch never pauses, and the Audit Trail carries both decisions with user, role, old value, new value, timestamp and reason.

4.4 Adding a pump, a balance or an analyzer to a running process

The premise: halfway through a run the team realises they need a second feed line, a bleed pump, or an inline analyzer. The equipment exists. Getting it into the running process is the problem.

What the evidence shows

A consortium technology forum with two major automation vendors presenting concluded that equipment skids need to be treated as bespoke units when they are connected to control systems, and that this places automation on the critical path for facility design, build and reconfiguration. The target benefit was cutting equipment installation time from weeks to days. [C]
The same consortium’s current plug-and-play workstream states that the lack of standardized interfaces between equipment and automation systems creates significant barriers, and that long lead times, sequential validation efforts, and custom-engineered solutions drive up costs, extend build timelines, and limit operational flexibility. [C]
The interoperability gap is documented at state-machine level. A NAMUR working-group position paper produced with ISA 88 WG2 and PNO finds that a restart, as defined by MTP, of the ISA 88 state model is not foreseen, and that services cannot be completed by the ISA 88 system via the complete command, with MTP permitting hold from transient states that ISA-88 does not. That is the concrete technical reason plug-and-produce modules cannot yet be orchestrated cleanly from a batch recipe. [C]
Modular hardware is not the bottleneck. From a specialty-chemicals process lead, via a public industry association: making modules physically available is not a problem, and to create a flexible system you need automation technology that is modular as well. [C]
Reported saving when interfaces are standardised: significant savings in both build and configuration times, and potentially upwards of nine months on overall project delivery, from a CDMO participant in the same plug-and-play workshop. [C]
Even a good outcome takes real work. Connecting a single Raman analyzer over OPC UA required manual selection of each required NodeID per process variable, both systems on the same subnet, and a licensed recipe-control module before the measurement could drive anything. [V]

Why it breaks today

Adding a device to a conventional system is three separate problems stacked: a physical problem of wiring, marshalling and I/O cards, a driver problem of protocol and tag mapping and sometimes a restart, and a binding problem of getting the new tag into the executing control strategy. The first two have well-known costs. The third is the one that forces a stop, because in most batch executives the recipe’s device manifest is fixed at deploy.

What QB Control changes

PoE auto-discovery removes the physical and driver problems. One cable per module, appearing in Inventory with no engineering action. So two of the three stacked problems disappear from the critical path entirely.
Third-party instruments are devices, not integration projects. MQTT, REST and SQL natively, OPC UA through a dedicated software connector, and native Hamilton and Mettler Toledo sensor support through QB Multisensor. So an existing analyzer drives a QB service through a component that ships with the platform rather than an interface you have to build.
Services and service binding are separate concerns. A service is written against a template; binding it to a specific device is a distinct step. So the architecture that makes hot-binding solvable already exists, rather than requiring a rewrite to introduce.
MTP object semantics in the recipe conditions. So while the standards bodies work on aligning ISA-88 with MTP, the recipe already addresses equipment as objects.

Use case: discovering new hardware while the process executes

What is to be achieved

With a recipe running and a vessel under active control, a QB pump module and a QB balance that have never been connected to this system are plugged into a PoE switch port. Both appear in Inventory as identified, addressable devices, with no engineering action, no I/O configuration, no driver installation, no controller download and no restart. The running process continues executing throughout. The boundary is then stated explicitly rather than glossed over: discovery into Inventory is live, while binding those newly found devices into the already-executing process still waits for a deployment at the next natural boundary.

4.5 Five pumps, one vessel weight, and only two degrees of freedom

The premise: in perfusion, media feed, permeate, bleed, base and glucose top-up all move mass through one vessel. The weight loop and the biology loop are fighting over the same actuators.

What the evidence shows

The constraint is structural, not a tuning problem. Harvest rate is determined from the feed and bleed rates so as to maintain constant volume: harvest equals feed plus bleed, and only two of the three can be set independently. [T]
In practice the loops are assigned to different objectives and then expected to coexist. The media feed is typically connected to the vessel weight and fed back to the media feed pump, while the cell bleed pump is often fine-tuned using feedback from a viable cell density probe. To maintain steady state, perfusion rate, cell bleed rate and product harvest rate must all be synchronised, monitored and controlled. [T]
Glucose is usually a fourth independently controlled loop, using an additional concentrated feed with feedback from at-line glucose and lactate measurements. [T]
Hardware runs out before the strategy does. A leading high-throughput perfusion platform provides four positive-displacement pumps per bioreactor: three for reagent addition and a fourth for permeate. With base, feed and glucose top-up occupying the three addition channels, a bleed line has no dedicated pump. [V]
Which is why bleeds get done by hand, and often for the wrong reason. A documented benchtop perfusion run used manual culture bleeds of 421 g (20% of vessel volume) on day 9, then daily 600 g (30%) bleeds from days 9 to 18. The trigger was not a VCD setpoint but oxygen transfer: DO fell to 6.8% by day 7 and approached 0% by day 9, with agitation ramped from 130 to 200 rpm and O₂ sparge from 0.3 to 0.8 SLPM. The bleed became an oxygen relief valve. [V]
Base addition alone moves the mass balance and the osmolality: 62.5 mL/h of 4 M NaOH for E. coli in a 10 L reactor; 750 mL of 4 M in 10 L adds about 280 mOsm; acid and base addition contributed 0.6% dilution per hour over a 12 h fed-batch. [V]
Evaporation is never zero and is not predictable from first principles. Across 0.02 to 2.0 VVM aeration, evaporation rates were never found to be zero, and engineering-predicted evaporation could be at least 10% different from what is expected at scale. [PR]
The detection floor is coarse. During a media hold, a reactor weight change of about 0.02% of starting weight was within the calibration tolerance of the fermenter load cells, and therefore invisible. [T]

Why it breaks today

Each stream gets its own single-loop controller, and the mass balance is left implicit. Nobody computes closure, so nobody notices when it fails. When the weight loop and the VCD loop disagree, the vessel arbitrates by drifting.

What QB Control changes

Parallel lanes, one per stream. Feed, permeate, bleed, base and glucose each get their own execution path with its own logic and its own clock, running in parallel rather than interleaved in one sequence. So a stream’s behaviour is readable in one place instead of distributed across a sequence.
The mass balance becomes an explicit computed signal. A formula block closes feed in, permeate out, bleed out, base in and sampled out against vessel weight, and exposes the residual as a value an event-driven wait can act on. So the check nobody currently performs becomes a standing part of the recipe.
Gravimetric services per stream. So each term in the balance is a measured mass rather than an inferred volume, which is the only way the residual means anything.
Two-row AND conditions give window tests without a state variable, so a lane’s behaviour can be scoped to a process phase without building a state machine out of variables.
Service profiles make per-stream parameter sets reusable across vessels rather than re-entered per run.

Use case: live mass-balance residual across four streams

What is to be achieved

A perfusion recipe runs four independent stream lanes: media feed under gravimetric control, permeate under rate control with a balance, bleed event-driven, and base under continuous control. A fifth lane continuously computes the mass-balance residual, comparing the sum of all measured mass movements against the measured vessel weight, and displays it as a live trace. A deliberate fault is then introduced by partially restricting the permeate line. The residual departs from zero, an event-driven branch reduces the feed rate to protect the vessel, and the run continues.

4.6 The bleed loop oscillates, and filtering it out reintroduces the lag

The premise: holding viable cell density at a setpoint with a bleed pump is a textbook control problem that behaves badly in practice.

What the evidence shows

Naive feedback control of the bleed is marginally stable. In Monte-Carlo simulation, feedback control produced fluctuations with increasing amplitude, with maximum deviation in the VCC prediction of ±0.2 MVC/mL, reduced to ±0.02 MVC/mL under single-prediction control. Harvest flow rate fluctuation halved from ±0.35 to ±0.17 mL/min, and the authors estimate 4.5 to 10% of total product losses could be avoided over 30 days. [SIM] These are simulation results, not measured plant data, and should never be presented as achieved performance.
The multivariable version is harder on the actuators. Using cell bleed as an additional degree of freedom, the controller is described as pretty harsh on the manipulated variables under noise, resolved with a two-hour time-constant low-pass filter, which reintroduces exactly the lag real-time control was meant to remove. [PR]
The sensor driving the loop has a systematic offset. In automatic real-time CSPR control via a permittivity probe updated every 30 minutes, offline CSPR values calculated from offline cell counts were approximately 10% lower than the setpoint on average, while the controller itself showed minimal oscillation from the setpoint. A tight loop tracking a biased measurement. [PR]
The bias moves with the state being measured. Bio-capacitance cell density accuracy depends on the calibration model, the cell line and the culture conditions, and is susceptible to variations in media conductivity and cell morphology. [PR]
The signal changes character with growth phase. Permittivity increment tracks biovolume during exponential growth, while critical frequency carries the information during the transition to death phase. A single-frequency calibration degrades exactly when the bleed loop matters most. [PR]
The complexity is not self-justifying, which is the most useful finding for an honest conversation: both real-time CSPR control and fixed daily VVDs can be equally efficient strategies to drive cell growth, and real-time CSPR control does not necessarily provide a clear advantage over predefined rates for cell proliferation. [PR]

Why it breaks today

A polling controller on a noisy, biased, phase-dependent soft sensor, with a slow actuator and a coupled mass balance. Each element is manageable. Stacked, they oscillate. The standard fix is heavy filtering, which trades oscillation for lag, and the lag is what you were paying for real-time measurement to avoid.

What QB Control changes

Event-driven conditions instead of polling. A blocking wait releases on the change itself, while a polled loop can only notice on its next pass and pays for every block it contains on every pass. So the polling tax is real and avoidable, and the filter budget goes into the noise rather than into loop overhead.
Two-row AND and OR conditions express deadbands, windows and OR-with-deadline logic declaratively. So a deadband is a condition, not a state machine assembled from variables.
Formula blocks give derived and filtered signals, including the clamping identities that avoid conditional-merge deadlocks: max(x,0) as (x+abs(x))/2 and min(a,b) as (a+b−abs(a−b))/2. So a filter is an expression rather than a subgraph.
Discriminate on the deadline, not on the plant signal. The verified interlock pattern is a blocking wait on “signal trips OR clock past deadline”, followed by a conditional that tests the clock. So a momentary dip that has already recovered still routes into the fail-safe branch, which is exactly the robustness a noisy VCD signal needs.
Clamp, do not stop. Setting the bleed pump’s flow setpoint to zero is one write with no state transition, against stopping the service and taking on its cost and its restart race.

Use case: event-driven bleed control against a polled implementation

What is to be achieved

A bleed lane is driven by a capacitance signal carrying realistic noise and a deliberate step bias. The same signal drives two implementations in turn: a conventional polled controller, and an event-driven implementation with a deadband expressed as a two-row condition. The polled version’s pump command visibly hunts. The event-driven version’s does not. When a 10% step bias is injected into the probe signal, a plausibility check catches it and routes it to an alarm instead of acting on it.

4.7 The filter fouls, and the intuitive response makes it worse

The premise: in perfusion, retention-device fouling forces a mid-run change to permeate flux or perfusion rate. The obvious response, throttling the permeate, can reduce product recovery.

What the evidence shows

Short validation tests systematically under-predict long-run fouling. Asymmetric polysulfone hollow fibres in ATF on a CHO reactor reached 69 LMH without exceeding critical flux, and tests under 3.5 h showed no fouling signs. Yet prolonged operation at only 8.3 LMH drove TMP to 0.9 to 0.95 bar. A flux setpoint validated in hours will fail over days. [PR]
The mechanism inverts the intuitive fix. Starling flow, the localized reversal of flux where permeate flows back into the fiber lumen due to axial variations in transmembrane pressure, is identified as a major contributor to membrane fouling and product retention, and the back-flow ratio correlates inversely with net permeate flux. Increasing flux reduces back-filtration, so throttling it can make sieving worse. [PR]
Decoupling TMP from crossflow recovered up to 40% higher product sieving compared with standard TFF. [PR]
Material and geometry swing retention enormously. Polysulfone fibres showed product retention 15% ± 8 to 43% ± 18% higher than polyethersulfone; higher harvest flow rate and ATF exchange rate increased retention by 13% ± 10% up to 31% ± 13%; and 0.65 µm pores increased retention 38% ± 7% against 0.2 µm. [PR]
The dominant fouling driver may be something added days earlier. Simethicone-based antifoam accumulates over time in perfusion cultures, significantly impacting fouling. A foam event on day 4 becomes a filter failure on day 12. [PR]
The alarm threshold is not shipped. A commercial lab perfusion controller provides permeate pressure alarms only as low and low-low, with no high-pressure thresholds, and states that no lower limit for alarm set-up has been established, requiring per-process consultation. Fouling detection is therefore a process-development deliverable rather than a default. [V, anonymised]
The actuator degrades at intensified density. Precision pumping maintains accurate flow control up to viscosity values of about 6 cp, corresponding to roughly 150 to 200 VCD. Above that, flow accuracy fails independently of fouling. [V, anonymised]
Fouling and cell stress form a loop. Cell lysis was most associated with sparging stress, followed by the hollow fibre and lastly agitation, and lysis debris is the fouling feedstock. [PR]

Why it breaks today

TMP is a derived value computed from two or three pressure sensors, so it is rarely a first-class control signal. Fouling therefore shows up as a slow trend on a screen nobody is watching, with no shipped threshold, and the response is a manual decision taken late and often in the wrong direction, because the physics is counter-intuitive.

What QB Control changes

A formula block makes TMP a first-class signal computed from bound pressure devices, and an event-driven wait acts on it the moment it crosses a threshold. So the derived value gets the same standing as a directly measured one.
The Alarms module carries configurable thresholds and priorities on that derived signal, with Notifications routing by priority. So the shipped-default gap becomes a configuration exercise rather than a project.
A conditional branch executes the whole fouling response as one coordinated change: adjust permeate flux, adjust perfusion rate, initiate or increase bleed, and log the decision. So the response is a designed procedure rather than one operator changing one number.
Cumulative antifoam becomes a monitored variable. Foam Control by Antifoam Reagent with the cumulative total held in a formula turns “how much simethicone have we added” into a value on the same page as TMP. So the delayed-cause signal the literature identifies is visible next to its effect.
A cumulative-totaliser check is self-disarming. “Totaliser greater than X” passes forever once the reagent has flowed, which makes it the right first-cycle test across dozens of cycles where a delta test would false-trip.

Use case: transmembrane pressure as a computed recipe signal

What is to be achieved

Three pressure devices (hollow-fibre inlet, hollow-fibre outlet, permeate) are bound into a running perfusion recipe. A formula block computes TMP live from those three readings, and an alarm threshold is configured on TMP rate of rise, not on absolute TMP. Fouling is induced by partially restricting the permeate line. The TMP rise is detected, the alarm routes to a named recipient, a conditional branch executes the coordinated fouling response, and the run continues. Cumulative antifoam is displayed on the same graph as a second, slower-moving cause.

4.8 The analyzer is the clock, and when it drops out the feed loop has nothing

The premise: feedback feeding is only as fast as the analyzer, and only as reliable. The loop time is set by instrument scheduling, not by process dynamics, and there is usually no plan for the instrument failing.

What the evidence shows

Loop time is an instrument-scheduling artefact. In an OPC UA integration of a Raman analyzer to a bioreactor controller, scheduled measurements were taken every 30 minutes and the pump rate was adjusted on the same 30-minute cadence. [V]
Multiplexing multiplies the interval. An automated feeding system sampled four reactors with a single 10-minute sample-and-analysis cycle, an effective per-vessel control interval of about 40 minutes. A process mass spectrometer analysing 30 s per stream and serving 60 or more bioreactors arithmetically bounds any RQ-based feed controller at roughly 30 minutes per vessel. [T, V]
Transport lag is separate from measurement lag. Measuring in the perfusion harvest stream rather than the vessel means the dwell time depends directly on the time required for the permeate to reach the Raman probe, and one team recovered about ten minutes of process dead time by shortening the tubing. A control problem solved with plumbing. [PR]
Timescales are mismatched by design: online Raman spectra collected at intervals of 45 to 55 minutes against offline analytical measurements recorded twice daily, requiring a custom mapping procedure. [PR]
Models drift for mundane reasons and need in-run updating. Degradation of deployed models arises from recipe modifications, raw material variability and process drifts, and under new base and feed medium compositions, models without updates failed outright, showing negative R². [PR]
Replacing the instrument breaks the model. Vendor-specific spectral signatures make Raman chemometric models incompatible across manufacturers, which impedes upgrades, maintenance and replacement of obsolete Raman equipment. [PR]
Fault tolerance is named as the top open problem: tolerance to sensor faults remains the greatest challenge in soft sensor development, especially with variable process lengths and multiple process phases. [PR]
The industry is already building fallbacks. A 2025 study developed a model-only continuous glucose calculator explicitly as a scalable alternative, to extend the benefits to manufacturing environments where Raman spectroscopy may not be feasible. [PR]
The calibration burden is not small: generating Raman calibration data took 528 spectra from 48 samples per day across 24 parallel bioreactors over 14 days, with an earlier cited approach requiring 37 separate production runs from 2 L shake flask to 5000 L and 444 data points, described as time-consuming and very expensive. [PR]

Why it breaks today

The feed loop has a single point of failure that nobody designs around. When the analyzer stalls, most systems either freeze the last setpoint indefinitely, which is a slow-motion overfeed or starvation, or fault the batch. There is rarely an explicit, tested degradation path.

What QB Control changes

Graceful degradation is a recipe pattern, not an exception handler. The verified idiom is a blocking wait with a two-row OR (the analyte condition trips, OR the run clock passes a deadline), followed by a conditional that discriminates on the deadline. If the analyzer is alive, the analyte path fires. If it is dead, the deadline fires and the recipe falls through to a time-based fallback profile. So the run keeps going on a documented degraded strategy instead of freezing or faulting.
Guard the write on service state, not on a timing assumption. Writing into a service whose state another path may be changing used to need a double gate with a hold sized by hand. That was fragile, because the hold has to be long enough for the slowest case and nobody knows the slowest case in advance. A hold that was comfortable in testing still missed a service restart in production and paused a batch. With service state readable in a condition block, the same protection is one condition row. So there is no hold to size, no race to lose, and the recipe retries on the next pass instead of parking.
Watchdog the service itself, not just the signal. A blocking wait on “service state is not EXECUTE OR clock past deadline”, followed by a conditional on the clock, applies the verified interlock idiom to the state machine. So a service that aborts or is stopped by something else routes into a recovery branch. Before service state was readable, that entire fault class was invisible to a recipe.
Third-party analyzers over MQTT and REST natively, and over OPC UA through a dedicated software connector. So the instrument does not need to be a QB module to drive a QB service, and replacing it does not mean replacing the control layer.
Formula-based plausibility checks on the incoming analyte value. So a stuck or out-of-range signal is caught before it reaches the pump.
Audit Trail and Reports record which strategy was in force at every point. So a run that spent six hours on the fallback profile says so in the batch record.

Use case: analyzer dropout and documented fallback

What is to be achieved

A glucose-feedback feeding lane is driven by a third-party analyzer connected over OPC UA. Mid-run, the analyte signal is killed. Within one deadline period the recipe falls through to a time-based fallback profile, raises an alarm, notifies a named recipient, and continues executing without pausing. The analyzer is then restored and the recipe hands control back to feedback. The generated report states which strategy was in force during which interval.

4.9 Nights, weekends, and the run that does what nobody is watching

The premise: feed decisions depend on measurements taken when staff are present. Cultures do not observe working hours.

What the evidence shows

The gap exists even in facilities purpose-built for automated feedback. In an eight-parallel-reactor high-throughput setup with a mobile robotic lab assistant, a gap in the offline measurements between 17 and 26 h of cultivation was due to an intended sampling break during the night. A nine-hour blind window by design. [PR]
Equipment fails precisely then. In a model-based perfusion intensification run, the authors report issues with the outflow pumps and associated recording devices during the weekend periods, with missing experimental points between days 21 and 24. [PR]
The offline sampling interval is the hard ceiling on any manually-driven feed decision. Off-line sampling typically occurs at 24 h testing intervals, and the need to routinely sample the bioreactor, typically restricted to trained laboratory staff, is both time- and labour-intensive, with contamination risk on every intervention. [PR]
Daily adjustment is an acknowledged oversimplification: daily metabolite adjustments lead to an oversimplification of the cell culture demands because the cellular metabolism of the culture can change. [PR]
Continuous feeding measurably beats daily boluses on both control and labour. Switching from 13 bolus feeds of one medium, 13 of another and 8 glucose boluses over 14 days to continuous PID-controlled delivery held glucose at 6 ± 0.25 g/L and saved roughly 7 hours of labour per 17-day batch. [V]
And the substrate all this runs on is still largely paper. In a biopharma digital maturity survey: 46% use hybrid digital and paper records, 32% rely primarily on paper with basic online data management, 3% entirely paper, and only 19% are fully digital or cloud with PAT. [T]

Why it breaks today

Automation covers the actuators but not the decisions. The pump runs all night; the choice of what the pump should do waits for a human. Anything needing a decision, whether a bottle change, a profile step, a bleed, or a response to a trend, clusters into working hours, and the culture experiences the process as a series of weekday step changes.

What QB Control changes

A recipe executes the decisions, not just the actions. Conditionals, event-driven waits, timers and formula blocks mean the choice logic runs at 03:00 exactly as written. So the culture stops experiencing the process as a working-hours pattern.
Automated Sampling by Syringe Pump and Selector Valve is a catalogue service. So the sampling gap that gates the decision closes without a bespoke rig.
Alarms routed through Notifications by priority. So the exceptions that need a human reach one, and the rest do not.
Reports generate automatically with batch metadata, Runs gives a searchable archive, and the Audit Trail gives real block durations from step started and completed pairs, with paused-execution events carrying the reason and the offending service identifier. So what happened overnight is read, not reconstructed.
Manual Operation blocks are the right tool for a genuine human gate. A pre-flight confirmation costs no run time and puts a timestamped, attributed record of the starting conditions into the batch history. So the human step that should exist is documented rather than remembered.
Browser-based on any device. So checking a run from a phone needs no client install.

Use case: an unattended run whose report is the handover

What is to be achieved

A recipe runs unattended overnight containing at least one decision that would normally wait for a human: a profile step gated on a measured signal, a bottle-change manual gate with an attributed confirmation, and an exception path that notifies a named recipient. In the morning, the generated report shows every step with real durations, states what the recipe decided and when, and identifies who confirmed the manual gate. Nobody reconstructs the night from memory or from a trend chart.

4.10 Mid-run flexibility is a compliance problem before it is a software problem

The premise: the technical ability to change a feeding strategy mid-run is worthless if the change cannot be defended in an audit.

What the evidence shows

The draft revised EU GMP Annex 11 makes every mid-run parameter change a structured audit event. §12.2 requires the audit trail to unambiguously capture the user who made a change including the user’s role, what was changed including the data changed and the old and new value, and the date and time. It adds that where data is changed from an old value to a new value, systems should automatically prompt the user for, and register, the reason why the change was made. [R]
Alarm and limit changes are separately governed. §8.2: alarm limits, delays and any early warnings or alerts should be appropriately justified and set within approved and validated process and product specifications, and setting, changing or deactivation should only be available to users with appropriate access privileges and should be managed by an approved procedure. [R]
Electronic signature is not a checkbox. §13.3: executing an electronic signature should enforce full re-authentication providing at least the same level of security as during system login. [R]
§3.1(ii) is the clause that makes adding a pump a change-control event distinct from changing a setpoint: any change to a computerised system including its configuration, hardware and software components, platform and operating system must be made in a controlled manner and in accordance with defined procedures. [R]
The US equivalents. 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails recording the date and time of operator entries and actions that create, modify or delete electronic records, and that record changes shall not obscure previously recorded information. 11.10(g) requires authority checks so that only authorised individuals can use the system, alter a record, or perform the operation at hand. §11.50 requires the signature to show printed name, date and time, and the meaning such as review, approval, responsibility or authorship. §11.70 requires signatures to be linked to their records so they cannot be excised, copied or otherwise transferred. [R]
Changing the model driving a feed loop can be a filing question rather than a software question. Certain changes to the scope of a spectroscopic method require regulatory notification and acceptance before a model update can be implemented, with ICH Q12 proposed as the update mechanism and a post-approval change management protocol recommended to avoid halting continuous manufacturing. Changes to a digital twin and soft sensor must remain traceable in a GxP environment. [R, C]
Soft sensors must be qualified before they drive anything, undergoing an intensive functional and risk assessment under GAMP 5 and 21 CFR Part 11. [PR]
No digital twin anywhere is currently authorised to act. To the knowledge of the authors of a 2025 review, there is no process authorized with a digital twin that actively intervenes in the manufacturing process, and digital twins sit at the highest validation demand category. [PR]

Why it breaks today

A control system that can change a loop mid-run but cannot produce the four-field audit record with a captured reason has moved the problem, not solved it. The predictable result is that teams stop making mid-run changes, because documenting them is harder than living with a suboptimal process.

One honest note on that last sentence. The constraint chain above is fully documented. The behavioural consequence, that teams therefore avoid mid-run changes, is not quantified anywhere in the public literature. Treat it as a mechanism, not as a measured statistic.

What QB Control changes

The Audit Trail is built for 21 CFR Part 11 with real operational depth: event types logged, user attribution, immutability, searchable and exportable, with step started and completed pairs, paused-execution events carrying the reason and the offending service identifier, and service state series for exact state-machine timing. So the record answers operational questions, not just compliance ones.
Users and Roles with per-module permissions. So the separation of duties that Annex 11 §8.2 and 21 CFR 11.10(g) both require is enforced structurally rather than by procedure.
Recipe versioning as a lifecycle. So “which version of the strategy was executing” is a first-class fact.
The Alarms module holds thresholds as governed configuration. So §8.2’s approved-procedure expectation is met by the system’s structure rather than by an SOP alone.
Reports generate GMP-ready output with batch metadata and audit-trail integration automatically at run completion. So the batch record is produced rather than assembled.
GAMP 5 Category 4 rather than Category 5. This is the strategic point. Every mid-run capability in Sections 4.1 to 4.9 lands inside a configurable system rather than a custom one, which is what makes the flexibility affordable to validate rather than theoretically available.

Use case: following one mid-run change through compliance

What is to be achieved

Any mid-run change from the preceding use cases is followed all the way through the compliance layer. A feed setpoint is changed by a user holding an operator role. The Audit Trail immediately shows the user, the role, the old value, the new value, the timestamp and the reason the system prompted for. A user holding only basic access then attempts to change an alarm threshold and is refused by role. Both events appear in the generated report, alongside the recipe version state, so “what was running” and “who changed it” are one story.

5. What This Adds Up To

Nine of the ten challenges above are execution problems that look like process-science problems. The tenth is a compliance problem that determines whether the other nine are worth solving.

The common thread is not sophistication. It is where the control logic lives and when it can be changed. When feeding logic is a compiled schedule with a device manifest fixed at deploy, every one of these ten challenges becomes a decision to stop the run or live with the deviation. When it is a graph of blocks over live signals, with service inputs writable during execution and service state readable in a condition, the same ten become edits. That difference is architectural, and it is available in a configurable system rather than a custom one, which is the part that decides whether a validated facility can actually use it.

This paper has been deliberate about the limits, and they belong in one place rather than scattered through ten sections.

Inside the platform. Service-parameter tags are not runtime-writable, so pH control has no runtime clamp today. Hot-binding a newly discovered device into an already-executing process is not solved, and the reason is audit-trail semantics rather than plumbing. A formula result is a snapshot, so every live computation has a stated polling period that should be quoted rather than implied. A recipe pause stops every service, agitator and heater included. Several blocks in the catalogue are not yet verified against real exports. A manual operation prompt is not a platform alarm: anything that has to wake somebody must be an alarm with a notification route.

At the edges of the platform. Gravimetric feed moves the measurement error, it does not delete it, and balance resolution becomes the new floor: one documented case needed 0.01 g rather than 0.1 g resolution before feed addition stopped oscillating, and large feed bottles force high-capacity balances that resolve at 5 g. Electronic signatures are not yet covered under 21 CFR Part 11. Adding hardware to a validated system remains an EU GMP Annex 11 change-control event whatever the discovery mechanism, so auto-discovery makes it fast rather than free. QB Control computes and acts on derived signals but does not model fouling, does not perform model predictive control natively, and does not qualify anyone’s soft sensor.

None of those limits change the central claim, and stating them is what makes the claim credible.

Four questions worth asking of any feeding control system

When a run finishes, how do you know how much feed actually went in: the pump’s number, or the bottle’s weight? If it is the pump’s number, the published in-run error on bench-accurate pumps is 15 to 20%, and your batch record does not contain that error.
If your glucose controller needs re-tuning on day three, do you tune it on the live culture or wait for the next run? One published study spent six days of a live perfusion culture identifying controller settings.
If your analyzer fails at 02:00 on day six, what does the feed pump do for the next six hours? Sensor-fault tolerance is called the greatest challenge in soft-sensor development in the peer-reviewed literature, and most systems either freeze the setpoint or fault the batch.
When you change a feed setpoint mid-run today, what does your audit trail capture, and does it prompt you for the reason? Draft revised Annex 11 §12.2 expects user, role, old value, new value, timestamp and an automatic prompt for the reason.

Where to start

The cheapest way to find out whether any of this applies to your process is also the least disruptive: run a parallel measurement. Put a balance under the feed line you trust least and run it alongside whatever you are doing now, for one campaign, with no change to your validated process. If the commanded and delivered traces stay locked, you have lost nothing and gained a number you did not have. If they separate, you have learned something your current system cannot show you.

What would that look like on your rig, and which feed line would you pick? Tell us about the process and we will size the parallel run against your actual configuration, including which of the limits listed above would matter for it.

Reference Documents

Third-party public documentation, peer-reviewed literature, conference and consortium publications, and regulatory sources referenced in this paper.

Pump metrology and gravimetric feeding

Securecell and Safi Biotherapeutics, Implementing gravimetric feed control in perfusion-based cell culture processes (vendor case study), securecell.ch
Securecell, Precision in every drop: gravimetric feeding with Lucullus software, securecell.ch
Watson-Marlow Fluid Technology Solutions, PureWeld XL continuous bioprocessing white paper, wmfts.com
Automation (MDPI) 2025, peristaltic pump rpm to flow non-linearity, mdpi.com
Testa Analytical Solutions via lab-worldwide, Investigating variation in flow from peristaltic pumps, lab-worldwide.com
Cole-Parmer, How to achieve accurate dispensing with peristaltic pumps, coleparmer.com
Darwin Microfluidics, tubing lifetime and the 50% flow end-of-life convention, darwin-microfluidics.com
TU Dresden IFTE, ESTC 2020, roller pump pulsation measurement, ifte.de
Biotechnology Letters 2022, evaporation rates in bioreactors, springer.com
BioPharm International, microbial fermenter equipment characterization, biopharminternational.com

Perfusion feeding, CSPR and bleed control

Frontiers in Bioengineering and Biotechnology 2025, real-time CSPR control against fixed VVD in CHO N-1, frontiersin.org
Frontiers in Bioengineering and Biotechnology 2022, model-based intensification from fed-batch to perfusion, frontiersin.org
Bioprocess and Biosystems Engineering 2022, model predictive control for steady-state performance in integrated continuous bioprocesses (simulation study), springer.com
Deschenes, Desbiens, Perrier and Kamen, Asia-Pacific Journal of Chemical Engineering 2006, cell bleed as an additional degree of freedom
Agarwal et al., Biotechnology Progress 2025, hybrid modelling for in silico optimisation of dynamic perfusion, aiche.onlinelibrary.wiley.com
Leong et al., Biotechnology Journal 2024, biomass-specific perfusion rate as a control lever
Biotechnology Progress, capacitance frequency dependence and growth phase
BioPharm International, Achieving process balance in perfusion bioreactors and Control strategies for perfusion cell culture
Sartorius, Ambr 250 HT Perfusion brochure (pump allocation), sartorius.com
Thermo Fisher, perfusion terminology white paper, thermofisher.com

Filter fouling and product sieving

Veje, Quirós, Kristensen and Jørgensen, Journal of Membrane Science 701:122764 (2024), fouling in perfusion, critical flux against sustained flux
Dhingra et al., Biotechnology and Bioengineering 2026, Starling flow, back-filtration and product retention
Romann et al., Biotechnology and Bioengineering 2023/24, co-current filtrate flow and product sieving
Su, Wei, Miao et al., Applied Microbiology and Biotechnology 2021, membrane material, pore size and flow rate against retention
Madabhushi et al., Biotechnology and Bioengineering 2025, simethicone antifoam accumulation as a fouling driver
Zhang, Ran, Zhao, Ye and Tan, Biotechnology Journal 2024, sparging against hollow-fibre against agitation as lysis sources
Public user documentation for a commercial lab perfusion controller (permeate pressure alarm limits and viscosity ceiling for flow accuracy)

PAT-driven feeding, model drift and analyzer dependency

Frontiers in Bioengineering and Biotechnology 2022, in-line Raman glucose control in perfusion
Rashedi et al., Biotechnology Progress 2025, continuous glucose feedback control and the model-only fallback
Bioprocess and Biosystems Engineering 2020 and 2023, feedback control of supplemental feeds using inline Raman
Olin et al., Biotechnology Progress 2024, N-1 perfusion enabling high-inoculation-density fed-batch
Sensors (MDPI) 2022, automated Raman calibration data generation in 24 parallel bioreactors
arXiv 2025 preprint, real-time model updating and drift in deployed cell-culture models
AAPS Journal 2025, cross-vendor Raman model transfer
Frontiers critical review, soft sensors in bioprocessing and sensor-fault tolerance
BioProcess International, Raman and OPC UA integration to a bioreactor controller, and automated bioreactor feeding across four reactors on one analyser
Thermo Fisher, Prima process mass spectrometer application note, thermofisher.com
Sartorius, connecting a Raman analyzer over OPC UA (manual NodeID mapping), sartorius.com

Mid-run change, batch executives and modular automation

US Patent 9,008,814, Online recipe synchronization in a real-time batch executive environment, assigned to Fisher-Rosemount Systems, Inc., patents.justia.com
US Patent 9,552,000, Batch authoring tool and bioreactor control system, assigned to GE Healthcare, patents.justia.com
NAMUR WG 2.3, WG 2.12 and WG 2.4.2 with ISA 88 WG2 and PNO JWG MTP Core Specification, September 2024, State Model Alignment of ISA 88 and Module Type Package, atpinfo.de
BioPhorum, Plug and play bioreactor interface development webinar (June 2022), Plug and Play workstream, A framework for the requirements for modular process equipment (June 2024), and the standardized-interfaces workshop, biophorum.com
ACHEMA and DECHEMA, modular plant construction, achema.de
Securecell via GEN (October 2021), multi-vendor scales and pumps and SCADA dynamic-control limits, genengnews.com
MDPI Fermentation 2023, adaptive MPC of fed-batch E. coli
MDPI Processes 2025, digital twins in biomanufacturing
Systems Microbiology and Biomanufacturing 2021, classical control as over 90% of industrial bioprocess control

Operational burden and unattended running

Frontiers in Chemical Engineering 2022, eight-parallel-STR facility with a robotic assistant
Sartorius, BioPAT Trace automated glucose control application note, sartorius.com
BioProcess International, Reimagining the future of biopharmaceutical digitalization survey
Technology Networks, continuous and perfusion bioprocessing, PAT strategies and chemometric model drift

Regulatory

European Commission, draft revised EU GMP Annex 11 (consultation), health.ec.europa.eu
eCFR, 21 CFR Part 11, ecfr.gov
ISPE Pharmaceutical Engineering, quality and regulatory solutions for PAT and continuous manufacturing, ispe.org

Conference programmes reviewed for feeding-control content

Cell Culture Engineering XIX (Tucson, 2025); ECI Integrated Continuous Biomanufacturing VI (2024) and VII (2025); ESACT 28th (Edinburgh, 2024) and 29th (Salzburg, 2026); Bioprocessing Summit 2025 and 2026; BPI US 2026; IFPAC 2025; Securecell 5th Learn and Connect Seminar (Leiden, 2026)

Specific configurations, firmware, and service offerings from the manufacturers referenced here may differ from the standard patterns described in this paper.

Methodology, Assumptions and Legal Disclaimer

1. Nature of the analysis. This whitepaper is an assumptions-based description of recurring problems in bioreactor feeding control and of the capabilities in QB Control and QB Modules that address them. The use cases are descriptions of what can be built and demonstrated on real hardware, written as objectives and success criteria. They are not a guarantee of performance, outcome, or result for any specific project, and this paper is not a competitive benchmark study. It contains no cost, price, or engineering-effort estimates of any kind, by design.

2. Sources of information. Everything stated here rests on publicly available information and on the assumptions set out below. QB Systems capabilities come from the QB Systems product catalogs and the QB Control User Manual. This paper deliberately quotes no platform latency or response-time figures: response times depend on the deployment, the recipe and the equipment, and belong in a characterisation against your own configuration rather than in a positioning document. Third-party architectures, capacities and product behaviours are described from the respective manufacturers’ publicly available product documentation, from peer-reviewed literature, from published conference and consortium material, and from public patent documents, all as known at the time of writing.

3. Evidence labelling. Source types are labelled throughout Section 4. A vendor-published figure, a Monte-Carlo simulation result and a peer-reviewed measurement are different kinds of evidence and are never presented as equivalent. Two labels deserve specific attention. The 15 to 20% in-run pump error figure and the 0.5% gravimetric result come from a vendor case study, not a peer-reviewed paper; they remain the best-quantified public comparison available, and they should be treated as directional. The bleed-control fluctuation figures of ±0.2 and ±0.02 MVC/mL come from a Monte-Carlo simulation study, not measured plant data, and must never be presented as achieved performance.

4. Documented assumptions. The descriptions above depend on the following. Change any of them and the conclusions change.

a. Scenario. The use cases assume lab-scale or pilot-scale vessels between roughly 2 and 250 L, with feed lines on balances, instruments addressable over MQTT, REST or OPC UA (the last through QB Control’s dedicated OPC UA connector), and a QB Control deployment with the relevant service templates and connectors licensed and the devices bound before the run starts.
b. Scope. “What can be demonstrated” covers configuration in QB Control, device binding, recipe construction and execution, and the resulting records. It excludes mechanical fabrication, sterilisation and CIP or SIP validation, formal GMP IQ, OQ and PQ documentation, calibration SOP authorship and execution, and cell line, media and process-science decisions. These exclusions apply equally to every architecture described.
c. Personnel. Standard bioprocess technician and automation engineer proficiency, with no pre-existing reusable recipe libraries. Teams with existing assets will move faster.
d. No effort or cost figures. This paper deliberately contains no engineering-hour ranges, no labour estimates, no prices and no cost comparisons. Any statement about relative ease refers to the structure of the work, not to its duration or price. Do not derive a budget from this document.
e. Assumed configurations. Third-party platform capacities cited here, including pump allocation per bioreactor and analyzer scheduling intervals, are taken from public product documentation. Actual counts and intervals depend on the exact models, options and firmware chosen.
f. Provenance, not precision. Every process figure quoted is reproduced with its original context and source type. Figures measured under one set of conditions, one cell line, one tubing type or one membrane material do not transfer automatically to another.
g. No specific project. No real customer, site, run or deployment is represented. The use cases are illustrative descriptions of demonstrable configurations, not case studies.
h. Vendor tooling that is not publicly documented. The third-party vendors and platforms referenced here may offer additional accessories, gateways, configuration utilities, software tools, firmware options or service packages that would reduce or remove the limitations described. Where that tooling is not publicly documented, it could not be evaluated and is not reflected here, so real-world capability with those vendors may exceed what is described in this paper.

5. Third-party trademarks. References to third-party products, platforms and publications are made for nominative and descriptive purposes only. All trademarks remain the property of their respective owners. Mentioning these brands does not imply any affiliation, endorsement, or sponsorship between QB Systems or A4BEE Sp. z o.o. and the trademark holders. Where this paper describes a capability that a product does not currently provide, the product is described anonymously and the statement is taken from that manufacturer’s own public documentation.

6. No disparagement. This paper is about control architecture: where feeding logic lives, what it closes the loop on, and when it can be changed. It says nothing about the measurement accuracy, reliability, or build quality of any third-party sensor, pump, membrane, analyzer or controller. The manufacturers referenced make high-quality, industry-standard equipment, and the differences described come from control architecture and integration method, not from any shortcoming in those products. Where a manufacturer offers a configuration that removes one of the constraints described, the outcome would differ from what is described here.

7. Limitation of liability. This document is for information only. It is not professional engineering, procurement, regulatory, legal or financial advice. Verify the assumptions, capabilities and regulatory interpretations against your own facility, your own quality system, the current vendor documentation and the current regulatory text before you decide anything. Regulatory references, including the draft revised EU GMP Annex 11, describe documents that may change; check the current version. A4BEE Sp. z o.o. accepts no liability for actions taken in reliance on this document.

Flexible. Innovative. Limitless.

Delivered, Not Commanded: Ten Challenges in Bioreactor Feeding Control

Two terms, before the numbers

Executive Summary

At a glance

1. The Structural Problem: Smart Measurement, Blind Delivery

Why this is hard even with modern equipment

The four architecture patterns

The evidence that mid-run change is a real requirement

2. Target Outcome and Success Criteria

What is excluded

3. The QB Systems Architecture

QB Modules: hardware that joins the system with one cable

QB Control: control logic as an editable graph

QB Data and the compliance layer

4. The Ten Challenges

What the evidence shows

Why it breaks today

What QB Control changes

Use case: parallel volumetric and gravimetric feed on one vessel

What the evidence shows

Why it breaks today

What QB Control changes

Use case: reshaping an exponential feed profile mid-run

What the evidence shows

Why it breaks today

What QB Control changes

Use case: live handover between two feeding strategies

What the evidence shows

Why it breaks today

What QB Control changes

Use case: discovering new hardware while the process executes

What the evidence shows

Why it breaks today

What QB Control changes

Use case: live mass-balance residual across four streams

What the evidence shows

Why it breaks today

What QB Control changes

Use case: event-driven bleed control against a polled implementation

What the evidence shows

Why it breaks today

What QB Control changes

Use case: transmembrane pressure as a computed recipe signal

What the evidence shows

Why it breaks today

What QB Control changes

Use case: analyzer dropout and documented fallback

What the evidence shows

Why it breaks today

What QB Control changes

Use case: an unattended run whose report is the handover

What the evidence shows

Why it breaks today

What QB Control changes

Use case: following one mid-run change through compliance

5. What This Adds Up To

Four questions worth asking of any feeding control system

Where to start

Reference Documents

Methodology, Assumptions and Legal Disclaimer

Topics

Curious to see how it works?

Contact us