Edge-Cloud-Verbindung mit Lightweight M2M (LwM2M)

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

RTSoft GmbH

Wie lassen sich zahlreiche Maschinen auf eine Weise an die Cloud bringen, die sichere Updates ermöglicht, zuverlässige Fernüberwachung gewährleistet und zugleich ressourcenschonend ist? Das Open-Source-Protokoll Lightweight M2M (LwM2M) bietet einen vielversprechenden Ansatz.

Die Zahl an vernetzten Geräten steigt jährlich. Das erstmalige Deployment und die fortlaufende Wartung solcher Geräte wären schon für mittelständische Betriebe mit erheblichen Ausgaben verbunden.

RTSoft hat in Projekten mitgewirkt, in denen tausende von Maschinen zentral gesteuert werden müssen, und dort Konfigurations,- Firmware- und Applikationsupdates durchgeführt, auch wenn die Maschinen teils weit entfernt über verschiedene Netzwerke verstreut im Einsatz sind. Der folgende Beitrag liefert einen Überblick über das Lightweight M2M (LwM2M) Protokoll der Open Mobile Alliance und beleuchtet dessen Vorteile sowie Best Practices.

Das Protokoll ist speziell für das sichere Management und die Bereitstellung von Geräten sowie für zuverlässige OTA-Updates ausgelegt und bietet sich daher hervorragend für den Einsatz in IoT-Lösungen an. Der Beitrag beschreibt die Erfahrungen des Unternehmens aus realen Projekten und macht auf dieser Basis Vorschläge zur Optimierung von IoT-Architekturen.

Grundüberlegungen

Bei der Konzeptionierung klassischer IoT-Lösungen sollten weitergehende Planungen berücksichtigt werden, z.B. hinsichtlich Edge-Analytics, Predictive Maintenance usw. Diese Features müssen bestmöglich geschützt und an künftige Sicherheitsbedrohungen anpassbar sein. Bargeldzählsysteme oder Fleet-Tracker sind aus Engineering-Sicht Embedded-Plattformen, die z.B. auf Windows Embedded Compact 2013 laufen und über zelluläre Netzwerke miteinander verbunden sind, deren Durchsatz und Stabilität oft sehr eingeschränkt sind.

IoT-Konnektivität

Ein IoT-Stack setzt sich aus mehreren Schichten zusammen:

• Die Cloud stellt skalierbare Storage- und Context-Broker bereit (IoT-Hub). Steuer- und Überwachungsanwendungen sind in der Cloud gehostet oder mit der Cloud verbunden. Die Clouddienste stellen einsatzfertige Authentifizierungs- und Autorisierungsfunktionen bereit.

• Über das IoT-Gateway werden hauptsächlich Proximalnetzwerke mit den in der Cloud bereitgestellten Internetdiensten integriert. In neueren Lösungen wird diese Schicht um Edge-Analytics erweitert, d.h. die Datenverarbeitung erfolgt on-premise. Dies spart Kosten für Cloud Traffic und CPU-Ressourcen und erhöht darüber hinaus die Sicherheit wertvoller Daten.

• Das Gateway ist auch für die Bereitstellung der Geräte (Provisioning) verantwortlich, also die Geräte-Registrierung und -Konfiguration mit keinen oder nur sehr geringen Verwaltungskosten.

• Die IoT-Device-Konnektivität wird über Protokolle bewerkstelligt, die sich für die verschiedensten physikalischen Netzwerke und ressourcenbeschränkte (constrained) Geräte eignen.

Hier kommt das LwM2M-Protokoll ins Spiel – es spielt in jeder Schicht des IoT-Stacks eine Rolle.

LwM2M - Einführung

IoT-Konnektivität stand anfänglich für die nachrichtenorientierte Kommunikation zur Übertragung von Telemetriedaten und die Reaktion auf einfache (oft nicht eindeutige) Steuerbefehle. Mit MQTT/AMQP lassen sich sichere und hochentwickelte Messaging-Implementierungen realisieren. Auch die HTTP REST API kann eingesetzt werden, da sie die Programmierung vereinfacht.

