Called by many names - Diagnostic communication over Controller Area Network (DoCAN), ISO 15765-2 protocol or CAN-TP (CAN Transport Protocol) is a vital component of modern automotive diagnostics. It allows for the efficient and reliable transmission of diagnostic information between a diagnostic tool and a vehicle's electronic control units (ECUs). This article aims to demystify the ISO 15765-2/CAN-TP/DoCAN protocol by providing a comprehensive overview of its functions, features, and applications.
Why Is ISO 15765-2 Protocol Important?
The need for the CAN-TP or ISO 15765-2 protocol arises from the increasing complexity of automotive systems and the need for standardized diagnostic communication. With the evolution of electronic systems in vehicles, diagnosing faults and retrieving valuable data has become crucial for efficient maintenance and repair.
The CAN-TP or ISO 15765-2 protocol ensures that diagnostic tools can communicate with different ECUs in a vehicle by providing a common language for data transfer. This standardization allows for interoperability between different diagnostic tools and vehicles, making it easier for technicians to diagnose and repair vehicle faults. Further the quantum of data has become large, so it is not possible to transfer the information over a single CAN/CAN-FD packet. This again calls for a standard and reliable transport mechanism as defined by the ISO 15765-2 standard.
Understanding CAN-TP Protocol In The OSI Layer Model
To understand the ISO 15765-2 or CAN-TP (Controller Area Network-Transport Protocol) better, it is essential to comprehend its position in the OSI (Open Systems Interconnection) layer model. The OSI model is a conceptual framework that defines how different network protocols interact and communicate with each other.
The CAN-TP protocol operates at the transport and network layers of the OSI model. These layers are responsible for ensuring reliable and error-free data transfer between two endpoints. By supporting the transport layer, the CAN-TP protocol provides mechanisms for segmentation, reassembly, and flow control of diagnostic messages effectively allowing transmission of packets up to size 4294967295 bytes.
Exploring The Different Frames In CAN-TP: Single Frame, First Frame, Consecutive Frame, Flow Control Frame
The ISO 15765-2 or CAN-TP protocol defines several types of frames that facilitate the transmission of diagnostic messages. These frames include the single frame, first frame, consecutive frame, and flow control frame.
The single frame is used for transmitting short diagnostic messages that can fit within a single frame. It is the most straightforward frame type, containing the entire diagnostic message within its payload.
For longer diagnostic messages that cannot fit within a single frame, the ISO 15765-2 or CAN-TP protocol utilizes the first frame and consecutive frame. The first frame provides information about the total length of the diagnostic message, while the consecutive frame carries the actual payload.
To ensure reliable transmission of multi-frame diagnostic messages, the CAN-TP protocol employs the flow control frame. This frame is responsible for regulating the transmission speed and ensuring that the receiving end can handle the incoming data.
Single-Frame Communication In DoCAN Protocol
Single-frame communication in the DoCAN protocol is ideal for transmitting small diagnostic messages that do not exceed the payload limits of a single frame. This frame type is simple and efficient, making it suitable for real-time diagnostic applications.
When a diagnostic tool sends a single-frame message, it encapsulates the complete diagnostic information within the payload of the frame. The receiving end, typically an ECU, can then extract and process the diagnostic data without the need for additional frames.
Single-frame communication is commonly used for diagnostic requests that require a quick response from the ECU. For example, retrieving sensor readings or requesting the status of a specific component can be accomplished using a single-frame message.
Multi-Frame Communication In DoCAN Protocol
In situations where the diagnostic message exceeds the payload limits of a single frame, the DoCAN protocol utilizes multi-frame communication. This method allows for the transmission of large diagnostic messages by breaking them down into multiple frames.
The multi-frame communication process starts with the transmission of a first frame that contains information about the total length of the diagnostic message. The receiving end uses this information to allocate sufficient memory for storing the complete message.
Following the first frame, the DoCAN protocol sends consecutive frames that carry sections of the diagnostic message. The receiving end reassembles these consecutive frames to reconstruct the original diagnostic message.
By using multi-frame communication, diagnostic tools can transmit extensive diagnostic information without being limited by the payload size of a single frame. This feature is particularly useful for retrieving detailed data or performing complex diagnostic procedures.
The FlowControl has the option for the receiver to ask the sender to wait in case the receiver wants to delay further reception. Then once it is ready, it can request the sender to ContinueToSend the data. Thus, it regulates the rate at which diagnostic messages are transmitted to prevent overwhelming the receiving end. Flow control frames are sent by the receiving end to inform the transmitting end about its current capacity to handle incoming data.
Network Layer Services In ISO 15765-2 Protocol
The ISO 15765-2 protocol provides essential network layer services to the higher-level protocols to ensure reliable communication between diagnostic tools and ECUs. These services include communication between the parties and setting the protocol parameters. The services provided are:
| Service Primitive | Originator | Description |
|---|---|---|
| N_USData.request | Sender | To request the transfer of data with segmentation as necessary |
| N_USData_FF.indication | Receiver | To signal the beginning of a segmented message reception to the upper layer |
| N_USData.indication | Receiver | To provide received data to the higher layer |
| N_USData.confirm | Sender | To confirm to the higher layers that the requested service has been carried out |
| N_ChangeParameter.request | Sender | To request the dynamic setting of specific internal parameters |
| N_ChangeParameter.confirm | Receiver | To confirm to the upper layer that the change parameter has been completed |
With these services, it is possible for higher layer services like UDS to communicate seamlessly between the tester and ECU.
Addressing Formats In ISO 15765-2 Protocol
Addressing in the ISO 15765-2 protocol allows diagnostic tools to specify the intended recipient ECU for diagnostic messages. This addressing mechanism ensures that diagnostic information reaches the correct ECU, preventing unnecessary data processing by other ECUs.
The ISO 15765-2 or CAN-TP protocol supports different addressing formats to specify the intended recipient ECU for diagnostic messages. These addressing formats include physical addressing and functional addressing.
Physical addressing uses the unique identifier (ID) of an ECU's CAN (Controller Area Network) node to identify the recipient. Each ECU in a vehicle has a unique CAN node ID, allowing diagnostic tools to directly communicate with a specific ECU using its ID.
Functional addressing, on the other hand, utilizes a logical address to identify the recipient ECU. Unlike physical addressing, which relies on the CAN node ID, functional addressing allows diagnostic tools to communicate with ECUs based on their functionality or role in the vehicle's system.
The choice between physical and functional addressing depends on the specific diagnostic requirements and the level of control needed by the diagnostic tool. Physical addressing is typically used for direct communication with a specific ECU, while functional addressing is more flexible and suitable for diagnostic operations involving multiple ECUs.
Application Of CAN-TP Protocol In UDS (Unified Diagnostic Services)
The CAN-TP protocol finds extensive application in the Unified Diagnostic Services (UDS) standard. UDS is a diagnostic communication protocol widely used in the automotive industry for diagnosing and maintaining vehicles.
UDS utilizes the CAN-TP protocol to establish reliable communication between diagnostic tools and ECUs. It defines a set of diagnostic services that can be performed on ECUs, such as reading sensor data, performing actuator tests, and retrieving fault codes.
The CAN-TP protocol ensures that these diagnostic services can be executed efficiently by providing the necessary mechanisms for data transfer and flow control. By combining the strengths of the ISO 15765-2 or CAN-TP protocol with the UDS standard, technicians can diagnose and repair vehicles more effectively.
Conclusion: The Importance Of DoCAN Protocol In Automotive Diagnostics
The DoCAN protocol plays a crucial role in automotive diagnostics by enabling efficient and standardized communication between diagnostic tools and ECUs. Its importance lies in its ability to facilitate the retrieval of valuable diagnostic information, leading to accurate fault diagnosis and efficient vehicle maintenance.
By understanding the ISO 15765-2 protocol, technicians can effectively communicate with different ECUs in a vehicle, retrieve essential data, and perform diagnostic procedures. This standardized protocol ensures interoperability between diagnostic tools and vehicles, making it easier to diagnose and repair vehicle faults.
As automotive systems continue to evolve, the CAN-TP protocol will remain a vital component of automotive diagnostics. Its versatility, reliability, and compatibility make it an indispensable tool for technicians and automotive manufacturers alike.
Embien has developed its own RAPIDSEA DoCAN stack that allows developers and OEMs to quickly integrate the UDS stack on to Linux, Android, Windows and MCU based bare metal environments.
