Unified Namespace for Pilbara Iron Ore — A Sparkplug B Reference Architecture

A concrete reference architecture for iron ore processing plants in the Pilbara. Edge brokers, MQTT, ISA-95 layered model, and a 12–18 week migration path from brownfield Rockwell + OSIsoft PI sites.

Introduction

Iron ore processing plants in the Pilbara generate thousands of real-time data points — conveyor speeds, motor temperatures, pump pressures, SAG mill loadings — that sit siloed in PLC registers and historian archives. The traditional SCADA point-to-point model served the plant for decades. It's not serving it now.

A Unified Namespace (UNS) — a single, hierarchical MQTT topic tree that all systems publish to and consume from — is the architectural foundation that makes OT data useful across MES, analytics, ML, and external integration. Without it, every new system requires a bespoke PLC driver, a custom historian connector, and a team of integrators who know the plant's naming conventions.

This article lays out a concrete, implementable reference architecture for Pilbara iron ore plants running Allen-Bradley PLCs (ControlLogix / CompactLogix) and OSIsoft PI, using Sparkplug B as the payload specification over MQTT. It covers the ISA-95 layered model, edge broker architecture, topic namespace design, brownfield migration, and a phased rollout plan with realistic timelines.

The ISA-95 Layered Model, Applied to Iron Ore

ISA-95 (IEC 62264) defines five levels from field equipment to business planning. For Pilbara iron ore, the relevant layers are:

L0 — Field: Sensors, actuators, VFDs, field instrumentation (pressure, temperature, level, vibration).
L1 — Basic Control: PLCs (Allen-Bradley ControlLogix), safety systems (PlantPAx), variable frequency drives.
L2 — Area Supervisory: SCADA/HMI (Ignition, FactoryTalk View SE), zone controllers, local alarm management.
L3 — Site Operations: MES (OSIsoft PI, Aspentech IP.21), production scheduling, shift handover, batch management.
L4 — Business Planning: ERP integration, logistics, sales订单 — the domain of cloud/enterprise systems.

The UNS lives between L1 and L3, bridging PLCs (L1/L2) and the operational technology (L3) and IT systems that consume it. It's the horizontal data backbone.

Why Sparkplug B over MQTT

MQTT (MQ Telemetry Transport) is the established industrial IoT standard — lightweight, publish/subscribe, TCP-based, tolerant of intermittent connectivity. Every major cloud (AWS IoT, Azure IoT Hub, Google Cloud IoT) speaks MQTT natively.

Sparkplug B is an open specification (Eclipse Sparkplug) that defines a standardized MQTT topic namespace and payload encoding for industrial devices. It was designed specifically to solve the problem Sparkplug solves: getting industrial OT data into modern cloud/analytics platforms without requiring custom integration work for every new system.

Key advantages for Pilbara:

Topic namespace standardisation: Every device follows the same pattern — Group/MessageType/EdgeNode/Device — eliminating the "what does Tag427 mean" problem.
Birth and Death certificates: Devices announce their presence (birth) and disappearance (death) explicitly. Operators can detect PLC comms loss in seconds, not minutes.
Opt-in metadata: Each metric carries a timestamp, quality, and optional properties (engineering units, alarm boundaries).
Vendor neutral: Cirrus Link (for Ignition), HiveMQ, EMQX, AWS IoT, Azure IoT Hub — all support Sparkplug B natively.
Edge-optimised: Compact binary encoding (Protobuf) means sub-1KB payloads for even complex process data, critical for satellite-linked Pilbara sites.

Edge Broker Architecture

The reference architecture uses a hub-and-spoke edge model:

Primary edge broker: Runs on a ruggedised industrial server (Supermicro or Dell Edge) co-located with the plant. EMQX or HiveMQ Edge as the MQTT broker. Handles local pub/sub for SCADA, PLC drivers, and any edge analytics.
SCADA/HMI integration: Ignition (Inductive Automation) with the Cirrus Link Sparkplug B module handles the PLC side — reading/writing ControlLogix tags over EtherNet/IP and republishing as Sparkplug B metrics to the edge broker.
Cloud bridge: The edge broker maintains a persistent TLS tunnel to a cloud MQTT endpoint (EMQX Cloud or AWS IoT Core). Bi-directional — analytics and commands flow both ways.
PI historian bridge: OSIsoft Connectors for MQTT (or the new PI Web API client writing to the broker) allows PI to consume and archive Sparkplug B metrics without replacing the existing historian infrastructure.

