Testen der Zuverlässigkeit von integrierten Schaltkreisen und Software: Ein praktischer Leitfaden zur Fehlereinspeisung

Autor: Johnny Liu, CEO bei Dowway Vehicle

Veröffentlicht: 21. Juli 2026

Kategorie: Eingebettete Systeme, Fahrzeugsicherheit, Hardwareentwicklung, Konformität

Als CEO von Dowway Vehicle, einem Unternehmen, das sicherheitskritische Systeme für Autos entwickelt, weiß ich, dass Zuverlässigkeit mehr ist als nur eine formale Anforderung. In unserer Branche können unentdeckte Chip-Ausfälle oder kurze Softwarefehler schwerwiegende Sicherheitsrisiken bergen.

Fehlereinspeisung ist die zuverlässigste Methode, um zu testen, wie gut ein System mit Fehlern umgeht. Dieser Leitfaden behandelt die wichtigsten Methoden der Fehlereinspeisung und hilft Ihnen bei der Entwicklung von Systemen, die Fehler elegant abfangen und Normen wie IEC 61508 erfüllen.

1. Warum wir Fehler einbauen müssen

Mitte der 1970er-Jahre berichteten Weltraummissionen erstmals von ungewöhnlichen Systemverhaltensweisen, die durch Chipfehler verursacht wurden. Seitdem müssen sich Chipdesigner und -hersteller intensiv mit der Zuverlässigkeit auseinandersetzen. Heute müssen wir analysieren, wie sich digitale Schaltungen in Flugzeugen, Autos und anderen kritischen Systemen bei Fehlern verhalten. Fehlereinspeisungstests sind eine der besten Methoden, diese Zuverlässigkeit zu bewerten. Tatsächlich empfehlen Normen für funktionale Sicherheit wie IEC 61508 nachdrücklich, in jeder Phase des Entwicklungszyklus Fehler einzuspeisen.

Wenn Systeme ausfallen, stürzen sie oft schwerwiegend ab und zerstören wertvolle Systemdaten. Fehler können zudem lange unentdeckt bleiben, bevor sie sichtbare Probleme verursachen. Dies macht es extrem schwierig, die Ursache eines Ausfalls in einem laufenden System zu finden. Bei großen, komplexen Systemen ist die Reproduktion dieser seltenen Fehlerzustände nahezu unmöglich.

Fehlereinspeisung löst dieses Problem. Sie ermöglicht es, die Leistungsfähigkeit eines Systems zu testen:

• Erkennt Fehler.
• Isoliert Fehler, um deren Ausbreitung zu verhindern.
• Konfiguriert sich selbst neu, um einen sicheren Betrieb zu gewährleisten.
• Kehrt in den Normalzustand zurück.

2. Innerhalb einer Fehlereinspritzumgebung

Ein professionelles Fault-Injection-Setup ist ein strukturiertes Ökosystem. Es verwendet neun Kernkomponenten, um Tests durchzuführen, ohne das Zielsystem zu beeinträchtigen:

1. Zielsystem: Die Hardware oder Software, die Sie testen.
2. Fehlereinspritzer: Das Werkzeug (Hardware oder Software), das den Fehler verursacht.
3. Fehlerbibliothek: Eine separate Datenbank speichert die Testparameter – wie Fehlertypen, -orte, -zeitpunkte und Hardware- oder Softwareregeln. Durch die Unabhängigkeit dieser Bibliothek bleibt das Gesamtsystem hochflexibel und lässt sich problemlos in andere Projekte integrieren.
4. Workload-Generator: Ein Tool, das dem Zielsystem operative Befehle übermittelt. Diese Befehle können reale Anwendungen, standardisierte Benchmarks oder synthetische Aufgaben sein.
5. Workload-Bibliothek: Eine Sammlung vordefinierter Arbeitslasten und Testfälle.
6. Regler: Das Programm, das das gesamte Experiment ausführt. Es kann entweder auf dem Zielsystem selbst oder auf einem unabhängigen Host-Computer ausgeführt werden.
7. Monitor: Ein Tool, das die Systemausführung in Echtzeit verfolgt, um zu erkennen, wann Befehle ausgeführt werden und wann Anomalien auftreten.
8. Datensammler: Ein Tool, das Systemdaten in Echtzeit aufzeichnet, wenn es vom Monitor ausgelöst wird.
9. Datenanalysator: Ein Offline-Tool, das die gesammelten Daten verarbeitet und überprüft, um die Zuverlässigkeit zu messen.

3. Hardware- vs. Software-Fehlereinspeisung

Die Wahl zwischen Hardware- und Softwaremethoden hängt von der Art der Fehler ab, die Sie testen möchten, und dem Aufwand, der für deren Einrichtung erforderlich ist.

