Softwarequalität im IoT Warum Softwaretests für das IoT wichtig sind

Autor Arthur Hicken

In allen IoT-Systemen arbeiten die eingesetzten Komponenten als ganzheitliches System zusammen. Das macht das Simulieren ihrer komplexen Interaktionen, das Reproduzieren der einzelnen Komponenten und das Testen der Funktionalität sowie der nicht funktionsbezogenen Anforderungen überaus schwierig.

Anbieter zum Thema

Fliegen im Simulator: Service Virtualization ermöglicht eine simulierte Testumgebung, um Software unter simulierten Konditionen zu prüfen.
Fliegen im Simulator: Service Virtualization ermöglicht eine simulierte Testumgebung, um Software unter simulierten Konditionen zu prüfen.
(Bild: gemeinfrei/Pixabay / CC0 )

Weil die Konnektivität von IoT-Umgebungen in der Regel über ein öffentliches Netzwerk erfolgt, haben Hersteller von IoT-Geräten keine Kontrolle über mehrere Eigenschaften:

  • Sicherheit: Auch, wenn man die Sicherheit auf der Software-Ebene kontrollieren kann, ist das Netzwerk möglicherweise Attacken ausgesetzt.
  • Zuverlässigkeit: Zwar lässt sich die Selbstheilungsfähigkeit der Software kontrollieren, aber die Verfügbarkeit des Netzwerks liegt möglicherweise außerhalb der Einflusssphäre.
  • Ausmaß: Man kann die Ausdehnung der internen Infrastruktur überprüfen, nicht aber die des öffentlichen Netzwerks.

Also muss der Gerätehersteller sicherstellen, dass die soeben skizzierten Softwaremerkmale auf der Komponenten-Ebene einen gründlichen Test unterlaufen. Außerdem sollten Szenarien zur Behandlung von Fehlern ausgearbeitet und geprüft werden, die Ereignisse außerhalb des Systems auslösen. Hilfreich dafür sind sowohl die Service-Virtualisierung als auch API-Tests.

Ein System aus mehreren Systemen

Eine IoT-Umgebung kann ein System sein, das seinerseits Teil eines übergeordneten Systems ist, etwa ein vernetztes Auto als eine Komponente mit Internet-Anbindung. Innerhalb des Autos gibt es wiederum viele kleinere Komponenten, die entweder miteinander interagieren oder unabhängig mit dem Internet verbunden sind.

Die Unterhaltungselektronik im Fahrzeug, OnStar oder Ähnliches lässt sich direkt mit dem Internet vernetzen, während andere Komponenten dagegen an den CAN-Bus angeschlossen sind. Mit diesem kommunizieren etwa die Lenkungs- und Bremskomponenten, um gegebenenfalls auftretende Problemen nach außen zu melden. Hierdurch entsteht ein potenzielles Sicherheitsproblem, zudem können potenzielle Konflikte auftreten, wenn mehrere Systeme ihre Daten über den CAN-Bus übertragen. Darum müssen die Tests auf verschiedenen Ebenen erfolgen, wie zum Beispiel:

  • Diskrete Komponenten,
  • Komponenten im Kontext eines Subsystems,
  • Komponenten im Kontext eines übergeordneten Systems.

IoT-Systeme stellen einen potenziellen Ausfallpunkt in sicherheitskritischen Systemen z.B. in der Automobiltechnik, in der Luftfahrt usw. dar. Arbeiten Entwickler an einem IoT-Projekt in einem sicherheitskritischen Markt, sollten sie das Risikoniveau jeder einzelnen Komponente bewerten, um den Umfang der erforderlichen Tests zu bestimmen. Hier gibt es zwei Aspekte - nämlich das mit dem Ausfall einer Komponente verbundene Risiko und die Wiederherstellbarkeit.

Sicherheitskritische Überlegungen

Die meisten Autos lassen sich auch dann noch bedienen, wenn die Servolenkung oder der Bremskraftverstärker ausgefallen sind. Allerdings werden immer mehr mechanische Verbindungen zugunsten von Control-by-wire-Technologien weggelassen, um die allgemeine Effizienz des Systems zu verbessern. Ein Ausfall des Bremssystems ist katastrophal, jedoch wäre in Systemen ohne Control-by-wire-Technologie immer noch eine Rückfallebene vorhanden.

Wechselnde Risikobewertungen gibt es auch bei Flugsteuerungssystemen (Flight Control System – FCS) von Flugzeugen. Hier stellt der Ausfall eines FCS ein sicherheitskritisches Risiko gemäß SIL 1 dar, ist also ein katastrophaler, allerdings behebbarer Ausfall, denn es gibt ein Hydrauliksystem, mit dem der Pilot das Flugzeug in der Luft halten kann.

In einigen Systemen aber sind die vom FCS angesprochenen Steuerflächen so kritisch, dass ein Ausfall des FCS ein Risiko mit SIL 0 darstellt. So hat beispielsweise die Komplexität der Steuerflächen mittlerweile ein Ausmaß erreicht, das eine manuelle Steuerung ohne das FCS unmöglich macht. Ein solcher Ausfall wäre somit nicht behebbar.

(ID:44803614)