J1939-Diagnose: DM1, DM2 und der Aufbau eines DTC
Wer den Fehlerspeicher eines Nutzfahrzeugs, eines Motors oder einer Landmaschine ausliest, landet unweigerlich bei drei Abkürzungen: SPN, FMI und OC. Sie bilden zusammen einen Diagnostic Trouble Code (DTC), und übertragen wird dieser über die Diagnosemeldungen DM1 und DM2 aus SAE J1939-73. Dieser Artikel erklärt, wie die beiden Parametergruppen aufgebaut sind, wie man einen DTC korrekt zerlegt und an welchen Stellen selbstgeschriebene Parser regelmäßig scheitern.
DM1 – aktive Fehler
Die Parametergruppe DM1 (Active Diagnostic Trouble Codes) trägt die PGN 65226 (0xFECA) und wird mit der Standardpriorität 6 gesendet. Sie ist eine Broadcast-Nachricht im PDU2-Format – der PF-Wert 0xFE liegt oberhalb von 240, es gibt also keine Zieladresse, sondern eine Group Extension. Jedes Gerät im Netzwerk kann DM1 mitlesen, ohne dass es adressiert werden muss.
Solange mindestens ein Fehler aktiv ist, sendet die ECU DM1 zyklisch einmal pro Sekunde. Das ist der Punkt, an dem DM1 sich grundlegend von einem Ereignis-Protokoll unterscheidet: Ein DM1 ist kein Fehlereintrag, sondern eine Momentaufnahme aller gerade anstehenden Fehler. Verschwindet ein Fehler, taucht er im nächsten DM1 einfach nicht mehr auf.
Wichtig für Empfänger: Auch wenn kein Fehler aktiv ist, sendet ein normkonformes Gerät weiter zyklisch DM1 – dann mit ausgeschalteten Lampen und einem DTC-Feld mit SPN 0, FMI 0 und Occurrence Count 0. Das Ausbleiben von DM1 bedeutet also nicht „keine Fehler“, sondern „Gerät antwortet nicht“. Wer diese Unterscheidung im Empfänger nicht abbildet, übersieht ausgefallene Steuergeräte.
Ändert sich der Fehlerzustand, darf DM1 einmal sofort gesendet werden; danach greift wieder der Sekundenzyklus. Eine ECU, die bei flatternden Sensorwerten DM1 im Millisekundenabstand herausschickt, verletzt die Spezifikation und belastet den Bus unnötig.
Der Lampenstatus in Byte 1 und 2
Die ersten beiden Bytes von DM1 beschreiben nicht den Fehler, sondern die Anzeige im Cockpit. Byte 1 enthält den Status von vier Lampen, jeweils in zwei Bit:
| Bits in Byte 1 | Lampe | Bedeutung |
|---|---|---|
| 8–7 | Malfunction Indicator Lamp (MIL) | emissionsrelevanter Fehler |
| 6–5 | Red Stop Lamp | Fahrzeug ist anzuhalten |
| 4–3 | Amber Warning Lamp | Warnung, Weiterfahrt möglich |
| 2–1 | Protect Lamp | Zustand außerhalb des Motorbetriebs, z. B. Kühlmittel |
Die Werte sind 00 für aus, 01 für ein und 11 für nicht verfügbar. Byte 2 hat exakt dieselbe Struktur, beschreibt aber das Blinkverhalten derselben vier Lampen: langsames Blinken, schnelles Blinken oder kein Blinken.
Genau dieses zweite Byte wird in der Praxis am häufigsten ignoriert. Byte 1 und Byte 2 müssen gemeinsam ausgewertet werden – erst beide zusammen ergeben die Aussage „Amber Warning Lamp blinkt langsam“. Ein Diagnosewerkzeug, das nur Byte 1 anzeigt, unterschlägt eine Information, die beim Motorenhersteller durchaus unterschiedliche Fehlerklassen bedeutet.
Der DTC in vier Bytes
Ab Byte 3 folgt der erste DTC. Er belegt immer genau vier Bytes und enthält vier Felder:
| Feld | Breite | Lage |
|---|---|---|
| SPN (Suspect Parameter Number) | 19 Bit | Bytes 3 und 4 vollständig, plus die oberen 3 Bit von Byte 5 |
| FMI (Failure Mode Identifier) | 5 Bit | untere 5 Bit von Byte 5 |
| SPN Conversion Method (CM) | 1 Bit | oberstes Bit von Byte 6 |
| Occurrence Count (OC) | 7 Bit | untere 7 Bit von Byte 6 |
Die SPN benennt den betroffenen Parameter, also was fehlerhaft ist – etwa die Kühlmitteltemperatur oder ein bestimmter Drucksensor. Die Zuordnung von SPN zu Parameter steht in SAE J1939-71 beziehungsweise im J1939 Digital Annex. Herstellerspezifische SPNs sind zulässig, weshalb ein unbekannter Wert nicht automatisch ein Parserfehler ist.
Der FMI benennt die Fehlerart, also wie der Parameter fehlerhaft ist. Der Wertebereich 0 bis 21 ist in J1939-73 definiert, 31 bedeutet „Zustand liegt vor“ ohne nähere Spezifikation. Die vollständige Tabelle gehört in die Norm und nicht in einen Blogartikel; für die Praxis lohnt es sich aber, die Gruppen zu kennen:
- Elektrische Fehler – Spannung zu hoch oder Kurzschluss nach Plus (3), Spannung zu niedrig oder Kurzschluss nach Masse (4), Strom zu niedrig oder Leitungsbruch (5), Strom zu hoch (6). Das sind die Codes, die auf Verkabelung deuten, nicht auf die Applikation.
- Plausibilitätsfehler – Wert gültig, aber über oder unter dem normalen Bereich, jeweils in drei Schweregraden. Hier gilt: Der Wert wird sauber gemessen, ist aber unplausibel.
- Signalverhalten – Wert schwankend oder unplausibel (2), auffällige Aktualisierungsrate (9), auffällige Änderungsrate (10).
- Kommunikationsfehler – empfangene Netzwerkdaten fehlerhaft (19). Der wichtigste FMI für Netzwerkintegratoren, weil er auf ein anderes Gerät zeigt, nicht auf das meldende.
Der Occurrence Count zählt, wie oft der Fehler seit dem letzten Reset aktiv geworden ist. Der Zähler läuft bei 126 fest, 127 bedeutet „nicht verfügbar“. Er zählt nicht zurück – ein OC von 40 bei einem gerade aktiven Fehler ist ein starker Hinweis auf einen intermittierenden Wackelkontakt und nicht auf einen Bauteildefekt.
Die SPN Conversion Method – der häufigste Parserfehler
Das CM-Bit ist historisch begründet und die Ursache der meisten falsch dekodierten Fehlercodes. In der Frühzeit von J1939 gab es mehrere Verfahren, die 19 Bit der SPN auf drei Bytes zu verteilen. Heute gilt nur noch eines davon, und es wird durch CM = 0 angezeigt: Byte 3 enthält das niederwertigste Byte der SPN, Byte 4 das mittlere, und die oberen drei Bit von Byte 5 enthalten die drei höchstwertigen Bit.
Ein CM = 1 signalisiert eines der älteren Verfahren. Diese sind untereinander nicht unterscheidbar, weshalb ein generischer Empfänger die SPN in diesem Fall nicht zuverlässig rekonstruieren kann. Für Neuentwicklungen ist ausschließlich CM = 0 zulässig.
Der praktische Fehler passiert an einer anderen Stelle: Viele selbstgeschriebene Parser lesen die SPN als 24-Bit-Wert aus Byte 3 bis 5 und maskieren die unteren fünf Bit weg – wodurch die drei SPN-Bit aus Byte 5 an der falschen Position landen. Das Ergebnis sind SPN-Werte, die für Fehler unterhalb von 65536 zufällig richtig aussehen und darüber systematisch falsch sind. Wer beim Testen nur kleine SPNs verwendet, merkt das nie.
Mehrere Fehler gleichzeitig
Sind mehrere Fehler aktiv, werden weitere DTCs einfach angehängt, jeweils in Vierbyte-Blöcken. Bei zwei DTCs sind das schon 10 Byte – die Parametergruppe passt damit nicht mehr in ein einzelnes CAN-Telegramm und muss über das Transportprotokoll übertragen werden.
Da DM1 ein Broadcast ist, kommt dafür die Broadcast Announce Message (BAM) zum Einsatz, nicht das Handshake-Verfahren CMDT. Das hat zwei Konsequenzen, die bei der Auslegung oft unterschätzt werden: BAM verlangt Pausen von mindestens 50 ms zwischen den Datentelegrammen, sodass ein DM1 mit vielen Fehlern mehrere hundert Millisekunden Übertragungszeit braucht. Und BAM kennt keine Flusskontrolle – ein Empfänger, der nicht schnell genug einsammelt, verliert die Meldung stillschweigend.
Für die Implementierung heißt das: Der Empfangspfad für DM1 muss den Transportprotokoll-Fall von Anfang an beherrschen. Ein Parser, der nur 8-Byte-Telegramme mit einem DTC verarbeitet, funktioniert im Labor tadellos und fällt genau dann aus, wenn im Feld mehrere Fehler zusammenkommen.
DM2 und das Löschen
DM2 (Previously Active Diagnostic Trouble Codes), PGN 65227 (0xFECB), enthält Fehler, die aufgetreten sind und nicht mehr anstehen – den eigentlichen Fehlerspeicher. Format und Lampenfelder sind identisch zu DM1, der entscheidende Unterschied liegt im Sendeverhalten: DM2 wird nicht zyklisch gesendet, sondern nur auf Anfrage über die Request-Parametergruppe (PGN 59904).
Zum Löschen stehen zwei Dienste bereit: DM11 (PGN 65235) setzt die aktiven Fehler zurück, DM3 (PGN 65228) löscht die zuvor aktiven, also den DM2-Inhalt. Beide werden als Anfrage gesendet und vom Gerät bestätigt. Wichtig ist die Erwartungshaltung: Ein DM11 auf einen Fehler, dessen Ursache noch besteht, führt dazu, dass der Fehler unmittelbar wieder aktiv wird — mit einem um eins erhöhten Occurrence Count.
Auswertung in der Praxis
Ein DM1 mit drei aktiven Fehlern besteht aus einem BAM-Ankündigungstelegramm und drei Datentelegrammen, in denen Lampenstatus und DTCs über Paketgrenzen hinweg verteilt sind. Diese Bytes von Hand zusammenzusetzen und die SPN aus drei Feldern zu rekonstruieren, ist mühsam und fehleranfällig.
Der emotas CANinterpreter mit der J1939-Erweiterung übernimmt das: Er setzt den Transportprotokoll-Transfer wieder zusammen, zerlegt jeden DTC in SPN, FMI und Occurrence Count und zeigt den Lampenstatus im Klartext. Für die Fehlersuche im Feld sind zusätzlich die Aufzeichnungs- und Replay-Funktionen relevant, weil intermittierende Fehler sich naturgemäß nicht auf Kommando reproduzieren lassen — hier hilft ein Langzeitmitschnitt, in dem man anschließend nach dem Auftreten des DTC sucht.
Für Gerätehersteller
Drei Empfehlungen, die den Integratoren des eigenen Geräts viel Arbeit ersparen:
- CM immer auf 0 setzen und die SPN nach dem aktuellen Verfahren packen. Alles andere ist für generische Werkzeuge nicht dekodierbar.
- DM1 auch im fehlerfreien Zustand senden, damit Empfänger zwischen „alles in Ordnung“ und „Gerät ausgefallen“ unterscheiden können.
- Die verwendeten SPNs dokumentieren, insbesondere die herstellerspezifischen. Eine SPN ohne Dokumentation ist für den Anwender nur eine Zahl — und erzeugt genau die Supportanfragen, die man sich sparen wollte.