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.
The TCK scope is to define the “edge profile” and “host profile” Sparkplug TCK implementations.