Below we shall consider the three diagnostic OBD protocols, UDS and KWP older 2000th But first the most important principles of diagnostic protocols.

The section is divided as follows:

• All­ge­mei­nes
• Adressierungsarten
• Security concept - diagnosis sessions
• Secu­ri­ty Access

All­ge­mei­nes

The basic principles are the same for all three protocols, although they differ in some details from each other.

 Diagnostic communication according to the request / response method

For all the request / response communication principle is used: The diagnostic tester sends a request, the request to one or more control devices and replaced by the control unit, a positive or negative response, the response. Within the request message is the first byte, called a service identifier to distinguish the various diagnostic services and the tasks to be done. The remaining bytes contain parameters and data.

Aufbau der Diagnoseservices

To distinguish the parameters from each other, we have introduced additional indicators. For OBD KWP 2000 and they are called parameter identifier (PID) and UDS level identifier (LEV). The controller responds to a diagnostic query with either a positive or negative with a response. The positive response in the first byte contains the SID again. This is basically the bit 6 set. Mathematically, this corresponds to an addition of 0x40 to SID. In the rest of the data bytes of the message sent back the PID and the response data. On error, the controller sends back the so-called negative response. The first byte is then always 0x7F. The second byte contains a copy of the SID and the last byte of the so-called response code. This describes the error.

Bereich für Genormte Service IDs 

The three diagnostic protocols differ in the various diagnostic services and their parameters. Fortunately, you have to OBD UDS and made sure that the SID regions are chosen decisively. OBD for the SID range between 0x00 and 0x0F is reserved, the corresponding positive response messages will then have a value that is greater at 0x40, 0x40 and 0x4F lies between. This service IDs are defined in the OBD standard in ISO 15031-5 and ISO for UDS in the 14229th In the UDS field to 0x10 0x3E and bus specific tasks of the range 0x83 to 0x87 is reserved. KWP 2000 uses the same SID field, so the UDS and KWP 2000 in the same vehicle network unfortunately can not distinguish. Finally, there are two other areas SID: 0xA0 0xB9 and up to 0xBA 0xBE that are reserved for vehicles and control equipment manufacturer-specific diagnostic services.

Typical error response codes

The error response codes indicate an error. You are in the table for all three standards listed and quite uniform, see above. Sun 0x10 means a general-Reject, ie, a general, not further specified error. The response codes 0x11 and 0x12 to indicate that a service or a specific sub-functions are not supported by the controller. 0x13 means that the message format is not correct and 0x31, it means that although the diagnosis service is supported in principle, but was exceeded in some parameters of the range of values. Furthermore, there is some diagnostic services that need to run a long time. There, the control unit of the response code 0x21 (Busy-repeat) and 0x78 (response pending) to tell the tester that it needs some more time to deliver the response message. In the case of 0x21 must repeat the request of the testers. In the case of 0x78 must wait for the diagnostic tester to the controller sends the actual answer.

Adressierungsarten

Another commonality of the three diagnostic protocols is the addressing of diagnostic tests and control devices. In the simplest case, the so-called physical addressing is used. Here are the diagnostic tester and the single control device a unique pair of addresses. In the case of CAN, the addresses of CAN IDs are shown: with a CAN ID send the tester's messages (requests) to the corresponding control unit, with another sends the controller's response (response) back to the diagnostic tester.

The so-called functional addressing one has used for cases in which the diagnostic tester does not know exactly which and how many controllers are installed in the vehicle. It only applies to the tester to the ECU. In the reverse direction - from the control devices to the tester - is always used the physical address. In addressing this, there is an address for an entire group of control devices and therefore must expect the diagnostic tester so that the answer to a single request request more control devices with a response message. In general, control units therefore have two addresses. A physical and optionally a functional address.

Addressing modes - functional and physical addressing

