Quelltext der Seite Unified Diagnostic Services

'''Unified Diagnostic Services''' ('''UDS'''; deutsch etwa „''vereinheitlichte Diagnosedienste''“) ist ein Diagnose-Kommunikationsprotokoll im [[Steuergerät]]e-Umfeld innerhalb der [[Automobilelektronik]], welches in der ISO 14229<ref>https://www.iso.org/standard/72439.html</ref> spezifiziert ist. Entstanden ist es aus der [[ISO]] 14230-3 ([[KWP2000]]) und der ISO 15765 (Diagnostic communication over Controller Area Network (DoCAN)). ''Vereinheitlicht'' bedeutet in diesem Zusammenhang, dass dieses Kommunikationsprotokoll bei fast allen Neuentwicklungen der Fahrzeughersteller verwendet wird und kein firmenspezifischer Standard ist.

Die Idee des Protokolls ist es, alle in einem Fahrzeug verbauten [[Steuergerät]]e mit Hilfe von UDS kontaktieren und warten zu können. Die Diagnosedienste spielen sich hierbei auf einer anderen Ebene ab als z. B. das CAN-Protokoll, das nur die erste und zweite Schicht des [[OSI-Modell]]s verwendet. Der UDS-Dienst selbst nutzt die fünfte und siebte Schicht des OSI-Modells.
Moderne Fahrzeuge besitzen für die Off-Board-Diagnose eine [[On-Board-Diagnose|Diagnoseschnittstelle]], die es ermöglicht, einen Rechner ([[Client]]), welcher in diesem Zusammenhang als ''Tester'' bezeichnet wird, an das [[Bus (Datenverarbeitung)|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.

== Dienste ==
Eine UDS-Botschaft ist immer einheitlich aufgebaut und unterteilt sich in SID-Feld (Service-ID), Parameterfeld und Datenfeld. Die  Kommunikation funktioniert nach dem Anfrage-Antwort-Prinzip. Der Client startet mit einer Anfrage an das Steuergerät den Dienst und dieses sendet nach Beendigung des Dienstes eine positive oder negative Antwort zurück. Wenn die Ausführung des Dienstes länger dauert als die vorgegebene Laufzeit, dann muss 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.

UDS selbst erlaubt Botschaften beliebiger Länge. Deshalb wird die maximale Größe durch das jeweils eingesetzte Transportprotokoll vorgegeben. Beim häufig verwendeten ISO-TP ([[ISO 15765-2]]) sind zum Beispiel Botschaften bis zu einer Länge von 4095 Byte erlaubt.

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ückgesendet. Nur in gewissen Fehlerfällen gibt es noch eine negative Antwort vom Steuergerät. Dies wird vor allem bei der sogenannten funktionalen Adressierung eingesetzt. Dabei handelt es sich um einen [[Broadcast]] an alle Steuergeräte. Dienste, die nur an ein Steuergerät adressiert sind, nennt man dagegen physikalisch adressiert.

Auch die Antwortbotschaften haben eine eigene ID. Diese entspricht im positiven Fall immer der SID der Anfrage plus $40. Die ID bei negativen Antworten ist $7F.

=== Funktionsgruppe "Diagnostic and Communications Management" ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|-
| style="text-align:center" | $10 
| 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 zu werden brauchen:

* In der „Programming Session“ sind die Funktionen zum Hochladen von Software in das Steuergerät freigeschaltet.
* Die „Erweiterte Diagnose-Session“ kann verwendet werden, um zusätzliche Diagnosefunktionen freizuschalten, wie die Justierung 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.
|-
| style="text-align:center" | $11 
| 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-Aus-An-Reset“ simuliert das Ab- und Anschalten der Zündung mit dem Schlüssel.
* Der „Soft Reset“ ermöglicht eine Initialisierung bestimmter Programmanteile und deren Speicherstrukturen

Auch hier gibt es einen reservierten Bereich, in dem Fahrzeughersteller und Fahrzeugzulieferer eigene Resets definieren können.
|-
| style="text-align:center" | $27 
| Security Access
| Damit nicht alle Dienste von jedem durchgeführt werden können, kann mit diesem Dienst eine Sicherheitsabfrage durchgeführt werden. Dazu sendet der Tester eine Anfrage an das Steuergerät. Daraufhin generiert das Steuergerät einen sogenannten „Seed“ (eine Zufallszahl), und schickt sie zurück. Der Tester berechnet daraus mittels einer geheimen Funktion einen Schlüssel (eine Zahl), den er an das Steuergerät zurücksendet. Das Steuergerät prüft, ob die Zahl korrekt berechnet wurde, und kann daraufhin sicherheitskritische Dienste freischalten. 
|-
| style="text-align:center" | $28 
| Communication Control
| Mit diesem Dienst kann sowohl das Versenden als auch das Empfangen von Botschaften im Steuergerät abgeschaltet werden.
|-
|$29
|Authentication
|Durch ein Update des Standards im Jahr 2020 wurde dieser Dienst hinzugefügt. Der Dienst bietet modernere Methoden zur Authentifizierung als der "Security Access" ($27) Dienst, darunter die bidirektionale Authentifizierung durch ein auf [[Public-Key-Infrastruktur]] oder [[Challenge-Response-Authentifizierung]] basierten Zertifikataustausch.
|-
| style="text-align:center" | $3E 
| 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.
|-
| style="text-align:center" | $83 
| 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.
|-
| style="text-align:center" | $84 
| Secured Data Transmission
| 

|-
| style="text-align:center" | $85 
| 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 anomales Verhalten einzelner Geräte hervorrufen können. Wenn zum Beispiel während einer Software-Aktualisierung ein Gerät nicht mehr auf Anfragen antworten kann, sollen die restlichen Geräte im Fahrzeug dies nicht als Fehler speichern.
|-
| style="text-align:center" | $86 
| Response On Event
| Dieser Service erlaubt es, dem Server mitzuteilen, dass er die Übertragung von Antworten auf ein bestimmtes 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.
|-
| style="text-align:center" | $87 
| Link Control
| Der Service Link Control wird zum Einstellen der Baudrate des Diagnosezuganges verwendet. Er ist meist nur bei zentralen Gateways implementiert. Normale Steuergeräte besitzen diesen Dienst in der Regel nicht.
|}

=== Data Transmission ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|- 
| style="text-align:center" | $22 
| 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 (0xFFFF). 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.
|-
| style="text-align:center" | $23 
| Read Memory By Address
| Im Unterschied zum Service „Read Data By Identifier“, bei dem über den Identifier der Inhalt eines Messwertes, einer Kalibriervariable, einer Zeitmarke ("time stamp") und Ähnlichem vom Tester gelesen wird, erfolgt hier der Zugriff auf den Speicher durch Angabe der physikalischen Speicheradresse. 

Dazu muss dem verwendeten Programm 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"-Dateien) im verwendeten Dienstprogramm. Natürlich kann für Testzwecke die Speicheradresse auch durch einfaches Nachsehen im "Map File" des Linkers nach dem Erstellen der Software herausgefunden werden.
|-
| style="text-align:center" | $24
| Read Scaling Data By Identifier
| 
|-
| style="text-align:center" | $2A 
| Read Data By Periodic Identifier
| Mit diesem Dienst werden Werte von einem Steuergerät periodisch gesendet. Die Werte, die gesendet werden sollen, können statisch definiert sein oder erst mit dem Dienst "Dynamically Define Data Identifier" dynamisch definiert werden.<ref>{{Literatur|Autor=|Titel=Road vehicles — Unified diagnostic services (UDS)|Hrsg=|Sammelwerk=|Band=Part 1: Specification and requirements|Nummer=|Auflage=Second edition|Verlag=|Ort=|Datum=2013-03-15|Kapitel=Annex C - Tabelle C.1|Seiten=341|ISBN=}}</ref> 
|-
| style="text-align:center" | $2C 
| 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 einer einzigen Anforderung ("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.
|-
| style="text-align:center" | $2E 
| 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.
|-
| style="text-align:center" | $3D 
| 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.
|}

===  Stored Data Transmission ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|-
| style="text-align:center" | $14 
| 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.
|-
| style="text-align:center" | $19 
| 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.
|}

