J1939 Request und Acknowledgement: PGN 59904 und 59392

Die meisten Parametergruppen in J1939 werden zyklisch gesendet: Drehzahl, Temperaturen oder der Lampenstatus kommen ungefragt im festen Takt. Einige Informationen gibt es aber nur auf Anfrage – den Fehlerspeicher DM2, die Software- und Komponentenidentifikation oder die Adresszuordnung der Geräte im Netzwerk. Für diese Fälle definiert SAE J1939-21 zwei Parametergruppen: den Request (PGN 59904), mit dem man eine beliebige PGN anfordert, und das Acknowledgement (PGN 59392), mit dem ein Gerät antwortet, wenn es statt Daten eine Quittung liefert. Beide sind schnell implementiert. Die Regeln, wann geantwortet werden muss und wann geschwiegen werden muss, sind aber eine häufige Ursache für Probleme zwischen Geräten verschiedener Hersteller.

Warum J1939 einen eigenen Request braucht

Classical CAN kennt für Anfragen den Remote Frame. J1939 nutzt ihn nicht. Der Request ist stattdessen ein gewöhnliches Datentelegramm, in dessen Nutzdaten die gewünschte PGN steht. Das hat zwei Vorteile: Die Anfrage kann gezielt an ein Gerät oder an alle gerichtet werden, und der Anfragende ist über seine Source Address eindeutig erkennbar. Genau diese beiden Informationen steuern später das Antwortverhalten.

Aufbau des Requests

Der Request hat die PGN 59904 (0xEA00) und das PDU1-Format: Der PF-Wert 0xEA liegt unter 240, das PS-Feld enthält also eine Zieladresse. Die Standardpriorität ist 6. Ein Servicetool mit der Adresse 0xF9, das beim Motorsteuergerät (Adresse 0x00) anfragt, sendet auf dem Identifier 0x18EA00F9. Dieselbe Anfrage an alle Geräte läuft auf 0x18EAFFF9.

Die Nutzdaten bestehen aus genau drei Bytes, nämlich der angefragten PGN:

Byte	Inhalt
1	PGN, Bit 0–7 (niederwertiges Byte)
2	PGN, Bit 8–15
3	PGN, Bit 16–23 (enthält Data Page und Extended Data Page)

Die PGN wird mit dem niederwertigen Byte zuerst übertragen. Wer DM2 (PGN 65227, 0x00FECB) anfordert, sendet CB FE 00, nicht 00 FE CB. Bei PDU1-PGNs ist das mittlere Byte der angefragten PGN immer 0x00, denn die Zieladresse ist nicht Teil der PGN.

Der Request ist eine der wenigen Parametergruppen mit einem DLC kleiner als 8: J1939-21 schreibt DLC 3 vor. In der Praxis tauchen trotzdem Requests mit DLC 8 und aufgefüllten Bytes auf, weil manche Schnittstellen-APIs jedes Telegramm auf acht Bytes verlängern. Ein robuster Empfänger wertet deshalb die ersten drei Bytes aus und verwirft längere Requests nicht.

Neben dem Request definiert J1939-21 einen Request2 (PGN 51456) mit zusätzlichen Identifikationsbytes und der Option, die Antwort über die Transfer-Parametergruppe zu senden. Er spielt in der Praxis eine deutlich kleinere Rolle und ist nicht Thema dieses Artikels.

Adressiert oder global: zwei verschiedene Regelwerke

Wie ein Gerät auf einen Request reagiert, hängt vor allem von der Zieladresse ab. Die wichtigste Regel lautet: Ein adressierter Request muss immer beantwortet werden, ein globaler Request nur von den Geräten, die die angefragte PGN tatsächlich unterstützen.

Situation	Adressierter Request (DA = eigene Adresse)	Globaler Request (DA = 255)
PGN wird unterstützt	Antwort mit der angefragten Parametergruppe	Antwort mit der angefragten Parametergruppe
PGN wird nicht unterstützt	NACK	keine Antwort
PGN unterstützt, Gerät gerade beschäftigt	Cannot Respond	keine Antwort
PGN unterstützt, Zugriff gesperrt	Access Denied	keine Antwort
Zieladresse der Antwort bei PDU1-Parametergruppen	Adresse des Anfragenden	global (255)
Antwort länger als 8 Byte	in der Regel CMDT an den Anfragenden	BAM

