OBD I and OBD II Are Not Star Wars Characters

Can you just hook a computer up to it?

Back in the late 70’s and early 80’s, someone thought it would be a good idea to start putting computers on cars to control all of the various vehicle systems. This started out very gradually at first with just the control of engine operation being handed over to a mysterious little box with a bunch of wires hanging out. Cars today not only have multiple computers but all of the computers are link together on a network.

Computer controls have been very good for the automobile because they have made all of the various systems much more efficient, and they have allowed many more important features to be added to the average car. Some people complain that all of the complex computer control systems aren’t necessary and that the old systems are better because they are simpler. Well if simplicity is the primary goal then the old systems are better. Considering that computer controls help vehicles have more power and get better gas mileage, it may be worth it to sacrifice simplicity.

A typical engine control computer. Notice the two big connectors with hundreds of wires.

Despite that fact that computer controls do add a certain level of complexity, there is another thing that is possible when something like engine operation is controlled by a computer. That thing is called on-board diagnostics (OBD). If the computer has the capability of receiving inputs, processing those inputs, and then controlling outputs, it can easily have the capability of verifying each one of its functions, and the functions of the things that it controls.

Early systems were not very smart and therefore had very little in terms of OBD. The first fuel injection systems had no OBD, but as these systems have gotten more complex, they have also been able to do more and more to monitor themselves, and make this monitoring information available to technicians.

The first thing that was available from OBD systems was the diagnostic trouble code (DTC). When the computer finds a problem somewhere in its systems it will set a DTC in its memory and turn on a malfunction indicator lamp in the instrument cluster. This is the “check engine light” that everyone is familiar with when a problem is found in the powertrain controls. If the problem is with the Anti-lock braking system then the ABS light comes on, and so on with all of the computer controlled systems. The driver of the vehicle will see that there is a problem and they will take the car in for repairs. Or they might just put a piece of black tape over the light so it won’t bother them while they are driving.

The technician will have to extract the trouble code from the vehicle’s computer to see where or what the problem might be. Sometimes this will mean that a special computerized tool will be hooked up to the car and the code will be extracted via the data link connector (DLC). Most of the early vehicles with OBD also provided a way to read the codes without the scan tool. This usually meant that a couple of terminals in the datalink connector could be jumpered with a wire, or some similar procedure could be performed to read the codes. In this instance the MIL will flash in sequence revealing what the DTC is. Every manufacturer had a different procedure for reading these “flash codes,” and the DLC design and location was always unique as well.

The next thing that OBD made available to help diagnose a failure in a computer controlled system was serial data. This is the data that reflects the inputs to the computer, and control of outputs by the computer. So most info going into the computer, being processed in the computer, or being controlled by the computer, can be seen in the serial data stream. This data must be accessed with a scan tool and cannot be accessed any other way. Some high-end cars provided a way for the technician to access all kinds of information, including DTCs, and serial data, via the climate control system display, or some other control system on the dash. This is pretty rare, but every car has data available via the scan tool.

Serial data can be used to see if the computer is getting a false reading from something like the coolant temperature sensor, or the mass airflow sensor. The serial data will also show what the computer is doing to control the air/fuel ratio. Fuel injector on time can be observed along with weather or not the exhaust gases indicate a lean or a rich condition. With a fair amount of practice this data can be easily interpreted by the technician to help them pinpoint a problem.

Because of differences in communication protocols, every auto manufacturer required a different scan tool back in the day, in order to see serial data as well as read trouble codes. The location and shape of the DLC was also different from one car to another. This meant that if you had a Ford and the shop you took your car to when the MIL illuminated, didn’t have a scan tool that could talk to Fords, they might not be able to work on your car. Every manufacturer also used there own trouble codes so that a code 15 on a Dodge meant something totally different then a code 15 on a Honda. Along with different numbers, some of the terminology used to describe trouble codes and bits of hardware were completely proprietary adding more confusion to the diagnostic process.

Not long after computer controls hit the market, a solution was reached that could help most auto shops take advantage of the OBD of most cars. Aftermarket tool companies developed scan tools that could communicate with most if not all, of the major auto manufacturer’s products. These new scan tools came with a connector for almost every DLC, and the ability to communicate with most vehicle control computers. These generic scan tools worked very well for the most common cars but some of the more obscure makes were impossible for technicians to work on unless they worked at the dealership where the car was sold, and had access to tools and information from that specific manufacturer.

The primary failures that cause the check engine light to illuminate are failures that cause emissions levels from the vehicle to increase beyond a certain level. With the difficulty that technicians had in not being able to diagnose any car that came into the shop the result was some cars were left unrepaired which meant that they were putting more pollution into the air. Because of this the U.S. Congress and the Environmental Protection Agency decided to get involved. Through modifications to the Clean Air Act, new standards were developed that would mandate some standardization in the OBD systems used by every manufacturer selling cars in the U.S.

A basic OBDII scan tool.

This new standard is known as OBDII. The first year that this new system was mandatory was the 1996 model year. All cars have to have the same DLC, and they all have to put the DLC under the dash on the driver’s side. Every car company has to use a similar communication protocol so that a generic scan tool can be used to read DLC’s from any vehicle on the road. So now if you have an OBDII scan tool you can read codes on a Buick just as easily as you can read codes on a Rolls Royce.

Under OBDII each vehicle also has to have the ability to run the same monitors on the same systems for each make and model. These monitors will be run by the computer when certain enable criteria are met. These criteria are operational conditions that occur during normal vehicle operation. A system monitor will run in a way that the driver will not be able to detect, and some monitors are running continuously anytime the vehicle is in operation. Some of these monitors are so smart and so sensitive that they can even tell if your gas cap was left loose or missing altogether. The computer looks for this condition because a loose gas cap releases pure unburned hydrocarbons directly into the atmosphere to react with sunlight and create smog. The serial data that can be read with the scan tool also has to be very similar when being read with a generic scan tool in the OBDII mode.

The OBDII DLC under the dash on the driver's side. This
is where the scan tool gets plugged in.

All of the basic trouble codes are also standardized using an alphanumeric structure. The code P0302 is an example of a common OBDII code. The letter and every number mean something and the meaning is the same on every car. Some codes can still be specific to the manufacturer but the structure of the code must follow the same guidelines which allow the technician to quickly tell if it is a generic code or a manufacturer specific code. All basic terminology used to describe systems and parts of systems related to parts, codes, and failures also follow specific OBDII guidelines.

A very fancy and expensive manufacturer
specific scan tool.

Since 1996 OBDII has evolved somewhat to further standardize various features of the onboard diagnostic system. All of these things have made it easier for technicians to diagnose any car, and for aftermarket equipment manufacturers to build useful and effective tools to aid in the diagnostic process. While a good generic scan tool can communicate with any car on the road built since 96, the manufacturer specific scan tools are still the best, and still provide the most functionality.

Despite the fact that computer controlled cars have the amazing capability to check themselves out, this does not mean that the technician needs to only hook up to the car’s computer in order to see everything that is wrong. Some people will take their car into the shop when the check engine light is on and get annoyed or angry when they are told that they have to pay 75 to 100 bucks just to find out what is wrong. The technician must use their expertise along with their expensive computer diagnostic equipment to diagnose a very complicated system. Why should they have to do this for free?