If you think multiplex is a building with many movie theatres and a single entrance, you're right. In fact, no matter how you use the term, it refers to multiple elements. Normally, however, we think of it as simultaneous transmission of many things-such as bits of information-on a single wire or through-the-air "channel."

If you're a hands-on kind of guy who's far more interested in hearty bites than bytes, you're not alone. It's easy to get turned off by so many computerese references to data buses, networks, protocols, gateways and assorted acronyms.

However, multiplexing in motor vehicles is what makes possible today's electronic controls and features. It eliminates an enormous number of wires and connections, saving weight and space and improving reliability.

Unless you learn the ins and outs of multiplexing, you won't know what to do when your OBD II scan tool refuses to work on an OBD II vehicle. Or even if the tool seems to be working, you won't know why you can't find a problem that should have been detected. You should also know that OBD II is being phased out in favor of something called CAN (Controller Area Network), which will mean either a new scan tool or a major upgrade to the one you have. If you're buying a new scan tool, think of not only what it does now, but what it will require to work with CAN diagnostics, reprogramming, etc.

Going further, a new world of add-on automotive electronics is coming next year, and you'll want to get your share of that installation and service business.

Just as the wireless phone is everywhere today, the "wireless repair shop" also is coming-not in a few years, but perhaps in a matter of months. The capability of remote diagnosis already is in place on millions of vehicles, so you should not doubt that a vehicle can transmit what it needs as it breaks down, or is being driven in a limp-in mode to the shop. Will it be your shop?

Learning the Terminology
Developments in electronics go into consumer use almost with the speed of light. But put aside your qualms. Here we'll use terms that you understand (even if it makes the computer gurus cringe). Let's begin with the most common terminology, then see how things fit together.

Multiplex--many pieces of information going through the same channel or wire at the same time. Sounds impossible, and in a sense it is. Actually, the data goes through in a sequence, but so fast that it seems simultaneous. A tenth of a second is pretty fast when you're reading a watch, but to even a comparatively "slow" computer, that's a long, long time. Many individual data items can be transmitted if that fraction of a second is divided into segments-one for each item. That's called time division multiplexing.

If there's a way to separate the streams of data through the atmosphere, such as radio or cell phone waves of different frequencies, there actually can be simultaneous flow of different data streams. As wireless multiplexing comes to today's and tomorrow's vehicles, you can expect simultaneous data transmissions based on frequency, wave amplitude or other methods. But in an automotive system with one or two wires, time division is the way it's done.

Module--an electronic device that can be a simple temperature or pressure sensor, or a sophisticated computer (microprocessor). Sensors are analog devices, and produce voltage readings related to temperature or pressure. These voltages are converted to digital signals at the entrance to the computer, a digital device. Some simpler modules in certain types of computer multiplexing systems are called nodes.

Data bus--the so-called information superhighway along which data travels between modules. If data can be both transmitted and received by the modules, the data bus is bidirectional. In a vehicle, the information superhighway actually is a wire, or perhaps two wires-not for an extra traffic lane, but sort of like a shoulder that holds the speed limit signs and traffic lights. In case the data lane breaks, this "shoulder" might be used in some data buses to carry "traffic." Or traffic actually might run in reverse to permit data travel along the intact section of a one- or two-wire data bus.

The two wires of a data bus are twisted to reduce electrical interference. Each vehicle maker has been designing its own data bus. If they're exclusive designs, they're called proprietary data buses. If they're designed to some international standard, they're not supposed to be proprietary but, in reality, could be, as you'll see. Now that you've come this far, you can go back a step and think of modules as entrances/exits on the superhighway.

Network--more than one data bus tied together to share information, or the data bus and its modules all considered as one system. The new Lexus LS 430 has 29 computer modules in several data buses, which exchange information with each other. Because the modules and data buses are physically so close to each other in a vehicle, it's often called a LAN (local area network). A Motorola-proposed low-cost, low-speed network for intelligent body accessories is being called a LIN (local interconnect network).

Architecture--the layout of the information highway, with all its entrances and exits labeled for what information can get on and leave. If "police" (special-function electronic chips) are to be used to regulate traffic, there will be stations for them, perhaps at each module's entrance/exit. The architecture covers the number of wires-usually one or two. Where two wires are used, the difference in voltage between them may be the basis for the data transmission. When one wire is used, the voltage reading is referenced against electrical ground.
Other important characteristics of any data bus/network architecture include:
*The number of modules that can work together.
*Expandability. Can a new module be added without a major rework?
*The types of information exchanged.
*Data transmission speed.
*"Robustness," or fault tolerance-resistance to significant breakdown from a failure, and how consistent and accurate the information exchange will be.
*Cost-the bottom line.

