Last Updated: January 29, 2020
An open source software specification that provides MQTT clients the framework to seamlessly integrate data from their applications, sensors, devices, and gateways within the MQTT Infrastructure.
For the time being, the Sparkplug specification is available as a PDF. It will migrate to a GIT repository in the coming months as its source is converted to an open document format.
No. Sparkplug is simply a specification that defines how to best use MQTT in real-time, mission critical industrial infrastructures. Sparkplug addresses the following components within an MQTT infrastructure: #1 - Sparkplug defines an OT centric Topic Namespace #2 - Sparkplug defines an OT centric Payload definition optimized for industrial process variables. #3 - Sparkplug defines MQTT Session State management required by real-time OT SCADA systems.
MQTT has emerged as a dominant messaging transport across both the IT and OT market sectors. By design, the MQTT specification does not dictate a Topic Namespace nor does it dictate any payload encoding. But as IIoT is adopted by device OEM’s in the industrial sector, having different Topic Namespace and payload encoding inhibits interoperability for the end customer.
The Internet of People exploded because of two open technologies: First there was HTTP which defined a data exchange protocol. Then there was HTML that was used to “define” the data sent by HTTP. Together, HTTP and HTML, these technologies provided the basis for the explosion of the Internet of People.
For the IIoT to obtain the same adoption and growth rate the same approach needs to be taken. The widely adopted MQTT message transport can be thought of like HTTP i.e. providing an open and interoperable messaging framework. But the IIoT is missing the “definition” of the data in the payload. Therefore Sparkplug can be thought of like the HTML of IIoT.
Sparkplug infrastructures are not intended to replace OPC but rather complement it. In existing brownfield industrial sites, OPC-UA polling engines are used to gain access to the raw Process Variables, for example. That said, Sparkplug is a better choice than OPC-UA in a wide range of scenarios. Here are a few points to consider:
Moreover, the Eclipse IoT working group is the home to a variety of protocol implementations, such as Eclipse Californium (CoAP), Eclipse Cyclone DDS (DDS), Eclipse Milo (OPC-UA) and Eclipse Paho (MQTT), among others. Ultimately, we believe it is up to developers to pick the right tool for their project.
Initially, the working group will host the Sparkplug specification project and Eclipse Tahu, an existing implementation of the standard. The current Sparkplug (version B) specification was contributed to the Eclipse Foundation by Cirrus Link Solutions. But since the development of the Sparkplug B specification, there have been many suggestions by both end customers and vendors for additional capabilities and features.
If you want to get in on the ground floor, start by reviewing the working group charter and the Sparkplug Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org. Individually, developers can join the Sparkplug WG mailing list where we’ll be sharing the progress of the working group.