ControlDTCSetting (0x85)
UDS ControlDTCSetting (0x85) schaltet das Speichern von Fehlercodes eines Steuergeräts während eines Tests ein oder aus. Die Sub-Funktionen, Bytes und was zu prüfen ist.
Aktualisiert Diese Seite als Markdown
Kurz gesagt
ControlDTCSetting (0x85) schaltet das Speichern von Diagnose-Fehlercodes eines Steuergeräts ein oder aus, damit ein Test den Fehlerspeicher nicht mit eigenen Nebenwirkungen füllt. Die Sub-Funktion wählt ein (01) oder aus (02). Der Request 85 02 stoppt das DTC-Speichern, die positive Antwort C5 02 bestätigt es. Er braucht die Extended Session, und das Steuergerät muss das DTC-Speichern bei Session-Ende oder Reset wieder einschalten.
Was ist ControlDTCSetting (0x85)?
ControlDTCSetting schaltet das Aufzeichnen von Diagnose-Fehlercodes ein oder aus. Das Sub-Funktions-Byte wählt den Zustand: on nimmt die normale DTC-Speicherung wieder auf, off setzt sie für die Dauer der Session aus.
Ein normaler Ablauf:
| Richtung | Bytes | Bedeutung |
|---|---|---|
| Request | 85 02 | DTC-Setting aus |
| Positive Antwort | C5 02 | akzeptiert, Speicherung ausgesetzt |
| Negative Antwort | 7F 85 7F | serviceNotSupportedInActiveSession |
Weitere typische negative Antworten sind 7F 85 12 (subFunctionNotSupported), 7F 85 13 (incorrectMessageLengthOrInvalidFormat) und 7F 85 22 (conditionsNotCorrect).
Wo ist es definiert?
ISO 14229-1:2020 definiert ControlDTCSetting (0x85) im Diagnostic and communication management functional unit. Die Norm beschreibt die Sub-Funktionen on und off, den optionalen DTCSettingControlOptionRecord und die Regel, dass der Service session-abhängig ist, sodass die Einstellung an die aktive Session gebunden und bei Rückkehr in die Default Session wiederhergestellt ist. Der Transport auf CAN ist ISO 15765-2. Die Fehler selbst werden mit ReadDTCInformation (0x19) gelesen.
Was es in der Praxis bedeutet
ControlDTCSetting gehört zu einem Tester, der gleich etwas tut, das sonst Fehler setzen würde, also lebt er in der Extended Session und ist nicht dafür gedacht, im Default erreichbar zu sein. Bei der Validierung wird geprüft:
- der Service antwortet nur in der vorgesehenen Session und gibt in der Default Session NRC 0x7F;
- eine unbekannte Sub-Funktion gibt NRC 0x12 und eine falsche Länge gibt NRC 0x13;
- das DTC-Speichern wird bei Session-Timeout, Session-Wechsel und Reset wieder aufgenommen;
- mit ausgeschalteter Speicherung werden Nebenwirkungsfehler wirklich unterdrückt und die echte Überwachung danach wiederhergestellt.
Der sicherheitsrelevante Fehler ist ein Steuergerät, das das DTC-Speichern nach dem Abziehen des Testers auf off lässt, weil ein später auftretender Fehler dann nicht aufgezeichnet würde. Wir sehen das regelmäßig neben anderen Session-Handling-Bugs, bei denen der Zustand bei einem S3-Timeout nicht zurückgesetzt wird.
Wie AutoST es testet
AutoST hält ControlDTCSetting bei der Enumeration fest, inklusive in welchen Sessions er mit welchen negativen Antwortcodes reagiert, und prüft, dass das DTC-Speichern bei Session-Ende auf on zurückkehrt. Die Session-Survival-Prüfung der Enumeration macht ein Steuergerät sichtbar, das die Einstellung nach einem S3-Timeout oder Reset auf off lässt, und der DTC-Count-Monitor der Fuzzing-Engine liest 0x19, sodass er erkennt, ob die Fehlerspeicherung während eines Laufs wie erwartet arbeitet.
FAQ
Häufig gestellte Fragen
Welche zwei Sub-Funktionen gibt es?
ControlDTCSetting definiert on (0x01), das die DTC-Speicherung wieder aufnimmt, und off (0x02), das sie aussetzt. Ein optionaler DTCSettingControlOptionRecord kann das Control auf eine DTC-Gruppe begrenzen, wenn das Steuergerät es unterstützt.
Warum das DTC-Setting während eines Tests ausschalten?
Eine Diagnosesitzung, eine Routine oder ein Reset kann Fehler setzen, die Nebenwirkungen des Tests sind, keine echten Ausfälle. Das DTC-Speichern auszuschalten hält den Fehlerspeicher sauber, und es wieder einzuschalten stellt danach das normale Verhalten her.
Was muss bei Session-Ende passieren?
Das DTC-Speichern muss auf on zurückkehren. Ein Steuergerät, das die Fehlercode-Speicherung nach Session-Timeout oder Reset auf off lässt, hat einen Session-Handling-Bug, weil ein echter Fehler dann unaufgezeichnet bleiben könnte.
Quellen
- ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht, Diagnostic and communication management functional unit, ControlDTCSetting (0x85)
- ISO 15765-2 Straßenfahrzeuge, Diagnosekommunikation über CAN (DoCAN), Teil 2: Transportprotokoll und Netzwerkschichtdienste
Passende Seiten
- GlossarDTC (Diagnostic Trouble Code, Fehlercode)Ein DTC ist ein Fehlercode, den ein Steuergerät bei einem erkannten Problem speichert. Das 3-Byte-Format in UDS, das Status-Byte, 0x19, 0x14 und die Rolle beim Fuzzing.
- GlossarReadDTCInformation (0x19)UDS ReadDTCInformation (0x19) liest Diagnose-Fehlercodes und ihren Status aus einem Steuergerät. Die Sub-Funktionen, Request- und Response-Bytes und was zu prüfen 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.
- 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-Nachrichten-DecoderUDS-Bytes aus einem Trace einfügen und sehen, was sie bedeuten: Service, Sub-Funktion, Session, DIDs, Routine Identifier, SecurityAccess-Level oder NRC, nach ISO 14229-1.