The principle is illustrated by an example with a diagnostic test and two control devices, the picture above. The specified CAN-IDs are from the OBD standard. There are those prescribed by the legislative. While manufacturers may be selected specifically for the general vehicle diagnostics (UDS), the CAN IDs. The diagnostic test is a request and because he did not know exactly which control devices are installed in the vehicle, it uses the functional addressing. With OBD, the functional address for emissions-related control devices - for a 11-bit CAN Identifier - set to 0x7DF. We now assume that the answer to this address two ECUs and ECU 1 ECU 2. The controllers respond each with a unique physical CAN-ID. The OBD standard specifies that to be spent on the response of the control unit 1 and the address 0x7E8 for the ECU 2, the address 0x7E9. Then would the diagnostic tester specifically addressed a request to the control unit 2. This reply does not control device 1 or other control devices, it uses the unique physical address of the control unit 2 - in the OBD standard set at 0x7E1 - and thus gets only this one answer - namely, the physical address 0x7E9, the same with which it has also replied to the functionally addressed request.

Since OBD tried to be largely independent bus system, the functional and physical addresses are not described in the OBD standard, but in the ISO 15765-4 (CAN diagnosis). The addresses are different, depending on whether 11-bit or 29 bit CAN identifiers are used, see table.

For OBD-related devices are the addresses in ISO 15765-4 fixed

The device addresses are in KWP 2000 (K-Line) and transmitted in the first bytes of the FlexRay Nutzdatenbotschaft. In addition to CAN, there are normal or extended addressing. Here the first data byte of the message is used for addressing. That is, the payload is again reduced slightly. For this reason, trying to avoid the extended addressing.

Further still are the timeouts (time constraints) is important. In the CAN controllers typically must respond within 50 milliseconds. It should be noted, particularly in the functional addressing. Since the diagnostic tester does not know how many controllers respond to his question, he must always wait until the timeout, or 50 milliseconds, before he can request the next diagnosis. This could for example take 50 installed in the vehicle control units for a few seconds. In physical addressing, however it can, as soon as he received a reply message, immediately send the next diagnostic request.

Security concept - diagnosis sessions

With OBD, there is no security concept. This is not critical insofar as the OBD diagnostic services can retrieve data from the control unit only. The only diagnostic service, the content here changes the ECU is the service that clears the fault memory.

At UDS and KWP 2000, however, there are a whole series of services involving ECU content could be manipulated. Therefore, it is there a security policy that prevents unlimited access to the ECU.

Security concept - diagnosis sessions

Normally, a control device is in the so-called default diagnostic session, as illustrated. Here are just a small, non-critical part of the diagnostic services can be used, and only a small part of the measurement and control device data can be read. may not actually be written. If one of the diagnostic services are necessary, which can be read critical data or even be written, it must be switched into a special diagnostic session. There are at UDS the diagnostic service StartDiagnosticSession. Typically, there are several diagnostic sessions with different groups of diagnostic services, such as the programming session (for flash programming) and the extended diagnostic session (within the workshop for the re-adjustment of different parameters). When switching from the default session in a special session is usually a specific login procedure is necessary, so-called Security-Access, see the next section. The non-default session is maintained only if the diagnosis diagnostic tester regularly sends requests to the controller. Otherwise, start as soon as the non-default session was entering a timer. If this goes into the timeout, the controller is automatically reset to the default session back with the limited scope of diagnosis.

Secu­ri­ty Access

The login procedure, the so-called Security-Access uses a seed-and-key method: The diagnostic tester requests the Access Security with a Security Access Request message. Are shown in the following figure symbolically the SID and the necessary parameters.

Security Access - "Seed & Key" method

This request asks the diagnostic tester called a seed to the control unit. This is simply a random number generated in the control unit. It is used in the diagnostic tester as initial value for a secret algorithm by which it calculates the key (key). The key is then returned to the control unit. The control unit calculates in parallel with the same algorithm is also the appropriate key and compares the diagnostic tester comes with the self-calculated. Votes Keys allow two match, the control unit diagnostic tester access to the desired diagnostic session and responds with a positive response.