Fehlertyp / Modell	Hardware-Fehlerinjektion	Software-Fehlereinspeisung
Leerlauf	Ja	NEIN
Überbrückung	Ja	NEIN
Bit-Flip	Ja	Ja
Störstrom	Ja	NEIN
Stromstoß	Ja	NEIN
Festgefahren bei	Ja (Am besten geeignet zur Standortkontrolle)	Schwierig / Hoher Aufwand
Beschädigung gespeicherter Daten (Speicher, Register, Festplatte)	Selten	Ja
Beschädigung von Kommunikationsdaten (Bus, Netzwerk)	Selten	Ja
Manifestation von Softwarefehlern (Maschinenebene & höher)	NEIN	Ja

Wenn Sie dauerhafte Fehler testen möchten (bei denen eine physikalische Leitung dauerhaft auf 1 oder 0 verharrt), ist ein Hardware-Injektor die beste Wahl, da Sie die genaue Position präzise steuern können. Dauerhafte Fehler per Software zu simulieren ist entweder extrem langsam oder völlig unmöglich.

Wenn es Ihnen um die Erkennung von Datenbeschädigung geht, reichen Softwaretools in der Regel aus. Manche Fehler, wie beispielsweise ein Bit-Flip in einer Speicherzelle, lassen sich sowohl mit Hardware als auch mit Software erzeugen. In solchen Fällen sollten Sie Ihre Wahl anhand der Kosten, der Genauigkeit, des Eingriffs des Tools in das System und der Wiederholbarkeit des Tests treffen.

4. Hardware-implementierte Fehlereinspeisung

Hardwarebasierte Methoden verwenden zusätzliche physische Geräte, um Fehler direkt in die Zielhardware einzuführen. Wir unterteilen diese Methoden in zwei Hauptgruppen: Kontakt- und berührungslose Methoden.

Kontakt-Hardware-Injektion (Pin-Ebene)

Dies ist die gebräuchlichste Methode zur Hardware-Injektion. Sie erfordert einen direkten physischen Kontakt mit den Pins des Zielchips.

• Aktive Sonden: Die Messspitzen werden direkt an die Pins angeschlossen, um Strom einzuspeisen. Dadurch ändert sich der Zustand der Pins. Dies wird hauptsächlich bei permanenten Fehlern (Stuck-at-Fehlern) verwendet, man kann aber auch zwei Pins überbrücken. Vorsicht: Zu viel Strom, der mit aktiven Messspitzen eingespeist wird, kann den Zielchip beschädigen.
• Einsetzen der Buchse: Sie platzieren einen speziellen Sockel zwischen dem Zielchip und seiner Leiterplatte. Dieser Sockel legt bestimmte analoge Spannungspegel an die Pins an, um Dauer-, Unterbrechungs- oder komplexe Logikfehler zu simulieren. Er kann Pin-Signale invertieren, UND- oder ODER-Verknüpfungen mit benachbarten Pins durchführen oder sogar Operationen ausführen, die das aktuelle Signal mit vorherigen Signalen am selben Pin kombinieren.

Diese Kontaktmethoden ermöglichen eine präzise Steuerung von Zeitpunkt und Ort des Fehlers. Sie beeinträchtigen die auf dem Zielsystem laufende Software nahezu nicht. Da diese Fehler jedoch auf Pin-Ebene auftreten, sind sie nicht mit echten internen Stuck-at- oder Brückenfehlern im Inneren des Siliziums vergleichbar. Dennoch eignen sie sich hervorragend zum Testen von Fehlererkennungsschaltungen. Alternativ können aktive Messspitzen an die Stromversorgung angeschlossen werden, um Spannungsschwankungen einzuspeisen. Dies birgt jedoch ein hohes Risiko, das Bauteil zu beschädigen.

Berührungslose Hardware-Injektion

Der Injektor berührt das System nicht. Stattdessen nutzt er externe physikalische Kräfte, um Probleme im Inneren des Chips zu verursachen.

• Schwerionenstrahlung: Ionen schießen durch die Verarmungszonen der Chips und erzeugen dabei kurzzeitige elektrische Ströme.
• Elektromagnetische Felder: Die Platzierung der Hardware in oder in der Nähe starker elektromagnetischer Felder ahmt natürliche physikalische Störungen nach.

Diese berührungslosen Methoden eignen sich hervorragend zum Testen früher Designprototypen, insbesondere wenn eine schnelle Hardwareüberwachung erforderlich ist (z. B. die Reaktionszeit einer CPU auf einen Fehler) oder wenn interne Bereiche erreicht werden müssen, die mit physischen Sonden nicht zugänglich sind. Hardware-Systeme können diese Fehler schnell und mit minimalen Systembeeinträchtigungen erfassen und auslösen, häufig mithilfe von Hardware-Timern oder durch Warten auf ein bestimmtes Ereignis (z. B. das Auftreten einer Adresse auf dem Bus).