Figure 1: ISA-95 layered model with Unified Namespace MQTT bus. Edge broker co-locates with SCADA; cloud bridge provides bi-directional connectivity.

ISA-95 Topic Namespace Design

Sparkplug B defines a four-level topic structure: {namespace}/{group_id}/{message_type}/{edge_node_id}[/{device_id}]

For Pilbara iron ore, the namespace should be spBv1.0 (the standard Sparkplug B payload version). The group_id maps to the physical site or process area. Topic examples:

# Structure: spBv1.0 / [Site-Area] / [MessageType] / [EdgeNode] / [Device]

# Conveyor lines — process area
spBv1.0/PilbaraSite/DDATA/CL1-EdgeNode/Conveyor01
spBv1.0/PilbaraSite/DDATA/CL1-EdgeNode/Conveyor02
spBv1.0/PilbaraSite/DDATA/CL2-EdgeNode/SAGMill01

# Pump stations
spBv1.0/PilbaraSite/DDATA/PS-EdgeNode/PumpStationA/Cell01
spBv1.0/PilbaraSite/DDATA/PS-EdgeNode/PumpStationA/Cell02

# NDATA — non-data (commands, acknowledgements)
spBv1.0/PilbaraSite/NDATA/SCADA-EdgeNode

# Birth certificate — sent when edge node comes online
spBv1.0/PilbaraSite/DBIRTH/CL1-EdgeNode

# Death certificate — sent when edge node disconnects
spBv1.0/PilbaraSite/DDEATH/CL1-EdgeNode

The Message Types in Sparkplug B are:

NBIRTH / NDEATH — Edge node online/offline announcement
DBIRTH / DDEATH — Device online/offline (e.g., a PLC comms link restored)
NDATA / DDATA — Metric data (non-birth / data)
NCMD / DCMD — Command to write a value (e.g., setpoint change)
STATE — Session state (used by primary/secondary broker failover)

Sparkplug B Payload Structure

Sparkplug B uses Google Protocol Buffers (Protobuf) for compact binary encoding. Here's the JSON-equivalent structure of a DDATA message for a conveyor motor:

{
  "timestamp": 1750708800000,
  "metrics": [
    {
      "name": "MotorSpeed",
      "alias": 1,
      "timestamp": 1750708799000,
      "dataType": "Float",
      "value": 1450.4,
      "properties": {
        "engUnit": { "type": "String", "value": "RPM" },
        "quality": { "type": "UInt8", "value": 192 }
      }
    },
    {
      "name": "BearingTemp",
      "alias": 2,
      "timestamp": 1750708799000,
      "dataType": "Float",
      "value": 67.3,
      "properties": {
        "engUnit": { "type": "String", "value": "°C" },
        "alarmLo": { "type": "Float", "value": 55.0 },
        "alarmHi": { "type": "Float", "value": 85.0 }
      }
    },
    {
      "name": "Online",
      "alias": 3,
      "dataType": "Boolean",
      "value": true
    }
  ],
  "seq": 1042
}

The alias field enables sparse metric updates (only send changed values) — critical for high-frequency data from conveyor belts and pump stations where polling at 1-second intervals generates large message volumes.

Brownfield Migration: Rockwell + PI

Most Pilbara iron ore sites run Allen-Bradley ControlLogix with EtherNet/IP, OSIsoft PI as historian, and Rockwell FactoryTalk SE or Inductive Automation Ignition as SCADA. Here's the migration path:

Step 1 — Install Ignition Edge + Cirrus Link (Weeks 1–3)

Install Inductive Automation Ignition (Edge licensing, ~$2,500/year) on the existing SCADA server or a dedicated industrial PC. Add the Cirrus Link Sparkplug B module. Ignition natively speaks EtherNet/IP to ControlLogix — no PLC program changes required. Tag mapping happens through the Ignition designer.

