On-board diagnostics
From Wikipedia, the free encyclopedia
| This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (June 2009) |
On-Board Diagnostics, or OBD, in an automotive context, is a generic term referring to a vehicle's self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since the introduction in the early 1980s of on-board vehicle computers, which made OBD possible. Early instances of OBD would simply illuminate a malfunction indicator light, or MIL, if a problem was detected—but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized fast digital communications port to provide realtime data in addition to a standardized series of diagnostic trouble codes, or DTCs, which allow one to rapidly identify and remedy malfunctions within the vehicle.
Contents |
[edit] History
- 1975: Datsun 280Z On-board computers begin appearing on consumer vehicles, largely motivated by their need for real-time tuning of fuel injection systems. Simple OBD implementations appear, though there is no standardization in what is monitored or how it is reported.
- 1980: General Motors implements a proprietary interface and protocol. The initial ALDL protocol communicates at 160 baud with Pulse-width modulation (PWM) signaling and monitors very few vehicle systems. Implemented on California vehicles for the 1980 model year, and the rest of the United States in 1981. Cadillac (gasoline) fuel-injected vehicles, however, are equipped with actual on-board diagnostics, providing trouble codes, actuator tests and sensor data through the new digital Electronic Climate Control display. Holding down Off and Warmer for several seconds activates the diagnostic mode without need for an external scan-tool.
- 1986: An upgraded version of the ALDL protocol appears which communicates at 8192 baud with half-duplex UART signaling. This protocol is defined in GM XDE-5024B.
- ~1987: The California Air Resources Board (CARB) requires that all new vehicles sold in California starting in manufacturer's year 1988 (MY1988) have some basic OBD capability. The requirements they specify are generally referred to as the "OBD-I" standard, though this name is not applied until the introduction of OBD-II. The data link connector and its position are not standardized, nor is the data protocol.
- 1988: The Society of Automotive Engineers (SAE) recommends a standardized diagnostic connector and set of diagnostic test signals.
- ~1994: Motivated by a desire for a state-wide emissions testing program, the CARB issues the OBD-II specification and mandates that it be adopted for all cars sold in California starting in model year 1996 (see CCR Title 13 Section 1968.1 and 40 CFR Part 86 Section 86.094). The DTCs and connector suggested by the SAE are incorporated into this specification.
- 1996: The OBD-II specification is made mandatory for all cars sold in the United States.
- 2001: The European Union makes EOBD mandatory for all petrol vehicles sold in the European Union, starting in MY2001 (see European emission standards Directive 98/69/EC [2] ).
- 2008: All cars sold in the United States are required to use the ISO 15765-4 [3] signaling standard (a variant of the Controller Area Network (CAN) bus).
[edit] Standard interfaces
[edit] OBD-I
The regulatory intent of OBD-I was to encourage auto manufacturers to design reliable emission control systems that remain effective for the vehicle's "useful life".[citation needed] The hope was that by forcing annual emissions testing for California[citation needed] , and denying registration to vehicles that did not pass, drivers would tend to purchase vehicles that would more reliably pass the test. Along these lines, OBD-I was largely unsuccessful[citation needed] —the means of reporting emissions-specific diagnostic information was not standardized. Technical difficulties with obtaining standardized and reliable emissions information from all vehicles led to an inability to implement effectively the annual testing program.[citation needed]
[edit] OBD 1.5
OBD 1.5 refers to a partial implementation of OBD-II which General Motors used on some vehicles in 1994 and 1995 (GM did not use the term OBD 1.5 in the documentation for these vehicles - they simply have an OBD and an OBD-II section in the service manual.)
For example, the 94-95 Corvettes have one post-catalyst oxygen sensor (although they have two catalytic converters), and have a subset of the OBD-II codes implemented. For a 1994 Corvette the implemented OBD-II codes are P0116-P0118, P0131-P0135, P0151-P0155, P0158, P0160-P0161, P0171-P0175, P0420, P1114-P1115, P1133, P1153 and P1158.[1]
This hybrid system was present on the GM H-body cars in 94-95, W-body cars (Buick Regal, Chevrolet Lumina ('95 only), Chevrolet Monte Carlo ('95 only), Pontiac Grand Prix, Oldsmobile Cutlass Supreme) in 94-95, L-body (Chevrolet Beretta/Corsica) in 94-95, Y-body (Chevrolet Corvette) in 94-95, on the F-body (Chevrolet Camaro and Pontiac Firebird) in 95 and on the J-Body (Chevrolet Cavalier and Pontiac Sunfire) and N-Body (Buick Skylark, Oldsmobile Achieva, Pontiac Grand Am) in 95.
The pinout for the ALDL connection on these cars is as follows:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
For ALDL connections, pin 9 is the data stream, pins 4 and 5 are ground and pin 16 is battery voltage.
Additional vehicle-specific diagnostic and control circuits are also available on this connector. For instance, on the Corvette there are interfaces for the Class 2 serial data stream from the PCM, the CCM diagnostic terminal, the radio data stream, the airbag system, the selective ride control system, the low tire pressure warning system and the passive keyless entry system.[2]
An OBD1.5 has also been used on Mitsubishi cars of '95 '97 vintage,[citation needed] some[which?] 1995 Volkswagen VR6's (Juice Box's GTI),[citation needed] and in the Ford Scorpio since 95.[3]
[edit] OBD-II
OBD-II is an improvement over OBD-I in both capability and standardization. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signalling protocols available, and the messaging format. It also provides a candidate list of vehicle parameters to monitor along with how to encode the data for each. Finally, the OBD-II standard provides an extensible list of DTCs. As a result of this standardization, a single device can query the on-board computer(s) in any vehicle. This OBD-II came in 2 models OBD-IIA and OBD-IIB.
[edit] OBD-II Diagnostic connector
The OBD-II specification provides for a standardized hardware interface—the female 16-pin (2x8) J1962 connector. Unlike the OBD-I connector, which was sometimes found under the hood of the vehicle, the OBD-II connector is nearly always located on the driver's side of the passenger compartment near the center console. SAE J1962 defines the pinout of the connector as:
- -
- Bus positive Line of SAE-J1850 PWM and SAE-1850 VPW
- Ford DCL(+) Argentina, Brazil (pre OBD-II) 1997-2000, Usa, Europe, etc.
- Chassis ground
- Signal ground
- CAN high (ISO 15765-4 and SAE-J2284)
- K line of ISO 9141-2 and ISO 14230-4
- -
- -
- Bus negative Line of SAE-J1850 PWM only (not SAE-1850 VPW)
- Ford DCL(-) Argentina, Brazil (pre OBD-II) 1997-2000, Usa, Europe, etc.
- -
- -
- CAN low (ISO 15765-4 and SAE-J2284)
- L line of ISO 9141-2 and ISO 14230-4
- Battery voltage
The assignment of unspecified pins is left to the vehicle manufacturer's discretion.
[edit] Signal protocols
There are five signalling protocols currently in use with the OBD-II interface. Any given vehicle will likely only implement one of the protocols. Often it is possible to make an educated guess about the protocol in use based on which pins are present on the J1962 connector:
- SAE J1850 PWM (pulse-width modulation - 41.6 kbaud, standard of the Ford Motor Company)
- pin 2: Bus+
- pin 10: Bus–
- High voltage is +5 V
- Message length is restricted to 12 bytes, including CRC
- Employs a multi-master arbitration scheme called 'Carrier Sense Multiple Access with Non-Destructive Arbitration' (CSMA/NDA)
- SAE J1850 VPW (variable pulse width - 10.4/41.6 kbaud, standard of General Motors)
- pin 2: Bus+
- Bus idles low
- High voltage is +7 V
- Decision point is +3.5 V
- Message length is restricted to 12 bytes, including CRC
- Employs CSMA/NDA
- ISO 9141-2. This protocol has a data rate of 10.4 kbaud, and is similar to RS-232. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.
- pin 7: K-line
- pin 15: L-line (optional)
- UART signaling (though not RS-232 voltage levels)
- K-line idles high
- High voltage is Vbatt
- Message length is restricted to 12 bytes, including CRC
- ISO 14230 KWP2000 (Keyword Protocol 2000)
- pin 7: K-line
- pin 15: L-line (optional)
- Physical layer identical to ISO 9141-2
- Data rate 1.2 to 10.4 kbaud
- Message may contain up to 255 bytes in the data field
- ISO 15765 CAN (250 kbit/s or 500 kbit/s). The CAN protocol is a popular standard outside of the US automotive industry and is making significant in-roads into the OBD-II market share. By 2008, all vehicles sold in the US will be required to implement CAN, thus eliminating the ambiguity of the existing five signalling protocols.
- pin 6: CAN High
- pin 14: CAN Low
Note that pins 4 (battery ground) and 16 (battery positive) are present in all configurations. Also, ISO 9141 and ISO 14230 use the same pinout, thus the connector shape does not distinguish between the two.
[edit] Diagnostic data available
OBD-II provides access to numerous data from the ECU (Electronic Control Unit) and offers a valuable source of information when troubleshooting problems inside a vehicle. The SAE J1979 standard defines a method for requesting various diagnostic data and a list of standard parameters that might be available from the ECU. The various parameters that are available are addressed by "parameter identification numbers" or PIDs which are defined in J1979. For a list of basic PIDs, their definitions, and the formulae to convert raw OBD-II output to meaningful diagnostic units, see OBD-II PIDs. Manufacturers are not required to implement all PIDs listed in J1979 and they are allowed to include proprietary PIDs that are not listed. The PID request and data retrieval system gives access to real time performance data as well as flagged DTCs. For a list of generic OBD-II DTCs suggested by the SAE, see Table of OBD-II Codes. Individual manufacturers often enhance the OBD-II code set with additional proprietary DTCs.
[edit] Emission testing
In the United States, many states now use OBD-II testing instead of tailpipe testing in OBD-II compliant vehicles (1996 and newer). Since OBD-II stores trouble codes for emissions equipment, the testing computer can query the vehicle's onboard computer and verify there are no emission related trouble codes and that the vehicle is in compliance with emission standards for the model year it was made.[4]
[edit] EOBD
EOBD is a version of OBD-II required in Europe since Model Year 2003 for diesel vehicles and since 2001 for gasoline vehicles[5]. With Euro V and Euro VI emission standards, EOBD emission thresholds will be lower than previous Euro III and IV.
[edit] EOBD2
The term "EOBD2" is a marketing term used by some vehicle manufacturers to refer to manufacturer-specific features that are not actually part of the OBD or EOBD standard.[5] In this case "E" stands for Enhanced.
[edit] Scan tools
OBD scan tools can be categorized in several ways ranging from whether they are OEM tools or aftermarket tools, whether they require a computer to operate (stand-alone tool vs PC-based software), and the intended market (professional or hobby/consumer use).
The advantages of PC-based scan tools are:
- Low cost (compared to stand-alone scan tools with similar functionality -if you don't count the cost of a laptop PC).
- Virtually unlimited storage capacity for data logging and other functions.
- Higher resolution screen than handheld tools.
- Availability of multiple software programs.
- Some are capable of reprogramming
The advantages of stand-alone tools:
- Wide selection beginning with simple code read/erase tools starting at as low as $79 retail.
- Simplified operation that requires no computer skills/ PC compatibility issues.
- Rugged designs, intended for use in and around cars (i.e. no lugging a laptop in and around a car).
[edit] Mode of Operation
Here is a basic introduction to the OBD communication protocol according to ISO 15031:
Mode $01 is used to identify what Powertrain information is available to the scan tool.
Mode $02 displays Freeze Frame data.
Mode $03 lists the emission-related "confirmed" diagnostic trouble codes stored. It displays exact numeric, 5 digit codes identifying the faults.
Mode $04 is used to clear emission-related diagnostic information. This includes clearing the stored pending/confirmed DTCs and Freeze Frame data.
Mode $05 displays the oxygen sensor monitor screen and the test results gathered about the oxygen sensor.
There are ten numbers available for diagnostics:
- $01 Rich-to-Lean O2 sensor threshold voltage
- $02 Lean-to-Rich O2 sensor threshold voltage
- $03 Low sensor voltage threshold for switch time measurement
- $04 High sensor voltage threshold for switch time measurement
- $05 Rich-to-Lean switch time in ms
- $06 Lean-to Rich switch time in ms
- $07 Minimum voltage for test
- $08 Maximum voltage for test
- $09 Time between voltage transitions in ms
Mode $06 is a Request for On-Board Monitoring Test Results for Continuously and Non-Continuously Monitored System. There are typically a minimum value, a maximum value, and a current value for each non-continuous monitor.
Mode $07 is a Request for emission-related diagnostic trouble codes detected during current or last completed driving cycle. It enables the external test equipment to obtain "pending" diagnostic trouble codes detected during current or last completed driving cycle for emission-related components/systems. This is used by service technicians after a vehicle repair, and after clearing diagnostic information to see test results after a single driving cycle to determine if the repair has fixed the problem.
Mode $08 could enable the off-board test device to control the operation of an on-board system, test, or component.
Mode $09 is used to retrieve vehicle information. Among others, the following information is available:
-VIN (Vehicle Identification Number): Vehicle ID
-CALID (Calibration Identification): ID for the software installed on the ECU
-CVN (Calibration Verification Number): Number used to verify the integrity of the vehicle software. The manufacturer is responsible for determining the method of calculating CVN(s), e.g. using checksum.
Mode $0A is required to store Permanent DTCs as per CARB.
[edit] Software Required
Many of the scan tools require a "host" computer, such as a laptop computer. Some come with proprietary software for Microsoft Windows like the software available with the Durametrics product[6]. Two open source programs are available: Opendiag[7] and Freediag[8].
[edit] Standards documents
[edit] SAE standards documents on OBD-II
- J1962 - Defines the physical connector used for the OBD-II interface.
- J1850 - Defines a serial data protocol. There are 2 variants- 10.4 kbit/s (single wire, VPW) and 41.6 kbit/s (2 wire, PWM). Mainly used by US manufacturers, also known as PCI (Chrysler, 10.4K), Class 2 (GM, 10.4K), and SCP (Ford, 41.6K)
- J1978 - Defines minimal operating standards for OBD-II scan tools
- J1979 - Defines standards for diagnostic test modes
- J2012 - Defines standards trouble codes and definitions.
- J2178-1 - Defines standards for network message header formats and physical address assignments
- J2178-2 - Gives data parameter definitions
- J2178-3 - Defines standards for network message frame IDs for single byte headers
- J2178-4 - Defines standards for network messages with three byte headers*
- J2284-3 - Defines 500K CAN Physical and Data Link Layer
[edit] ISO standards
- ISO 9141: Road vehicles — Diagnostic systems. International Organization for Standardization, 1989.
- Part 1: Requirements for interchange of digital information
- Part 2: CARB requirements for interchange of digital information
- Part 3: Verification of the communication between vehicle and OBD II scan tool
- ISO 11898: Road vehicles — Controller area network (CAN). International Organization for Standardization, 2003.
- Part 1: Data link layer and physical signalling
- Part 2: High-speed medium access unit
- Part 3: Low-speed, fault-tolerant, medium-dependent interface
- Part 4: Time-triggered communication
- ISO 14230: Road vehicles — Diagnostic systems — Keyword Protocol 2000, International Organization for Standardization, 1999.
- Part 1: Physical layer
- Part 2: Data link layer
- Part 3: Application layer
- Part 4: Requirements for emission-related systems
- ISO 15765: Road vehicles — Diagnostics on Controller Area Networks (CAN). International Organization for Standardization, 2004.
- Part 1: General information
- Part 2: Network layer services
- Part 3: Implementation of unified diagnostic services (UDS on CAN)
- Part 4: Requirements for emissions-related systems
[edit] Vehicle Communication Command modes 1 - 9, for OBD-II
Currently OBD-II defines 9 modes of operation, all 9 are supported by the APEX with specialized software to minimize communication overhead.
OBD-II Mode 1 Request data by PID Send 01XX(CR) CR=Carriage Return, ASCII code 13 XX= PID byte Receive Returns single message string – example V486B10410536CA(CR
OBD-II Mode 2 Request Freeze Frame Data Send 02-PID-Frame-CR Frame is always 00 Receive single message string – example send 020000 – PID=00, show all supported Mode2 PIDs Rec. - V416B104200007F980000(CR)
OBD-II Mode 3 Request Trouble Codes Send 03(CR) Receive Single or multiple messages, refer to SAE-J1979 for complete specifications V0A416B104304010000000099 – indicates trouble code P0401
OBD-II Mode 4 Clear Codes and reset Malfunction Lamp Send 04(CR) Receive V486B10444436(CR) if successful, anything else means unsuccessful
OBD-II Mode 5 Legacy O2 Sensor Test Results Send 05 TID O2sensor CR -050001(CR) Receive Returns single message string – example: Send 050001(CR) Rec-V0B486B0E4500010000000108 (CR) If TID or O2 not supported then response will be V(CR) Refer toSAE-J1979 for full information
OBD-II Mode 6 Send For non-CAN systems send:06 TID – CR, TID=Test ID, usually defined by the vehicle manufacturer. For CAN vehicles send 06-#of TID’s-TID1-TID2….TID6 You should zero fill unused PIDs. Receive Returns single or multiple message string – example: Send-0600, Receive -V0B486B0E4600FF0001818109 (CR) – From ISO9141 Honda If TID not supported then response will be V(CR)~
For CAN, to get the results of TID 01, O2 Sensor Monitor Bank 1-Sensor 1, send 060101(CR), the vehicle replies: V101C4601010A0E68210000FFFF01800A2217401002FFFF 0123810E01CF00E60B24B8000000000000 Please see ISO-15031-5 for the description of the 28 byte reply.
OBD-II Mode 7 Pending Codes Send 07(CR) Receive Single or multiple messages, refer to SAE-J1979 for complete specifications.
OBD-II Mode 8 Control the operation of an on-board system, test or component. Send 08 TID DataA-DataB-DataC-DataD-DataE Receive V486B1048-TID-D0-D1-D2-D3-D4(CR) Example: Send 08010000000000(CR) Rec. V0A416B104801000000000085 A response of ‘VERR’ means the data buffer to transmit did not contain sufficient characters to form a message.
OBD-II Mode 9 Read VIN, Calibration Numbers. For NON-CAN OBD the VIN is 17 characters for vehicles that provide electronic access to the VIN. VIN characters shall be reported as ASCII values. The response consists of the following messages: Message #l shall contain three filling bytes of $00, followed by VIN character #l Message #2 shall contain VIN characters #2 to #5 inclusive Message #3 shall contain VIN characters #6 to #9 inclusive Message #4 shall contain VIN characters #lO to #13 inclusive Message #5 shall contain VIN characters #14 to #17 inclusive
Send 09-01-PID-(CR) Receive Send 090102(CR) to get VIN. Multiple messages, CAN Bus example : - response to 090102 for CAN communications V101449020131465421505731343532352246423235323338.
Legacy OBD Example: Send 0902(CR) Receive: V0A416B1049020539000000A30A416B1049020434363938DE0A416B1 049020333594E42AE0A416B1049020258313757F90A416B1049020131 46545278
In all cases, if the vehicle did not respond to an OBD request, only a ‘V’ followed by a (CR) will be sent. One more thing about the OBD-II communication. When a Mode 01, PID 00 command is issued, every OBD-II PCM in the vehicle will respond. Usually there is only one PCM, but some cars will have two, an engine controller and a transmission controller. This can lead to extra work in sorting out responses from multiple ECU’s when acquiring data. The APEX default settings will only receive bus messages from the lowest number ECU ( the Engine Controller) responding to a 00-01 command. This keeps the clutter out and simplifies user software.
APEX V1.0 Vehicle Data Bus Interface Providing all OBD-II and EOBD protocols, including CAN, and a very software friendly interface, the APEX chip is ideal for scan tools, code readers, telematics and Car Computers. The APEX is based on a high speed Digital Signal Processor (DSP), which means it’s fast enough to handle all vehicle messaging applications and it has large internal data buffers for storing multiple message responses from all protocols. The APEX allows the ISO-9141 and ISO-14230 interfaces to be customized for different bit rates, message timing and 1,2 or 3 byte message headers. The serial data interface is set to 115,200 baud as default, but can go to 625,000 baud via user commands. There are two high speed, 10bit, analog inputs which can be used for battery voltage monitor, external Wide Band O2 sensor interface, Accelerometer input for a useful Dyno/Performance analyzer, etc. It’s possible to get analog data rates of 1000 samples/sec at 115,200 baud, which makes a low speed oscilloscope possible too. All OBD-II modes, 1 through 9, are handled by onboard firmware which automatically takes care of message formatting, CRC or checksum, bus initialization and error detection. This makes the software for creating a scan tool very simple and straight forward. All responses from the APEX are terminated with CR-LF codes so the users application software only has to wait for a “read line complete” event to get any response. The APEX uses the standard RS232 type serial communication. The default data rate is 38400, 115,200 or 428000 baud with 8 data bits, no parity bit, and 1 stop bit. All responses from the APEX IC are terminated with an acknowledgement.
[edit] References
- ^ 1994 Corvette Service Manual, Book 2. General Motors Corporation. December 1993. pp. 6E3–A-166 : 6E3–A-223.
- ^ 1994 Corvette Service Manual, Book 2. General Motors Corporation. Dec., 1993. pp. 6E3–A-11.
- ^ [1]
- ^ http://www.epa.state.oh.us/dapc/echeck/testing_info/obd_faq.html
- ^ a b KBM Systems - OBD Specifications :: OBD Introduction
- ^ Sensolutions home page
- ^ Opendiag home page
- ^ Freediag sourceforge page
- Birnbaum, Ralph and Truglia, Jerry. Getting to Know OBD II. New York, 2000. ISBN 0-9706711-0-5.
- SAE International. On-Board Diagnostics for Light and Medium Duty Vehicles Standards Manual. Pennsylvania, 2003. ISBN 0-7680-1145-0.
[edit] See also
- OBD-II PIDs ("Parameter IDs")
- OBD-II Diagnostic Codes
[edit] External links
| This article's external links may not follow Wikipedia's content policies or guidelines. Please improve this article by removing excessive or inappropriate external links. |
- CAN Bus make, mode and year vehicles supporting OBD II CAN bus.
- OBD II Connector Pinout pin numbers and connections on the OBD II connector.
- National OBD Clearing House Center for Automotive Science and Technology at Weber State University
- United States Environmental Protection Agency OBD information for repair technicians, vehicle owners, and manufacturers
- OBD-II Trouble Code Articles OBD-II trouble code technical articles for vehicle owners
- Obd2 Weblog Official blog about the obd2 standard and news.
- List of Open Source OBD software
- List of proprietary OBD software
- List of vendors of OBD cables and plugs
- Proyecto Ford DCL
- Ford DCL Enthusiast
- Obddiag.net Freeware OBD adapter supporting all protocols
- DiagnostiCar Scanner to Ford EEC IV DCL