Der größte Nachteil besteht darin, dass berührungslose Verfahren schwer zeitlich und räumlich exakt auszulösen sind, da man nicht perfekt kontrollieren kann, wann ein schweres Ion ausgestoßen wird oder wann eine elektromagnetische Welle auf einen bestimmten Transistor trifft.

5. Softwareimplementierte Fehlereinspeisung (SFI)

Softwarebasierte Fehlereinspritzwerkzeuge sind sehr beliebt. Der Hauptgrund dafür sind die Kosten: Man benötigt keine teure Laborausrüstung. SFI ermöglicht zudem das direkte Testen von Anwendungen und Betriebssystemen, was mit Hardware nur sehr schwer möglich ist.

Um eine Anwendung zu testen, platzieren Sie den Injektor entweder innerhalb der Anwendung selbst oder zwischen Anwendung und Betriebssystem. Um das Betriebssystem zu testen, muss der Injektor im Betriebssystemcode integriert werden, da das Hinzufügen einer zusätzlichen Schicht zwischen der Hardware und dem Betriebssystem äußerst schwierig ist.

Trotz seiner Flexibilität weist SFI drei wesentliche Nachteile auf:

1. Zugriffsbeschränkungen: Es kann keine Bereiche berühren, auf die die Software keinen Zugriff hat (wie zum Beispiel physikalische Logikgatter).
2. Systeminterferenzen: Der Injektorcode kann das Zielsystem verlangsamen oder sogar die ursprüngliche Struktur der Software verändern.
3. Niedrige Zeitauflösung: Dies kann die Genauigkeit des Tests beeinträchtigen. SFI funktioniert gut bei sich langsam entwickelnden Fehlern (wie Speicherproblemen). Bei extrem schnellen Fehlern (wie CPU- oder Bus-Timing-Problemen) kann die Software jedoch möglicherweise nicht erkennen, wie sich der Fehler im System ausbreitet.

Der Hybridansatz

Um diese Timing-Probleme zu beheben, greifen Ingenieure mitunter auf eine Hybridmethode zurück. Diese kombiniert die Flexibilität der Software-Einspeisung mit der Geschwindigkeit und Genauigkeit der Hardware-basierten Zeitmessung. Sie eignet sich hervorragend zur Messung kleinster Timing-Verzögerungen. Der Einsatz von Hardware-Tracking-Tools erhöht jedoch die Kosten und schränkt die Testflexibilität aufgrund der begrenzten Speicherkapazität ein.

6. Software-Injektion zur Kompilierzeit vs. zur Laufzeit

Bei der Software-Fehlerinjektion wird danach unterschieden, wann der Fehler auftritt: zur Kompilierzeit oder zur Laufzeit.

Kompilierzeit-SFI

Sie modifizieren die Programmanweisungen vor dem Laden oder Ausführen des Programms. Anstatt die physische Hardware zu verändern, ändern Sie den Quellcode oder Assembler-Code, um Hardware-, Software- oder vorübergehende Fehler zu simulieren. Dadurch entsteht ein modifiziertes, fehlerhaftes Programmabbild. Wenn das System dieses Abbild ausführt, tritt der Fehler auf.

Dies erfordert keine zusätzliche Software zur Laufzeit und führt zu keinerlei Leistungseinbußen. Da der Fehler dauerhaft im Code verankert ist, eignet er sich perfekt zur Simulation permanenter Hardwareausfälle. Der Nachteil besteht darin, dass Fehler nicht dynamisch während der Programmausführung eingefügt werden können.

Laufzeit SFI

Sie benötigen eine Möglichkeit, Fehler während der Programmausführung auszulösen. Dafür gibt es drei gängige Methoden:

• Auszeiten: Ein Timer (Hardware oder Software) löst nach einer festgelegten Zeit eine Interruptanforderung aus und ruft damit den Fehlerinjektor auf. Dies erfordert keine Änderungen an Ihrem Anwendungscode. Da die Auslösung jedoch zeitbasiert und nicht abhängig von der aktuellen Programmaktivität erfolgt, können die Ergebnisse unvorhersehbar sein. Diese Methode eignet sich am besten zur Simulation zufälliger, vorübergehender Hardwarefehler.
• Ausnahmen und Fallen: Eine Hardware-Ausnahme oder eine Software-Trap-Anweisung (wie ein Haltepunkt) übergibt die Kontrolle an den Injektor. Im Gegensatz zu Timeouts ermöglicht dies das Einfügen von Fehlern genau dann, wenn ein bestimmtes Ereignis oder eine bestimmte Bedingung eintritt (z. B. wenn das Programm versucht, auf einen bestimmten Speicherbereich zuzugreifen). Beide müssen direkt mit den Interrupt-Handlern des Systems verbunden sein.
• Codeeinfügung: Sie fügen dem Programm neue Anweisungen hinzu, die direkt vor dem Zielcode ausgeführt werden. Dies ähnelt der Codeänderung, erfolgt jedoch zur Laufzeit und fügt neue Anweisungen hinzu, anstatt bestehende zu ändern. Im Gegensatz zu Traps kann der Injektor vollständig im Benutzermodus anstatt im Systemmodus ausgeführt werden und benötigt daher keine tiefgreifenden Betriebssystemrechte.

