![[DoCAN] Vehicle Diagnostic Communication Part 10 [ISO-TP 6]](https://www.simulationroom999.com/blog/wp-content/uploads/2022/11/01_eyecatch-6.png)
Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/
Introduction.
Explanation of the network layer of vehicle diagnostic communication.
This time, an example of decomposition of messages into various frames will be explained.
Decompose message into type of frame
In the last issue, I explained the types of frames, but do you have an idea of what the actual communication will be like?
“I’m not sure yet, and to be honest, I don’t know what I’m thinking.” I guess that’s about it.
So, let’s break down the specific message sending/receiving into the type of frame.
SF-SF communication
The simplest pattern would be the one where the request is SF and the response is also SF.
It is complete in one frame, so you won’t have to worry about it that much.
If the message is less than 7 bytes, this pattern is used.
The following is the message, the actual message, and various communication results.
Request message (off-board tester side)
| TargetID | SourceID | Length | |||||||
| 10 | F1 | 07 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
Response message (ECU side)
| TargetID | SourceID | Length | ||||||
| F1 | 10 | 06 | 01 | 02 | 03 | 04 | 05 | 06 |
line log
| CANID | DLC | DataField | |||||||
| 18DA10F1 | 08 | 07 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
| 18DAF110 | 08 | 06 | 01 | 02 | 03 | 04 | 05 | 06 | CC |
If you look at the line log of the response, 18DAF110, you will notice that there is a CC at the end of the CAN frame.
The message itself is only 6 bytes long, so the last CC is data that is not included in the message.
This is called padding.
Padding does not mean that the CC is fixed.
According to the example of SO15765-2, it is CC, but in the old ISO15765-2, there was a time when it was 55.
Whatever the case may be, it is a part that is not readable, so you can put anything you like in it.
Common patterns are as follows
00, 55, AA, CC, FF.
Some of you may be thinking, “Why don’t we just put the DLC in 7 instead of 8 in the first place, so we don’t need the padding?” Some of you may think “Why not use 7 instead of 8 for the DLC?
That’s OK.
However, there is a pattern to be filled with padding, so in this example, I assumed there is padding.
By the way, setting DLC to other than 8 with no padding is called DLC optimization specification.
You should be aware of both specifications.
MF-MF communication
The pattern explained here is a rather complicated one, in which both the request and response are multi-framed.
As before, the messages and line logs are written out.
Request message (off-board tester side)
| TargetID | SourceID | Length | ||||||||||||||||||
| 10 | F1 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | 0E | 0F | 10 | 11 | 12 |
Response message (ECU side)
| TargetID | SourceID | Length | ||||||||||||||||||
| F1 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | 20 | 21 | 22 | 23 | 24 |
line log
| CANID | DLC | remarks | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 18DA10F1 | 08 | 10 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | FF(FF_DL=0x12) |
| 18DAF110 | 08 | 30 | 00 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=0,STmin=0) |
| 18DA10F1 | 08 | 21 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | CF(SN=1) |
| 18DA10F1 | 08 | 22 | 0E | 0F | 10 | 11 | 12 | CC | CC | CF(SN=2) |
| 18DAF110 | 08 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | FF(FF_DL=0x12) |
| 18DA10F1 | 08 | 30 | 00 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=0,STmin=0) |
| 18DAF110 | 08 | 21 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | CF(SN=1) |
| 18DAF110 | 08 | 22 | 20 | 21 | 22 | 23 | 24 | CC | CC | CF(SN=2) |
It seems complicated, but it will be a matter of getting used to it.
Once you get used to it, you will be able to construct the message in your brain.
MF-MF communication (with BS)
Finally, a more complicated pattern, when BS is 1 in the MF-MF communication just described.
You may have thought that the previous pattern is the most difficult to deal with, but this is the more difficult pattern to deal with.
So, here are the messages and line logs.
Request message (off-board tester side)
| TargetID | SourceID | Length | ||||||||||||||||||
| 10 | F1 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | 0E | 0F | 10 | 11 | 12 |
Response message (ECU side)
| TargetID | SourceID | Length | ||||||||||||||||||
| F1 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | 20 | 21 | 22 | 23 | 24 |
line log
| CANID | DLC | 備考 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 18DA10F1 | 08 | 10 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | FF(FF_DL=0x12) |
| 18DAF110 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DA10F1 | 08 | 21 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | CF(SN=1) |
| 18DAF110 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DA10F1 | 08 | 22 | 0E | 0F | 10 | 11 | 12 | CC | CC | CF(SN=2) |
| 18DAF110 | 08 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | FF(FF_DL=0x12) |
| 18DA10F1 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DAF110 | 08 | 21 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | CF(SN=1) |
| 18DA10F1 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DAF110 | 08 | 22 | 20 | 21 | 22 | 23 | 24 | CC | CC | CF(SN=2) |
You’ve seen normal MF-MF communication beforehand, so you won’t find it as complicated as you think.
One more difficult pattern is that the FS of FC is non-zero, e.g., WAIT, but it is not a pattern that comes up very often, and you can probably guess what to expect from the examples so far.
Conclusion
- Decomposition of SF-SF and MF-MF communications into type of frame.
- MF-MF communication behaves slightly differently in the BS and FS of FC.
- The parts of the message that are not included in the message for DLC reasons are filled in with padding.
- Any value can be used for padding.
- Commonly used values are 00, 55, AA, CC, and FF.
Click here for back issues.
コメント