PLEASE NOTE: FIGURES WILL LINK TO A PDF FILE

August 17, 1998

CAN protocol eases automotive-electronics networking

Without networking, connecting the electronic modules in a modern automobile results in bulky, complex, and difficult-to-install wiring harnesses. Using a serial bus, such as the CAN, simplifies wiring, reduces the number of data sensors, and implements extra functions at no additional cost.

NS Manju Nath, Technical Editor

The automotive industry worldwide has been working for many years to develop standards for in-vehicle networking. Standards makers have developed the vehicle-area-network (VAN), Automobile Bitserielle Schnittstelle (ABUS), controller- area networking (CAN), and Society of Automotive Engineers (SAE) J1850 standards. Of theses, SAE J1850 and CAN 2.0 are the predominant standards (Table 1). The International Standards Organization (ISO) has adopted CAN as the high-speed networking protocol in Europe, and CAN acceptance is growing in the United States. 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. Robert Bosch GmbH (Stuttgart, Germany, www.bosch.com) developed the CAN protocol in 1989 as an open standard for networking the various electronic modules in automotive applications (Reference 1). ISO 11898 covers layers 1 and 2 of the ISO's Open Systems Interconnect (OSI) Reference Model and standardizes the CAN protocol (Table 2).

You can interconnect the growing number of distributed electronic modules in cars using a serial multiplex network, or multiplexer. You create a multiplexer network by connecting each module that collects, generates, or transfers data onto a serial communication bus. The module or system, which is closer to the source of the data, can, if necessary, manipulate the data. For example, the electronic control unit requires engine-temperature data for correct engine management and transmits this data onto the serial network; the dashboard then receives and displays this information.

A multiplexer network uses one or more serial networks to simplify wiring within a vehicle, increase the number of available functions, provide greater flexibility, and improve system diagnostics. To classify various multiplexer standards, the SAE defines classes A, B, and C in-vehicle networks based on network speed and functions (Figure 1 and Table 3). These local networks are functionally self-contained and operate independently. However, to maximize the vehicle's performance, you must interlink these networks. You can achieve this goal by means of gateways, which are intelligent systems that protect data (messages) before passing them onto other networks. A gateway ensures that only certain messages transfer among networks. For example, if a transmission-branch CAN (Class C) requests messages from the body CAN (Class B), then the gateway computer extracts these messages from the Class B CAN and passes them on to the transmission-branch CAN, modifying them if necessary. This selective triggering of messages promotes accurate delivery of messages and minimizes the bus load in the various networks. In this way, you avoid duplicating some sensing systems.

Both SAE J1850 and CAN 2.0 are carrier-sense, multiple-access-with-collision-resolution (CSMA/CR) arbitration protocols. Through a multimaster architecture, prioritized messages transfer on a serial bus. When two or more nodes try to transmit a message at once, 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 collision, as the term "collision resolution" implies.

CAN messages have no explicit addresses. When a CAN controller transmits data, it does not address stations. Instead, an identifier that is unique throughout the network designates the content of the message (for example, rotations per minute or engine temperature). The identifier defines not only the content but also the priority of the message. This definition is important for bus allocation when several stations compete for bus access. If the CPU of a given station wishes to send a message to one or more stations, the CPU passes the data and their identifiers (IDs) to the assigned CAN chip. The CAN controller then constructs and transmits the message. As soon as the CAN controller receives the bus allocation, all other stations on the CAN become receivers of this message. When each station in the CAN has correctly received the message, each performs an acceptance test to determine whether the data received are relevant for that station.

The CAN's content-oriented addressing scheme provides a high degree of system and configuration flexibility. For example, you can easily add stations to the CAN without modifying any hardware or software on the stations. Because the CAN protocol requires no physical-destination addresses for individual components, it allows for multicast data transmission with robust error checking and correction. The CAN protocol supports standard and extended message-frame formats. The standard format's ID is 11 bits long, and the extended format's ID is 29 bits long (Table 4).

CAN implementation issues

Several possible CAN implementations are available, depending on the microcontroller you use. Picking the right microcontroller depends on the application. For example, if an application requires sensor monitoring, you need a microcontroller with an ADC feature as well as CAN. Also, determine whether your application needs filtering of CAN 2.0A or CAN 2.0B active data packets. In principle, all CAN controllers have a common structure comprising a CAN-protocol controller and memory for buffering messages. The CAN-protocol controller handles all messages transferred via the CAN bus lines, a task that includes synchronization, error handling, arbitration, and parallel-to-serial and serial-to-parallel conversions.

