[CanTp] Vehicle Diagnostic Communication Part 39 [Simulation 27]

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

Introduction.
Change BS parameters
Log of BS parameter changes
Summary of the series
Conclusion

Introduction.

Let’s simulate ISO-TP. Series of.
Continuation of the times to simulate.
This time, we will check the behavior when BS parameters are changed.

Change BS parameters

This is the last in the series of simulations. Probably.
(Actually, I was going to finish it in the last issue…)

Change the parameters of BS (BlockSize) of FC (FlowControl) as I said before.
The following assumptions are made.

BS transmitted by the off-board tester side is 4
The BS transmitted by the pseudo-ECU side is 1

You can review the BS story below.

Log of BS parameter changes

Let’s check the resulting log.
Same as last time, slightly modified for easier viewing.

Begin Triggerblock
 0.000000 Start of measurement
 
 // SF Request, SF Response
 0.000000 1  18DA10F1x       Rx   d 8 03 22 01 0A CC CC CC CC	// SF
 0.001852 1  18DAF110x       Rx   d 8 06 62 01 0A 00 01 02 55	// SF
 
 // SF Request, MF Response
 0.200548 1  18DA10F1x       Rx   d 8 07 22 01 0A 01 0A 01 0A	// SF
 0.204890 1  18DAF110x       Rx   d 8 10 10 62 01 0A 00 01 02	// FF
 0.206496 1  18DA10F1x       Rx   d 8 30 04 00 CC CC CC CC CC	// FC
 0.207487 1  18DAF110x       Rx   d 8 21 01 0A 00 01 02 01 0A	// CF
 0.208470 1  18DAF110x       Rx   d 8 22 00 01 02 55 55 55 55	// CF
 
 // MF Request, MF Response
 0.400999 1  18DA10F1x       Rx   d 8 10 11 22 01 0A 01 0A 01	// FF
 0.401891 1  18DAF110x       Rx   d 8 30 01 00 55 55 55 55 55	// FC
 0.403939 1  18DA10F1x       Rx   d 8 21 0A 01 0A 01 0A 01 0A	// CF
 0.404881 1  18DAF110x       Rx   d 8 30 01 00 55 55 55 55 55	// FC
 0.406954 1  18DA10F1x       Rx   d 8 22 01 0A 01 0A CC CC CC	// CF
 0.413303 1  18DAF110x       Rx   d 8 10 29 62 01 0A 00 01 02	// FF
 0.415973 1  18DA10F1x       Rx   d 8 30 04 00 CC CC CC CC CC	// FC
 0.416883 1  18DAF110x       Rx   d 8 21 01 0A 00 01 02 01 0A	// CF
 0.417931 1  18DAF110x       Rx   d 8 22 00 01 02 01 0A 00 01	// CF
 0.418882 1  18DAF110x       Rx   d 8 23 02 01 0A 00 01 02 01	// CF
 0.420954 1  18DAF110x       Rx   d 8 24 0A 00 01 02 01 0A 00	// CF
 0.422027 1  18DA10F1x       Rx   d 8 30 04 00 CC CC CC CC CC	// FC
 0.422847 1  18DAF110x       Rx   d 8 25 01 02 01 0A 00 01 02	// CF
End TriggerBlock

As expected, the handshake was quite complicated.
This BS specification is quite an aspect that makes the design and implementation of vehicle diagnostic communication difficult.

Is the BS specification being used in the first place?
I have almost never seen it, but if the performance on the ECU side is not very high, there may be situations where the throughput needs to be controlled by STmin or BS.
This is one of the destinies of vehicle development, which is the swing of specifications due to ECU-side constraint dependence.

Summary of the series

We used Python instead of Vector’s CANoe, etc., which we would normally use.
At first, you may not have understood it well, but once it started working, you could get an idea of what it was like.

If you want to do something while logging, CANoe is probably easier to use.
In Python, we had to start multiple terminals and mess around with them, which was quite a hassle.

This is a cost-effective way of thinking.
I think that Python is sufficient for a small test, and CANoe is better for a heavy-duty test.

There is also the idea of using a combination of the two.
I have not tried it this time, but I have already confirmed that it can be used together during the preliminary investigation.

So, the ISO15765-2 (IsoTp, CanTp) simulation is over.

Conclusion

Simulation conducted by playing with the BS (BlockSize) parameter of FC (FlowControl).
Summary of the series.
- A test environment where CANoe and Python coexist or something like that might be useful.

Click here for back issues.