Vehicle Diagnostics is like speaking to a vehicle, more precisely commanding. If you give the vehicle the right command in the right manner, it will respond back. Note that diagnostics is always request-response. It is not like CAN messages which are available on the network without any request.

So, in what format or protocol should the commands (or more accurately called requests) be sent? Who decides these formats or protocols?

Of course, the protocols can be decided and implemented by any Tom, Dick, and Harry! But such protocols lack the advantages of standardization. So, organizations like SAE (Society of Automotive Engineers) have defined standards that can be used in Automotive for vehicle diagnostics. Let’s look at some of the most important standards in use today.

Before diving into the standards, let us understand vehicle diagnostics and OBD. OBD stands for On-Board Diagnostics. How is it different from vehicle diagnostics? Well, it’s no different. The purpose and operation are still the same – to diagnose vehicles. The term OBD is regularly used to point to the data that the certifying authorities and agencies demand. Whereas Vehicle diagnostics is the term mostly used to represent OEM specific diagnostic data (the data that OEMs do not share with the agencies and would like to keep confidential). Such diagnostic data will be used by OEMs for testing their automobiles.

OBD standards – These standards define not only the protocols of the request (sent to ECUs) and response (from ECUs), but also the identifiers and corresponding data from the ECU. The data/information that can be read from automobiles is fixed in these standards. The codes/ids to be used to access the data are also fixed. There is no scope for changes/extensions/reductions in these cases. The format of the data, resolution, factors, offsets is fixed. These standards are used for certification and homologation purposes.

The well-know OBD standards are:

  • SAE J1979 – This diagnostic standard is majorly used for passenger vehicles like cars, SUVs, motorbikes, 3 wheelers (rickshaws, tuk-tuks), etc. To get to know the standard technically, access the documentation from SAE.
  • SAE J1939 – This is also called as HD OBD (Heavy Duty OBD). As you might have guessed, this standard is majorly used for trucks, buses and off-road vehicles (cranes, excavators).

An important fact to be noted about J1939 is that it was not developed for diagnostics, it is mainly a protocol that was developed for inter-ECU communication and the same protocol has been used for diagnostic purposes. SAE provides detailed technical documentation on J1939.

  • ISO 27145 – As mentioned earlier J1939 was not built for diagnostic purposes, but the dataset of J1939 is still valid for diagnostic applications. Hence the standard ISO 27145 was developed and it is called World Wide Harmonized (WWH) OBD. ISO 27145’s dataset is the same/similar to J1939’s dataset and as protocol part, UDS (introduced below) is used. This OBD protocol is gaining popularity over J1939.

UDS – This protocol called Unified Diagnostic Services. In this protocol, different services like how to read/write data, reading fault codes, diagnostics sessions are defined. This protocol does not define the dataset. Using this protocol, the OEMs have control over defining the data, the resolution, factors, offsets, codes/ids. OEMs can create their own dataset in the form of ODX files (Open Diagnostic eXchange) and that data can be used for testing. UDS is so powerful that it can be utilized for flashing ECUs.


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 BusMaster.

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.

CAN Frame

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.

CAN Frame - Diag

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.


BusMaster is an opensource analyzer software for CAN. It is free to use and provides good features for analyzing CAN data. Other commercial CAN software are CANalyser, VehicleSpy, CANLab, etc.

The best and most widely used diagnostic software tools in the industry are DiagRA D and Silver Scan-Tool. They work on plug and scan principle. DiagRA D is a 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.


