Introduction to In-Vehicle Networking

Introduction

Today's vehicles contain hundreds of circuits, sensors, and many other electrical components. Communication is needed among the many circuits and functions of the vehicle. For example, when the driver presses the headlights switch on the dashboard, the headlights react. For this to occur, communication is needed between the dashboard switch and the front of the vehicle. In current vehicle systems this type of communication is handled via a dedicated wire through point-to-point connections. If all possible combinations of switches, sensors, motors, and other electrical devices in fully featured vehicles are accumulated, the resulting number of connections and dedicated wiring is enormous. Networking provides a more efficient method for today's complex in-vehicle communications.

In-vehicle networking, also known as multiplexing, is a method for transferring data among distributed electronic modules via a serial data bus. Without serial networking, inter-module communication requires dedicated, point-to-point wiring resulting in bulky, expensive, complex, and difficult to install wiring harnesses. Applying a serial data bus reduces the number of wires by combining the signals on a single wire through time division multiplexing. Information is sent to individual control modules that control each function, such as anti-lock braking, turn signals, and dashboard displays (see figure 1).

As the electrical content of today's vehicles continues to increase the need for networking is even more evident. For example, some high-end luxury cars contain more than three miles and nearly 200 pounds of wiring. The resulting number of connectors creates a reliability nightmare.

Benefits of Networking

In-vehicle networking provides many system-level benefits, many of which are only beginning to be realized.

A decreased number of dedicated wires is required for each function, and thus reduces the size of the wiring harness. System cost, weight, reliability, serviceability, and installation are improved.
Common sensor data, such as vehicle speed, engine temperature, etc. are available on the network, so data can be shared, thus eliminating the need for redundant sensors.
Networking allows greater vehicle content flexibility because functions can be added through software changes. Existing systems require an additional module or additional I/O pins for each function added.
Car manufacturers are discovering new features that are enabled by networking. For example, the 1996 Lincoln Continental's Memory Profile System stores each driver's preference for ride firmness, seat positions, steering assist effort, mirror positions, and even radio station presets.

However, for networking to expand into higher volume economy class vehicles, the overall system benefits need to outweigh the costs. Standardized protocols will enable this expansion. Automotive manufacturers and various automotive industry standards organizations have been working for many years to develop standards for in-vehicle networking. Many standards such as VAN, ABUS, CAN, and SAE J1850 have been developed, but SAE J1850 and CAN 2.0 (Controller Area Network) are the predominant standards.

Multiplexing Standards

The early days of networking involved proprietary serial buses using generic UART (Universal Asynchronous Receiver/Transmitter) or custom devices. This was acceptable in the US because the Big Three (Ford, GM, Chrysler) were vertically integrated and were not highly dependent on external suppliers. However, in Europe and increasingly now in the US, the car manufacturers utilize many external suppliers. Proprietary protocols pose many difficulties with suppliers who need many special system designs to conform to the different protocols. Standard protocols allow modules from many suppliers to easily link together forming a type of `open architecture.' An open architecture will allow standardized diagnostic and emissions testers and will allow suppliers to benefit from the economies of scale of mass-produced standard protocol devices.

SAE Classification

To classify the various standards, SAE has defined three basic categories of in-vehicle networks based on network speed and functions:

Class A	Low Speed (<10K bits/second) Convenience features (entertainment, audio, trip computer, etc.)
Class B	Medium Speed (10K b/s to 125K b/s) General information transfer (instrument cluster, vehicle speed, legislated emissions data, etc.)
Class C	High Speed (125K b/s to 1M b/s or greater) Real-time control (powertrain control, vehicle dynamics, brake by wire, etc.)

A high speed CAN (Class C) network can be analogous to commuting to work at 200 miles per hour versus 2 miles per hour for a Class B protocol. The travel time is much less for Class C networks. This travel time, known as latency, is critical for safety and real time control systems, because any delays in communication could be disastrous.

Class A Multiplexing

Most Class A functions require inexpensive, low-speed communication and typically utilize generic UARTs. These functions are proprietary and have not been standardized by the international organizations.

Class B Multiplexing

In the US, the SAE adopted J1850 as the standard protocol for Class B networks. J1850 has been a recommended practice for over seven years and has gained wide acceptance throughout North America. Today J1850 is implemented in many production vehicles for data sharing and diagnostic purposes. The widespread integration of J1850 in-vehicle networks is contingent on low-cost implementation into applications such as body electronics, diagnostics, and instrumentation.

SAE J1850 was a joint effort among the Big Three and is actually a combination of GM's Class 2 protocol and Ford's SCP (Standard Corporate Protocol). The resulting standard has two basic versions. The first is a 10.4 Kb/s VPW (Variable Pulse Width) type which uses a single bus wire. The second is a 41.6 Kb/s PWM (Pulse Width Modulation) type which uses a two-wire differential bus. Chrysler adopted a variation of the 10.4Kb/s version.

A strong force driving the standardization of J1850 was emissions legislation. CARB (California Air Resources Board) established OBD-II (On Board Diagnostics II) which requires the implementation of diagnostic tools for emission-related systems. OBD-II specifies that stored fault codes be available through a diagnostic port via a standard protocol. Currently, OBD-II specifies J1850 and the European standard, ISO 9141-2.

Class C Multiplexing

The predominant Class C protocol is CAN 2.0. The CAN protocol is targeted at high-speed, real-time control and can operate at up to 1 Mb/s. Robert Bosch GmbH developed the CAN protocol in the early 1980s and worked with Intel on the first silicon implementation, namely, the 82526 controller. This initial implementation of CAN version 1.2 (now known as version 2.0 part A) only allows for an 11-bit message identifier, thus limiting the number of distinct messages to 2032. In 1993 Intel released a new controller, the 82527, the first component to support the latest version of CAN version 2.0B. CAN 2.0B supports both the standard 11-bit and enhanced 29-bit identifier, allowing millions of distinct messages.

ISO in Europe has adopted CAN as the high-speed networking protocol. European automakers have expressed immediate need for the CAN protocol, particularly for luxury models, due to the advantages in-vehicle networking offers to the highly distributed nature of their electronic subsystems. The CAN protocol was first implemented in a 1991 S-class Mercedes Benz, and has since been adopted by BMW, Volvo, VW, Renault, PSA, and others.

In the US, CAN acceptance is growing. The SAE Truck and Bus Control and Communications subcommittee selected CAN in 1994 as the basis for J1939, the class C network for truck and bus applications. For class C automotive networks, the SAE formed a task force to develop a recommended practice for US passenger cars utilizing the CAN protocol. Members from the Big Three, module suppliers, and silicon vendors are participating.

Networking Definitions

Both SAE J1850 and CAN 2.0 are CSMA/CR (Carrier Sense, Multiple Access with Collision Resolution) arbitration protocols. Through a multi-master architecture, prioritized messages are sent on a serial bus. When two or more nodes try to transmit a message at the same time, the protocols handle message contention by arbitration. The lowest priority nodes lose, but the highest priority message successfully reaches its destination without being destroyed by the collision, hence `collision resolution.'

