CommunicationControl (0x28)
UDS CommunicationControl (0x28) schaltet normale und Netzwerknachrichten eines Steuergeräts ein oder aus. Sub-Funktionen, Bytes und was zu prüfen ist.
Aktualisiert Diese Seite als Markdown
Kurz gesagt
CommunicationControl (0x28) schaltet die normale und Netzwerk-Kommunikation eines Steuergeräts ein oder aus, meist um den Bus beim Flashen stillzulegen. Die Sub-Funktion wählt den Control-Typ, etwa disableRxAndTx (03), und ein communicationType-Byte wählt, welche Nachrichten. Der Request 28 03 01 schaltet normale Nachrichten ab, die positive Antwort 68 03 bestätigt es. Er braucht die Extended Session, und der Zustand muss bei Session-Ende oder Reset verworfen werden.
Was ist CommunicationControl (0x28)?
CommunicationControl schaltet die normale (Applikations-) und Netzwerkmanagement-Kommunikation eines Steuergeräts ein oder aus. Das Sub-Funktions-Byte wählt den Control-Typ, und ein communicationType-Byte wählt, für welche Nachrichten das Control gilt.
Ein normaler Ablauf:
| Richtung | Bytes | Bedeutung |
|---|---|---|
| Request | 28 03 01 | disableRxAndTx, normale Kommunikation |
| Positive Antwort | 68 03 | Control akzeptiert |
| Negative Antwort | 7F 28 7F | serviceNotSupportedInActiveSession |
Weitere typische negative Antworten sind 7F 28 12 (subFunctionNotSupported bei unbekanntem Control-Typ), 7F 28 13 (incorrectMessageLengthOrInvalidFormat, fehlender communicationType), 7F 28 31 (requestOutOfRange, nicht unterstützter communicationType) und 7F 28 22 (conditionsNotCorrect).
Wo ist es definiert?
ISO 14229-1:2020 definiert CommunicationControl (0x28) im Diagnostic and communication management functional unit. Die Norm listet die Control-Typ-Sub-Funktionen, den communicationType-Parameter mit seinen Feldern für Nachrichtentyp und Subnetz und die Regel, dass der Service session-abhängig ist. Weil er ändert, welche Nachrichten das Steuergerät sendet und empfängt, ist er an die Session gebunden und wird bei Rückkehr in die Default Session oder nach einem Reset wiederhergestellt. Der Transport auf CAN ist ISO 15765-2.
Was es in der Praxis bedeutet
CommunicationControl ist ein Flash-Helfer, kein alltäglicher Lese-Service, und gehört in die Extended oder Programming Session. Bei der Validierung wird geprüft:
- der Service antwortet nur in der vorgesehenen Session und gibt in der Default Session NRC 0x7F;
- ein unbekannter Control-Typ gibt NRC 0x12 und ein nicht unterstützter communicationType gibt NRC 0x31;
- ein fehlendes communicationType-Byte gibt NRC 0x13;
- die normale Kommunikation wird bei Session-Timeout, Session-Wechsel und Reset wiederhergestellt.
Der sicherheitsrelevante Fehler ist ein Steuergerät, das nach dem Abziehen des Testers stumm bleibt. Wir sehen regelmäßig Steuergeräte, bei denen CommunicationControl den normalen Verkehr weiter abschaltet, weil der S3-Timeout oder Reset ihn nicht wiederherstellt, was eine Funktion bis zu einem Power-Cycle vom Bus nehmen kann.
Wie AutoST es testet
AutoST markiert CommunicationControl bei der Enumeration als riskanten Service, hält fest, in welchen Sessions er mit welchen negativen Antwortcodes reagiert, und prüft, dass die normale Kommunikation nach dem Session-Ende zurückkehrt. Weil er das Busverhalten ändert, hält AutoST den Service im risikobewerteten Set, und die Session-Survival-Prüfung der Enumeration macht ein Steuergerät sichtbar, das die Kommunikation nach einem S3-Timeout oder Reset nicht wiederherstellt.
FAQ
Häufig gestellte Fragen
Welche Control-Typ-Sub-Funktionen gibt es?
enableRxAndTx (0x00), enableRxAndDisableTx (0x01), disableRxAndEnableTx (0x02) und disableRxAndTx (0x03). Der Typ entscheidet, ob das Steuergerät weiter empfängt, weiter sendet, beides oder nichts.
Was wählt das communicationType-Byte?
Es wählt, für welche Nachrichten das Control gilt: normale Kommunikation (Applikationsnachrichten), Netzwerkmanagement-Nachrichten oder beide. Das untere Nibble wählt den Nachrichtentyp, das obere Nibble kann ein bestimmtes Subnetz adressieren.
Warum Kommunikation überhaupt abschalten?
Beim Flashen oder während einer Routine würde Applikations- und Netzwerkmanagement-Verkehr stören, also legt der Tester ihn am Steuergerät für die Dauer still und schaltet ihn danach wieder ein. Das Steuergerät muss die normale Kommunikation bei Session-Ende oder Reset wiederherstellen.
Quellen
- ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht, Diagnostic and communication management functional unit, CommunicationControl (0x28)
- ISO 15765-2 Straßenfahrzeuge, Diagnosekommunikation über CAN (DoCAN), Teil 2: Transportprotokoll und Netzwerkschichtdienste
Passende Seiten
- GlossarUDS (Unified Diagnostic Services)UDS (ISO 14229) ist das Diagnoseprotokoll der meisten Steuergeräte: Sessions, Services, DIDs, SecurityAccess. Was es definiert und warum es die erste Angriffsfläche ist.
- GlossarDiagnose-Session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) wechselt ein Steuergerät zwischen Default, Extended und Programming Session. Bytes, Timing-Parameter und was zu prüfen ist.
- GlossarTesterPresent (0x3E)UDS TesterPresent (0x3E) hält eine Non-Default Session am Leben. Request- und Response-Bytes, das Suppress-Bit, der S3-Server-Timer und die Session-Bugs am Prüfstand.
- PlattformKenne jede Tür ins ECU.AutoST enumeriert ein ECU über UDS: Diagnose-Endpunkte, Sessions, alle 255 Services und lesbare DIDs, plus XCP/CCP. Riskante Services werden markiert.
- InsightsECU-Reset- und Session-Handling-Fehler, und wie du sie testestWie du UDS-Session- und Reset-Verhalten testest: Session-Rückfall, S3-Timeout, Security-Zustand nach Reset, TesterPresent und was jedes Ergebnis bedeutet.
- Kostenlose ToolsUDS-Negative-Response-Code-DecoderNegative UDS-Antwort in einer Sekunde dekodieren: 7F 27 35 oder einen Code einfügen, ISO-14229-Namen, abgelehnten Service und Bedeutung bekommen. Mit NRC-Tabelle.
