German English

OBD on CAN

(3 votes)

The exhaust gas legislation and along with their on-board diagnostics for emissions-related systems has a long history. Back in 1970, Congress decided after preliminary work, particularly in California, the Clean Air Act, the first legislation regulating the emissions of cars dramatically. At the same time, the Environmental Protection Agency (EPA) was founded with the objective to monitor the emissions standards and further develop. In the episode saw the introduction of the catalyst, the electronic ignition and electronic fuel injection in conjunction with the lambda probe.

Geschichte On Board DiagnoseHistory On Board Diagnostics

Very soon it became clear that the electronic measures to improve the exhaust gas also require a diagnosis and a diagnostic interface. 1982 GM implemented for the first time was then, a proprietary interface for on-board diagnostics. And in 1987, this interface was introduced together with a series of further measures for monitoring the emissions performance of new vehicles in the U.S.. First by the California Environmental Protection Agency, the Californian Air Resources Board (CARB) and later by the EPA for the entire United States. 1996/97, the rules were further clarified and strengthened. We speak in this second generation of OBD II

In Europe lagged somewhat behind the development. In 2000, for model year 2001, the European version of the on-board diagnostics was introduced. It is there under the name JOBD. In 2000, for gasoline vehicles in Europe over the appropriate regulation of U.S. large extent. For diesel vehicles, the binding only in the years 2003 / 04.

Tasks of the OBD

  • Continuous monitoring of all emission related components
  • Detecting emission increases during the term
  • Ensure low exhaust emissions
  • Protection of components, such as a catalyst in misfire
  • Reporting of emission-related defects on the driver
  • Save errors
  • Provide a diagnostic interface

What are the duties of the on-board diagnostics? First, the monitoring emission-related components. The OBD rules here require that emission increases must be recognized at a certain limit during the lifetime of the vehicle. This is to ensure that exhaust emissions not only in the type approval, but for the life of real vehicles remain low. Furthermore, measures to protect components. In gasoline engines, for example, catalysts are destroyed by a misfire relatively quickly. This requires the on-board diagnostic measures for monitoring, which should prevent this destruction, and thus the failure to work the catalyst. The detected errors must be reported to the driver. There is also an indicator lamp in the dashboard, called the Malfunction Indicator Lamp-, short-MIL. The errors must be stored in the control devices. And this memory must be made available on an appropriate diagnostic interface for shop tester. The most visible consequence of the introduction of OBD regulations led to the diagnostic connector, although it long before diagnosis interfaces were already in all vehicles had long each manufacturer's proprietary connection technology. In the controls this OBD ISO 15031-3, or the same content as American standard SAE J1962.

OBD-Diagnosestecker nach ISO 15031-3 bzw. SAE J1962OBD diagnostic connector according to ISO 15031-3 or SAE J1962

How should look the diagnostic connector, you see in the picture above. What you can rely on in practice, the installation of the driver, not in the engine room, but in the passenger compartment and the minimum pin assignment with battery voltage and ground connections. You also see that suggested by the standard assignment for the three different interfaces: the K-Line for Europe, SAE J1850 for American cars and since 2007 / 08 is binding on both the U.S. and in Europe CAN.

About the diagnostic interface

The diagnostic services of the on-board diagnostics are defined by the ISO 15031 part 5 and the substantially identical content standard SAE J1979. These two standards are initially independent of the bus system. The specific regulations for CAN bus system in ISO 15765, there described in Part 4.

The requirements here are in CAN that the ISO transport protocol to be used, the CAN bit rates either kbit 250 / s or 500 kbit / must be second, and that either 11 bit or 29 bit CAN identifier must be supported. This means that a control unit using one of the two bit rates, or one of the two lengths must identifier. A diagnostic tester must, however, support both bit rates and lengths of both identifier and automatically detect which works with the bit rate control unit. It also required that uses the ISO transport protocol flow control is always a block size of zero and a minimum separation of zero-time also. Requests for diagnosis, a functional addressing the diagnostic tester must be prescribed and used it for 11 bit CAN IDs CAN-ID 0x7DF be.

Control devices that do not support a request to OBD some diagnostic tests are, in order to relieve the bus communication, do not respond with a negative message.

Zulässige Diagnose-Requests, sgn. „Test Modes“Permissible Diagnostic requests sgn. "Test Modes"

The maximum diagnostic services (diagnostic requests), at SAE "test mode", shall be listed in the table above. They are relatively straightforward. There is a group of two diagnostic services that serve the recall of measurement and vehicle data. The service ID 0x01 can query data. Which is specified by additional parameters identifier, see the following example. The service ID 0x09 can be queried general vehicle information on the VIN number, software or hardware version numbers of the control units. Then there is a group of services that relate to the error memory. The service 0x03 you can read error codes, with the service 0x02 data that was saved when an error occurs in the ECU, so-called freeze-frames. And last but not least, you can delete the error memory with 0x04 service.

Then writes the OBD standard for a series of tests, for example, the tank vent in order to test the catalyst in order to test the function of the lambda probe and the like. With the services 0x06, 0x07 and 0x08 are specified appropriate diagnostic services that perform such tests and inspections or query.

