Selecting the Components of an Industrial Data Architecture

1. Introduction

1.1 The selection problem

Operational data does more than keep a plant running. It carries context that can improve the rest of the business if it is harnessed correctly, and every serious technology initiative now depends on it arriving intact. Yet the estates that produce it are rarely planned as a whole. An organization introduces a process, selects hardware, and moves data to meet an objective: to inform a decision, to automate a task. Each step requires a decision about how data gets from one place to another so that something can happen at a third. Those decisions are made in real time, to solve the problem of the day, and they compound, hundreds or thousands of times, across technology stacks, hardware, software, protocols and human interaction, until nobody can look at the whole picture in a clean and straightforward way.

The engineering response is to stop deciding case by case and plan: select technology that serves the whole, with interoperability, security and organization in view. Planning starts from the industrial standards of the day, Modbus, OPC Classic, OPC UA, MQTT, Sparkplug B, and each stack carries its own strengths, weaknesses and trade-offs in what it can interoperate with and how it can be secured. Three questions follow at once. Which one is the best and right one to use? Which one will actually work with the technology and needs at hand? And how does the plan cover yesterday’s installed base, today’s operation and tomorrow’s requirements? Depending on the organization’s expertise, its maturity, and its industry and compliance obligations, the answers lead down wildly different paths.

The first of those questions is the wrong one to ask. Posed as a contest, which term to standardize on, it has no correct answer, because the terms are not alternative answers to one question. Call that assumption the substitutability error: treating the terms as substitutes, so that adopting one releases the obligations the others would have carried. The error is not that practitioners choose badly. It is that the choice, as posed, cannot be answered, partly because the terms differ in kind, taken up in section 2.1, and partly because none of them covers the whole job, which is the subject of section 2.7. What the discourse lacks is a decomposition fine enough to show what each term is good at and what remains after it has done its work. Supplying that decomposition, and turning it into a method that answers the second and third questions rather than the first, is the task of this paper.

1.2 Six concerns collapsed into one conversation

Moving data, agreeing what the data means, organizing it so that it can be found, retaining it durably, governing who may see or change it, and securing the boundary it crosses are six distinct obligations. Public discussion runs them together, and a team that inherits the collapsed version attempts to satisfy all six with one artifact. This paper labels them MOVEMENT, MEANING, ORGANIZATION, RETENTION, AUTHORIZATION and SECURITY, and treats them as the primitive terms of the analysis.

1. MOVEMENT. Getting the data from where it is produced to where it is needed, at an acceptable latency and with a defined behaviour when the link fails.
2. MEANING. Fixing what a datum denotes: its type, its units, its place in an asset model, and its relation to the events and objects around it, in a form that holds across vendors and sites.
3. ORGANIZATION. Arranging data so that a consumer who does not know the producer can find what it needs, and so that two sites describe the same asset the same way.
4. RETENTION. Holding data and records over time, the process history and the record of access alike, with replay, correction, defined retention, and integrity sufficient to support an audit.
5. AUTHORIZATION. Deciding which principal may read or write which object across a trust boundary, and applying that decision consistently wherever the boundary is crossed.
6. SECURITY. Protecting the crossing between trust domains: preserving the segmentation the estate is assumed to have, opening no inbound path into the secure network, and encrypting what leaves it. AUTHORIZATION decides what a principal may do; SECURITY protects the channel and the boundary on which that decision rides.

One audit question runs through RETENTION and AUTHORIZATION, and it belongs to RETENTION. AUTHORIZATION decides, at the moment of a request, which principal may read or write which object. Whether anything can be reconstructed afterwards, what the data was and who reached it, is a question of what was kept, and keeping is RETENTION whether the thing kept is a process value or an access record. A system can therefore decide access perfectly and keep no record of its decisions, which is AUTHORIZATION without RETENTION, and it can keep immaculate records behind an interface that admits anyone, which is RETENTION without AUTHORIZATION.

Each term in the discourse solves one specific function well, and a function solved is not the goal of the overall architecture achieved. A system can move data flawlessly while the meaning of that data is undefined, which is MOVEMENT without MEANING. It can define meaning precisely inside one server and leave a consumer unable to discover it, which is MEANING without ORGANIZATION. It can organize current state into a clean hierarchy and retain nothing, which is ORGANIZATION without RETENTION. It can retain a decade of history and expose it through an unauthenticated interface, which is RETENTION without AUTHORIZATION. It can decide access perfectly while the network carrying the requests is reachable by anyone on it, which is AUTHORIZATION without SECURITY. And it can enforce a strict authorization policy over objects whose semantics nobody has fixed, which is AUTHORIZATION without MEANING. A robust and comprehensive architecture requires all six to be satisfied at once, so each concern must be assigned separately, and a term that satisfies one of them has, by that fact alone, done nothing about the other five.

1.3 Related work and its limits

Four kinds of published work define and shape this discussion, and each contributes something the others do not: feature comparisons from the protocol vendors, writing on how industrial data should be organized, reference architectures from industry analysts, and the standards themselves.

The protocol comparison literature sets OPC UA against MQTT and Sparkplug feature by feature (HiveMQ, n.d.; EMQX, n.d.; i-flow, n.d.). It is technically careful and it is the best available account of what each protocol can and cannot carry. Its limitation is structural rather than factual: a feature table presupposes that its columns can be compared like for like, so the form of the comparison asserts the substitutability that this paper disputes. FlowFuse (2026) is the notable exception in that it concludes the question has no straight answer, but it stops at the observation without deriving a structure from it.

The data organization literature distinguishes the Unified Namespace from the data-product framing and argues that each occupies a place in an industrial estate (Waehner, 2025). It is the strongest available treatment of ORGANIZATION. It leaves AUTHORIZATION largely to an unspecified platform, which is the gap this paper takes up.

The reference architecture literature supplies the industrial transformation reference model and its platform concept (LNS Research, n.d.a; LNS Research, n.d.b). Its platform layer is a container into which MEANING, RETENTION and AUTHORIZATION are placed without separate assignment. Concerns filed there are assumed to be handled rather than given an owner.

The standards literature supplies a vocabulary for AUTHORIZATION in the form of zones and conduits (ISA, n.d.a). It is a security framework rather than a data architecture, and it deliberately does not say which component in a given design satisfies the obligation it defines. That is a correct division of labour for a standard and an unfilled gap for an architect.

None of these sources breaks the problem down into the specific questions that have to be asked before the right solution can be chosen. Each covers its own ground well, but an architect can read all four and still not know which questions to ask, in what order, or how the answers select the layers of an architecture. That is the gap section 5 and section 6 exist to close.

1.4 Thesis, method and contributions

The terms on offer are not substitutable answers to one question, and an architecture cannot be selected by crowning one of them. Sorted by what each one does and scored against the six concerns, no term satisfies more than four concerns fully and only one reaches four, while retention, the keeping of the data’s history and of the record of access alike, is satisfied fully by none. To satisfy all six, the selection must be made carefully, identifying the strengths and weaknesses of each candidate. For each concern, choose the solution that fits the architecture best.

The gap is not permanent. Retention can be covered by careful product selection, since historians and audit stores exist whose job is keeping, and the boundary crossing is in practice a product’s home as well, since enforcement components exist whose job is carrying protocols across it and applying policy there. This paper is vendor neutral by design and does not evaluate or recommend products, so that selection is left with the reader. What the paper establishes is the ground the selection has to cover, and the questions that should be asked to make a proper selection. Section 7 records these limitations.

The method is analysis rather than field study, and it moves in three steps. Section 2 sorts the terms by what each one does, states the designed scope of each, and assembles the concern matrix. Section 5 turns that scoring into the specific questions an architect should ask, in the order they should be asked. Section 6 gives the failure modes that appear when the order is not kept, each with a symptom and a check that can be run at the pilot stage or against an installation that already exists. No such check is performed in this paper, and section 7 is explicit about what follows from that.

The paper makes three contributions. The conceptual contribution is the six-concern decomposition and the matrix built on it, which turn an argument about protocol preference into an argument about coverage, together with the sorting by function that keeps an organizing concept from being compared against a transport. The architectural contribution is the identification of RETENTION as the one concern nothing in the discourse satisfies in full, and therefore the ground a single-term strategy leaves out by construction. The practical contribution is the ordered decision procedure and the four failure modes of section 6.1 with their checks. The first two exist in service of the third: the decomposition and the matrix make the selection method possible, and the method is what a reader can put to work.

1.5 Assumptions: the ISA-95 estate

This paper assumes that the estate under discussion is organized on ISA-95, standardized internationally as IEC 62264. In industrial controls the assumption is safe, because the standard has been the industry model for many years and is implemented wherever a control system of any size meets a business system. It defines models and terminology for the exchange of information between business systems and manufacturing control systems, and it supplies both a level model and an equipment hierarchy of enterprise, site, area and the units beneath them (ISA, n.d.b).

The assumption does two kinds of work. The first is organizational: an enterprise topic tree is, in the ordinary case, an instance of the ISA-95 equipment hierarchy rendered as strings, so a namespace architecture does not need to invent a hierarchy, and section 2.6 scores the Unified Namespace with that inheritance in view.

The second is structural, and it is what lets the paper generalize about the network. ISA’s own account of the standard says it deals principally with the interface between levels 3 and 4, and conventional practice separates the networks at that line, as Figure 1 shows. The paper therefore assumes segmented networks with one defended crossing between the operational and enterprise domains, and SECURITY is scored against that assumed boundary: a term earns its cell by how it crosses, whether it opens an inbound path into the secure network, and whether what leaves is encrypted. The boundary this paper is about is not an invention of the OT and IT convergence discourse.

2. Sorting and Scoring the Six Terms

Six terms are surveyed here, and they are not all the same kind of thing, so the survey begins by sorting them. MQTT, Sparkplug B, OPC UA and the installed base of legacy protocols are communication layers: they carry industrial data between systems and, in the case of OPC UA, say what it means as it moves. A unidirectional gateway is a mechanism that constrains how data crosses a boundary, and the Unified Namespace is a concept for organizing data once systems are already communicating.

2.1 The terms do not all perform the same function

Each of these terms has strengths and weaknesses, and the survey evaluates every term independently against the six concerns rather than against each other. The evaluation begins with a sort, because the terms do not all do the same kind of work in a design. Some carry data or constrain its passage. Others describe that activity, specify how it ought to be structured, or arrange its results after the fact. A term scored against a function it was never built to perform is not shown to be weak, only misread, so the sorting comes first and the scoring against the concerns follows in section 2.7.

The terms fall into two groups, and those groups are the functional categories the comparison requires. A mechanism moves data or constrains how it crosses, and removing one stops something: MQTT, Sparkplug B, OPC UA, the legacy protocols and the unidirectional gateway. An organizing concept arranges what the mechanisms have already delivered, so removing one costs findability, which is the Unified Namespace.

An organizing concept operates on the output of communication rather than on communication itself, and that has a consequence the discourse rarely draws: it cannot repair a defect in its input. A namespace laid over inconsistent models is an organized view of inconsistent models, and the organization makes the inconsistency easier to reach rather than smaller. That is why this paper treats the namespace as sitting above transport rather than beside it, and why the order is a dependency and not a preference.

The sort settles some of the argument on its own. A concept should not be measured against a mechanism, and once the terms are in their kinds those comparisons fall away. What the sort cannot settle is the choice among the mechanisms themselves, which is where most practitioner disagreement sits. That choice needs the scoring, and section 2.7 supplies it.

2.2 MQTT and Sparkplug B

MQTT is a lightweight publish and subscribe transport. A publisher sends a message to a broker under a topic, subscribers to that topic receive it, and neither end holds a reference to the other. The decoupling is the point: it is efficient, it scales, and it suits intermittent links and cloud endpoints. MQTT is an answer to MOVEMENT and a very good one.

What remains is substantial. MQTT does not describe what a payload denotes, does not enforce naming consistency between publishers, and does not adjudicate what counts as trusted. Its security facilities divide across two concerns and fare differently against each. Against SECURITY the row reads full under the assumption of section 1.5: an MQTT client connects outbound to its broker, so publishing across the boundary opens no inbound port into the secure network, and TLS encrypts the traffic that leaves. Against AUTHORIZATION it stays partial: the broker can be restricted by access control list, but deciding which principal may read or write which object remains external to the protocol, and any record of what was read or written is a keeping question that belongs to RETENTION.

History requires a more careful statement than it is usually given. The payload is opaque to the protocol. A publisher may put whatever it likes in one, including a batch of timestamped samples covering the previous week, and store-and-forward clients do precisely that when a connection is restored. Sparkplug B goes further and provides for marking a metric as historical when it is one. History can arrive over MQTT, if the payload has been designed that way.

Moving history is not the same as keeping it. A payload full of past values is still MOVEMENT. RETENTION is a different job: holding data so that a consumer can ask for any past interval, corrections have a defined mechanism, retention follows a stated policy, and the record can support an audit. A broker does none of that. Its retained-message facility holds one value per topic, which is a cache rather than a record, and its persistent-session queues exist to deliver messages to a subscriber that went offline, not to keep them. That difference is why the RETENTION cell for MQTT reads empty while the same cell for OPC UA reads partial: OPC UA defines an interface for asking about the past, and MQTT defines a way of sending whatever a publisher already has. The job described here is mainly the function of a historian. Evaluating historians is not covered by this paper.

