MQTT existiert mittlerweile seit fast 10 Jahren als OASIS Standard für IoT Anwendungen. Die meisten kennen MQTT als leichtgewichtiges Pub/Sub Protokoll schon seit längerem – nicht zuletzt durch die hohe Verbreitung in vielen Open Source IoT Projekten. Das Protokoll ist einfach zu benutzen und bietet durch passende Bibliotheken für eine Vielzahl von Programmiersprachen einen passablen Weg zum Einstieg in die Welt des Internet-of-Things. Problematisch ist seit jeher das Fehlen eines standardisierten Daten- und Informationsmodells: Gerade in der Automatisierung kocht jeder Hersteller noch immer sein eigenes Süppchen in Bezug auf die Abbildung von Topics, unterstützte Datentypen, das Payloadformat sowie technische Workflows. Mit Sparkplug ist die eclipse Foundation nun angetreten, dies für die typische Welt der Automatisierungstechnik ein und für alle Mal in Form einer nachhaltigen Spezifikation zu lösen. Im Vortrag bekommt ihr einen kurzen Überblick darüber, was MQTT ist, wie Sparkplug darauf aufsetzt, was es an Konzepten mit sich bringt und ob dies die Welt der Vernetzung von OT wirklich beeinflussen könnte.

1. Dev Day 2023 – Dresden
Eclipse
Sparkplug
Zündfunken für MQTT in der Industrie?

2. 2
Eclipse
Sparkplug.
01
Industrie 4.0 &
Begriffe und
Datenaustausch im
IIoT.
02
MQTT –Gestern,
heute & morgen.
03
Sparkplug –
Architektur,
Payload & Ablauf
04
Sparkplug
im Vergleich &
Fazit

3. 3
Eclipse
Sparkplug.
01
Industrie 4.0 &
Begriffe und
Datenaustausch im
IIoT.
02
MQTT –Gestern,
heute & morgen.
03
Sparkplug –
Architektur,
Payload & Ablauf
04
Sparkplug
im Vergleich &
Fazit

4. Ressourcen, Applikationen & Planung
→ unternehmerisch
Prozess- und Maschinensteuerung
→ operational
4
IT - OT.
IT OT

5. Ressourcen, Applikationen & Planung
→ unternehmerisch
Prozess- und Maschinensteuerung
→ operational
5
IT – OT – I4.0 - IIoT.
IT OT
Industrie 4.0
IIoT

6. Automatisierungspyramide
nach ANSI/ISA-95
6
IT - OT.
I/O
PLC
SCADA
MES
ERP
IT
OT

7. Automatisierungspyramide
nach ANSI/ISA-95
7
IT - OT.
I/O
PLC
SCADA
MES
ERP
IT
OT

8. 8
Shopfloor :: „Architektur“.
Security
IT OT
MES
Historian
Analytics
SCADA/IIOT Host
Device
4-20ma Input
4-20ma Input
Digital Output
Digital Output
Device
Sensor
Device
Device
ERP

9. 9
Shopfloor :: „Architektur“.
Security
IT OT
MES
Historian
Analytics
SCADA/IIOT Host
Device
4-20ma Input
4-20ma Input
Digital Output
Digital Output
Device
Sensor
Device
Device
ERP

10. 10
Datenaustausch im IIoT.
Scope auf
Automatisierung
Seriell
Shopfloor
Fertigung
Machine-to-
Machine
Polling
Geringe
Bandbreite
Einfache
Implementierung
Quasi-
standard
Breitband
Netzwerk
TCP/IP-
fähig
Protokoll
Selbst-
beschreibung
Frei
Verbindungs
-aussetzer
RbE
Realtime
IoT
Cloud
JSON
Internet
REST
SCADA
Informations-
verteilung

11. 11
Datenaustausch im IIoT.
Scope auf
Automatisierung
Seriell
Shopfloor
Fertigung
Machine-to-
Machine
SCADA
Polling
Geringe
Bandbreite
Einfache
Implementierung
Quasi-
standard
Breitband
Netzwerk
TCP/IP-
fähig
Protokoll
Selbst-
beschreibung
Frei
Verbindungs
-aussetzer
RbE
Realtime
IoT
Cloud
JSON
Internet
REST
“Altbacken”
“Teuer” “ist das nicht Internet?”
“für Hobbyprojekte”
Informations-
verteilung

