Objective: To develop an OBDII diagnostic Scanner

On Board Diagnostics is a universally defined protocol to fetch diagnostic information from cars. This is developed primarily for technicians and service centers to diagnose and troubleshoot cars. Every OEM is bound to broadcast certain service related signals on universally defined IDs. The service technicians are equipped with tools that read can read these signals and can figure out what the problem is. These is a very elaborate article on Wikipedia explaining the details of this protocol.

 This protocol is a request-response protocol. This means that if you request data for certain signals (following a certain set of rules), then the vehicle would respond with the requested data.

 A typical request message looks like the one below

obd_req

The request is 8 bytes long and usually every byte means something. Usually the request is sent on ID 0x7DF. Any message on this ID is recognized by the vehicle ECU as an OBD request.

  • Byte0: This tells how many data bytes the request is of. Here a number of 2 means there are 2 bytes (byte 1 and byte 2) which are used for the request. Rest of the bytes are not used.
  • Byte1: Mode: There are 9 modes universally defined and a certain group of signals are bucketed in each mode. This list is available on Wikipedia
  • Byte 2: PID Code: This tells which signal is been requested from the bucket of multiple signals in the mode defined on byte 1
  • The other bytes are not used.

A typical response looks like:

obd_resp

The response is alse 8 bytes long. A multiframe response would be a set of 8 bytes repeated multiple times. Usually the response is given on an ID which is 8+the request ID.

  • Byte0: This tells how many data bytes the vehicle is sending. A value of 3 would tell that there are byte 1, byte 2 and byte 3 with real data, other bytes may have garbage values.
  • Byte 1: This is usually 0x40+modeNumber. If the mode is 3, this byte will be 0x43. If you get anything else than this, there is some error in transmission and you should not believe this data
  • Byte 2: Usually this is the ID of the signal you requested.
  • Byte 3 through 7 is the actual data.

The following video shows how to fetch data from the OBD port.

[coming soon]

Developing a Scan Tool:

After you know how to get relevant data from your vehicle, its just a matter of coding to make a service tool and sell it to your local dealership. I used python and PyQT4 to code and design the user interface.

There are there parts to create this tool

  • Creating a Graphic User Interface. PYQT4 is a great python based free platform to create GUIs. You can pick and place buttons/ indicators on your design
  • Coding to display data. The second part is to implement the OBD request-response protocol I explained above to fetch data from the vehicle. I used Kvaser for this. Kvaser has a python library and I wrote a driver to fetch and parse the incoming data. Using signal-slot method I am displaying the data on the tool.
  • Packaging it into an executable. I used Pyinstaller to package it into a distributable so that it can be installed on any machine (windows and linux) and can be used by service technicians.

TOOL

After you connect your Kvaser dongle to the OBD2 bus, you start this tool and click Start. This will fetch data from the vehicle and display it on the tool. If you check the log option, it will log the entire CAN bus of the vehicle. These are some of the signals I have reverse engineered for various vehicle platforms. (I am hiding other tabs for proprietary reasons).

Advertisements