Introduction
This is a back-issue of a series that discusses various aspects of vehicle diagnostic communications.
The following article is the original source for the summary and English translation.
Wikipedia On-board diagnostics OBD
https://en.wikipedia.org/wiki/On-board_diagnostics
Related Books
There is very little information on this type of information both on the Internet and in books.
However, it does not mean that there is no information at all.
Therefore, it is necessary to research and obtain information from wherever it can be obtained.
This is a truly troubling area where knowledge is hard to come by.
Video, etc.
Overview
CAN
Addressing Format
DoCAN Overview
- The typical standards for vehicle diagnostic communication are ISO 15765-2 and ISO 14229-1.
- Depending on the manufacturer’s policy, the standard number may be a requirement rather than a specific requirement.
- The layers of vehicle diagnostic communication can be represented by the OSI model.
- There are two main axes of vehicle diagnostic communication.
- UDS and OBD.
- OBD is referenced by vehicle emission regulations, so the various parameters are clear.
- UDS only has recommended values, and the actual values are dependent on the finished vehicle manufacturer.
- UDS and OBD.
- The required standard numbers were reviewed.
- CAN has become a relatively common specification, and you can find information there on the Internet and in books.
- 1 Mbps is not often used in DoCAN.
- For legal reasons
- 1Mbps lacks stability in some aspects.
- Basically, a Google search can provide information on the CAN data link layer.
- CAN baud rate setting is special.
- It is not possible to set the baud rate directly, but the quantum time, which is a decomposition of 1 bit, is determined first.
- Since the total quantum is the baud rate, it is necessary to calculate backward from the baud rate you want to set.
- CAN can adjust the sampling point.
- It can be decided at which quantum in the total quantum to sample.
- This is often expressed as [%].
- 50[%] for the middle, 75[%] for slightly behind (around 3/4).
- To determine the sampling points, the number of quantums in each segment must be determined.
- There are 4 types of segments, each for 1 bit.
- Synchronization Segment.
- Propagation Segment.
- Phase Segment1.
- Phase Segment2.
- Propagation Segment + Phase Segment1 is called tseg1, and Phase Segment2 is called tseg2.
ISO-TP
- There are physical addresses for one-to-one communication and functional addresses for one-to-many communication.
- Physical and functional addresses are composed of four different addressing formats
- The addressing formats consist of N_AI, N_TAtype, N_TA, N_SA, and N_AE.
- However, they may or may not be used depending on the addressing format.
- Normal addressing is the simplest addressing format.
- Normal fixed addressing is the easiest addressing format to define as a specification.
- Extended addressing is an extended version of Normal addressing with N_TA added.
- Mixed addressing has 11bitID and 29bitID versions.
- The 11bitID (standard ID) version is based on Normal addressing and assumes gateway traversal.
- The 29bitID (extended ID) version is based on Normal fixed addressing and assumes gateway traversal.
- CAN multiple frames can send/receive up to 4095 bytes.
- The parameter N_PCI is at the start of each frame, and there is a mechanism to concatenate the frames well.
- There are two main transmission methods depending on the number of data to be sent.
- If the number of data to be sent is 7 bytes or less, single frame transmission is used.
- If the number of transmitted data is 8 bytes or more, it is a multi-frame transmission.
- Multi-frame transmission has a mechanism to control the throughput by setting the CF transmission interval and the timing for receiving another FC with FC.
- Four types of frames are explained.
- The first N_PCItype is available for immediate judgment upon reception.
- Each has its own unique parameters.
- SF.
- SF_DL.
- FF.
- FF_DL.
- FC.
- FS.
- BS.
- STmin.
- CF.
- SN.
- SF.
- Decomposition of SF-SF and MF-MF communications into type of frame.
- MF-MF communication behaves slightly differently in the BS and FS of FC.
- The parts of the message that are not included in the message for DLC reasons are filled in with padding.
- Any value can be used for padding.
- Commonly used values are 00, 55, AA, CC, and FF.
- ISO-TP has six timeout parameters.
- N_As, N_Bs, N_Cs, N_Ar, N_Br, and N_Cr.
- Single frame transmission is complete in one frame, so only N_As.
- Multi-frame transmission uses all parameters.
- ISO-TP only determines the timeout at the frame level, and the timeout per message is determined by a higher layer.
- ISO15765-2 (UDS) and ISO15765-4 (OBD) have different values for the timeout parameter.
- The UDS side is looser and the OBD side is stricter.
- Some timeout parameters are set as performance requirements.
- N_Br and N_Cs.
CanTp simulation
- We are tired of studying and it’s time to do some simulations.
- I will also do AUTOSAR related things.
- I will also dare the challenge of using Python.
- We installed Vector’s free XL Driver Library and Vector Driver Setup.
- There is an application called xlCANControl in the XL Driver Library, so it is a quick way to check the operation.
- You can assign channels to each app, so you need to assign them in VectorHardware in the control panel.
- We set up BusMaster.
- Monitored CAN frames on Virtual CAN Bus with BusMaster.
- Finally, we get into Python.
- I’ll use Anaconda, but you can use the official Python for Windows.
- You’d better make sure each one works! (I keep telling myself that…)
- I installed python-can.
- Checked the operation of python-can.
- Sent by can.player and recorded by BusMaster.
- The performance of python-can is on the order of 1-2[ms].
- CANoe has better accuracy.
- CAN transmissions were replayed in can.player and recorded in can.logger.
- There are three file formats recorded by can.logger.
- asc, blf, and csv.
- Listed the devices supported by python-can.
- Sending/receiving by python-can was realized.
- The Python package can-isotp can communicate ISO15765-2, or ISO-TP.
- However, python-can must also be installed due to dependencies.
- For now, SF (SingleFrame) transmission is possible.
- The multi-frame transmission stopped at FF (FirstFrame) and ended in an error.
- The protocol specification is that the next sequence cannot proceed unless FC is received after FF.
- 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.
- 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.
- 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.
- 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.
- We experimented with can-isotp request-response.
- SF-SF communication -> OK!
- MF-MF communication -> OK!
- 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.
- 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.
- 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.
- 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.
- 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.
- The body of CanTp for A-COMSTACK is cantp.c.
- Many header files also need to be brought in.
- Timer interrupt and exclusion are realized by Win32API.
- The AUTOSAR CanTp specification is published in AUTOSAR_SWS_CANTransportLayer.
- The minimum interfaces that need to be grasped are the following.
- CanTp_Transmit.
- CanTp_MainFunction.
- CanTp_RxIndication.
- CanTp_TxConfirmation.
- CanIf_Transmit.
- PduR_CanTpCopyRxData.
- PduR_CanTpCopyTxData.
- PduR_CanTpRxIndication.
- PduR_CanTpStartOfReception.
- PduR_CanTpTxConfirmation.
- Review of AUTOSAR CanTp interfaces.
- I have drawn a figure of the interfaces of AUTOSAR CanTp.
- Each interface is defined in its own header file.
- But we need to be reconciled for simulation.
- CanTp is based on the concept of a pair of transmitting and receiving channels.
- Channels can be duplicated.
- However, dynamic duplication is not allowed. Only static duplication is possible.
- The configuration structure of CanTp is described in the AUTOSAR specification.
- However, there is no UML description.
- The update priority may have been lowered since it has been followed since the OSEK era.
- This time, we will define the corresponding structure entity manually without using a configurator.
- We defined a concrete configuration structure for AUTOSAR-CanTp.
- The number PduId is used when interacting with CanIf.
- In this case, the following.
- 0: Transmission of 0x18DAF110.
- 1: Receipt of 0x18DA10F1.
- 2: Transmission of 0x18DA10F1.
- 3: Receipt of 0x18DAF110.
- In this case, the following.
- The Receive Control Block for CH_RX_CB and the Transmit Control Block for CH_TX_CB are for work.
- Fixed the script for Python can-isotp requests.
- The request is now ISO14229-1 compliant.
- Implemented AUTOSAR-CanTp side.
- The response is now SO14229-1 compliant as well.
- The code has not been published yet for personal reasons.
- 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.
- 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.
UDS
- Review of the Diagnostic Troubleshooting Communication Layer.
- The response message timeout parameter is P2 time.
- Session timeout parameter is S3 time.
- P2 time is explained with figures.
- P2* timeout will be explained later.
- S3 time is explained with figures.
- S3 time is explained in detail.
- It is difficult if you don’t know the various services.
- Diagnostic services fall into six categories of functional units.
- Diagnostic and Communications Management explained.
- Session, Security, and Communications Control.
- Data Transmission Description.
- Read/write data by memory address and DID.
- Stored Data Transmission Description.
- Getting and clearing DTC and freeze data.
- Input/Output Control Description.
- I/O control of ECU.
- While convenient, this service can be dangerous depending on the condition of the vehicle,so it is necessary to consider safety functions.
- Routine explanation.
- Mainly used for functions such as those used during development.
- Explanation of Upload/Download.
- A group of services for data transfer that can also compress and encrypt data.
- AUTOSAR-BSW for ISO14229 is DCM.
- A-COMSTACK does not include DCM.
- There is another open source AUTOSAR called OpenSAR which includes DCM.
- Presentation of the overall structure of the USD simulation.
- A-COMSTACK is AUTOSAR r3.x series and OpenSAR is AUTOSAR r4.x series.
- Therefore, illegal construction.
- There are five services to be realized by UDS simulation
- DiagnosticSessionControl.
- SecurityAccess.
- TesterPresent.
- ReadDataByIdentifier.
- WriteDataByIdentifier.
- When explaining the request and response messages, the CAN frame is not explained.
- I will only explain the ISO 14229-1 layer and not the ISO 15765-2 layer.
- Explains the session as defined in the ISO for DiagnosticSessionControl
- Request message of DiagnosticSessionControl.
- Response message of DiagnosticSessionControl.
- P2 time and P2* time of the relevant session can be obtained.
- Explanation of PositiveResponse.
- Response SID is set to Request SID with 0x40 and OR.
- Explanation of NegativeResponse.
- Like 0x7F 0x10 0x12.
- Special ones like ResponsePending will be explained next time.
- Review of P2 time.
- P2 time is 1 second
- Explanation of P2* time
- P2* time is 5 seconds.
- When the off-board tester receives NRC$78, it switches from P2 time to P2* time.
- When the off-board tester receives NRC$78 again, it extends P2* time from there.
- The SecurityAccess service has two major message patterns.
- requestSeed.
- Odd sub-functions.
- sendKey.
- Even sub-functions.
- requestSeed.
- The SecurityAccess service is purposely troublesome procedure, which is the security strength.
- Must transition to non-defaultSession in advance.
- Must wait 10 seconds after IGon.
- If you make a mistake unlocking, you have to IGoff once.
- Explain the basic flow of the SecurityAccess service.
- Explain the actual messages in the basic flow of the SecurityAccess service.
- Security is applied to resources.
- Service.
- DID.
- There is a service called TesterPresent service that does nothing.
- The TesterPresent service has the following usage scenarios.
- Checking for communication.
- Node presence/absence check.
- Session maintenance.
- The TesterPresent service is a service that must be supported.
- Explanation of the messages of the TesterPresent service.
- Explanation of suppressPosRspMsgIndicationBit.
- PositiveResponse suppression.
- NegativeResponse is returned.
- PositiveResponse after NRC$78 is also returned.
- Explanation of the usage scenario of the ReadDataByIdentifier service.
- Vehicle status monitoring (verification during development, failure analysis after market release).
- Forced operation status monitoring during vehicle assembly.
- Freeze data acquisition at the time of failure detection.
- Explanation of the request message for the ReadDataByIdentifier service.
- Multiple DIDs can be set.
- There may be a limit on the number of DIDs that can be set, and it is an error if the number is exceeded.
- It is also an error if the response message exceeds 4095 bytes.
- Explanation of the ReadDataByIdentifier service response message
- Combination of DID and dataRecord.
- In case of multiple DIDs, the above combination is placed in one message.
- Confirmed single DID transmitted and received.
- Confirmed transmitting and receiving multi-DIDs.
- Confirmed some DIDs are undefined patterns.
- The WriteDataByIdentifier service has been explained.
- Usage scenarios.
- Communication characteristics tied to non-volatile memory.
- Explanation of the request message for the WriteDataByIdentifier service.
- Unlike the ReadDataByIdentifier service, one DID is fixed.
- Explanation of the response message of the WriteDataByIdentifier service.
- In practice, NRC$78 may be interleaved.
- The following is an example of a specific transmission/reception of the WriteDataByIdentifier service.
- I have explained examples of transmission/reception including NRC$78.
Dcm Simulation
- AUTOSAR-Dcm simulation configuration review.
- Review of services used in AUTOSAR-Dcm simulation.
- Listed specific items to be checked.
- Will also include confirmation of responsePendingCount, the number of times NRC$78 replies are received.
- Check AUTOSAR-Dcm specification (r3.3).
- Check AUTOSAR-Dcm interface.
- NRC$78 is just SingleFrame as AUTOSAR-CanTp.
- The interface specification of AUTOSAR-Dcm is figured out.
- The buffers for communication are managed by AUTOSAR-Dcm, which is a memory-saving and copy-saving design implementation.
- AUTOSAR-Dcm consists of three sub-modules.
- dsl: Diagnostic Session Layer.
- dsd: Diagnostic Service Dispatcher.
- dsp: Diagnostic Service Processing.
- Review of AUTOSAR-Dcm interface functions.
- I implemented the interface functions of AUTOSAR-Dcm.
- The content of AUTOSAR-Dcm structure consists of dsl, dsd, and dsp.
- Some are const defined and some are defined by variables for work.
- There are about 50 structures for configuration in total.
- Dsl (Diagnostic Session Layer) is Session related sub-module.
- It manages P2 time, P2* time, S3 time, etc.
- It also contains the PudId of CanTp that is actually used.
- I wrote the code for the Dsl structure definition.
- The end of the list is when Arc_EOL is TURE.
- ArcCore (OpenSAR) proprietary specification.
- Callback functions can be defined to trigger diagnostic service start/stop, valid service request, and session transition.
- Dsd is a sub-module whose purpose is to distribute to each service.
- At the same time, it also determines the security level and sessions to be supported.
- For the above purposes, it has the following configuration parameters
- Existing service definition.
- Support service definition.
- Definition of the security level and sessions that the service can support.
- I wrote the configuration code for Dsd.
- The corresponding security level and session entity are in Dsp and only referenced from Dsd.
- Dsp is the application layer.
- It is divided into ISO14229-1 dependent and manufacturer dependent, and manufacturer dependent is handled by callback functions.
- The DID-related part of Dsp is the most complicated.
- Once you know DID, other configurations are relatively easy.
- I wrote the configuration code for Dsp.
- Mostly security, session definition and association with DID.
- Review of AUTOSAR Dcm simulation configuration
- The Python code on the off-board tester side is the same as we have used so far.
- Modifications will be made as needed.
- The order in which the simulations are run is as follows.
- DiagnosticSessionControl.
- SecurityAccess.
- TesterPresent.
- ReadDataByIdentifier.
- WriteDataByIdentifier.
- I wrote a Python code for simulation of DiagnosticSessionControl.
- Communication patterns include error patterns.
- Non-existent session.
- Wrong message length for a DiagnosticSessionControl request.
- Check the results of the DiagnosticSessionControl simulation.
- Confirmation of message level.
- Confirmation of CAN line level.
- NegativeResponse can be automatically determined and returned by Dcm or by adding your own code.
- Message length and parameter abnormality are judged automatically.
- Rejections due to vehicle status are returned with an original code.
- I wrote Python code for the SecurityAccess simulation.
- There is a large amount of work to be done to make sure SecurityAccess works.
- Support sessions.
- Sequence.
- Seed in security unlocked state.
- Transition to locked state on session transition.
- Session transitions due to S3 timeouts.
- Check the results of the SecurityAccess simulation.
- Check the message level.
- Check the CAN line level.
- SecurityAccess behavior depends on session state and security state.
- SecurityAccess behavior depends on session state, security state, and S3 timeout.
- I wrote a Python code to simulate TesterPresents.
- Considering the main purpose of TesterPresents, SessionControl and SecurityAccess are also implemented.
- The main purpose is to suppress S3 timeouts.
- Check the results of the TesterPresents simulation.
- Verification of messages.
- Checking the CAN line log.
- TesterPresents with suppressPosRspMsgIndicationBit is a special AUTOSAR-Dcm specification.
- After S3 time extension in Dsl, the message is discarded and not passed to Dsd and Dsp.
- The result is different from ISO14229-1, but the practicality is more important.
- I wrote Python code for simulation of ReadDataByIdentifier.
- Test pattern main related to ReadDataByIdentifier multi-DID.
- Multi-DID.
- Mix unsupported DIDs.
- Specify DIDs such that the response message length exceeds the maximum value.
- Check the results of the ReadDataByIdentifier simulation.
- Confirmation of the message.
- Check CAN line logs.
- Multi-DID specification is tricky.
- A request for a non-existent DID is an error.
- However, if the DID exists in the multi-DID, it is not an error.
- If the DID exists, it is not an error.
- However, an error may occur due to the response message length.
- A request for a non-existent DID is an error.
- I wrote Python code to simulate WriteDataByIdentifier.
- WriteDataByIdentifier is often protected by session and security, so the main test is to test it.
- Check the results of the WriteDataByIdentifier simulation.
- Confirmation of the message.
- Confirmation of CAN line.
- Often used in conjunction with ReadDataByIdentifier to check operation for reading after writing.
- NRC$78 returned atmosphere.
- In fact, NRC$78 is rarely followed three times.
- We saw a pattern of returning NRC$10 (generalReject) when NRC$78 (ResponsePending) exceeds a certain number of times.
- This specification is not specified in ISO 14229-1.
- However, it is likely to be a de facto standard.
- Therefore, it is assumed that it is incorporated as an AUTOSAR specification.
CAN-FD Overview
- Switch from CAN to CAN-FD for the physical and data link layers.
- CAN-FD is described in Vector’s “CAN/CAN-FD for Beginners”.
- Simulation procedure and intuition explanation.
- CAN-FD control with python-can.
- CAN-FD diagnostic communication with can-isotp (ISO15765-2).
- CAN-FD diagnostic communication with AUTOSAR-CanTp (ISO15765-2).
- AUTOSAR-Dcm for CAN-FD diagnostic communication (ISO14229-1).
- BusMaster does not support CAN-FD.
- The asc format of CAN-FD is different from CAN.
- FDF bit and BSR bit parameters are added.
CAN-FD python-can
- Review can.player and can.logger.
- Created asc file for CAN-FD and CAN mixed replay.
- Mixed CAN is for identifying the affected area in case of an anomaly.
- It was discovered that can.player and can.logger do not support CAN-FD.
- I immediately modified them to support CAN-FD.
- can.logger has a little different problem.
- Explanation of how to use the modified versions of can.player and can.logger.
- I just added the option “-fd” to both.
- I used can.player and can.logger to play and record.
- The ascwriter in can.logger does not support CAN-FD format, so I cannot distinguish between CAN and CAN-FD.
- For the time being, we do not care about this in the simulation.
- Review of python-can request and response code.
- Create request and response code as CAN-FD.
- fd=True when initializing Bus.
- When creating the message, bitrate_switch=True, is_fd=True.
- Simulation configuration review.
- Simulation execution of CAN-FD transmission and reception.
CAN-FD ISO-TP
- can-isotp can probably do CAN-FD.
- Extended SingleFrame and Extended FirstFrame configurations were explained.
- I wrote the Python code for the request.
- SingleFrame with 8 bytes or more.
- MultiFrame of 4096 or more.
- Wrote Python code for response.
- Extended the size of the received frame by changing the max_frame_size parameter.
- CAN line logged.
- Checked SingleFrame.
- SingleFrame of 7 bytes or less.
- SingleFrame with more than 8 bytes.
- FirstFrame check.
- FirstFrame of 4095 bytes or less.
- FirstFrame with 4096 bytes or more.
CAN-FD AUTOSAR
- The policy is to do AUTOSAR-CanTp and AUTOSAR-Dcm CAN-FD simulations at once.
- The reason for using A-ComStack in r4.x for CanTp was to support CAN-FD. (Foreshadowing!)
- The simulation configuration is exactly the same as for CAN.
- Benefit of layered architecture.
- Fixed the configuration of AUTOSAR-CanTp for CAN-FD.
- Fix configuration of AUTOSAR-Dcm for CAN-FD.
- Simulation of AUTOSAR-Dcm was executed.
- Simulation of AUTOSAR-Dcm, the basic principle is the same, except for the maximum message length.
- Simulation of AUTOSAR-CanTp.
- Both request and response behaved according to CAN-FD rules.
Looking Back
- Brief look back.
- The vehicle diagnostic communication has a wide range of use cases, which makes it a broad topic.
- This series is now over.
コメント