Connectivity and Interoperability Standards

📍 Where we are: The last chapter organized the systems with a reference architecture; this one gives them a shared language so the data can actually move between them.

In the previous chapter we stacked the plant into levels — sensors at the bottom, the enterprise at the top — using the ISA-95 / Purdue hierarchy, and we saw how operational technology (OT) and information technology (IT) are converging along an edge-to-cloud path. But a tidy diagram of levels does not, by itself, make data flow. A bioreactor's controller, a chromatography skid, a lab spectrometer, and the factory's manufacturing system can sit perfectly arranged on that diagram and still be unable to exchange a single number, because each was built to speak its own private dialect. This chapter is about the agreements — the standards — that let them talk.

The simple version

Imagine a giant hospital where every doctor, nurse, and machine speaks a different language. You could hire a translator for each pair of people — but with 100 people that is thousands of translators, and adding one new nurse means hiring 100 more. The smarter fix is to agree on one shared language everyone learns. Connectivity standards are that shared language for machines. The catch: speaking the same language is not the same as understanding each other — and that gap is the whole point of this chapter's ending.

What this chapter covers

We follow the data from the plant floor upward: first the standards that connect process equipment (OPC UA and MTP), then the lightweight publish/subscribe backbone that complements them (MQTT / Sparkplug B), then the laboratory (SiLA 2, AnIML, Allotrope), then the business layer (ISA-95 / B2MML), and finally the distinction that all of this exposes — moving bytes versus preserving meaning.

The connectivity stack: transport versus semantic

Why point-to-point integration collapses

The naïve way to connect systems is point-to-point: write a custom piece of software — an interface — for each pair that needs to talk. Two systems need one interface. But the number of possible pairs is n×(n−1)/2, which grows roughly with the square of the number of systems — so ten systems can need up to forty-five interfaces, and twenty can need one hundred and ninety. Engineers call this the n² problem: connection cost explodes faster than the plant grows. Worse, each interface is proprietary and brittle — swap one instrument and every interface touching it breaks.

The same four systems connected two ways: a tangle of custom links versus one shared standard. Original diagram by the authors, created with AI assistance.

A shared standard cuts that tangle to a single connection per system. That is the entire economic case for standards: they convert a quadratic problem into a linear one.

Transport standards versus semantic standards