The architecture is designed to work with certain protocols.

Protocol--the so-called rules of the road, including the way the "road signs" are written. When the presidential limousine is on a highway, it has absolute priority over any other vehicle. After the President's car and those of other VIPs, police cars, fire trucks, ambulances, etc., get priority, but only if they're performing a critical function, not merely cruising or returning to their base.

The details of a data bus protocol are not simple, but here's a simple example: When Module A determines that the engine is close to overheating, it gets priority over less important information, such as that from Module B, which wants to report the latest change, say, in barometric pressure. Standard inclusions in a protocol usually are wake-up call (a signal to a module that's "sleeping" to conserve current) and handshake (an exchange of signals between modules to acknowledge compatibility and readiness to perform).

There are practically as many totally different protocols as the human mind can devise:
*In a simple protocol, all modules are equal. Each broadcasts information to all others according to a set of priorities, and each module knows what information to accept.
*One module is the master, which decides (based on its priorities) which slave should report and when.
*All modules are like riders on a carousel, with the "free ride" token ring revolving around them. When one module has useful information, it grabs the ring and attaches a message; whichever other module needs it can pick it off the ring.
*There's an "arbitration" system, usually based on the digital "spelling" of each message. The system sets the priority for each data transmission (for example, a digital message that ends with a 1 has a higher priority than one ending in a 0).

As a service technician, you really don't care about the protocol itself, only the effect it can have on diagnosis.

Why all the motor vehicle protocols? It all depends on how much data the maker wants to transmit to how many modules and how fast that data has to move along the bus. Every data bus could be lightning fast, which is useful for engine torque management, emissions, etc. But how fast a signal do you need to turn on the a/c or operate a power window? And how much data does it really take to send a simple signal to open a power door lock vs. operating a complex emissions strategy? A sophisticated protocol can do a lot of things, but it may require more expensive modules to process information at high speed. Why spend extra money for simple requirements?

Most protocols (and therefore the data buses and networks they serve) are proprietary and require specific software for diagnosis. Heard of GM's E&C (entertainment and comfort) bus, introduced in the mid-'80s for operation and diagnosis of radio, HVAC and some other body systems? It's a proprietary data bus that requires specific diagnostic software. Ditto for Chrysler's CCD (Chrysler Collision Detection), which is used for chassis/body/engine networks on many models through the present model year. Software for these two are widely available in the aftermarket, but many other systems, particularly safety-related, are dealer-only at this time. Incidentally, CCD offers the following good example of a fault intolerance: If a module loses its ground, the network goes down (although many individual functions continue).

Data bus speed and electronic "width"--traffic patterns, toll booths, etc., prevent you from driving the posted speed all the time. It's basically the same with a data bus, where a module may be asleep, has to wake up and let the other modules know it's awake, perhaps awakening them, too. The speed limits in an automotive data bus are not posted in mph, but usually in baud rate, which are kilobytes per second (kB/sec). The "width" of the highway also affects data transmission speed-a 32-bit system means that four times as much data can be transmitted than one wide enough for only 8 zeroes and ones.

Proving that speed isn't everything, GM has introduced a master/slave architecture using a version of its low-speed OBD II data bus, for its new Bravada/Trailblazer/Envoy sport/utes. A Truck Body Controller is the master, and there are 17 modules in physically different zones, providing a broad range of features, from battery rundown protection through HVAC, all lighting, seats, antitheft systems, wipers, washer, memory seats and mirrors and door locks, including personalization of many adjustments through the remote.

Super-fast data buses and networks are prone to produce a lot of electrical noise (electromagnetic interference), which causes errors in data transmission. There are many ways for a data bus to detect errors, such as by checking the length of a particular transmission. But if there's an error detected, data has to be retransmitted, which slows everything down again. The alternatives are costly (more powerful, more sophisticated) modules, two wires vs. one (more expensive than you'd think) and even shielding of wiring.

To keep the price right, a data bus and network has to be no faster or more complex than necessary. Most designs are done in at least three basic versions-slow, moderate and fast.

Enforcing the protocol--may be self-enforcing (arbitration, token-ring, master/slave). It also may be done with the aid of electronic chips that decide who goes and when. The Chrysler CCD data bus has such a chip in each module, and the way everything works together is Chrysler's proprietary design.

