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.
MQTT was originally designed as a message transport for real-time SCADA (Supervisory Control and Data Acquisition) 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 MQTT specification to provide maximum flexibility across any solution sector that might choose to use MQTT infrastructures.
But at some point, for industrial 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/DSC (Distributed Control System)/ICS (Industrial Control System) OT solutions. Meeting the operational requirements for these systems will enable MQTT based infrastructures to provide more valuable real-time information to Line of Business MES/OEE/Track-and-Trace/Cloud Services 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/DCS/ICS applications simple, efficient and easy to understand and implement.
This project proposal includes the Sparkplug specification itself, client libraries, and sample applications.
The scope of the Eclipse Tahu project consists of three major components:
- The Sparkplug Specification - This document describes the MQTT topic namespace, the payload-encoding scheme, and the required flow of messages, which ensure state of data originating from an edge device reporting to a backend/central application.
- Client library implementations initially in the following programming languages:
- Reference implementations of Sparkplug applications using the client libraries.
Eclipse Tahu addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures and provides a much-needed definition of how best to apply MQTT into these existing industrial operational environments.
Basic network architecture:
Tahu is currently addressing the following features required for MQTT centric IIoT:
Well-defined MQTT Topic Namespace applicable for the IIoT market
In order to be interoperable across the plethora of OEM device manufacturers of industrial equipment and the SCADA/HMI/Control/Cloud Services backend components that desired to subscribe to the resulting information a well-defined MQTT topic namespace needs to be defined. The topic namespace needs to be both efficient yet applicable to the applications that currently exist in the industrial market. The topic namespace needs to provide both the contextual information all the way to an individual device in the field, but also provide topic “verbs” to efficiently manage the “life cycle” of an MQTT session.
Efficient MQTT payload definition
Staying with the original intent of MQTT, the payload specification needs to stay “lean and mean” to best utilize low bandwidth networks (VSAT, Radio, Cellular). Not only does the payload need to be efficient, it needs to recognize the fact that the primary purpose of IIoT solutions is to provide Industrial Process Variable information from devices in the field to both SCADA/DCS/FCS OT solutions as well as line of business IT solutions.
MQTT STATE Management definition
MQTT has the awareness of the current MQTT session built in using the LWT feature. But for STATE aware OT applications like SCADA/DCS/FCS, there needs to be a succinct definition on how best to use MQTT’s built in STATE awareness in an overall SCADA/DCS/ICS infrastructure.
The Sparkplug specification provides all of the definitions and requirements listed above. In addition to the Sparkplug specification, Tahu will provide the required libraries and reference implementation code following the Sparkplug specification in:
Tutorials on getting the reference implementation code running on popular open hardware platforms like the Raspberry Pi will also be included in Tahu.
Eclipse IoT is a good location for Eclipse Tahu for a number of reasons. We believe that one of the best features of this technology is providing consistency around how MQTT is used in the Industrial Internet of Things (IIoT). There are a number of hardware/device manufacturers that have already implemented it natively as well as some cloud/application software companies. By open sourcing this technology through Eclipse IoT we believe it will accelerate the growth and adoption of it as well as provide a better and open forum for improvement and compatibility over time.
We also believe that there are a number of synergies with existing Eclipse IoT projects for Eclipse Tahu. These include but are not limited to:
The code is owned by Cirrus Link Solutions but has already been made available on a public Github site. This is the code that will be moved to Eclipse under Tahu. There are a number of OEM hardware manufacturers that are already using these libraries in their own commercial Sparkplug implementations.
With regard to third party licenses we have been careful all along to use 'Eclipse friendly' licenses. This is a list of third party dependencies:
Jackson-annotations - Apache Software License v2.0
Jackson-core - Apache Software License v2.0
Jackson-databind - Apache Software License v2.0
Protocol Buffers - New BSD License
Apache Commons IO - Apache Software License v2.0
Log4J - Apache Software License v2.0
Eclipse Paho - EPL v1.0
SLF4J - MIT License
NanoPB - https://github.com/metormote/nanopb/blob/master/LICENSE
We don't believe there are any legal issues but we would like some help in determining the best license for the Sparkplug specification itself.
The Sparkplug specification already exists as does the code. We'll need to do a bit of cleanup, refactoring, and completing the Eclipse legal review process but since we don't have too many dependencies we expect this should all happen fairly quickly. Rough estimates:
Initial contribution expected: 5/2018
First working build expected: 6/2018
- Potential improvements/revisions of the Sparkplug specification.
- Additional client library language support
- Additional reference/sample applications