15. Januar 2008
TRW Gurtstraffer: Fehlerspeicher, UDS-Diagnose — und wie aus Wochen ein halber Tag wurde
Ein Gurtstraffer-Steuergerät (Insassenschutz im Crash) muss ~30–40 Diagnose-Fehlercodes korrekt setzen, entprellen und wieder heilen. Alle 6–8 Wochen kam ein neuer Softwarestand, der komplett gegen die Diagnose-Spezifikation zu prüfen war — anfangs rein manuell.
Alle Fehlerspeicher-Einträge (DTCs) je Softwarestand zuverlässig prüfen (setzen, entprellen, heilen), Spezifikationsänderungen einarbeiten und einen belastbaren Testreport erzeugen — reproduzierbar und schnell.
Über drei Jahre eine CAPL-Testsuite auf Restbussimulation (CANoe) + XCP-Signalmanipulation (CANape) aufgebaut. Aus wochenlanger Handarbeit plus monatelanger Einarbeitung wurde ein halber Tag pro Softwarestand — inkl. automatisch generiertem HTML-Testreport.
Wenn ich zurückblicke, war dieses Projekt meine eigentliche Schule. Nicht das eleganteste, nicht das größte — aber das, aus dem ich am meisten gelernt habe: über Fahrzeug-Diagnose, Fehlerspeicher und die Kunst, eine stumpfe, wiederkehrende Prüfaufgabe so lange zu automatisieren, bis aus Wochen ein halber Tag wird.
Was ein Gurtstraffer macht
Ein Gurtstraffer gehört — wie der Airbag — zum passiven Sicherheitssystem. Bei einer Kollision strafft er den Sicherheitsgurt innerhalb von rund 10–15 Millisekunden, damit der Insasse früher an der Verzögerung des Fahrzeugs teilnimmt und nicht nach vorn schleudert. Ausgelöst wird er über die Crash-Sensorik; klassische Straffer sind pyrotechnisch (einmalig), moderne reversible Varianten nutzen einen elektrischen Antrieb und können schon in der Gefahrensituation vorspannen.
Kurz: Es ist ein sicherheitskritisches Steuergerät, bei dem im Ernstfall alles funktionieren muss. Und damit man sich darauf verlassen kann, muss es seine eigenen Fehler erkennen, speichern und melden können — genau mein Bereich.
DTC & Fehlerspeicher nach UDS
Jedes moderne Steuergerät führt einen Fehlerspeicher. Tritt ein Fehler auf, legt es einen DTC (Diagnostic Trouble Code) ab — einen genormten Fehlercode mit Statusinformationen. Ausgelesen und gelöscht wird er später in der Werkstatt über die Diagnose-Schnittstelle nach UDS (Unified Diagnostic Services). Das Entscheidende ist: Ein DTC entsteht und vergeht nicht einfach schlagartig — er durchläuft einen Lebenszyklus mit Entprellung und Heilung:
Die Fehlerklassen
Die ~30–40 DTCs des Steuergeräts fielen in klar unterscheidbare Klassen — und jede brauchte eine eigene Teststrategie:
Besonders lehrreich war die interne Aktuator-Diagnose. Ein Steuergerät prüft nicht nur „kommt ein gültiges Signal?”, sondern auch „ist mein Aktuator (z. B. der elektrische Antrieb) überhaupt da und gesund?”. Das macht es über Strom- und Spannungsmessung: Ein kurzer, definierter Ansteuerimpuls und die Messung, wie viel Strom fließt, verraten, ob eine Last angeschlossen ist. Zu wenig Strom → nichts angeschlossen (Open Load). Zu viel → Kurzschluss.
Mein Test-Setup: PIL, Restbussimulation und CANape/XCP
Ich hatte einen PIL-Aufbau (Processor-in-the-Loop): Die echte TRW-Software lief auf der Zielhardware an meinem Laborplatz — aber ohne die echten elektrischen Komponenten des Fahrzeugs. Genau das war der Trick.
Über die Restbussimulation (CANoe) spielte ich dem Steuergerät das „fehlende restliche Fahrzeug” vor und konnte CAN-Signale gezielt auf SNA oder ungültige Werte setzen. Für die internen Größen — Strom, Motorspannung, Bauteilzustände — nutzte ich CANape über XCP: ein Mess- und Kalibrierprotokoll, mit dem sich interne Variablen der laufenden Software lesen und schreiben lassen. Und die Bordnetzspannung stellte ich schlicht am Labornetzteil ein.
Von manuell zu automatisiert
Am Anfang war alles Handarbeit: erst den Laborplatz aufbauen, die Diagnose-Spezifikation verstehen, eine Testspezifikation schreiben und ausführen. Das kostete Monate an Einarbeitung und Praxis. Und alle 6–8 Wochen kam ein neuer Softwarestand vom Kunden — der komplett neu geprüft und mit einem Testreport belegt werden musste (anfangs eine Excel-Tabelle neben der Spezifikation).
Also investierte ich bei jedem neuen Softwarestand ein Stück in Automatisierung: eine Testsuite in CAPL (der Programmiersprache von CANoe), aufgesetzt auf die Restbussimulation, mit automatischer HTML-Report-Generierung.
Was man daraus mitnehmen kann
- In wiederkehrende Arbeit lohnt sich jede Minute Automatisierung. Der Schlüssel war nicht ein großer Wurf, sondern bei jedem der vielen Softwarestände ein kleines Stück zu automatisieren. Zins und Zinseszins fürs Engineering — dieselbe Logik, die heute hinter CI/CD steckt.
- Fehler erkennen ist die halbe Miete — Fehler zurücknehmen die andere. Das saubere Entprellen und Heilen von DTCs (Setzen und Löschen) ist mindestens so wichtig wie das Erkennen. Ein Fehlerspeicher voller „Geisterfehler” ist wertlos.
- Wenn die reale Welt fehlt, simuliert man sie — auf der richtigen Ebene. CAN-Signale über Restbussimulation, interne Größen über XCP/CANape, Spannung übers Netzteil: Man muss wissen, welcher Fehler auf welcher Ebene entsteht, um ihn gezielt auslösen zu können.
- Diagnose ist Empathie fürs spätere Ich. Jeder gut gesetzte DTC ist eine Nachricht an den Werkstattmechaniker Jahre später. Sauberes Fehlermanagement ist gelebte Wartbarkeit.
Dieses Projekt hat mich zum Diagnose-Menschen gemacht. Das Wissen über UDS, Fehlerspeicher und Restbussimulation habe ich anschließend bei Gigatronik immer wieder gebraucht — und das CANoe/CANape-Handwerk daraus 1:1 weiter zu Beru getragen. Aber das ist eine andere Geschichte.