Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/
Introduction.
Explanation of ISO 14229, the UDS.
In this article, specific telegrams for the WriteDataByIdentifier service will be explained.
Prerequisite DID resource state
Let’s define the DID first as we did for the ReadDataByIdentifier service.
There is no multi-DID specification, so only one DID is defined.
Define only the DID and data length.
- 0x1234: 2 bytes length
transmission/reception
Transmission/reception using the defined DID is as follows.
Req:0x2E 0x12 0x34 0x01 0x02
Res:0x6E 0x12 0x34
It would be fairly simple.
In fact, it would be simple as a telegram for this service only, although it would often require a session move or security release.
Transmission/reception including NRC
Let’s do one more pattern.
The communication is the same, but NRC$78 is included in the pattern.
Assuming that NRC$78 is entered twice, the pattern is as follows.
Req:0x2E 0x12 0x34 0x01 0x02
Res:0x7F 0x2E 0x78 // ResponsePending(Transition to P2* time)
Res:0x7F 0x2E 0x78 // ResponsePending(P2* time reset)
Res:0x6E 0x12 0x34
Assuming NRC$78, the communication appears to be quite troublesome.
However, the NRC$78 specification is not limited to the WriteDataByIdentifier service.
Therefore, it will be a problem to be solved initially.
In other words, when implementing the WriteDataByIdentifier service, we are not so much aware of NRC$78.
Even if the implementation difficulty is high, it is not so scary in the end because the design verification contents are clear.
I have explained the services handled in the simulation in a nutshell.
Therefore, from the next article, I will start to explain the structure of the simulation and how to connect CanTp and Dcm.
Conclusion
- The following is an example of a specific transmission/reception of the WriteDataByIdentifier service.
- I have explained examples of transmission/reception including NRC$78.
Click here for back issues.
コメント