Digitalisierung

Fehlertoleranz in IoT-Systemen

Meine Frau und ich haben uns letztes Jahr ein etwa 100 Jahre altes Haus gekauft. Wir waren von dem Charme der verwinkelten Räume, den knarrenden Holztreppen und den gemütlichen Kaminen begeistert. Und obwohl ich versuche, die alte Bausubstanz so gut wie möglich zu erhalten, möchte ich auch auf die neuesten technischen Spielereien, Gimmicks und Gadgets nicht verzichten – und dazu gehört natürlich auch das Internet of Things. Eine meiner ersten Renovierungsmaßnahmen war daher die Installation eines intelligenten Lampensystems.

IoT-System Lampen

 

Das System

Das Licht lässt sich damit zentral im gesamten Haus steuern. Helligkeit und Farbe können angepasst werden und auf „Events“ reagieren – das Licht wird beispielsweise abgeschaltet, wenn alle das Haus verlassen haben, und es kann morgens, indem es langsam heller wird, ein entspanntes Aufstehen unterstützen. Per Lichtfarbe könnte man sich sogar das Wetter anzeigen oder über neue E-Mails informieren lassen.

Grob vereinfacht, lässt sich der Aufbau dieses IoT-Systems folgendermaßen zusammenfassen: Unsere Gadgets – in meinem Fall zehn Glühbirnen – werden über einen oder mehrere Hubs gesteuert. Dieser Hub ist mit unserem Router verbunden und könnte, sollte einmal die Internetverbindung ausfallen, auch direkt über den Laptop o. a. angesteuert werden. Bei einem externen Zugriff von unterwegs nutze ich die App auf meinem Mobilgerät, um mit dem Server des Anbieters zu kommunizieren. Dieser leitet meine Steuerbefehle anschließend an mein Heimnetz weiter – damit kann ich über den Router und den Hub schließlich auf die einzelnen Lampen zugreifen.

 

Aufbau IoT-System

Abb. Aufbau eines IoT-Systems

 

Was kann schon schiefgehen?

Derart viele Schnittstellen und insbesondere die potenzielle Vielfalt der Systemkonfigurationen machen diesen Aufbau jedoch fehleranfällig. Auf Anbieterseite ist mit Fehlern zu rechnen, die wir auch aus anderen Systemen kennen – einzelne Services können überlastet sein oder gänzlich ausfallen, die Server können schlecht oder nicht erreichbar sein und es können Probleme in der Cloud oder unerwartete Bugs auftreten. Die Internetverbindung zwischen Kunde und Anbieter könnte auch einfach langsam, instabil oder überlastet sein.

Und auch auf Seiten des Kunden sind zahlreiche Szenarien denkbar, von einem physischen Defekt einer Glühbirne, einem Stromausfall, schlecht konfigurierten Firewalls und anderen Inkompatibilitäten bis hin zu einem manuellen Ausschalten der Lampen, wenn gerade keine Internetverbindung besteht.

Wie reagiert mein IoT-System in diesem Fall? Was zeigt mir die App an, wenn ich unterwegs bin und die Lampe zu Hause manuell ausgeschaltet wurde? Was passiert, wenn keine WLAN-Verbindung besteht und der Nutzer fünf Mal auf den Ein- und Ausschaltbutton in der App drückt, weil eine Lampe nicht reagiert? Schaltet sich die Lampe fünf Mal ein und aus, sobald die Verbindung wieder hergestellt ist?

Diese und andere Fragen sollten IoT-Anbieter proaktiv beantworten – denn die Frage ist nicht, ob Fehler auftreten, sondern wann und wie sie auftreten. Und wie das System darauf reagieren soll.

 

„Failure is not an option, it’s a certainty.“

 

Fehler testen

Konventionelle Testansätze für komplexe Systeme verfolgen häufig eine von zwei Strategien: Man hält den Testaufwand so gering wie möglich und hofft darauf, gleichzeitig so viele Fehler wie möglich zu finden und zu beheben. Oder man investiert hohe Summen in den Nachbau von Systemkonfigurationen, um ein möglichst stabiles Produkt zu gewährleisten. Es liegt jedoch auf der Hand, das beide Ansätze aus unternehmerischer und wirtschaftlicher Perspektive langfristig nicht zielführend sind.

Eine Testinfrastruktur kann niemals alle potenziellen Geräte-, Netzwerk- und Anwendungskombinationen der Endnutzer abdecken und gerade im IoT-Bereich müssen Anbieter auf Mindestanforderungen und Einschränkungen der kompatiblen Geräte soweit wie möglich verzichten, wenn sie einen hohen Marktanteil anstreben. Wenn ich die Anzahl der nutzbaren mobilen Endgeräte, die Router- und Firewallkonfigurationen, die Systemsoftware usw. so weit beschränke, dass ich die Stabilität meines IoT-Produkts zuverlässig vorhersagen kann, reduziere ich damit auch meine potenzielle Zielgruppe.

Dabei gilt es auch zu bedenken, welche Rolle die jeweilige IoT-Anwendung im Leben der Endnutzer spielt. Der Ausfall der Appsteuerung einer Glühbirne lässt sich durch das manuelle Ein- und Ausschalten der Lampe einfach umgehen. Bei einem vernetzten Kühlschrank oder Herd, die nicht wie vom Nutzer erwartet reagieren, kann es sich jedoch im Haushalt des Kunden schnell um „kritische Systeme“ handeln, deren Ausfall mehr als nur eine Unannehmlichkeit darstellt.

 

Isolation durch simulierte Services

Simulierte Services, eine Art „Mocking auf Protokollebene“ können hier Abhilfe schaffen und eine kosteneffiziente Fehlerfindung in frühen Entwicklungsstadien ermöglichen. Einzelne Systeme können dabei mit möglichst geringem Aufwand isoliert und externe Fehlerquellen nachgestellt werden. (Lesen Sie mehr zum Thema auch im Artikel „Mit Service Virtualisierung Grenzen durchbrechen“ von Dominik Schildorfer).

In der Kommunikation zwischen dem mobilen Endgerät des Nutzers und dem Unternehmensserver können wir beispielsweise Ausfälle oder langsame und instabile Internetverbindungen simulieren. Im Haushalt des Kunden lassen sich restriktive Firewalls nachstellen, unterschiedliche Verbindungsgeschwindigkeiten oder sogar Komplettausfälle testen oder Updates simulieren. Und auf Ebene der Endkomponenten können wir physische Defekte und Ausfälle, manuelle Eingriffe oder langsame Reaktionszeiten schnell, mit minimalen Kosten und ohne Verwendung von tausenden echten Glühbirnen testen.

Kurz gesagt, wird es möglich, das „Untestbare“ zu testen. Simulierte Services ermöglichen eine schnellere Entwicklung, ein früheres Aufdecken von Fehlern und damit eine erhebliche Kostenreduktion. Dies steigert nicht nur die Effizienz und wirtschaftliche Rentabilität, sondern sorgt auch für zufriedenere Kunden.

 

Passende Artikel

Kommentare gesperrt.