IT-Teams geben sich beim Monitoring im Internet der Dinge (IoT) zu oft damit zufrieden, dass beispielsweise ein vernetzter Sensor plausible Messwerte in der erwarteten Regelmäßigkeit sendet. Dabei könnten die IT-Verantwortlichen jedoch einige kritische Umstände übersehen. Zum Beispiel, dass das Gerät häufige Reboots ausführt, die auf einen latenten Hardwaredefekt hindeuten. Oder dass aufgrund der zahlreichen Neustarts der Ladestand der Batterie rapide abnimmt. Nicht zuletzt könnte den Betriebsverantwortlichen auch das merkwürdige Kommunikationsvolumen des Device entgehen, das darauf hindeutet, dass es nicht nur regelkonform mit der Applikation im Backend kommuniziert, sondern als Mitglied eines Botnetzes auch Angriffe gegen fremde Webseiten ausführt.

Bild 1 zeigt den typischen Aufbau eines IoT-Systems: Dies besteht in der Regel aus den drei Schichten Endgeräte, Edge und Backend. Die Schichten sind über Netzwerke verbunden. Die Applikationen auf den Endgeräten kommunizieren mit Applikationen im Backend oder auf Edge-Servern. Edge-Server ermöglichen es, IoT-Daten nahe am Entstehungsort zu verarbeiten und zu speichern.

Die Anbindung der Endgeräte kann sowohl kabelgebunden als auch kabellos erfolgen. Bei den kabelgebundenen Varianten finden sich Feldbus-Systeme (KNX, Modbus, Profibus et cetera) oder Ethernet-basierte Systeme (EtherCAT, EtherNet/IP, Single Pair Ethernet und ähnliche). Häufig bevorzugen IT-Verantwortliche jedoch kabellose Infrastrukturen – entweder weil es sich bei den zu vernetzenden Dingen um mobile Objekte wie zum Beispiel Fahrzeuge, Ladungsträger oder mobile Werkzeuge handelt, oder weil Funknetze einfacher, schneller und kostengünstiger zu implementieren sind.

In der Gebäudeautomatisierung kommen Funktechniken wie Enocean, ZigBee, Z-Wave, Bluetooth LE oder Bluetooth Mesh zum Einsatz, in Smart-City-Anwendungen Techniken, die in der Lage sind, größere Strecken zu überbrücken, wie beispielsweise LoRa/LoRaWAN, NarrowBand-IoT (NB-IoT) oder auch vermaschte Netze auf der Basis von IEEE 802.15.4. Bei den Netzen in Richtung Backend und innerhalb des Edge treffen wir auf IP-basierte Netze, deren Kommunikationsmedien aus der klassischen IT hinlänglich bekannt sind: Ethernet, WLAN, Mobilfunk, Internet-VPN, SD-WAN und so weiter.

Als Brücken zwischen den Netzen der Endgeräte und denen des Edge oder des Backends dienen entweder IP-Router oder Gateways, abhängig davon, ob die Endgeräte IP unterstützen oder nicht. Auch bei den IoT-Devices geht der Trend zur All-IP-Kommunikation, entweder nativ oder mithilfe einer speziellen Adaptionsschicht (siehe hierzu auch die RFCs und Drafts der IETF zu "6LoWPAN" und "6lo" [1]). Extrem schmalbandige Funknetze sind jedoch für den mit IP verbundenen Overhead selten geeignet. In diesem Fall müssen Gateways die erforderlichen Protokollkonvertierungen durchführen. Es gibt auch IoT-Systeme, die gänzlich ohne Edge auskommen. Typische Beispiele sind Telematiksysteme, bei denen die in Fahrzeugen verbauten Onboard Units direkt über Mobilfunk und Internet-VPN mit dem Backend verbunden sind.

Das Monitoring von IoT-Endgeräten und deren Konnektivität unterscheidet sich aus mehreren Gründen vom klassischen IT-Infrastrukturmonitoring und stellt Betriebsteams mit entsprechenden Erfahrungen vor neue Herausforderungen. An erster Stelle sind die Ausstattung der IoT-Devices und die oftmals schmalbandige Anbindung zu nennen. Eingeschränkte Verarbeitungs- und Speicherkapazitäten erlauben weder die Installation von Monitoringagenten noch häufige Zustandsabfragen durch einen zentralen Monitoringserver. Wenn die Geräte zudem nur wenige Bytes pro Stunde übertragen dürfen, stehen die Überwachungsdaten in Konkurrenz zu Applikationsdaten im Netz.

IT-Verantwortliche können zudem nicht davon ausgehen, dass die IoT-Technik jederzeit bereit ist, Zustandsabfragen zu empfangen. Bei batteriebetriebenen Geräten ist es für eine lange Batterielebensdauer essenziell, die Aktivzeiten möglichst kurz zu halten.