Most of the time we associate Vehicle Diagnostics to OBD-II which is a certification requirement and the possibilities are extremely limited. But Vehicle Diagnostics opens up an entire lot of automotive testing possibilities. The following are the uses of Vehicle Diagnostics:

  1. Read data – data like engine speed, vehicle speed, temperatures, pressures, and several other vehicle parameters can be read and hence diagnostics can be used in different stages of testing like End of Line (EoL) Testing, Quality testing, Indoor testing, Outdoor testing, Performance testing, Service Testing and more.
    The A2L file that provides full access to ECU data is many times not available with teams performing EoL/quality/service testing. A2L files are confidential and providing them to different teams is a risky affair. In such cases, Diagnostics comes to the rescue. A diagnostic dataset (in the form of ODX files) can be authored and access to data can be specified in the ODX file. So, for different testing purposes, different ODX files can be authored limiting or allowing data depending on the requirements.
  2. Write data – yes, diagnostics is powerful enough and allows writing data into the ECU. And of course, what data can be written is controlled by limiting access. So, we can easily say that calibration is possible using vehicle diagnostics to a limited extent.
  3. Read trouble codes – The major application of vehicle diagnostics is reading trouble codes (widely called as DTCs). The errors and faults recorded by the ECUs a vehicle can be read out just by a click saving us the time and effort in finding out the problem.
  4. Clear DTC Information – After physically fixing the troubles/faults in the vehicle, the faults codes can be deleted from the memory of ECUs.
  5. Read Freeze Frame Data – When a fault occurs in a vehicle, a fault code is registered. For analysis of the fault, it will be helpful for the engineer if there was more information about the occurrence of the fault than just the fault code. The surrounding information (like engine speed, vehicle speed, temperature, pressure, etc) when a fault occurs is stored in ECU memory called Freeze Frame. Such data can be read out using diagnostics.
  6. Variant Coding – Many different variants of any vehicle are generally released with different features. Changing the software on the ECU to turn the features ON/OFF is not effective and involves huge efforts. That’s where variant coding comes into picture using which the engineer can easily enable/disable features of a vehicle depending on its variant. Such variant coding is possible using diagnostics.
  7. Actuator testing – We have learned that reading any sensor data is possible using diagnostics. It is also possible to check how actuators (injectors, brakes, mirror motors, lights, horns, etc) perform using diagnostics.
  8. IUMPR – In Use Monitoring Performance Ratio, is a ratio that tracks how frequently the systems in a vehicle are monitored on the road. Further, it is a measure of how good a system is. Such IUMPR data are read by diagnostics.
  9. Flashing – This is proof of how powerful diagnostics is; ECUs on the vehicle can be flashed just by connecting through the OBD port using diagnostics. A flash sequence is needed which can be defined inside the ODX file.

It is true that diagnostics applications are not as simple as listed above. But it can be made as simple as a click of a button by using DiagRA D. DiagRA D is an all-in-one Diagnostics software which groups and display data in a simple and human-readable format with the click of a button. DiagRA D reads the ODX file and configures itself with the diagnostics dataset. In case an ODX file is not available, DiagRA D allows the user to create a diagnostic dataset.

With DiagRA D different stages of testing becomes a simple process resulting in decreased testing efforts and increased quality of testing. The burden of understanding the insides of diagnostics is reduced on the part of the engineer resulting in better focus on the testing.


The market for Electric Vehicles is on the rise and development is heading at a fast pace. What about diagnostics on EVs?


This article speaks about different diagnostic standards for different kinds of vehicles and throws light on diagnostics for EVs.


There are different protocols/standards in vehicle diagnostics. The main ones accepted and used worldwide are:

BMW i8 plugged in and charging.
  1. SAE J1979 – This standard is mainly used for passenger vehicles like cars, SUVs, 3 wheelers, and 2 wheelers. The standard is developed for both Gasoline and Diesel engines.
  2. SAE J1939 – This is also called as HD OBD, stands for Heavy-Duty OBD. As the name suggests, the standard is used for heavy-duty vehicles like trucks, buses, and off-road vehicles. Primarily the standard was developed for communication between ECUs and later intensely used for heavy-duty OBD.
  3. ISO 27145 – This standard is also called WWH OBD, which stands for World Wide Harmonized OBD. Its applications are majorly in Heavy-Duty Vehicle. (Interested in a scanner that’s generic to the above 3 OBD standards? Try Silver Scan-Tool – A Plug and Scan generic OBD tool)
  4. UDS – UDS stands for Unified Diagnostic services and follows the document SAE J14229. The above 3 standards are accepted worldwide for certification and homologation by different authorities. UDS enables OEMs or suppliers to set up their own diagnostics which is useful for testing at different levels of development and also after-sales & maintenance. (Interested in an all in one diagnostic tool? Try DiagRA D, read about it, and get to know how it makes testing activities easier)

