Virtuelles Prototyping Software-Fehlern in sicherheitskritischen Systemen auf der Spur

Sicherheitskritische Systeme im Auto dürfen keine Fehler enthalten. Wie Hersteller das mithilfe virtueller Prototypen und Fehler-Injektion-Tests sicherstellen können, erfahren Sie in diesem Beitrag.

Anbieter zum Thema

Ansys

Für die Automobil-Industrie ist es eine enorme Herausforderung, Fahrzeuge freizugeben, die absolut keine Software-Fehler enthalten. Die Vielzahl von Rückrufen und Re-Designs aufgrund von Software-Problemen zeigt deutlich, wie groß diese Herausforderung ist – und sie ist in den letzten zehn Jahren sogar exponentiell gewachsen. Das hat für die Hersteller auch enorme wirtschaftliche Konsequenzen, da die Kosten eines Fahrzeug-Rückrufs immens sein können, vor allem, wenn das Problem den guten Ruf der Marke schädigen könnte.

Hersteller stecken immer mehr Geld in Tests

Deshalb investieren die Hersteller bereits eine Menge Geld in Software-Tests: Das Testen macht mittlerweile rund 75% der Software-Entwicklungskosten aus. Dieser Anteil steigt weiter – und zwar im gleichen Maße, wie auch die Anzahl der von den Herstellern durchzuführenden Tests immer weiter zunimmt.

Mehr Tests reduzieren nicht immer die Fehler

Einfach nur die Anzahl an Tests stets weiter zu erhöhen, ist allerdings nicht immer der beste Weg zur Verringerung der Defekte. Um die Qualität zu erhöhen, müssen vielmehr die Tests so verbessert werden, dass sie spezielle Fälle prüfen, die im Normalbetrieb nicht auftreten.

Planung und Entwicklung sicherheitskritischer Systeme

Standards wie ISO 26262 adressieren die Planung und Entwicklung sicherheitskritischer Systeme und stellen weitere Anforderungen an den Software-Test. ISO 26262 bietet einen automotive-spezifischen, risiko-basierten Ansatz auf der Grundlage von Automotive-Safety-Integrity-Levels (ASIL). Er spezifiziert die Anforderungen und empfohlenen Methoden für die Validierung der Sicherheitsebenen, darunter auch Fault-Injection-Tests.

Mit der Fehler-Injektion lässt sich ermitteln, ob die Antwort eines Systems der Spezifikation bei Vorliegen von Fehlern entspricht. Sie unterstützt Systemingenieure dabei, die Auswirkung von Fehlern auf das Verhalten des Zielsystems zu verstehen. Sie hilft ferner, die Effizienz von Fehlertoleranz-Mechanismen zu beurteilen, und ermöglicht dem Design-Team, Fehler während der Entwurfs- und Implementierungsphase zu vermeiden.

Mit Fehler-Injektion lassen sich auch Ausnahmefälle erfassen

Die Fehler-Injektion kann die Testabdeckung von Sicherheitsmechanismen (auf Systemebene) erhöhen, indem Ausnahmefälle erfasst werden, die im Normalbetrieb nur schwer zu aktivieren sind. Sie wird außerdem empfohlen, wann immer ein Hardware-Sicherheitsmechanismus definiert wird, um sein Verhalten im Fehlerfall zu analysieren, und wo zufällige Fehler, die Software- und Hardware-Komponenten beschädigen können, injiziert werden müssen, um Sicherheitsmechanismen zu testen.

Fehler können software- oder hardwarebedingt sein

Fehler lassen sich als Software- oder als Hardware-Fehler kategorisieren. Fehler innerhalb der Hardware-Kategorie sind:

• permanent (ausgelöst durch Beschädigung einer Komponente),

• transient (ausgelöst durch bestimmte Umgebungsbedingungen, auch als Soft-Error bezeichnet) oder

• sporadisch (verursacht durch instabile Hardware).

Die Tabelle vergleicht vier herkömmliche Fehler-Injektionstechniken durch Betrachtung einiger der wichtigsten Faktoren. Diese umfassen:

• die Art der Fehler, die aktiviert werden können (Fehler-Injektionspunkte),

• die Fähigkeit, permanente Fehler zu modellieren,

• die Beeinflussung, oder wie die Fehler-Injektion den ursprünglichen Ausführungsablauf des Systems ändert,

• die Beobachtbarkeit, welche definiert, wie gut die durch den Fehler ausgelösten Reaktionen bzw. Ereignisse erkannt und aufgezeichnet werden können,

• die Kontrollierbarkeit, welche die Präzision hinsichtlich des Zeitpunkts und des Ortes der Fehler-Injektion bestimmt,

• die Reproduzierbarkeit, oder die Fähigkeit, den Test in einer deterministischen Weise zu wiederholen,

• und die Geschwindigkeit, welche zum Teil die Komplexität und die Dauer der Test-Szenarien definiert.

(ID:44908852)