Six layers, each with one job

Session 5 gave every measure one name. This session moves those measures out of the plant and into your platform, safely. The path has six layers. Each layer does one job, and each can be replaced without disturbing the others.

OPC UA: named, typed and secured

OPC UA (Open Platform Communications Unified Architecture, published as IEC 62541) is the industrial standard for reading and writing machine data with meaning attached ^[1]. Instead of a register number, a client browses an address space of named objects: a Filler with a GoodCount of type integer, in units, with a timestamp and a quality flag. Many newer controllers include an OPC UA server; older ones are reached through the gateway's own drivers.

OPC UA also builds security into the protocol. Each application has its own certificate. Before any data flows, the client and server check each other's certificates, agree a security policy, and choose a mode: None, Sign (tamper-evident) or Sign and Encrypt (tamper-evident and private). Then a user or application signs in, and the server applies that user's rights ^{[1] [5]}.

MQTT and Sparkplug B: changes, not polls

Polling asks every device for every value on a timer, whether anything changed or not. MQTT turns this round: the gateway publishes a value to a broker only when it changes, and every consumer that subscribed receives it ^[3]. This is called report by exception. On a stable process the saving is large.

Plain MQTT says nothing about what a message contains. Sparkplug B, an Eclipse Foundation specification published as ISO/IEC 20237, adds three things industrial systems need ^{[4] [6]}:

• A fixed topic shape and a compact binary payload, so every consumer can decode every publisher.
• Birth certificates: when an edge node or device connects, it announces every metric with its name, type and current value.
• Death certificates: the broker publishes a pre-registered message if a node drops off, so consumers mark its data as stale instead of trusting the last value forever.

CESMII: profiles and a shared platform

CESMII, the US Smart Manufacturing Institute, publishes Smart Manufacturing Profiles: open, reusable definitions of a type of equipment and its attributes, so that two vendors' machines can present the same structure ^{[7] [8]}. A profile is the industry-wide version of the template you built in Session 5. CESMII also runs the Smart Manufacturing Innovation Platform (SMIP) for members, a shared place to model and exchange data using those profiles ^[8].

For a small or mid-size plant the practical lesson is simple: before you invent a template for a common machine, look for a published profile or an OPC UA companion specification for it, and reuse its attribute names in your vocabulary.

Where Ignition fits

Ignition is the gateway most often used for this layer in mid-size plants. It is licensed per server, not per tag or per screen, connects to controllers through its drivers or OPC UA, and with Cirrus Link's MQTT modules publishes and consumes Sparkplug B ^{[2] [9]}. Its Maker Edition is free for personal, non-commercial use, which makes it a good place to practise; a plant needs a commercial licence ^[2].

The map IT already uses

The Purdue model sorts plant systems into levels: the physical process and controllers at the bottom (Levels 0 and 1), supervisory control (Level 2), site operations (Level 3), and the business and the internet above (Levels 4 and 5). Between Level 3 and Level 4 sits the industrial DMZ, often called Level 3.5 ^{[1] [2]}. ISA/IEC 62443 turns the levels into zones, and every permitted path between zones into a conduit with defined rules ^[3].

Your platform lives in the cloud, at Levels 4 and 5. That is fine, as long as it never reaches down into the plant. The design question is only: where does each piece go, and which way does each connection start?

The pattern: outbound only

The core rule of an industrial DMZ, in the Cisco and Rockwell Automation reference designs, is that traffic from either side ends in the DMZ: nothing passes straight from the business network to the plant ^[2]. The DMZ connector pattern applies that rule to a cloud platform:

1. The gateway at Level 3 opens a connection out to a broker in the DMZ and publishes the measures the platform needs (MQTT over TLS, port 8883).
2. A small connector service in the DMZ subscribes to that broker, buffers what it receives, and sends it out to the platform over HTTPS (port 443), signed in with its own account that can only add readings (Session 7 writes that rule).
3. No connection from the office or the internet ever starts inside the plant. The platform has no address to call in on, so it cannot write to the plant even if it is compromised.

When the link goes down

A plant must never depend on the internet to make product. The gateway keeps running the machines' screens, alarms and history locally. The connector stores readings while the platform is unreachable and sends them, in order, when it comes back. Sparkplug B describes the same idea at the edge as store and forward ^[5].

The firewall rules

Write the rules as an allow-list: each line says exactly which source may reach which destination, on which port, and why. The last line denies everything else. NIST SP 800-82 recommends this default-deny approach for operational technology networks ^[1].

Notice what is missing: no rule allows anything from the internet or Level 4 into Level 3, and no rule allows the DMZ to reach Level 2 or below.

Bridging brokers: out, never in

Many plants run a broker at Level 3 for local use and a second one in the DMZ. Eclipse Mosquitto, a free open-source broker, can bridge them: the site broker connects out to the DMZ broker and forwards chosen topics in one direction only ^{[6] [7]}. The bridge's out keyword is the whole lesson: data leaves; a message published on the DMZ broker never reaches the site broker.

# site.conf — the Level 3 broker (laptop lab: plain ports on this computer only)
listener 1883 127.0.0.1
allow_anonymous true
connection to-dmz
address 127.0.0.1:1884
topic acme/# out 1

# dmz.conf — the DMZ broker
listener 1884 127.0.0.1
allow_anonymous true

What IT needs to see

An IT or OT security team reviewing a new connection asks the same questions every time: what are the parts, where do they sit, what talks to what, who can sign in, what data leaves, and what happens when something fails? ISA/IEC 62443-3-2 frames the same questions as a risk assessment over zones and conduits ^[1], and NIST SP 800-82 lists them for OT systems ^[2]. Answer them in writing, once, and keep the answers in the repository next to the code, so they change when the design changes.

The data flow inventory

Every arrow on the architecture diagram becomes one row. If an arrow has no row, it does not exist; if a row has no arrow, the diagram is wrong. Reviewers trust a design where the two match exactly.

Failure modes

AI agents: look, never touch

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data ^[3]. An MCP server offers an AI agent a list of named tools; the agent can call only those tools. That makes MCP a natural fit for the plant: you decide exactly which questions an agent may ask, and you give it no tool that writes.

• Place it in the DMZ or at Level 4, reading the historian replica and the platform database, never a controller or the Level 3 gateway directly.
• Offer named tools, not raw access. get_oee(line, shift) is safe to reason about; a tool that runs any SQL is not.
• Use read-only accounts underneath, so even a fault in the server cannot write.
• Log every call: who asked, which tool, which arguments, when.
• Assume prompt injection. Text the agent reads may carry hidden instructions. OWASP lists prompt injection and excessive agency among the top risks for AI applications; the defence is fewer, narrower tools and a person approving any change ^[4].

Tools offered by the plant MCP server (read-only)
  get_oee(line, shift)              -> availability, performance, quality, OEE
  list_downtime(line, day)          -> start, end, reason, minutes
  get_open_work_orders(area)        -> number, asset, priority, age
No tool writes, sends a command, or accepts free-form SQL.