By Bernard J. Carr
Our affair with automotive systems started with the desire to know how under-the-hood things operated. Noises and rattles piqued our interest and led investigative car guys to get to the source of the problem. In a way, the racket and clattering was the system's means for letting us know something was wrong.
Roll the tape back to 1980 or so, and the previous scenario is quite real. In the early 1980s, we as a society realized that our air was not healthy. Service technicians were changing ignition points, breaker plates, carburetor parts or other mechanical parts in a meaningful attempt to get the vehicle back to normal operating condition. Soon, though - to comply with emerging emission standards - a new wave of electronic systems were starting to make their presence known in the vehicle. The aim and goal of these newfangled electronic components was to enable the straight mechanical system to operate better and last longer. Carburetors had electronic parts inside of them, and electronic data link connectors (DLC) that connected specialized test equipment under the hood appeared. Again, this was an attempt to reduce tailpipe emissions and clean the air we breathe.
Most apparent to the owner of a vehicle from that era was the factory installation of a new lamp on the instrument panel. Text-based check engine lamps or lights with a picture of a little engine diagram became prevalent. What we desired to know then was why we needed this new instrument panel mounted light, and what was it for? Understanding why is again rooted in the manufacturers' quest to clean the tailpipe emissions expelled by their new cars, which gave rise to the role of on-board diagnostics (OBD) as a means to self-diagnose these advanced, yet early systems.
Inside the electronic control unit (ECU), and co-existing with the operating system and embedded application, is the OBD software element. Describing the hardware that ECUs use can be difficult because they rival some desktop computers. Equally more inspiring is how these eight-, 16- or 32-bit based microprocessor systems are environmentally conditioned to operate subsystems of small- to large-sized ground based vehicles in the oppressive heat of the Southwest or the chilling cold of the Antarctic. ECUs of all types are installed on vehicles, and they operate all kinds of subsystems on the vehicle such as the engine, antilock brakes, seats, stability and entertainment - to name a few. Subsystem self-diagnostics is purely a secondary function that is resident within the ECU and serves to troubleshoot intricate problems within a complex machine. OBD determines failures when inputs stray from expected normal values for incorrect periods of time. Similarly, OBD checks on outputs to make sure the commanders of actuating devices are changing the medium they are controlling.
Today's OBD is robust, multifarious and loaded with information and data. Often though, a short step back to observe how things were can best explain why we have what we have today. As manufacturers devised these discriminating ECUs to better manage fuel control (so that tailpipe emissions were kept low), they implemented OBD by applying their in-house engineering methods. Cross-sectional review of vehicles from that time yielded many different data link connectors and the functions within the OBD system varied across makes. This made for lots of equipment and training but started a category of diagnostician within the ranks of service technician job classifications. Rightly so, manufacturers implemented diagnostic utilities that enabled their systems to be diagnosed effectively, which was the dawn of OBD.
In the mid-1980s, regulatory agencies started to become involved. Realizing that this "OBD thing" was good for the environment, they chose to tighten the reins by regulating manufacturers to enlist ECU software checks for input and output circuit open and short circuit conditions. Accompanying this regulation was the requirement for a standardized malfunction indicator lamp. By 1987, all new vehicle production sold in California had to be equipped with these new features, which became known as On-Board Diagnostics Level I (OBD I). The underlying goal of OBD was to better the air we breathe.
Just as technology was expanding in other markets like personal computers and calculators, inroads were being made in automobile electronic system design and functionality. In furthering their desire to clean the air, regulatory groups established even more complicated functions that OBD would have to support. Continuous detection of fuel system concerns, component circuit monitors, real-time cylinder misfire detection, malfunction indicator lamp, multiple on-board diagnostic evaluations, plus oxygen sensors after the catalytic converter, were some of the more prominent provisions specified as law. Beginning with 1996 models, cars and light duty trucks were required to have such OBD functionality, which was appropriately titled on-board diagnostics level II (OBD II).
The role of industry standards cannot be overlooked at this point because there was just too much technology finding its way onto the vehicle electronic system. Industry groups like the U. S.-based Society of Automotive Engineers (SAE) and European-centered International Standards Organization (ISO) were enlisted to work with experts from the automotive and tool equipment manufacturers. They devised new and better ways to support regulatory functionality that were within the abilities of their talented engineering teams. An example of their tireless efforts led to recommended practices such as SAE J1962, the standard 16-pin DLC that is referenced by California ARB OBD II regulations, plus other standardized methods and processes.
As OBD II was coming on the horizon, another area of vehicle electronics was experiencing phenomenal changes. 1980s-invented vehicle data communication networks morphed from dedicated point-to-point communication links with single solution functionality to Class B medium speed communication networks. Borrowing the topologies from a local area network (LAN) model, possible on-board vehicle configurations were ring, star and pole, with the advantage that these new networks could transfer data between ECUs, thereby eliminating redundant sensing paths. And like the DLC and diagnostic approaches from the 1980s, these data links changed from manufacturer defined to industry derived. Examples were Mitsubishi 1952bps MMC or Ford 9600bps Data Communication Link protocol to the more advanced SAE J1850 or ISO 15765-4 protocol.
With a means to share information over more innovative networks in place, the charge was on to speed up the diagnosis and repair of emission-related problems. Generic diagnostic capabilities - including on-board diagnostic evaluations for oxygen sensors, catalytic converters, evaporative subsystem, exhaust gas recirculation subsystem, standard diagnostic trouble code (DTC) definitions, generic diagnostic data parameter lists, plus standardized serial data protocols - fundamentally became resources for a service technician's repertoire of diagnostic data and information with which to diagnose emission problems. The effort to get where we are today with such unsurpassed information and diagnostics is partly due to industry experts working to harmonize diagnostics between SAE and ISO working groups. Some look at this as a start for global diagnostic strategies while others desire to use the advanced functions of OBD II to feed the next generation of inspection and maintenance test programs that are being implemented across the United States and other air quality-challenged areas of the world.
Of course, the genericness of any diagnostic process can always be enhanced. At least that is what the manufacturers may believe. Embedded within their sophisticated ECU algorithms lays the need for sophisticated diagnostic data and enhanced diagnostic capabilities for the diagnostician. Factory diagnostic functions include extended length diagnostic data parameter lists, specialized and expanded failure records (a single data capture of ECU system failures that includes manufacturer system specific information), status information for DTCs, automated system tests that generate a determinative assessment of the subsystem or component under test, and the all-inclusive on-board diagnostic control. With this deep functionality and coverage of powertrain, chassis and body systems, it is no wonder that today's diagnostic technician speaks with technological abandon while demanding a well-equipped shop and commensurate compensation.
All this data and information cries out for a suite of clever and dedicated diagnostic tools to support demanding diagnosticians while they perform inquisitive analysis of the ECU-based OBD system. One key item on the equipment list is a dedicated scan tool that acquires parametric information (e.g. DTCs, diagnostic data parameters) from the ECU and presents it to a skilled reader for knowledgeable interpretation of the OBD data. Such a formidable tool would also provide functional command of actuators and minimal automated test sequences. Of course, this requires skilled understanding of data, and is especially important when the data is used by a diagnostician to determine which path to take while using diagnostic flow charts available in service information. As is the case now, quite often the diagnostician has to sift through monumental amounts of service information with the hope of locating a
suitable diagnostic process that can aid in the determination of what is wrong. While the display of parametric information and service information is separated and lacking total integration,
the latter presents service
procedures, diagnostic routines and specification values to fix vehicle systems. Then it is up to the service technician or diagnostician to marry the two together and make sound decisions based on his or her knowledge of system operation, the data and the control system designer's diagnostic process.
With each passing decade, the functionality that OBD provides will increase. In fact, it is on a path that embraces extra capability and integration into the overall diagnostic process. In the coming years, we'll likely see that through further vehicle network and communication protocol enhancements, the data and information available from the ECU's high-level OBD system will allow for more advanced service and diagnostic processes. The widening gap between automotive technology and diagnostician learning only increases the role and importance of OBD. How that skill gap integrates with OBD is quite possibly the most important and current problem to solve.
| Bernard J. Carr is manager of automotive systems engineering at Vetronix (ETAS Group) in Santa Barbara, Calif. You may reach him at Bcarr@vetronix.com.
|