[DoCAN] Vehicle Diagnostic Communication Part 58 [UDS 19]

Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/

Introduction.
Prerequisite DID resource status
Transmit and receive for single DID
Transmit and receive for multi-DID
Transmit and receive multiple DIDs (if there are unsupported DIDs)
Conclusion.

Introduction.

Explanation of ISO 14229, UDS.
In this article, specific telegrams for the ReadDataByIdentifier service will be explained.

Prerequisite DID resource status

I think the explanation of the ReadDataByIdentifier service is OK since last article, but you may want to see the specific telegrams.
Therefore, I will describe the specific telegrams.

Before that, let’s define a DID resource.
Simply put, a DID resource defines how many bytes long the dataRecord associated with the DID is and what kind of parameters are arranged.
In this case, we will ignore the meaning of the parameters and only define the data length and what fixed data is to be returned.

There are two DIDs, each with the following data length and data.

0x1234:2byte length, 0x01,0x02
0x5678:4byte length, 0x03,0x04,0x05,0x06

The actual data length is often several tens to several hundreds of bytes, but here we have kept it short for ease of reading.

Transmit and receive for single DID

The following is how to transmit and receive for a basic single DID.

Req: 0x22 0x12 0x34		// DID=0x1234 request
Res: 0x62 0x12 0x34 0x01 0x02

Req: 0x22 0x56 0x78		// DID=0x5678 request
Res: 0x62 0x12 0x34 0x03 0x04 0x05 0x06

This would be simple and easy to understand.

Transmit and receive for multi-DID

Transmit and receive in the case of multi-DIDs are as follows.

Req: 0x22 0x12 0x34 0x56 0x78		// DID=0x1234/0x5678 request
Res: 0x62 0x12 0x34 0x01 0x02 0x56 0x78 0x03 0x04 0x05 0x06

Req: 0x22 0x56 0x78 0x12 0x34		// DID=0x5678/0x1234 request
Res: 0x62 0x56 0x78 0x03 0x04 0x05 0x06 0x12 0x34 0x01 0x02

It is a little more complicated, but all it does is request two DIDs and respond with the corresponding recordData for each.

Transmit and receive multiple DIDs (if there are unsupported DIDs)

In addition, let’s describe a more special case.

Req: 0x22 0x11 0x11 0x12 0x34		// DID=0x1111/0x1234 request
Res: 0x62 0x12 0x34 0x01 0x02

Req: 0x22 0x56 0x78 0x22 0x22		// DID=0x5678/0x2222 request
Res: 0x62 0x12 0x34 0x03 0x04 0x05 0x06

You must have been surprised to suddenly see 0x1111 and 0x2222, which you have not defined.
This is just an attempt to see what happens when non-existent DIDs are mixed in.

As you can see, it does not result in an error, but responds with the recordData of the existing DID.
In the case of multiple DIDs, this kind of thing happens, so the DIDs on the response message need to be checked as well.

The question is why not to make an error.

Perhaps they are assuming operation using functional addresses.
The specification is to request multiple identical DIDs from all ECUs and return as many as possible even if there are some unsupported DIDs.

At anyway, I think you have a general understanding of the ReadDataByIdentifier service.