Choosing an Industrial Edge Gateway for MQTT and Sparkplug

Industrial data architectures are moving away from repeated point-to-point polling by every consuming system and toward brokered, event-driven distribution. Field protocols such as Modbus may still be polled locally at the edge, but once the data is collected, an edge node can publish changes to an MQTT broker, and authorized applications subscribe to the information they need without opening a new direct connection to every field device. The two technologies most associated with this shift are MQTT and Sparkplug. This article looks at what they do, where the edge node actually runs, and what to expect from the industrial edge gateway it runs on as a project moves from a pilot to production. For the protocol details themselves, we point to the definitive sources rather than reinventing them.

In short: In a common MQTT and Sparkplug deployment, the industrial edge gateway is the physical computer that runs the edge-of-network software between field devices and the MQTT broker. For production use, it typically needs multiple Ethernet ports, industrial serial connectivity, protected DC power, cabinet-ready mounting, environmental tolerance, and long lifecycle support.

MQTT and Sparkplug, in Plain Terms

A quick, practical framing, with links to the authorities for the detail:

• MQTT is a lightweight publish/subscribe messaging protocol. Clients publish messages to topics on a central broker, and other clients subscribe to the topics they care about. It was created for constrained, low-bandwidth industrial telemetry and is now an
  OASIS standard.
  Because publishers and subscribers only ever talk to the broker, adding a new consumer of the data does not require touching the devices.
• Sparkplug is an open specification governed by the
  Eclipse Sparkplug Working Group.
  It defines an OT-centric MQTT topic namespace, payload, and session-state management, including birth and death messages that help subscribers tell whether edge nodes and devices are online and whether their data is current. The current published specification is Sparkplug 3.0. The familiar term Sparkplug B refers to the B payload form used in the Sparkplug topic namespace. Sparkplug was originally created by
  Cirrus Link Solutions
  and contributed to the Eclipse Foundation.

To go deeper on the protocol, those sources, along with MQTT broker vendors such as
HiveMQ
and platforms like
Ignition by Inductive Automation,
are the right references. Our focus here is narrower and complementary: where the edge node lives and what it runs on.

Why the Industry Is Moving This Way

Three practical benefits explain why MQTT with Sparkplug keeps showing up in new industrial architectures:

• Report by exception. Once data is collected, updates are normally published when values change rather than delivered on a fixed timer to every consumer. Sparkplug also uses birth, death, and state messages to keep the data context current. On large systems, this cuts network traffic and load compared with constant point-to-point polling.
• Decoupling. Publishers and subscribers do not connect to each other, only to the broker. A new dashboard, historian, or analytics tool can subscribe to existing data without any change to the field devices, which makes the architecture far easier to extend.
• A single structured source of truth. By organizing published data into one consistent, real-time hierarchy, teams can build toward a unified namespace: one place where the current state of the operation lives, instead of many point-to-point integrations. This concept, not tied to any single vendor, is a large part of why the model is gaining traction.

Sparkplug provides important building blocks for a unified namespace, including the topic structure, payload, and session state, but it does not replace the governance work of defining consistent asset names, hierarchy, ownership, and data models across an organization.

None of this replaces field protocols like Modbus, OPC UA, or BACnet. Those still connect to the physical equipment. What changes is how that data is transported and shared once it has been collected, and that collection point is the edge.

The Edge-of-Network Node: Where the Software Runs

In Sparkplug, the edge-of-network node is an MQTT client role that connects field data to the broker. It can be implemented in a gateway, a controller, or a native MQTT-enabled device. In a common gateway deployment, software such as
Ignition Edge
with the Cirrus Link MQTT Transmission module runs on an industrial computer, polls Modbus, OPC UA, or BACnet sources locally, models the data, and publishes Sparkplug messages upstream. Where the software supports it,
local history and store-and-forward
can buffer change events during a temporary network outage and republish them once connectivity returns.

The software and the computer underneath it are two separate decisions. The software, including the MQTT node, Sparkplug encoding, operating system, and any control runtime, is chosen and licensed from its vendors. The computer is chosen on its own merits. Keeping the two independent is a large part of the appeal of an open architecture.

From Pilot to Production: What Changes for the Edge Gateway

Because the software is portable, the same edge node can run on very different computers. A laptop, developer board, or mini-PC on a bench is perfectly fine for a proof of concept: connect one device, publish a few tags to a broker, and watch them arrive.

A production edge node is a different job. It runs unattended, around the clock, in a control panel, electrical room, mechanical yard, or remote skid. It is doing real work, including protocol conversion, data modeling, and local buffering, rather than simply forwarding packets. That is where the requirements change.

What Hardware Does an MQTT and Sparkplug Edge Gateway Need for Production?

A production edge gateway needs enough networking, serial, and processing capability to collect and model field data reliably and keep publishing without interruption. In practice, that means a fanless industrial computer with multiple independent Ethernet ports, industrial serial and digital I/O, protected DC power, cabinet-ready mounting, wide-temperature operation, and a long, revision-controlled lifecycle.

