Sparkplug™ provides an open and freely available specification for how Edge of Network (EoN) gateways or native MQTT enabled end devices and MQTT Applications communicate bi-directionally within an MQTT Infrastructure.
Why do we need it?
Sparkplug is a specification for MQTT enabled devices and applications to send and receive messages in a stateful way. While MQTT is stateful by nature it doesn't ensure that all data on a receiving MQTT application is current or valid. Sparkplug B provides a mechanism for ensuring that remote device or application data is current and valid.
MQTT enabled infrastructure requires that one or more MQTT Servers are present in the infrastructure. The only requirement that the Sparkplug specification places on the selection of an MQTT Server component in the architecture is it is required to be compliant with the latest MQTT V3.1.1 specification and is sized to properly manage all MQTT message traffic. One can implement the use (if required) of multiple MQTT servers for redundancy, high availability, and scalability within any given infrastructure
MQTT Edge of Network (EoN) Node
An MQTT Edge of Network (EoN) Node is any V3.1.1 compliant MQTT Client application that manages an MQTT Session and provides the physical and/or logical gateway functions required to participate in the Topic Namespace and Payload definitions. In CODESYS context the EoN node is instantiated once within a program on a PLC, usually a single EoN instance per PLC is neccesary.
The EoN node is responsible for any local protocol interface to existing legacy devices (PLCs, RTUs, Flow Computers, Sensors, etc.) and/or any local discrete I/O, and/or any logical internal process variables(PVs).
The Device/Sensor represents any physical or logical device connected to the MQTT EoN node providing any data, process variables or metrics. This can be seen as any data from the PLC (or any slave devices) on which the CODESYS EoN node resides.
MQTT Enabled Device (Sparkplug)
This represents any device, sensor, or hardware that directly connects to MQTT infrastructure using a compliant MQTT 3.1.1 connection with the payload and topic notation as outlined in the Sparkplug specification.
Note that it will be represented as an EoN node in the Sparkplug topic payload.
The SCADA/IIoT Host node is any MQTT Client application that subscribes to and publishes messages defined in this document.
In typical SCADA/IIoT infrastructure implementations, there will be only one Primary SCADA/IIoT Host Node responsible for the monitoring and control of a given group of MQTT EoN nodes. Sparkplug does support the notion of multiple critical Host applications. This does not preclude any number of additional MQTT SCADA/IIoT Nodes participating in the infrastructure that are in either a pure monitoring mode, or in the role of a hot standby should the Primary MQTT SCADA/IIoT Host go offline.
MQTT Application Node
An MQTT Application Node is any non-primary MQTT SCADA/IIoT Client application that consumes the real-time messages or any other data being published with proper permission and security
There are several levels of security and access control configured within an MQTT infrastructure. From a pure MQTT client perspective, the client does need to provide a unique Client ID, and an optional Username and Password
Although access control is not mandated in the MQTT specification for use in MQTT Server implementations, Access Control List (ACL) functionality is available for most MQTT Server implementations. The ACL of an MQTT Server implementation is used to specify which Topic Namespace any MQTT Client can subscribe to and publish on. Examples are provided on how to setup and manage MQTT Client credentials and some considerations on setting up proper ACL’s on the MQTT Servers.
The MQTT specification does not specify any TCP/IPsecurity scheme as it was envisaged that TCP/IP security would (and did) change over time.
Allthough Sparkplug B will not specify any TCP/IP security schema it will provide examples on how to secure an MQTT infrastructure using TLS security.
Sparkplug B Topic Namespace Elements
Sparkplug defines the Topic Namespace for set of MQTT messages that are used to manage connection state as well as bidirectional metric information exchange that would apply to many typical real-time SCADA/IIoT, monitoring, and data collection system use cases.
The defined message types include:
NBIRTH–Birth certificate for MQTT EoN nodes.
NDEATH–Death certificate for MQTT EoN nodes.
DBIRTH–Birth certificate for Devices.
DDEATH–Death certificate for Devices.
NDATA–Node data message.
DDATA–Device data message.
NCMD–Node command message.
DCMD –Device command message.
STATE–Critical application state message.
Using these defined messages host SCADA/IIoT applications can:
1. Discover all metadata and monitor state of any EoN/Device connected to the MQTT infrastructure.
2. Discover all metrics which include all diagnostics, properties, metadata, and current state values.
3. Issue write/command messages to any EoN/Device metric.
Development and testing
We strongly encourage every developer / tester to use the following
TCP Port: 1883
No authentication or certificate verification should be used, so beware what data you share.
See http://www.mqtt-dashboard.com/ for their current traffic.
For a good MQTT explorer search the web, there are many out there.