12. 12
Eclipse
Sparkplug.
01
Industrie 4.0 &
Begriffe und
Datenaustausch im
IIoT.
02
MQTT –Gestern,
heute & morgen.
03
Sparkplug –
Architektur,
Payload & Ablauf
04
Sparkplug
im Vergleich &
Fazit

13. 13
(< 3.1.1) – Gestern.
• 1999 von IBM und Cirrus Link als Protokoll für Telemetriedaten
entwickelt
• Popularität für M2M / IoT ab ~2012
• Initialer Fokus: leichtgewichtiges Pub / Sub Protokoll mit geringem
Overhead und hoher Effizienz
• 2013 über die OASIS standardisiert → Aufmerksamkeit für
aufkommende IoT Themen
• Einsatz in IoT Anwendungen (Microcontroller, Embedded Devices)
• Einsatz für Sensordaten und Metriken
• mosquitto anfangs praktisch einzig verfügbarer Broker
• Anfangs nur eine Client Lib verfügbar
(C/C++)

14. 14
Allgemein.
MQTT Broker
Sensor
Gateway
Sensor Sensor
Laptop
Mobiles
Endgerät
…01001101…

15. 15
Allgemein.
Broker
Client A Client B
CONNECT
CONNACK
SUBSCRIBE
building/room/temp
PUBLISH
building/entry/rfidtag
0xFA09872B519C78D984E2
DISCONNECT
PUBLISH
PUBLISH
PUBLISH
building/room/temp
25°C
+retain
PUBLISH
building/room/temp
30°C
25°C
25°C
30°C
30°C
0xFA0987
2B519C78
D984E2

16. 16
RPC.
Broker
Client A Client B
PUBLISH
clients/A/result
result=foobar123
PUBLISH
PUBLISH
clients/A/command
doThisAndThat()
doThisAnd
That()
SUBSCRIBE
clients/A/command
doThisAnd
That()
foobar
123
PUBLISH foobar
123
SUBSCRIBE
clients/A/result

17. 17
Offene Flanken.
„Wer hat mir die Response
bereitgestellt?“
„Muss ich wissen, wer die Response bekommt?“
„Woher weiß mein zweiter Client,
dass seine Response nun obsolet ist?“
„Hat mein Client das Kommando
bereits bekommen?“ „Wie bekomme ich hier Berechtigungen hin?“

18. 18
(3.1.1) – Heute.
• Kommerzialisierung (HiveMQ!)
• Erste Anwendungen & Projekte
• Mehr Features, erhöhte Effizienz
• QoS: z.B. PUBLISH → PUBREC → PUBREL (entspricht in etwa TCPs SYN,ACK,ACK)
• MQTT via Websockets
• Auth
• 2014: Paho @ Eclipse Foundation (Eurotech FTW!)
• Client Libraries für praktisch alle gängigen Sprachen verfügbar, insbesondere auch durch WebSocket Support
• Unterstützung in Frameworks, RTOSes usw.

19. 19
Offene Flanken.
„Was genau ist warum
schief gegangen?“
„Was weiß der Client alles
über sich selbst bzw. seinen Kontext?“
„In welchem Format hat mir der Client
Daten geschickt?“
„Wie sage ich dem Client,
dass ich ihn (gerade) nicht mehr
bedienen kann?“
„Woher weiß der Client ob etwas
noch relevant ist?“

20. 20
(5) – Morgen.
• Features
• DISCONNECT vom Broker
• TTL für Client Daten
• verbesserte Fehlerbehandlung und –Reporting (PUBACK, SUBACK)
• Content-Type für MQTT-PUBLISH
• Identifikation und Bereitstellung von Funktionen für gängige Kommunikationsmuster mit MQTT
• Response Topic-Header, Correlation-Data
• Session & Message Expiry
• verbesserte Authentifizierungs- und Autorisierungsmechanismen.
• Shared Subscriptions (Server-seitiges „Load Balancing“ über mehrere Clients) →
• Metadaten nun als Header statt im Payload (vgl. X-Header bei HTTP)
• Eclipse Paho → Umfangreiche Client Libraries für verschiedenste Technologien
• (!) keine Rückwärtskompatibilität; allerdings zum Teil mittels „Emulatoren“ (spezielle Broker)
• ➔ Hat dadurch noch nicht den vollen Impact – 3.1.1 oder darunter ist weiterhin am häufigsten anzutreffen
$share/[GROUP_ID]/[TOPIC]/

