Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?

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

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

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

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?“

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

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/

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

Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?

Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?

Recommandé

Contenu connexe

Similaire à Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?

Similaire à Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?(20)

Plus de CarolinaMatthies1

Plus de CarolinaMatthies1(7)

Tobias Nebel- Eclipse Sparkplug - Zündfunken für MQTT in der Industrie?