7. Zusammenfassung der Unterschiede

Betrachten wir nun die beiden Hauptansätze im Vergleich:

• Zielorte: Hardware zielt auf Gehäuseanschlüsse und physische interne Komponenten ab. Software zielt auf den aktiven Speicher, CPU-Register und den allgemeinen Softwarezustand ab.
• Interferenz: Hardware verursacht nahezu keine Zeitverzögerungen. Software führt zu Leistungseinbußen, da zusätzlicher Code ausgeführt werden muss.
• Kosten: Hardware ist teuer und erfordert ein spezielles Labor. Software basiert auf Code und ist kostengünstig zu implementieren.
• Zeitliche Auflösung: Hardware arbeitet mit hoher Präzision (Nanosekunden). Software hat eine gröbere Auflösung (Mikrosekunden oder Millisekunden).
• Testschwerpunkt: Die Hardware bewertet die Fehlererkennung und -abschirmung auf niedriger Ebene. Die Software testet Wiederherstellungsprogramme, Betriebssysteme und Anwendungen auf höherer Ebene.

8. Häufig gestellte Fragen

Worin besteht der Hauptunterschied zwischen Hardware- und Software-Fehlerinjektion?

Hardware-Injektion zielt auf physische Pins und Schaltkreise ab, während Software-Injektion auf Speicher, Register und Code abzielt. Hardwarebasierte Methoden nutzen physikalische Werkzeuge wie Sonden oder Strahlung, um Reaktionen in Schaltkreisen auf niedriger Ebene zu testen. Softwarebasierte Methoden modifizieren den Code oder den Systemspeicher, um zu testen, wie Anwendungen und Betriebssysteme mit Fehlern umgehen.

Kann Software-Fehlerinjektion permanente Hardwareausfälle simulieren?

Ja, indem man zur Kompilierzeit Injektionen verwendet, um den Programmcode dauerhaft zu verändern. Durch die Veränderung von Quellcode oder Assembler-Anweisungen vor der Ausführung erzeugen Sie ein dauerhaft fehlerhaftes Programmabbild. Dies simuliert einen permanenten physischen Defekt, ohne jedoch Laufzeitverzögerungen zu verursachen.

Warum ist das Einstecken in eine Buchse sicherer als die Verwendung aktiver Prüfspitzen für Pin-Level-Tests?

Beim Einstecken in einen Sockel wird eine kontrollierte Signalmanipulation verwendet, während aktive Sonden externe Ströme einspeisen, die den Chip durchbrennen können. Aktive Sonden leiten den Strom direkt an die physischen Pins, was leicht zu einer Überhitzung des Siliziums führen kann. Breakout-Sockel fangen die Pins sicher ab und verwenden logische Gatter (UND, ODER, Invertierung), um Fehler ohne elektrische Gefahr zu simulieren.

Schlussbetrachtungen für Systemarchitekten

Bei Dowway Vehicle befolgen wir eine einfache Regel: Wenn Sie die Reaktion Ihres Systems auf einen Fehler nicht getestet haben, müssen Sie davon ausgehen, dass Ihr System ausfällt, wenn dieser Fehler auftritt. Verlassen Sie sich nicht nur auf eine einzige Testmethode. Nutzen Sie Software-Injection frühzeitig in der Entwicklung, um Zustandsautomaten auf Anwendungsebene und Wiederherstellungsroutinen des Betriebssystems zu testen. Verwenden Sie später Hardware-Injection auf physischen Prototypen, um sicherzustellen, dass Ihre Hardware-Überwachungsmechanismen, Speicherschutzsysteme und Ausfälle physischer Pins keinen systemweiten Ausfall verursachen.

Referenzen

• [1] Fehlereinspritztechniken und -werkzeuge (Umfassende akademische Umfrage)
• [2] Eine auf funktionaler Verifikation basierende Fehlereinspritzumgebung (IEEE-Symposium für Zuverlässigkeit und Instandhaltbarkeit)
• [3] ISO 26262-11:2018 – Richtlinien für die Anwendung von Halbleitern zur funktionalen Sicherheit in der Automobilindustrie.
• [4] IEC 61508 – Funktionale Sicherheit von elektrischen/elektronischen/programmierbaren elektronischen sicherheitsrelevanten Systemen.