Insbesondere das industrielle IoT zeichnet sich durch eine heterogene Landschaft an IoT-Teilnehmern aus: Sensoren, Aktoren, mobile Werkzeuge, Indoor-Ortungssysteme, Kameras oder nachträglich IoT-tauglich gemachte Altsysteme. Mit dieser Heterogenität gehen unterschiedliche Hardwareausstattungen, Betriebssysteme, Kommunikationstechniken und Protokolle einher.

Die IT-Welt im Edge und im Backend ist über IP vernetzt und lässt sich mit den bekannten Methoden und Tools des klassischen IT-Monitorings überwachen. Wir werden uns daher im Folgenden auf das Monitoring von Endgeräten und deren Konnektivität konzentrieren. Das bedeutet aber nicht, dass IT und IoT getrennte Monitoringsilos bilden müssen. Vielmehr ist es in der Regel sinnvoll, die Monitoringdaten beider Welten in einer Observability-Plattform zusammenzuführen, um eine ganzheitliche Sicht auf das IoT-System und dessen Bausteine zu erlangen.

Kommen wir noch einmal auf Bild 1 zurück. Darin sehen wir bereits Ansatzpunkte für das Monitoring von IoT-Geräten und deren Konnektivität: den Datenstrom der IoT-Anwendung, das Gerätenetz und die die IoT-Devices. Geräte, die keine Monitoringfunktionen unterstützen, lassen sich zumindest dadurch im Blick behalten, dass ein Augenmerk im Backend oder im Edge auf den Datenstrom der IoT-Anwendung auf betrieblich relevante Ereignisse oder Merkmale gelegt wird. Betrieblich relevant ist dabei Folgendes:

- Gerät kann sich erfolgreich mit Edge oder Backend verbinden.

- Verbindungsversuch des Geräts schlägt fehl (eventuell zusätzlich differenziert nach Ursache).

- Device sendet korrekte Applikationsnachricht.

- Gerät sendet fehlerhafte Applikationsnachricht (eventuell zusätzlich differenziert nach Fehlertyp).

- Applikationsnachricht an das Gerät ist erfolgreich.

- Applikationsnachricht gelangt nicht zum Device.

Daraus sind Metriken ableitbar, wie zum Beispiel der Zeitpunkt des letzten erfolgreichen Verbindungsaufbaus, die Rate erfolgreicher Verbindungen, die Rate abgebrochener Verbindungsversuche, die Nachrichtenraten in Sende- und Empfangsrichtung oder die Anzahl gesendeter beziehungsweise empfangener Bytes. Diese Metriken lassen sich nicht nur für einzelne Geräte, sondern auch für Gruppen davon oder die gesamte Flotte berechnen. In Kombination mit Schwellenwerten ist ein geeignetes Werkzeug in der Lage, Alarme bei Über- oder Unterschreitungen zu versenden.

Das Überwachen des Anwendungsdatenstroms ist auch für die Erkennung von Anomalien nutzbar. Beispielsweise zeigen große Telematik-Systeme oft typische, immer wiederkehrende Tagesverläufe der Nachrichtenrate. Störungen, die eine große Zahl von Endgeräten betreffen, äußern sich als Dellen im erwarteten Kurvenverlauf, die mit statistischen Mitteln gut detektierbar sind. An der Größe der Abweichung lässt sich auch abschätzen, wie viele Devices gestört sind oder wie groß die geografische Region ist, die von der Störung betroffen ist. Anomalien in IoT-Systemen zeigen sich den Verantwortlichen manchmal auch ohne KI, sondern nur über die Erfahrung und mit einfachen statistischen Werkzeugen.

Das Monitoring des Anwendungsdatenstroms ist ein effizientes Mittel, um grundlegende Fehlerzustände in einer IoT-Landschaft zu erkennen und zu alarmieren. Es ist daher nicht verwunderlich, dass IoT-Plattformen wie "Microsoft Azure IoT" entsprechende Funktionen anbieten. Bild 2 gibt einen Überblick, wie die Dienste IoT Hub [2] und Azure Monitor [3] den IoT-Datenstrom über den Alarmierungspfadüberwachen. Darüber hinaus gibt es in Azure Monitor weitere Funktionen für Analysen, Visualisierungen und automatischen Aktionen, auf die wir hier nicht näher eingehen.

Der IoT-Hub ist die zentrale Komponente, die die Kommunikation mit den Endgeräten abwickelt. Neben zahlreichen weiteren Metriken sammelt der Dienst auch folgende gerätebezogenen Metriken:

- Anzahl von Geräten, die mit dem IoT Hub verbunden sind.

- Übersicht der Cloud-zu-Gerät-Nachrichten, deren Übertragung abgebrochen wurde.

- Cloud-zu-Gerät-Nachrichten, die vom Device erfolgreich angenommen wurden.