Now let’s talk a bit about EVs (Electric Vehicles). Until now, there are no OBD standards specific for EVs. For conventional engines, the standards and protocols are matured, accepted, and used worldwide. However, for EVs, none of the authorities or organizations have come up with any standard. The same standards may be used with EVs with changes like Motor speed instead of Engine speed, Battery status, etc. But it needs to be seen how it all turns out to be.

Until then the EV manufacturers and suppliers can use UDS for their own diagnostic applications. It is also seen that some of the EV OEMs are already using UDS.


  1. Accuracy of OBD standards: Silver Scan-Tool (SST) is used by authorities themselves for homologation and certification. Using SST you can make sure that there are no unfulfilled OBD conditions before going for certification.
  2. One tool for all OBD standards: There is no need to invest in multiple tools for different OBS protocols/standards. SST supports different protocols and standards:
    1. SAE J1979 – passenger vehicle OBD
    2. SAE J1939 – heavy-duty OBD
    3. ISO 27145 – worldwide harmonized OBD
  3. One tool for worldwide markets: SST supports OBD standards accepted by European, American, and Asian countries. If you intend to export vehicles you need not worry about OBD certification.
  4. No data configuration needed: You don’t have to worry about configuring data. SST is pre-configured with OBD standards and all you need to do is plug and scan. It saves time and avoids human errors.
  5. Quick updates: Any change in the OBD standards are updated and released in a short time. This way we make sure that you stay updated and ready for any certification procedures.

Know more about Silver Scan-Tool:

Vehicle Diagnostics – Internet of Vehicles

With BSVI (Bharath Stage 6 – BS6), On-Board Diagnostics (OBD) has become popular among the masses. More and more people have started to recognize and understand the role of electronics in automobiles.

Vehicle diagnostics opens up a plethora of applications in automotive engineering and forms the future of Automotive – Internet of Things “IoT” (also called as Internet of Vehicles “IoV”). As the name suggests diagnostics is about finding the faults in the system, but it does not stop there. With diagnostics, we can read not only fault codes but also other data pertaining to the operation of automobiles. We can also instruct the automobile to perform particular actions.

Below are a few applications that are possible with IoV through vehicle diagnostics:

Health of the Vehicle

  • Helpful to OEMs/Service stations in avoiding break downs and accidents by determining the issues of the vehicles in advance and fixing them.
  • Helpful to fleet owners in keeping their fleet of vehicles in good condition, thereby delivering on time and effective transportation services to customers.
  • Study of Driving Patterns

  • Helpful to insurance agencies in determining the value of the vehicle by studying the data from the vehicle.
  • The data helps greatly when reselling the vehicle.
  • Helpful to fleet owners in determining the driving patterns of the drivers.
  • Helpful to OEMs in understanding the driving patterns of their customers and accordingly calibrating the vehicles to deliver the best driving experience.

  • Quick access to Accident Data

  • Helpful to insurance agencies and police in determining the cause of accidents.
  • Video from dashboard camera of the vehicle can also be delivered over the air, which can help in determining the extent of accidents so that appropriate help can be sent to the accident site.
  • Helpful to fleet owners to send alternative vehicles to carry the passengers/goods.

  • Tracking Vehicles

  • Helpful to the police in tracking down vehicles.
  • Helpful to fleet owners in tracking the path the driver takes to reach the destination. This will help in optimizing the routes.

  • Immobilize Vehicles remotely

  • Access can be given to police to immobilize stolen/illegal vehicles remotely and trace the vehicles.
  • In GTA style chasing, the cops can immobilize the cars remotely, thereby protecting people and property.

  • Over the Air Software updates

  • Just like smartphones, software updates and calibration changes can be delivered to vehicles over the air. But care needs to be taken that the updates happen only when the car is not in use!.