The distinction is worth labouring because “we send history over MQTT” is a sentence that conceals an unassigned concern rather than satisfying one. Something buffered that week of samples before the payload was assembled. In a majority of designs that component has no name in the architecture, no retention policy and no owner, and it is discovered only when somebody asks for a range it did not keep. The transport did exactly what it should; the buffer is what nobody owned. To satisfy the requirement fully, the movement has to include a durable store-and-forward path, one that survives interruptions and delivers into a component whose job is keeping, and that requirement spans MOVEMENT and RETENTION at once. The checklist of section 6.2 asks for that path by name.

Sparkplug B answers part of that remainder and earns a row of its own for doing so. It defines a topic namespace, a typed payload and session state management built on MQTT birth and death messages, so that a subscriber can know what a publisher is, what its metrics are, and whether it is currently alive (Eclipse Foundation, n.d.). Those are contributions to MEANING and ORGANIZATION, which MQTT makes neither of. The row also inherits, because the specification mandates MQTT as its transport rather than merely suggesting one. A Sparkplug deployment is an MQTT deployment with further constraints laid over it, so it carries MQTT’s movement coverage and MQTT’s partial authorization coverage unchanged, and the matrix records them as such. The Unified Namespace earns no such credit: it is usually built over a broker but requires no particular one, and a term inherits only what its specification requires. The contribution stops short of an information model: Sparkplug structures a payload without describing the plant that produced it, so two sites can both be perfectly Sparkplug compliant and still disagree about what a tank is. This is the strongest challenge to the claim in section 2.3 that OPC UA alone answers MEANING fully, and section 7 records it as one of the three judgements on which the paper is most exposed.

2.3 OPC UA

OPC UA is the industrial standard for stating what a datum means and not merely what it reads. It carries structured data types, descriptions, object models, secure sessions and standardized handling of events and history. It belongs to no vendor, and it is the usual means of presenting operational data in consistent structured form. It is the only row in the matrix that answers MEANING fully, and it is the reason the communication layers are capable of carrying meaning at all.

It answers MOVEMENT fully as well. The comparison literature contrasts OPC UA’s client-server sessions with MQTT’s publish and subscribe (HiveMQ, n.d.; EMQX, n.d.), a contrast that is easy to read as a scalability limit on OPC UA. Part 14 of the specification closes that reading: it defines a publish and subscribe model with a broker-based mapping onto MQTT, carrying either JSON or binary payloads (OPC Foundation, n.d.b), so a design can keep the OPC UA information model and still distribute through a broker. On Table 1 this makes movement the row’s second full cell; authorization, argued below, is its third.

The remaining two are partial in ways quickly stated. Its address space is browsable and typed, so it contributes to ORGANIZATION, and the Global Discovery Server lets a consumer find the servers that hold it across an administrative domain (OPC Foundation, n.d.a). What the specification does not supply is one arrangement of the data across servers and sites: each address space is organized by its own server, and two sites stay consistent only through modeling discipline. It defines historical access, so it contributes to RETENTION, but the definition is an access interface and not a store.

AUTHORIZATION reads full, and the machinery behind the cell is worth setting out. OPC UA authenticates both ends with X.509 certificates, signs and encrypts sessions under negotiated policies, and accepts a user identity distinct from the application identity. Per-node access attributes and role permissions let what a user may do differ from one object to the next, and Views bound what a user sees to exactly the subset of the address space intended for them (OPC Foundation, n.d.d). Set against the definition of AUTHORIZATION, deciding which principal may read or write which object and applying that decision wherever its traffic crosses, that is the whole concern, scored as section 2.1 requires on what the term was built to do.

Auditing splits across the two concerns the way section 1.2 divides them: generating a record of access is one thing, and keeping it is another. The model defines audit event types, and an audit event identifies the user and the session that initiated the action which produced it, so the decisions AUTHORIZATION makes can be observed. Auditing is a capability a server may support, and a server that supports it may satisfy the requirement either by writing entries to a log or by publishing them through the event mechanism (OPC Foundation, n.d.b). A trail that is published rather than written exists only for as long as something is subscribed to it and keeping what it receives. The record of access therefore lands where the definition of RETENTION puts it, in the keeping, and it is part of why the RETENTION cell of this row stays partial.

The SECURITY cell reads full, on two independent grounds. OPC UA secures its own sessions by design: certificate-based authentication of client and server, with signed and encrypted channels, is part of the specification (OPC Foundation, n.d.c). And it crosses the assumed boundary of section 1.5 without opening an inbound port into the secure network: reverse connect lets the server initiate the connection outbound to the client (OPC Foundation, n.d.e), and Part 14 PubSub publishes outbound through a broker (OPC Foundation, n.d.b). Encrypted traffic leaving on outbound connections, with nothing listening for inbound ones, is exactly what the assumption asks of a term.

OPC UA’s biggest weakness is its complexity. The specification has the capability to address most of the six concerns, but much of that capability is optional: role permissions, auditing, historical access and the rest are features a vendor may implement and maintain, not behaviours a conforming server must have. Two products can both be OPC UA servers while one carries the machinery this section describes and the other carries a fraction of it. That optionality returns downstream as analytics friction, inconsistent models, governance, and interoperability difficulty, and it moves the burden onto the end user, who has to evaluate individual vendors against the requirements of section 5 to ensure that what the specification permits is what the product actually does.

2.4 The legacy protocols

A survey that included only the terms under active debate would misrepresent every site that already exists. The installed base speaks OPC Classic, Modbus, DNP3, HART and ROC Plus, and it will continue to for as long as the equipment lasts. These are grouped into one row because they behave identically against the decomposition: each moves data and none carries a vendor-neutral information model. Modbus is the clean representative case, being a register-and-coil protocol in which meaning is conveyed entirely by an out-of-band convention about what register 40001 holds (Modbus Organization, n.d.).

Members of the class do reach past the class floor, and honesty requires saying so. OPC Classic adds historical and alarm and event profiles, which touch RETENTION and the structure half of MEANING. DNP3 buffers events with timestamps, which is a genuine if narrow retention contribution. Neither amounts to an information model, and the class row records the floor rather than the best member. The SECURITY cell reads none on the same basis: the class predates the threat model the boundary now faces, and protecting this traffic is done around these protocols rather than by them.

This row scores lower than any other mechanism in Table 1, and it still matters. Brownfield sites are very common, and an architecture evaluated for one has to take the installed protocols into account: meaning has to be added to this traffic because it was never carried in it. These protocols are often the reason the project exists in the first place, since many modernizations of an industrial data architecture begin because they have to be secured or standardized. That is also where an existing estate differs from a new build: brownfield concentrates its effort on recovering MEANING from this traffic and retrofitting SECURITY into zones that already exist, while greenfield can fix both at inception and concentrate on specifying the outcome instead. The worked example in section 5 develops the OPC Classic case, which is the one most often met.

2.5 The unidirectional gateway

A unidirectional gateway, often called a data diode, permits data to leave a zone and makes the reverse physically impossible rather than merely forbidden. It belongs in this survey because it is the most direct boundary mechanism in the field: nothing else makes a statement about crossings that is physically enforceable rather than configured. It is not a marginal option: a joint advisory on internet-exposed controllers lists unidirectional gateways among its recommended mitigations for data historian connections (CISA, 2026).

Its AUTHORIZATION cell reads partial. A diode settles direction absolutely, which is the part of the deciding that most designs get wrong, and it settles nothing else: it does not know which principal requested the data and cannot apply a rule that distinguishes one object from another, because there is no return channel on which a principal could ever have been authenticated. Whatever record of the crossing exists is kept downstream, which is RETENTION work. The mechanism that most fully answers the direction question is also the one that shows direction is not the whole of AUTHORIZATION.

On SECURITY the gateway reads full, and it is the extreme of the column. The other full cells rest on connection patterns that open no inbound path; a diode removes the inbound path physically, so it is disconnected from incoming attack by construction rather than by configuration, which is the maximum the concern admits. The cost of the extreme shows in the rest of its row: no identity, no per-object rule, no record, and data moving one way only. In practice the component that occupies the crossing also carries the older protocols across it, tunnelling OPC Classic, aggregating several OPC UA servers behind one interface, or publishing OPC UA data sets into MQTT, which is why the crossing tends to be a component in its own right rather than one of the protocols it carries.

Water and wastewater treatment furnishes the sharpest instance of the brownfield constraint. A federal alert issued on July 30 directed water and wastewater utilities to remove internet-exposed control equipment from public networks. Removing the exposure closes an inbound path; it does not remove the operational requirement that produced the path, and so it converts what was posed as a data question into a SECURITY question about which side opens the connection. For more information read this companion note: water data after the disconnect.

2.6 The Unified Namespace

The Unified Namespace organizes the current state of an operation into one shared hierarchy that the whole organization can address. It is a concept rather than a protocol, and it is not tied to one mechanism: most implementations realize it over an MQTT broker with Sparkplug, but an OPC UA address space serves the same role, since it also presents the operation as one browsable hierarchy. The namespace makes data findable and it reduces the combinatorial sprawl of point-to-point integrations, because consumers address agreed names standing for assets and events, whether those names are broker topics or nodes in an address space. It is an answer to ORGANIZATION. Its contribution to MOVEMENT is inherited from whatever mechanism realizes it and its hierarchy is usually inherited from ISA-95, which together are the formal statement of the category point made in section 2.1: the namespace is downstream of both the mechanisms and the model, and depends on each. Its SECURITY cell is empty on the same inheritance ground: the concept mandates no substrate, so whatever channel protection a deployment has belongs to the broker or server beneath it.

When a namespace project fails, the concept itself is rarely the cause. The more common cause is the assumption that organizing data is the same operation as governing it. A namespace fixes the shape of data. It does not on its own guarantee that two sites name the same asset identically, that schema change is controlled, that write-back has a policy, that actions are attributable, or that history is sound. Each of those is a separate design obligation, and each corresponds to a concern the concept does not address. The point is not a criticism of the namespace, which does its own job well. It is that the governance around it has to be made real by standard practice inside the company: conventions and procedures that are written down and enforced, and that the namespace itself cannot supply.

2.7 The concern matrix

Table 1 places all six terms against the six concerns, grouped by kind, with the communication layers first. A cell reads Full where the row was designed to satisfy the concern and does so on its own, Partial where it covers part of the concern but leaves a specific gap, and None where it is silent. Every cell is argued in the subsections above.

Table 1. Coverage of the six concerns.

• MQTT. Transport security and broker access control, but no per-object authorization and no attribution. Its SECURITY reads full under the assumption of section 1.5: the client connects outbound to its broker, so crossing the boundary opens no inbound port into the secure network, and TLS encrypts what leaves. The payload is opaque, so history can certainly be delivered over MQTT; retaining it is a separate concern that no broker facility addresses, and section 2.2 argues the distinction.
• Sparkplug B. Mandates MQTT as its transport, so it inherits MQTT's movement, authorization and security coverage entire. On top of that it adds a topic namespace, a typed payload and birth and death state rules. It structures payloads without modelling the plant, so its MEANING contribution stops short of an information model, and its historical metric flag delivers past values rather than retaining them, as section 2.2 sets out.
• OPC UA. The widest row in the table: movement, meaning, authorization and security all read full. Its SECURITY reads full under the assumption of section 1.5: reverse connect establishes client and server sessions with the server dialling outbound, PubSub publishes outbound through a broker, and sessions and channels are certificate-authenticated, signed and encrypted. Many of its interfaces are optional for a conforming server, so whether a given product carries them has to be checked vendor by vendor. Part 14 PubSub with its MQTT mapping settles the movement cell. Each address space is organized by its own server, so cross-site consistency is modeling discipline rather than a property of the protocol; historical access is an interface rather than a store, and the access record the specification defines but does not require to be kept is part of what holds RETENTION at partial. See section 2.3.
• Legacy and SCADA protocols. OPC Classic, Modbus, DNP3, HART and ROC Plus. The SECURITY none records the class floor: these protocols predate the threat model the boundary now faces, and protecting their traffic is done around them rather than by them. Individual members reach past the class floor, since OPC Classic adds historical and alarm profiles and DNP3 buffers events, but none carries a vendor-neutral information model.
• Unidirectional gateway. The most direct boundary mechanism surveyed, and the extreme of the SECURITY column: physically disconnected from incoming attack, it fixes the direction of flow absolutely and reduces the inbound surface to nothing. It settles nothing about identity or per-object authority, and any record of what crossed is RETENTION work downstream.
• Unified Namespace. Presupposes communication rather than providing it. Unlike Sparkplug B it mandates no particular substrate, so it inherits no transport's coverage, and its movement cell records only that it requires movement it does not supply. Its hierarchy is usually inherited from ISA-95, the assumption of section 1.5.

Three conclusions follow from the table.

