Readers of Pen Computing Magazine probably know significantly more about computers than your average citizen. And that goes especially for the mobile kind, the Palms and Pocket PCs and pen tablets and notebooks that we take with us when we leave the house. Yet, most of us know hardly anything about the mobile computers we use more than any other, the one in our cars.
Yes, cars have computers and plenty of them. They've snuck up on us over the past couple of decades or so and quietly assumed a central role in our daily transportation. In fact, they are vital. While to many of us computers and internet access are part of our daily work, we can still live and work without them until they're back online. If a car's computer is down or doesn't work right, the car won't work (or at least it won't pass an emissions test). That's because these days all major functions of an automobile and controlled, and monitored, by computers on their own networks. If something goes wrong with the car, the computer will know and record a fault code long before a light comes on on the dashboard (the automotive industry calls that a MIL, or Malfunction Indicator Light) alerting us that something is wrong. Some of those problems are simple and will be taken care of next time you go in for a service. Others are not and, if unchecked, can damage or destroy the engine. Bottomline: our cars have computers and networks but most of us don't even know where they are and what they do. And those computers hide their data. There isn't a screen that lets you see what's going on under the hood. However, there is a way to peek inside your car's computer.
OBD: On Board Diagnostics
When computers began appearing in cars, the auto industry realized that standardization was needed. In the 1980s the Society of Automotive Engineers (SAE) came up with OBD, On Board Diagnostics, a set of diagnostics data variables and also with a relatively standard connector plug. OBD's mission was to reduce emissions, make sure failures could be discovered and fixed quickly via good diagnostics. Those standards were adopted by the very stringent CARB (California Air Resources Board) in 1985 and applied in 1988. They primarily checked the proper functioning of a few components and circuits related to emissions. Unfortunately, the original OBD standard was unable to identify a potential problem until it actually happened or a component completely failed, and then it was often too late. Learning from the first standard, OBD-II is an expanded set with much more standardization both in connectors and fault codes, and was adopted by CARB in 1989 and later by the EPA (Environmental Protection Agency). Starting with 1996, every car sold in the US became required to have a computer that can generate the OBD-II codes and a standard OBD-II connector. In fact, OBD-II is a worldwide standard. Internationally, OBD is handled by the ISO (International Organization for Standardization). As a result, every car can accommodate the same DLC (Data Link Connector) and generates the same generic DTC (Diagnostic Trouble Codes).
Generic and enhanced codes
To make things a bit more complicated, Diagnostic Trouble Codes can either be "generic," i.e. the lowest common denominator, or "enhanced," i.e. include codes used only by specific manufacturers. General Motors, Ford, and Chrysler all have their own set of enhanced codes. A standard OBD-II scanner can read all those codes, but not necessarily interpret them as they may apply to a single vehicle of a particular model year.
Automotive networks
And it doesn't stop there. There are also different Data Communication Network Interfaces (DCNI) for vehicles. In the US, SAE specifies "Class 2" J1850 VPW Variable Pulse Width (GM) and "SCP" J1850 PWM Pulse Width Modulation (Ford). Internationally, the ISO specifies the "K-line" 9141-2 standard (also used by Chrysler) and on newer vehicles the "KWP2000" 14230-4 standard. The Canadians use yet another standard. Not all of these protocols use the same pins on the connector, and sometimes it is possible to determine the protocols just by looking at what pins are present.
Data Link Connectors
So where is the car's Data Link Connector, also called a female SAEJ1962? Generally under the dash on the driver side, a foot or so away from the center of the dash. It looks a bit like one of those old Centronics Parallel connectors, though it only has 16 contacts, eight on each side. If you can't find yours, try the national OBD Clearinghouse. I tried it for my 2004 Acura RSX Type-S. The Clearinghouse database said "Under driver side dash next to the center console."And that's where I found it (see picture below). Amazingly, it even had a photograph of the location in my car. That site also contains a wealth of other OBD-II information.
What do you plug into the DLC? That would be a scanner that can read the codes generated and either display them on its own LCD or pass them on to a more sophisticated computer.
OBD-II scanners
The task of a scanner is to interface with one or more of those automotive data communication network interfaces that are very different from any PC network, read the codes, and convert them into something a PC's serial port can read. Yes, serial port. We're talking lowest common denominator here. These days that's increasingly a USB port, but for now you'll need a serial-to-USB converter if your PC does not have a serial port anymore. A popular scanner is the T16 series from Multiplex Engineering (www.multiplex-engineering.com). It can emulate the popular automotive network standards and can be had with a variety of plugs, including one that directly connects to a Palm hotsync cable.
OBD-II Data loggers
In addition to scanners, there is another type of device that uses the OBD-II system--data loggers. Data loggers collect all generated data, up to several hundred hours' worth. An example of a data logger is the Davis CarChip (www.davisnet.com) that, via software, is able to recreate every aspect of a trip--speed, distance, breaking and acceleration and much more. The implications are staggering. Such a system, of course, could easily determine speeding violations. However, it could also provide important clues to what happened right before an accident. Fact is that OBD-III is already being developed, and it will have more sensor s and faster interfaces, and it also may contain transponders that could allow automatic vehicle locating and monitoring.
Software needed
As is, OBD-II simply generates data in the form of codes (see "OBD-II Codes" below). It is up to software to interpret those codes and convert them into meaningful information that can be used to figure out what is wrong with a car, how to fix it, and more. As with all data, experts and professionals may simply take a look at the codes and know exactly how to interpret them. However, having a good software interface is preferable for most of us, and a number of companies have developed special OBD-II software for proprietary scanner tools, but also for PCs and even for Palms and Pocket PCs. Many of those packages are very well designed, with excellent user interfaces, data interpretation, graphic depictions of data, and ways to show how different data points are interrelated and affect each other. See the review of AutoEnginuity's ScanTool on the previous page.
OBD-II Caveats
Technology, of course, moves very rapidly and the state-of-the-art in 1996 is old hat by now. How many of us still use 1996-vintage hardware and software? In addition, since OBD-II was conceived to work on every car and every computer (which the automotive field calls ECU, for Electronic Control Unit), it was sort of a lowest common denominator. For example, OBD-II doesn't require the high rate of data polling that may be needed on some of today's high-tech powerplants. Also, since OBD was originally conceived to get a handle on air pollution, there is a heavy slant to monitoring those components that affect a car's emissions. Fortunately, the wealth of data collected by OBD-II can tell us quite a bit about the operation of the engine sitting under the hood of our cars. In addition, OBD-II provide real-time data acquisition which can be used for more than just fault diagnostics. Some software uses it to measure vehicle performance and it might even be used for tuning purposes. --Conrad H. Blickenstorfer