Broker v10.5 - SparkplugB 3.0 Compliant
I ran the Sparkplug Compliant test against our 10.5 broker and the result is, it is complaint. The 10.5 broker was running as a hyper-v image.
I had to make the changes as detailed at
in order for the retain test to pass. I had to increase the VM's memory to 8192 MB in order to make the aforementioned MQTT retain changes.Setting up the compatibility test is detailed here:
and
The test result:
Comments
-
Thanks for sharing :)
1 -
is it here that you increase the memory to 8192 MB ?
solace(configure/message-vpn/mqtt/retain/cache)# max-memory <megabytes>
0 -
When I tried to use the max-memory command initially I got an error.
I had to increase the memory in the hyper-v image to 8192:
Then I could run: max-memory 300
1 -
Reposting this from Thomas's posting in our Slack channel:
Introduction to MQTT and Sparkplug for IIoT
Sparkplug is a specification designed to standardize interoperability in the Industrial Internet of Things (IIoT) arena, particularly in relation to the MQTT protocol. MQTT has become the de facto standard for messaging in IoT applications but was designed to be as open as possible, lacking restrictions on topic names and message structures. Sparkplug was introduced by Cirrus Link in 2016 to address some of these perceived shortcomings.
Key Features of Sparkplug- Topic Namespace Structure: Sparkplug provides a standardized topic namespace structure, which looks like this:
namespace/group_id/message_type/edge_node_id/[device_id]
. - State Management: It introduces a mechanism for state management that uses “birth messages” and the existing “last will and testament” message in MQTT.
- Payload Structure: Sparkplug uses Google protocol buffers for its payload structure.
Implications
- Sparkplug doesn’t change MQTT but defines certain aspects that were left open for the end user to decide.
- It provides clear guidelines for designing topic namespaces, packaging message payloads, and maintaining and communicating client state, which aids in system interoperability.
Components
- MQTT Broker (Server): Standard MQTT broker running standard compliant MQTT v3.1.1 (or greater, current version is 5.0).
- Management Application or Applications: SCADA/IIoT Host Node receives data from Sparkplug nodes and sends control information to them.
- MQTT Edge of Network Nodes (MQTT EON): These are gateway devices or MQTT-enabled devices that support Sparkplug.
Detailed Aspects of Sparkplug
Topic Namespace Structure
Sparkplug introduces a standardized topic namespace structure to MQTT. The structure is as follows:namespace/group_id/message_type/edge_node_id/[device_id]
This allows for a more organized way to manage topics and ensures that all devices and applications are on the same page when it comes to topic naming.
State Management
One of the unique features of Sparkplug is its state management mechanism. It introduces “birth messages” in addition to MQTT’s “last will and testament” messages. This allows for better tracking of client states, which is crucial for industrial applications.
Payload Structure
Sparkplug employs Google protocol buffers for its payload structure. This ensures a more efficient and structured way to package data, which is essential for IIoT systems that may deal with large volumes of data.
Message Types
Sparkplug introduces specific message types like:- NBIRTH: Birth certificate for MQTT Edge of Network (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.
These message types allow for more granular control and monitoring of devices and nodes in an IIoT system.
0 - Topic Namespace Structure: Sparkplug provides a standardized topic namespace structure, which looks like this:
-
Thanks Bryce. Yes we are considering posting the results there.
0