Intel and Multiplexing

Intel has been a key player in standardized automotive in-vehicle networking since the early days of CAN in the mid 80s. With the development of the 82526 and the standalone and integrated versions of the 82527 CAN architecture, Intel has taken the lead in CAN products development. Now, Intel is integrating J1850 functionality into the MCS® 96 product line.

The Intel standalone 82527 and integrated CAN 2.0B communications controllers are based on the same full CAN architecture. These controllers handle all communication functions, including message transmission, reception, error detection and error confinement. This minimizes the burden of the host microcontroller to manage communications, allowing the controller to handle its application functions, such as engine control or anti-lock braking. Intel has integrated this CAN architecture on two members of the MCS 96 microcontroller family, the 87C196CA and 87C196CB.

Intel also supports the SAE J1850 protocol with an integrated protocol handler on the 87C196LB, a 16-bit microcontroller. This J1850 protocol handler supports network functions including access, arbitration, in-frame response, error detection, and delay compensation. A digital noise filter automatically rejects unwanted noise pulses. To minimize CPU overhead, three dedicated interrupts and byte-level message buffering provide for efficient message handling. The protocol handler has dedicated hardware to support low-level network functions, yet is flexible enough to support GM and Chrysler J1850 specifications.

Multiplexing Trends

As the use of serial networks grows and more car manufactures adopt the CAN and J1850 communication protocol standards, certain trends will emerge.

More functions

One of the key benefits of networking is the ability to add functions without adding new hardware or decreasing reliability. As the networking capability becomes common on mid- and low-priced automobiles, the car manufacturers will be able to easily offer functionality found today only on high-end vehicles. Traditionally proprietary Class A functions will move to the standard networks like J1850 and CAN to benefit from the available shared data and standardization.

Multiple networks

Not all networks are created equal. The need for speed and low latency are critical for powertrain control and vehicle dynamics. However, the driver compartment functions like power windows and instrumentation only require a speed sufficient to exceed human perception. To optimize the costs and control data access, multiple networks in a single vehicle are becoming common. For example, a CAN network running at 500 Kb/s may link the engine, transmission, and ABS, while a slower CAN network or J1850 network would link the doors, instrumentation, and other body electronics. A gateway would transfer required diagnostic information between the multiple networks.

Standard application layers

Not only is there a benefit to a standardized protocol at the data link and physical layers, but also system designers are seeing the benefits of standardized application layer protocols. While this is more common in industrial control standards for CAN, but it is also appearing in automotive applications. Examples include: SAE J1939, OSEK from the German automotive consortium, SDS from Honeywell, and DeviceNet from Allen-Bradley. These standards allow system designers to avoid low-level protocol details and focus on the application itself. However, the impact of this type of standardization is increased demand on the microcontrollers and protocol devices, and thus the need for efficient message handling and standardized protocol devices will become even more important.