The service industry calls the Check Engine light on your dash an "MIL" or Malfunction Indicator Light. It shows three different types of signals. Occasional flashes show momentary malfunctions. It stays on if the problem is of a more serious nature, affecting the emissions output or safety of the vehicle. A constantly flashing MIL is a sign of a major problem which can cause serious damage if the engine is not stopped immediately. In all cases a "freeze frame" of all sensor readings at the time is recorded in the central computer of the vehicle.     Hard failure signals caused by serious problems will cause the MIL to stay on any time the car is running until the problem is repaired and the MIL reset. Intermittent failures cause the MIL to light momentarily and they often go out before the problem is located. The freeze frame of the car's condition captured in the computer at the time of the malfunction can be very valuable in diagnosing these intermittent problems. However, in some cases if the car completes three driving cycles without a re-occurrence of the problem, the freeze frame will be erased.

Modes of operation in OBD-II

According to the OBD-II standard, requests to a vehicle's ECU via the OBD-II port are made up of two bytes (excluding header and CRC bytes). The first byte determines the desired mode of operation, and the second byte is the requested parameter identification (PID) number. The ECU will respond with a two byte acknowledgement and possibly some number of data bytes.     There are nine modes of operation described in the OBD-II standard (SAE J1979). They are:         1. Show current data         2. Show freeze frame data         3. Show stored trouble codes         4. Clear trouble codes and stored values         5. Test results, oxygen sensors         6. Test results, non-continuously monitored         7. Show pending trouble codes         8. Special control mode         9. Request vehicle information     Vehicle manufactures are not required to support all modes. In addition SAE J2190 defines further diagnosis-test-fashions in the area of Hex 10 until Hex 7F. The areas 80 - FF is reserved for future expansions and manufacturer-specific use.

Diagnostic data available via OBD-II

OBD-II provides access to numerous data from the ECU 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 formula to convert raw OBD-II output to meaningful diagnostic units, see OBD II PID's list.

Mistake codes (DTC– Diagnostic Trouble Codes)?

Every OBD II vehicle has to comply to strict emission standards. When the vehicle is new, this is easily achieved, but what about after 50,000 or even 100,000 miles? Every OBD II vehicle is required to able to determine if a fault within the system that would cause excessive emissions to be expelled from the tailpipe in the form of a DTC. The Generic DTC's are a list of mandatory trouble codes that must be present and able to be displayed should a fault arise. There are many Generic DTC's and not all of them will be used on every vehicle. The ones used depends on the yr/make/model/engine of the vehicle. The Generic DTC's are also designed to be able to be retrieved using a standard OBD II Scanner or code reader. The Enhanced DTC's are DTC's that are vehicle specific. Simply put these are DTC's that have been added by the manufacture to further "Enhance" the diagnosis capabilities of the vehicle. Without this option every vehicle would be a clone to one another (see DTC list).     According to OBD II standard (SAE J 1972) a request of mode 3 (Diagnosis mistake codes) returns information about the DTCs that have been set. The response will be an integer number of packets each containing 6 data bytes. Each trouble code requires 2 bytes to describe, so there are three codes per answer. A trouble code can be decoded from each pair of data bytes. The first character in the trouble code is determined by the first two bits in the first byte. A7 A6 First DTC character -- -- ------------------- 0 0 P 0 1 C 1 0 B 1 1 U The second character in the DTC is a number defined by A5 A4 Second DTC character -- -- -------------------- 0 0 0 0 1 1 1 0 2 1 1 3 The third character in the DTC is a number defined by A3 A2 A1 A0 Third DTC character -- -- -- -- ------------------- 0 0 0 0 0 0 0 0 1 1 0 0 1 0 2 0 0 1 1 3 0 1 0 0 4 0 1 0 1 5 0 1 1 0 6 0 1 1 1 7 1 0 0 0 8 1 0 0 1 9 The fourth and fifth characters are defined in the same way as the third, but using bits B7..B4 and B3..B0.

What is OBD 3?

Currently under development are plans for OBD III, which would take OBDII a step further by adding telemetry. Using miniature radio transponder technology similar to that which is already being used for automatic electronic toll collection systems, an OBDIII-equipped vehicle would be able to report emissions problems directly to a regulatory agency. The transponder would communicate the vehicle VIN number and any diagnostic codes that were present. The system could be set up to automatically report an emissions problem via a cellular or satellite link the instant the MIL light comes on, or to answer a query from a cellular, satellite or roadside signal as to its current emissions performance status.     What makes this approach so attractive to regulators is its effectiveness and cost savings. Under the current system, the entire vehicle fleet in an area or state has to be inspected once every year or two to identify the 30% or so vehicles that have emissions problems. With remote monitoring via the onboard telemetry on an OBDIII-equipped vehicle, the need for periodic inspections could be eliminated because only those vehicles that reported problems would have to be tested.     On one hand, OBDIII with its telemetry reporting of emission problems would save consumers the inconvenience and cost of having to subject their vehicle to an annual or biennial emissions test. As long as their vehicle reported no emission problems, there would be no need to test it. On the other hand, should an emissions problem be detected, it would be much harder to avoid having it fixed, which is the goal of all clean air programs anyway. By zeroing in on the vehicles that are actually causing the most pollution, significant gains could be made in improving our nation's air quality. But as it is now, polluters may escape detection and repair for up to two years in areas that have biennial inspections. And in areas that have no inspection programs, there is no way to identify such vehicles. OBDIII would change all that.     The OBDIII telemetry could also be combined with global positioning system (GPS) technology to document or monitor the whereabouts of vehicles. The advantages of using a satellite based telemetry system for OBDIII rather than a roadside system are: * Greater coverage of the entire vehicle population for more accurate surveillance. Vehicles could be monitored and queried no matter where they were, even while sitting in a garage or driveway. There would be no way to avoid the watchful eye of the emissions police. * Being able to locate vehicles that are in violation of clean air statutes, either for "demographic studies" or to track down and arrest violators. * Being able to monitor the whereabouts of vehicles for purposes other than emissions surveillance such as recovering stolen vehicles, keeping tabs on suspected drug dealers, gang members and other undesirables. * Being able to disable vehicles that belong to emission scofflaws by transmitting a secret code. Law enforcement officers might also be able to use such a code to disable a vehicle fleeing from a crime scene or one that belonged to someone with a backlog of unpaid traffic violations.