Onboard vehicle data used to be the domain of the system from where it originated. It didn’t take long, though, before engineers figured out that sharing data from one system could be useful in another. With that understanding, and the fact that overall onboard electronic content continued to grow, the groundwork for onboard vehicle networking was established.
As the list of applications and accessories continues to escalate, it brings about the need for additional vehicle wiring and sophistication. Since additional wiring means added weight, cost and complexity, it goes against the grain of the need for lighter vehicles. Enter Controller Area Network, the perfect technology where less equals more.
MULTIPLEXING WITH ATTITUDE
CAN improves upon a technology known as multiplexing, using multiple onboard computers linked together in the same circuit (a “bus”). Each computer in the link is capable of talking with the other computers, using a specific language known as a protocol.
But CAN goes beyond talking; it plays a greater role in controlling circuits and components than earlier-generation multiplexing.
The first applications of multiplexing used various different protocol standards to send messages across the bus.
Although these early systems were successful in reducing wiring needs to some extent, more work needed to be done to take multiplexing further in terms of efficiency, capabilities and control.
The CAN system was originally designed by Robert Bosch during the mid-1980s, and essentially consists of a simplified, low-cost version of networks used to connect personal computers. Any device on a CAN may communicate with any other device using a common pair of wires.
TECHNOLOGY MARCHES ON
CAN systems provide several benefits today, and may offer even more as other vehicle technologies come online.
Not only are there less wires required for each function in a CAN system, the size of the wiring itself may be reduced.
Sensor data can be shared across the network, eliminating the need for redundant sensors and associated wiring.
Additional vehicle features and functions can be added by way of software changes, rather than adding physical components such as electronic modules and wiring.
Diagnostic information for all systems can be accessed though a single connection point since all of the computers on the bus share information. Without CAN, individual systems need to be accessed separately.
If 42-volt technology is resurrected as the next generation vehicle electrical voltage, CAN will make integration easier.
SPEED WITH CLASS
Before CAN, the first attempts at multiplexing used manufacturer-specific serial communications protocols. Although these systems worked OK for the Big Three automakers, they were proprietary for each manufacturer and did not meet standardized performance criteria. As the U.S. manufacturers became more aware of their needs and as development progressed overseas, it became clear that standards for onboard networking were imminent.
By moving away from proprietary communications protocols (medium- and high-speed networks) and towards industry-developed standards, automakers from around the world moved to embrace established performance criteria for onboard network performance.
The Society of Automotive Engineers established three different classes of onboard networks, based on speed and function:
Class
A networks have low-speed data transfer requirements (less than 10,000 bits/second) and are
used primarily for convenience features such as power windows, power seats, lights, audio
and so on.
Since these requirements are low-speed and convenience-related, manufacturers often retain
proprietary protocols for this application.
Class B networks have medium-speed data transfer requirements (ranging from 10,000 bits/second to 125,000 bits/second) and serve for general information transfer. SAE standard J1850 is the standard protocol for Class B networks and is used in many cars for data sharing and diagnostics.
Class C networks have high-speed data transfer requirements (ranging from 125,000 bits/second to 1 million bits/second) and are used for real-time applications such as engine and transmission control. The most common protocol for Class C networks is CAN 2.0.
Devised by Bosch of Germany in the early ’80s, the CAN 2.0 protocol was first used in a 1991 Mercedes-Benz S-class. To no surprise, CAN 2.0 has found a home with other European manufacturers including BMW, Volvo and VW. Here in the U.S., CAN 2.0 is being similarly adopted.
ALPHABET SOUP
As you have seen, vehicles have different data speed requirements on the same vehicle.
Consequently, when looked at from a networking perspective, it’s becoming quite common for a vehicle to have a Class A CAN, a Class B CAN, and a Class C CAN. This gives manufacturers the flexibility to implement CAN speeds appropriate for the systems they’re controlling, without the expense of overkill or suffering from poor performance in a given application.
Though the various CANs may operate at different speeds, they are still linked together through a common gateway for the purpose of sharing diagnostic information.
SERVICE IMPLICATIONS
First of all, understand that CAN is a technology not reserved exclusively to exotic vehicles. Some common applications include the 2004 and up Ford F-150, the 2005 and up Toyota Avalon and the 2005 and up Chevrolet Cobalt.
Controlled applications of CAN systems also go beyond the reach of high-technology areas like engine and transmission control.
Even common circuits like lighting and accessories have been integrated with onboard networking control.
As more vehicles incorporate CAN, you will need to understand how it works on various makes and models and how to troubleshoot it when a problem occurs.
Your scan tool will need to be CAN-capable as well as any PC-based diagnostic tool.
Check with your equipment rep on the state of CAN-readiness for your equipment.
From here on out, CAN will impact everything you do in the service bay.
