UDS is a diagnostic communication protocol in the ECU environment, this diagnostic protocol can interact with all the ECUs in a vehicle that is capable of UDS communication. CAN protocol works on first and second layers, UDS works on fifth and Seventh layers of OSI model, Modern vehicles can connect to off-board diagnostics like connecting it to a client.
The UDS service request message has a data format as specified below:
Uds is a collection of various diagnostic services with a unique service identifier (SID) assigned to each service. SID is a 1-byte length and varies from 0x00 to 0x3E. Based on the SID the server understands what type of service is required by the client. This is mandatory in the UDS command to perform the service.
Next, we have a Sub-function field of 1byte which makes the server understand what kind of subfunction is needed. For example, there is routine control(0x31) in this 0x01 is to start the routine. We do have services that don’t need a subfunction to be specified like reading Data By Identifier (RDBI) / Write Data By Identifier (WDBI). Subfunction is an optional field that may or may not be there. Data Identifier is of 2 bytes, as we know we can only communicate with numbers, the data identifier is used to specify the data element which is to be read. For example, if the tester wants to read total distance traveled then it will send a DID as 0x0585 here both the tester and ECU know that 0x0585 is DID of total distance traveled.
In UDS car manufacturers make their own DIDs so that only their tools can read them. Depending on the service it will be referred to as DID/RID/UID etc. There can be multiple data identifiers in a request message or no data identifiers, it is an optional field.
Data record field is optional as per the service requested, reading data doesn’t need it whereas write needs it. When we give write instruction the data record specifies the data to be written in the destination. It can be taken as metadata of DID which is mandatory for some services only.