Build the topology you need
NATS servers snap together like building blocks. Connect autonomous plants, regional clusters and cloud in the topology your operations need.
Keep MQTT. Add NATS as your enterprise backbone.
Use the right protocol at each layer. MQTT gets data out of the plant. NATS takes it everywhere else, and lets applications ask questions of it, not just listen.
- MQTT 3.1.1
- listener built into the NATS server, Sparkplug Aware since 2.11
- 0
- inbound ports at the site: the leaf link connects outbound
- 1
- system for telemetry, request-reply, durable streams and shared state
$ nats sub "spBv1.0.>" Example: 3 msgs
[#1]Received on "spBv1.0.plant-dtw.DDATA.edge-01.press-07"{"metrics":[{"name":"Spindle/Vibration","value":0.82}],"seq":41}
[#2]Received on "spBv1.0.plant-dtw.DDATA.edge-01.oven-02"{"metrics":[{"name":"Zone3/Temp","value":182.4}],"seq":42}
[#3]Received on "spBv1.0.plant-dtw.NDATA.edge-01"{"metrics":[{"name":"Line3/OEE","value":0.847}],"seq":43}
site cluster plant-dtwMQTT :8883 · Sparkplug BWAN down · buffering
Trusted by leading enterprise companies
MQTT gets data out of the plant. Then what?
MQTT is the right protocol at the edge. It is small, it runs on constrained devices, and your SCADA, gateways and newer PLCs already speak it. Above Level 1, though, a broker only moves data up. Everything downstream can only listen.
So the enterprise side grows around the gap: a streaming platform for retention, a database for current state, an API for anything that needs an answer, and another broker to federate per site. Four systems for one data point, in every plant.
-
Applications can only listen
A broker moves telemetry up. A dashboard, an MES or a model has no way to ask a line a question, so that path is built separately, with its own auth.
-
Every site is another broker to federate
Connecting plants, regions and cloud means bridging brokers or adding a second platform in the middle. Either way you get a hub with spokes.
-
Retained messages are not a system of record
A broker keeps the last value per topic. Replay, independent consumers and shared state mean another cluster beside it, in every plant.
MQTT at the site, one NATS backbone above it
SCADA, gateways and MQTT-native devices publish over MQTT and Sparkplug B to a NATS cluster at the site. PLCs that only speak Modbus or OPC UA get a small NATS client beside them. The site cluster keeps working through a WAN outage and holds one outbound link to the enterprise, where MES, ERP and analytics subscribe and use request-reply on the same subjects.
1
SCADA publishes over MQTT
SCADA, edge gateways and MQTT-native devices publish MQTT or Sparkplug B to the MQTT 3.1.1 listener built into nats-server. Nothing at Level 1 changes, and there is no separate broker at the site.
2
A NATS cluster at every site
With the WAN down, SCADA keeps publishing, the HMI and local applications keep subscribing and asking, and JetStream buffers what the enterprise missed until the link returns.
3
Request-reply on the same subjects
The hub serves the same subjects to MES, ERP and analytics across every site. Request-reply rides beside the telemetry, so the MES can ask a line a question and get an answer.
4
Outbound from the site, no inbound ports
One outbound leaf link from the site to the hub. OT keeps its segmentation, with no inbound firewall rules or VPN tunnels.
A backbone that does more with your data
Events, queries and services
Publish updates, distribute work and use request-reply on one data plane. Applications consume events and ask for answers.
Durable streams and state
JetStream adds retention, replay and independent consumers. Key-value and object stores extend the same platform to shared state and files.
Open source. No vendor lock-in.
Clustering for high availability is built into open-source NATS. Run it yourself, on infrastructure you choose, or bring in Synadia support.
Connecting more than one site?
The edge guide covers the topologies a multi-site namespace needs: leaf node sizing, stream sourcing and account layout.
Verrus Flexible data centers
“NATS for us forms the backbone of our unified namespace. And it's essentially the data plane for our data centers into our cloud.”
Christopher Coco Principal Software Engineer, Verrus
Where MQTT and NATS work together
The same pattern, in the industries where SCADA and MQTT already carry the site.
Manufacturing & Industrial
Every plant autonomous, one UNS above them
A NATS cluster per plant keeps lines and SCADA talking through a WAN outage. The MES gets request-reply and last-known state lives in KV.
Manufacturing & Industrial Automotive & MobilityThe plant and the vehicle on one namespace
The plant that builds the vehicle and the vehicle on the road run the same leaf node pattern, on the same namespace.
Automotive & Mobility RetailStores that keep trading offline
Point of sale, sensors and back-office systems keep working on the store network and sync to the enterprise when the link returns.
RetailContinue exploring
Customer storyCalix: 200 million events per minute on NATSThe communication layer for millions of home routers and access devices, moving device telemetry into the cloud in real time.
Blog seriesConnecting distributed SCADA with NATS.ioPart two maps leaf nodes, JetStream and decentralized auth onto ISA-95 Levels 1–4.
Blog seriesConnecting distributed SCADA with NATS.ioPart one: how SCADA Levels 0–4 map to modern industrial systems, and where NATS fits.
BlogDo you really need MQTT and Kafka for industrial IoT?What the MQTT-to-Kafka bridge costs, and how one system can do both jobs.
BlogMQTT vs NATS for fleet managementHub-and-spoke against a distributed mesh, with the trade-offs at each layer.docs.nats.ioDocsMQTT in NATSEnable the MQTT listener, map topics to subjects, and connect a client.
BlogWhat a unified namespace actually requiresFive capabilities any UNS needs, and why an MQTT broker covers two of them.Bring us your edge use case
Bring your site count, protocols and uptime targets. We will sketch the site cluster, the leaf links and the account layout with you, and the engineers on the call are the ones who build nats-server.
NATS and MQTT, side by side
The questions plant and platform teams ask once they have decided to keep MQTT and are working out what sits above it.
What is the difference between NATS and MQTT?
MQTT is a protocol for getting data off devices: a lightweight publish-subscribe wire format with quality-of-service levels, retained messages and last-will, designed for constrained hardware and unreliable links. It says nothing about what happens once the data reaches a broker.
NATS is a messaging system. It has publish-subscribe too, but also request-reply, queue groups for distributing work, JetStream for durable streams, key-value and object stores for shared state, and clustering, leaf nodes and gateways for building a topology across sites and clouds. And nats-server speaks MQTT 3.1.1 natively, so you don't choose between them: MQTT at the edge, NATS everywhere else.
Do we have to replace our MQTT broker?
No. The simplest path is to point your SCADA platform's MQTT publisher and your gateways at the MQTT listener built into NATS, so the site cluster is the broker. If you already have a broker in place and want to keep it, forward selected data through an MQTT-to-NATS adapter instead. The adapter owns topic mapping, optional payload translation, and delivery handling such as retries and buffering, so decide up front who deploys, monitors and supports it.
How do SCADA, PLCs and the MES connect to NATS?
Three ways, and you choose the one that fits the site. Most SCADA platforms, Ignition among them, and most edge gateways can publish MQTT or Sparkplug B straight to the MQTT 3.1.1 listener in NATS. If a broker is already in place, keep it and forward selected data through an MQTT-to-NATS adapter. Anything you write yourself uses a NATS client, and there are libraries for 45+ languages: a small client beside a Modbus, OPC UA or DNP3 PLC publishes its readings onto named subjects, and the MES and historian use the same libraries for request-reply and JetStream.
Whichever path you choose, you get the same NATS backbone above the site.
Where does NATS sit in the SCADA levels?
Between Level 1 and Level 2, as a data fabric. PLCs and the real-time control loops stay at Level 1, close to the process. The site NATS cluster gates them: it publishes their state and measurements as named subjects, carries commands back down under rate limits and permit lists, and lets the supervisory, MES and planning systems above subscribe and ask without touching the PLC network. The distributed SCADA series walks through the model level by level.
Does NATS support Sparkplug B?
Yes. NATS 2.11 and later includes Sparkplug Aware broker behavior: NBIRTH and DBIRTH messages are stored as they pass through and made available on the $sparkplug/certificates topics the specification requires. Native NATS consumers see Sparkplug topics as subjects and must account for the topic mapping, and decode or normalize the Sparkplug payloads.
What happens at the site when the WAN drops?
Nothing the plant notices. The site cluster is a full NATS system: SCADA keeps publishing, the HMI and local applications keep subscribing and calling each other, and JetStream keeps writing. When the link returns, the site sources what it buffered into the enterprise cluster, in order and from the last sequence the hub received.
Do we need to open inbound ports at the plant?
No. The site cluster connects out to the enterprise hub as a leaf node, on port 7422 by default. There are no inbound firewall rules and no VPN tunnels. Accounts decide which subjects cross from the site to the enterprise, so raw machine data can stay local while KPIs and alarms go up.