Dennoch war selbst einfaches Messaging basierend auf MQTT/REST auf ressourcenbeschränkten Devices, z.B. kleinen Messgeräten zur Erfassung und Übertragung von Rohdaten, nicht möglich, da diesen nicht immer eine stabile TCP-Verbindung zur Verfügung steht. Angesichts der enormen Nutzlast entsteht durch TCP/IP ein maßgeblicher Overhead.

Zusammenfassend lässt sich eingeschränkte Konnektivität wie folgt definieren:

• Schmale Bandbreite

• Niedrige Kommunikationsfrequenz

• Geringer Payload (Nutzdaten)

• Hohe Latenz

• Geräte schlafen die meiste Zeit oder verlieren regelmäßig die Verbindung

Das CoAP-Protokoll trägt dazu bei, dass ressourcenbeschränkte Geräte von der Flexibilität aus REST und der Robustheit des MQTT-Protokolls profitieren. Es ermöglicht das Gerätemanagement und Service-Enablement für das IoT-Gerätemanagement in zellulären IoT-Netzwerken basierend auf 3GPP, darunter die neuen NB-IoT und EC-GSM IoT Technologien.

Der CoAP-basierte LwM2M-Stack bietet eine integrierte Überlastkontrolle, blockweise Transferfragmentierung, Handling-Mechanismen, die effiziente Codierung von Headern und Payload und ist gewissermaßen transportagnostisch. Damit eignet er sich für IP-basierte und auch nicht-IP-basierte Deployments. Das OMA LwM2M ist ein CoAP-basiertes Protokoll, das die Device-Konnektivität um objektorientierte Funktionalität erweitert und damit die Kommunikationsstrategie erheblich beeinflusst.

Ein über LwM2M verbundenes Gerät agiert als digitaler Zwilling – eine digitale Repräsentation einer realen Einheit bzw. eines Systems. Auf dem LwM2M-Server, mit dem das Gerät verbunden ist, wird also der Gerätezustand abgebildet, und auf diesem Zwilling lassen sich Geräteattribute ändern oder bestimmte Aktionen durchführen. Die OMA bezeichnet diesen Ansatz als IPSO – Smart Objects.

LwM2M-Datenmodell

Immer mehr End-to-End IoT-Lösungen kommen auf den Markt, und aus Sicht der Lösungsanbieter nimmt die Wiederverwendbarkeit von Software einen immer höheren Stellenwert ein. Mit einem konfigurierbaren Softwaremodell lässt sich Software schneller entwickeln, und die gleiche Gerätehardware kann mit nur minimalen Änderungen über verschiedene Anwendungsfälle verwendet werden.

LwM2M bietet eine Standardstruktur mit klar definierten Objekten. So lassen sich unterschiedliche Use Cases, Geräte usw. zusammenführen und eine Applikation so implementieren, dass sie sich für den Einsatz mit einem Standard-Betriebsmodell eignet.

LwM2M-Objektmodell

LwM2M bietet ein wiederverwendbares Objektmodell. So können alle Beteiligten eigene Objekte definieren und diese der OMA zur Standardisierung vorschlagen oder diese ohne Standardisierung für eigene Anwendungen nutzen. Grundsätzlich hat jedes LwM2M-Objekt einen 1) Ressourcenpfad (eindeutige REST URI) und 2) Ressourcen, die ebenfalls von URIs angesprochen werden und die folgenden Operationen erlauben:

1. Lesen (read), oder

2. Schreiben (write), oder

3. Ausführen (execute)

Die wichtigsten Resource-Datentypen decken alle Anwendungsfälle ab, von einfachen Datentypen (Zahl, String) bis hin zu binär codierten Chunks. Der LwM2M-Server kann für die Überwachung aller lesbaren Ressourcen konfiguriert werden (Subscribe) und wird über jede Änderung benachrichtigt.

