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.

Risikofaktor nicht sichere Software

Unter nicht-sicherer Software verstehen wir jede Software, die in ein sicherheitsbezogenes Produkt integriert ist, selbst jedoch nicht nach einem passenden Sicherheitsstandard entwickelt worden ist. Damit ist nicht gesagt, dass diese Software fehlerhaft sein muss. Doch ein weniger strenges Design oder fehlende Dokumentation können dazu führen, dass mögliche Seiteneffekte (Ressourcenzugriff, Wartezeiten) nicht erkannt werden. Das Argument, die Komponente sei bisher ohne Probleme eingesetzt worden, reicht im Kontext funktionaler Sicherheit nicht aus. Die Lösung kann entweder sein, die vorhandene Komponente zu überarbeiten und entsprechend zu testen, oder ihre Verwendung so zu steuern, dass die sicherheitsgerichtete Software soweit wie möglich unabhängig ist. Diese Rückwirkungsfreiheit kann nur durch Planung auf Ebene der Softwarearchitektur erreicht werden. Als zusätzliche Sicherheitsmaßnahme müssen Kontrollen umgesetzt werden, die die Annahmen über die nicht-sicheren Teile prüfen und gegebenenfalls eine sichere Reaktion ausführen.

Risikofaktor Umgebung

Software wirkt nur durch die Verbindung mit Hardware auf die physische Umgebung ein. Generell darf sich eine sicherheitsgerichtete Software nie darauf verlassen, dass Hardwareelemente wie Speicher, Sensoren oder Bussysteme korrekt funktionieren. Es ist Aufgabe der Software, einen angemessenen Grad an Diagnosen durchzuführen, und eine passende Reaktion auf eventuelle Probleme zu definieren. Gleiches gilt für die ausführende Umgebung im Mikrocontroller. Hier kann es zu Problemen im zeitlichen Verhalten des Programms kommen, oder auch zu falschen Sprüngen innerhalb der Software. Sofern die Hardware nicht explizit für sicherheitsbezogene Anwendungen freigegeben und somit robust genug ist, muss auch hierfür eine Diagnose umgesetzt werden um Probleme zu erkennen und zu behandeln. In diesen Fällen ist es zwingend notwendig, dass ein entsprechender Informationsfluss an alle Abnehmer der Daten vorgesehen und gewährleistet ist. In einem entkoppelten Softwaredesign wird ein Hardwarefehler oft in einem Modul entdeckt werden, das keine Information über die Auswirkung des Problems und die angemessene Reaktion besitzt. Indem wir passende Schnittstellen und Informationsflüsse einbringen stellen wir sicher, dass die Fehlerinformation dorthin übermittelt wird, wo diese Entscheidung getroffen werden kann.

Fazit

Nach unserer Erfahrung entstehen kritische Softwarefehler am häufigsten durch unvorhergesehene Abhängigkeiten zwischen zwei verschiedenen Teilen der Implementation. Die konsequente Kapselung durch eine modulare Architektur hat sich als effektives Mittel bewährt, dieses Risiko zu vermeiden. Zusätzlich setzen wir konsequent Unittests und methodische Reviews ein, um Implementierungsfehler zu finden.