The buffer-memory block, which contains control and message segments, resides between the CAN-protocol controller and the host microcontroller. The exchange of status, control, and command signals between the CPU and the CAN controller takes place in the control segment. You use the message segment to store transmitted or received messages. The message segment also contains a programmable acceptance filter.

The essential difference among CAN implementations is that some controllers have separate transmitting and receiving buffers featuring simple acceptance filtering, whereas other controllers use dual-ported RAMs as message segments with advanced acceptance filtering. CAN controllers with intermediate buffers, such as BasicCAN chips, use hardware logic to create and verify the bit stream according to CAN protocol. However, the host CPU must help the controllers to manage transmitted and received messages, including acceptance-filtering tasks. CAN controllers with intermediate buffers typically have two reception buffers and one transmission buffer. Several vendors offer this type of device. One such device is the Mitsubishi M37630E/M4-xxxFP 8-bit microcontroller with on-chip BasicCAN function (Table 5). The Mitsubishi controller complies with the CAN 2.0B specification and supports standard and extended data frames as long as 8 bytes. The device's BasicCAN module works using a double-buffered receiver and single-buffered transmitter storage scheme and allows acceptance filtering as large as 29 bits for incoming messages.

High-end CAN controllers with intermediate buffers feature hardware-based advanced acceptance filtering. An example of advanced filtering is the Siemens SAE 81C90/91 SFCAN (standalone full-CAN controller). The SFCAN circuit filters incoming messages using a content-addressable memory (CAM). SFCAN compares the ID of each incoming message with the IDs stored in the CAM. Upon finding a match, SFCAN writes the received data bytes into the RAM buffer of the matching message. Meanwhile, the circuit sets the corresponding receive-ready bit and generates a receive interrupt. If SFCAN detects no match, the device rejects the received message.

Object storage

CAN objects primarily comprise an ID, data-length code, and useful data. CAN controllers with object storage (FullCAN) function as CAN controllers with intermediate buffers but also administer certain objects. When several requests occur simultaneously, for example, FullCAN controllers determine which object transmits first. They also filter the acceptance of incoming objects. CAN controllers with object storage offload filtering CAN messages from the CPU. But this performance comes at a price: CAN controllers require more chip area and are expensive.

CAN controllers are available in versions combining both BasicCAN and FullCAN implementation. For example, Motorola's 32-bit M68300 family devices, the MC68376 and the flash MC68F396, comply with CAN 2.0B and offer 16 message buffers, each of which you can configure as transmitting or receiving. The devices feature two dedicated receive-identifier masks and feature time stamping to allow network timing synchronization. The devices suit power-train (engine- and transmission-control) applications.

APIs/development support

A standardized protocol at the data-link and physical layers benefits CAN firmware engineers. Now, system designers are also seeing the benefits of standardized application-layer protocols. In particular, the CAN in Automation (CiA) association has developed a protocol for CAN-based networks corresponding to the ISO/OSI reference model CAN application layer.

In addition, the OSEK/VDX (open systems and their corresponding interfaces for automotive electronics/Vehicle Distributed eXecutive) Consortium specifies a communication protocol with an integrated RTOS suitable for use in CANs for automobiles. These standards allow system designers to avoid low-level protocol details and focus on the application itself. Also, as networking capability becomes common on midpriced and low-priced cars, car manufacturers will easily be able to offer functions in high-end vehicles.

References

1. CAN specification, version 2.0, 1991. Robert Bosch GmbH, Stuttgart, Germany.
2. Zeltwanger, Holger, CAN Communication Model and Its Implications, Managing Director and General Secretary, Can in Automation.

NS Manju Nath, Technical Editor

You can reach Technical Editor NS Manju Nath at +852 2965-1555, fax +852-2976-0706, nsmanjunath@cahners.com.hk.

| EDN Access | Feedback | Table of Contents |

Copyright © 1998 EDN Magazine, EDN Access. EDN is a registered trademark of Reed Properties Inc, used under license. EDN is published by Cahners Business Information, a unit of Reed Elsevier Inc.