SOME ISSUES RELATED TO THE OBD DATA
SCANNING AND INTERPRETATION
Merkisz J., Kotowski M.
Poznań University of Technology, Institute of Internal Combustion Engines and Transport, Poznań, Poland
Automex, Gdańsk, Poland
Abstract: The paper is an attempt to collect and systemize the problems that diagnostic
technicians encounter when they try to scan and interpret the OBD data with generic scanning devices. The origins of OBD have been depicted in brief along with the objectives that the designers wished to attain. The transmission protocols have been characterized and compared in order to help the readers understand the difficulties which the manufacturers of both, software and ECU controllers, had to overcome. Further section of the paper discusses the procedures applied by the institutions responsible for type approvals of the scanning devices and vehicles for their compatibility with the OBD standards. The same section also discusses the errors occurring during the type approval tests. The final part is a representation of problems related to the OBD scanning and interpretation processes known to the authors. The final part also includes a troubleshooting guide.
1. Introduction
The notion of the OBDII/EOBD system is not abstract and only theoretical in use anymore. Independent car repair shops, LPG installation shops and vehicle inspection stations service vehicles which are OBDII/EOBD compliant frequently. A universal generic scanning device is not anymore perceived as expensive of a limited applicability. It became a common, must-have tool.
When it confronted with the workshop practices, the OBD system defends itself well despite of several shortcomings. At a relatively low cost of purchase of such a device, the mechanic has a tool that greatly facilitates the servicing procedure or in some cases is the only option to diagnose a vehicle. Vehicles fitted with self-test systems which are OBDII/EOBD compliant are doing fairly good with the assigned tasks.
The OBDII system was developed in the USA and introduced as obligatory in this country as early as in 1996. In 2001 its European counterpart– EOBD – became obligatory in the
EU member states and since 2002 it has also been obligatory in Poland. Initially, the obligation to fit vehicles with the on-board diagnostic system pertained exclusively to spark-ignition vehicles. Since 2004 all vehicles, including with the compression-ignition engine, are subject to this obligation. Taking the account of the above data we can see that the system has been present for 9 years. For all this period of time millions of OBDII/EOBD compliant vehicles and hundreds of thousands of scan tools for workshops and inspection stations have been manufactured [1, 2, 3].
The basic problem that the diagnostic engineers encounter when they service vehicles with the OBDII/EOBD scan tool is connected with difficulties establishing during communication with the vehicle controllers. There may be a lot of reasons for such a situation and these problems may be caused by the vehicle, the scanning device or the diagnostic engineer himself. This paper sheds some light on the problems with the application of generic scan tools, attempts to explain their possible reasons and hints some ways to resolve them.
2. Diagnostic information transmission in the OBDII/EOBD systems
One of the basic assumptions that were being taken into consideration during establishing of the OBDII/EOBD standards was to develop a unified communication system between the vehicle controllers and the external scanning device. The standards were to define i.e. the communication protocol, its layers (physical and application) and the diagnostic port. Pursuant to the intentions of the designers, the problem of matching the scanning device with the vehicle was to be resolved. Before the introduction of the OBDII/EOBD, each car manufacturer provided his own scanning device dedicated only to a small group of ‘own’ vehicles. The new assumptions provide that a single scanning device can retrieve data from any OBDII/EOBD compliant vehicle, irrespectively from the manufacturer. This was to be the paramount importance for the inspecting institutions and the car repair shops.
According to the SAE and ISO standards [1, 3, 4, 5, 6, 7, 8], the communication between the scanning device and the vehicle controller may be done through 5 basic communication protocols (table 1). Despite significant differences in speeds among the protocols (table 1), the transmission speeds are comparable and do not exceed 10–11 queries per second. This is due to the fact that, during the communication, a minimum space between the queries to the vehicle controller must be maintained. These time lags amount to 50–100 ms depending on the communication protocol.
Beginning from 2008 the only allowed communication protocol between the scan tool and the vehicle controller will be the CAN protocol. The above presented communication protocols have the following properties:
Table 1. Characteristics of transmission parameters for the OBD communication protocols Names of protocols/ abbreviationsStandard Transmission speed [kbit/s] Number of bit of the header Coding of data bits on the transmission lines Medium Initialization
PWM J1850SAE 41,6 24 Pulse widthModulation
Pair of wires (differential signal) PIN 2 i 10 none VPW J1850SAE 10,4 24 Variable pulse width (depending on the previous bit value) A single wire PIN 2 none
ISO 9141-2ISO 10,4 24 Voltage levels A single wirePIN 7 Required
KW2000 14230ISO 10,4 24 Voltage levels Pair of wiresPIN 7 i 15 Slow speed High speed CAN 15765ISO 250 11 Modulation realized through CAN bus controllers Pair of wires (differential signal) PIN 6 and 14 CAN bus controller configuration 250 29 500 11 500 29
PWM (Pulse Width Modulation) – has a two wire connection with the speed of data transmission of 41.6 kbit/s. The bus should be in the form of a pair of parallel wires with a fixed distance or in the form of a twisted pair. The logical states are encoded as signals of a fixed duration but variable modulation. The logical ‘one’ is coded with a high state, lasting for 1/3 of the whole bit length but the logical zero is expressed by a high state lasting 2/3 of the whole bit length. The remaining period of the bit is filled with a low logical state. The information transmitted via PWM is organized in the form of a frame whose length amounts up to 101 bits. Each frame contains special scripts aside from the data bits.
VPW (Variable Pulse Width) – as opposed to PWM only one wire is used for communication. The noise frequency range was reduced through variable bit length modulation in comparison to PWM the result of which was a reduction of noise affecting the OBDII system. The transmission compliant with VPW ensures a minimum range independent of the transmitted data (transmission of ‘1’ is of the same narrow range as is in the case of data with a 50% modulation of ‘0’ and ‘1’, which PWM does not provide). The drawback of this interface is its reduced transmission speed of 10.4 kbit/s, which means that each component needs a time window four times larger in order to transmit information as compared to PWM. The information transmitted via PWM is organized in the form of a frame whose length amounts to 96 bits. Each frame contains special characters aside from the data bits.
ISO the communication is established through one or two lines. The first line marked with the letter K is a two way line and is assigned for address and data transmission. The L line is the one way line which is used during the initialization of the communication to transmit address data and is subsequently switched to idle i.e. logical ‘one’. The data are transmitted with the speed of 10.4 kbit/s. The transmission format is close to RS serial transmission. This method of data coding, as opposed to PWM and VPW, does not ensure the minimum noise range generated by the OBDII bus. During the initialization the controller sends a synchronizing byte consisting of interchanging ‘ones’ and ‘zeros’ transmitted with the speed of 10.4 kbit/s. We can calibrate the diagnostic scanner precisely to fit the transmission speed by measuring the timing between the pulses. The scanner will then remain resistant to deviations from the established data transmission speed.
KW2000 the communication, as opposed to ISO, is performed through only one two
way transmission line marked with the letter K. The data are sent similarly to ISO with the speed of 10.4 kbit/s with 0.5% margin. Two methods of initialization are possible: low speed (similar to ISO) and high speed.
CAN is characterized by a quick data transmission, great flexibility advanced functions that boost the transmission stability (hardware detection and error signaling, automatic retransmission of corrupt messages, automatic permanently corrupt node cutoff).
The data transmission between the scan tool and the OBDII/EOBD system (within the B class network) is organized into frames whose structure, irrespective of the applied protocol is similar:
SOF ( Start of Frame) – the start signal of a frame (for PWM and VPW)
HEADER – the header containing pieces of information on: a frame type (a data scan command, a controller feedback), a number of data bytes, addresses of a sender and recipient; 11–29 bits;
DATA – data [1,3,7], 1–8 bytes
CRC – checksum, 1 byte (is realized through hardware and is
not included in the frame for CAN);
EOF (End of Frame) – the end signal of a frame (for PWM and VPW).
In the OBDII/EOBD system (class B network) there are two methods for data frame addressing: physical and functional.
By using the physical addressing we directly point to the network node being the recipient of the message i.e. particular vehicle controller. This type of addressing is frequently used in the network data transmission. In the CAN protocol, physical addressing is allowed exclusively for frames that control the data flow (Flow Control) of multi-frame transmission [1].
In the case of functional addressing the network nodes are assigned not only the unique physical address but also a functional one (common for a group of nodes). This means that the frame addressed in a functional way will be directed to more than one node (controller). This results in a much faster data scan from the vehicle controllers and guarantees that the query gets to all modules. In the CAN protocol the functional addressing is the only allowed method of data frame addressing [1]. By sending a query addressed in a functional way in mode 1 of PID 0, which the OBDII/EOBD compliant controllers obligatorily support, we can establish how many of those modules a tested vehicle has.
3. Testing of the scan tools with the OBDII/EOBD compliance
The tests on vehicle compliance with the OBDII/EOBD standards including the scan tools were and still are performed by state-owned homologation institutions. The basic tool used for these homologation tests is a specimen scan tool that complies with the obligatory standards in every detail. The selection of such a device and its thorough testing has a crucial meaning in further homologation tests for the compatibility with the diagnostic systems.
In order to verify the compliance of a specimen scan tool, variety of tests with the use of a specialized equipment have to be performed. The necessary equipment should include: an OBDII and EOBD system simulator, oscilloscope or electrical compliance measurement devices. The homologation institutions have only been using all these apparatuses for a short period of time. The reality speaks for itself: after the launch into the market of Volvo
vehicle supporting the 29-bit CAN protocol (Controller Area Network) only a few per cent of the scan tools were ready to establish communication with the vehicle and scan the data1 even though all of them had valid certificates.
For the first years of the presence of the OBDII and EOBD standards, the selection of a specimen scan tool consisted in a performance of several tests on real vehicles. If the scan tool communicated with the vehicle and could scan the diagnostic data from several vehicles it was presumed to be compliant. The usual methodology was to use a couple of specimen scan tools of different manufacturers. This method entailed many caveats such as:
– no possibility of scanning from a single vehicle or a group of vehicles the entire array of diagnostic data in all possible configurations and no possibility of execution of all possible procedures. Some of the procedures cannot be executed on a real vehicle until today. The authors of this paper have no knowledge of any vehicle that would realize the comprehensive component test2 in the OBDII/EOBD mode. The authors
reckon that a generic scan tool should have such an option,
– a device tested on a vehicle which is then supposed to be diagnosed with this device, proofs itself against the error code of such a vehicle.
To recapitulate, after a few years it turned out that the vehicles on our roads theoretically communicate with any and all OBDII/EOBD scan tools, but car repair shops have tons of scanners stacked on the shelves being universal only by name. The errors and inconsistencies with the standards were gradually corrected. The manufacturers of diagnostic devices, due to the nature of their products, can easily replace bad software in already existing devices. In the case of vehicles, such a replacement, for logistic and economic reasons, is impossible. We have to come to terms with the fact that for some vehicles a full communication might be difficult.
After the introduction in Germany of the obligatory standard of inspecting vehicles with the use of OBDII/EOBD scan tools, it turned out that there were more problems than expected. This particularly pertained to vehicles manufactured before December 2002. In these vehicles we may encounter problems with establishing communication as well as correct diagnostic data interpretation.
The following types and descriptions of software errors including hardware layer can be distinguished, that make the OBDII/EOBD diagnostic impossible in a trouble free way:
1Such scan tools included i.e. the products of: Sun (www.sun-diagnostics.com) and
Automex (www.automex.pl).
2According to the standards, the realization of the comprehensive component tests
(mode 8) is optional. The car manufacturers keep taking advantage of this opportunity denying access to this mode. In order to perform a test you must establish communication with the controller using a communication protocol provided by the car manufacturer which in fact means using an in-service scan tool.
3.1. Sensitivity to the order of protocol identification
When establishing communication with the vehicle controllers the diagnostic device performs a variety of actions which in this paper will be referred to as protocol identification. The order of identification is arbitrary [12]. The programmers who developed the software for the vehicle controllers omitted this important issue frequently, the result of which is that some of the controllers do not support identification order other than that specified by the programmer. This pertains particularly to the identification of ISO-9141 and ISO-14230 protocols (slow initialization). This results from the fact that the initialization procedure for both protocols is similar. In both cases, the diagnostic device sends a sequence of bits at the speed of 5 bits/s, which is to activate the controllers. If an activated controller uses the ISO-14230 protocol and the diagnostic device attempts to establish communication using the ISO-9141 protocol the controller will hang. We must then wait at least 5 s and retry to establish communication in a reverse order. It does happen that such an operation is not successful either. In such a case it is necessary to switch the ignition off and on again.
3.2. Simultaneous support of several protocols
The standards [12] force the car manufacturers to apply a single protocol for the communication with an external diagnostic device. Unfortunately, these standards are not entirely complied with. Volkswagen vehicles are a good example here – Golf V – capable of communication with the OBDII/EOBD via the KW 2000 or CAN protocols. In communication protocols where the transmission is realized on different pins, it is possible to identify several protocols at the same time [12]. As a result of the above the time needed for establishing the communication is shorter. The application of the above procedure in vehicles supporting more than one communication protocol would probably result in a total lack of communication. None of the diagnostic tool manufacturers known to the authors applies this subtle method of protocol identification. It is though feasible that such scanners will appear in the market soon. It is hard to predict what will happen to the controller being initialized by two channels simultaneously, not to mention the diagnosing device successfully initializing the communication in several standards at the same time. We may only hope that the software developers did take this into account.
3.3. Faulty headers
Some vehicles communicating with a diagnostic scanner via the PWM or VPW protocols create data frame headers using wrong values. To exemplify: a data frame sent from the scanning device with the header 68 6A F1 should receive response with the header 48 6B 10. Some vehicles respond with a sequence of 68 6B 10. This fault blocks the communication with the majority of universal scan tools.
As per the SAE-J1979 standard, a maximum response time of the controller to a diagnostic device query equals 100 ms. This pertains to the PWM and VPW protocols. In many vehicles this time is exceeded. The majority of diagnostic scanning devices is resistant to this kind of error. The excess of 100 ms for many controllers, however, is too large and generates errors in communication. Some of the controllers have been designed so that when the first controller sends a response the 100 ms counter is reset and the time is counted again for another controller. Thus, the response time is aggregated.
3.5. The improper choice of the scan able data
Prior to the data scan a universal diagnostic device will check what data are available for scan from a given controller. To that end, it sends a special query – PID0. It happens that the controller will erroneously respond to such a query informing that the denied data are available for scan. The access attempt to such data causes momentary delays in data scan and in extreme cases may lead to a communication breakdown.
3.6. The lack of the consequence in addressing
The SAE 2178-1 document assigns addresses to controllers of the particular vehicle components. To exemplify: the engine controller address is defined in the range of 10h– 17h and the vehicle transmission address: 18h–1Fh. The standards merely recommend rather than force the manufacturers to apply the above. Some diagnostic tools, however, use these criteria to identify a particular controller. The consequence of such actions is the lack of possibility to test oxygen sensors if the address of the controller does not match that given in the specimen description of SAE 2178-1. Some of the problems do not arise from the direct errors in the OBDII/EOBD system implementation.
3.7. No voltage in the diagnostic port
The majority of diagnostic devices is powered by the DLC (Data Link Connector). The lack of a voltage in the DLC will result in the lack of communication. Diagnostic devices are usually equipped with a LED whose illumination signifies correct voltage in the DLC. If there is no voltage in the DLC we must check the fuses first. It occurs frequently that Fiat vehicles do not have the fuse and it should be fitted in the pre-sale service inspection. In the case of vehicles with a special ignition button rather than a regular key ignition switch, where a traditional key has been replaced with a microchip card the voltage in the DLC will only occur after the engine start (Renault Megane). After the engine switch-off, the voltage will remain in the DLC for several minutes.
In Volkswagen AG vehicles manufactured until 1998 and fitted with an OBDII/EOBD port, without the implementation of the OBDII/EOBD system itself, it might occur that +12 V occurs in pin 7. The situation is due to an improper radio set fitting. A hookup of a universal diagnostic tool may lead to its serious damage.
It must be noted that the universal scan tools should be resistant to a momentary voltage occurrence in its diagnostic lines. The reality shows that those kinds of tests were not always performed in the homologation procedures. Unfortunately such a damage is not scarce.
3.9. The additional security and DIY in the vehicles
Non-original antitheft systems are a frequent cause of problems with the communication between the vehicle and the scan tool. Depending on the design and level of complexity of such a security device it will distort proper communication immediately after ignition, after a given engine rpm is exceeded, after a defined period of time counting from the ignition or at fulfilling any other given conditions. It is frequently a difficult task to associate the source of a trouble with a simple antitheft device. Hence, all non-original devices must be disconnected. A radio set other than that provided by VW A.G. may result in a total lack of communication. Such a set must be disconnected.
3.10. Calculation of CVN
CVN (Calibration Verification Number) is a parameter needed for the verification of the operating program and the variables controlling the engine components. This parameter is calculated in the background during regular program use or if requested by a scan tool. The calculation of CVN lasts from several seconds to several minutes and can be interrupted. In some vehicles (i.e. Renault Kangoo) sending of a command to read the CVN will initiate the procedure of calculating a requested parameter that cannot be interrupted even if the ignition is switched off. For several minutes the diagnostic system gives the impression of incompatibility with the OBDII/EOBD scan tool.
3.11. Diagnosing at WOT (Wide Open Throttle)
During the engine operation at wide open throttle a communication breakdown between the OBDII/EOBD and the scan tool is possible.
3.12. Diagnosing during the engine operation
Starting the engine will frequently cause noise on the transmission lines and in extreme cases will result in a communication breakdown (some Fiat Punto and Stilo vehicles). German TÜV publishes a list of vehicles for which it is impossible to properly perform a diagnostic test because of the errors in OBDII/EOBD implementation or no access to all
required parameters. The problems pertain to the vehicles manufactured by the concerns of PSA, Renault, Fiat and Volkswagen concerns before December 2002. The reality hints, though, that the basic issue to be solved by the diagnostic engineers is to determine whether the vehicle is fitted with the OBDII/EOBD system. Such an assessment usually consists in checking the vehicle model year and the shape of the diagnostic port but, as it turns out, such information is not sufficient and may be the reason for errors.
In order to have 100% certainty that a vehicle is fitted with the OBDII/EOBD system it must fulfill all of the following conditions:
– model year – we may assume that spark ignition vehicles with homologation tests performed after:
1 January 1996 in the USA,
1 January 2001 in the EU member states,
1 January 2002 in Poland,
are compliant with the OBDII/EOBD system. It does not mean that all vehicles will fall into this category. The manufacturers had two years to adapt their vehicles with the homologation tests performed before the above dates. It may occur that a vehicle manufactured in 2002 in Germany will not be OBDII/EOBD compliant;
The obligation to fit diesel vehicles with the OBDII/EOBD system was introduced only in 2004.
– a second oxygen sensor behind the catalytic converter – a characteristic element
of the OBDII/EOBD compliant diagnostic system is a second oxygen sensor placed behind the catalytic converter (spark-ignition engines). If the vehicle is equipped with such a sensor we may assume with a high level of probability that the vehicle is OBDII/EOBD compliant;
– DLC (Data link Connector) – all vehicles OBDII/EOBD compliant are equipped
with a two row, 16-pin, standardized port. Unfortunately, an identical port was also fitted in older vehicles before the OBDII/EOBD standards were introduced. Hence, the assumption that each vehicle fitted with an OBDII/EOBD port is OBDII/EOBD compliant is erroneous.
Several months ago the knowledge of diagnostic engineers regarding the OBDII/EOBD system was still insufficient. Their knowledge, however, continues to grow thanks to regular trainings and the experience gained in their daily engineering routines. The problems start when a vehicle, which, according to the best of the engineers knowledge, is OBDII/EOBD compliant does not communicate with a type approved scan tool or when the scanned data do not seem reliable. The fault is usually attributed to the scan tool. If the problems recur when diagnosing other vehicles the diagnostic device, in the eyes of a diagnostic engineer, becomes an unreliable tool shouldering the whole responsibility for any faults in this matter. As a matter of fact it turns out that it is the wrong approach of the engineer himself that underlies such an unfavorable situation. The core mistake that the diagnostic engineers make is inappropriate assessment whether the vehicle is OBDII/EOBD compliant. The lack of the communication between the vehicle and the diagnostic scanner may also result from an internal fault of the system or the DIY approach of the driver (a blown fuse, non-original anti-theft systems). The errors in the controller software also prevent trouble free diagnostic, particularly in vehicles manufactured before December 2002. As of now, the problems of diagnostic software errors have been almost entirely eliminated, provided that software updates have been installed. Current works on the diagnostic scan tools are focused on searching for errors in the vehicle controllers and such a modification of own software to enable their elimination.
Quick and trouble free OBDII/EOBD vehicle diagnosis requires systematic training of the relevant personnel in the OBDII/EOBD operation, functions and its typical problems. It is also a prerogative that the diagnostic scan tools have the up-to-date software.
References
1. ISO 15765 – Road Vehicles – Diagnostic Systems – Diagnostics on CAN.
2. ISO 9141 – Road Vehicles – Diagnostic Systems – Requirements for Interchange of
Digital Information.
3. ISO 9141-2 – CARB Requirements for Interchange of Digital Information.
4. ISO/DIS 14230-1 E – Road Vehicles-Diagnostic System-Keyword. Protocol 2000. Part 1: Physical Layer.
5. ISO/DIS 14230-2 E – Road Vehicles-Diagnostic System-Keyword Protocol 2000. Part 2: Data Link Layer.
6. ISO/DIS 14230-3 E – Road Vehicles-Diagnostic System-Keyword. Protocol 2000. Part 3: Application Layer.
7. ISO/DIS 14230-4 E – Road Vehicles-Diagnostic System-Keyword. Protocol 2000. Part 4: Requirements for Emission-related Systems.
8. SAE J1850 – Class B Data Communications Network Interface.
9. Merkisz J., Gis W., Damm A., Ślęzak M.: Wykorzystanie systemów diagnostyki
V Konferencja szkoleniowa: Badania Techniczne Pojazdów w Świetle Obowiązujących Przepisów, s. 105–134, Mikołajki, 20–22 października 2004. 10. Merkisz J., Gis W.: Stan obecny (na rok 2004) i kierunki zmian przepisów
toksyczności spalin z silników spalinowych: V Konferencja szkoleniowa: Badania
Techniczne Pojazdów w Świetle Obowiązujących Przepisów, s. 91–104, Mikołajki 20–22 października 2004.
11. Processing CITA Conference: Global Perspective on Roadworthiness Enforcement, organized by International Motor Vehicle Inspection Committee, Chicago 24– 28.05.2005.
