About the Project

The last years I have been working on this project at university and want to share at least some basics. The whole project is really complex involving a datalogger management platform, wifi server upload and automatic database import, software version managment, data processing with online viewer and so on... 

If you are interested in more scientific projects of my former research group, check out their links page:https://www.linkedin.com/company/tum-smart-mobility/

Vehicle Diagnostic Protocols

Vehicle manufacturers are engaged by law to provide an OBD-II socket in every car. This is intended for emission control and workshop diagnostics in case of malfunction, all covered by the OBD-II protocol. But manufacturers also use it for their extended diagnostics of subsystems. This needs some further knowledge on vehicle diagnostic protocols. Different manufacturers, models series and production year use different protocols. This article shows some insights into these different protocols and how to handle them.

Diagnostic Protocols used in an automotive environment are in general request-based and can be divided in transport protocols (ISO-TP, TP2.0) and application protocols (UDS). Most modern vehicles use ISO-TP and support UDS functions to read data from storage registers, like service Read Data by Identifier (0x22). The description of the data stored in these registers is defined by ODX and may vary for each ECU and vehicle model. ODX definitions are normally not publicly available, but can either be implicitly extracted from workshop test equipment by matching the CAN Bus traffic with the requests and actual data displayed as reference or just by reverse engineering without reference values by triggering states and events on the vehicle leading to known signal paths.

Most diagnostic protocols use CAN bus as a physical transport layer. But you need to differentiate to CAN messages used in normal automotive applications, where there is amassage with a fixed ID containing some data. In diagnostic protocols, there are sessions, multi-part messages, and functional addressing. Without a request triggering an ECU to reply, there is no information at all. This implies to handle with timeouts, negative responses and timing requirements according to request scheduling.
This illustration gives an overview of the diagnostic and transport protocols used inmodern vehicles. The old KWP2000 protocol also is partially included in the UDS specification.

You see, all current diagnostic protocols are included in UDS, and transported over ISO-TP (some older VW use TP2).
The UDS specification includes a wide range of functions, most applications get alongwith a fraction of it. And that’s how it’s handled: A application normally only supports thepart of UDS ist uses, do not expect more than that.

Transport Protocols

There is a nice overview of the TP2 protocol on http://jazdw.net/tp20
And also for ISO-TP, there is much information available, already. And it’s not that complicated. So I’ll focus on diagnostic protocols instead.

Diagnostic Protocols

UDS is the new standard used by almost every manufacturer. It provides different services from a simple E-OBD request up to authentification and ECU firmware flashing. Most of the functions are not relevant for normal users, because the specification only defines the way of access and transport structures but no specific data, memory addresses and credentials you need to access these functions.
For just reading values, you only need two commands:

• 0x10 Diagnostic Session Control
• 0x22 Read Data By Identifier

The first one 0x10 tells the ECU to switch to another diagnostic mode, in our case we need “Extended Diagnostic Session” (0x03) 

After a positive response of the ECU, we can read registers with “Read Data...