Suchen

Virtuelles Prototyping Software-Fehlern in sicherheitskritischen Systemen auf der Spur

Autor / Redakteur: Victor Reyes * / Dipl.-Ing. (FH) Thomas Kuther

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.

Firma zum Thema

Sicherheitskritische Systeme im Automobil: mithilfe von virtuellen Prototypen lässt sich sicherstellen, dass sie keine Fehler enthalten
Sicherheitskritische Systeme im Automobil: mithilfe von virtuellen Prototypen lässt sich sicherstellen, dass sie keine Fehler enthalten
(Bild: Snopsys)

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).

Tabelle: Vergleich vier herkömmlicher Fehler-Injektionstechniken durch Betrachtung einiger der wichtigsten Faktoren
Tabelle: Vergleich vier herkömmlicher Fehler-Injektionstechniken durch Betrachtung einiger der wichtigsten Faktoren
(Bild: Synopsys)

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.

Hardwarebasierte Fehler-Injektion mit und ohne Kontakt

Typischerweise wird das Test-Team die hardwarebasierte Fehler-Injektion mit Kontakt nutzen, um Fehler an den Ein-/Ausgabeschnittstellen der Electronic-Control-Unit zu injizieren, sowie auch die Variante ohne Kontakt, um Soft-Errors zu aktivieren – zum Beispiel um eine Speicherverfälschung aufgrund von Strahlung oder elektromagnetischer Einflüsse zu simulieren.

Techniken mit Kontakt

Die Techniken mit Kontakt können permanente Fehler modellieren, und sie sind nicht-beeinflussend (wenngleich bei falscher Anwendung das Risiko einer Beschädigung besteht).

Techniken ohne Kontakt

Die Techniken ohne Kontakt sind mehr auf transiente Fehler fokussiert und sind ebenfalls nicht-beeinflussend. Jedoch besteht nur wenig Kontrollpotenzial hinsichtlich des Zeitpunkts und des Ortes der Fehler-Injektion.

Softwarebasierte Fehler-Injektion ist beeinflussbar

Softwarebasierte Fehler-Injektionstechniken erlauben die Injektion von Fehlern lediglich an Stellen, die durch Software zugänglich sind, also Speicher und Register für speicherabgebildete Peripheriekomponenten. Das bedeutet, dass damit nur transiente Fehler modelliert werden können. Das Hauptproblem softwarebasierter Fehlerinjektionstechniken besteht darin, dass sie beeinflussend sind: Weil der Ingenieur zur Injektion eines Fehlers den Software-Binärcode modifizieren muss, besteht die Gefahr, dass sich das Testobjekt im Vergleich zur Produktionsversion unterschiedlich verhält.

Nutzung realer Hardware schränkt die Beobachtbarkeit ein

Die zuvor beschriebenen Techniken nutzen reale Hardware, was die Beobachtbarkeit einschränkt. Sie sind kontrollierbar und reproduzierbar. Weil sie aber reale Hardware nutzen, sind sie niemals vollständig deterministisch. Alle drei Techniken laufen schnell genug (in Echtzeit), um komplexe Software-Stacks zu bewältigen.

Voller Zugriff auf alle Hardwareelemente des Systems

Die simulations-basierte Fehlerinjektion – ausgeführt auf Gatter- oder Register-Transfer-Ebene – hat den Vorteil vollständiger Zugriffsmöglichkeiten auf alle Hardwareelemente des Systems. Sie ist nicht beeinflussend, bietet aber volle Beobacht- und Kontrollierbarkeit und ist deterministisch. Allerdings sind die Simulationen extrem langsam, was sie bei komplexeren Szenarien unbrauchbar macht.

Virtuelle Prototypen als Software-Abbild der Hardware

Ein virtueller Prototyp ist ein Software-Modell, welches die Hardware nachbildet. Entwicklerteams können einen virtuellen Prototypen verwenden, um die digitalen Aspekte einer Mikrocontroller-Einheit, einer Electronic-Control-Unit (ECU) oder gar eines kompletten ECU-Netzwerks zu modellieren, und die Simulation auf einem Desktop-PC ausführen. Virtuelle Prototypen führen denselben Binärcode wie die reale Hardware aus. Weil der virtuelle Prototyp ein Soft-Modell ist, können Softwareteams bereits Monate vor der Verfügbarkeit des tatsächlichen Hardware-Bausteins darauf zugreifen.

