Deutsche BlogsISO26262Top_5

ISO26262: Fault Injection Test – Braucht man den wirklich?

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.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der
HEICON Homepage.

2 Gedanken zu „ISO26262: Fault Injection Test – Braucht man den wirklich?

  1. Hallo Herr Heininger, hallo Martin,

    besser kann man es nicht beschreiben und man sieht schon in den Antworten, dass das Verständnis oftmals nicht detailliert genug ist in der Automotive-Branche. Ich gebe Dir zu 100% recht und man kann es nicht nachdrücklich genug sagen: Fault Injection Tests sind ein oder der wesentliche Bestandteil der Nachweisführung und sind und müssen als ein Teile der Requirements basierten Tests verstanden werden. Wir sehen bei der Implementierung wie auch bei Anfragen unserer Kunden nach Testsystemen, dass sich dieses Verständnis noch nicht komplett durchgesetzte hat. Hier auch nochmals Dank an Herrn Schacht, der es aus einer automotiven Sicht herrlich beschreibt und auf den Punkt bringt: Requirements basierte Tests werden als ganz konkrete Testfälle mit wohl überlegten Anforderungen wahrgenommen, Fault Injection Tests als „darf halt nix böses passieren“. Aber genau dies ist doch das Wichtigerer und der Zweck der sicherheitskritischen Architektur? Eben nicht nur der Funktion zu folgen, sondern mit ausreichender Sicherheit Fehler zu identifizieren und dann richtig zu reagieren. Top Beitrag !!

    Mit freundlichen Grüßen

    Frank Heidemann / SET GmbH

  2. Guten Tag Herr Heininger,
    herzlichen Dank für Ihre tolle Erklärung, die ich auch sehr gut nachvollziehen kann. Da haben Sie mir mit Ihren Luftfahrtkenntnissen sehr viel weiter geholfen.
    Bisher hatte ich den Unterschied im Bereich Automotive immer so gesehen, dass der Requirements Based Test ein Positiv-Test ist und der Fault Injection Test ein Negativ-Test. Grundsätzlich spricht ja auch nichts dagegen. Da merkt man sicherlich, dass in der Automobilindustrie sehr viel mehr Wert auf die Definition des gewünschten Zustands gelegt wird (Requirements) und der unerwünschte Zustand meistens nur pauschal mit „muss in den sicheren Zustand gehen“ oder „es darf zu keinen Verletzungen des Sicherheitszieles kommen“ umschrieben wird.
    Da dürften die Anforderungen in der Luftfahrt sicherlich noch deutlich höher sein. Aber was wohl außer Frage steht ist, dass der Fault Injection Test eine Untermenge des Requirements Based Tests darstellt.
    Vielleicht werden ja in Zukunft auch die „Negativ-Szenarien“ noch eindeutiger mit entsprechenden Anforderungen beschrieben. Das wäre sicherlich für alle Beteiligten nur von Vorteil!
    Mit freundlichen Grüßen
    Jörg Schacht

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden .