Device-Payloads mit Eclipse Vorto synchronisieren: Ein praxisnaher Leitfaden

Alexander Edelmann

你好 (Chinesisch für „Hallo“), ich bin Alexander Edelmann, seit 2006 Software Engineer bei Robert Bosch, basiert in Singapur. Ich brenne für IoT und setze mich für offene Standards ein, die nahtlose Device-Interoperabilität über Plattformen hinweg ermöglichen. Ich engagiere mich aktiv im Eclipse IoT Vorto Project, das Cloud-basierte Tools für einheitliche Device-Beschreibung und Integration über diverse IoT-Ökosysteme liefert. Abseits des Engineerings genieße ich asiatische Küche, übe meine Stäbchen-Skills und spiele Tennis.

In einer Umgebung ohne globalen Standard ringen IoT-Device-Hersteller, Integratoren und Plattformanbieter mit der schieren Vielfalt an Payload-Formaten, APIs und proprietären Protokollen.

Eclipse Vorto adressiert diese Herausforderung durch Cloud-basierte Editoren, die vendor-spezifische Payloads in wiederverwendbare Vorto Function Blocks abstrahieren. Diese Blöcke werden zu einem Vorto Information Model zusammengesetzt, das den Digital Twin eines Devices definiert. Sowohl Information Models als auch Function Blocks sind in vortolang geschrieben, einer prägnanten Grammatik, die das Interface zwischen physischem Device und seinem Digital Twin spezifiziert. IoT-Lösungen kommunizieren ausschließlich über diese abstrakten Function Blocks und ihre zugehörigen Datenschemata – entkoppelt von disparaten Device-Datenformaten. Die Konvertierung roher Device-Daten in diese abstrakten Interfaces erfolgt via Vorto Mapping Specifications, die die Instruktionen zur Harmonisierung device-spezifischer Payloads kodieren.

Payload-Normalisierung im Allgemeinen

Daten-Normalisierung kann an verschiedenen Stellen im IoT-Stack erfolgen, sodass Stakeholder Kontrolle darüber behalten, wo proprietäre Daten in standardisierte Form transformiert werden.

1. Am Device-Node – Ein smartes Device (z. B. Bosch Smart Oven) verarbeitet Sensordaten lokal, normalisiert sie und kann Analytics exponieren, die in einen Cloud Data Lake aggregiert werden.
2. Am Gateway-Node – Ein Gateway, das multiple Sensoren/Devices via diverser Protokoll-Treiber (BLE, GPIO, etc.) aggregiert, normalisiert eingehende Daten für Gateway-Level-Analytics oder andere Business-Funktionen.
3. Am IoT-Plattform-Node – Analog zum Gateway normalisiert eine Cloud-IoT-Plattform Telemetrie, die durch Protokoll-Adapter (MQTT, CoAP, etc.) eingeht, für Device-Management oder Analytics-Services.
4. Am Applikations-Node – Eine Applikation normalisiert Daten, um agnostisch gegenüber spezifischen Devices zu bleiben und sich auf Business-Logik statt device-spezifische Decoder zu fokussieren.

Wenn ein Device Payload-Mapping nicht selbst durchführen kann – etwa wegen limitierter Rechenleistung oder Bandbreite – muss eine separate Mapping-Engine diesen Schritt auf einem intermediären, Gateway-, Plattform- oder Applikations-Node ausführen.

Tim Grossmann

Als deutscher Informatik-Student habe ich im letzten Jahr und halb Projekte in drei verschiedenen Bosch-Abteilungen absolviert. Meine Interessen liegen in Open Source und EduTech. Ich glaube, IoT und Automation bergen immenses Potenzial, den Alltag zu transformieren. Ich bin engagierter Learner und Developer und betreibe den weltweit größten kostenlosen Open-Source Instagram-Automation-Bot. In der Freizeit klettere und reise ich gerne.

Wie Eclipse Vorto Normalisierung adressiert

Eclipse Vorto stellt eine Runtime-Library bereit, die – konfiguriert mit einem Vorto Information Model – die Mapping Specification anwendet, um rohe Device-Payloads in ihre normalisierte Form zu transformieren. Die Mapping Specification ist versioniert und wird neben dem Information Model des Devices im Vorto Repository gespeichert, was Wiederverwendung über verschiedene Deployment-Nodes hinweg ermöglicht – Device, Gateway, Plattform, Applikation. Die Library steht aktuell für Java und Node.js zur Verfügung. Mehr zur Vorto Payload Mapping Library.

Beispiel: Industrielle Daten mit Eclipse Vorto normalisieren

Zur Illustration betrachten wir ein Szenario, in dem CSV-Telemetrie eines Permanentmagnet-Synchronmotors (PMSM) an einen Eclipse Hono MQTT Connector übertragen wird.

Die Vorto Payload Normalization Middleware konsumiert diese Daten von Hono, routet sie durch die Vorto Payload Mapping Engine und publiziert die harmonisierten Daten als AMQP Topic. Jeder AMQP 1.0 Subscriber kann die standardisierten Daten dann konsumieren, unabhängig vom ursprünglichen Device – unter Nutzung einer Digital-Twin-Plattform wie Bosch IoT Things.

In diesem Beispiel setzen wir Eclipse Ditto ein, einen Open-Source-Digital-Twin-Service, um die normalisierten Daten zu ingestieren und zu speichern. Das Vorto Dashboard fragt dann die Ditto API ab und präsentiert die Informationen mittels vorgefertigter, Vorto-konformer UI-Widgets.

Wenn Sie die gesamte Mapping-Pipeline in Aktion sehen möchten, besuchen Sie die Vorto Dashboard Demo.

Dieser Artikel gibt einen kurzen Überblick über Payload Mappings. Für einen umfassenden, schrittweisen Guide zur Konfiguration Ihrer eigenen Pipeline konsultieren Sie unser detailliertes Tutorial.