Conclusion 1. No single term accomplishes all six concerns. One row satisfies four concerns fully and no row satisfies more. That row is OPC UA, which answers movement, meaning, authorization and security together. Two rows satisfy two concerns fully, two satisfy one, and one satisfies none. Even the most capable single term leaves two of the six concerns partly or wholly unassigned, and every weaker choice leaves at least four. The shortfall arises by construction rather than through an oversight that better execution would repair, so full coverage can only come from a combination of terms.

Conclusion 2. The strongest row carries a caveat. OPC UA has the widest coverage of any single term surveyed, but much of the capability behind its full cells is optional for a conforming server, as section 2.3 sets out. The cells score the specification rather than any particular product, so the coverage transfers to an installation only through due diligence: the burden is on the end user to select the vendor whose implementation actually carries it.

Conclusion 3. Even the combination falls short in one place: the RETENTION column contains no full entry. The data’s history is touched only by the historical access facilities of OPC UA, which define an interface rather than a store, and by the narrower event buffering of parts of the legacy protocol class; the record of access is touched by the audit event types of OPC UA, which the specification defines without requiring anything to keep them. So one concern cannot be fully satisfied by anything in the discourse, whatever combination is chosen. It can still be fully covered, but by a vendor’s historian rather than by anything on the list.

Conclusion 3 invites the objection that the survey was drawn too narrowly. The historian shows the objection is half right: a component whose job is keeping does exist, but it is not one of the terms the discourse compares, which is the point. A sharper objection would be that some term was deliberately left off the list to protect the claim. The opposite is true: the rows added to the survey are the terms most likely to close the RETENTION column, and that is why the unidirectional gateway, the most direct boundary mechanism in the field, appears in Table 1 at all. It is present to be tested rather than to be counted. None of them closes it. That is weak evidence of robustness rather than proof of it, and section 7 states what would count against it.

Retention is unowned by anything on the list, and the gap is left open here deliberately. Selecting a historian is its own undertaking, with enough criteria of its own to overshadow the point of this paper if they were treated properly. To keep the point direct, that evaluation is omitted: the paper marks RETENTION as the concern a product must staff, and leaves the selection with the reader.

The rest of the paper builds on this. Section 5 orders the questions a selection has to answer, and section 6 shows what neglecting that order looks like in practice and how to check for it.

3. The Leading Candidates, For and Against

The comparisons surveyed in section 1 argue over three candidates: MQTT with Sparkplug, OPC UA and the Unified Namespace. This section states the case for each and the case against it, both at full strength. Table 1 sits underneath the arguments: a case for rests on the concerns a candidate covers, and a case against rests on the concerns it leaves open, or on what covering them costs.

3.1 MQTT and Sparkplug B, for and against

The case for is that decoupling is worth more than it appears to be. A broker separates every producer from every consumer, so a new consumer costs a subscription rather than an integration, and the combinatorial sprawl that makes an estate expensive to change never forms in the first place. Sparkplug B supplies what a bare transport lacks: typed payloads, a defined topic namespace, and birth and death messages that tell a subscriber what a publisher is and whether it is currently alive. The result tolerates intermittent links, survives a dropped connection through store and forward, and reaches a distant endpoint without a translator in the middle. The comparison literature documents the resulting capability difference carefully (HiveMQ, n.d.; EMQX, n.d.).

The strongest form of the case today is not about integration cost at all. It is that this is the practical route to the cloud and analytics platforms where models are trained and run, and that demand has done more to fund industrial data work than a decade of efficiency arguments managed. A model handed raw tags without units, asset context or continuity does not fail loudly. It produces confident output that nobody downstream is placed to check. The demand this produces is specific, and in the terms used here it is a demand for three concerns at once: data arriving in context is MEANING, governed is AUTHORIZATION, and continuous enough to be worth training on is RETENTION. Wanting all three is an engineering requirement rather than a fashion, and a broker carrying a structured payload is how most estates currently attempt to meet it.

The case against does not lie in the transport, which does its job. It lies in the assumption that a transport supplies meaning. Where structure has not been agreed upstream, MQTT is an efficient means of distributing inconsistent data, and the efficiency makes the inconsistency arrive faster and in more places than it otherwise would. Sparkplug narrows the gap without closing it, since two publishers can each be entirely compliant and still disagree about what a tank is: the specification types a payload without describing the plant that filled it. Which is why the demand above is not met by the mechanism enlisted to meet it. Of the three concerns that demand names, this row satisfies two partially and the third not at all, and the one it satisfies in full, movement, is the one nobody was worried about. For more information read this companion note: AI-ready data still has to cross the boundary.

3.2 OPC UA, for and against

The case for OPC UA is that it is not principally a way of moving data but a way of stating what data means, and nothing else in the survey does that job: MEANING is the concern its row alone holds in full, and MOVEMENT and AUTHORIZATION read full beside it, which makes it the widest row in Table 1. It carries structured types, object models, descriptions, standardized events and historical access, and it belongs to no vendor, so a model expressed in it can be read by a new system without custom integration work, including systems selected years after the model was built. Removing it does not remove the requirement it satisfies. The requirement relocates downstream into naming conventions, payload contracts and custom mapping code, where the same shared understanding is rebuilt informally, at greater expense of effort and with weaker governance. FlowFuse (2026), itself one of the vendor comparisons, reaches the same conclusion from the practitioner’s side: OPC UA and MQTT do different jobs, so choosing between them has no straight answer.

The case against is more substantial than its opponents usually allow, and it is not a gap in the row but the cost of covering what the row covers. The information modelling is heavyweight: address spaces, companion specifications, certificate handling and tooling all take time to learn before they deliver anything. Most projects need a fraction of it, which is a few hundred measurements carrying units and a timestamp. The modelling effort is front-loaded, falls due before anybody has seen a result, and is often redone at the far end anyway when an analytics team remodels the data for its own purposes. The width of the row is also the specification’s rather than any product’s: much of the capability behind its full cells is optional for a conforming server, as section 2.3 sets out, so the coverage arrives only with the due diligence of establishing, vendor by vendor, that the machinery the row is credited with is present in the product. Set against that, a broker and an agreed payload convention reach a working endpoint in days rather than months. The simpler stack is also cheaper to keep running, with fewer components to patch and fewer specialist skills to hire. The analytics platforms the data is destined for consume streams rather than address spaces.

The case against holds best for one site, one team and one destination, because informally agreed conventions are genuinely cheaper than a formal model when everyone who needs them is within earshot. It weakens with every site added, since informal conventions do not travel and each new site negotiates its own. It weakens again with every year the installation runs, because the people who held the conventions in their heads move on and leave the payloads behind. Both weaknesses are contained by standard practice: conventions that are written down, enforced and kept under management of change stay consistent across sites and outlive the people who wrote them. The argument for doing without is not so much wrong as scoped, and it is usually invoked well outside that scope.

