[CanTp] Vehicle Diagnostic Communication Part 26 [Simulation 14]

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

Introduction.
Parameters of can-isotp
Change parameters
Operation after parameter change
Conclusion

Introduction.

Let’s simulate ISO-TP. series.
In this article, we will try to adjust the parameters of the pseudo-ECU by the Python package can-isotp.

Parameters of can-isotp

In the last issue, we successfully confirmed the request response by can-isotp.
This time, we will try to adjust FC parameters.

By FC parameters, it means BS and STmin.
You may review them below.

Since can-isotp seems to be easy to adjust, let’s experiment with a light hearted approach.

Change parameters

In the scripts used in the previous and previous sections, there are dictionaries for the following parameters.

isotp_params = {
 'stmin' : 0, 
 'blocksize' : 0,
 'wftmax' : 0,
 'll_data_length' : 8,
 'tx_padding' : 0xCC,
 'rx_flowcontrol_timeout' : 1000,
 'rx_consecutive_frame_timeout' : 1000,
 'squash_stmin_requirement' : False,
 'can_fd' : False,
 'tx_data_min_length' : 8
}

If you’re astute, you’ve probably noticed.
The only work to be done is to adjust the values here.
So, let’s adjust BS and STmin on both the request and response sides.

Operation after parameter change

The parameters shall be as follows.

Request side: BS=3, STmin=1
Response side: BS=2, STmin=2

After modifying the script, the log of the operation 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.001909 1  18DAF110x       Rx   d 8 30 02 02 CC CC CC CC CC
 0.005915 1  18DA10F1x       Rx   d 8 21 07 08 09 10 01 02 03
 0.008880 1  18DA10F1x       Rx   d 8 22 04 05 06 07 08 09 10
 0.010953 1  18DAF110x       Rx   d 8 30 02 02 CC CC CC CC CC
 0.016843 1  18DA10F1x       Rx   d 8 23 01 02 03 04 05 06 07
 0.020881 1  18DA10F1x       Rx   d 8 24 08 09 10 55 55 55 55
 0.036889 1  18DAF110x       Rx   d 8 10 1E 01 02 03 04 05 06
 0.039780 1  18DA10F1x       Rx   d 8 30 03 01 55 55 55 55 55
 0.058802 1  18DAF110x       Rx   d 8 21 07 08 09 10 01 02 03
 0.072778 1  18DAF110x       Rx   d 8 22 04 05 06 07 08 09 10
 0.078709 1  18DAF110x       Rx   d 8 23 01 02 03 04 05 06 07
 0.079643 1  18DA10F1x       Rx   d 8 30 03 01 55 55 55 55 55
 0.106660 1  18DAF110x       Rx   d 8 24 08 09 10 CC CC CC CC
End TriggerBlock

I can be sure that it is properly waiting for FC and accepting BS units.
STmin also seems to be functioning.

So, can-isotp’s degree of perfection is quite high.
Actually, it is far more reliable than something implemented by someone who has dabbled a bit in vehicle diagnostic communication.

I am sure there are those who may have felt a negative connotation in the above statement.

If only looking at the behavior of vehicle diagnostic communication, it is possible to implement it like that without being too conscious of layers.
However, implementation that ignores layers often breaks down somewhere, and I had to analyze and modify the broken vehicle diagnostic communication….
The structure of the code was broken before it was clean or dirty, so we had to go beyond the level of modification to begin with.

Let’s all be careful not to let this happen!

Conclusion

We experimented with changing FC parameters in can-isotp.
can-isotp is highly complete.
- At least, it is much better than those vehicle diagnostic communication whose structure is broken.

Click here for back issues.