Step 2 — Define Topic Namespace (Week 2–3)

Work with the plant operations team to map the existing tag naming conventions to the ISA-95 topic structure. This is the most important and most underestimated step. A poor namespace is painful to fix after data consumers are built.

Tag mapping matters: PI tags have their own naming conventions (e.g., PIL_C1_MOT01_SPEED). Map these to Sparkplug B metric names consistently. Consider a tagging standard: [Site]-[Area]-[Equipment]-[Signal] — e.g., PIL-CL1-MOT01-Speed.

Step 3 — Deploy Edge Broker (Week 4–5)

Install EMQX Edge on a hardened industrial server. Define the topic tree. Configure Ignition to publish to the local broker over MQTT. Validate with a 30-minute soak test — all expected metrics present, no duplicate topic registration, broker restart recovery in under 60 seconds.

Step 4 — Connect PI (Weeks 6–8)

Configure the OSIsoft PI Connector for MQTT (requires PI 2020 or later) or use the PI Web API with a small Node.js or Python bridge to read from the MQTT broker and write to PI. Existing PI tags and analyses remain intact — the connector only adds a new data pathway.

Step 5 — Cloud Bridge (Weeks 8–10)

Configure the edge broker's cloud bridge (EMQX Cloud native, or MQTT bridge via AWS IoT Core). Use TLS mutual authentication. Validate that metrics arrive in the cloud broker within 2 seconds of the PLC value changing.

Step 6 — Consumer Applications (Weeks 10–16)

Build on top of the UNS, not against it. Connect analytics, dashboards, and operational applications to the cloud MQTT broker. The namespace is now the contract — application teams consume topics, they don't query databases.

FIFO Maintenance Windows

Pilbara iron ore operates on shutdown-based maintenance. Every shutdown is a rare and valuable window. Plan integration work in these windows:

1–2 week shutdowns: PLC tag mapping, Ignition configuration, edge broker installation. No OT network changes required.
2–4 week major shutdowns: Network infrastructure changes, cloud bridge configuration, PI connector commissioning. Full shutdown required for network segment changes.

Never plan a change that requires a system restart outside a shutdown window. If the edge broker goes down during a 3am crusher alarm, the operations team needs to be able to restart it without waiting for an integrator.

Vendor Stack Recommendations

All recommendations are real, commercially available products with established Pilbara/iron ore deployments:

Edge MQTT Broker: EMQX Edge (open-core, commercial support available) or HiveMQ Edge. EMQX preferred for native Sparkplug B with the commercial extension.
SCADA / PLC Driver: Inductive Automation Ignition with Cirrus Link Sparkplug B module. FactoryTalk SE works but lacks native MQTT/Sparkplug.
Sparkplug B Library: Cirrus Link — their Sparkplug B libraries for Ignition, Node-RED, and custom applications are the de-facto standard in Rockwell-heavy environments.
Historian: OSIsoft PI (now AVEVA PI) with the MQTT Connector. PI is entrenched in Pilbara — don't replace it, extend it.
Cloud Broker: EMQX Cloud (AWS/Azure/GCP) for managed MQTT with native Sparkplug B support. AWS IoT Core is a viable fallback.
Tagging / Asset Model: PTC ThingWorx or AVEVA Asset Framework for ISA-95-aligned asset hierarchy management.

Conclusion

A Unified Namespace built on Sparkplug B over MQTT transforms iron ore processing data from siloed PLC registers into a live, discoverable, vendor-neutral data layer. The investment is front-loaded: ISA-95 namespace design and tag mapping takes 4–6 weeks and requires genuine collaboration between OT engineers, process engineers, and IT/data teams. That's the hard part. Everything downstream — PI integration, cloud analytics, ML models, remote dashboards — becomes additive, not bespoke.

The 12–18 week migration path (starting with Ignition + Cirrus Link, deploying edge broker, then PI connector, then cloud bridge) is designed to deliver working data within the first shutdown window, with each phase adding a new capability layer. It's not a big-bang; it's a staged rollout that generates value progressively.

If your site is running Rockwell PLCs and OSIsoft PI and you're not yet on MQTT, the UNS is not optional — it's the only path to the OT data quality that modern mining operations demand.