Unified Diagnostic Services
Unified Diagnostic Services ( UDS ; German for " unified diagnostic services ") is a diagnostic communication protocol in the control unit environment within automotive electronics , which is specified in ISO 14229. It arose from ISO 14230-3 ( KWP2000 ) and ISO 15765 (Diagnostic communication over Controller Area Network (DoCAN)). In this context, standardized means that this communication protocol is used in almost all new developments by vehicle manufacturers and is not a company-specific standard.
The idea of the protocol is to be able to contact and maintain all control units installed in a vehicle with the help of UDS. The diagnostic services play here on a different level than z. B. the CAN protocol, which only uses the first and second layers of the OSI model . The UDS service itself uses the fifth and seventh layers of the OSI model. Modern vehicles have a diagnostic interface for off-board diagnostics , which makes it possible to connect a computer ( client ), which in this context is referred to as a tester , to the bus system of the vehicle. In this way, the messages defined in UDS can be sent to the control units that have to provide the specified UDS services. This makes it possible, for example, to query the fault memory of the individual control units or to update them with new firmware .
services
A UDS message is always structured uniformly and is divided into a SID field (service ID), parameter field and data field. Communication works on the request-response principle. The client starts the service with a request to the control unit and the control unit sends back a positive or negative response after the service has ended. If the execution of the service takes longer than the specified runtime, the control unit must send a preliminary response (requestCorrectlyReceived-ResponsePending) at regular intervals. This confirms the receipt of the request, but informs you that the execution is still ongoing.
UDS itself allows messages of any length. Therefore, the maximum size is specified by the transport protocol used. With the frequently used ISO-TP ( ISO 15765-2 ), for example, messages up to a length of 4095 bytes are allowed.
UDS also offers the option of not receiving a response from the control unit. An extra bit is provided for this in every UDS message. If this bit is set, no response to a successfully performed service is sent back. There is only a negative response from the control unit in certain error cases. This is mainly used for so-called functional addressing. This is a broadcast to all control units. Services that are only addressed to one control unit, on the other hand, are called physically addressed.
The reply messages also have their own ID. In the positive case, this always corresponds to the SID of the request plus $ 40. The ID for negative answers is $ 7F.
Function group "Diagnostic and Communications Management"
| SID | service | description |
|---|---|---|
| $ 10 | Diagnostic session control | UDS knows different operating sessions to which you can switch with the "DiagnosticSessionControl" service. Different services are enabled depending on which session is currently active. When starting, the control unit is in the "Default Session" by default. In addition, other sessions are defined which, depending on the type of device, do not need to be implemented:
There is also a reserved area in which vehicle manufacturers and vehicle suppliers can define their own sessions. |
| $ 11 | ECU reset | The "ECU Reset" service is used to restart the control unit (ECU). Depending on the ECU hardware and implementation, you can choose between different types of restart, for example:
Here, too, there is a reserved area in which vehicle manufacturers and vehicle suppliers can define their own resets. |
| $ 27 | Security Access | So that not all services can be carried out by everyone, a security query can be carried out with this service. To do this, the tester sends a request to the control unit. The control unit then generates a so-called “seed” (a random number) and sends it back. The tester uses a secret function to calculate a key (a number), which it sends back to the control unit. The control unit checks whether the number has been calculated correctly and can then activate safety-critical services. |
| $ 28 | Communication Control | With this service, both the sending and receiving of messages in the control unit can be switched off. |
| $ 3E | Tester present | If there has been no communication with the client for a while, the control unit automatically leaves the current session and returns to the "default session". Therefore there is an extra service that only serves to signal the device that the client is still present. The client can determine whether the control unit should respond to the service or not. |
| $ 83 | Access timing parameters | Certain times must be observed when communicating between the control units and the client. If these are exceeded without a message being sent, it must be assumed that the connection has been interrupted. These times can be queried and changed. |
| $ 84 | Secured data transmission | |
| $ 85 | Control DTC Settings | It is possible to switch the detection of individual or all errors off and on again at once. This is important when performing diagnostic activities in the car that could cause individual devices to behave abnormally. If, for example, a device can no longer respond to queries during a software update, the remaining devices in the vehicle should not save this as an error. |
| $ 86 | Response on event | This service allows the server to be informed that it should start or stop the transmission of responses to a specific event. In addition, it makes it possible to automatically run a diagnostic service on the server when a certain event occurs. The client defines the event and the service to be performed. |
| $ 87 | Link Control | The Service Link Control is used to set the baud rate of the diagnostic access. It is usually only implemented in central gateways. Normal control units usually do not have this service. |
Data transmission
| SID | service | description |
|---|---|---|
| $ 22 | Read data by identifier | With this service it is possible to call up one or more values from a control unit. This can be information of all kinds and of different lengths such as B. act the part number or software version. Dynamic values such as the current state of the sensor can also be queried in this way. The values are given an identifier between 0 and 65535 (0xFFFF). This has the advantage that the values can still be called up even if their position in the memory has changed, since their identifier remains the same. |
| $ 23 | Read memory by address | In contrast to the "Read Data By Identifier" service, in which the content of a measured value, a calibration variable, a time stamp and the like is read by the tester via the identifier, the memory is accessed here by specifying the physical Memory address.
To do this, the program used must of course know the address of the object. This is usually done automatically by importing files specially generated for this purpose (for example ".a2l" files) into the utility program used. Of course, the memory address can also be found out for test purposes by simply looking in the "Map File" of the linker after creating the software. |
| $ 24 | Read Scaling Data By Identifier | |
| $ 2A | Read Data By Periodic Identifier | With this service, values are periodically sent from a control unit. The values to be sent can be statically defined or only dynamically defined with the "Dynamically Define Data Identifier" service. |
| $ 2C | Dynamically Define Data Identifier | This service offers the option of configuring a further data identifier from a fixed data identifier (DID) pool for a device. This is usually a combination of parts of different DIDs or simply a chain of complete DIDs. In this way, for test purposes, for example, originally separate data objects can now be read out with a single "request".
The requested data can be configured or grouped in the following way:
Depending on the session, this service is partially protected against unauthorized use by using the so-called "Security Access" feature. |
| $ 2E | Write Data By Identifier | The values can also be changed with the same identifier. In addition to the identifier, the new value is also sent. This is checked by the control unit for length and format and then saved. |
| $ 3D | Write memory by address | The Write Memory By Address service can be used to write smaller amounts of data directly into the EEPROM of the ECU or to erase the entire memory. |
Stored data transmission
| SID | service | description |
|---|---|---|
| $ 14 | Clear Diagnostic Information | In addition to deleting the entire error memory, it is also possible to delete only a certain group of errors. You can limit yourself to only removing errors from the error memory that relate to the powertrain area, for example . |
| $ 19 | Read DTC information | DTC stands for "Diagnostic Trouble Codes". These are entries in the error memory . Every error recognized by the control unit is stored with its own code in the error memory and can be read at any time via UDS. In addition to the error, additional information is saved that can also be read. For example, the frequency and time of the error are typically also stored. |
Input / output control
| SID | service | description |
|---|---|---|
| $ 2F | Input Output Control By Identifier | This service enables external intervention in system-internal / external signals via the diagnostic interface. For example, it can be used to switch outputs and simulate input signals (e.g. switches).
By specifying a data identifier, outputs or inputs can be combined in groups (e.g. digital inputs vs. analog inputs). By specifying a so-called option byte, additional conditions can be specified for a request, the following values are specified:
|
Remote activation of routine
| SID | service | description |
|---|---|---|
| $ 31 | Routine control | All types of services can be carried out with the Routine Control Service. There are three different message types for this:
The start and stop messages can be given parameters. This makes it possible to implement every imaginable project-specific service. |
Upload / download
| SID | service | description |
|---|---|---|
| $ 34 | Request download | The transfer of new software or other data to the control unit is initiated with the "Request Download" service. The storage location and the size of the data are specified. In return, the control unit specifies how large the data packets may be with which the software is transmitted. |
| $ 35 | Request upload | The “Request Upload” service is almost identical to the “Request Download” service. This service initiates the download of the software from the control unit back to the tester. The storage location and size are specified for this. Here, too, the tester specifies the size of the data blocks. |
| $ 36 | Transfer data | The “Transfer Data” service is available for the actual transfer of data. This service is used for both uploading and downloading data. The direction of transmission is determined in advance by the “Request Download” or “Request Upload” services. The maximum amount of data that can be transferred at one time is the amount previously specified in these services. If the data set is larger, the "Transfer Data" service must be used several times in succession until all data has arrived. |
| $ 37 | Request transfer exit | A data transfer is always concluded with the "Transfer Exit" service. The service is used again for the comparison between the control unit and the tester. If this service is carried out although the amount of data that was specified in the “Request Download” or “Request Upload” service has not yet been transferred, the control unit can indicate this with a negative response. |
| $ 38 | Request file transfer | This service is used to transfer a file from the client to the server (download) or from the server to the client (upload). This service also provides information about the file system. The service is intended as an alternative to the "Request Download" and "Request Upload" services if the server has a file system. |
literature
- Werner Zimmermann and Ralf Schmidgall: Bus systems in vehicle technology - protocols, standards and software architecture. 5th edition, Springer Vieweg, 2014, ISBN 978-3-658-02418-5 .
- Christoph Marscholik, Peter Subke: Data communication in automobiles . Hüthig, ISBN 978-3-7785-2969-0
Individual evidence
- ↑ https://www.iso.org/standard/72439.html
- ^ Road vehicles - Unified diagnostic services (UDS) . Second ed.Part 1: Specification and requirements, March 15, 2013, Annex C - Table C.1, p. 341 .