Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Sparkplug
MQTT was originally designed as a message transport for real-time SCADA systems. The MQTT message transport specification does not specify the Topic Namespace to use nor does it define the Payload representation of the data being published and/or subscribed to. In addition to this, since the original use case for MQTT was targeting real-time SCADA, there are mechanisms defined to provide the state of an MQTT session such that SCADA/Control HMI application can monitor the current state of any MQTT device in the infrastructure. As with the Topic Namespace and Payload the way state information is implemented and managed within the MQTT infrastructure is not defined. All of this was intentional within the original specification to provide maximum flexibility across any solution sector that might choose to use MQTT infrastructures.
But at some point, for MQTT based solutions to be interoperable within a given market sector, the Topic Namespace, Payload representation and session state must be defined. The intent and purpose of the Sparkplug specification is to define an MQTT Topic Namespace, payload, and session state management that can be applied generically to the overall IIoT market sector, but specifically meets the requirements of real-time SCADA/Control HMI solutions. Meeting the operational requirements for these systems will enable MQTT based infrastructures to provide more valuable real-time information to Line of Business and MES solution requirements as well.
The purpose of the Sparkplug specification is to remain true to the original notion of keeping the Topic Namespace and message sizes to a minimum while still making the overall message transactions and session state management between MQTT devices and MQTT SCADA/IIoT applications simple, efficient and easy to understand and implement.
Consider that the “Internet of People” exploded to where it is today due in large part to two open source technologies:
- HTTP as an application protocol.
- HTML as the definition of the data payload within the protocol.
Therefore with these two open source technologies at hand, developers around the world were able to create the solutions users are enjoying today.
For the Industrial Internet of Things (IIoT) to truly scale at the rate the Internet of People did the very same notion is true. MQTT is already one of the most broadly adopted message transport technologies in the world today. But to scale and be interoperable within the Industrial sector, an “HTML for Industrial Data” is required. That is Sparkplug.
Project Scope
The Sparkplug Specification Project defines and maintains the Sparkplug specification and related TCK descriptions.
Specification Scope
Sparkplug defines how Edge of Network (EoN) gateways or native MQTT enabled end devices and MQTT Applications communicate bi-directionally within an MQTT infrastructure. The specification details the structure and implementation requirements for Sparkplug compliant MQTT Client implementations on both EoN gateways/devices (edge profile) and MQTT Applications (host profile).
It is recognized that MQTT is used across a wide spectrum of application solution use cases, and an almost indefinable variation of network topologies. To that end the Sparkplug specification strives to accomplish the three goals in the following description.
Define an MQTT Topic Namespace
The intent of the Sparkplug specification is to define and document a Topic Namespace that is well thought out and optimized for the SCADA/IIoT solution sector.
Define an MQTT Payload
The intent of the Sparkplug specification is to strive to define payload encoding architectures that remain true to the original, lightweight, bandwidth efficient, low latency features of MQTT while adding modern encoding schemes targeting the SCADA/IIoT solution sector.
Define MQTT State Management
One of the unique aspects of MQTT is that it was originally designed for real time SCADA systems to help reduce data latency over bandwidth limited and often unreliable network infrastructure. In many implementations though, the reason and full benefit of this “Continuous Session Awareness” is not well understood, or not even implemented. Using Report by Exception (RBE) techniques have been shown to reduce network bandwidth consumption by 80% to 95%, but that only works if the full extent of the State Management is implemented.
In order for MQTT to be seriously considered within the SCADA/IIoT market, end users have to be confident that the “state” of an end device is known at all times. The device is either connected to the MQTT Server and can and will publish any data that changes and can accept any command that is sent to it, or it is disconnected from the MQTT Server in which case applications can set any associated data to a “stale” state. When properly implemented the LWT mechanism within MQTT does exactly this.
TCK Scope
The TCK scope is to define the “edge profile” and “host profile” Sparkplug TCK implementations.
In order to be adopted broadly across industry, the Sparkplug Specification needs to be open source and available to anyone that wants to implement it. But to remain viable over time the specification also needs the governance and process that the Eclipse Foundation can uniquely provide.
The initial Sparkplug specification document has been contributed by Cirrus Link Solutions.
None known.
The first 3 months of the project will entail converting the existing Sparkplug specification from an informal "this is how Sparkplug works" document to a more rigorous specification document much like the resulting OASIS MQTT 3.1.1 specification that exists today. The project should indentify any ommissions or assumptions that were made in the current specification and provided added context where required. A backlog of comments on ommissions/errors in the current specification document already exists.
A backlog of feature request already exists. Once a V1.0 of the specificaton exists, then this project will set a 3 month cadance on reviewing feature requests and get agree on the priority of each one. Given the community of solution providers, OEMs, and end customers, the community will grow rapidly around this project.