Unified Diagnostic Services

Unified Diagnostic Services (UDS) ist ein Kommunikationsprotokoll der Automobilelektronik, welches in der ISO 14229-1 spezifiziert ist. Entstanden ist es aus der ISO 14230-3 (KWP2000), der ISO 15765-3 (Diagnostics on CAN) und der GMLAN-Spezifikation von General Motors (ISO 15765-2).

Die Idee des Protokolls ist es, alle in einem Fahrzeug verbauten Steuergeräte mit Hilfe von UDS kontaktieren und warten zu können. Dazu haben moderne Fahrzeuge eine Diagnoseschnittstelle, die es ermöglicht einen Computer (Client), welcher in diesem Zusammenhang als Tester bezeichnet wird, an das Bus-System des Fahrzeugs anzuschließen. Somit können die in UDS definierten Botschaften an die Steuergeräte gesendet werden, welche die vorgegebenen UDS-Dienste bereitstellen müssen. Damit ist es zum Beispiel möglich, den Fehlerspeicher der einzelnen Steuergeräte abzufragen oder diese mit einer neuen Firmware zu aktualisieren.

Transportprotokoll

Da die in Fahrzeugen verwendeten Netzwerke keine Botschaften dieser Größe erlauben, müssen Transportprotokolle eingesetzt werden, die die Nachrichten auf mehrere Botschaften verteilen und beim Empfänger wieder zusammenzusetzen. Beim sehr häufig verwendeten CAN-Bus, mit einer maximalen Botschaftsgröße von nur 8 Byte, wird zum Beispiel das ISO-Transportprotokoll (ISO 15765-2) verwendet.

Dienste

Jeder Dienst muss durch einen Aufruf vom Client gestartet werden und ist erst beendet, wenn das Steuergerät durch eine positive oder negative Antwort die Anfrage beantwortet hat. Damit auch bei länger dauernden Diensten der Client eine Bestätigung bekommt, kann das Steuergerät in regelmäßigen Abständen eine vorläufige Antwort (requestCorrectlyReceived-ResponsePending) senden. Diese bestätigt den Erhalt der Anfrage, teilt aber mit, dass die Ausführung noch andauert. Aber auch in diesem Fall muss der Dienst durch eine abschließende Antwort noch bestätigt werden.

UDS bietet zusätzlich die Möglichkeit, auf eine Antwort vom Steuergerät zu verzichten. Dazu ist in jeder UDS Botschaft ein extra Bit vorgesehen. Ist dieses Bit gesetzt wird keine Antwort auf einen erfolgreich durchgeführten Dienst zurück gesendet. Nur im Fehlerfall gibt es weiterhin eine Rückmeldung.

Diagnostic Session Control

UDS kennt verschiedene Betriebs-Sessions in die man mit dem Dienst „DiagnosticSessionControl“ wechseln kann. Je nachdem welche Session gerade aktiv ist, sind unterschiedliche Dienste freigeschaltet. Beim Start befindet sich das Steuergerät standardmäßig in der „Default Session“. Daneben sind weitere Sessions definiert, die aber je nach Art des Gerätes nicht implementiert werden müssen:

• In der „Programming Session“ sind die Funktionen zum Hochladen von Software in das Steuergerät frei geschaltet.
• Die „Erweiterte Diagnose-Session“ kann verwendet werden, um zusätzliche Diagnosefunktionen frei zu schalten, wie die Justage von Sensoren.
• Die „Sicherheits-Diagnose-Session“ schaltet alle sicherheitskritischen Diagnosefunktionen ein, wie zum Beispiel Airbag-Tests.

Zusätzlich gibt es einen reservierten Bereich, in dem Fahrzeughersteller und Fahrzeugzulieferer eigene Sessions definieren können.

ECU Reset

Der Dienst „ECU Reset“ dient zum Neustarten des Steuergeräts (ECU). Hierbei kann, abhängig von der Steuergeräte-Hardware und Implementierung, zwischen verschiedenen Formen des Neustarts gewählt werden, beispielsweise:

