Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/
Introduction.
Explanation of ISO 14229, UDS.
In this article, the services used in the UDS simulation will be explained.
Services to be used in the UDS simulation.
We are going to start a lot of things for the UDS simulation, but first let’s decide which services we will use.
Deciding which services to use means not doing everything….
In fact, it would be better to do all of them.
But it’s hard to explain all the services and simulate them all!
For now, I’ve picked up the pieces on me.
Service | SID | Description |
---|---|---|
DiagnosticSessionControl | $10 | Diagnostic session control |
SecurityAccess | $27 | Security unlocking |
TesterPresent | $3E | Notification of the presence of an off-board tester. (Used for session keeping, etc.) |
ReadDataByIdentifier | $22 | Reading of the current value of the record identified by dataIdentifier |
WriteDataByIdentifier | $2E | Writing of the record identified by dataIdentifier |
Basic flow of UDS simulation
These five services were chosen for a reason.
I was aware of a combination that could reproduce the basic flow of diagnostic communication.
The flow I am considering now is as follows.
(1) Move to a non-default session with DiagnosticSessionControl
(2) SecurityAccess to unlock security
(3) Keep the session with TesterPresent
(4) Read specific data by ReadDataByIdentifier
(5) WriteDataByIdentifier is used to rewrite specific data.
WriteDataByIdentifier should be set to be unusable unless it is in a security unlocked state.
In other words, the purpose is to read and write with ReadDataByIdentifier and WriteDataByIdentifier, but to realize WriteDataByIdentifier, session movement and security unlock are required.
It would be a moderately interesting combination.
Request and response messages for each service
Therefore, I will explain request and response messages focusing on the above five services one after another starting from the next.
However, I will not explain up to the CAN frame.
The division into CAN frames was explained in ISO 15765-2, and each frame pattern is not service-dependent but message-length-dependent, so I will not explain them this time.
If it is less than 7 bytes, it will be a single frame only.
If it is 8 bytes or more, it will be multi-frame.
If you remember these, you don’t have to think again about ISO14229-1 in the upper layer.
Well, in the actual simulation, we will log in ASC file, so we will see CAN frames in the end, but I don’t think we are aware of it as a message specification.
Conclusion
- There are five services to be realized by UDS simulation
- DiagnosticSessionControl.
- SecurityAccess.
- TesterPresent.
- ReadDataByIdentifier.
- WriteDataByIdentifier.
- When explaining the request and response messages, the CAN frame is not explained.
- I will only explain the ISO 14229-1 layer and not the ISO 15765-2 layer.
Click here for back issues.
コメント