OPC-UA in Fermentation Data Infrastructure: What It Is and Why It Matters for Modeling

If you've been in fermentation process development for more than a few years, you've encountered OPC-UA — usually while trying to figure out why your historian data won't export cleanly, or while asking your process controls engineer whether the DCS can stream live data to an external tool. This article is a practical introduction for fermentation scientists who want to understand what OPC-UA actually is, what data it makes available, and why it matters for computational scale-up modeling.

What OPC-UA Is

OPC-UA (Open Platform Communications Unified Architecture) is an industrial communication protocol standard maintained by the OPC Foundation. It provides a standardized framework for real-time data exchange between industrial control systems (SCADA, DCS, PLCs) and external software applications — without requiring custom drivers or proprietary middleware for each combination of hardware and software.

Before OPC-UA (and its predecessor OPC-DA), connecting a historian database from one vendor (e.g., OSIsoft PI) to a control system from another vendor (e.g., Siemens PCS 7, DeltaV, Rockwell PlantPAx) required vendor-specific adapters and COM-based drivers that were fragile, platform-dependent, and difficult to maintain. OPC-UA replaced this patchwork with a platform-independent, transport-protocol-agnostic (TCP/IP, HTTPS) standard that any modern DCS, SCADA, or historian system should be able to speak.

For fermentation scientists, the practical implication is that OPC-UA is the mechanism through which modern bioreactor control systems can stream real-time process variables — DO%, pH, temperature, agitation, feed rate, pressure, off-gas composition — to external software for analysis, modeling, and feedback control.

The Data Model: Nodes, Tags, and Subscriptions

OPC-UA represents the data in a server as a hierarchical address space of nodes. Each node has a NodeId (a unique identifier within the server), a BrowseName (a human-readable tag), a value (the current measurement), and metadata (units, data type, quality). Navigating the node hierarchy is called "browsing" — you connect to an OPC-UA server, browse its address space, and identify the node IDs corresponding to the process variables you want to read.

For a typical bioreactor OPC-UA server, the address space hierarchy might look like:

Root/
  Objects/
    Bioreactor_1/
      Process_Variables/
        DO_percent/          (value: 38.4, unit: %, quality: Good)
        pH/                  (value: 7.02, unit: pH, quality: Good)
        Temperature/         (value: 37.1, unit: °C, quality: Good)
        Agitation_rpm/       (value: 380, unit: rpm, quality: Good)
        Feed_rate_Lh/        (value: 2.8, unit: L/h, quality: Good)
      Off_gas/
        O2_inlet_pct/        (value: 20.9)
        O2_outlet_pct/       (value: 18.4)
        CO2_outlet_pct/      (value: 2.1)

Once you've identified the relevant node IDs, you can set up a subscription: the OPC-UA server publishes updated values to your client whenever the value changes by more than a configured deadband, or at a specified sampling interval. For typical bioprocess monitoring, a 1-second sampling interval is more than sufficient for most variables. Off-gas measurements typically change on a timescale of 10–30 seconds, and DO and pH on a timescale of 30 seconds to 2 minutes in a well-mixed vessel.

PI Historian and OPC-UA

OSIsoft PI (now AVEVA PI) is the dominant industrial data historian in large-scale fermentation operations — particularly in CDMOs, established food ingredient producers, and any organization with SCADA-connected infrastructure. PI Historian stores time-series process data in a compressed archive and makes it available for retrieval.

The connection between PI Historian and OPC-UA is typically made via PI OPC-DA Server or PI Connector for OPC-UA, which exposes the PI tag namespace as an OPC-UA address space. This allows external software that speaks OPC-UA to read PI tags directly — either live (from the current value in PI's real-time event frame) or historicized (from archived values with timestamp, via OPC-UA's Historical Data Access extension, OPC-HDA).

For scale-up modeling applications, the most useful PI-OPC interface is the historical data access: being able to pull the full time series from a past fermentation run (DO%, feed log, OD600 if linked, temperature, pH, agitation, off-gas) as a structured dataset with consistent timestamps and quality codes. This is the data that populates the exchange flux inputs for FBA — and getting it cleanly from a PI archive via OPC-UA or PI OLEDB is substantially faster than manually exporting CSV files from the historian UI.

What Data Is Available for Metabolic Modeling

From a typical OPC-UA connected bioreactor system, the data streams available for metabolic model inputs are:

• DO%: Online, typically 1-second to 1-minute logging intervals. Used to estimate OUR via dynamic or steady-state methods, and to determine whether the culture is operating oxidatively or under oxygen limitation.
• Off-gas O₂ and CO₂: If available (requires gas analyzers on the exhaust line), these allow direct calculation of OTR (oxygen transfer rate) and CER (CO₂ evolution rate) via inlet/outlet gas balance. OTR and CER give you OUR and qCO₂ directly, without the kLa uncertainty of DO-based methods. The respiratory quotient RQ = CER/OTR is one of the most informative real-time metabolic indicators available.
• Feed rate: The feed pump log, if connected to the DCS and historian. Essential for calculating specific substrate uptake rate qs from mass balance.
• Agitation rpm and motor power: Together with vessel geometry, these allow estimation of P/V (power per unit volume) and correlation-based kLa.
• Temperature: Required for accurate oxygen solubility (DO* correction) and for temperature-dependent kinetic parameter adjustments.
• pH: pH log can indicate metabolic shifts (acid production from overflow metabolism, base consumption rate as a proxy for nitrogen utilization and growth rate).

What OPC-UA typically does not provide directly:

• Offline sample measurements (OD600, glucose concentration, titer, acetate, metabolite panels) — these must be manually entered or integrated from a LIMS.
• Cell-specific parameters (μ, qs, qO2) — these are calculated from the online and offline data, not directly measured.

Practical Considerations for OPC-UA Integration in Fermentation Environments

Security and network architecture

OPC-UA supports several security modes, including None (unauthenticated, unencrypted — appropriate only for isolated lab networks), Sign (authenticated but unencrypted), and SignAndEncrypt (authenticated and encrypted with X.509 certificate-based mutual authentication). Industrial facilities typically run OPC-UA on isolated process networks, and connecting to external software (like a cloud-based scale-up modeling platform) requires network architecture decisions: is the OPC-UA server on a DMZ-accessible network, or must data be extracted via a PI relay? These decisions belong to your IT and process controls teams, not to the fermentation scientist, but understanding the architecture helps you specify the correct connection approach when requesting integration.

Data quality codes

OPC-UA includes quality codes with every data point: Good, Uncertain, and Bad, with sub-status codes for specific failure conditions (probe failure, loss of communication, calibration needed). When extracting historical data for model inputs, always check quality codes and exclude Bad-quality intervals from your flux calculations. A DO probe that was uncalibrated for 4 hours mid-run will report apparently stable DO values that don't represent the actual culture state — and using those values to calculate OUR will produce incorrect model constraints.

Time synchronization

For data from multiple instruments to be meaningfully correlated (DO from probe A, feed rate from pump B, off-gas from analyzer C), the timestamps must be accurate and synchronized. OPC-UA uses UTC timestamps, which avoids daylight saving time artifacts, but the underlying hardware clocks for each instrument must be synchronized to a common reference. Timestamp drift of 30–60 seconds between the feed pump log and the DO sensor log will introduce artifacts into any qs-qO2 correlation analysis.

Integration in Practice: From Historian to Model Input

A practical integration workflow for extracting fermentation run data from a PI historian into a scale-up model might look like:

1. Identify the PI tag names for DO%, feed rate, agitation, temperature, and off-gas for the target run.
2. Pull the time-series data for the run from PI via PI OLEDB, PI OPC-HDA, or PI Web API. Specify a regular resampling interval (e.g., 60-second intervals) that's consistent with measurement dynamics and data volume requirements.
3. Merge offline sample data (OD600, glucose, titer, acetate from LIMS or manual entry) with the online data by timestamp.
4. Calculate derived variables: qs = (F × C_feed) / (V × DCW), qO2 from OTR balance or dynamic DO method, μ from OD600 time series, RQ = CER/OTR.
5. Pass these as exchange flux constraints to the FBA model. Solve for internal flux distribution. Use the result to parameterize the scale-up model.

This workflow can be partially automated once the data connections are established. The manual step — merging offline sample data by timestamp — remains a bottleneck in most fermentation operations, and improvements to LIMS-DCS integration reduce this bottleneck but don't eliminate it.

References

• OPC Foundation. OPC UA Part 1: Overview and Concepts. OPC Foundation; 2022.
• Mayr T, Gruber W, Moser D, et al. Comprehensive in-line monitoring of batch bioprocesses by modular Raman spectroscopy. J Biotechnol. 2015;200:1–7.
• Schügerl K. Progress in monitoring, modeling and control of bioprocesses during the last 20 years. J Biotechnol. 2001;85(2):149–173.