Wenn Softwarefehler Safety gefährden
Moderne Steuersysteme setzen ihre Funktionalität zu großen Teilen durch Software um. Die Konsequenz für die funktionale Sicherheit ist, dass Softwarefehler ein wesentliches Risiko darstellen.
Softwarefehler zu vermeiden bedeutet vor allem, dass wir in der Entwicklungsphase das Verhalten des Programms für jede Situation vorhersagbar machen müssen. Software ist ein reines Konzept, dass nur in Verbindung mit mechanischen oder elektronischen Elemente – kurz ‚Hardware‘ – wirken kann. Daher enthält Software ausschließlich systematische Fehler, bei denen eine bestimmte Kombination von Stimulationen zu einem falschen Verhalten führt. Diese Fehler entstehen ausschließlich während der Entwicklungsphase und müssen folglich auch dort vermieden werden. Hardware kann neben den systematischen Fehlern auch zufällige Fehler enthalten, beispielsweise den bekannten Wackelkontakt.
Zwei Typen von Fehlfunktionen
In unserer Praxis unterscheiden wir zwei grundlegende Typen von Softwarefehlern. Zum einen sehen wir die klassischen Programmierfehler, beispielsweise eine nicht korrekt umgesetzte Rechenformel. Dieser Fehlertyp ist meistens in einer einzelnen Softwarefunktion isoliert, und kann durch systematische Unittests frühzeitig erkannt werden. Als zweiten und kritischeren Fehlertyp sehen wir, dass das Zusammenspiel der einzelnen Teile der geplanten Funktionalität zu unerwarteten Ergebnissen führt. Fehler dieses Typs sind in der Regel schwieriger zu finden und auch aufwendiger zu beheben. Kennzeichnend ist hier, dass jeder Teil der Software für sich korrekt und wie spezifiziert arbeitet, und das Problem nur durch die Integration der Module entsteht. In diese Kategorie fallen insbesondere Ressourcenkonflikte und Timingfehler. Diese lassen sich nicht durch die Betrachtung eines einzelnen Moduls entdecken, und sind nur im integrierten System sichtbar. Ein solcher Fehler wäre zum Beispiel, dass die Abschaltung im Fehlerfall beim gleichzeitigen Speichern des Betriebsstundenzählers wegen des Zugriffs auf eine gemeinsame Ressource zu lange braucht. Unsere Softwarearchitekten müssen daher insbesondere sämtliche Interaktionen der einzelnen Softwaremodule untereinander berücksichtigen und planen. Eine Übersicht über Konzepte für robuste Architekturen, die dieses Risiko minimieren, wurde in [Christian Gießelbach / Sascha Körner: ‚SW-Architektur: unsichtbarer Qualitätsfaktor‘, Embedded Design, Ausgabe 6/2015] vorgestellt.
Risikofaktor später Anforderungen
Es ist eine Binsenweisheit, dass man nur Funktionalitäten umsetzen kann, die man auch kennt. Für eine robuste Architektur ist es unerlässlich, den vollständigen Funktionsumfang zu kennen. Nur so lassen sich die angesprochenen Interaktionsprobleme effektiv vermeiden. Im Gegensatz zur Hardware wird ein Designfreeze, ab dem keine funktionalen Änderungen mehr vorgenommen werden, in Software meist weniger konsequent eingehalten. Spät hinzugefügtes Verhalten birgt jedoch immer die Gefahr, dass neue Schnittstellen geschaffen werden müssen, die mit dem ursprünglichen Konzept nicht vereinbar sind. Dies begünstigt die Entstehung ungeplanter und damit potenziell kritischer Seiteneffekte. Dieses Risiko lässt sich nur bedingt durch Testen reduzieren. Wir wenden zusätzlich formelle Reviews und Inspektionen an, wenn nachträglich Funktionalität ergänzt werden muss.