3.3 The Unified Namespace, for and against

The namespace is treated last because, by section 2.1, its case is not a case about communication at all. The case for is strong and should be conceded in full: ORGANIZATION is the concern the namespace covers, and the problem it answers is real and expensive, the sprawl of point-to-point integrations. Consumers address one agreed hierarchy instead of negotiating a separate link with every producer, which improves visibility and shortens the interval between a new question and an answer to it. As a means of organizing data intended for reuse in many places, it is the best pattern currently available.

The case against is the work the pattern hides. A namespace is only as good as the standard practices that keep it consistent: naming and modeling conventions have to be created, written down and enforced at every site that publishes into it, and then maintained under management of change for as long as the installation runs. That effort is ongoing and easy to underestimate, and skipping it yields inconsistent context, with topic naming standing in for modeling, which is MEANING misassigned. The rest of the case against comes from asking the component to do jobs it does not implement. The broker holds current state and the flow of events, not long-term history, so treating it as a historian creates gaps in replay and in what can be produced for an auditor, which is RETENTION misassigned. Treating broker security as governance omits identity, policy enforcement and audit depth, which is AUTHORIZATION misassigned. That is three of the six concerns assigned to a component that implements one.

4. Security, Governance and Regulatory Alignment

Access to operational data is now a security and governance question and no longer only an integration question. The ISA/IEC 62443 series treats the securing of industrial automation and control systems as a whole, in terms of zones, the conduits between them, policy and working practice (ISA, n.d.a). Read against the decomposition offered here, the series supplies the vocabulary for SECURITY and part of AUTHORIZATION without nominating the components that satisfy either, which is the appropriate division of labour for a standard and an open question for a design.

A design that answers the question spells the obligations out by concern. The network stays segmented and the traffic that leaves is encrypted, which is SECURITY. The requester is authenticated and the operations permitted to it are bounded by role, which is AUTHORIZATION. The decisions are logged at a granularity that would support reconstruction, and the log is kept, which is RETENTION. None of that concentrates the controls themselves: authentication, authorization and audit belong on every node that can carry them, and an estate is stronger for each node that does. What the assignment adds is accountability, a named owner for each obligation rather than a hope that some product in the path is quietly carrying it. Reachable surface contracts as a consequence, because applications no longer wire directly into control systems when a governed broker or enforcement component can stand between them. The direction of the connection, which section 1.5 made part of the scoring, is the part that repays separate treatment. For more information read this companion note: what can reach your control layer.

4.1 Requirements are not components

The sharpest objection to the claim that retention is unowned comes from regulation rather than from technology. In life sciences, retention is not left to architectural taste. The ALCOA+ expectations, that a record be attributable, legible, contemporaneous, original and accurate, and beyond those complete, consistent, enduring and available, are the working vocabulary of the auditor, and the electronic side of the same ground is the subject of an explicit rule on electronic records and signatures (eCFR, n.d.; FDA, n.d.). Retention, in that setting, is specified in considerable detail. Does regulation not fill column RETENTION?

It does not, and the reason generalizes well past one sector. A regulation states an obligation that a design must satisfy. It does not satisfy it. The rule on electronic records says what an audit trail has to do and says nothing about which component keeps one. The ALCOA+ expectations require that a record be attributable and say nothing about where attribution is captured. The matrix scores what does the work. A regulation is not that: it states what the work must achieve once something is doing it. So a design that writes a regulation into the place where a component belongs has not assigned the concern to anything. It has only given the gap a name.

Two consequences follow. The claim survives, because regulation raises the cost of leaving RETENTION unowned without reducing the chance of it: the obligation lands on a design that has no component prepared to receive it. The second consequence inverts a common expectation. A heavily regulated industry is assumed to have this settled already, but regulation makes the gap more expensive, not less likely, so the sectors with the strictest rules are the ones with the most to lose from it. An architecture of the kind described here is built to support obligations like these. Whether a particular installation actually satisfies them is a question for a qualified assessor, which is the subject of the next subsection.

4.2 Assessability, not compliance

One caution needs stating plainly rather than in a footnote. When every concern has a named owner and SECURITY has a named crossing, an assessor can be shown which component answers each question, which makes the architecture easier to assess against whichever framework the organization uses: ISA/IEC 62443, NIST 800-53 or ISO 27001. Easier to assess is all it is. Alignment is decided by qualified assessors examining a specific installation against a defined scope, and no diagram or architecture, this one included, can grant it on its own.

5. An Ordered Decision Procedure

The six concerns lead to a way of working, and almost all of it is the order. The procedure below does not supply answers. It only fixes the order in which the questions have to be asked: outcome, information, location, latency, boundary, authority, consistency, retention, and write policy. That order is the whole method. Ask a question out of order and an artifact that has already been chosen starts deciding the requirements, instead of the requirements deciding the artifact. That is how a protocol decision becomes a governance decision without anyone having decided to make it.

1. What operational outcome is the architecture accountable for, whether reliability, yield, energy, safety, regulatory reporting or time to an answer?
2. What information is required to deliver it, meaning which signals, events, context, history and documents?
3. Where does that information reside today, across control systems, historians, edge gateways and business applications?
4. What latency must it meet, and what is the defined behaviour when the link fails?
5. Which trust boundaries must it cross, and what is the standing policy on remote access?
6. Which authority decides who may cross, which approves a change, and which reviews the record afterwards?
7. How will naming, models, steering measures and schema change be kept consistent across sites?
8. What must be retained, for how long, and in which system of record?
9. What is the position on writing back into the operational domain: read-only for now, controlled writes later, and by which mechanism?

On an existing estate the recommended sequencing is to take one bounded use case and map it end to end: the operational sources, the context required, the trust boundaries crossed, and the consumer waiting at the far end. Satisfy MEANING and AUTHORIZATION before MOVEMENT and ORGANIZATION, then generalize into a pattern applied site by site. An enforcement layer established once avoids later redesign, because it makes exposure and audit behave identically everywhere rather than per integration.

A worked instance illustrates the procedure without requiring a new architecture. The common brownfield case is an OPC Classic server running over DCOM, the older Windows remote-object plumbing that Microsoft’s KB5004442 hardening has been constraining since 2023. Serving the same tag data as OPC UA brings certificate-based sessions and policy handling with it, and does so without replacing the server or touching field equipment. In the terms used here, that is a MEANING, AUTHORIZATION and SECURITY upgrade accomplished with no change of transport at all, which is exactly the kind of move the artifact-centred framing cannot describe. For more information read this companion note: your OPC Classic server did not break.

6. Failure Modes and How to Detect Them

6.1 Four failure modes

