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 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.

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 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. Figure by the authors.

Where each connectivity standard lives: transport standards move bytes; semantic standards preserve meaning. 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.

Connecting the process: OPC UA and MTP

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 BR-101, 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 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.

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.

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]. According to the standard, a module designed for such integration — say, a self-contained filtration skid — ships with an MTP, a vendor-neutral digital manifest describing its interfaces, its services, and a description of its operator interface (HMI). The plant's control system reads the 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.

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]. 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. It pairs the Allotrope Data Format (ADF) — a single file holding the raw numbers, the context, and the description together — with the Allotrope Simple Model (ASM) and 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]. Member companies including Roche and instrument makers such as Agilent and Shimadzu contribute to these ontologies through the Foundation. The goal 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 and related lab-software systems (LES, ELN, SDMS, CDS) — 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 a production order, a material lot, a batch record [7].

To send those objects between systems, the industry uses B2MML (Business To Manufacturing Markup Language), an XML implementation of the ISA-95 object models for ERP/MES data exchange in both directions [7]. When the business system issues "make 500 vials of Product X," B2MML is the structured message format used to send that instruction down to the plant and report the results 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 — so the connectivity layer and the compliance layer are designed together.

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].

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]. The U.S. NIIMBL institute and its NIIMBL-NIST real-time lab-data proof of concept 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. (Nearby, NIIMBL's SABRE center — a pilot-scale cGMP biomanufacturing and workforce-training facility — is being developed to give such advanced biomanufacturing approaches a place to be scaled up, de-risked, and taught.) 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 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.
• 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 be assembled like building blocks.
• SiLA 2 — a service-oriented standard 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.

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.