Unified Diagnostic Services – einfach erklärt

Grundidee und Kommunikation

Unified Diagnostic Services (UDS; deutsch etwa „vereinheitlichte Diagnosedienste“) ist ein Diagnose-Kommunikationsprotokoll für Steuergeräte in der Automobilelektronik. Es ist in der ISO 14229 spezifiziert und entstand aus ISO 14230-3 (KWP2000) und ISO 15765 (Diagnostic communication over Controller Area Network, DoCAN). „Vereinheitlicht“ bedeutet hier, dass UDS bei fast allen Neuentwicklungen der Fahrzeughersteller verwendet wird und kein firmenspezifischer Standard ist.

Die Grundidee ist, alle in einem Fahrzeug verbauten Steuergeräte über UDS kontaktieren und warten zu können. UDS arbeitet dabei auf einer anderen Ebene als etwa CAN: CAN nutzt nur die erste und zweite Schicht des OSI-Modells, während der UDS-Dienst selbst die fünfte und siebte Schicht nutzt. Moderne Fahrzeuge besitzen für die Off-Board-Diagnose eine Diagnoseschnittstelle. Darüber kann ein Rechner, der in diesem Zusammenhang Tester genannt wird, an das Bus-System des Fahrzeugs angeschlossen werden. Der Tester sendet UDS-Botschaften an Steuergeräte, die die vorgegebenen UDS-Dienste bereitstellen müssen. So kann man zum Beispiel Fehlerspeicher abfragen oder Steuergeräte mit neuer Firmware aktualisieren.

Eine UDS-Botschaft ist einheitlich aufgebaut: Sie besteht aus SID-Feld (Service-ID), Parameterfeld und Datenfeld. Die Kommunikation folgt dem Anfrage-Antwort-Prinzip. Der Client startet mit einer Anfrage an das Steuergerät einen Dienst. Nach Abschluss sendet das Steuergerät eine positive oder negative Antwort zurück. Dauert die Ausführung länger als die vorgegebene Laufzeit, muss das Steuergerät regelmäßig eine vorläufige Antwort senden: requestCorrectlyReceived-ResponsePending. Diese bestätigt den Erhalt der Anfrage, bedeutet aber, dass die Ausführung noch läuft.

UDS selbst erlaubt Botschaften beliebiger Länge. Die tatsächliche maximale Größe wird deshalb durch das eingesetzte Transportprotokoll bestimmt. Beim häufig verwendeten ISO-TP (ISO 15765-2) sind zum Beispiel Botschaften bis zu 4095 Byte erlaubt. UDS kann außerdem auf eine Antwort des Steuergeräts verzichten: Dafür gibt es in jeder UDS-Botschaft ein extra Bit. Ist es gesetzt, wird bei erfolgreich durchgeführtem Dienst keine Antwort gesendet; nur in bestimmten Fehlerfällen gibt es noch eine negative Antwort. Das wird vor allem bei funktionaler Adressierung genutzt, also einem Broadcast an alle Steuergeräte. Dienste an ein einzelnes Steuergerät heißen physikalisch adressiert. Positive Antwortbotschaften haben als ID immer die SID der Anfrage plus $40; negative Antworten haben die ID $7F.

Diagnose- und Kommunikationsverwaltung

Die Funktionsgruppe „Diagnostic and Communications Management“ umfasst Dienste, mit denen Sitzungen, Sicherheit, Kommunikation und Verbindungsparameter gesteuert werden.

Mit Diagnostic Session Control ($10) kann der Tester zwischen verschiedenen Betriebs-Sessions wechseln. Je nach aktiver Session sind unterschiedliche Dienste freigeschaltet. Beim Start befindet sich das Steuergerät in der „Default Session“. Weitere definierte Sessions sind die „Programming Session“ für Funktionen zum Hochladen von Software in das Steuergerät, die „Erweiterte Diagnose-Session“ für zusätzliche Diagnosefunktionen wie die Justierung von Sensoren und die „Sicherheits-Diagnose-Session“ für sicherheitskritische Diagnosefunktionen wie Airbag-Tests. Nicht jedes Gerät muss alle Sessions implementieren. Zusätzlich gibt es einen reservierten Bereich für eigene Sessions von Fahrzeugherstellern und Fahrzeugzulieferern.

ECU Reset ($11) dient zum Neustarten des Steuergeräts. Je nach Hardware und Implementierung sind verschiedene Neustartformen möglich: Der „Hard Reset“ simuliert eine Abschaltung der Spannungsversorgung, der „Schlüssel-Aus-An-Reset“ simuliert das Ab- und Anschalten der Zündung mit dem Schlüssel, und der „Soft Reset“ initialisiert bestimmte Programmanteile und Speicherstrukturen. Auch hier gibt es einen reservierten Bereich für eigene Reset-Arten.

