Digitalisierung / Software-Test / Testautomatisierung

Eingebettete Systeme und IoT aus Sicht des Software-Tests

Eingebettete Systeme und IoT-Geräte sind überall. Oft sind sie so gut versteckt, dass man sie lange nicht bemerkt. Vielleicht haben Sie sogar bei Ihnen zuhause schon eines entdeckt? Werfen wir einen näheren Blick darauf: Viele elektrische Haushaltsgeräte (Waschmaschine, Mikrowelle, …), Hausautomationsgeräte (Thermostat, automatische Beleuchtung, …), Systeme im Automobil-Umfeld (ABS, ESP, …), Medizingeräte (Monitoring von vitalen Lebenszeichen, Bildgebende Diagnostik, …), Telekommunikation (Router) sind nur ein paar der bekannteren Vertreter von Geräten mit eingebetteten Systemen. Laut mehreren Prognosen mögen wohl im Jahre 2020 bis zu 30 Milliarden IoT-Geräte im Einsatz sein. Und deren Anzahl wird in den kommenden Jahren nicht sinken. Ein Trend, den man nicht ignorieren soll und kann!

Embedded Systems

Was ist eigentlich ein eingebettetes System und was IoT?

Ein eingebettetes System (Embedded System) ist ein System, das spezialisierte Hardware und Software benutzt, um eine bestimmte Tätigkeit auszuüben. Es ist also keine Applikation auf gängigen Betriebssystemen, mit denen ein normaler Endbenutzer wie ich oder Sie gut vertraut sind.
IoT (Internet of Things ) ist eine Ansammlung von physischen Elektrogeräten (Haushaltsgeräte, Autos, Sensoren, …) die Netzwerk-Konnektivität besitzen, um “empfundene” Informationen auszutauschen und/oder sich gegenseitig übers Netz zu beeinflussen bzw. sich zu steuern. Meistens handelt es sich bei diesen Geräten um eingebettete Systeme.

 

Anwendungen im Bereich von IoT

Einige Beispiele von eingebetteten Systemen habe ich eingangs schon aufgezählt. Damit das Bild vollständig wird, bin ich dies noch für IoT schuldig.

Abgesehen von sehr ähnlichen Anwendungen wie bei eingebetteten Systemen (wenn ohne Netzwerk betrachtet) sind Beispiele von IoT die folgenden:

  • Smart City – z.B. automatische Sammlung von Verkehrsdaten und deren Auswertung oder auch automatisches Management von freien Parkplätzen
  • vernetzte Autos
  • intelligente Einkaufssysteme (z.B. intelligente Kühlschränke)
  • (teils-) automatisierte Steuerung von landwirtschaftlichen Arbeiten – beispielsweise automatische Bewässerung je nach Erdfeuchtigkeit und Wetteraufzeichnungen
  • Smart Grid – intelligente Verwaltung von großen Stromnetzen

 

Was sollen wir testen?

Da ich als Testautomatisierer im Bereich des Web- und API- Testings arbeite, hat mich natürlich interessiert, was beim Testen von eingebetteten Systemen und IoT zu beachten ist.

Wie auch bei “traditionellen” Applikationen, die auf Desktop getestet werden (Webanwendungen, Fettapplikationen), sind die Unit-, Integration-, Subsystem- und Systemtests ein wichtiger Bestandteil der QA. Selbstverständlich ist dies sowohl für eingebettete Systeme als auch für IoT-Geräte der Fall. Außerdem gibt es aber auch andere Aspekte, die man zusätzlich bzw. tiefer testen sollte.

 

Sonderheiten beim Test von eingebetteten Systemen

Software auf eingebetteten Systemen ist physisch viel mehr eingeschränkt als Software auf “Standard-Architekturen” (x86 mit Windows, Linux oder Mac OS). Dies trifft vor allem auf CPU-Geschwindigkeiten und Speicher zu. Daher kann der Testcode (Logs, Assertions) die begrenzte Zeit für die Ausführung der Software wesentlich beeinträchtigen. Darüber hinaus ist es wichtig, dass viel mehr Performance Testing benötigt wird als bei traditioneller Software.

Bei eingebetteten Systemen, die von den Ressourcen her besonders eingeschränkt sind, ist es üblich, ein RTOS (real time operating system) zu verwenden. Dies hat zur Folge, dass spezialisierte Debuggers und andere Werkzeuge benutzt werden müssen, die auf RTOS Rücksicht nehmen.

Eingebettete Systeme können zudem auch Hardware-unabhängig getestet werden. Dies gelingt dank Hardware Emulation, Virtualisierung oder mittels Hardware Stubbs und Hardware Abstraktion. Dies ist auch dann möglich, wenn das ganze eingebettete System noch nicht fertig entwickelt worden ist.

