車両診断通信

車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 30 [Simulation 18]

A-COMSTACK, a set of communication stack BSW for AUTOSAR, is released by the TOPPERS Association. CanTp is used in this stack. A-COMSTACK can only be used commercially if you are an AUTOSAR partner. This time, it is used for learning purpose. The off-board tester side for operation check uses python can-isotp.
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 29 [Simulation 17]

The code for interrupt emulation is presented. Wait for signal with WaitForSingleObject. xlCanReceive to get various information on receive, send, and error. xlEvent.tag allocates to various processes.
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 28 [Simulation 16]

To realize MCAL-CANDRV, it is necessary to reproduce the receive and transmit completion interrupts. The XL driver library notifies the events of received, sent, and error via Win32API event object. Therefore, knowledge of thread and event object handling by Win32API is required.
車両診断通信

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

We are now in the AUTOSAR CanTp section! AUTOSAR has a layered structure of SW-C, RTE, BSW, and MCAL. AUTOSAR CanTp is one of BSW and reproduces ISO 15765-2.
車両診断通信

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

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.
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 25 [Simulation 13]

We experimented with can-isotp request-response. SF-SF communication -> OK! MF-MF communication -> OK!
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 24 [Simulation 12]

Most vehicle diagnostic communication is a single request-response communication. There are some exceptions such as request-only and response-only communication, but they are quite rare. Both the request and response sides are script fatted by the receive thread mechanism.
車両診断通信

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

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.
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 22 [Simulation 10]

In the default state of can-isotp, the DLC optimization specification is adopted. If you set padding and MIN_DLC in the parameters passed to CanStack, it switches to the padding specification.
車両診断通信

[CanTp] Vehicle Diagnostic Communication Part 21 [Simulation 9]

The FC's add up in python-can. Supported by inserting CAN frames with a bit of timing in python-can. This allowed the multi-frame request to go through for now.