1. Juli 2008
Beru Zündkerzensteuergerät: Diagnose nach GMW3110 — und wie aus einem Einmal-Auftrag eine Testsuite wurde
Die Diagnosedienste eines Zündkerzensteuergeräts (nach dem GM-Standard GMW3110) waren seit Jahren implementiert, aber lange von niemandem mehr geprüft. In 2 Monaten sollten alle Dienste unter Laborbedingungen verifiziert und ein Testreport erstellt werden — als einmalige Aktion.
Das Steuergerät im Labor in Betrieb nehmen, eine Restbussimulation aufsetzen und mit CANoe (plus C-Code-Studium und der GMW3110) alle Diagnosedienste testen und belegen.
Statt nur eines Testreports lieferte ich in den 2 Monaten eine wiederverwendbare CANoe-Testsuite — die GMW3110 gibt je Dienst Pseudo-Code und eine Verifikations-Spezifikation vor, ideal für Automatisierung. Voller Erfolg → Folgebeauftragung: Redesign des virtuellen EEPROM-Managers.
Manchmal ist der beste Weg, einen Auftrag zu „übererfüllen”, nicht mehr Stunden — sondern die richtige Idee. Dieser Artikel ist die direkte Fortsetzung meiner Diagnose-Schule beim TRW-Gurtstraffer: Dieselbe Handwerkskunst — Restbussimulation, CANoe, Testautomation — nur bei einem neuen Kunden, einem neuen Diagnose-Standard und mit einem Ergebnis, das weit über den ursprünglichen Auftrag hinausging.
Was ein Zündkerzensteuergerät macht
In einem Ottomotor (Benziner) zündet ein Funke das Luft-Kraftstoff-Gemisch. Diesen Funken liefern die Zündkerzen, angesteuert über Zündspulen. Das Zündkerzensteuergerät steuert diese Zündung — Zeitpunkt und Ansteuerung der Spulen — und überwacht dabei, ob jede Zündung sauber funktioniert (z. B. Erkennung von Fehlern im Zündkreis). Ein kleines, spezialisiertes Steuergerät also, das über den Fahrzeugbus mit dem Rest des Autos spricht — und deshalb Diagnosedienste anbieten muss.
Entwickelt wurde es bei Beru in Bretten, einem bekannten Spezialisten für Zünd- und Glühtechnik. Gigatronik konnte mich — nach der Gurtstraffer-Erfahrung — erfolgreich mit diesem Industriepartner verknüpfen, der einen sehr ähnlichen Bedarf hatte.
GMW3110 statt UDS
Der spannende Unterschied zu TRW: Hier war die Diagnose-Spezifikation nicht UDS, sondern GMW3110 — der Diagnose-Standard von General Motors, eher bei amerikanischen Fahrzeugbauern im Einsatz. Das Prinzip ist dasselbe wie bei UDS: Ein Tester schickt über den Bus Anfragen (Diagnosedienste), das Steuergerät antwortet. Nur die konkrete Ausprägung der Dienste unterscheidet sich.
Und die eigentliche Aufgabe war auch eine andere als bei TRW: Es ging nicht um Fehlerspeicher-Einträge, sondern darum, alle vorhandenen Diagnosedienste zu überprüfen. Die waren zwar seit Jahren umgesetzt — aber hatte sich schon lange niemand mehr angeschaut.
Der Auftrag — und der Kniff
Der Auftrag war klar umrissen und als einmalige Aktion gedacht: In 2 Monaten das Steuergerät unter Laborbedingungen in Betrieb nehmen, eine Restbussimulation aufsetzen und mit CANoe — plus Studium des C-Codes und der GMW3110 — alle Diagnosedienste testen und einen Testreport erstellen.
Ich hätte das stumpf abarbeiten können. Aber ich war zu diesem Zeitpunkt im Thema Restbus, Diagnose und Testautomation schon so eingespielt, dass ich es besser machen wollte. Und die GMW3110 spielte mir dabei perfekt in die Karten: Die Spezifikation enthält für jeden Diagnosedienst sowohl eine Pseudo-Code-Implementierung als auch eine Verifikations-Spezifikation. Mit anderen Worten: Der Standard beschreibt nicht nur, was ein Dienst tut, sondern gleich, wie man ihn prüft. Das ist eine Steilvorlage für Automatisierung.
Vom Einmal-Auftrag zur Testsuite
Also baute ich in den 2 Monaten nicht nur den Testreport, sondern gleich eine wiederverwendbare CANoe-Testsuite, die alle Diagnosedienste automatisiert prüft. Aus einer „einmaligen Aktion” wurde ein bleibendes Werkzeug — und für den Kunden ein Unterschied ums Ganze:
Ein Gedanke aus heutiger Sicht
Ehrlich gesagt: Heute würde ich diese Aufgabe einer KI geben. Ein Standard, der pro Dienst Pseudo-Code und Verifikation mitbringt, ist die perfekte, strukturierte Vorlage, aus der sich eine Testsuite generieren lässt — genau die Art Arbeit, die sich automatisieren und heute mit Sprachmodellen beschleunigen lässt. Damals war ich die „Engine”: Ich war im Thema Restbus, Diagnose und Testautomation so eingespielt, dass ich die Spezifikation im Kopf in Testfälle übersetzte. Die Werkzeuge ändern sich — das Prinzip bleibt: strukturierte Spezifikation rein, reproduzierbare Prüfung raus.
Was man daraus mitnehmen kann
- Liefere über die Bestellung hinaus — wenn es dem Kunden nachhaltig hilft. Ein Testreport war beauftragt; eine Testsuite war der Hebel. Der Mehrwert entstand nicht durch mehr Stunden, sondern durch die richtige, wiederverwendbare Form des Ergebnisses.
- Eine gute Spezifikation ist schon der halbe Test. Wenn ein Standard die Verifikation gleich mitdenkt (wie GMW3110), wird Testen fast mechanisch. Das ist ein Plädoyer dafür, Prüfbarkeit von Anfang an mitzuspezifizieren.
- Kompetenz überträgt sich. Das CANoe/Restbus-Handwerk vom TRW-Gurtstraffer konnte ich hier 1:1 anwenden — nur mit einem anderen Diagnose-Standard. Fähigkeiten sind Kapital, das mit jedem Projekt Zinsen trägt.
Der Auftrag war ein voller Erfolg — und zog direkt die nächste Aufgabe nach sich: das Redesign eines virtuellen EEPROM-Managers. Aber das ist die nächste Geschichte.