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

[CanTp] Vehicle Diagnostic Communication Part 38 [Simulation 26] 車両診断通信
[CanTp] Vehicle Diagnostic Communication Part 38 [Simulation 26]

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

Introduction.

Let’s simulate ISO-TP. series.
Finally, we will simulate it in the configuration we initially envisioned.

Simulation Configuration Review

Let’s review the configuration of the simulation.

Simulation Configuration,Python,iso-tp,python-can,Virtual ECU,AUTOSAR,CanTp,can,Virtual CAN Bus

It was a long time until we realized this…

About the source code of the virtual ECU

The source code of the virtual ECU side is not open to the public.
Although the A-COMSTACK code itself is open source, I am not sure if I am allowed to release it.
In addition, because it contains some code that may violate confidentiality, I will keep it private.

I know many people are not convinced, but every industry has this kind of problem, and the automotive industry is especially severe.
Even the parts that are considered standard specifications can only be disclosed to companies participating in the same consortium.
For better or worse, there are strange barriers to entry.
Some companies are not allowed to enter due to barriers to entry, while others are protected by barriers to entry.

If I have time, I may make the code for the reception interrupt and transmission completion interrupt parts from scratch by full scratch and release it to the public.

Simulation results

Without going into any more detail, I’ll just put up a log of the simulation results.
I’ve modified it a bit to make it easier to read.

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.001892 1  18DAF110x       Rx   d 8 06 62 01 0A 00 01 02 55	// SF
 
 // SF Request MF Response
 0.199410 1  18DA10F1x       Rx   d 8 07 22 01 0A 01 0A 01 0A	// SF
 0.201949 1  18DAF110x       Rx   d 8 10 10 62 01 0A 00 01 02	// FF
 0.202465 1  18DA10F1x       Rx   d 8 30 00 00 CC CC CC CC CC	// FC
 0.203399 1  18DAF110x       Rx   d 8 21 01 0A 00 01 02 01 0A	// CF
 0.204391 1  18DAF110x       Rx   d 8 22 00 01 02 55 55 55 55	// CF
 
 // MF Request MF Response
 0.401523 1  18DA10F1x       Rx   d 8 10 11 22 01 0A 01 0A 01	// FF
 0.402334 1  18DAF110x       Rx   d 8 30 00 00 55 55 55 55 55	// FC
 0.404390 1  18DA10F1x       Rx   d 8 21 0A 01 0A 01 0A 01 0A	// CF
 0.404529 1  18DA10F1x       Rx   d 8 22 01 0A 01 0A CC CC CC	// CF
 0.416162 1  18DAF110x       Rx   d 8 10 29 62 01 0A 00 01 02	// FF
 0.417333 1  18DA10F1x       Rx   d 8 30 00 00 CC CC CC CC CC	// FC
 0.418349 1  18DAF110x       Rx   d 8 21 01 0A 00 01 02 01 0A	// CF
 0.419340 1  18DAF110x       Rx   d 8 22 00 01 02 01 0A 00 01	// CF
 0.420258 1  18DAF110x       Rx   d 8 23 02 01 0A 00 01 02 01	// CF
 0.421306 1  18DAF110x       Rx   d 8 24 0A 00 01 02 01 0A 00	// CF
 0.422322 1  18DAF110x       Rx   d 8 25 01 02 01 0A 00 01 02	// CF
End TriggerBlock

How many times have we gone through to realize this much….

Well, I had to check each and every one of them as I went along.
Even though we had done preliminary experiments, it took a lot of time to log and check every detail.
There were also experiments to change parameters.

And here, I remembered one thing I should do.
I have not yet looked at the behavior of AUTOSAR-CanTp when the parameters are adjusted.
(I did implement the parameter adjustment on the can-isotp side…).

Next time, I will try to adjust the parameters of BS, which are relatively easy to understand visually.

Conclusion

  • Review of simulation configuration.
  • Code handling on the virtual ECU side.
    • Currently, it’s private, give me a break.
  • Confirmation of communication logs of SF-SF, SF-MF, and MF-MF.

Click here for back issues.

コメント

タイトルとURLをコピーしました