21. 21
Offene Flanken.
„Wie soll ich meine Anlagendaten
modellieren?“
„Welches Datenformat eignet sich?“
„Wie soll ich Payload formatieren?“
„Welches Informationsmodell eignet sich
zur Abbildung meiner Anlagendaten?“
„Wie bilde ich Sessions und
deren Statusinformationen ab?“
„Wie bilde ich typische
Muster/Szenarien ab?“
„Wie bilde ich
meine IIoT Architektur ab?“
Korrelation: „Wer hat mir das geschickt?
Und wie soll ich ihm antworten?“

22. 22
Eclipse
Sparkplug.
01
Industrie 4.0 &
Begriffe und
Datenaustausch im
IIoT.
02
MQTT –Gestern,
heute & morgen.
03
Sparkplug –
Architektur,
Payload & Ablauf
04
Sparkplug
im Vergleich &
Fazit

23. 23
Sparkplug.
• Sparkplug ist eine Spezifikation zur Nutzung von MQTT in industriellen Anlagen und Abläufen
• Aktuelle Version: 3.0
• Von Cirrus Logic entwickelt
• Sparkplug Working Group → Eclipse Foundation

24. 24
Sparkplug.
Inhalte:
• Topics – Festlegung eines Topic-Namensraumes für IIoT
• Payload Schema – Datenstrukturen, Payloadformate & -inhalte
• State Management – Definition von Strategien für Sessions, Ausfälle, Recovery, Resumption
Ziel:
• Standard für IIoT & SCADA
• Werkzeug für effiziente Übermittlung einer hohen Anzahl individueller Metriken in Echtzeit
Projekte:
• Eclipse tahu → (nutzt Paho); liefert: Client Libs, Referenzimplementierungen, Beispiele für Sparkplug
Technologiebasis:
• MQTT 3.1.1

25. 26
Shopfloor :: „Architektur“.
Security
IT OT
MES
Historian
Analytics
SCADA/IIOT Host
Device
4-20ma Input
4-20ma Input
Digital Output
Digital Output
Device
Sensor
Device
Device
ERP

26. 27
Shopfloor :: „Architektur“.
Security
IT OT
MES
Historian
Analytics
SCADA/IIOT Host
Device
4-20ma Input
4-20ma Input
Digital Output
Digital Output
Device
Sensor
Device
Device
ERP

27. MQTT Device Node
(Sparkplug)
28
Sparkplug :: „Architektur“.
Security
IT OT
MES
(Sparkplug)
Historian
(Sparkplug)
Analytics
(Sparkplug) MQTT Broker
SCADA/IIOT Host
(Sparkplug) MQTT EoN Node
(Sparkplug)
Device
MQTT EoN Node
(Sparkplug)
MQTT EoN Node
(Sparkplug)
4-20ma Input
4-20ma Input
Digital Output
Digital Output
Device
Sensor
Device
Device
ERP
(Sparkplug)

28. 29
Sparkplug OT Devices.
EoN Node
➢ Gateway für Non-Sparkplug
Devices
➢ Bindet (legacy) OT Hardware
an
➢ Plug-and-Play Detection
Devices
➢ Sensoren
➢ Aktoren
➢ Steurungen
➢ Typischerweise Polling-
basierte (Legacy-)Protokolle
Enabled
Device
➢ Intelligente Devices mit
nativem Sparkplug Support

29. 30
Sparkplug Applications.
Primary
Host
➢ SCADA Host / IIoT Host
➢ Manage & Monitor EoN
Sparkplug
Host
➢ Sparkplug Konsumenten

30. 31
Sparkplug :: MQTT Topics.
• Topics strukturieren nach Hierarchie bzw. Kontext der Devices
• Bsp: spBv1.0/location1/STATE/app01
spBv1.0/location1/NCMD/node123
spBv1.0/location1/DCMD/node123/device456
• Daten von Devices unterhalb von EoN Gateways haben eigenes Topic
• (SCADA) Host Applikationen abonnieren per Wildcard
• RBAC: Devices werden über Credentials auf SUBSCRIBE und PUBLISH auf Ihr individuelle Ids beschränkt
[namespace]/[group_id]/[message_type]/[edge_node_id]/{[device_id]}
[namespace]/[group_id]/#