First example: read data

As a first example we want the diagnostic service 0x01, the service with which you can read data look more closely.

Auszug aus ISO 15031-5Extract from ISO 15031-5

To this end, we take a look at the ISO standard. In the table 127 of the standard diagnostic service is 0x01 described in more detail, the picture above. You see here in the first line the name of the service and you will see here in this column are M. M stands for mandatory, that is "authentic", and here a hexadecimal value 01 That is, if you use the diagnostic service, you have to send in any case, the hexadecimal value 01 as the first byte of the message. This is the SID. Then follows the PID. You see it in the second line M for mandatory, and in the following lines U for user-defined, so any number of other PIDs. So you can retrieve with this diagnostic service one or more readings. Analytical results are available here and how they are formatted, is in another table in the so-called Appendix-B. There in the table B.6 the PIDs for the service 01 are defined. Here we find among other things, the 05th PID The PID allows us in 2005, the Engine Coolant Temperature, then read out the engine temperature. The corresponding data format is as follows: we have a byte which contains the values ​​range from -40 ° C to +215 ° C. We thus have a resolution of 1 ° C with an offset of -40 ° C.

The response is described in the table 128, the picture above. There you can see that the hexadecimal value returned 41 as the first byte must. This corresponds to the SID, when the bit is set 6, ie an increase from 0x01 to 0x40 SID. That is exactly 41 hex Then, the PID will be returned as a copy. Then follow the data bytes and data bytes that the value is to provide a measurement value correspond.

The Appendix B contains a series of measurements. Of course not every controller supports all measured values. Analytical results are supported, is in the documentation of the control equipment or diagnostic test queries so. There is also a special PID, the PID 0 that is on all diagnostic services in use. In response to the PID 0, the controller returns a bit field that indicates which PIDs are supported.

SID = 0x01 (Abfrage von Messdaten); Auswahl des Messwerts erfolgt über PIDSID = 0x01 (query of data), selection of reading via PID

In the table above, some of the readings are listed. For example, PID 0x01: Number of errors in the error memory, PID 0x04: engine load (percentage between zero and 100% coded with 8 bits), PID 0x05: cooling water temperature and PID 0x0C: engine speed (16 bit value with a resolution of one revolution per minute ).

Request zum Lesen der Kühlwassertemperatur (PID = 0x05) vom Tester zum SteuergerätRequest for reading to the cooling water temperature (PID = 0x05) from the tester controller

Now look at our example of reading out the cooling water temperature in all details (including CAN-ID, and including what happened at the transport layer). We have the diagnostic request coming from the diagnostic tester to the controller, as shown above. There must be functional addressing. We assume that we use a 11 bit CAN identifier. This is 0x7DF by default. Since that message with 2 bytes of user data manages, this means that enough at the transport level, a single frame. Accordingly, the PCI byte followed by the value 02 (zero shows the single-frame, and the two shows that two user data is sent). Then the actual request. The request has the SID 01 and the 05th PID

Response des Motor-Steuergerätes zum TesterResponse of the engine control unit to the tester

The response, the response of the control unit is shown in the picture above. Here, the physical address of the tester to the first control unit is assigned to be used, according to norm 0x7E8. This is followed by a PCI-byte of which indicates a single frame with 3 user data bytes. Now comes the actual response message: it starts with the increased to 0x40 SID, in this case 0x41. Then, the PID is returned 05 and then the actual engine temperature. Suppose the temperature is currently 62 ° C, producing the 0x66.

Interpretation of the numeric value 0x66: We know that the engine temperature is an 8 bit value, normalized for the range between -40 ° C and +215 ° C. The 0x66 must first be converted to a decimal and then, as we have an 8-bit high value of 8, ie 256 divided by 2. The whole thing has to be multiplied with the value range (maximum value minus minimum value, ie 215 minus 40 ° C) and added to the offset (here, -40 ° C). This results in 62 ° C.

Second example: read VIN

As a second example we want to read the VIN number with SID 09th And if you turn in Appendix B of the standard-look, you realize, for the chassis number, we need the PID 02 That is, the request message to the ECU contains the data bytes 0x09 and 0x02 as a PID as SID. The corresponding control device response is shown in the table 186 in the standard, as shown below. The response begins with the SID increased by 0x40 (0x49), followed by the copy of the PID 02 and then the value 01 This value indicates how many chassis numbers are stored in the ECU. There are countries where there is more than a chassis number. In Germany, this is currently not the case. Therefore, this is usually the value 01 Then follows calibrate the chassis number, although a total of 17 ASCII characters. Here you can see in the example, the ASCII character codes in hex (0x31, 0x47, etc.).

Auszug aus ISO 15031-5Extract from ISO 15031-5

Now consider how this diagnostic service is implemented as a complete sequence of CAN messages.

Request zum Lesen der Vehicle Identification Number vom Tester zum Steuergerät (SID: 0x09, PID: 0x02)Request to read the Vehicle Identification Number from the tester to the ECU (SID: 0x09, PID: 0x02)

