Ein Großteil der Unternehmen in Deutschland, Österreich und der Schweiz steckt bei IoT-Projekten noch in den Kinderschuhen. Die meisten der in Accenture-Studien befragten Firmen experimentieren oder planen derzeit noch – und ihr Erfahrungsschatz beschränkt sich maximal auf abgeschlossene Pilotprojekte.
So ist es auch nicht verwunderlich, dass bislang nur wenige Firmen eine Strategie für Qualitätssicherung und Testing von Hardware und Software im IoT definiert haben. Dabei sind Tests in frühen Entwicklungsphasen und schnelle Feedbackzyklen die Grundvoraussetzung für den Erfolg von IoT-Projekten. Sie decken auf, ob und wie gut die Qualitätsansprüche im Produktdesign adressiert werden, und ermöglichen auch ein frühes Gegensteuern, sollte das „Quality Engineering“ Mängel aufweisen.
IT/OT-Konvergenz: Vereinigung der Disziplinen – auch beim Testen
Die durch IoT bedingte Integration von Informationstechnik (IT) und Operational Technology (OT) [TechTarget] und das Design neuer Produkte mithilfe neuer Technologien stellen in vielen Unternehmen einen relativ unbekannten Bereich für das Testen dar. Denn für IoT-Lösungen müssen nicht nur Prozesse angepasst werden. Hier findet sich eine Vielzahl an unterschiedlichen Schnittstellen für physische Komponenten wie Sensoren und Anlagen, die ständig kommunizieren, zuverlässig erreichbar sein und schnell reagieren müssen.
Im IoT unterliegt die Zuverlässigkeit der Interaktion vielfältigeren und stringenteren Anforderungen; diese zu kennen, stellt für sich betrachtet bereits eine Hürde da. Im Test ist daher eine Untersuchung zu den Wechselwirkungen in mehreren, bislang disjunkt betrachteten Bereichen erforderlich, wie zum Beispiel:
- Stabilität und Zuverlässigkeit der Kopplung physischer Komponenten mit zentralen IT-Diensten über remote Anbindungen,
- Wechselwirkungen und Verlauf physischer Änderungen auf die IT-Anwendung,
- Nachweis der Funktionalität und Nutzbarkeit der IoT-Anwendung bei Feld-Einsätzen und in Echtzeit.
Ein Beispiel stammt aus dem Logistikbereich: Eine Warenhaus-Management-Lösung soll in die Cloud migriert werden. Da diese mit der für den automatisierten Warenfluss eingesetzten Roboter-Technologie ständig kommunizieren muss, besteht die Gefahr von latenzbedingten Timing-Problemen in der Materialsteuerung. Instabiles Netzverhalten und eine erhöhte Latenzzeit können nicht ausgeschlossen werden. Und hier kommen mit den gesteigerten Anforderungen neue Test-Disziplinen zum Tragen, die beim Testen von reinen Softwareanwendungen eher exotischer Natur sind: Der Einsatz von Netzwerk-Impairment-Simulatoren, die eine Simulation von Netzwerkkonditionen im Labor-Umfeld ermöglichen.
Mit Netzwerk-Impairment-Simulatoren lässt sich das Verhalten verschiedener drahtgebundener oder drahtloser Netz-Anbindungen realitätsgetreu simulieren, wie zum Beispiel Jitter beziehungsweise der Laufzeitvarianz einzelner IP-Netzwerkpakete. Der Netzwerk-Impairment-Simulator lässt sich als „Man-in-the-Middle“ zwischen die Komponenten schalten und für verschiedene Impairment-Szenarien konfigurieren.
Ein mögliches Tool ist die Linux basierte Command Line-Lösung namens tc-netem, welche auf dem IP-Netzkonfigurationstool Iproute2 basiert und eine Out-of-the-box-Verkehrskontrolle im Linux IP-Routing-Modul bietet. Dieser kann mithilfe weniger Kommandos als Netzwerk-Impairment-Simulator eingesetzt werden [netem]. Eine Linux-Maschine kann für das erwähnte Warenhaus-Szenario genutzt werden, indem diese als Router aufgesetzt wird und mithilfe von tc-netem das Paketvermittlungsverhalten von WAN-Anbindungen für unterschiedliche Szenarien simuliert.
Sobald man also beginnt, industrielle Anlagen remote zu vernetzen und per Softwareerweiterungen neuen digitalen Mehrwertdiensten zugänglich zu machen, ergeben sich neue Herausforderungen, die gezielt im Test zu adressieren sind.
Spätestens hier sollte klar werden, warum ein Wechsel zum Quality Engineering essenziell ist. So sind bereits zu Beginn elementare Fragen zu klären, welche wesentlichen Qualitätsaspekte in der Lösung zu berücksichtigen sind. Bei sich autonom bewegenden Produkten, wie Robotern und Fahrzeugen, gelten bereits strenge industrielle Normen, um die Unversehrtheit von Mensch und Maschine sicherstellen zu können. Mit IoT kommen neue Anforderungen hinzu. Das Öffnen von Systemen muss mit den Sicherheitsanforderungen und dem Datenschutz in Einklang gebracht werden und die Möglichkeiten, um Wechselwirkungen aus IT und OT flexibel prüfen zu können, sind rechtzeitig auf den Weg zu bringen.
Zukunft: Neue Technologien machen den Unterschied
Im IoT Quality Engineering ist die Unterstützung für schnelle, jedoch gleichzeitig qualitative Lieferungen von Software- und Hardware-Updates in das Feld ein wesentliches Merkmal. Hardware-Abhängigkeiten auf Plattformebene, wie zum Beispiel zu verschiedenen Mikrocontrollern und Sensoren, erschweren dies erheblich.
Kommt es in unserem Warenhaus-Beispiel zum vermehrten Einsatz von Logistik-Robotern und Logistik-Sensoren, um zum Beispiel Lagerorte autonom zu ändern und gleichzeitig Bestände automatisiert zu erfassen, ergeben sich komplexe Test- und Validierungsszenarien. Diese lassen sich unter Einsatz echter Hardware und in echten Feld-Umgebungen dauerhaft als Testumgebung kaum wirtschaftlich darstellen.
Cloud-Plattformen mit ihren umfassenden Diensten spielen daher eine gewichtige Rolle, um neue, auch Hardware bezogene Produkte schneller entwickeln, flexibel testen und sicher betreiben zu können. Sie bilden das Rückgrat, um Software-Änderungen schnell und stabil auf die sich im Feld befindenden IoT-Komponenten ausbringen zu können.
Eine Möglichkeit ist die Emulation von IoT-Komponenten in virtualisierten Containerstrukturen und die Skalierung mittels Cloud basierter Containerplattformen. Hiermit werden Hardware-Abhängigkeiten auf Sensor- und Mikrocontroller-Ebene umgangen und Umgebungen reproduzierbar simuliert. Ein hoher Automatisierungsgrad und die Integration von automatisierten Testläufen in bestehende CI/CD-Verfahren wird somit ermöglicht (Beispiel siehe [FOSDEM]).
So kommen ganze CI basierte Toolketten und per remote zugängliche IoT-Device-Farmen zum Einsatz, um flexibel neue Software auf einer Vielzahl an IoT-Komponenten testen zu können. Automatisierungslösungen können per API in bestehende Lösungen integriert werden, um die gewünschten IoT-Komponenten auszuwählen, diese mit neuer Software zu bestücken und automatisierte Tests auf diesen laufen zu lassen. Vergleichbare Dienste werden bereits bei Tests von Mobil-Geräten und Tablets genutzt und eine Standardisierung auf Schnittstellenebene wird angestrebt (siehe [ELC]).
Herkömmliche, zeitaufwendige Testprozeduren führen kaum zum Erfolg. Agile Ansätze sind wesentlich besser geeignet. Dauerhaft entfalten sie ihre Wirkung jedoch nur, wenn eine moderne Plattform als Unterbau zum Einsatz kommt und das gesamte Team die Voraussetzungen schafft, um in automatisierten Verfahren neue Software und Hardware testen und validieren zu können. Eine Grundvoraussetzung dafür ist das Quality Engineering mit abteilungsübergreifenden Kooperationen und organisatorische Anpassungen im Unternehmen. Denn IT und OT müssen Hand in Hand arbeiten, um alle Aspekte im Qualitätsmanagement abzudecken.
Begrifflichkeit: Das IoT-Testing?
Verstärkt kamen in der Vergangenheit Diskussion auf, ob mit der Einführung agiler Verfahren wie Scrum dedizierte Tester überhaupt noch erforderlich sind oder ob das Scrum-Team im „Whole Team Approach“ nicht auch ohne Tester auskommt [TechBeacon]. Zweifelsohne gibt es viel Bewegung mit einer starken Diversifikation der Aufgaben im Entwicklungsteam. Kundenansprüche sind regelmäßig zu evaluieren und in sinnvolle Maßnahmen zu überführen, eine zielgerichtete Sicht auf die Qualität und die erforderlichen Maßnahmen ist wichtig, um das Quality Engineering etablieren zu können.
Aufgrund der Vielzahl an unterschiedlichen Arten an IoT-Tests, wie zum Beispiel Netzwerktests, Sicherheitstests und Tests des Feldverhaltens und zuletzt der Entwicklung innovativer Use-Cases (siehe Abbildung 1), wird der Anspruch an das Quality Engineering sich noch erhöhen. Testvorgehen unterscheiden sich je nach Integrationsstufe oder Fokus sehr stark und stellen jeweils eigene Anforderungen an den Test. Eine standardisierte Teststrategie kann daher nur schwer abstrahiert werden. Und somit ist es wichtig, die Kernkompetenzen im Test wieder verstärkt auszubilden, um sinnvolle Ansätze finden zu können.
Abb. 1: Übersicht Vielzahl von Testarten im IoT-Testing
Die folgende Kernkompetenz ist daher auch im Quality Engineering wichtig: die Fähigkeit den Dingen auf den Grund zu gehen und kritisch zu hinterfragen. Denn mit dem Hype um IoT ist nicht immer nachvollziehbar, welcher Mehrwert geschaffen werden soll. Genau hier können erfahrene Tester mithilfe der im Test gewonnenen Erkenntnisse wichtige Impulse liefern und helfen, die Qualität zu verbessern (vgl. Best Practices aus [Acce]).
Zusammenfassung
Das IoT-Testing schließt neben neu zu berücksichtigen Testarten auch neue Vorgehensmodelle und Technologien mit ein, was zu einer deutlichen Zunahme der Komplexität und der erforderlichen Fähigkeiten führt. Diese Herausforderung kann durch einen Tester allein nicht bewältigt werden und muss im „Whole Team“-Ansatz gelöst werden. Voraussetzung ist die richtige Team-Zusammenstellung und die Schaffung geeigneter Organisationsstrukturen.
Umfassende Simulationen stellen eine wichtige Grundlage dar, um IoT-Lösungen aus verschiedenen Blickwinkeln effizient testen zu können. Der Einsatz von Cloud basierten Plattformendiensten tritt in den Vordergrund und ist für das effiziente Testen mit zunehmender Zahl an IoT-Komponenten und -Umgebungen unabdingbar, um auch im Wettbewerb besser bestehen zu können.
Das IoT-Testen als Einzel-Disziplin gibt es kaum, es sind viele verschiedene Facetten und Testarten im Test zu berücksichtigen, wie zum Beispiel Feld-Tests, Sicherheitstests, Interoperabilitätstests, Netzwerktests und funktionale Tests neuer Use-Cases. T-Shaped Profile sind weiter zu entwickeln und auszubauen, um der Komplexität im Testen besser zu begegnen und ein erfolgreiches Quality Engineering etablieren zu können.
Referenzen
[Acce]
S. Coombs, The 7 best practices for IT-OT convergence, Accenture, 15.10.2020, siehe:
https://www.accenture.com/us-en/blogs/industry-digitization/the-7-best-practices-for-it-ot-convergence
[ELC]
H. Bansal, T. Bird, Board Farm APIs for Automated Testing of Embedded Linux, Timesys, 2020, siehe:
https://elinux.org/images/3/3e/ELC-Board-Farm-API-Sony-Timesys-2020-10-27.pdf
[FOSDEM]
S. A. Parker, P. Schroeder, Test Software On Emulated Hardware In Containers... In The Cloud, in: FOSDEM 2020, siehe:
https://archive.fosdem.org/2020/schedule/event/test_software_on_emulated_hardware_in_containers_in_the_cloud/
[netem]
networking:netem [Wiki] (linuxfoundation.org), siehe:
https://wiki.linuxfoundation.org/networking/netem
[TechBeacon]
R. Wilsenach, Two years with no testers: What I learned, TS TechBeacon, siehe:
https://techbeacon.com/app-dev-testing/two-years-no-testers-what-i-learned
[TechTarget]
St. J. Bigelow, B. Lutkevich, What is IT/OT Convergence? Everything you need to know, TechTarget, letzte Änderung August 2021, siehe:
https://searchitoperations.techtarget.com/definition/IT-OT-convergence