Engineering Standards: Where They've Taken Us and What's Coming Soon
When the term standard is used, we're talking about an engineering standard. Think of a protocol standard as sort of a National Highway Act, in which there are broad guidelines, such as maximum speed, lane width, etc. But each state and city gets to fill in the details when it builds roads. The old cliche "The devil is in the details" applies to local highway laws, and certainly to OBD II, as well.

OBD II was legally required across the board by 1996, although some vehicles were equipped with the system as early as '94. The objective of OBD II was to create a generic protocol standard for detection and diagnosis of emissions-related failures and operating conditions of specific systems. Everyone had to use the same 16-pin diagnostic connector and produce specific numbered trouble codes that when logged by the powertrain computer would report to a generic scan tool. 
In addition, certain data items called PIDs (parameter IDs) that were in the emissions control area would have to be displayed.

What emerged was J1850 from the Society of Automotive Engineers-really 21Ú2 data bus protocols under a single banner. One is a GM "Class 2 Bus" protocol that operates at 10.4kB/sec with one wire. A second is the Ford "Standard Corporate Protocol," which operates at 41.6kB/sec with two wires. Finally, there's a Chrysler adaptation of the GM Class 2. The GM and Ford protocols cause a data bus to operate in totally different ways. These protocols not only feed the scanner, but operate the data bus, as well.

ISO 9141-2 (from the European-influenced International Standards Organization). This is a single-wire system, but nothing like anything in J1850. Modules talk only when asked, and only to the scan tool, not to each other, so it's a master/slave setup. And it's even slower than GM and Chrysler versions of SAE J1850. It has a long wake-up call and allows lots of time for each module to report each PID.

ISO 14230. This was considered an upgrade to ISO 9141-2 and was in use by 1997. It has a faster wake-up call and a system to bypass any PIDs that are not supported by the data bus.
All existing protocols support burst mode, a setup where you can ask the on-board system to transmit in "multiword" bunches, so perhaps a half-dozen PIDs can be transmitted and updated continuously. In standard mode, the scanner waits for each PID to be reported one by one, then displays them all...slowly. Burst mode obviously is handy for diagnosing intermittents.

However, "supports" doesn't necessarily mean "available." While some OBD II vehicles actually provide burst mode, others don't. It varies by model, so check your CD-ROM information system. If burst isn't supported, pick only the most likely PID or two for evaluation, or the information will come slooowly.

Basic Compatibility
It should be obvious that all these OBD II protocols involve different computer languages, and with proprietary protocols, the electronics can be complex. Cadillac Catera, for example, uses ISO 14230, J1850, GM's E&C and CAN. Just as you can learn a foreign language, a scan tool can be programmed to recognize all these protocol languages.

But if you thought that when you bought your first OBD II scan tool the generic coverage would be complete, you've now found out otherwise. For example, an early-release generic scanner will not "hear" anything from a data bus using ISO 14230. It will think nothing is being transmitted, and tell you that on its digital display. The tool needs a software upgrade.

Note that almost all ISO systems on vehicles that underwent anything but a trim change went from ISO 9141-2 to ISO 14230.

In-Depth Compatibility
Remember our cliche about the devil being in the details? One team of software engineers will read the protocols and their in-depth rules one way, while others come up with slightly different interpretations. So long as they're very close, everyone's scan tool should do the same on OBD II generic. An aftermarket company may choose to ignore some PIDs if it feels they're not useful to the independent technician, or duplicated by other PIDs, but the key information should be there.

Unfortunately, real problems have arisen with generic OBD II. Here are a couple of examples:

*Chrysler trouble codes. There was a programming error on early-production 2001 Ram Vans and Trucks, Dakotas and Durangos, Jeep Wranglers and Grand Cherokees and Vipers. So a generic scan tool won't display six oxygen sensor heater codes or ambient sensor temperature. And on Viper, it also may generate a false P1394 code (for the leak detection pump switch). There's a new program out there, but don't bet dealers will bother reprogramming, because the error doesn't affect them. The problem doesn't arise with the DRB III (or aftermarket scan tools using Chrysler's enhanced mode).
*Hyundai and Kia. Late models of these vehicles use ISO 14230, but they have German engine computers and Korean transmission controllers. When you plug in your scanner, you'll see a message about emissions "readiness tests," saying whether they're completed or not. However, when you try to grab trouble codes or PIDs, you'll run into a problem. The transmission controller may get on the line and start talking. But it has nothing meaningful to say. Its jabber is interpreted by your scan tool as "no transmission," which is what you'll see on the display. You can try plugging in your scanner and starting the engine once more, and then again, and again. At some point you may be lucky and the engine controller will get on the line first, giving you access to the codes and PIDs.