This paper has argued that projects fail because concerns are left unassigned, not because the wrong artifact was chosen. The failures should be recognizable and testable on an installation that already exists. The four below are the forms that are encountered most often.

• F1. The broker-first build. The pilot succeeds, and it succeeds quickly, with a single area feeding a single dashboard after a few weeks of work. Then the build reaches its second area, and somebody in security asks which accounts may subscribe to which topics. Every honest answer amounts to the same thing: anyone already on the network can read anything the broker carries.What you see. The design passes engineering review and stops at security review. The architecture drawing shows a broker in the middle and no component at all between the plant and the enterprise.What went unassigned. MEANING and AUTHORIZATION were left unassigned while MOVEMENT and ORGANIZATION were built.How to check. Ask the fifth and sixth questions of section 5 while the pilot is still one area and one dashboard: which trust boundaries the data crosses, and which authority decides who may cross them. If the only answer anyone can give is the access list of whatever product happens to carry the data, the failure is already forming.
• F2. The broker used as the record. Somebody asks for a month of readings from one asset, wanting to set them against a maintenance record. The data was flowing for that entire month, and none of it can be produced now.What you see. Retained messages hold the last value and nothing before it, and the analytics platform holds whatever it happened to be subscribed to at the time. The gaps in what survives line up exactly with restarts, upgrades and network events.What went unassigned. RETENTION was assigned to a component that implements MOVEMENT and ORGANIZATION.How to check. Ask the eighth question of section 5 before anything ships: what must be retained, for how long, and in which system of record. If the answer names a platform rather than a system of record, or nobody can say where a year-old value would be found, RETENTION has no owner.
• F3. Encryption mistaken for governance. A reviewer asks which accounts read a particular record last month. The transport was encrypted the whole way, every certificate is current, and nobody can answer the question.What you see. The security review passes on the strength of the transport and fails at the first request for evidence, because the logs that exist describe connections rather than access to objects.What went unassigned. The partial AUTHORIZATION contribution of the transport layer was mistaken for the whole concern.How to check. Ask the sixth question of section 5: which authority reviews the record of access afterwards. If the answer describes how the traffic is encrypted rather than how the record is traced and validated, AUTHORIZATION has stopped at the transport.
• F4. The second site starts over. The first site’s namespace is a success. The team at the second site opens by proposing a different hierarchy, because their plant has three production lines where the first had one. Both hierarchies are reasonable, and nothing on paper says which one governs.What you see. The estate ends up carrying two namespaces, two mapping layers, and the same enterprise integration written twice, and the third site is planned as though the first two had not happened.What went unassigned. MEANING and ORGANIZATION were assigned per site rather than once for the estate.How to check. Ask the seventh question of section 5 before the second site is planned: how naming and models will be kept consistent across sites. If the answer is that each site will decide for itself, or that the question will be settled later, the failure is already under way.

These four are typical scenarios, and versions of them appear across many project implementations. The way to avoid them is to follow the ordered decision procedure of section 5: the questions it asks early are exactly the ones each failure mode leaves unanswered, and taking them in order narrows the risk and reduces the gaps an implementation would otherwise carry. The limitations of this account, and the threats to its validity, are stated in section 7.

6.2 The assignment checklist

The following is an overall checklist for undertaking a new project that involves these elements. It is built on the concepts set out in this paper, principally the six concerns and the decision procedure of section 5.

1. State the outcome and its measure before any artifact is named.
2. Inventory the sources, and record for each whether it carries live state, events, history or files.
3. Define the cross-site naming and modeling convention, and where it will be phased in.
4. Draw the security zones and the conduits between them, and mark which boundaries the design crosses.
5. Ensure that authentication, authorization by role and audit logging exist on every node, and above all at the layer between the operational and enterprise domains.
6. Model the data close to the source, so that it carries its context before it is published to the enterprise layer.
7. Ensure that data which needs to be recalled or trended has a durable path that recovers from interruptions and moves it into a historian.
8. Establish a management of change process for the models and schemas: what may change, who approves it, and how consumers are notified.
9. Execute one bounded use case end to end, then turn it into a scalable pattern that expands across the architecture.

7. Limitations and Threats to Validity

The account is conceptual, not empirical. The failure modes in section 6.1 are called typical on the strength of practitioner observation, and the decomposition explains why they would occur, but neither is a measured finding. The situations that illustrate them are composites, written to be recognizable, not reports of particular projects. Nothing here was tested against a control group, and nobody counted how often the failures happen. The attached tests let a reader check each mode against one installation; finding out how common the modes are would take outcome data that is rarely published. Treat the account as a diagnostic framework, not as an established result.

The sources are practitioner, regulatory and vendor material. Roughly half are normative documents from bodies with no stake in the comparison: two ISA standards, the OPC UA specification, the Sparkplug specification, the Modbus specifications, a federal advisory and two regulatory texts. The rest come from parties with a commercial interest in one term or another: broker and integration vendors, and the analyst firm behind the industrial transformation framing. The second group is used only for technical claims about what a protocol can do, which can be checked and which sources with opposing interests agree on, never for its recommendations, which cannot be separated from the interests behind them. There is no peer-reviewed source in the list, because this discussion does not happen in journals. That is still a limitation.

The concern definitions are not perfectly neutral. Three definitional choices carry weight, and each could have been made differently. First, AUTHORIZATION is defined as a property, not as an architecture. If it demanded one central chokepoint, a distributed enforcement model would fail by definition instead of on evidence, and the paper’s conclusion would be built into its definitions. As written, it asks only that the decision apply consistently wherever the boundary is crossed, which a distributed model could in principle satisfy. Second, the record of access belongs to RETENTION, because AUTHORIZATION decides who may act now while a record is a thing kept, and the full AUTHORIZATION cell of the OPC UA row depends on that. A reader who keeps the recording inside AUTHORIZATION would read that cell partial, which would extend Conclusion 3 to a second column, widening the paper’s claim rather than threatening it. Third, AUTHORIZATION and SECURITY are kept separate: one decides who may act, the other protects how the traffic crosses. Merging them would push two different questions into one cell, and the modern rows, full on one and partial on the other, show the questions do not move together. Any decomposition sharp enough to be useful carries a point of view; these are the three places where this one shows.

The survey is not exhaustive, and it is not a random sample. It covers more terms than the discourse usually compares, and the added terms were picked deliberately as the ones most likely to prove Conclusion 3 wrong. That is the right way to stress a claim and the wrong way to estimate anything: it shows that the obvious objections fail, and it cannot show that no term outside the survey closes the RETENTION column. Some candidates were considered and left out, chiefly the digital twin and asset-model standards nearby, because their scope could not be verified to the standard the reference list is held to, not because they were judged irrelevant. A reader who knows of a term that fully satisfies RETENTION has the paper’s central claim in their hands.