Security Access ($27) schützt Dienste vor unberechtigter Nutzung. Der Tester sendet eine Anfrage, das Steuergerät erzeugt einen „Seed“, also eine Zufallszahl, und sendet ihn zurück. Der Tester berechnet daraus mit einer geheimen Funktion einen Schlüssel und sendet diesen an das Steuergerät. Wenn das Steuergerät den Schlüssel als korrekt erkennt, kann es sicherheitskritische Dienste freischalten. Authentication ($29) wurde durch ein Update des Standards im Jahr 2020 hinzugefügt. Dieser Dienst bietet modernere Authentifizierungsmethoden als Security Access, darunter bidirektionale Authentifizierung durch Zertifikataustausch auf Basis von Public-Key-Infrastruktur oder Challenge-Response-Authentifizierung.

Communication Control ($28) kann das Senden und Empfangen von Botschaften im Steuergerät abschalten. Tester Present ($3E) verhindert, dass ein Steuergerät bei längerer Kommunikationspause automatisch die aktuelle Session verlässt und zur Default Session zurückkehrt. Der Client kann dabei bestimmen, ob das Steuergerät antworten soll. Access Timing Parameter ($83) erlaubt das Abfragen und Verändern von Zeitparametern der Kommunikation. Secured Data Transmission ($84) ist als Dienst genannt. Control DTC Settings ($85) kann die Erkennung einzelner oder aller Fehler abschalten und wieder einschalten, etwa damit während einer Software-Aktualisierung andere Steuergeräte keine Folgefehler speichern. Response On Event ($86) lässt den Server Antworten auf bestimmte Ereignisse starten oder stoppen oder automatisch einen Diagnosedienst ausführen, wenn ein Ereignis eintritt. Link Control ($87) dient zum Einstellen der Baudrate des Diagnosezugangs und ist meist nur bei zentralen Gateways implementiert.

Daten lesen und schreiben

Die Funktionsgruppe „Data Transmission“ enthält Dienste, mit denen Daten aus Steuergeräten gelesen, definiert oder geändert werden.

Read Data By Identifier ($22) ruft einen oder mehrere Werte von einem Steuergerät ab. Solche Werte können Informationen unterschiedlicher Art und Länge sein, etwa Bauteilenummern, Software-Versionen oder dynamische Werte wie der aktuelle Zustand eines Sensors. Die Werte erhalten einen Identifier zwischen 0 und 65535 (0xFFFF). Das ist nützlich, weil ein Wert über denselben Identifier abrufbar bleibt, auch wenn sich seine Position im Speicher geändert hat.

Read Memory By Address ($23) liest nicht über einen Identifier, sondern direkt über eine physikalische Speicheradresse. Dafür muss das verwendete Programm die Adresse des Objekts kennen. Normalerweise geschieht das automatisiert durch den Import speziell erzeugter Dateien, zum Beispiel „.a2l“-Dateien. Für Testzwecke kann die Speicheradresse auch im „Map File“ des Linkers nach dem Erstellen der Software nachgesehen werden. Read Scaling Data By Identifier ($24) ist als weiterer Dienst genannt.

Read Data By Periodic Identifier ($2A) sorgt dafür, dass Werte periodisch von einem Steuergerät gesendet werden. Diese Werte können statisch definiert sein oder erst durch Dynamically Define Data Identifier ($2C) dynamisch festgelegt werden. Dynamically Define Data Identifier erlaubt es, aus einem festgelegten Data-Identifier-Pool einen weiteren Data Identifier zu konfigurieren. Dieser besteht meist aus Teilen verschiedener DIDs oder aus einer Verkettung kompletter DIDs. So können zu Testzwecken ursprünglich getrennte Datenobjekte mit einer einzigen Anfrage ausgelesen werden. Die Daten können über Quell-DID, Position und Länge in Bytes, über Speicheradresse und Länge in Bytes oder durch Kombinationen dieser Methoden über mehrere Requests gruppiert werden. Der Dienst ist teilweise sessionabhängig durch Security Access geschützt.

Write Data By Identifier ($2E) nutzt denselben Identifier, um Werte zu ändern. Neben dem Identifier wird der neue Wert gesendet. Das Steuergerät prüft Länge und Format und speichert den Wert danach ab. Write Memory By Address ($3D) kann kleinere Datenmengen direkt in den EEPROM der ECU schreiben oder den gesamten Speicher löschen.