First, the diagnosis request (Request) of the control unit diagnostic tester: Functional Addressing and 11-bit CAN identifier return the value 7DF. Then follows the PCI byte for a single frame with 2 bytes of user data. Now comes the real question with the SID 09 and PID 02

The response of the control unit, the chassis number with 17 characters would not fit into a single CAN message. Therefore, we have now at the level of the transport protocol, a sequence with a first frame and a number of Consecutive Frames. Let's start with the first-frame, as shown below.

Response des Motor-Steuergerätes zum TesterResponse of the engine control unit to the tester

For the physical address of the first control device provides for the OBD CAN-ID Joint 7E8. Then the 2 PCI-bytes of the first frame. The top 4 bits (here: 1) characterize the first frame, the following 12 bits (here 0x14 = 20) the number of user data bytes. Then come to the increased SID 0x40, (0x49), the PID 02 and continue to really 17 characters of the VIN number. It begins with the number 01, which indicates that exactly one vehicle identification number is stored. Now follow the first three ASCII characters (0x57 = W, A = 0x41, U = 0x55). The pictured vehicle is a chassis number of the company Audi. Thus, the 8 bytes of the first CAN message are filled.

It follows, not shown, for the first frame of a flow-control control unit diagnostic tester. Then the controller sends a second reply message, that is the first Consecutive frame. He has the number 2 in the first place of the PCI-bytes and a sequence number 1 in Now follow the 7 remaining user data bytes in the next 7 ASCII characters. The next Consecutive frame with the sequence number 2 then provides the remaining ASCII characters. With three messages, the response has been processed.

Third example: memory error

In the third example, we will now consider a sequence of diagnostic services with which the history can be read. To make the example a little clearer, we have omitted, unlike the two previous examples, the level of the bus system and the transport protocol level. So you see here no CAN identifier and no PCI-bits.

Auslesen des Fehlerspeichers nach OBDReading out the error memory OBD

The query whether and how many mistakes are stored, is carried out with the service 01 and PID 01. Look at the response the SID 41, PID 01 and then dimmed, a number of bytes that contain the actual answer. The first byte 83 is the most important. If the top bit 0x83 is set. According to the standard that is, the Malfunction Indicator lamp is turned on. The lower 7 bits (equivalent to the value 3 here) indicate that three faults are stored. The following 3 bytes provide information on which enabled monitoring system during the previous cycles or not activated. This is important because it may be - if no errors were displayed - that the vehicle is driven in cycles, in which certain inspections were not active. For example, in the short-distance transport can not reach its operating temperature of the catalyst. Therefore, the catalyst and oxygen sensor monitoring shall not be engaged in full.

Let us consider next the query which errors are stored. We know that there are three of them, but we are not sure which. Therefore we use as the next diagnostic service with the SID 03 with no parameters. In the answer we get back together with the SID three times 2 bytes. The 2 bytes represent a so-called Diagnostic Trouble Code (DTC), see below. This is a coded hexadecimal error code. In our example, the first error the value 0x0119.

OBD-Fehlerkodes nach ISO 15031-6OBD error codes to ISO 15031-6

If we look in the standard, we see there an explanation of the error code (2 bytes DTC). The top two bits, the diagnostic tester typically represented as a character and that P, C, B or U. P stands for power train (power train), C for chassis (chassis), B (body electronics) and in practice not so U rare for any problem in the bus system.

Bit 5 and bit 4 of the first byte indicate the first digit of the error values. This number indicates whether the error code is defined by the OBD standard (0) or at 1 or 2, the error code from the ECU or the vehicle manufacturer defined. He therefore does not correspond to the standard.

The second number is defined by bits 3 to 0. It shows - if the error code is an OBD error code - ever occurred in any component of the error. 1 and 2 refer to the injection system, 3 for 4 for the ignition and the exhaust gas or air system.

The next 4 bits, the third figure shows the component in more detail. For example, the injection, the injection nozzle or a particular lambda sensor. The fourth paragraph describes the error. Here, for example a loose connection, so a signal is outside the normal working area.

If you look for our example 0x0119 in the standard, you notice the error relates to the driveline, the error code defined by ISO, we are dealing with a bug in the injection system and that is not the water temperature sensor in order. The controller says that the sensor has a loose connection.

Let us now return to the penultimate image "error reading the memory after OBD". If the error code are not as information for troubleshooting is adequate, we still could, for example query, in which engine speed, engine temperature, etc., in which the error occurred. To obtain this information, we need the so-called freeze-frames. These have the SID 02 and the corresponding PIDs are listed in the standard.

If the error is corrected on the basis of this information, we can clear the fault memory. We use the service with the SID 04, which requires no additional parameters.

In contrast to the on-board diagnostics, which provides relatively few features and can be accessed that essentially read only, provides UDS provides functions that allow virtually every detail of the control devices are operated. Then we make in the next section.

See also

  • Created
    12. January 2011
  • Version
    4
  • Amended
    05. April 2011
  • Hits
    4739