The decomposition is one choice among several. Six concerns were chosen because the resulting matrix is diagnostic, not because six is the only defensible count. Splitting MEANING into syntax and semantics, or splitting attribution out of AUTHORIZATION, would give a finer matrix, and neither change would disturb Conclusions 1 and 3, which depend on where the full entries are missing, not on how many columns there are. Folding retention into movement would be different: it would dissolve Conclusion 3 rather than refine it, and anyone proposing that should argue for it rather than assume it.

The cell assignments are judgements. Table 1 records this paper’s reading of what each row was designed to do, and five cells matter more than the rest. The partial RETENTION cell of the OPC UA row is the most consequential judgement in the paper: a reader who holds that historical access and audit events together satisfy retention fully would empty Conclusion 3 entirely. The full AUTHORIZATION cell of the same row comes next, argued in section 2.3: it rests on assigning the record of access to RETENTION and on scoring a term over its own traffic, and reversing either would make it partial, adding a second column to Conclusion 3 and broadening the claim rather than damaging it. The empty RETENTION cell of the MQTT row rests entirely on the line section 2.2 draws between delivering history and keeping it; reject that line and the cell reads partial. The partial MEANING cell of the Sparkplug B row is fourth: read as full, it would overturn the claim that OPC UA is alone in that column. The full SECURITY cells of the four modern rows are fifth, and they all stand on the assumption of section 1.5: an estate without ISA-95 segmentation has no defended crossing for an outbound pattern to respect, and on such an estate those cells should be read partial, which reopens the SECURITY column and adds a second column to Conclusion 3. Conclusion 1 survives every one of these readings, though the fifth cuts its count back to three full cells. Conclusion 3 survives all but the first, which would empty it, and the fifth would broaden it. Disagreement is therefore best aimed at the RETENTION cell of the OPC UA row, and most easily reached at the RETENTION cell of the MQTT row, where the freeform payload makes the objection a short step.

The scope is the read path. The analysis covers observation, reporting and analytics. Writing back into the operational domain, and closed-loop control, raise safety questions that a data architecture does not settle and this paper does not address. Question nine of section 5 requires taking a position on write-back; nothing here says which position to take.

No product is evaluated. The paper argues that RETENTION must be staffed by a product, and it observes that the boundary crossing is in practice a component of its own. It gives no criteria for choosing either one, and the declarations below disclose the author’s interest in the question.

8. Conclusion

This paper set out to replace one question: which of these terms an architecture should standardize on. Split into the six concerns of movement, meaning, organization, retention, authorization and security, the terms on offer cover the ground unevenly and incompletely. One reaches four concerns fully and none reaches further, and even there much of the capability is optional for a conforming server, so what a given product actually carries has to be checked vendor by vendor. The lesson is not that any of the terms is deficient. Each fills a different role, and an architecture uses several of them together, each covering the part it was built for. What fails is treating the choice as picking a single winner: that is how parts of the architecture end up with no owner, and it is not a mistake better execution would have caught. It is what the framing produces when it is followed faithfully.

The replacement is selection by concern. The method requires every concern to end up with a named owner. The procedure of section 5 puts the questions in an order that lets requirements choose artifacts, instead of artifacts dictating requirements. The checklist and failure modes of section 6 make the method something a project can run and a reviewer can check. A team that works this way will still make technology choices, and often the same ones it would have made anyway.

The discipline proposed here is about assignment, not technology. Fix meaning, then govern the crossing, then move, then organize, and keep history in a component whose job that is.

Appendix A. Reference Data Flow

The following specification is vendor-neutral and protocol-aware, and it is stated in a form intended to be lifted into design documentation. Each stage carries the concern it satisfies, so that a reviewer can check the assignment rather than infer it.

Table 2. Reference data flow, with the concern satisfied at each stage.

If a reviewer cannot point to the stage that provides security, history, context or distribution, the assignment has never actually been made. It is being carried informally by the people who built the system, and it will leave when they do.

Declarations

References

• CISA (2026). Joint cybersecurity advisory AA26-231A. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-231a
• Eclipse Foundation (n.d.). The Sparkplug specification. https://sparkplug.eclipse.org/specification/
• eCFR (n.d.). Title 21, Part 11: Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
• EMQX (n.d.). A comparison of IIoT protocols: MQTT Sparkplug vs OPC UA. https://www.emqx.com/en/blog/a-comparison-of-iiot-protocols-mqtt-sparkplug-vs-opc-ua
• FDA (n.d.). Data integrity and compliance with drug CGMP: questions and answers, guidance for industry. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers-guidance-industry
• FlowFuse (2026). MQTT vs OPC UA: why this question never has a straight answer. https://flowfuse.com/blog/2026/01/opcua-vs-mqtt/
• HiveMQ (n.d.). A comparison of OPC UA and MQTT Sparkplug. https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/
• i-flow (n.d.). OPC UA vs MQTT: a comparison of the most important features. https://i-flow.io/en/ressources/opc-ua-vs-mqtt-a-comparison-of-the-most-important-features/
• ISA (n.d.a). ISA/IEC 62443 series of standards. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• ISA (n.d.b). ISA-95 standard: enterprise-control system integration. https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
• LNS Research (n.d.a). Industrial transformation (IX) reference architecture. https://blog.lnsresearch.com/industrial-transformation-reference-architecture
• LNS Research (n.d.b). What is an industrial transformation (IX) platform? https://blog.lnsresearch.com/what-is-an-industrial-transformation-ix-platform
• Modbus Organization (n.d.). Modbus specifications and implementation guides. https://www.modbus.org/modbus-specifications
• OPC Foundation (n.d.a). OPC Unified Architecture, Part 12: Discovery and global services. https://reference.opcfoundation.org/Core/Part12/v105/docs/
• OPC Foundation (n.d.b). OPC Unified Architecture, Part 14: PubSub. https://reference.opcfoundation.org/Core/Part14/v105/docs/
• OPC Foundation (n.d.c). OPC Unified Architecture, Part 2: Security model. https://reference.opcfoundation.org/Core/Part2/v105/docs/
• OPC Foundation (n.d.d). OPC Unified Architecture, Part 3: Address space model. https://reference.opcfoundation.org/Core/Part3/v105/docs/
• OPC Foundation (n.d.e). OPC Unified Architecture, Part 6: Mappings. https://reference.opcfoundation.org/Core/Part6/v105/docs/
• Waehner, K. (2025). Unified namespace vs data product in IT/OT for industrial IoT. https://www.kai-waehner.de/blog/2025/07/01/unified-namespace-vs-data-product-in-it-ot-for-industrial-iot/