LwM2M ist vornehmlich ein Device-Management-Protokoll. Es sollte jedoch so ausgelegt werden, dass es entsprechend der Anforderungen bestimmter Anwendungen erweiterbar ist. LwM2M eignet sich nicht nur für das Device-Management, sondern auch für die Übertragung von Service-/Anwendungsdaten. Auch dies wurde in unserem Projekt umgesetzt: Reports und Statistikdaten der Embedded-Software wurden als LwM2M-Objekte bereitgestellt und in der Cloud verarbeitet.

Lösungsansatz

LwM2M ist ein Client-Server-Protokoll; also muss das Device clientseitig entwickelt werden, damit eine geeignete Server-Implementierung auf Cloudseite laufen kann. Das LwM2M-Ökosystem entwickelt sich rasant, und es gibt bereits Open-Source-Client- und Server-Implementierungen für verschiedene Plattformen und Sprachen. Am ausgereiftesten erscheint die Eclipse Leshan Implementierung, die sowohl Server als auch Client bietet.

In einem unserer Projekte läuft das Zielgerät jedoch auf WEC2013 (Arm-Plattform), daher sind wir hier auf die C/C++ Implementierung bzw. C# für das .Net Compact Framework beschränkt.

Glücklicherweise steht mit Anjay.io die Referenz-Implementierung eines LwM2M-Clients, der in reinem C (C99) geschrieben ist, zur Verfügung. Mit erheblichem Aufwand konnten wir den Library-Port zum Arm-Compiler für Visual Studio 2015 entwickeln und im Projekt erfolgreich umsetzen.

INFO: Der Microsoft Visual Studio Arm-Compiler für WEC2015 bietet die meisten der C99-Features nicht an, z.B.

• Inline-Funktionen

• C99 – Deklaration lokaler Variablen

• Variable Length Arrays

• Boolesche Datentypen <stdbool.h>

Die Windows-API war dabei auch hilfreich, denn die ursprüngliche Implementierung basiert nur auf einer POSIX-API.

Durch Portieren der LwM2M-Anjay-Library auf WEC2013 entsteht eine Cross-Platform-Implementierung (WES, WEC, Linux), und die Schlüsselkomponenten werden als LwM2M-Objekte implementiert. Die OMA Registry für LwM2M-Objektfunktionen steht hier zur Verfügung: http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html

Wir haben die nachfolgenden wesentlichen Objekte im Projekt verwendet:

• LwM2M-Server, LwM2M-Sicherheit, LwM2M-Gerät - unerlässlich für jede LwM2M-Client-Implementierung

• Firmware-Update

• Lage

• Connectivity-Statistik

Dabei handelt es sich um Standardobjekte, doch LwM2M eignet sich nicht nur für die Implementierung von Standardobjekten; eigene Objektspezifikationen können entworfen werden. In unserem Projekt haben wir einen Anjay LwM2M-Objektgenerator entwickelt und verwendet, um kundenspezifische LwM2M-Objekte zu implementieren, die alle (etwa 100) Maschinenparameter abbilden.

Lessons Learned

Beim Einrichten von IoT-Lösungen basierend auf der LwM2M-Referenzimplementierung traten auch Schwachstellen zutage, zum einen die Konnektivität des UDP, dem wichtigsten Transportprotokoll für CoAP. UDP eignet sich nicht unbedingt für Internetanwendungen, da es häufig von Unternehmensfirewalls geblockt wird und Heartbeat-Signale zum Aufrechterhalten der Kommunikation benötigt. Diesem Problem lässt sich mit dem neuen Standard CoaP over TCP (RFS8323) begegnen. Bei ressourcenbeschränkten Geräten ist gewöhnlich ein TCP-Tunnel nur zwischen dem Cloud-Server und Gateway einzurichten.