Der Grund für das Schweigen bei globalen Requests ist die Buslast: Würde jedes Gerät, das eine PGN nicht kennt, ein NACK senden, erzeugte jede globale Anfrage eine Flut von Telegrammen, aus denen der Anfragende ohnehin nichts lernt.

Eine Regel wird oft übersehen: Bei einem globalen Request muss auch der Anfragende selbst die Anfrage bearbeiten und antworten, wenn er die PGN unterstützt. Da ein CAN-Controller seine eigenen Telegramme normalerweise nicht empfängt, muss der Protokollstack den Request intern an sich selbst weiterreichen.

Unterstützt ein Gerät eine PGN, kann aber einzelne Parameter darin gerade nicht liefern, ist NACK die falsche Antwort. Stattdessen sendet es die Parametergruppe und setzt die betroffenen Parameter auf den Wert „nicht verfügbar“ (alle Bits auf 1). Ein NACK sagt „diese PGN gibt es bei mir nicht“, und das ist eine andere Aussage als „dieser Wert fehlt gerade“.

Aufbau des Acknowledgements

Das Acknowledgement (ACKM) hat die PGN 59392 (0xE800), ebenfalls im PDU1-Format und mit der Standardpriorität 6. Obwohl es eine Zieladresse tragen könnte, wird es nach J1939-21 immer an die globale Adresse 255 gesendet. Ein NACK des Getriebesteuergeräts mit der Adresse 0x03 läuft also auf 0x18E8FF03, unabhängig davon, wer angefragt hat.

Byte	Inhalt
1	Control Byte (Art der Quittung)
2	Group Function Value, sonst 0xFF
3–4	reserviert, 0xFF
5	Address Acknowledged: Adresse des Anfragenden
6–8	quittierte PGN, niederwertiges Byte zuerst

Für die Praxis sind vier Werte des Control Bytes relevant:

0 – Positive Acknowledgement (ACK): Die angeforderte Aktion wurde ausgeführt.
1 – Negative Acknowledgement (NACK): Die PGN wird nicht unterstützt.
2 – Access Denied: Die PGN wird unterstützt, der Zugriff ist aber gesperrt, etwa durch eine Sicherheitsfunktion.
3 – Cannot Respond: Die PGN wird unterstützt, das Gerät kann aber gerade nicht antworten. Der Anfragende sollte es später erneut versuchen.

Weil das Acknowledgement global gesendet wird, sehen es alle Teilnehmer. Byte 5 und die PGN in Byte 6 bis 8 sind deshalb keine Zusatzinformation, sondern das einzige Mittel, ein Acknowledgement der richtigen Anfrage zuzuordnen. Ein Servicetool, das nur auf PGN 59392 und die Source Address des befragten Geräts filtert, wertet in einem Netzwerk mit zwei Tools auch die NACKs aus, die dem anderen Tool galten.

Ein vollständiges Beispiel: Das Servicetool 0xF9 fragt beim Getriebesteuergerät 0x03 die PGN 65248 (0xFEE0) an, die dieses nicht unterstützt.

Richtung	Identifier	Daten	Bedeutung
Tool → Getriebe	`0x18EA03F9`	`E0 FE 00`	Request PGN 65248, adressiert an 0x03
Getriebe → alle	`0x18E8FF03`	`01 FF FF FF F9 E0 FE 00`	NACK für PGN 65248, Anfragender 0xF9

Wann ein positives Acknowledgement kommt

Auf einen gewöhnlichen Request ist die Antwort die angefragte Parametergruppe selbst, ein ACK wird nicht zusätzlich gesendet. Positive Acknowledgements kommen dort vor, wo ein Request keine Daten abholt, sondern eine Aktion auslöst. Das bekannteste Beispiel sind die Löschdienste der J1939-Diagnose: Ein Request auf DM11 (PGN 65235) setzt die aktiven Fehler zurück, ein Request auf DM3 (PGN 65228) löscht die zuvor aktiven. Bei einem adressierten Request bestätigt das Gerät mit ACK, wenn es gelöscht hat, und mit NACK, wenn es das nicht konnte.

Richtung	Identifier	Daten	Bedeutung
Tool → Motor	`0x18EA00F9`	`D3 FE 00`	Request DM11, adressiert an 0x00
Motor → alle	`0x18E8FF00`	`00 FF FF FF F9 D3 FE 00`	ACK für DM11, Anfragender 0xF9

