Background of OBD On Board Diagnostic

 
On Board Diagnostic (OBD, it is also called Enhanced OBD in European) is installed in many vehicles for on board self-diagnostic and reporting purpose. OBD systems give the owner or a technician access to the state of health information for various vehicles. Modern OBD implementations use digital communication ports to provide real-time data in addition to standard diagnostic codes, which allow one to rapidly identify malfunctions within the vehicle. OBD-II scanner is also a common debug and programming tool for the component suppliers in the automobile industry.

Two important organizations are involved in OBD specifications. One is Society of automobile Engineers (SAE), the other is International Organization for Standards (ISO). SAE serves American auto manufacturers for years. With its help, OBD comes to a standard. After a brief research, although both SAE and ISO define OBD standards and specifications, there is not one to one transformation between them. If you are working for an automobile manufacturer, you can just follow one specification for specific model. In contrast, an OBD-II scanner developer has to read all related documents to support them as many as possible.

According to the specifications, OBD-II leaves some custom contacts for manufactures. As a result, the OBD becomes a mess because the automobile manufactures define their own specifications due to historical and business reasons. Auto market is different from PC market. The used cars are still an important portion of whole market. You can implement an ODB-II tool with necessary features, but you can not expect to support all of the car models. There are too many combinations.

In general, people have to purchase the specifications from SAE/ISO if they are not members. As I know, SAE offers a complete CD-ROM contains all necessary specifications and supplementary information for 250+ USD. ISO can offer equivalent service as well. I tried to locate the specifications from these two sites, but I found their search didn't work well. Finally, I found a powerful way to search their web. Try this in Google:

"J1850 site:sae.org"

This method allows you to find out the corresponding specification by external search engine. (P.S. , you can try it with Bing as well.)

Before OBD-II becomes the industrial standard, various car manufactures defined the protocols for the in-vehicle multiplex networks. As a result, the OBD-II scanner has to be compatible with the following protocols.

Standard Protocols:

• SAE J1850 PWM (Class B Data Communications Network Interface, Pulse Width Modulation, Ford SCP compliant)
• SAE J1850 VPW (Variable Pulse Width Modulation, GM class 2 compliant plus light trucks)
• ISO 9141-2 (Road vehicles: Diagnostics requirements) K-Line (Chrysler + European brands + Asian Brands)
• ISO 14230-4 KWP2000 (Road vehicles: Diagnostics Key Word Protocol 2000, replacement of ISO9141)
• SAE J2284 (High-speed CAN for Vehicle Applications at 500KBPS) / ISO 15765-1/2/3/4 (Road vehicles: Diagnostics on CAN)

Optional Protocols:

• SAE J2602 (LIN Network for Vehicle Applications)
• UBP (UART Based Protocol by Ford)
• CCD (Chrysler proprietary protocol)
• ALDL (Assembly Line Diagnostic Link)
• SAE J1939 (The Real-Time CAN Solution for Heavy Duty Applications)
• KWP1281 (Keyword Protocol 1281, Legacy, but quite popular in Volkswagen made in China)

Related Standards:

• ISO15031 (Road vehicles -- Communication between vehicle and external equipment for emissions-related diagnostics)
• ISO11898 (Road vehicles -- Controller area network (CAN))
• SAE J1979 (E/E.Diagnostic Test Modes)
• SAE J2190 (Enhanced E/E.Diagnostic Test Modes)
• SAE J2012 (Diagnostic Trouble Code Definitions)
• SAE J2178 (Class B Data Communication Network Messages)
• SAE J1962 (Diagnostic Connector)
• SAE J1978 (OBD II Scan Tool)

Freescale Silicon 

ISO has defined its famous OSI 7 layer model:

• User Application Layer
• Network Management Layer
• Transport Layer
• Data Link Layer
• Hardware Abstraction Layer
• Physical Layer

Most of the in-vehicle buses follow the OSI concepts, but usually they have not complete 7 layers. Instead, most of the buses have Physical layer and Data Link Layer. These buses may share common transport layer so the higher user application layer can abstract lower layers. If we are going to design an "all-in-one" OBD scanner, we can approximately divide the system into three parts, physical interface, protocol controller and application software. The physical interface handles data decoding/encoding, circuit protection and hardware related issues. The protocol controller processes the data frame, bus arbitration, address decode and so on. The application software actually contains all higher protocol stack, including communication management and presentation. Maybe such description is not good enough. Please contribute your idea to define it more clearly. 

Let us summarize the technical requirements for OBD/E-OBD protocols:

• SAE J1850: Physical Interface (both PWM and VPW), BDLC-D (Byte Data Link Controller) for J1850, device driver and message parser
• ISO9141-2/ISO14230-4 K-Line KWP1281/KWP2000: Physical Interface, UART driver and message parser
• SAE J2284/ ISO15765 CAN bus: Single-wire and Dual-wire CAN bus interface, CAN controller, device driver and message parser
• SAE J2602 LIN bus: optional, UART driver and message parser.

Freescale has served automobile market for many years, so it can offers complete semiconductor profolio for this market. It has unique competency with its broad SBC (System Basis Chip) product line, which contains bus transceiver, analog features, and dedicated for automobile applications with reference designs. Here are some candidate products from Freescale available for OBD-II tool. Freescale has a good web search, you

• MC9S12DJ128 16-bit microcontroller with SAE J1850 BDLC and CAN controller
• MPC5121e PowerPC MobileGT SoC
• MC33390 SAE J1850 Serial Transceiver
• MC33910/11/12 SAE J2602 LIN System Basis Chip
• MC33661 LIN Enhanced Physical Interface
• MC33689 System Base Chip with LIN
• MC33897 SAE J2284 Single Wire CAN Interface
• MC33989 System Basis Chip with High speed CAN transceiver
• MC33742 System Basis Chip with High speed CAN transceiver
• MM908E62X Embedded MCU and LIN
• much more ...

The OBD controller usually connects to external physical interfaces for different networks (J1850/CAN/LIN/ISO KWP respectively). Then the rest of the stacks are implemented in a general purpose microcontroller with necessary features such as CAN controller. You can visit the ELM electronics web site listed in the references. ELM offers ELM32X OBD controllers for most popular networks, and its ELM327 is its all-in-one OBD controller to support all networks. In fact, its OBD controllers are just pre-programmed Microchip microcontrollers (8PIN/14PIN/28PIN).

An all-in-one OBD scanner microcontroller should have following features:

• UART/SCI: UART/SCI/USART, it is widely used in ISO9141(KWP1281)/ISO14230(KWP2000)/J2602(LIN)/UBP/CCD.
• Timer: it may be used to decode VPW for software decoding.
• CAN: It is a necessary feature if ISO15765/SAE J2284 is involved.
• USB device: it is the communication to host PC. The RF link such as Bluetooth connection can be setup with either USB host or UART.
• BDLC-D: Byte Data Link Controller for SAE J1850. Up to now, I found only Freescale offers hardwired BDLC-D facility in its 8/16/32-bit microcontrollers. I think it can be implemented in software. Please correct me if I am wrong.

Freescale offers 68HCXX, MC9S12XX and MPC52XX (MPC5121e) with BDLC-D circuit. The MPC5121e from its MobileGT family has equipped with all of the mentioned connectivity features. It is quite expensive for a low cost OBD scanner. MC9S12DJ128 has both BDLC and CAN controller, as well as other necessary resources. It is good enough for an OBD scanner. We can add external USB interface to this microcontroller for PC communication. I would like to recommend ColdFire like MCF52259 for OBD-II Scanner application. With USB or Ethernet connection, the diagnostics can be shared over Internet. However it has no BDLC-D controller inside. You can implement it in software, which may require extra resource. Alternatively you can interface ColdFire to external microcontroller with BDLC, such as MC68HC908AS32A. Finally, if J1850 VPW is not on your list. You can ignore it.

Of course, if you only support UART based OBD protocol. There is a simple OBD interface, which only requires an opto-coupler for electric isolation. The software running on PC can read the data via this simple interface. Please Jeff Noxon’s web for VAG interface.

References

Freescale LIN, ISO9141, J1850 Physical Interfaces
Freescale CAN Physical Interfaces
ISO – International Organization for Standardization
SAE – Society of automobile Engineers
Rose Tech LLC, An American company, offers diagnostic software for European automobiles, including VAG-COM.
Ozen Eletronik offers mOByDiC OBD/EOBD Scanner and related products
OBD-2 diagnostics program with low cost scanner: 
Overview for OBD PID (Parameter Identifier) designator
A collection for the Trouble codes for many brands
ELM electronics, offers OBD all-in-one chip
Gerd Müller’s OBD-2 site
Jeff Noxon’s VAG interface, simple OBD interface
Elektor's OBD Forum

CONTACT REQUEST
If you want to know more about this Freescale product, please submit your request to Arrow Italy using this form.

NOTE: this form is valid ONLY for Companies or Customers based in Italy and working in the Italian area.