Die ISO 26262 definiert als eine Test Methode jeweils auf System- Integrations- und Unit-Test Ebene den Fault Injection Test (ISO 26262-4 [System] Tabellen 5, 8, 10, 13, 15, 18; ISO 26262-5 [Hardware] Tabelle 11;  ISO 26262-6 [Software] Tabellen 10, 13).
Diese Methode hat ganz sicher einen großen Anteil bei der Implementierung eines möglichst fehlerfreien und damit sicheren Systems. Mir geht es nachfolgend um eine möglichst effiziente Implementierung dieser Test Methode in der Praxis. Dabei möchte ich insbesondere die Vorgehensweisen in der Luftfahrt mit denen in der Automobilbranche vergleichen.

Automobilbranche:

Die ISO 26262-4 [System] beschreibt den Fault Injection Test wie folgt:
The test uses special means to introduce faults into the item. This can be done within the item via a special test interface or specially prepared elements or communication devices. The method is often used to improve the test coverage of the safety requirements, because during normal operation safety mechanisms are not invoked.
In der ISO 26262-6 [Software] wird der Test weiter wie folgt definiert:
Fault Injection Test includes injection of arbitrary faults in order to test safety mechanisms (e.g. corrupting software or hardware components, corrupting values of variables, by introducing code mutations, or by corrupting values of CPU registers).

Folgende Punkte sind mir für die nachfolgende Betrachtung dabei von besonderer Bedeutung:
1) Requirements based Tests und Fault Injection Tests werden als zwei (unterschiedliche?) Testmethoden behandelt.
2) Die ISO 26262 geht davon aus, dass man diese Tests braucht um die Test Coverage der Safety Requirements zu erhöhen.
3) Mit diesen Tests werden willkürliche (=arbitrary) Fehler ins System eingebracht um die Safety Mechanismen die in der Software codiert wurden zu prüfen.
Nun wollen wir einen kurzen Blick in die Luftfahrtbranche werfen. Wie geht diese Branche mit dem Thema Fault Injection Test um?

Luftfahrtbranche:

In den zur ISO 26262 vergleichbaren Normen DO-178C [Software], DO-254 [Hardware] und
ARP 4754 [System] der Luftfahrtbranche sucht man diesen Begriff zunächst einmal vergeblich. In der Luftfahrt werden dagegen die Begriffe „Normal Range Test Cases“ und „Robustness Test Cases“ verwendet. Der DO-178C bringt diese beiden Begriffe in Verbindung mit dem Requirements basierten Testen. Folgende 2 Fragen spielen in jedem sicherheitskritischen Luftfahrtprojekt eine ganz wesentliche Rolle:
1) Sind die Requirements mit Normal Range Test Cases geprüft
2) Ist der Source Code robust gegen die High-Level Requirements?

In der Luftfahrt spielen die Requirements eine sehr große Rolle. Es wird verlangt, dass der gesamte Source Code durch passende Requirements abgedeckt wird. Dies schließt den Code zum Verhalten des Systems im Fehlerfall, ausdrücklich mit ein. Bezogen auf Safety-Aspekte, spielt die korrekte Funktionsweise genau dieses Source Code Teils eine sehr wichtige Rolle.

Die Requirements werden über Normal Range und Robustness Test Cases getestet. Wobei die Robustness Test Cases darauf abzielen die Requirements selber in Frage zu stellen und ggf. Lücken in den Requirements zu finden. So unbestritten wichtig die Robustness Tests sind, so wichtig ist auch zu erkennen, dass die Festlegung, ob ein entsprechender Test „Passed“ oder „Failed“ ist, nicht mehr ohne weiteres möglich ist. In nicht wenigen Fällen fehlt nämlich das erwartete Systemverhalten. Im Idealfall setzen sich Tester und Systemspezialisten zusammen und diskutieren die problematischen Fälle. Das Ergebnis der Diskussion ist dann immer eine Festlegung des korrekten Systemverhaltens. Eine Dokumentation davon bedeutet die Definition/Änderung von Requirements.
Wenn man diesem Vorgehen folgt, führt dies dazu, dass auch die relevanten Robustness Test Cases Requirements abprüfen.
Wenn man der Logik der Luftfahrt folgt, dann stellen Fault Injection Tests sowohl Normal Range Tests als auch zum Teil Robustness Tests dar. In jedem Fall aber, gibt es für jeden Test ein entsprechendes Requirement.

Schlussfolgerungen:

Wenn wir nun mit der Luftfahrtbrille auf die Fault Injection Tests in der ISO 26262 blicken, dann ergeben sich daraus spannende Erkenntnisse:

1. Ein eindeutiges Testergebnis, auch das eines Fault Injection Tests, kann man nur bekommen, wenn das erwartete Ergebnis bekannt ist. Requirements definieren dieses erwartete Ergebnis. Wenn man dieser Logik folgen würde, stellt sich die Frage: wo liegt der Unterschied in der ISO 26262 zwischen einem Fault Injection Test und einem Requirements basierten Test? Dieser Logik folgend ist der Fault Injection Tests eine Untermenge der Requirements basierten Tests.
2. Wenn Fault Injection Tests nicht vorhanden sind, fehlt definitiv Test Coverage von Safety Requirements. Jedes Safety Requirement muss aber zu 100% verifiziert werden. Aus dieser Sicht stellen Fault Injection Tests keine Besonderheit dar.
3. Aus Sicht der Luftfahrt führen auch „willkürliche“ Fehler in einem System immer zu einem definierten Systemverhalten. In dieser Definition wird „willkürlich“ gleichgesetzt mit „ein Fehler aus einer definierten (=bekannten) Liste von Fehlern“.

Der Fault Injection Test ist am Ende schlicht eine Teilmenge aller Requirements basierten Tests. Wobei schon festgehalten werden soll, dass es sich hierbei um eine wichtige Teilmenge handelt. Diese Tests stellen erfahrungsgemäß einen erhöhten Anspruch an die Tester, das Testsystem und auch an die Requirements.
In der Automobilbranche ist die praktische Anwendung von Requirements Engineering eine Disziplin die erst in den letzten Jahren in der Breite ausgerollt wurde. In vielen aktuellen Projekten die eine ASIL Einstufung haben, ist die Anzahl der Requirements noch nicht sehr hoch. Die ISO 26262 hatte sicher auch diesen pragmatischen Aspekt im Blick, als der Fault Injection Test definiert wurde. Je weniger Requirements vorhanden sind, je mehr Sinn macht die Definition einer solchen Testmethode.
Ein weiterer Aspekt ist, dass Fault Injection Tests natürlich in einer sehr frühen Projektphase gezielt zur Validierung der angedachten Safety Mechanismen gemacht werden können. Die obige Argumentation der Luftfahrtbranche, ist stark geprägt von der Nachweisführung gegenüber einer Zertifizierungsbehörde. Dabei kommen oft die frühen Projektephasen eher etwas zu kurz.
Zusammenfassend, lässt sich sagen, dass Fault Injection Tests eine wichtige Testmethode darstellen. Richtig zur Geltung kommt die Methode aber nur, wenn Requirements für das erwartete System- bzw. Softwareverhalten vorhanden sind.

Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).