Zeitverhalten

J1939-21 verlangt, dass ein Gerät innerhalb von 200 ms auf einen Request antwortet. Der Anfragende wartet bis zu 1,25 s, bevor er die Anfrage als unbeantwortet wertet. Bleibt bis dahin jede Reaktion aus, ist das bei einem adressierten Request ein Fehler des befragten Geräts, denn es hätte mindestens mit NACK antworten müssen. Bei einem globalen Request bedeutet Stille dagegen schlicht, dass kein Gerät die PGN unterstützt.

Sonderfall Address Claimed

Ein Request auf PGN 60928 (0xEE00) fordert die Address-Claimed-Meldungen der anderen Teilnehmer an. Global gesendet, liefert er eine Übersicht aller belegten Adressen im Netzwerk und ist damit die Grundlage jedes Netzwerkscans. Für diesen Fall gelten Besonderheiten, die im Artikel zum J1939 Address Claiming ausführlich beschrieben sind:

Ein Gerät, das noch keine Adresse hat, darf den Request mit der Null-Adresse 254 als Source Address senden. Der globale Request lautet dann 0x18EAFFFE mit den Daten 00 EE 00.
Address Claimed wird immer an die globale Adresse gesendet, auch wenn der Request adressiert war.
Bei einem globalen Request muss auch der Anfragende selbst seine Address-Claimed-Meldung senden, sofern er bereits eine Adresse beansprucht hat.

Typische Implementierungsfehler

PGN in falscher Byte-Reihenfolge: Der Request auf DM2 wird als 00 FE CB gesendet. Das Zielgerät sieht eine Anfrage nach einer PGN, die es nicht kennt, und antwortet mit NACK.
NACK auf globale Requests: Das verletzt die Norm und erzeugt bei jedem Netzwerkscan unnötige Telegramme.
Keine Antwort auf adressierte Requests: Der Anfragende läuft in den Timeout von 1,25 s und kann nicht unterscheiden, ob das Gerät die PGN nicht kennt oder gar nicht erreichbar ist.
Acknowledgement nicht zugeordnet: Ohne Auswertung von Byte 5 und der quittierten PGN hält ein Tool fremde NACKs für Antworten auf die eigene Anfrage.
Eigener globaler Request nicht bearbeitet: Das Gerät fragt global nach Address Claimed, taucht aber in der eigenen Teilnehmerliste nicht auf.
NACK statt „nicht verfügbar“: Das Gerät antwortet mit NACK, obwohl es die PGN kennt und nur einzelne Werte fehlen.
Lange Antworten nicht vorgesehen: Requests auf Software Identification (PGN 65242) oder Component Identification (PGN 65259) liefern in der Regel mehr als 8 Byte. Der Anfragende muss deshalb beide Transportprotokolle beherrschen, denn welches zum Einsatz kommt, hängt davon ab, ob er adressiert oder global gefragt hat.

Request und Acknowledgement im Trace

Im Rohtrace sind Request und Antwort schwer zusammenzubringen: Die angefragte PGN steht mit vertauschten Bytes in den Nutzdaten, das Acknowledgement geht an alle, und bei langen Antworten liegt zwischen Request und Daten ein ganzer Transportprotokoll-Transfer. Der emotas CANinterpreter mit der J1939-Erweiterung zeigt PGNs, Quell- und Zieladressen interpretiert an und setzt Transportprotokoll-Transfers wieder zusammen. So ist schnell zu erkennen, ob auf einen Request die Daten, eine Quittung oder gar nichts folgte. Mit der Aufzeichnungsfunktion lässt sich das auch bei sporadischen Problemen im Feld im Nachhinein nachvollziehen.

Für Gerätehersteller

Jeden adressierten Request beantworten, mit Daten oder einer Quittung. Am sichersten ist es, das zentral im Protokollstack zu erledigen: Jede PGN, die die Applikation nicht bedient, wird dort automatisch mit NACK beantwortet.
Globale Requests nie quittieren, weder positiv noch negativ.
Dokumentieren, welche PGNs nur auf Anfrage gesendet werden. Für Integratoren ist das eine der wichtigsten Angaben, denn eine PGN, die nie ungefragt kommt, bleibt im Trace unsichtbar, bis jemand sie anfordert.