Fehlerspeicher und Ein-/Ausgänge

Die Funktionsgruppe „Stored Data Transmission“ betrifft gespeicherte Diagnosedaten, vor allem den Fehlerspeicher. Clear Diagnostic Information ($14) kann den gesamten Fehlerspeicher löschen, aber auch nur bestimmte Fehlergruppen. Man kann sich zum Beispiel darauf beschränken, nur Fehler zu entfernen, die den Bereich Antriebsstrang betreffen. Read DTC Information ($19) liest DTCs aus. DTC steht für „Diagnostic trouble codes“ und bezeichnet Einträge im Fehlerspeicher. Jeder vom Steuergerät erkannte Fehler wird mit einem eigenen Code abgelegt und kann über UDS gelesen werden. Zusätzlich zum Fehler werden weitere Informationen gespeichert, typischerweise Häufigkeit und Zeitpunkt des Fehlers.

Die Funktionsgruppe „Input/Output Control“ enthält den Dienst Input Output Control By Identifier ($2F). Er ermöglicht ein externes Eingreifen in systeminterne oder externe Signale über die Diagnoseschnittstelle. Damit können zum Beispiel Ausgänge geschaltet oder Eingangssignale wie Schalter simuliert werden. Durch Angabe eines Data Identifiers lassen sich Ausgänge oder Eingänge gruppieren, etwa digitale Eingänge gegenüber analogen Eingängen.

Zusätzlich kann ein sogenanntes OptionByte Bedingungen für einen Request angeben. ReturnControlToECU teilt dem Gerät mit, dass es nach dem Eingreifen des Testers wieder selbst die Kontrolle über die genannten Signale übernehmen soll. ResetToDefault fordert das Zurücksetzen von Signalen auf den systeminternen Default-Wert. FreezeCurrentState friert den aktuellen Signalwert ein. ShortTermAdjustment erlaubt durch Angabe einer „Activation Time“, die Lebensdauer eines gewünschten Signalverhaltens festzulegen; danach geht die Kontrolle wieder an das Steuergerät zurück.

Routinen und Datenübertragung

Remote Activation of Routine umfasst den Dienst Routine Control ($31). Mit ihm können Dienste aller Art ausgeführt werden. Es gibt drei Botschaftstypen: Eine Start-Botschaft stößt einen Dienst an. Dabei kann frei definiert werden, ob der Dienst mit der positiven Antwort bereits abgeschlossen ist oder ob dadurch nur der Beginn der Ausführung bestätigt wird. Eine Stop-Botschaft kann einen laufenden Dienst jederzeit unterbrechen. Eine dritte Botschaft fragt die Resultate des Dienstes ab. Start- und Stop-Botschaft können Parameter enthalten, sodass projektspezifische Dienste umgesetzt werden können.

Die Funktionsgruppe „Upload/Download“ dient zur Übertragung von Software oder anderen Daten zwischen Tester und Steuergerät. Request Download ($34) leitet das Überspielen neuer Software oder anderer Daten in das Steuergerät ein. Dabei werden Speicherort und Größe der Daten angegeben. Das Steuergerät antwortet, wie groß die Datenpakete für die Übertragung sein dürfen. Request Upload ($35) ist fast identisch, leitet aber das Herunterladen von Software vom Steuergerät zurück zum Tester ein. Auch hier werden Speicherort und Größe angegeben; die Größe der Datenblöcke wird ebenfalls festgelegt.

Transfer Data ($36) übernimmt die eigentliche Datenübertragung. Dieser Dienst wird sowohl beim Hochladen als auch beim Herunterladen verwendet. Die Richtung wurde vorher durch Request Download oder Request Upload festgelegt. Pro Übertragung dürfen höchstens so viele Daten gesendet werden, wie zuvor festgelegt wurde. Ist der Datensatz größer, wird Transfer Data mehrmals hintereinander verwendet, bis alle Daten angekommen sind.

Request Transfer Exit ($37) schließt eine Datenübertragung ab und dient noch einmal dem Abgleich zwischen Steuergerät und Tester. Wird dieser Dienst ausgeführt, obwohl die zuvor festgelegte Datenmenge noch nicht vollständig übertragen wurde, kann das Steuergerät dies mit einer negativen Antwort anzeigen. Request File Transfer ($38) überträgt eine Datei vom Client zum Server oder vom Server zum Client und liefert zusätzlich Informationen über das Dateisystem. Dieser Dienst ist als Alternative zu Request Download und Request Upload gedacht, wenn der Server über ein Dateisystem verfügt.