Virtuelle Prototypen stellen Umgebungen dar

Virtuelle Prototypen geben Entwicklungsteams mehr als nur Software-Modelle zur Hardware-Simulation; sie stellen Umgebungen dar, die ihnen das Debuggen und Analysieren von Hardware-/Software-Interaktionen erlauben. Sie bieten auch komplette Sichtbarkeit der internen und externen Register und Signale, ermöglichen die volle Kontrolle über die Programmausführung und sind zudem nicht-beeinflussend.

Die gesamte Systemausführung lässt sich einfrieren

Entwickler können mittels virtueller Prototypen die gesamte Systemausführung zu einem beliebigen Zeitpunkt einfrieren – sogar bei Multicore-Hardware – um interne Werte auszulesen oder zu modifizieren. Fortgeschrittene Analysefunktionen lassen sie außerdem die Software (auf Anwendungsebene) mit Hardware-Ereignissen korrelieren, die Code-Coverage ermitteln, Fehler-Injektion ausführen, sowie die Simulationen mittels Skripts automatisieren.

Virtuelle Prototypen integrieren sich nahtlos in vorhandene Software-Toolketten und verbinden sich mit externen Tools von Drittanbietern zwecks vollständiger „Hardware-in-the-Loop“- und „Rest-of-Bus“-Simulationen. Entwickler können die Simulationsmodelle auf einfache Weise einsetzen und skalieren. Virtuelle Prototypen lassen sich über eine weltweit operierende Organisation hinweg leicht gemeinsam nutzen, archivieren und einsetzen.

Fehler-Injektion mit Virtual-Prototyping-Technologie

Virtuelle Prototypen ermöglichen Anwendern, sowohl auf sämtliche interne Hardwareelemente eines Designs – Speicherinhalte, Register, Signale – als auch auf spezifische Fehlertoleranz-Mechanismen wie fehlerkorrigierende Codes bei Speichern zuzugreifen, vorausgesetzt, dass diese Funktionen modelliert wurden. Anwender können virtuelle Prototyp-Modelle ohne großen Aufwand erstellen, indem sie die Funktionalität des Blocks auf einer abstrakteren Ebene spiegeln.

Virtuelle Prototypen können sowohl transiente als auch permanente Fehler modellieren. Anwender können Fehler über Mechanismen des Simulationsframeworks injizieren, ohne die eingebetteten Software-Modelle modifizieren zu müssen. Ferner sind sie in der Lage, alle in den Systemen modellierte Hardware- und Software-Ereignisse zu visualisieren und zu verfolgen. Visualisierungstools stellen die Hardware- und Softwareausführung und –ereignisse im selben Fenster und über der gleichen Zeitachse dar, so dass Anwender sie korrelieren und den Zusammenhang zwischen Ursache und Auswirkung eines Fehlers nachvollziehen können.

Elemente der Umgebung zur Fehler-Injektion

Umgebung zur Fehler-Injektion: Sie umfasst ein Zielsystem, einen Fehler-Injektor, den Workload-Generator, einen Monitor zur Rückkopplung von Informationen vom Zielsystem und der Datenerfassung und -analyse sowie einen Controller.
Umgebung zur Fehler-Injektion: Sie umfasst ein Zielsystem, einen Fehler-Injektor, den Workload-Generator, einen Monitor zur Rückkopplung von Informationen vom Zielsystem und der Datenerfassung und -analyse sowie einen Controller.
(Bild: Synopsys)

Eine grundlegende Umgebung zur Fehler-Injektion umfasst die folgenden Elemente:

  • Zielsystem: das virtuelle Hardware-Modell,
  • Fehler-Injektor: injiziert Fehler aus einer Bibliothek,
  • Workload-Generator: erstellt Stimuli nach Maßgabe der Test-Szenarien,
  • Monitor: zur Rückkopplung von Informationen vom Zielsystem und der Datenerfassung und -analyse,
  • Controller: um alles zu instrumentieren.

