UDS Overview

Micael Coutinho,Wed Nov 09 2022 • autosar bsw dcm

UDS is the diagnostics language all ECU's speak nowadays, linked to the Autosar DCM module. Learn its basic services here

I'm guessing you heard about UDS (Unified Diagnostic Services) at least some time in your life, or, at least, OBD2 (On-Board Diagnostics 2). If these terms sound familiar to you, you're already on the right path to knowing what vehice diagnostics are and the way they are performed.

UDS (Unified Diagnostic Services) is a widely used protocol in production vehicles, for diagnostics. The protocol (ISO 14229) has been around for ages, and it's hard to find a vehicle that does not implement this communication layer. According to the OSI layer, UDS sits between the session and application layers. The remaining layers are handled via the ECU's communication stack, which is likely CAN. It's a client-server protocol, where the ECU is the server, and the client is a testing tool, which can be an OBD2 connector from Amazon.

UDS and the OSI Model, configured via CAN in this example { w: 373, h: 340 }

UDS and the OSI Model, configured via CAN in this example

When your mechanic mentions it connected your vehicle to a computer, he's saying that used the OBD2 port on your vehicle to connect via UDS with some program he overpaid for to get the diagnostics your vehicle picked up along the way. So, you can already decipher the first advantage of UDS: it makes diagnosis of problems easier. But does it stop there? No, not really, and it can also be useful during development. Let's see some of the main advantages of UDS:

Error diagnosis - UDS is just a protocol, but when combined with different diagnostic modules in Autosar (such as the ones we overviewed on the recent article What are DEM, DLT, DCM and DET (opens in a new tab)), the ECU network of your vehicle can inform you of all problems, through the fault memory on the ECU's (which store the errors detected while driving).
ECU Reprogramming - During development, you can use Xcp for reprogramming purposes (more on Xcp soon, but if you want, you can dive into the calibration world, in The Basics of A2L Files (opens in a new tab) and Calibration Overview (opens in a new tab)), but it's not your only option, and you cannot use it in production, making it a lesser choice than reprogramming via UDS.

Now, these are the two main reasons UDS is used, but there is more you can do with it. A better way to better understand UDS is by learning about the services it provides. A side-note, all SID requests are responded with 0x40 + request SID, unless an error occurs. And, the OEM's can complete the command responses with their own reserved values, so it's not limited to what we're mentioning here.

Diagnostic / communication management:

Service Name	SID	Description
Diagnostic Session Control	0x10	Switch between operating sessions. These sessions provide access to a subset of commands. There can be OEM-specific sessions, but the most common are: default session (enabled from reset), extended session (allows an extra set of diagnostic functions), programming session (used for ECU reprogramming) and safety system diagnostic session (used for safety-cricical diagnostics). The session is restored in case of a timeout. To avoid it, read the Tester Present service
ECU Reset	0x11	Resets the ECU. Some of the reset types are: hard reset (emulates a shutdown of the power supply) and soft reset
Security Access	0x27	Allow access to security-relevant services
Communication Control	0x28	Control the sending and reception of messages to and from the ECU
Authentication	0x29	Used for the same purpose as the Security Access service, but for modern security athentication methods. Exists since 2020
Tester Present	0x3E	Ping the ECU in order to keep the current session active
Access Timing Parameters	0x83	Change the connection timing parameters between the ECU and the client, in order to avoid timeouts while communicating
Secure Data Transmission	0x84	Used to transmit data in a secure mode, adding chryptographic protection
Control DTC Setting	0x85	Control DTC detection for specific or all errors. Useful when anomalous behaviors are triggered (for example, by maintenance work on a vehicle)
Response On Event	0x86	Configure a specific diagnostic service to get triggered in response to an event on the server
Link Control	0x87	Set the baud rate for diagnostic access. Usually available only on the gateway ECU

Data Transmission:

Service Name	SID	Description
Read Data by Identifier	0x22	Retrieve values from the ECU. Usually, many values are available for the user, and most of them are OEM-specific. Of course, some are obvious, such as the software version or part number
Read Memory by Address	0x23	Read memory from an address (if it's made available by the ECU, there are rules to this). Sort-of works as an upload command in calibration
Read Scaling Data by Identifier	0x24	Read scaling data of a specific DID
Read Data by Identifier Periodic	0x2A	Retrieve values from an ECU at a periodid pace
Dynamically Define Data Identifier	0x2C	Define a DID to send a set of DID's
Write Data by Data Identifier	0x2E	Write a value to a DID
Write Memory by Address	0x3D	Write to one or a set of contiguous addresses

Stored Data Transmission:

Service Name	SID	Description
Clear Diagnostic Information	0x14	Delete all stored DTC's (Diagnostic Trouble Codes)
Read DTC Information	0x19	Read a DTC state. Additional information can also be read

IO Control:

Service Name	SID	Description
IO Control by Identifier	0x2F	Control a signal in the ECU

Routine Activation:

Service Name	SID	Description
Routine Control	0x31	Trigger a function on the ECU. There are 3 different options: start (to start execution), stop (to interrupt the service) and to retrieve the results of the service

Upload and Download:

Service Name	SID	Description
Request Downlaod	0x34	Write data into the ECU, by specifying address and length
Request Upload	0x35	Read data from the ECU, just as the Request Download service
Transfer Data	0x36	Used to write or read data. The direction is specified via the two former commands (Request Download and Request Upload). As opposed to the former, it can send multiple commands, in case the data is too large to fit in a single packet, where the former are limited to the ECU-configured packet length
Request Transfer Exit	0x37	Used to signal completion of the data transferred. The service can be rejected in case the specified length in Treansfer Data is not reached
Request FIle Transfer	0x38	Download/upload a file from/to the client to/from the server

After all of these services, there is also one message sent via the ECU to your client. You'll see it often, the Negative Response, which has the code 0x7F and signals the service requested could not be performed. There is also a NRC (Negative Response Code) included, giving you a clue on what went wrong.

Before we end this article, I would like to give you a picture on how UDS maps to the Autosar layered architecture. The UDS protocol lies within the DCM (Diagnostic Communication Manager) module, and you can configure all its services there. There is also the option to interface with other modules, most notably DEM (Diagnostic Event Manager), where the DTC's are configured and set. The lower layers are pretty obvious, are the COM-stack you are using (the most common is CAN, an CAN-TP can be used to enhance the size of the PDU's that can be exchanged). Other modules, such as the BSWM (BSW Mode Manager) can be used to provide functionalities, such as the communication control.

As some bottom notes, I would like to mention you don't need to know all these services by heart. You'll deal with them via an external tool. Of course, you'll get the hang of it when you need to put your hands on it. One good exercise is to buy one of those OBD2 connectors, an see how far you can go. Of course, at your own risk!

Author: Micael Coutinho (opens in a new tab)

References: