There is a common confusion between CAN and diagnostics and this article is an attempt to clarify and bring an understanding of differences between CAN & diagnostics.

Background:  Both CAN and diagnostics are used to read messages/data from ECUs, both involve using a VCI (Vehicle Communication Interface) and analysis software (same CAN analysis software may be used for diagnostics also). This adds to the confusion of differences between CAN and diagnostics. It has to be noted that CAN and diagnostics are different protocols. They are intended for different purposes and used to read data differently. In the below sections we will read and get a clear picture of the differences between CAN and diagnostics.

Purpose: CAN is a protocol used to exchange information between ECUs. At any given point of time, the data is broadcasted by an ECU on the vehicle network and any node on that network is allowed to read that data. The node can be an ECU, a sensor, an actuator of a CAN analysis tool like CANEasy.

On the other hand, diagnostics is not intended for communication between ECUs. The very purpose of diagnostics is for the outside world to read data from the vehicles. In diagnostics, communication is never between ECUs, but always between ECU and analysis software (like DiagRA D or Silver Scan-Tool)

Data: Note that CAN messages between ECUs are scheduled. They are sent and received regularly or on an interrupt. On the other hand, diagnostics is strictly based on request-response. It means, unless the analysis tool sends a valid request to the ECU, the ECU will not generate any diagnostic message. This means while testing, CAN messages are readily available on the network, but they are limited to the messages that ECUs exchange. Any more data will not be available.

With diagnostics, data are available by sending requests to the ECUs, but note that they are limited too to the configured messages in the ECUs.

Format: The format of the messages carrying data in CAN and diagnostics are different. CAN follows it’s standard (CAN 2.0 specification) for carrying data. With diagnostics, the format of messages completely depends on the different diagnostic standards (like UDS, SAE J1979, J1939, ISO27145, etc). But it is important to note that the diagnostic protocols are built on the network protocols. It means, if CAN is used as a vehicle network, CAN messages are used to carry diagnostic requests, responses, and data. So, there is CAN FRAME with its entire format and then inside the data field of the CAN FRAME is the diagnostic request/response/data in its own format as specified by the diagnostic standard.

Tools: There are several tools in the industry providing support for CAN and diagnostics, below are few best in the industry examples: VCI – Vehicle Communication Interface, it is the hardware cable that is used to connect CAN and USB on the PC. Kvaser Leaf Light is one of the best-suited interfaces in the industry for all the CAN applications. It is sturdily built and has stable drivers and APIs, high accuracy and supports several analysis software. It also supports diagnostic standards like SAE J2534 (passthru), J1979, J1939, ISO27145 (WWH-OBD). So, it is one product for CAN as well as all the diagnostic standards. For analyzing CAN data CANEasy an be used, it is a Windows-based development tool that can be seamlessly integrated into any existing toolchain. With CanEasy, real and simulated electronic control units [ECUs] communicate across different buses following the communications matrix [residual bus simulation].

The best and widely used diagnostic software  in industry are DiagRA D and Silver Scan-Tool. They work on plug and scan principle. DiagRA D is highly configurable diagnostic tool (ODX compatible ) and Silver Scan-Tool is the best generic OBD scan tool used by OEMs, suppliers, and authorities all over the world.