ISO 14229-1

Unified Diagnostic Services (UDS) ist ein Übertragungsprotokoll 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) 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

Die Botschaften der einzelnen UDS-Dienste können in ihrer Länge stark variieren. Es sind theoretisch Paketlängen zwischen einem und 4095 Bytes möglich. Der für die Übertragung verwendete CAN-Bus erlaubt aber nur Botschaften mit maximal 8 Byte Daten. Deshalb wird das ISO-Transportprotokoll (ISO 15765-2) verwendet, um die Nachricht auf mehrere Botschaften zu verteilen und beim Empfänger wieder zusammenzusetzen.

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. 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.

Diagnostic Session Control (SID 0x10)

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 zwischen verschiedenen Formen des Neustarts gewählt werden:

• 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“ bedeutet eine sofortigen Neustart des Programms. Der Speicher wird dabei nicht neu initialisiert.

Es ist möglich die sogenannte „schnelle Spannungsabschaltung“ zu aktivieren und zu deaktivieren. Ausgeführt wird diese, wenn die Zündung des Fahrzeugs abgeschaltet wird.

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

Security Access (SID 0x27)

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 eine Zufallszahl 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 Zeitlang 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.

Secured Data Transmission

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 jeder Zeit 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 Softwareupdates 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 ein 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

Read Data By Identifier (SID 0x22)

Mit diesem Service ist es möglich, einen oder mehrere Werte von einem Steuergerät abzurufen. Dabei kann es sich um Informationen aller Art unterschiedlicher Länge wie die Bauteilenummer oder Softwareversion 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 ihre Position im Speicher geändert wird, 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", wo ü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 Files (z.B. 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 Scaling Data Identifier

Read Data By Periodic Identifier

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 z.B. 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

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 Powertrain Bereich 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 (z.B. Schalter) simuliert werden.

Durch Angabe eines Data Identifiers können Ausgänge/Eingänge in Gruppen (z.B. digital Eingänge vs. analoge Eingänge) eingeteilt 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 Defaultwert.

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 jeder Zeit 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, wirklich jeden erdenklichen projektspezifischen Dienst zu implementieren.

Upload und Download Funktionen

Die Aktualisierung der Software ist ein sehr heikler Vorgang. So könnte es passieren, dass bei einer fehlerhaften Übertragung, das Gerät nicht mehr über UDS kontaktierbar wäre. Damit wäre eine Reparatur in einer Kfz-Werkstatt unmöglich und das Gerät unbrauchbar. Deshalb findet die Neuprogrammierung gewöhnlich in einem extra Programm statt. Dieses muss vollkommen unabhängig von der restlichen Software funktionieren können. Erkennt das Programm eine beschädigte Software, verhindert es eine Aktivierung des Steuergeräts und wartet darauf, dass eine neue Software übertragen wird. Dieses Programm kann jederzeit aktiviert werden durch den Aufruf der „Programming Session“.

Literatur

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