=== Input/Output Control ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|-
| style="text-align:center" | $2F 
| 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.
|}

=== Remote Activation of Routine ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|-
| style="text-align:center" | $31 
| 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.
Der Start- und der Stop-Botschaft können Parameter mitgegeben werden. Dadurch ist es möglich, jeden erdenklichen projektspezifischen Dienst zu implementieren.
|}

===  Upload/Download ===
{| class="wikitable"
|-
! SID !! Service !! Beschreibung
|-
| style="text-align:center" | $34 
| Request Download
| Das Überspielen neuer Software oder anderer Daten 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.
|-
| style="text-align:center" | $35 
| 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.
|-
| style="text-align:center" | $36 
| 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.
|-
| style="text-align:center" | $37 
| 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.
|-
| style="text-align:center" | $38 
| Request File Transfer
| Dieser Dienst wird benutzt, um eine Datei vom Client zum Server zu übertragen (download) oder vom Server zum Client (upload). Zusätzlich liefert dieser Dienst Informationen über das Dateisystem. Der Dienst ist als Alternative zu den Diensten „Request Download“ und „Request Upload“ gedacht, wenn der Server über ein Dateisystem verfügt.
|}

== Literatur ==
* Werner Zimmermann und Ralf Schmidgall: ''Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur.'' 5. Auflage, Springer Vieweg, 2014, ISBN 978-3-658-02418-5.
* Christoph Marscholik, Peter Subke: ''Datenkommunikation im Automobil''. Hüthig, ISBN 978-3-7785-2969-0

== Einzelnachweise ==
<references />

[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Automobilelektronik]]