Universal-Simulator für IoT-Cloud-Infrastruktur So gewinnen Sie wertvolle Zeit in IoT-Projekten

Der Faktor Zeit kann bei der Entwicklung und Herstellung von IoT-Geräten und -Services „game-winning“ sein. Das trifft ganz besonders auf die Möglichkeit zu, schon zu einem frühen Zeitpunkt die Kommunikation zwischen Gerät und Cloud testen und mögliche Fehler beheben zu können.

Die Krux: Hardware, Geräte-Software, Front- und Backend sowie die IoT-Cloud-Infrastruktur entstehen in aller Regel gleichzeitig. Das trifft auf eigens entwickelte Services genauso zu wie auf den Einsatz von Cloud-IoT-Services, wie zum Beispiel von Azure. Dabei zeigt allein ein Ausschnitt erforderlicher Services, wie komplex die Entwicklung und damit auch das Testen einer sicheren Device-to-Cloud-/Cloud-to-Device-Kommunikation tatsächlich ist:

• Device Provisioning Service: Dieser Service sorgt dafür, dass nur die entwickelten IoT-Geräte mit jener Cloud kommunizieren können. Hierfür bietet der Service verschiedene Möglichkeiten. Denkbar ist etwa die Bereitstellung eines Zwischenzertifikats für die gegenseitige Authentisierung mit Geräten. Bei erfolgreicher Authentisierung sendet der Service eine IoT-Hub-URL an das Gerät zurück, das dann mit dem IoT Hub kommunizieren kann.

• IoT Hub: Dem IoT Hub kommen mehrere Funktionen zu. Seine wichtigste Rolle: Er ermöglicht eine bidirektionale IoT-Kommunikation – zum Beispiel via MQTT-Verbindungen. Darüber hinaus bietet er mit der Direct Method auch eine Übersetzung von HTTP in MQTT und ermöglicht einem Backend, Befehle beziehungsweise Daten an ein Gerät zu senden. Der Device Twin verantwortet wiederum die Kommunikation mit einem Ist- und Wunschzustand. Seine Aufgabe besteht folglich in der Vermeidung von Synchronisierungsprobleme, zum Beispiel bei einer nicht durchgängigen beziehungsweise Verbindung zum Gerät.

• Event Hub: Während sich der IoT Hub mehr oder weniger wie ein Message Broker und RPC-Provider verhält, fungiert der Azure Event Hub als vollständig verwalteter Dienst zur Echtzeitdatenerfassung. Als solcher bewahrt er Nachrichten in einer sogenannten Message Queue so lange auf und organisiert diese, bis sie von verschiedenen Anwendern abgerufen werden.

• AKS Backend: In diesem, etwa in Kubernetes gehosteten Backend befindet sich die Domänenlogik. Anders als die Infrastruktur, die festlegt, wie die Cloud mit einem IoT-Gerät kommuniziert, definiert sie, was kommuniziert wird und wie reagiert werden kann. Dabei lassen sich Teile einer erarbeiteten Infrastruktur oftmals gut beziehungsweise nach leichten Anpassungen in andere Projekte übertragen. Die Domänenlogik ist hingegen immer projektspezifisch und damit individuell abzustimmen.

Allzweck-Gerätesimulator schlägt spezifischen Projekt-Gerätesimulator

Keine Frage: Standardisierte IoT-Services bieten zahlreiche Vorteile. Gleichzeitig gilt es, Lösungen für das fehlende, gute Debugging zu finden. Hierfür werden im Laufe des Projekts spezifische Gerätesimulatoren entwickelt und eingesetzt. Mit ihrer Hilfe können Unternehmen oder Dienstleister die beschriebenen Cloud-Architekturen testen, noch bevor das eigentliche IoT-Device zur Verfügung steht.

Das Problem: Verschiedene Teams verwenden unterschiedliche Programmiersprachen, beliebige Tools und Frameworks. Dadurch sind die Geräte nur selten auf andere Projekte übertragbar. Insbesondere, wer auf einen IoT-Dienstleistungspartner setzt, ist gut beraten, auf einen Allzweck-Gerätesimulator mit wieder verwendbarem Asset zu setzen. Denn der spart Zeit, Aufwände und Entwicklungskosten. Was sollte ein Universal-Gerätesimulator können?

• Benutzerfreundlichkeit: Der Simulator muss so einfach zu bedienen sein, dass sein Einsatz für einen Entwickler einfacher ist als das Verfassen von kurzen Skripts. Das setzt unter anderem eine Kenntnis der Simulationsmöglichkeiten voraus. Dazu zählen Domänen, aber auch wiederverwendbare Kommunikationslogik. Effizient ist zum Beispiel der Einsatz von Konfigurationsdateien. Sie lassen sich nicht nur wiederverwenden, sondern auch leicht anpassen. So enthalten sie alle domänenspezifischen Daten und können die Cloud-Architektur und ihre Umgebung abbilden.

• Wartbarkeit: Da sich IoT-Cloud-Services stetig weiterentwickeln und in der Folge immer wieder neue Funktionen bieten, muss ein Universal-Simulator flexibel und einfach erweiterbar sein. Auf diese Weise lässt er sich leicht an die neuesten Architekturen und Cloud-Kommunikationstechnologien anpassen.

• Stabilität: Beim Debuggen und Testen einer Cloud-Infrastruktur gilt es, Fehlermeldungen des Simulators selbst zu vermeiden. Kotlin ist vor diesem Hintergrund eine gute Wahl, um generische Implementationen und Laufzeitfehler auf einem Minimum zu halten. Zudem sollte der Simulator problemlos hoch- und runtergefahren werden können. Voraussetzung: Er ist „stateless“, enthält also alle relevanten Daten in der Konfigurationsdatei.

• Testfunktionen: Ein Allzweck-Simulator sollte Entwickler in die Lage versetzen, vor allem Funktionen testen zu können, die in fast allen IoT-Projekten auftreten. Bei Full-Stack-IoT-Anbietern zählt dazu etwa das Provisioning, das für das Onboarding von IoT-Geräten über Authentifizierungs-Services verantwortlich ist. Darüber hinaus spielt das Funktionieren der Device-2-Cloud-Kommunikation eine herausragende Rolle, da IoT-Geräte Daten wie Telemetrieparameter oder Zustandsinformationen senden. In der Konfigurationsdatei lässt sich leicht definieren, welche Art von Daten wann und wo gesendet werden. Auf diese Weise ermöglicht sie ein einfaches Testen der Verbindung zwischen IoT Hub über Event Hub bis zum Backend. Relevant ist in diesem Kontext auch das Testen der Cloud-2-Device-Kommunikation, die vor allem Befehle an das IoT-Device betrifft, etwa das Einstellen eines Parameters. Nicht zuletzt sollte ein Stress-Test durchführbar sein. Mit seiner Hilfe lässt sich feststellen, wie viele Geräte gleichzeitig mit einer Cloud-Infrastruktur kommunizieren können bevor Anpassungen der Service Tiers notwendig sind.

IoT-Entwicklungszeit sparen

Wer IoT-Geräte entwickelt, steht seit jeher auch unter Zeitdruck. Gerade frühzeitige Testmöglichkeiten der IoT-Cloud-Architektur gelten daher als erfolgskritisch. Wer folglich auf einen Umsetzungspartner setzt, der mit universellen IoT-Gerätesimulatoren arbeitet, spart Entwicklungszeit und -kosten und verschafft sich einen Wettbewerbsvorteil.