- Anzahl der abgelehnten Cloud-zu-Gerät-Nachrichten.

- Erfolgreich empfangene Gerät-zu-Cloud-Nachrichten.

Diese Metriken werden in der Regel im Minutentakt gemessen und im Anschluss an Azure Monitor weitergeleitet (in Azure auch als "Plattformmetriken" bezeichnet). Das Erfassen und Weiterleiten der Plattformmetriken erfolgt automatisch, eine explizite Konfiguration ist nicht erforderlich. Im Azure Monitor können sogenannte "Alert Rules" Alarme auslösen, wenn eine Metrik einen Schwellenwert über- oder unterschreitet.

Allerdings decken die Plattformmetriken nicht alle Aspekte ab, die für ein umfassendes Monitoring erforderlich sind. In einem sicherheitskritischen IoT-System könnte zum Beispiel die aktuelle Rate von Verbindungsversuchen unbekannter Endgeräte interessant sein. Gleiches gilt für die Rate von Verbindungsanforderungen, die wegen Zertifikatsfehlern fehlgeschlagen sind. Solche Vorgänge lassen sich im IoT Hub als Logeinträge erfassen und an Azure Monitor weiterleiten. Im IoT-Hub ist dazu eine sogenannte Diagnoseeinstellung erforderlich, die angibt, welche Kategorien von Logeinträgen dieses Verfahren berücksichtigen soll. Zu den verfügbaren Logkategorien gehören beispielsweise "Connections", "Device Telemetry" oder "Device Identity Operations". Spezielle Alert Rules, die im Azure Monitor mit einer Suchabfrage auf der Log-DB verbunden sind, können wie bei den Metriken Alarme auslösen.

Ein häufiges Fehlerbild in IoT-Systemen ist, dass die Kommunikation zwischen Backend und einzelnen Devices oder ganzen Gerätegruppen unterbrochen ist. Das Überwachen des Anwendungsdatenstroms kann diese Störung zwar detektieren, aber keinen Hinweis liefern, ob das Problem auf einem fehlerhaften Softwareupdate oder einem Netzwerkfehler basiert. Das zusätzliche Monitoring des Gerätenetzes ist daher eine Voraussetzung für die schnelle Identifikation von Fehlerursachen.

Dies gilt insbesondere beim Einsatz von Funknetzen, die in einem lizenzfreien Frequenzbereich arbeiten. Solche Netze können schwer kontrollierbaren externen Einflüssen unterworfen sein. Beispielsweise wenn neu in Betrieb genommene Fremdsysteme, die in räumlicher Nähe denselben Frequenzbereich nutzen, zu spontanen Beeinträchtigungen in der Gerätekommunikation führen. Die Signalqualität auf der Funkstrecke könnte sich auch schleichend verschlechtern, zum Beispiel weil ein oder mehrere Geräte in den Funkschatten eines gerade im Bau befindlichen Gebäudekomplexes geraten sind.

Das Monitoring des Gerätenetzes erläutern wir am Beispiel von LoRaWAN [4] und einem Dienst von Amazon Web Services (AWS). LoRaWAN gehört zur Klasse der sogenannten "Low Power Wide Area Networks" (LPWAN) und seine Bausteine sind Endgeräte, Gateways und drei Typen von Uplink-Servern (Network, Join, Application). Zwischen IoT-Devices und Gateways kommt eine proprietäre Funktechnik der Firma Semtech Corporation zum Einsatz. Sie nutzt in Europa eines der lizenzfreien Frequenzbänder mit 433 MHz oder 868 MHz. Network-Server übernehmen das Routing von Nachrichten zwischen Gateways und den übrigen Uplink-Servern. Gateways und alle Uplink-Server sind über einen IP-Backbone verbunden.

Der Dienst "AWS IoT Core for LoRaWAN" [5] bildet die Funktion von Network- und Join-Server in der Cloud ab (Bild 3). Er entlastet die Betreiber eines LoRaWAN-Netzes somit vom Betrieb eigener Network- und Join-Server. Mit dieser Umgebung ist es möglich, LoRaWAN-Gateways direkt an die Cloud anzuschließen. Die Funktion des Application-Servers kann in derselben Cloud mittels weiterer AWS-Dienste abgebildet werden. Für ein reibungsloses Interworking zwischen Gateways und dem AWS-Service ist Voraussetzung, dass auf den Gateways das Softwarepaket "LoRa Basics Station" läuft.

Bei jeder Nachricht, die ein Gateway von einem Endgerät erhält, bewertet das Gateway die Qualität der Funkstrecke. Die zu diesem Zweck gemessenen Metriken werden als Metadaten zu jeder Uplink-Nachricht hinzugefügt. Der Network-Server kann mithilfe dieser Metriken in der Downlink-Richtung bestimmen, über welches Gateway ein Endgerät am besten zu erreichen ist. Solche Metriken sind aber auch für das Monitoring hilfreich. AWS macht sie daher in einem Dashboard oder per API verfügbar:

- Signal to Noise Ratio (SNR): Maß für die Qualität des Nutzsignals und gibt an, wie gut es sich vom Hintergrundrauschen beziehungsweise Störsignalen abhebt.

- Received Signal Strength Indicator (RSSI): Indikator für die Feldstärke eines Signals.

- Verlustrate von Uplink-Nachrichten: Die Verlustrate lässt sich aus Sprüngen im Frame Counter ableiten.

Diese Datensätze lassen sich über ein vorzugebendes Zeitintervall aggregieren, entweder für einzelne oder für alle Geräte, die ein Gateway bedient. Aus dem zeitlichen Verlauf der Daten ergeben sich Hinweise darauf, wo und wie sich die Qualität des Funknetzes verändert. Abzuleitende Maßnahmen wären beispielsweise, die Datenraten zu verändern, Gateways zu tauschen, Devices näher bei einem Gateway zu platzieren oder zusätzliche Gateways zu installieren.

Bei IoT-Endgeräten, die über ausreichende Verarbeitungs- und Speicherkapazitäten verfügen und zudem direkt in ein IP-Netz eingebunden sind, ist es nahe liegend, sie wie andere IT-Systeme mit einem Monitoringagenten auszustatten. IoT und IT können damit in eine gemeinsame Überwachung integriert werden. Es ist daher nicht verwunderlich, dass etablierte Produktanbieter aus dem IT-Monitoring auch spezielle IoT-Agenten im Portfolio führen.

So zum Beispiel die Firma Datadog, die eine auf das IoT zugeschnittene, leichtgewichtige Version ihres Monitoringagenten anbietet [6]. Diese Software läuft unter Linux und unterstützt gängige Hardwareplattformen für IoT-Systeme (x64, ARM). Laut Herstellerangaben benötigt der Agent in der aktuellen Version 36 MByte Hauptspeicher, 63 MByte Plattenplatz und Netzwerkbandbreiten von 237 Bits/s (Uplink) und 79 Bits/s (Downlink). So kann Datadog die CPU-Auslastung, IO-Raten, TCP/IP-Statistiken und Performancedaten über den Linux-Systemmanager systemd erfassen. Ferner unterstützt der Agent das Einsammeln von Logs und ist in der Lage, individuelle Applikationsmetriken einzubinden.

Es mag Fälle geben, in denen die IT zwar Überwachungspunkte auf den Endgeräten benötigt, jedoch etwa aus Kostengründen keine kommerziellen Monitoringagenten auf den Geräten installieren möchte. Wenn die Implementierung der IoT-Applikation unter eigener Kontrolle stattfindet, lässt sich das Monitoring auch in die Applikation integrieren. Die Ergebnisse lassen sich so entweder als Metadaten an Applikationsnachrichten anhängen oder separat innerhalb einer Heartbeat-Nachricht an das Backend übertragen. Nicht zuletzt ist es eine Alternative, auf die Standards von OpenTelemetry zu setzen und die Monitoringdaten an eine Open-Source-Software im Backend zu senden.

Wir haben drei Ansätze für das Monitoring in IoT-Systemen beschrieben und an Beispielen aus der industriellen Praxis erläutert. Das Überwachen des Anwendungsdatenstroms bildet dabei in vielen Fällen die Basis der Überwachung. Welche weiteren Bausteine erforderlich sind, hängt von den spezifischen Anforderungen des Systems ab. Wenn keine kritischen Geschäftsprozesse von der korrekten Funktion eines IoT-Geräts abhängen und es zudem in seiner Netzwerkumgebung gut abgesichert ist, mag es in der Tat ausreichen, lediglich den Applikationsdatenstrom im Blick zu behalten.

IoT-Geräte sind jedoch zunehmend auch in kritische Geschäftsprozesse eingebunden, die durch Fehlfunktionen empfindlich gestört werden, zum Beispiel die Überwachung kühlpflichtiger Güter während Transport und Lagerung. Ein Ausfall der überwachenden IoT-Infrastruktur kann nicht nur zum Verlust wirtschaftlicher Güter, sondern auch zur Verletzung branchenspezifischer Vorschriften führen. Vergleichbar kritische Rollen spielen IoT-Systeme in der Fertigungsindustrie, in der Medizin, im Gebäudemanagement und zahlreichen weiteren Einsatzgebieten. Es gibt daher kein allgemeingültig optimales Monitoring für das IoT. Ob eine entsprechende Software dem jeweiligen Einsatzfeld angemessen ist, müssen IT-Verantwortliche immer vor dem Hintergrund der übergeordneten Geschäftsziele, der branchenspezifischen Vorschriften, der Sicherheitsrisiken und der Kosten betrachten.