• Der „Hard Reset“ simuliert eine Abschaltung der Spannungsversorgung.
• Der „Schlüssel-An-Aus-Reset“ simuliert das An- und Abschalten des Fahrzeugs mit dem Schlüssel. Dies ist vor allem für Systeme relevant, die auch noch nach dem Abschalten des Fahrzeugs mit Strom versorgt sind.
• Der „Soft Reset“ erzwingt einen sofortigen Neustart des Programms. Der Speicher wird dabei nicht neu initialisiert.

Auch hier gibt es einen reservierten Bereich, in dem Fahrzeughersteller und Fahrzeugzulieferer eigene Resets definieren können.

Security Access

Damit nicht alle Funktionen von jedem durchgeführt werden können, gibt es einen Dienst, der eine Sichheitsabfrage durchführt. Erst durch Ausführung dieses Dienstes werden weitere sicherheitskritische Dienste frei geschaltet. Dazu wird vom Steuergerät ein sog. „Seed“ generiert und an den Client gesendet. Dieser kann daraus einen Schlüssel berechnen, den er zurück sendet und damit die benötigten Funktionen freischaltet.

Communication Control

Mit diesem Dienst kann sowohl das Versenden als auch das Empfangen von Botschaften im Steuergerät abgeschaltet werden.

Tester Present

Wenn eine Zeit lang keine Kommunikation mit dem Client mehr stattgefunden hat, verlässt das Steuergerät automatisch die aktuelle Session und kehrt zur „Default Session“ zurück. Deshalb gibt es einen extra Service, der nur dazu dient, dem Gerät zu signalisieren, dass der Client immer noch anwesend ist. Der Client kann dabei bestimmen, ob das Steuergerät auf den Dienst antworten soll oder nicht.

Access Timing Parameter

Bei der Kommunikation zwischen den Steuergeräten und dem Client sind bestimmte Zeiten einzuhalten. Werden diese überschritten, ohne dass eine Botschaft versendet wird, muss davon ausgegangen werden, dass die Verbindung unterbrochen wurde. Diese Zeiten können abgefragt und verändert werden.

Read DTC Information

DTC steht für „Diagnostic trouble codes“. Dabei handelt es sich um Einträge im Fehlerspeicher. Jeder vom Steuergerät erkannte Fehler wird mit einem eigenen Code im Fehlerspeicher abgelegt und kann über UDS jederzeit gelesen werden. Dabei werden neben dem Fehler zusätzliche Informationen abgespeichert, die ebenfalls gelesen werden können. Zum Beispiel werden typischerweise Häufigkeit und Zeitpunkt des Fehlers mit abgespeichert.

Control DTC Settings

Es ist möglich die Erkennung einzelner oder aller Fehler auf einmal ab- und wieder anzuschalten. Dies ist wichtig, wenn Diagnosetätigkeiten im Auto vorgenommen werden, die ein unnormales Verhalten einzelner Geräte hervorrufen können. Wenn zum Beispiel während eines Software-Updates ein Gerät nicht mehr auf Anfragen antworten kann, sollen die restlichen Geräte im Fahrzeug dies nicht als Fehler speichern.

Response On Event

Dieser Service erlaubt es, dem Server mitzuteilen, dass er die Übertragung von Antworten auf ein bestimmten Ereignis starten oder stoppen soll. Darüber hinaus ermöglicht er es, automatisch einen Diagnosedienst auf dem Server auszuführen, wenn ein bestimmtes Ereignis eintritt. Der Client legt dabei das Ereignis und den auszuführenden Dienst fest.

Link Control

Der Service Link Control wird zum Einstellen der Bitrate des Diagnosezuganges verwendet. Er ist meist nur bei zentralen Gateways implementiert. Normale Steuergeräte besitzen diesen Dienst in der Regel nicht.

Read Data By Identifier

Mit diesem Service ist es möglich, einen oder mehrere Werte von einem Steuergerät abzurufen. Dabei kann es sich um Informationen aller Art und unterschiedlicher Länge wie z. B. die Bauteilenummer oder Software-Version handeln. Auch dynamische Werte, wie der augenblickliche Zustand des Sensors können so abgefragt werden.

Dazu erhalten die Werte einen Identifier zwischen 0 und 65535. Dies hat den Vorteil, dass die Werte auch dann noch abgerufen werden können, wenn sich ihre Position im Speicher geändert hat, da ihr Identifier gleich bleibt.

Write Data By Identifier

Mit dem gleichen Identifier können die Werte auch geändert werden. Neben dem Identifier wird dazu der neue Wert mitgesendet. Dieser wird vom Steuergerät auf Länge und Format geprüft und dann abgespeichert.

Read Memory By Address

Im Unterschied zum Service „Read Data By Identifier“, bei dem über den Identifier der Inhalt eines Messwertes, einer Kalibriervariable, eines Timestamps und Ähnlichem vom Tester gelesen wird, erfolgt bei diesem Service der Zugriff auf den Speicher durch Angabe der physikalischen Speicheradresse.

Dazu muss dem verwendeten Tool natürlich die Adresse des Objekts bekannt sein.

Dies geschieht normalerweise automatisiert durch das Importieren speziell für diesen Zweck generierter Dateien (zum Beispiel a2l Files) im verwendeten Tool. Natürlich kann für Testzwecke die Speicheradresse auch durch einfaches Nachsehen im Map File des Compilers nach dem Buildprozess herausgefunden werden.

Read Data By Periodic Identifier

Mit diesem Dienst werden Werte von einem Steuergerät peridoisch gesendet. Die Werte, die gesendet werden sollen, müssen zu erst mit dem Dienst "Dynamically Define Data Identifier" definiert werden.

Dynamically Define Data Identifier

Dieser Service bietet die Möglichkeit, aus einem für ein Gerät fix festgelegten Data Identifier(DID) Pool, einen weiteren Data Identifier zu konfigurieren. Dieser ist meist eine Kombination aus Teilen von verschiedenen DIDs oder einfach eine Verkettung kompletter DIDs. Damit lassen sich nun zum Beispiel für Testzwecke ursprünglich getrennte Datenobjekte mit einem einzigen Request auslesen.

Die angefragten Daten können auf folgende Weise konfiguriert bzw. gruppiert werden:

• Quell-DID, Position, Länge (in Bytes) → Sub-Function Byte: defineByIdentifier
• Speicheradresse, Länge (in Bytes) → Sub-Function Byte: defineByMemoryAddress
• Kombinationen der beiden oberen Methoden durch mehrere Requests.

Dieser Service wird sessionabhängig teilweise durch den Einsatz des sogenannten „Security Access“ Features vor unberechtigter Benutzung geschützt.

Write Memory By Address

Für das Schreiben kleinerer Datenmengen direkt in den EEPROM der ECU oder zum Löschen des gesamten Speichers kann der Dienst Write Memory By Address verwendet werden.

Clear Diagnostic Information

Neben dem Löschen des gesamten Fehlerspeichers ist es auch möglich, nur eine bestimmte Gruppe von Fehlern zu löschen. So kann man sich darauf beschränken, nur Fehler, die zum Beispiel den Bereich Antriebsstrang betreffen, aus dem Fehlerspeicher zu entfernen.

Input Output Control By Identifier

Dieser Service ermöglicht ein externes Eingreifen auf systeminterne/externe Signale über die Diagnoseschnittstelle. Zum Beispiel können damit Ausgänge geschaltet werden und Eingangssignale (zum Beispiel Schalter) simuliert werden.

