Understand "Unified Diagnostic Services (UDS)", Part.2
In the previous Understand "Unified Diagnostic Services (UDS)", Part.1 Introduction I have explained what is UDS, I have explained why it is important and needed. In this blog, I going to jump into technical details.
We’ll be defining some terminologies along our way to help us understand how UDS works when tester (AKA Client) makes a request and the ECU (AKA Server) will respond.
Diagnostic services
It is a service provided by the server to the client to exchange information or change a behavior. For example, the client might need to read data from the server. Or the client might want to change the state of the server to a state where more data is only available to a privileged client.
So the server will offer few services and each service will be given a hex number. For example, if tester wants to read certain data, the tester has to use “read service” which is 0x22 and so on.
Every service provided by the server will have a number which is called SID (Service Identifier) and certain functionality.
I will explain the most important services that almost every ECU in your vehicle will have. And I will explain how the whole request can be constructed and how to decode the response in a meaningful way.
One more thing to mention, there are services with subfunctions and services without subfunctions. For example, “read service” doesn’t need subfunction, you only need to provide DID (Data identifier) of which you want to read. On the other hand, services like “DiagnosticSessionControl”, you will need to provide subfunction to the request, this subfunction will determine to what session you want the ECU to go to.
List of most important Diagnostic services
DiagnosticSessionControl 0x10
ECUReset 0x11
SecurityAccess 0x27
TesterPresent 0x3E
ReadDataByIdentifier 0x22
WriteDataByIdentifier 0x2E
ClearDiagnosticInformation 0x14
ReadDTCInformation 0x19
InputOutputControlDataIdentifier 0x2F
Service “DiagnosticSessionControl 0x10”
Every ECU that implements UDS has what is called “Diagnostic sessions”. The diagnostic session, in short, is a state in which the ECU determines what is available for diagnosis. For example, you can read X and Y in a certain session and you can read X and Z in another session.
Nearly every ECU I worked on had at least 3 main sessions:
0x01 default session: which is the default state when the ECU is in the normal running state
0x03 extended session: which is the state where all diagnostic services are available ( doesn’t mean accessible yet)
0x02 programming session: which is the state where the ECU switch from application software to its bootloader software where you can the client can update the application with a new version and fix.
Constructing request with DiagnosticSessionControl Service:
To enter each of the following sessions, tester (client) shall send a message with payload:
Request Default session → $10 01
Request Extended session → $10 03
Request Programming session → $10 02
-------------------------------------------
Now I wouldn’t continue with explaining the rest of the services until I explain some basics about requests, responses construction, and server response behavior.
Then why did I explain DiagnosticSessionControl Service since I shouldn’t explain services now? The truth is, if I kept explaining each service and how to make a request and response, I will be rewriting the ISO document, which is not my intention. My intention is to lay basic understanding for you to be able to open ISO 14229 and find your way through it, but at the same time, I needed you to understand what services are and use one example (The most basic service) so that you can feel what services could be like.
SO KEEP IN MIND, you will need to read through ISO 14229 whenever you need to find certain information. This is not a summary of ISO 14229, but I would like to think more about this blog series as a user manual, where you will learn how to read through ISO 14229 and find your own way through it.