None of these are exotic requirements, but together they are what separates an industrial computer from an office or consumer one. A fanless design eliminates the cooling fan, and paired with solid-state storage, it removes the main moving parts that fail in conventional office PCs.

Multiple independent Ethernet ports keep the field network separate from broker and IT uplinks. A wide-range DC input fits panel power, DIN-rail mounting fits the cabinet, and a long, revision-controlled product life lets a team reuse one qualified edge profile across every site instead of stitching together mismatched boxes.

Before selecting gateway hardware, it helps to size the workload. Estimate the number of field connections, expected tag count and change rate, required outage-buffering period, local storage needs, network-separation requirements, operating environment, and expected deployment lifetime. Those factors determine the appropriate processor, memory, storage, networking, and expansion configuration.

This is the category of computer NODKA builds. Fanless
automation PCs and industrial edge gateways
such as the NP-6116 are designed for this edge role, with multiple Ethernet and serial interfaces, digital I/O on selected configurations, cabinet-ready mounting, protected DC input, and a long lifecycle, plus optional cellular connectivity on supported configurations.

The point here is the category rather than any one model: an edge node belongs on industrial computing hardware, while the runtime, broker, and licenses are selected separately.

Note on positioning: MQTT brokers, the Sparkplug specification, and edge-node software such as Ignition Edge and the Cirrus Link MQTT modules are products of their respective vendors and are licensed directly from them. NODKA supplies the industrial hardware that this software runs on, not the software itself, and is broker- and runtime-neutral.

One Platform Across the Architecture

The edge node is only one place industrial computing shows up in a publish/subscribe system. Brokers, central SCADA services, and operator stations may also need industrial-grade computing or display platforms.

Working with one industrial computing supplier across these layers, from the edge gateway to
automation PCs,
including rack-mount units for central services, to
industrial panel PCs
and touch monitors for operators, can simplify vendor qualification, documentation, lifecycle coordination, and spares planning. Each platform can still be sized and validated for its own workload.

Because the model is open and broker-neutral, the same approach carries across industries. Whether the backbone feeds a
data center monitoring system,
a water utility, a renewable-energy site, or a manufacturing line, only the field devices and protocols change.

Key Takeaways

• MQTT is a lightweight publish/subscribe protocol, while Sparkplug, currently at specification version 3.0, standardizes how MQTT is used for real-time OT data with report-by-exception and session-state awareness.
• Report by exception, publisher and subscriber decoupling, and a consistent structured data model are helping drive adoption in new industrial architectures.
• The edge-of-network node is where field data is collected, modeled, and published. In a gateway deployment, it is software running on an industrial computer, and the two are chosen independently.
• Moving from a pilot to production is where the edge gateway’s requirements appear: unattended uptime, buffering through outages, network separation, environmental tolerance, and a manageable fleet lifecycle.

Frequently Asked Questions

What is the difference between MQTT and Sparkplug?

MQTT is the underlying publish/subscribe messaging protocol and broker model. Sparkplug is an open specification, currently at version 3.0, that defines how to use MQTT for industrial OT data. It provides a standard topic namespace, defined payload, and session-state birth and death messages so subscribers know a device’s status and whether its values are current.

The widely used term “Sparkplug B” refers to the B payload form used in the Sparkplug topic namespace. MQTT provides the messaging protocol and broker model, while Sparkplug defines the industrial data conventions used with it.

What is an edge-of-network node?

It is the MQTT client role that connects field data to the broker. It can be implemented in a gateway, controller, or native MQTT-enabled device. In a gateway deployment, it connects to field equipment over native protocols such as Modbus, OPC UA, BACnet, or serial, models the data, and publishes it to the broker, typically by exception and with local buffering where supported.

What kind of computer runs an MQTT or Sparkplug edge node?

The edge-node software is portable, so it can run on many platforms. For a production deployment, the practical fit is a fanless industrial computer with multiple independent Ethernet ports for network separation, serial and digital I/O for legacy devices, wide-range DC power, DIN-rail mounting, and a long product lifecycle. A bench PC or developer board may be sufficient for a proof of concept.

Does NODKA provide the MQTT or Sparkplug software?

No. NODKA is an industrial hardware manufacturer. MQTT brokers, the Sparkplug specification, and edge-node software such as Ignition Edge with the Cirrus Link MQTT modules come from their respective vendors. NODKA supplies the industrial edge gateway that the software runs on and is broker- and runtime-neutral.

Can one gateway support both Sparkplug and OPC UA?

Often yes, depending on the edge software. A gateway may collect data from OPC UA servers, expose its own OPC UA server, publish modeled data over MQTT Sparkplug, or perform more than one of these functions at once. The exact combination is a software and licensing decision. The hardware must provide sufficient networking, memory, storage, and processing capacity.

Explore Hardware for MQTT and Sparkplug at the Edge

Build your edge on an industrial computer designed for 24/7 unattended operation, with the networking, I/O, and lifecycle a production deployment expects.

See the NP-6116 fanless automation PC →

Read: The edge gateway behind AI data center monitoring →

Guide: Connect a NODKA controller to Ignition Perspective via OPC UA →