Testen wir ausreichend?

Mit Blick auf die Cybersecurity typischer IoT-Anwendungen im industriellen Umfeld lässt sich klar sagen: Es wird zu wenig getestet. Hinsichtlich der Funktionalität und Stabilität ist das Lagebild relativ diffus. Ein individueller Abgleich mit den existierenden Möglichkeiten zeigt aber vielfach deutliche IoT-Test-Gaps auf. Im Vorfeld eines Wireless IoT-Praxiseinsatzes müssen umfangreiche Tests stattfinden, die weit über die Erfüllung der Compliance-Pflichten hinausgehen. Wichtig ist, mit Hilfe geeigneter Testmethoden möglichst viele Schwachstellen und Fehler zu finden und zu beseitigen, um die erforderliche Zuverlässigkeit und Sicherheit zu gewährleisten. Während der gesamten Nutzungsphase durch den Anwender sollten darüber hinaus DevOps-Prozesse und Over-the-Air (OTA)-Software-Updates zur Anwendung kommen.

Die Methodenauswahl

Bild 1. Ein effektiver Ende-zu-Ende-Test für Wireless IoT-Lösungen bezieht die Benutzeraktivitäten ein und wird in Zielumgebungen mit realistischen Umgebungsbedingungen durchgeführt. Als Bindeglied zum Entwicklerteam wird beispielsweise ein an die Aufgabe angepasstes Test- und Debug-Proxysystem mit Zugriff auf alle relevanten Endpunkte genutzt, das einen eigenen (Out-of-Band) Kommunikationskanal benötigt. © SSV

Den Entwicklern von IoT-Komponenten und Anwendungen stehen inzwischen zahlreiche Testmethoden zur Verfügung. Die Auswahl des jeweils zum Einsatz kommenden Methodenmix hängt von verschiedenen Faktoren ab. Neben dem spezifischen Know-how innerhalb des Entwicklerteams haben die jeweils zu testenden Komponenten, IoT-Systemanforderungen und Compliance-Aspekte einen großen Einfluss auf den »Was wird wie getestet?«-Fragenkomplex. Aber auch Terminpläne und Budgets hinterlassen ihre Spuren. Zu den Kernkompetenzen eines IoT-Entwicklerteams und somit zum Pflichtprogramm der durchzuführenden Tests sollten allerdings auf jeden Fall die folgenden vier Methoden gehören:

• Unit-Test: Mit diesem Softwaretest werden etwa die Module und Funktionen einer IoT-Baugruppen-Firmware isoliert getestet, um die fehlerfreie Funktion sicherzustellen. Ein Beispiel für einen Unit-Test wäre die Überprüfung einer IoT-Sensor-Codefunktion hinsichtlich der korrekten Umwandlung einer analogen Eingangsmessgröße in einen digitalen Messwert.
• Integrationstest: Hierbei wird die Hard- und Software mehrerer IoT-Komponenten gemeinsam getestet, um die einwandfreie Zusammenarbeit sicherzustellen. Ein Beispiel ist der MQTT-Kommunikationstest zwischen Sensor und Gateway, um sicherzustellen, dass die Sensormesswerte korrekt übertragen und empfangen werden und auf dem Gateway die exakte Messgröße vorliegt.
• Funktionstest: Dieser Test dient der Validierung spezifischer IoT-Baugruppenfunktionen hinsichtlich ihrer korrekten Funktion. Ein Anwendungsbeispiel wäre der Test eines KI-basierten Machine Vision-Sensors, dem verschiedene physische Objekte mit bestimmten Merkmalen präsentiert werden. Dabei wird zum Beispiel das Datenpaket am Sensorausgang hinsichtlich des Klassifizierungsergebnisses geprüft.
• Systemtest: Mit seiner Hilfe wird ein gesamtes System als Einheit geprüft, um festzustellen, ob die erforderliche Systemfunktionalität gegeben ist. Ein Beispiel wäre der vollständige Test eines IoT-Systems für das Energiemanagement einer Produktionsanlage mit allen Sensoren, Aktoren, Infrastrukturbaugruppen, Netzwerkverbindungen sowie der Cloud-basierten Steuerungssoftware. Da ein solcher Ende-zu-Ende-Test in der Regel unter Laborbedingungen stattfindet, erfolgt die Simulation einiger Teilfunktionen – etwa die Benutzer- interaktionen oder das Sensordatenbild mit den realen Umgebungsbedingungen - mit entsprechenden Hilfsmitteln.

Darüber hinaus gibt es Sicherheits-, Leistungs-, Zuverlässigkeits-, Protokoll- und Stresstests. Aber auch zum Testen der Interoperabilität, Benutzerakzeptanz und Gebrauchstauglichkeit (Usability) existieren etablierte Methoden. Im Rahmen von DevOps kommen zusätzlich Regressionstests zum Einsatz. IoT-Produkte, die spezielle Normen erfüllen müssen – im Bereich der funktionalen Sicherheit –, erfordern unter Umständen weitere Test- und Dokumentationsschritte. Auch das Thema „Manuelle oder automatisierte Testdurchführung“ ist zu bewerten. Auf Grund der zahlreichen Methoden und der damit verbunden Komplexität sind teilweise sogar externe Experten erforderlich, um ein IoT-Entwicklerteam bei der Testdurchführung zu unterstützen. Auf jeden Fall sollte im Rahmen der Entwicklung auch die Cybersicherheit und die Zuverlässigkeit einer IoT-Lösung getestet werden. Dabei sind auch die jeweiligen Alterungsprozesse elektronischer Bauelemente über die gesamte Nutzungsphase einzubeziehen; beispielsweise Flash-Speicher-ICs und Energiespeicher, wie Batteriezellen, Kondensatoren, Gold Caps.