Information Sharing: Meet the Gateway
With so many different data buses and networks in use, there has to be a way for them to share information accurately and without protocol conflicts. The powertrain electronics may want to be awakened when the driver unlocks the car, for example. To permit an error-free exchange between data buses that operate with different protocols and different speeds, there are special computers called gateways.

Gateway refers to a type of module, and how well it can do its job determines the effectiveness of any attempt to get different computer data buses, modules, networks, etc., to talk to each other. In effect, your OBD II scanner performs a gateway function to its own display, for the generic OBD II protocols. A gateway is like the guard at a gated residential community. Before he raises the gate to let anyone in, he finds out if the guest is invited. Or he may just pass some information to a resident. The gateway module does the same thing for communication between data buses and networks that are not compatible but need information from each other. But don't necessarily blame the messenger (the gateway) if the data doesn't get through. The software may be faulty in one or more modules.

CAN Is Here, and Now It's for Diagnostics
Why do we need still another network and protocol? CAN (Controller Area Network) actually has been around for years, used just for powertrain control on many big-rig trucks and European cars. However, diagnostic data goes through a gateway to a J1850 or ISO data bus. 
CAN itself is legal for emissions diagnosis in Europe now, and apparently will be approved for use in the U.S. by next year. When there's talk about CAN, it's really CAN C, the highest speed network, although there also will be widespread use of CAN B, a medium-speed network.

CAN C runs at very high speed, permitting ultra-fast emissions control, which explains its popularity. It's a two-wire system with multiple master modules, so failure of one has little effect on operation. It's intended to operate at a 500kB/sec baud rate, about 50 times faster than GM's Class 2 data bus version of J1850 and over 60 times faster than ISO 9141-2. When CAN C is used for diagnostics, you can expect a near revolution in scanner performance. As one electronic architecture specialist at Chrysler put it, "That's quasi-realtime." Others are not quite so exuberant, claiming that some driveability glitches come and go even faster, so don't expect your multitrace oscilloscope to gather dust just yet.

CAN B, the medium-speed network (nominally about 125kB/sec), will be used for body electrical systems and probably will operate at just 83.3kB/sec at Chrysler, according to its engineering staff. Will CAN B and CAN C be able to work together (doing a CAN-CAN?)? No, there'd be too big a difference in "leg-kicking speed." There has to be a gateway between them.

The bottom line on CAN C is that your present scan tool won't be able to do CAN diagnostics, and you'll likely need more than just new software. Can your scan tool be upgraded economically? Some have the internal hardware or plug-in configuration that permits this; others don't and will not be upgraded, particularly older and lower-end scan tools from several makers. Before you buy something new today, ask the questions regarding CAN diagnostic capabilities. If the salesman doesn't know, call the technical service department at the tool manufacturer.

Plug & Play Is On the Way
If you have a personal computer with "plug and play" software, you know the feature doesn't always work. (Some call it "plug and pray.") And so-called standard formats in graphics (TIF, JPG and PDF) sometimes do and sometimes don't. Be prepared for that in automotive accessories, including the scanner software that may be marketed to diagnose trouble. The proposed standards are "open" to all, but how they're interpreted will determine how effective they are.

Virtually all the vehicle makers have signed on to a proposed "plug and play" standard for add-on accessories called Intelligent Data Bus, or IDB. But like OBD II, it already has two distinct proposals for "the details." One is to use IEEE1394, the Apple standard for personal computer systems better known as "Firewire." It's fast and sophisticated, and Ford has been showing a Lincoln Navigator rear-seat entertainment system (Sony PlayStation) based on it. Pluses: A lot of Firewire product already is out, ready for plugging in, and more is in the pipeline.

But German manufacturers are supporting MOST (see the sidebar "Acronym Stew" at left), an alternative. The first set of specs from the IDB consortium hasn't picked a winner. Will the final specs (due out in a year) do that? Not likely. It probably will be like SAE J1850, and give both sides room to deal with the IDB gateway.

IDB is for physical connections. Wireless standards also are in the works for cell phones and other devices, such as Palm Pilot and its competitors.

If you got through to here, you're entitled to ask: Have we told you everything you need to know about multiplexing? Truth is, we haven't even come close. We gave you just the absolute basics. However, causes of problems you've been encountering should start to clear up. And as the new systems come out, you'll pick up details that will not seem as though they're in a foreign language. You'll be able to ask the right questions when you buy or upgrade your test equipment. And we'll tell you more, to help you negotiate the learning curve.