Sparkplug B is truly unique and offers a modern, flexible, free and open way for any of your devices to exchange data using MQTT as a basis. By exploiting the scalability of MQTT, the Sparkplug B protocol provides you with a very unique and flexible architecture and let's you add or remove nodes/devices on the fly without any problem
Whether your devices are state-of-the-art or legacy, this protocol is able handle all types of devices. On top of this your data can be delivered securely and with rich metadata for added context.
Why do we need it?
Sparkplug is a specification for MQTT enabled devices and applications to send and receive messages in a stateful way. This means that each participant is fully aware of each other's connection state. While MQTT itself is stateful by nature, it does not ensure that all data on a receiving MQTT application is neither current or valid. Sparkplug B provides an mechanism on top of MQTT for ensuring that device or application data is always current and valid. Next to this, Sparkplug B can be used to act as a gateway between legacy and modern devices for seamless interaction. Lastly, Sparkplug B is capable to leverage "store & forward" to ensure that data-gaps are a thing of the past.
This is maybe the simplest part of the sparkplug infrastructure. Once you have an MQTT V3.1.1 compliant server up and running on hardware sized to manage all the expected traffic, configure the appropriate access controls for the level of risk of your application, and that's it.
MQTT communicates over a single (inbound to the server) TCP port. This means every other node in the network need only have outbound firewall rules, which on most systems are allow all by default.
If required, many Open Source MQTT Server implementations are available which offer multiple server instances for redundancy, high availability, and scalability. Sparkplug is able to take advantage of these MQTT features.
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 (a '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 Messages
Sparkplug B Messages consists of two parts;
1. a Topic Namespace,
2. a Message (a Payload and Metrics)
Each EoN node can share data on a broker via a set of pre-defined topic rules (these are the namespaces). The topics follow these pre-defined rules. When your infrastucture changes, the topics will change along. If your infrastructure grows, the topics grow accordingly, if your infrastructure shrinks, your topics shrink accordingly.
Each message consists of a single Topic in the form of a hierarchy and a payload which consists of one or several metrics and it's metadata.
The Node decides what payload information will sent the broker (and thus shared to all other clients in the network which are subscribed) and whether this information is refreshed in a timely fashion or on change of the data (The decision of what information is shared is ultimatly determined by the goal of the software)
So, it is up to the EoN node device how much information and what kind of meta data of the information is shared.
Sparkplug defines the Topic Namespace for a 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.
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.
For an in depth overview of all namespaces see
SparkPlug Specification Chapter 6. Sparkplug™ MQTT Topic Namespace
Message Payload & Metrics Component
As specified the second part of the message consists of a Payload and Metrics
A Sparkplug B payload is the top-level component that is encoded and used in an MQTT message. It contains some basic information such as a timestamp and a sequence number as well as an array of metrics which contain key/value pairs of data.
For a in depth overview of all Payload components & metrics see
SparkPlug Specification Chapter 15. Sparkplug™ B v1.0 Payload Components
You are free to use any MQTT Library implementation you wish.
However in this project we will use the following Library; https://store.codesys.com/iiot-libraries-sl.html Note: Without a license, the software runs for 30 minutes in demo mode.