[CanTp] Vehicle Diagnostic Communication Part 23 [Simulation 11]

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

Introduction.
Parameters in FC response
Try to change STmin.
Conclusion

Introduction.

Let’s simulate ISO-TP. series.
In this article, we will try to change the FC response for multi-frame requests in the Python package can-isotp.

Parameters in FC response

Do you remember what the parameters are in the FC?
Let me reiterate them for those who have forgotten.

FS(FlowStatus)
BS(BockSize)
STmin(SeparationTimeMinimum)

It’s explained below, so if you’ve forgotten, you might want to check it out.

Try to change STmin.

I would like to experiment with changing all parameters of FS, BS, and STmin, but based on the current FC response script, only STmin is super easy, so I’ll just check STmin here.

(You’re probably thinking, “You skipped this because it’s too much hassle.” That’s right.)

The experimental script is as follows.
Only the FC part has been rewritten.

import can

# Bus connection
bus = can.interface.Bus(bustype='vector', channel='0', bitrate=500000)

# reception
while True:
	recv_msg = bus.recv(timeout=1)
	if recv_msg != None:
		print('Recv msg : %s' % recv_msg)
		break


send_msg = can.Message(arbitration_id=0x18daF110, extended_id=1, data=[0x30, 0x00, 0x0A, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC])
print('Send msg : %s' % send_msg)

# transmission
bus.send( send_msg )

In this message, STmin=10, which means that there should be at least 10[ms] between CF and CF.

And the resulting log is as follows.

Begin Triggerblock
 0.000000 Start of measurement
 0.000000 1  18DA10F1x       Rx   d 8 10 1E 01 02 03 04 05 06
 0.001622 1  18DAF110x       Rx   d 8 30 00 0A CC CC CC CC CC
 0.013967 1  18DA10F1x       Rx   d 8 21 07 08 09 10 01 02 03
 0.024928 1  18DA10F1x       Rx   d 8 22 04 05 06 07 08 09 10
 0.037134 1  18DA10F1x       Rx   d 8 23 01 02 03 04 05 06 07
 0.049070 1  18DA10F1x       Rx   d 4 24 08 09 10
End TriggerBlock

As you can see from the timestamps, the transmission between CFs is more than 10[ms] separated.

However, upon closer inspection, it seems that it would be more correct to say 11[ms] or more rather than 10[ms] or more.
This may be due to the responsiveness of python-can, which is under can-isotp, or it may be that it is really handling at “11[ms] or more” to begin with.

Some may feel strange about the “11[ms] or longer” handling part.

If you aim for exactly 10[ms], you may find yourself at 10[ms], but your communication partner may perceive that you are actually just short of 10[ms].

As the theory of relativity explains, time flows differently in different inertial systems.
This is not the reason why I am talking about this.

It is simply that the timing of the start of time counts and the accuracy of the time counts are likely to not match because they are between different systems.
Therefore, it is safer to aim for 11[ms], which is definitely more than 10[ms], than to aim for 10[ms].

This is a bit of a digression.
The API for time-specified task WAITING states in a real-time OS is based on a similar idea.
In the ITRON OS API, there is dly_tsk. dly_tsk(1) means “wait 1[ms] or more,” so it actually behaves like “wait 1[ms] to 2[ms].

The flow of time is absolute, but it cannot be managed in the same way in a real sense, so a range like this is necessary.

Conclusion

I changed the FC equivalent to change the behavior of can-isotp multi-frame requests.
- The behavior is now compliant with the specified STmin.
The time parameters for communication are wide enough to allow for synchronization between systems.
- If it is more than 10[ms], we aim for 11[ms] to ensure that it meets 10[ms] or more.

Click here for back issues.