31. 32
Sparkplug :: MQTT Topics.
• Topics strukturieren nach Hierarchie bzw. Kontext der Devices
• Bsp: spBv1.0/location1/STATE/app01
spBv1.0/location1/NCMD/node123
spBv1.0/location1/DCMD/node123/device456
• Daten von Devices unterhalb von EoN Gateways haben eigenes Topic
• (SCADA) Host Applikationen abonnieren per Wildcard
• RBAC: Devices werden über Credentials auf SUBSCRIBE und PUBLISH auf Ihr individuelle Ids beschränkt
[namespace]/[group_id]/[message_type]/[edge_node_id]/{[device_id]}
[namespace]/[group_id]/#
message_type
➢ NBIRTH
➢ NDEATH
➢ DBIRTH
➢ DDEATH
➢ NDATA
➢ DDATA
➢ NCMD
➢ DCMD
➢ STATE
NODE
DEVICE
Applications

32. 33
Sparkplug :: BIRTH, DEATH, STATE.
• NBIRTH Messages müssen sämtliche Metriken ankündigen und mit Default-Werten füllen
• Muss stets erste MQTT Message sein und alle Metriken ankündigen
• ggf. Updates bei Änderungen im laufenden Betrieb
• DBIRTH Messages müssen sämtliche Metriken ankündigen und mit Default-Werten füllen
• Durch EoN publishen sobald ein lokales Device erkannt wurde („Plug-and-Play“)
• NDEATH
• „Last Will“ bei CONNECT mit Referenz auf NBIRTH
• Broker sendet NDEATH nach Ausfall → Property „Stale“ für Metriken aus NBIRTH
• DDEATH Messages müssen durch EoN bekannt gegeben werden
• STATE für SCADA Host
• +Retain und QoS 1 („at least once“) → für Konsistenz beim State
• „ONLINE“
• Muss als erste Nachricht nach Verbindungsaufbau published werden
• „OFFLINE“
• „Last Will“ bei CONNECT

33. 34
Sparkplug :: DATA, CMD.
• NDATA & DDATA
• Metriken
• Beispiele:
• I/Os
• Messwerte
• Software Versionen
• NCMD & DCMD
• Kommandos
• Beispiele:
• Outputs schreiben
• Rebirth
• Reboots

34. 35
Sparkplug :: Payload.
{
"timestamp": <timestamp>,
"metrics": [{
"name": <metric_name>,
"alias": <alias>,
"timestamp": <timestamp>,
"dataType": <datatype>,
"value": <value>
"metadata": ...
"properties": ...
"is_null": ...
"is_transient": ...
"is_historical": ...
}],
"seq": <sequence_number>
}
• Payload wir mittels Protobuf in der
Spezifikation definiert (außer STATE)
→ Binäres Format!
(wird aber häufig als JSON dargestellt)
• Name: Hierarchische Metrikstruktur
vergleichbar mit „Ordnerstrukturen“
• Datentypen:
(u)int8, (u)int16, (u)int32, (u)int64, float,
double, boolean, string, datetime, text, UUID,
dataset, bytes, file, template
Metrik Hierarchie Wert Datentyp
<value> <type>

35. 36
Sparkplug :: Payload.
{
"name":"Properties/Hardware Model",
"timestamp":1486144502122,
"dataType":"String",
"value":"Pi 3 Model B"
}
{
"name":"Node Control/Reboot",
"timestamp":1486144502122,
"dataType":"Boolean",
"value":false
}
{
"name":"Outputs/LEDs/Green",
"timestamp":1486144502122,
"dataType":"Boolean",
"value":true
}
NDATA
NCMD
DCMD
• Payload Format „gleich“ für xDATA
und xCMD

36. 37
Sparkplug :: MetaData.
• An Metriken
• is_multipart
• content_type
• size
• seq
• file_name
• md5
• description

37. 38
Sparkplug :: Properties und DataSets.
PropertySet & PropertyValue
• An Metriken
• Key-value Paare von zwei Arrays (key- und value-Array)
• is_null
• value
• Spezialfall Property „Quality“
• 0 = BAD
• 192 = GOOD
• 500 = STALE (→ NDEATH, DDEATH)
DataSet
• „Matrix“ bestehend aus Rows und Columns
• Inhalte sind Elemente eines Typs

