OBD Car Doctor - History of Mobile Application Development

The idea of connecting a smartphone to the on-board vehicle system appeared long time ago, as a starting point was an article about e-filling of the modern cars and CAN network that transfers data of different devices connected to it. The research of the possible ways of launching to the car shows that the diagnostic connector DLC - Data Link Connector, which serves to connect the on-board network of the car to the auto diagnostic scanners and request/read data from different vehicle’s subsystems.

The problem connected with the number and variety of cars’ brands, scanners, connectors, has been resolved due to one of the environmental agencies of the United States - California Air Resources Board - CARB, which is responsible for vehicle emissions control. Today there is the actual set of OBD-II standards, which specifies the type of diagnostic connector and its pinout, the electrical signalling protocols available, and the messaging format. It should be mentioned that the compliance with one of the parameters does not guarantee compliance with the others. So, right mechanical connector in the car does not guarantee compliance with the standard signal and logic protocols, accordingly doesn’t necessarily ensure compliance with OBD-II standard. Let's consider the above-mentioned levels of compatibility:  

  • Mechanically it is the female 16-pin (2x8) J1962 connector.
  • Electrical signal level defines supported protocols:

- SAE J1850 PWM

- SAE J1850 VPW

- ISO 9141-2

- ISO 14230 KWP2000

- ISO 15765 CAN

  • Logic level specifies sending of the default structure messages and thus receiving a structured response. The package consists of a header, the message body and a checksum: <header> <body> <crc>
Let’s consider the structure of the request body:
 
The structure is represented as <body> <mode> <pid>.
 
  • <mode> (1 byte) defines the functional group of parameters, such as 01 - the parameters of real-time, 02 – freeze frame of the parameters at the time of the error, etc.
  • <pid> (1 or 2 bytes) - Parameter ID, requested parameter identifier in the context of group, for example for mode 01 pid 0D mode is responsible for the current vehicle speed.
 
For example, 68 01 6C F1 0D A6, where the header = 68 6C F1, body = 01 0D, crc = A6.

Response body structure contains the return code:

  • for a positive response <mode+0x40> <pid>
  • for information about the error 7F <pid | mode>
  • then the actual return value
<header> <body> <crc>.

As a result, we obtain a set of commands described by the standard, with different models of machines supporting a small part of this list. In addition, OBD-II standard provides customized commands that are specific to certain car brands and models, but the public information on these commands is not available. Summing up the results. We have a list of parameters described by the standard and if supported by the car, they can be read. Usually it is the dynamic parameters that can be monitored in real time (speed, rpm, temperature, parameters of lambda sensors, parameters to calculate fuel consumption, etc.), errors leading to CheckEngine indicator turn on; cat on-board systems self-diagnostics results. Also clear error codes feature can be supported. Also, hypothetically it is possible to rich to the car user settings, a list which is much larger than the standard. By this article we open the cycle of notes on software solution and applications for motorists.   Detailed article, as well as its second part can be read at PNN Soft unofficial blog at Habrahabr.