Example: Fault (DTC-DOP, ENV-DATA-DESC)

As an example of complex data objects, we will consider reading the fault memory. Reading out the error memory is always in two stages. Remember: The content of the error memory consists of the number of errors from an error code for each error (DTC = Diagnostic Trouble Code) and a statute. The status includes whether the fault is active, whether it is a sporadic or a permanent error. Furthermore, the error memory consists of the environmental data, the so-called freeze-frame. These are measured values, such as the engine speed at the time when the error occurred.

To describe this error memory entries is ODX DOPs the DTC and the Environmental Data Description (ENV-DATA-DESC) ready. The figure shows a typical sequence of diagnostic messages is shown. He begins by reading out the error status. We sat in the example KWP 2000 as a protocol. The first diagnostic message is ReadDTCByStatus shown consisting of the request, here in orange, with the service ID 0x18 and the necessary parameters that characterize the contents of memory error. In the example of the entire error memory is read. On the right side is shown in yellow, the response from the controller. As is returned as an echo to the increased SID 0x40, 0x58 So. Will appear in the response, the number of memory error messages (here 2) followed by the actual error code and a status. Error code and status are then repeated as many times as there are errors.

The ReadStatusOfDTC message should now be read, which environmental data are stored on a specific error. This sends the diagnostic tester a request (REQUEST) for each error code that was read out in the previous message. The controller responds with the respective stored on this error environment data, ie engine speed, coolant temperature, etc.

Data elements for the fault memory DTC-DOP, ENV-DATA-DESC

How does the first part of the diagnostic message in ODX defined? Let's look at the structure, with the ODX the response message for the first request (first message highlighted in yellow picture above), defined as shown below.

Reading the error status memory - Positive Response by ReadDTCByStatus

The first data value in the response message is the SID for ReadDTCByStatus. We define a parameter of type CODED-CONST. The second data value is the number of errors. For this, define a parameter of type Value. You need is a SIMPLE-DOP, since the number of errors has exactly one byte, so has a fixed length. It is different from the other hand, with the data structure that results consisting of DTC and status of the bug. Since the number of errors is variable, may be repeated this data structure. It depends therefore on the first parameter. It will define the list of existing errors associated with their status, therefore, as a structure with a dynamic length (DYNAMIC-LENGTH-FIELD). Within this structure, we again refer to a structure consisting of the actual error code to 2 bytes, which is described by a DOP and the corresponding status with 1 byte, which is also described by a DOP. For the error code itself you will describe a DTC-DOP, which assigns the hexadecimal error code, a plain text description.

For the iterative reading of the individual fault memory entries in the second step, we now consider the response to ReadStatusOfDTC, as described in ODX.

After the SID in turn, the error code and the status of the error are returned. That is, as described in the previous section, represented by a structure, which in turn refers to a DTC-DOP. The environmental data that are returned when an error are dependent on the DTC. They are in the table Env Data Desc stored as a collection of structures. This table is indexed by the DTC at run time.