Systemtests allein reichen nicht

Eine weitere wichtige Testmethode ist der Ende-zu-Ende (E2E)-Test. Er ähnelt auf den ersten Blick zwar dem Systemtest, liefert aber in der Praxis tiefere Einblicke hinsichtlich möglicher Schwachstellen und Fehler. Bei einem E2E-Test wird ebenfalls das gesamte System überprüft, ausgehend von den IoT-Endpunkten (Sensoren, Aktoren) über die Infrastrukturkomponenten bis zur Benutzeranwendung. Dabei sind neben den Kommunikationsschichten – Netzwerke, Protokolle, Cloud-Services – auch die Benutzerschnittstellen miteinbezogen. Der Ende-zu-Ende-Test deckt somit den vollständigen Daten- beziehungsweise Informationsfluss ab: von der Datenerfassung mittels der IoT-Sensorik über die Datenübertragung und -verarbeitung in der Cloud bis hin zur Darstellung der Daten in einer Benutzeroberfläche. Im Unterschied zum Systemtest ist dabei auch die Benutzerinteraktion berücksichtigt. Sprich, es wird bedacht, wie beispielsweise der Endnutzer mit dem System interagiert und ob das gesamte System auch in diesem Kontext wunschgemäß funktioniert. Ein weiterer Unterschied zum Systemtest ist, dass ein solcher E2E-Test nicht im Labor, sondern so realitätsnah wie möglich mit echten Umgebungs- und Netzwerkbedingungen sowie realistischen Benutzerinteraktionen direkt in einer typischen Anwendungsumgebung erfolgen sollte. Ein effektiver IoT-Ende-zu-Ende-Test ist daher ein Feldtest, beispielsweise mit ausgesuchten Pilotkunden über einen längeren Zeitraum.

Solche Tests liefern weitreichende Erkenntnisse, die sich mit einem Systemtest in einer Labor- oder Entwicklungsumgebung in der Regel nicht gewinnen lassen. Ein Beispiel ist immer wieder die unvorhersehbare Kreativität der Anwendungsnutzer und die dadurch verursachten Interaktionssequenzen. Aber auch die Nutzung von Mobilfunknetzen mit IoT-Gateways an unterschiedlichen Standorten – sowohl national als auch international – bietet diverse Überraschungen. In der Praxis zeigt sich diesbezüglich immer wieder, dass IoT-Anwendungen beispielsweise dynamische Veränderungen in Mobilfunknetzen – Verfügbarkeitseinschränkungen, Latenzzeitunterschiede, einen 4G-auf-2G-Fall-back oder die Besonderheiten einer Global-SIM-Karte – nur unzureichend berücksichtigen und dadurch Probleme im 24/7-Dauerbetrieb auftreten.

Transparenz für Funkschnittstellen

Bild 2. Die Hardware eines Software Defined Radio (SDR) besteht typischerweise aus einem (analogen) Sender- und Empfängermodul als RF-Interface, sowie A/D- und D/A-Umsetzern plus einem digitalen Base Band Processing, z. B. eine Software-basierte digitale Signalverarbeitung mit Digitalen Signalprozessoren (DSPs). Zwischen den Wandlern und dem DSP ist ein Digital Front End zu finden, das verschiedene Adaptionsaufgaben ausführt. © Wikipedia

Ein sehr wertvolles Werkzeug für E2E-Tests mit Wireless IoT-Anwendungen sind Software Defined Radio (SDR)-Systeme (Bild 2). Eine wesentliche SDR-Eigenschaft ist, dass die relevanten Parameter eines Funksystems, wie Frequenzbereich, Modulation, Bandbreite, Zeitverhalten und Kanalkodierungsverfahren durch alleinige Änderungen der Software beziehungsweise der entsprechenden Parametervariablen erreicht werden. So lässt sich ein SDR über die passenden Parameterwerte und Softwarefunktionen an die Funktechnik einer IoT-Anwendung anpassen. Anschließend ist ein passives Mithören sowie die Endpunkt-Emulation von verschiedenen Funkprotokollen in unterschiedlichen Frequenzbereichen möglich, beispielsweise LoRa, Bluetooth, LTE. Mit einem SDR lassen sich auch verschiedene Cyberangriffsszenarien wie Wireless Replay Attacks durchspielen, um das Verhalten des zu testenden Systems zu untersuchen. SDRs sind daher ein äußerst vielseitiges Werkzeug für die Funkkommunikationsprüfung in Wireless IoT-E2E-Tests. Sie ermöglichen flexible, Budget-freundliche und weitreichende RF-Tests, um sicherzustellen, dass die drahtlose Kommunikation in einem IoT-System robust, sicher und zuverlässig im Rahmen der jeweiligen Anforderungen auch im Praxiseinsatz funktioniert.

Der Autor: Klaus-Dieter Walter ist Geschäftsführer bei SSV Software Systems.