[DoCAN] Vehicle Diagnostic Communication Part 59 [UDS 20]

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

Introduction.
WriteDataByIdentifier service
Usage scenarios for WriteDataByIdentifier service
Characteristics of WriteDataByIdentifier service because it often writes to non-volatile memory
Conclusion.

Introduction.

Explanation of ISO 14229, UDS.
This article explains the WriteDataByIdentifier service.

WriteDataByIdentifier service

In this article, I will explain the last service we plan to simulate, the WriteDataByIdentifier service.

Think of it as the reverse of the ReadDataByIdentifier service.
The ReadDataByIdentifier service reads and the WriteDataByIdentifier service writes.
Note, however, that there are some things that are not possible with this approach.

For example, suppose there is a DID that can acquire vehicle speed and engine RPM.
That DID is supported by the ReadDataByIdentifier service, but not by the WriteDataByIdentifier service.
This is because vehicle speed and engine RPM are values obtained by sensors in the vehicle and cannot be allowed to be rewritten from the outside.

So, just remember that it can not always be a pair.

Usage scenarios for WriteDataByIdentifier service

It may be easier to understand if I explain the usage scenario.

However, as was the case with the ReadDataByIdentifier service, the definition of DID is manufacturer-dependent.
Well, as I explained above, the restrictions are stronger than those of the ReadDataByIdentifier service, so it may be possible to explain that it is probably something like this.

The usage scenario of the WriteDataByIdentifier service is roughly as follows.

Writing of control parameters
Writing vehicle, ECU, and software identification numbers

The common point is that it is non-volatile information stored in E2PROMs and so on.

Those who think that information in this area should not be easily rewritten have a good feeling.
That’s exactly right. Basically, security locks are often applied to each service or DID.

Characteristics of WriteDataByIdentifier service because it often writes to non-volatile memory

The WriteDataByIdentifier service has a property, or rather, a characteristic of the WriteDataByIdentifier service, because it often “writes to non-volatile memory”.
The response is not immediate, and in some cases NRC$78 is returned.

There are three major steps in writing to non-volatile memory.

Memory erase
Write
Verify

In other words, it is not a quick process.
Therefore, the off-board tester needs to wait until the writing is finished.
This is where NRC$78 is needed.

Well, the recommended UDS value for P2 time is 1 second, and the OBD setting is 50 ms, so basically it should be in time, but there is no guarantee that it will be in time, so it is sometimes implemented to return NRC$78 just to be safe.

In other words, NRC$78 is returned and extended to 5 seconds of P2* time, but as a result, it is possible that a PositiveResponse is returned in about 10ms.
Well, it is not a violation of the specification, and considering the certainty, I think it is a reasonable specification.