Grenzen der Testbarkeit von Embedded-Software

Anbieter zum Thema

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

Syslogic GmbH

Mixed Mode GmbH

In der Embedded-Welt kann Hardware zum Teil, aber nie vollständig simuliert werden. Nicht vollständige Testbarkeit tritt bei Grenzzuständen auf, im Timing oder im Interruptverhalten. Das integrierte Gesamtsystem ist eine Herausforderung, wenn es um den Test in Grenzsituationen geht. Als Beispiel dient ein Hardware-Watchdog, der bei Unterspannung für einen Reset des Systems zuständig ist. Nicht selten hängt am übergeordneten Controller eine Routine, die in den Millisekunden vor dem Reset noch einen Logeintrag machen soll. Im Gutfall ist die dafür zur Verfügung stehende Zeit ausreichend. Die Zeit wurde statistisch ermittelt und Toleranzen unterworfen.

Das System in der Grenzsituation zu beobachten ist sehr eingeschränkt; eine softwaregestützte Simulation des Hardware-Watchdogs ist zwar möglich, aber letztlich – wie beim eingangs erwähnten Kernkraftwerk – nur von bedingter Aussagekraft. Es kann kaum nachvollzogen werden, ob der Schreibmechanismus in den letzten Millisekunden wirklich noch vollständig ausgeführt wird. Hinzu kommen variable physikalische Parameter, wie sie im gesamten Verkehrswesen von Zug, Flug, Schiff bis zum Auto auftreten, bei Brandschutzeinrichtungen oder Bezahlautomaten.

Auch gewisse fertigungsbedingte Schwankungstoleranzen bei den Ansprechzeiten des Bauelements wirken sich aus. Außerdem müssen bei Standard-Hardwarebauteilen Funktionalitäten in die Software verlegt werden, die besser von der Hardware übernommen würden.

Die fünfte Grenze resultiert aus zu wenig Zeit für eine sachgerechte Entwicklung. Es gab einmal eine Software – Namen werden nicht genannt –, die verschiedene Steuergeräte problemlos unterstützte. Im Lauf der Jahre haben sich in einigen Steuergeräten Protokollfehler angesammelt. Statt sie beim Entstehen zu fixen, wurden in der Software Workarounds eingebaut. Das Ergebnis: der Aufwand für den Freigabetest der Software wuchs stetig an, da tatsächlich jeder Steuergerätetyp einzeln getestet werden musste.

Schnittstellen unbedingt sauber definieren

Wenn vieles reibungslos funktioniert, so ist das das Ergebnis hervorragender und sorgfältiger Arbeit. Trotzdem sollte man sich gelegentlich der ineinandergreifenden Cluster von logischen Komplexitäten bewusst sein, die uns in stetig steigendem Maße umgeben und von denen wir immer abhängiger werden. Es zeigt die enorme Wichtigkeit sauberer Schnittstellendefinitionen und Implementierung der Vorgaben.

Aus Sicht des Testers wird klar: selbst bei knappen Budgets dürfen keine Kürzungen bei Testverfahren angesetzt werden, auch keine indirekten. Denn steigt die Komplexität der zu testenden logischen Systeme, dann bedeutet schon eine nicht damit Schritt haltende Erweiterung des korrespondierenden Testprozesses eine indirekte Kürzung. Nicht nur das jeweilige Produkt muss weiterentwickelt werden, sondern auch die zugehörigen Testverfahren.

* Dr. Richard Kölbl, Erwin Pschernig und Wolfram Gettert arbeiten beim Software-Spezialisten Mixed Mode in Gräfelfing bei München.

(ID:36418840)