Ein weiteres erhebliches Problem ist die Skalierbarkeit des LwM2M-Servers. Es hat sich gezeigt, dass die Leshan-Implementierung für den direkten Einsatz in einer Cloudumgebung unzureichend ist; sie ist sehr langsam, wenn große Datenvolumen eingehen, und eignet sich wohl nicht für mehrere Tausend anhaltende Verbindungen. Ausschlaggebend bei der Migration auf einen Ansatz mit IoT Smart Objects/Digital Twins ist jedoch, dass der gesamte IoT-Stack für intelligente Objekte ausgelegt wird. Überwachung, Reporting und Datenverarbeitung sind so zu gestalten, dass alle Vorteile aus dem Einsatz von Context-Objekten genutzt werden, anstatt nur Messages bei jedem Device-Event in einer Datenbank zu speichern. Mithilfe einer Cloud-Applikation lassen sich Echtzeit-Streamanalysen basierend auf dem Gesamtgerätezustand bzw. dem Betriebskontext aus mehreren Gerätezuständen ausführen.

Vorgeschlagene Lösung

Das erste Projektrelease der Banknotenzähler-Steuerung ergab ein schnelles IoT-Enablement der verfügbaren Hardware, obwohl ein veraltetes Betriebssystem verwendet wurde. Der Memory-Footprint ist hervorragend, da sich die LwM2M C-Implementierung für ressourcenbegrenzte Geräte bis hin zum Mikrocontroller eignet und eine gute Performance und Stabilität aufweist. Die Skalierbarkeit der WLAN-Verbindungen war jedoch unzureichend, so dass eine zusätzliche Lösung erforderlich war, um eine funktionierende On-Premise-Lösung in die Cloud zu übertragen.

Am schnellsten lässt sich dies über die Verbindung mit bestehenden Cloud-Providern umsetzen, so dass sich das LwM2M-Protokoll nahtlos integrieren lässt. Hier muss die Lösungsarchitektur folgende Schichten enthalten:

• LwM2M-Client (Gerät)

• LwM2M-Bootstrap-Server (für die Security-Konfiguration von Geräten im LAN)

• IoT-Edge-Gateway mit LwM2M-Server mit der Cloud verbunden. Ein Teil der Daten wird in dieser Schicht verarbeitet; das spart Kosten für die Cloud-Kommunikation. Hier kommt auch der digitale Zwilling ins Spiel, und der Kontext wird in Echtzeit verarbeitet.

• Die Cloud-Anwendung ermöglicht die zentrale Steuerung und Wartung einschließlich OTA-Updates der in der Cloud gemappten LwM2M-Geräte.

Mögliche Implementierungen für die LwM2M-Integration in eine Cloud-Infrastruktur: Azure Bridge, FiWare Orion adapter

Zusammenfassung

Bei der Entwicklung der neuesten IoT-Softwarearchitekturen wurden im oben beschriebenen Projekt zahlreiche Anforderungen adressiert. Mit einem plattformübergreifenden Open-Standard-Modul wurde Flexibilität geschaffen und das Projektrisiko gemindert. Das LwM2M-Protokoll erwies sich bei Provisioning- und OTA-Aktivitäten als äußerst effizient. Daten werden in der Cloud aggregiert, und der Gerätezustand wird dort abgebildet. Die Kombination mit mächtigen Cloud-IoT-Services wie AWS oder Microsoft Azure IoT schafft letztlich die ideale Balance zwischen Skalierbarkeit, Echtzeit-Analyse und Kosteneffizienz.

Connectivity im IIoT – Welcher Konnektivitätsstandard passt zu welcher Anwendung?

Was ist MQTT?

Das steckt hinter dem IIoT-Framework Connext DDS

(Der Beitrag wurde mit freundlicher Genehmigung der Autoren dem Embedded Software Engineering Kongress Tagungsband 2018 entnommen.)

Übersetzung: Sabine Pagler

* Dipl. Ing. Evgeny Denisov ist Leiter des IoT-Bereichs bei RTSoft. Dipl. Ing. Roman Alyautdin ist technischer Projektleiter bei RTSoft

(ID:46645883)