38. 39
Sparkplug :: Template.
message Template {
message Parameter {
optional string name = 1;
optional uint32 type = 2;
oneof value {
uint32 int_value = 3;
uint64 long_value = 4;
float float_value = 5;
double double_value = 6;
bool boolean_value = 7;
string string_value = 8;
ParameterValueExtension extension_value = 9;
}
message ParameterValueExtension {
extensions 1 to max;
}
}
optional string version = 1; // The version of the Template to prevent mismatches
repeated Metric metrics = 2; // Each metric includes a name, datatype, and optionally a value
repeated Parameter parameters = 3;
optional string template_ref = 4; // MUST be a reference to a template definition if this is an instance
optional bool is_definition = 5;
extensions 6 to max;
}
• Templates für eigene Datentypen
• Komplexe Datentypen als
Zusammenstellung einzelner
Subvalues
• Auch User Defined Types (UDTs)
genannt
• Muss (und darf nur) in NBIRTH
Messages announced werden
• Versionierung ☺

39. 40
Sparkplug :: Version 3.0.
• Oktober 2022
• MQTT 3.1.1 mit Anforderungen in Anlehnung an 5.0
• Unterscheidung zw.
• Sparkplug Compliant MQTT Server
• Sparkplug Aware MQTT Server
• $sparkplug/certificates/... → Cache für BIRTH und DEATH Zertifikate
• Einführung TCK (Sparkplug Technology Compatibility Kit)
• Zertifizierungsprozess für Sparkplug Konformität
• Einführung von Tests in der Spezifikation (~300 Check Statements)
• Technische Prüfung mittels bereitgestelltem Tooling (HiveMQ-basiert + WebUI)
• Bei Absolvierung ist Verwendung des Logos möglich
$sparkplug/certificates/

40. 41
Eclipse
Sparkplug.
01
Industrie 4.0 &
Begriffe und
Datenaustausch im
IIoT.
02
MQTT –Gestern,
heute & morgen.
03
Sparkplug –
Architektur,
Payload & Ablauf
04
Sparkplug
im Vergleich &
Fazit

41. 42
Sparkplug VS *
Modbus OPC-UA HTTP MQTT / Sparkplug
(+) Weite Verbreitung
(+) Leichtgewichtung
(+) Seriell für Legacy Hardware
(+) Ubiquitäre Hardware
(+) State-of-the-Art
(+) Quasi-Standard
(+) Weite Verbreitung & Kompatibilität
(+) Einfache Implementierung
(+) Offener Standard
(+) Leichtgewichtung
(+) Guter Funktionsumfang durch MQTT
(+) Open Source (Libs „4 everywhere“;
Lösungsvielfalt - OSS und kommerz.)
(+) (aus Client-Sicht) Infrastruktur-
agnostisch
(+) SKALIERBARKEIT
!!!!!1111!1111einseinself
(-) Unflexibel
(-) Geringer Featureumfang
(-) Keine standardisierten „Workflows“,
proprietäre Protokollabläufe
(-) Teure Lizenzen & Produkte
(-) Komplexe Implementierung
(-) Proprietäre Erweiterungen
(-) ohne Informationsmodell
gleichermaßen unstandardisiert wie
Plain-MQTT
(-) schlecht skalierbar
(-) Messagebus als separates Konzept
nötig
(-) Paradigmenwechsel auf dem
Shopfloor nötig
(-) Akzeptanz & Wahrnehmung
„nimmt man das nicht für den
Bastelprojekte?“
„schon wieder eine neue Sau, die durch`s
Dorf getrieben wird“

42. 44
Fazit.
• Sparkplug bringt endlich Struktur und Organisation in MQTT!
• Es wird schwer, den Pace, den OPC-UA vorlegt, aufzuholen. Das Potential ist allerdings vorhanden
• Es wird schwer, die Automatisierer ohne konkrete Schmerzpunkte zu einem Paradigmenwechsel zu bringen

43. 45
Links.
• Sparkplug Spezifikation
• https://sparkplug.eclipse.org/specification/
• Sparkplug Protobuf File
• https://github.com/Cirrus-Link/Sparkplug/blob/master/sparkplug_b/sparkplug_b.proto
• Eclipse Tahu Projekt
• https://projects.eclipse.org/projects/iot.tahu
• https://github.com/eclipse/tahu
• Cirrus Link Examples
• https://github.com/Cirrus-Link/Sparkplug/tree/master/sparkplug_b/stand_alone_examples

44. 46
Fragen?

45. Danke!
Tobias
Nebel
IT Architect
Telekom MMS
+49 351 2820 5583
T.Nebel@telekom.de
47