Viele eingebettete Systeme sollen lange Zeiten ohne menschlichen Eingriff stabil laufen oder werden in kritischen Bereichen eingesetzt (z.B. Herzschrittmacher). Daher muss deren Test Ausmaß viel höher sein als bei traditioneller Software.

 

Sonderheiten beim Test von IoT

 

Konnektivität und damit verbundene Probleme

Was die Konnektivität angeht, sollte sich ein Tester mit folgenden Fragen bzw. Aspekten auseinandersetzen:

  • Welche Folgen hat Konnektivitätsschwankung bzw. ein Ausfall während einer Datenübertragung? (Was geschieht mit den Daten? Was passiert mit teilweise ausgeführten Funktionen?)
  • Bei manchen Anwendungen (vor allem im medizinischen Bereich) müssen auch Einflüsse von verschiedenen elektromagnetischen Strahlungen berücksichtigt werden. (z.B. Röntgenstrahlung)
  • Wie kann man testen, ob ein IoT-Gerät online oder offline ist?
  • Welche Untermenge der Funktionalität soll auch ohne Konnektivität unterstützt werden?

 

Energieverwaltung

  • Woher bezieht das IoT-Gerät seinen Strom? Nur aus Stromnetz, hat es auch Batterie oder sorgt es sogar für selbständige Energieversorgung, z.B. durch Solarenergie?
  • Backup kurz vorm geplanten Stromausfall (wenn Batteriestand niedrig wird)
  • Wiederherstellung nach Stromausfall – wie sieht die Datenkonsistenz nachher aus?

 

Sicherheit (Security)

Aktuell schätzt man, dass ungefähr 70-80% aller IoT-Geräten entweder gar nicht oder nur sehr schwach gesichert sind. Dies kann bei einem Hackerangriff auf IoT-Geräte von nicht-nennenswerten (eine IoT- Glühbirne schaltet sich ab) bis hin zu tödlichen Schäden (Übernahme von Steuerung von einem vernetzten Auto) reichen.

Zusätzlich ist zu beachten, ob die Endbenutzer die Daten, die über ihre IoT-Geräte gesammelt und ausgetauscht werden, den IoT Anbietern geben möchten und was diese damit tun.

Weiters könnte die zwar relativ schwache, aber dennoch genügende und zahlreiche Rechenstärke von IoT-Geräten dazu ausgenutzt werden, dass Hackerangriffe indirekt über IoT-Geräte auf anderen Geräten ausgeführt würden (z.B. DOS Attacken).

Wenn sich die Endbenutzer dieser Risiken bewusst werden, wird sich etwas Wesentliches ändern. Dies wird wahrscheinlich aber erst nach ernsten Hackerangriffen auf IoT-Geräte passieren oder als Folge von Konkurrenz, wenn sich der Markt der Sättigung nähern wird.

 

Tests von physischen Eigenschaften von IoT-Geräten

Wie verhält sich das IoT-Gerät nach einer gewissen Anzahl von Benutzungen, (relevant z.B. bei automatischen elektrischen Türschlössern), Vibrationen, zu verschiedenen Temperaturen, beim Regen, unter physischem Druck?

Bei manchen IoT-Geräten sind Tests mit realen Testpersonen sinnvoll oder gar erforderlich – z.B. für implantierte IoT-Geräte, Fitnessgeräte, Straßensensoren (in Parkplätzen, auf Autobahnen) mit realen Autos, usw.

 

Testautomatisierung von IoT

Der Einsatz von Testautomatisierung erweist sich aktuell als eingeschränkt bzw. nicht in allen Fällen von IoT-Geräten als sinnvoll oder praktikabel.

Außerdem gibt es bei den meisten IoT-Geräten eine Vielzahl an unterschiedlichsten Einsatz-Konstellationen (verschiedene Hardware und Software Versionen, Kommunikation über verschiedene Protokolle – IP, Bluetooth, WiFi, …, Kombination mit verschiedene anderen (IoT-) Geräten, usw.).

Damit trotzdem das Ausführen von so viel wie möglichen Tests auf IoT-Geräten möglich ist, kann man sich der schon früher angeführten Möglichkeiten von Hardware Emulation, Virtualisierung und Hardware Stubbs bedienen. Und vielleicht birgt die Zukunft noch andere Möglichkeiten.

 

Zum Abschluss möchte ich noch sagen, dass die Welt in den nächsten Jahren viel ‘intelligenter’ sein wird. Vielleicht werden wir uns in 20-30 Jahren fragen, wie es überhaupt möglich war, ohne all die gängigen Sachen wie automatischen Einkauf von fehlenden Lebensmitteln oder Hausautomation leben zu können. Es bleibt spannend …

Passende Artikel

Kommentare gesperrt.