Der Fehler-Injektor und die zugehörige Bibliothek stützen sich auf ein einfaches Fehler-Injektions-API, um Fehler-Injektionsszenarien zu modellieren. Das API besitzt zwei grundlegende Befehle: trigger und inject. Der Trigger-Befehl ruft eine Injektor-Routine auf, sobald ein Trigger-Ereignis auftritt.

Verknüpfte Trigger zur dynamischen Freigabe weiterer Trigger

Anwender können Trigger verknüpfen, um weitere Trigger dynamisch freizugeben, abhängig vom Status des Systems. Der Inject-Befehl setzt das spezifizierte Element auf einen bestimmten Wert. Unterstützte Elemente sind I/O-Pins, Register, interne Signale und Speicherplätze. Der Wert kann entweder einmalig gesetzt (transient) oder permanent erzwungen werden. Von Anwendern können modell-abhängige Befehle für bestimmte Zwecke hinzugefügt werden, beispielsweise um einen ECC-Fehler nach einem Speicher-Lese- oder Schreibzugriff zu melden.

Fehler-Injektions-Szenario: Datenabbruch wegen ECC-Fehlers

Dieses Soft-Error-Szenario verwendet die Fehler-Injektion, um Daten im SRAM-Speicher während der normalen Programmausführung zu verfälschen. Die ECC-Funktionalität des SRAM-Modells löst die Datenabbruch-Ausnahme aus. Der Ablauf ist wie folgt:

  • Die MCU führt eine AUTOSAR-Software-Anwendung aus;
  • Gesteuert durch die interne Interrupt-Leitung verzweigt der Prozessor-Core zu einer Standard-Interrupt-Service-Routine;
  • Der nächstfolgende Zugriff auf den SRAM-Speicher löst einen ECC-Fehler aus.

Ingenieure können dieses Szenario unter Nutzung der Skript-Möglichkeiten des Frameworks und des Fehler-Injektions-APIs mit lediglich drei Befehlen und weniger als 10 Zeilen Code beschreiben. Wenn der Core zur Interrupt-Service-Routine verzweigt, fährt eine Fehler-Routine das Betriebssystem herunter. Es ist dann möglich, die Fehler-Injektion und ihre Auswirkungen mittels der eingebauten Überwachungs- und Analyse-Funktionen zu verfolgen.

Fehler-Injektion als optimale Methode der Softwarediagnose

Die Fehler-Injektion, wie sie vom ISO-26262-Standard empfohlen wird, ist die beste verfügbare Methode, um die Fehlertoleranz von Hardware-Blöcken zu prüfen und die Effektivität der Diagnose-Software sicherzustellen. Virtuelle Prototypen stellen ein komplettes Framework zur Erstellung fortgeschrittener Fehler-Injektions-Szenarien dar. Sie bieten eine größere Sichtbarkeit und mehr Fehler-Injektionsstellen als hardware-basierte Fehler-Injektion, und können sowohl permanente als auch transiente Fehler modellieren. Im Gegensatz zu software-basierter Fehler-Injektion sind virtuelle Prototyp-Frameworks vollständig nicht-beeinflussend. Virtuelle Prototypen laufen um Größenordnungen schneller als RTL- und Gatterlevel-Simulatoren.

Automatische Regression-Tests

Fehler-Injektions-Frameworks, welche virtuelle Prototypen nutzen, erlauben Anwendern, die Fehler einer Versionskontrolle zu unterziehen und auf diese Weise automatische Regression-Tests durchzuführen, wenn es zu Änderungen der Software kommt.

Virtuelle Prototypen als Nachweis für Erfüllung von Standards wie ISO 26262

Simulationen virtueller Prototypen besitzen das Potenzial, als Nachweis für die Zertifizierung und Erfüllung von Standards wie ISO 26262 anerkannt zu werden.

* Victor Reyes ist Technical Marketing Manager bei Synopsys, Inc.

Artikelfiles und Artikellinks

(ID:42569124)