The standards in this chapter divide cleanly into two stacked jobs, and confusing them is the most common mistake in plant integration. Transport standards move bytes between systems: they define a wire protocol, a session, a security envelope, and a way to address a value. OPC UA and MQTT live here. Semantic standards preserve meaning: they define vocabularies, units, and relationships so that a value still means the same thing after it has travelled. Allotrope's ontologies, AnIML's technique definitions, and NIST UnitsML live here. The same physical reading — a CHO (Chinese hamster ovary, the industry's standard antibody-producing cell line) bioreactor's titer measured in the production bioreactor — needs both layers to arrive intact and understood. Get the transport but not the semantics and you have a fast pipe delivering ambiguity; that gap is this chapter's destination.

Where each connectivity standard lives: transport standards move bytes; semantic standards preserve meaning. Original diagram by the authors, created with AI assistance.

Connecting the process: OPC UA and MTP

OPC UA: the request-driven standard

The dominant standard for connecting process equipment is OPC UA — OPC Unified Architecture, published as the international standard IEC 62541 [1]. ("OPC" originally meant OLE for Process Control, but the modern standard has outgrown the acronym.) Vendors such as Siemens, ABB, and Rockwell Automation ship industrial control systems with OPC UA built in, and bioprocess-equipment makers such as Sartorius and Eppendorf ship bioreactors and chromatography skids with OPC UA drivers. Its crucial idea is that it does far more than shuttle raw numbers. OPC UA carries an information model: alongside the value 37.0, it carries that this is a temperature, measured in degrees Celsius, belonging to bioreactor BR101, with a timestamp and a quality flag. This structured, self-describing space of objects is called the address space [1]. A single node in that address space might be addressed as ServerName/Bioreactor/BR101/Temperature/Value, carrying attributes for its units (°C), a timestamp (2026-06-13T14:23:07.123Z), and a quality flag (Good, Uncertain, or Bad). A receiving system does not need to be pre-told what each number means; the data describes itself.

OPC UA is request-driven: a client opens a connection, asks the server what do you have?, and reads — or subscribes to — the nodes it wants. That conversation is wrapped in a real security model. Before any data moves, the client and server negotiate a secure channel with a cryptographic policy, exchange and validate application certificates, and decide whether to trust each other by checking those certificates against a trust list — the explicit set of peers a server will even talk to. Only then does a session carry the user identity. A security policy is just a named bundle that fixes which cryptographic algorithms the channel uses — how it encrypts the data and how it signs each message to prove it was not tampered with. The long-serving baseline policy is named Basic256Sha256; it is the one most deployed equipment still negotiates, and the one the open-source companion (Book 3 of this series, where these standards become runnable code) stands up in code. Note, though, that the OPC Foundation (the industry consortium that maintains the OPC UA standard and publishes its registries) has formally deprecated Basic256Sha256 in favor of the newer AES-based policies Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss, so a current-day greenfield plant should prefer those — a reminder that "the modern baseline" is a moving target even inside one standard. This is the same address space, certificate, and trust-list machinery that Book 3 stands up in code in Speaking OT: OPC UA, MQTT, and Sparkplug B, down to the Basic256Sha256 policy and the DataValue a client reads back.

OPC UA is platform-neutral and built for secure factory networks. Because of these strengths, comparative engineering studies benchmark it as a reference connectivity protocol for what is called Industry 4.0 (the shift toward digitized, networked manufacturing), testing its performance against lighter messaging protocols such as MQTT [9]. That security and self-description also carry a regulatory dividend: under FDA data-integrity guidance and EU Annex 11, data transferred between systems must stay attributable and unaltered, and the structured address space and built-in security of OPC UA help preserve that chain of custody electronically — the same ALCOA+ chain of custody the next chapter formalizes.

One nuance keeps the picture honest: request-driven is not the only shape OPC UA takes. The standard's Part 14 adds a native PubSub model (publish/subscribe with no per-client session, runnable over UDP multicast or over MQTT itself), and OPC UA FX (Field eXchange) extends it down to deterministic controller-to-controller traffic — direct exchange between the programmable controllers that run the equipment, with guaranteed timing rather than best-effort delivery. The request/response client-server model is the one a data-management reader meets most, but OPC UA and the publish/subscribe world the next section introduces are not strictly rival camps.

note

The phrase plug-and-produce is the factory cousin of plug-and-play: you connect a new piece of equipment and it works, with little hand-written integration. Standards are what make that possible.

MTP: modular plug-and-produce

OPC UA solves how machines talk. A second standard tackles how whole production modules are described so they can be assembled like building blocks: the Module Type Package (MTP), defined in VDI/VDE/NAMUR 2658 [2]. The standard splits the world into two roles. A physical module — say, a self-contained filtration skid — is a Process Equipment Assembly (PEA), and it ships with an MTP: a vendor-neutral digital manifest describing its interfaces, its services, and a description of its operator interface (HMI). The supervisory system that reads those manifests and conducts the modules is the Process Orchestration Layer (POL). The POL imports each PEA's MTP and integrates the module automatically, communicating over OPC UA [2]. This is modular plug-and-produce: it lets a manufacturer reconfigure a line from interchangeable units instead of re-engineering everything — exactly the flexibility that intensified, single-use bioprocessing demands. Equipment makers including Sartorius and Pall have released MTP-compatible skids for steps such as chromatography, buffer preparation, and filtration in recent years.

A downstream example: the data a Protein A capture skid throws off

The standards above are easiest to feel on a concrete downstream unit operation, because purification skids are where the richest, most decision-laden data streams are born. Take the first purification step, Protein A affinity capture — the chromatography step that grabs the monoclonal antibody out of the clarified harvest and discards most impurities (described in Book 1's capture chapter). A capture skid is precisely the kind of self-contained PEA the MTP standard imagines: a column packed with Protein A resin, pumps, valves, and a UV detector, running the four-phase load / wash / elute / clean cycle as an MTP service the POL can start and monitor. While it runs, its OPC UA address space exposes a live stream of self-describing DataValues — the UV280 absorbance (in milli-absorbance units, mAU, the protein-elution trace), conductivity (mS/cm), inlet and outlet pressure (bar), flow rate (L/min), and pH — each carrying its units, timestamp, and quality flag exactly as BR101's temperature did upstream. The skid also emits event data the n² problem makes painful to integrate by hand: the phase transitions, the dynamic binding capacity (DBC) the load was sized against (in grams of antibody per litre of resin), and — the highest-value record of all — the two operator-set pooling-window cut points that decide which slice of the elution peak is kept as product. That pooling decision is a real-time quality judgment that must land in the batch record attributable and unaltered; carrying it over a self-describing transport like OPC UA, rather than re-keying it from a local chart, is the difference between a reviewable electronic record and a transcription waiting to fail an audit. One book further along, Book 3 builds exactly this downstream chromatography bridge in code, turning the skid's tags and its pooling decision into a contextualized record.

Sparkplug B over MQTT: the pub/sub backbone

OPC UA is request-driven and rich, but a plant with hundreds of devices and thin network links also wants a lightweight, fan-out path that does not require every consumer to poll every server. This is the publish/subscribe backbone that carries data across the OT/IT seam the reference-architecture chapter drew — the layer that lets a forest of edge devices feed cloud and enterprise consumers without a point-to-point cable to each. The transport is MQTT (an OASIS standard, also published as ISO/IEC 20922 [12]): a publish/subscribe protocol where devices publish to topics and a broker fans each message out to whoever subscribed. MQTT is frugal enough to run on a soil sensor or a bioreactor skid, but raw MQTT is stateless and topic-anarchic — any device can publish anything to any string, and a subscriber cannot tell a silent device from an unchanged one.

Sparkplug B (Eclipse Sparkplug 3.0.0) is the open specification that disciplines MQTT for industrial use [13]. It fixes a strict five-field topic namespace and a birth/death lifecycle. When an edge node connects, it publishes a birth message (NBIRTH for the node, DBIRTH for each device beneath it) that defines every metric it will ever report — name, datatype, current value. The birth is a contract: nothing may appear later that was not declared in one. Afterward the node sends only what moved — NDATA / DDATA carrying the changed values and nothing else. This report by exception is the same economy as an OPC UA subscription's deadband — a threshold below which a value has not changed enough to be worth resending — and it is why a Sparkplug bus stays quiet over a stable process.

The clever part is death. Sparkplug leans on MQTT's Will message: when the edge node connects, it hands the broker a pre-written NDEATH payload registered at QoS 1 — an MQTT delivery guarantee that the message will arrive at least once rather than be silently lost — so it cannot be silently dropped. If the connection then dies — a crash, a pulled cable, a power loss — the broker itself publishes that pre-armed death certificate. There is no polling and no timeout guessing; the network learns within the keep-alive window — the timeout, set when the device connects, after which a silent client is presumed gone — that the device is gone. For a process where a silently dead sensor could mean an unnoticed temperature excursion, that guarantee earns its keep.

Two ways to start and stop talking: OPC UA negotiates a secure session on request, while Sparkplug B announces its birth and pre-arms its own death so the bus is never left guessing. Original diagram by the authors, created with AI assistance.

Sparkplug also carries quality on the wire, but with a twist worth knowing: many edge nodes front a legacy OPC DA server — OPC Data Access, the original OLE-for-Process-Control interface that OPC UA replaced, still embedded in much installed equipment — and pass its quality straight through, so a Good reading often shows up as the integer 192 (the legacy OPC DA "Good" code), not the OPC UA zero. Same idea, two lineages — a small but real reminder that even inside one device a value can wear two different quality conventions. Book 3 builds this exact Sparkplug bus, the seq/bdSeq sequencing, and the 192-versus-zero quirk in Speaking OT: OPC UA, MQTT, and Sparkplug B.

Anatomy of a connectivity data point: OPC UA DataValue and Sparkplug metric

Every other chapter dissected a record that sits still — a tag, a batch row, a sample. Connectivity's data point is different: it is a reading in motion, and the two dominant standards carry that same reading in two different shapes. The figure below puts them side by side. On the left, an OPC UA client reads the bioreactor's titer and gets back not a bare 4.902 but a DataValue — value, quality, and time bound together — hanging off a node that also advertises its units, its valid range, and typed References to its neighbors. On the right, the same reading rides the Sparkplug bus as a metric: the address is in the topic, the envelope carries a timestamp and a wrapping sequence number (a counter that lets a subscriber spot a dropped message, resetting to zero once it passes its maximum of 255), and the metric itself names the value, its alias, its datatype, and a properties card holding the unit and quality.

The same 4.902 g/L titer reading carried two ways: an OPC UA DataValue answered on request versus a Sparkplug B metric announced on the bus — both bind value to quality, units, and time, neither is ever a bare number. Original diagram by the authors, created with AI assistance.

The point is not which shape is "better." It is that both standards independently arrived at the same discipline this whole book argues for: a measurement is never just a number, it is a number plus its meaning. That structured reading is exactly the self-describing data point born at the sensor, the control-system signal that flows up the ISA-95 levels into the plant information systems, and — one book further along — the concrete OPC UA node and Sparkplug message Book 3 stands up in code.

Connecting the lab: SiLA 2, AnIML, and Allotrope

The laboratory has its own connectivity tradition, because instruments are even more diverse than process equipment. Three standards matter most.

SiLA 2 standardizes device integration — how lab instruments are controlled and read out [3]. It uses a service-oriented design: each instrument exposes its capabilities as network services (a microservice style, where small independent units each do one job), and those capabilities are described in a machine-readable Feature Definition Language so software can discover what an instrument can do without bespoke drivers [3]. Under the hood, SiLA 2 carries those service calls over gRPC — a modern, language-neutral remote-procedure-call framework that uses HTTP/2 and Protocol Buffers — which is what lets a Python orchestration script and a vendor's C++ instrument firmware speak the same Features without a hand-written driver. Lab-automation vendors such as Tecan and Hamilton are among those advancing SiLA 2 support in their instruments and platforms. SiLA 2 governs commanding the instrument.

The standards so far govern how systems talk. But the data produced by instruments — the actual numbers, spectra, and results — needs its own standards. AnIML — the Analytical Information Markup Language, an open XML format developed under ASTM (subcommittee E13.15) — was an early, foundational effort, structured as a stable core plus pluggable technique definitions for each measurement type, so results from different methods share one container with full data-integrity context [5]. The point is that every measurement carries its own context inside the file. A simplified AnIML-style record makes this concrete:

<Result name="pH Measurement">
  <SeriesSet>
    <Series name="pH" dependency="dependent">
      <IndividualValueSet>
        <F>7.20</F>
      </IndividualValueSet>
      <Unit label="pH" />
    </Series>
  </SeriesSet>
  <Method name="SOP-PH-001 pH Determination" />
  <Instrument id="PH-METER-07" />
  <Timestamp>2026-06-13T14:23:07.123Z</Timestamp>
</Result>

The value, its unit, the method that produced it, the instrument, and the time of measurement all travel together. AnIML grew out of older ASTM analytical-data-interchange specifications — the ANDI/NetCDF analytical-data protocols, whose mass-spectrometry pair is the ASTM E2077 specification and ASTM E2078 guide [6].

The most active modern effort is the Allotrope Foundation's stack. Its anchor is a set of ontologies — formal, machine-readable vocabularies that fix not just the names but the defined relationships and meaning of each term — known as the AFO, the Allotrope Foundation Ontologies [4]. The stack then offers two ways to carry data against that shared meaning. The Allotrope Data Format (ADF) is a single self-contained file (built on HDF5, a binary container format designed for large scientific datasets) holding the raw numbers, the context, and the description together — well suited to large instrument datasets. The Allotrope Simple Model (ASM) is the lighter-weight, JSON-based representation of the same modeled meaning; because it is plain JSON it is far easier to produce and consume in everyday software, and it has become the more widely adopted of the two for routine result exchange. Member companies including Roche and instrument makers such as Agilent and Shimadzu contribute to these ontologies through the Foundation. The goal of all three pieces is vendor-agnostic analytical data: results that mean the same thing regardless of which company's instrument produced them [4].

caution

A standard for the lab information system is distinct from these. ASTM E1578 (Standard Guide for Laboratory Informatics) covers LIMS (laboratory information management system) and related lab-software systems — LES (laboratory execution system), ELN (electronic lab notebook), SDMS (scientific data management system), CDS (chromatography data system) — the software that tracks samples and tests — and provides shared terminology and best practices rather than a wire format. Knowing which standard governs which layer prevents a great deal of confusion.

Connecting the business: ISA-95 and B2MML

Higher up, the factory's MES (manufacturing execution system — the software running the actual production) must exchange information with the ERP (enterprise resource planning — the business software for orders, inventory, and finance). The agreement here is ISA-95, standardized internationally as IEC 62264 [7]. ISA-95 is the same standard whose level hierarchy organized the last chapter; here we use its object models — its formal definitions of named objects such as a ProductionSchedule and its ProductionRequests, a MaterialLot, and a MaterialDefinition [7].

To send those objects between systems, the industry uses B2MML (Business To Manufacturing Markup Language) — a set of royalty-free XML schemas, maintained by the trade association MESA International, that implement the ISA-95 object models for ERP/MES data exchange in both directions [7]. (The same schema family includes BatchML, which implements the ISA-88 batch-control objects — ISA-95's sibling standard for how a batch recipe is structured and executed, rather than how MES and ERP exchange data.) When the business system issues "make 500 vials of Product X," it sends a B2MML ProductionSchedule carrying that ProductionRequest down to the plant, and the plant returns the matching ProductionResponse and MaterialLot records back up. In a regulated plant, those electronic messages cannot move in a vacuum: where they create or modify GMP electronic records, 21 CFR Part 11 and EU Annex 11 expect a tamper-evident audit trail and, for electronically approved records, a valid electronic signature — both laws are the subject of their own chapter, Records, Signatures, and the Law — so the connectivity layer and the compliance layer are designed together.

Standards do not validate themselves: qualification and the CSV-to-CSA shift

A connection that conforms to OPC UA or B2MML is not, by that fact, qualified for GMP use — conformance proves the bytes parse, not that the integration is fit for purpose. Before a connected system may run a regulated batch, it is validated (proven, documented, and held under change control), traditionally through the three qualification rungs IQ / OQ / PQ — Installation Qualification (the system and its drivers are installed as specified), Operational Qualification (each OPC UA service, address-space node, and B2MML message behaves as specified in a test environment), and Performance Qualification (the integrated line meets its acceptance criteria on real product). The MTP promise of plug-and-produce shifts where that effort lands rather than removing it: a vendor's qualified PEA carries its own Factory and Site Acceptance Testing (FAT/SAT) evidence the integrator can leverage, so the POL re-qualifies the interfaces and the orchestration, not the module from scratch. This is also where the connectivity layer meets the move from CSV (Computerized System Validation) to risk-based CSA (Computer Software Assurance) that Validating Computerized Systems tells in full: under the GAMP 5 / CSA lens, the assurance effort on an interface scales to its patient risk — a B2MML link that merely schedules vials earns a lighter, unscripted check than an OPC UA channel writing a setpoint to a sterilizing filter. And the same connectivity that makes data flow is what makes that data ALCOA+ — Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available — end to end: a self-describing DataValue carried over a secure, authenticated channel arrives attributable to its source node and contemporaneous to its real timestamp, the very properties the next chapter formalizes. The same discipline governs tech transfer — moving a validated process from a development site to a manufacturing site, or scaling it up — because a recipe only transfers cleanly when both sites' systems agree on what each tag means, which is the unsolved semantic-alignment problem the end of this chapter returns to.

Syntactic versus semantic interoperability

Every standard so far solves part of one problem and exposes a deeper one. There are two different kinds of interoperability — the ability of systems to work together.

Syntactic interoperability means systems agree on format: the message parses, the fields line up, the bytes arrive intact. Semantic interoperability means they agree on meaning: both ends agree the value is on the same scale and in the same units [8], and that one system's pH and another's acidity name the same physical quantity under the same conditions. Syntax moves the bytes; semantics preserves the meaning.

This is not hair-splitting. Two instruments can both emit valid XML — perfect syntax — yet label the same measurement differently, or report it in different units, so software silently combines numbers that should never be combined. Imagine one analyzer reporting a result as a bare scalar 7.2 while another wraps it as <pH units="pH_units" value="7.2"/>. A program that merges both feeds, but never checks the units field, can silently apply different scale factors and corrupt the combined dataset without any error ever surfacing. The fix lives one level deeper: machine-readable definitions of meaning. NIST's UnitsML, a markup for embedding unambiguous units of measure inside formats such as AnIML, is a concrete example of supplying that semantic layer [8], and it is exactly why standards like Allotrope invest so heavily in ontologies [4].

What the semantic layer looks like, made explicit

It is worth seeing what "machine-readable meaning" actually is, because the next two chapters build it in earnest and this chapter is where the need first bites. A reading that arrives over OPC UA as a DataValue — value, units, quality, time — can be written as a small set of RDF triples (the subject–predicate–object statements of fact that a knowledge graph is built from), so the meaning the transport carried in attributes becomes meaning a reasoner can act on. The same BR101 titer reading looks like this in Turtle (the standard text syntax for RDF; bp: is a placeholder namespace for the plant vocabulary, qudt: the QUDT units ontology):

# one self-describing titer reading as RDF triples — the semantic twin of an OPC UA DataValue
bp:BR101-titer-2026-06-13T1423 a bp:TiterMeasurement ;
    bp:ofBatch        bp:BATCH-2026-001 ;
    bp:measuredOn     bp:BR101 ;
    bp:hasValue       4.902 ;
    bp:hasUnit        qudt:GM-PER-L ;          # grams per litre, NOT mg/L
    bp:hasQuality     "Good" ;
    bp:resultTime     "2026-06-13T14:23:07.123Z"^^xsd:dateTime .

This is the same discipline the ontologies-and-FAIR chapter and Book 4 formalize, where an ontology fixes not the name of a tag but its defined relationships and meaning. Two further ideas from that book are worth borrowing here, because they speak directly to the gap this chapter exposes. First, a competency question — a question the data must be able to answer, the unit of an ontology's specification (see specification and ORSD) — turns "does my graph have units on every titer?" into an executable SPARQL query (the standard query language for RDF) that either returns the offenders or returns nothing:

# CQ: every titer measurement must declare an explicit unit — list any that do not
PREFIX bp: <https://example.org/bioproc#>
SELECT ?m WHERE {
  ?m a bp:TiterMeasurement .
  FILTER NOT EXISTS { ?m bp:hasUnit ?u }
}

Second, the units rule the bare-scalar 7.2 violated is not prose in an SOP a human must remember — it can be a SHACL shape (the Shapes Constraint Language, a closed-world gate over graph data; see the release gate and SHACL) that fails any measurement missing a unit, exactly the way a release gate fails a missing sterility test:

# SHACL: a titer measurement is invalid unless it carries exactly one explicit unit
bp:TiterShape a sh:NodeShape ;
    sh:targetClass bp:TiterMeasurement ;
    sh:property [ sh:path bp:hasUnit ; sh:minCount 1 ; sh:maxCount 1 ;
        sh:message "A titer measurement must declare exactly one explicit unit." ] .

The deeper modeling point that Book 4 makes from BFO is one this chapter has already met without naming: the connectivity data point is an occurrent — a measurement event that happens at an instant and is then over — bound to a continuant, the batch of antibody that persists and bears the titer through time. OPC UA's sourceTimestamp and Sparkplug's envelope timestamp are both pinning when the occurrent happened; keeping that distinct from the thing measured is exactly what lets one batch's genealogy be traced across thousands of readings. The transport carried these facts as attributes; the semantic layer turns them into statements a machine can query, constrain, and reason over — which is the bridge from this chapter into the semantic-interoperability and ontology chapters that follow.

The unsolved challenge: semantic alignment across multi-vendor deployments

It is tempting to read this chapter as a solved problem — adopt OPC UA, layer on ontologies, and meaning takes care of itself. It does not, and the gap is concrete. Imagine two bioreactor skids from two vendors, both shipping fully compliant OPC UA servers. Both are syntactically perfect. Yet one exposes the titer reading under the address Bioreactor/BR101/Titer in grams per litre with quality reported as the OPC UA zero, while the other exposes it under Reactor1/PV/Product_Conc in milligrams per litre with quality passed through as the legacy OPC DA 192. Nothing is broken. Both servers are standard. A collector that subscribes to both still has to be told, by a human, that these two address spaces name the same physical quantity and that one feed must be scaled by a thousand before the two can be compared.

OPC UA's answer to this is the companion specification — a per-domain agreement that fixes the address-space layout, the node names, and the units for a given kind of equipment, so two compliant servers expose the same measurement the same way. The OPC Foundation publishes a registry of these for pumps, machine tools, analytics, and many other domains [10]. The trouble for our industry is what is not in that registry: there is no published companion specification for a CHO (Chinese hamster ovary) mammalian-cell bioreactor. So in practice each integrator hand-maps each vendor's address space, and that mapping is bespoke, undocumented, and quietly assumes the units and quality conventions are what the engineer happened to expect — the very assumptions the misconfigured-server problem warns against. (OPC UA is built for isolated factory networks, but in practice some servers end up exposed to the open internet through misconfiguration — and the same 2020 internet-wide study that scanned for those found most reachable OPC UA servers misconfigured exactly this kind of detail, including hundreds advertising the Basic256Sha256 policy while presenting certificates that did not match it [11], is a reminder that "compliant" and "correctly deployed" are different claims.) Allotrope's AFO attacks the same problem from the lab side with a shared ontology of analytical meaning [4], but the AFO does not describe a running bioreactor's process tags either.

So the honest state of the art is this: the transport of bioprocess data across vendors is a solved, standardized, secure problem; the semantic alignment of that data across vendors is still largely manual, deployment-specific, and unbacked by a published bioreactor companion spec. That is why the semantic-interoperability and ontology chapters that follow are not a victory lap but the genuinely open frontier — and why Book 3 spends whole chapters bridging real systems by hand, from historians to MES and ERP, precisely because no standard does it for you.

Why the missing companion spec is a machine-learning problem too

The two-vendor mismatch above is not only an integration nuisance; it is the silent killer of any model trained on the combined data. A soft sensor (a software model that infers a slow, expensive lab value — here titer — from cheap online signals, the central object of Book 5) consumes exactly the DataValue stream this chapter describes: it is fed by the self-describing address space. So when one skid reports Bioreactor/BR101/Titer in grams per litre and another reports Reactor1/PV/Product_Conc in milligrams per litre, a model that joins the two feeds on a hand-written mapping inherits every assumption that mapping got wrong — a thousand-fold scale error becomes a thousand-fold feature error, learned as if it were biology. The semantic layer above is not academic hygiene for the model; it is the difference between a feature and an artifact.

Three machine-learning consequences follow directly, and each is developed in Book 5:

• Address-space drift is the input-distribution shift a model must watch for. Book 5's MLOps chapter splits model decay into covariate shift (the inputs move) and concept drift (the input-to-answer relationship moves), and watches the first with a Population Stability Index (PSI) — a standard measure of how far an input distribution has moved from the one a model was trained on. A vendor firmware update that silently re-scales a tag, or a re-mapped address space after an equipment swap, registers as a covariate shift the model never lived through — process drift and connectivity drift wearing the same statistical signature. The lesson is sharp: a model fed by an un-aligned address space cannot tell a real biological excursion from a units re-mapping, and only the semantic layer separates them.
• Cross-vendor data forces a batch-grouped, leak-free split. Book 5's data chapter shows that the correct way to validate a bioprocess model is a batch-grouped split — every reading from a given batch goes wholly to train or wholly to test, never both — scored with grouped or leave-one-batch-out cross-validation (rotating which batches are held out). A row-wise random split scatters near-identical neighbouring readings across the train/test line and reports a fantasy score; only the batch_id that contextualization attaches — the same identity the connectivity layer must carry intact — makes the honest split possible. Without a companion spec aligning two vendors' address spaces, the very batch identity the split depends on is itself hand-mapped and fragile.
• The companion-spec gap is the cross-batch generalization gap. A soft sensor calibrated on one vendor's skid will not transfer to another's until something reconciles their address spaces — exactly the cross-batch, cross-instrument generalization problem Book 5 calls the validation paradox. A model can look excellent within one deployment and fail outright on the first reading from a differently-mapped server, for the same reason an unaligned units field corrupts a merge. The semantic alignment this chapter leaves open is precisely the precondition a trustworthy, transferable model needs — clean, governed features with traceable identity — which is why Book 5 treats this book's data-management work as barrier number one, not an afterthought.

Why it matters

For data management, the lesson is that connectivity is necessary but not sufficient. Adopt OPC UA, MTP, SiLA 2, AnIML, Allotrope, and B2MML and you have solved the n² problem — data now flows cheaply and reliably across the plant and the lab. But flowing data is not the same as trustworthy, comparable data. If meaning is not preserved end to end, you build a fast pipeline that efficiently delivers misunderstandings. Choosing standards is therefore a two-part decision: a transport choice (which protocol) and a semantic choice (which vocabulary of meaning) — and skipping the second is the most expensive mistake in the field.

In the real world

These standards are not aspirational; they are how working plants are built. OPC UA is the default backbone for new process automation [1][9], MTP-based modular units are shipped by major equipment vendors [2], and SiLA 2 and Allotrope are advanced through industry consortia of pharmaceutical companies and instrument makers [3][4]. In practice the two transports rarely run end to end on their own: an edge gateway sits at the OT/IT seam, speaking OPC UA down to the equipment and republishing onto the Sparkplug bus upward — the pattern Book 3 builds in its edge-gateway chapter. Real-time lab-data proof-of-concept efforts sit precisely at the seam this chapter exposes: getting instruments, labs, and partner organizations not merely connected but semantically aligned, so a number measured in one place means the same thing everywhere it travels. That is the bridge from this chapter into Part IV of the book.

Key terms

• Standard — a published, shared agreement that lets different systems exchange data the same way.
• Point-to-point integration — connecting systems with one custom interface per pair; suffers the n² problem.
• n² problem — the explosion of needed connections as systems multiply.
• OPC UA (IEC 62541) — the dominant, request-driven process-connectivity standard, carrying a self-describing information model, not just raw values.
• Information model / address space — the structured, self-describing organization of data inside OPC UA.
• DataValue — the OPC UA bundle that binds a value to its quality (StatusCode) and time (source and server timestamps) so a reading is never a bare number.
• MQTT / Sparkplug B — a lightweight publish/subscribe transport (MQTT) disciplined for industry by Sparkplug B's strict topic namespace and birth/death lifecycle.
• Report by exception — sending only changed values after an initial definition, the economy shared by Sparkplug data messages and OPC UA subscriptions.
• Companion specification — a per-domain OPC UA agreement fixing the address-space layout, node names, and units so compliant servers expose the same measurement the same way.
• Plug-and-produce — the factory ability to add equipment with minimal hand-written integration.
• MTP (Module Type Package, VDI/VDE/NAMUR 2658) — a vendor-neutral manifest letting production modules (each a Process Equipment Assembly, PEA) be assembled like building blocks under a Process Orchestration Layer (POL).
• SiLA 2 — a service-oriented standard, carried over gRPC, for integrating and commanding laboratory instruments.
• AnIML — an open, ASTM-developed XML format for storing analytical results with full context.
• Allotrope (ADF / ASM / AFO) — a modern stack for vendor-agnostic analytical data, including ontologies of meaning.
• ASTM E1578 — the standard guide for laboratory informatics (LIMS and related systems).
• ISA-95 / IEC 62264 — the enterprise-control integration standard and its object models.
• B2MML — the XML implementation of ISA-95 used for ERP-MES messaging in both directions.
• Syntactic interoperability — agreement on data format.
• Semantic interoperability — agreement on data meaning.
• Protein A capture skid — the first downstream purification PEA, whose OPC UA address space exposes UV280, conductivity, pressure, flow, pH, the dynamic binding capacity it was loaded against, and the operator-set pooling-window cut points that decide which slice of the elution peak is kept.
• RDF triple / SPARQL / SHACL — the semantic-layer trio: a subject–predicate–object statement of fact, the query language that reads it, and the closed-world shape that gates it (e.g. failing any titer missing a unit).
• Continuant vs. occurrent — the BFO distinction between a thing that persists (the batch of antibody) and an event that happens and is over (the measurement); a connectivity data point is an occurrent bound to a continuant.
• Soft sensor — a software model that infers a slow, expensive lab value (e.g. titer) in real time from cheap online signals; it is fed by the self-describing DataValue stream and so inherits any units or address-space misalignment as a feature error.
• Batch-grouped split — the leak-free validation discipline of keeping every reading from one batch wholly in train or wholly in test, keyed on the batch_id the connectivity layer must carry intact.
• Drift (covariate shift) / PSI — model decay from a moving input distribution, watched with the Population Stability Index; a re-mapped address space or silently re-scaled tag registers as drift the model never lived through.
• IQ / OQ / PQ — Installation, Operational, and Performance Qualification: the three rungs that prove a connected system is installed, operates, and performs as specified before it runs a GMP batch.
• CSV → CSA — the shift from exhaustive Computerized System Validation to risk-based Computer Software Assurance, scaling the assurance effort on each interface to its patient risk.

Where this leads

Standards get data moving and, with the right semantic layer, get it meaning the same thing everywhere. But moving and meaning are not enough on their own: every number that flows must also be trustworthy — provably true, unaltered, and traceable to who recorded it and when. The next chapter, Data Integrity and ALCOA+, introduces the principles that make data believable — Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available — together with audit trails and the data-integrity enforcement wave that reshaped the entire industry.