Durch Angabe eines Data Identifiers können Ausgänge bzw. Eingänge in Gruppen (zum Beispiel digitale Eingänge vs. analoge Eingänge) zusammengefasst werden.

Durch Angabe eines sogenannten OptionBytes können zusätzliche Bedingungen für einen Request angegeben werden, folgende Werte sind spezifiziert:

ReturnControlToECU

Dieser OptionByte-Wert teilt dem Gerät mit, dass es nach dem Eingreifen des Testers wieder die Kontrolle über die angeführten Signale übernehmen soll.

ResetToDefault

Über diesen Wert fordert der Tester das Zurücksetzen von Signalen auf den systeminternen Default-Wert.

FreezeCurrentState

Dieser Wert fordert das Gerät auf, den aktuellen Signalwert einzufrieren.

ShortTermAdjustment

Bei einem „ShortTermAdjustment“ Request kann durch Angabe einer sogenannten „Activation Time“ die Lebensdauer eines geforderten Signalverhaltens bestimmt werden. Nach Ablauf der Activation Time geht die Kontrolle wieder an das Steuergerät zurück.

Routine Control

Mit dem Routine Control Service können Dienste aller Art ausgeführt werden. Dazu gibt es drei verschiedene Botschaftstypen:

• Mit der Start-Botschaft kann ein Dienst angestoßen werden. Dabei kann frei definiert werden, ob der Dienst mit der positiven Antwort abgeschlossen ist oder ob damit nur der Beginn der Ausführung bestätigt wird.
• Mit der Stop-Botschaft kann ein laufender Dienst jederzeit unterbrochen werden.
• Als dritte Möglichkeit gibt es eine Botschaft zum Abfragen der Resultate des Dienstes.

Allen drei Botschaftstypen können Parameter mitgegeben werden. Dadurch ist es möglich, jeden erdenklichen projektspezifischen Dienst zu implementieren.

Request Download

Das Überspielen neuer Software ins Steuergerät wird mit dem Dienst „Request Download“ eingeleitet. Dabei wird der Speicherort und die Größe der Daten angegeben. Im Gegenzug gibt das Steuergerät an, wie groß die Datenpakete sein dürfen, mit der die Software übertragen wird.

Request Upload

Der Dienst „Request Upload“ ist fast identisch zum Dienst „Request Download“. Mit diesem Dienst wird das Herunterladen der Software vom Steuergerät zurück zum Tester eingeleitet. Dazu werden der Speicherort und die Größe angegeben. Auch hier wird vom Tester die Größe der Datenblöcke angegeben.

Transfer Data

Für die eigentliche Übertragung von Daten gibt es extra den Dienst „Transfer Data“. Dieser Dienst wird sowohl für das Hochladen als auch für das Herunterladen von Daten verwendet. Die Übertragungsrichtung wird dabei vorher festgelegt durch die Dienste „Request Download“ oder „Request Upload“. Dabei dürfen immer nur maximal so viele Daten auf einmal übertragen werden, wie in diesen Diensten vorher festgelegt wurde. Wenn der Datensatz größer ist, muss der „Transfer Data“-Dienst mehrmals hintereinander verwendet werden, bis alle Daten angekommen sind.

Request Transfer Exit

Abgeschlossen wird eine Datenübertragung immer mit dem Dienst „Transfer Exit“. Der Dienst dient noch mal zum Abgleich zwischen Steuergerät und dem Tester. Wird dieser Dienst ausgeführt, obwohl die Datenmenge, die im Dienst „Request Download“ oder „Request Upload“ festgelegt wurde, noch nicht übertragen wurde, dann kann das Steuergerät dies mit einer negativen Antwort anzeigen.

Literatur

• Werner Zimmermann und Ralf Schmidgall: Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur. Vieweg+Teubner, 4. Auflage, 2010, ISBN 978-3-8348-0907-0
• Christoph Marscholik, Peter Subke: Datenkommunikation im Automobil. Hüthig, ISBN 978-3-7785-2969-0