Jack Shandle
TechOnline

First defined by the European automotive electronics company Robert Bosch GmbH as an internal project to develop an in-vehicle network in 1983, the controller-area network (CAN) is still commonly associated with the worldwide automotive industry.

But it's hard to keep a robust, simple, and versatile network protocol confined to a single market segment—even if it comprises just the physical and data-link layers in the OSI model. In fact, leaving the upper layers of the protocol stack for others to define has been an advantage. The relationship of CAN and other protocol layers in the ISO protocol stack is shown in Figure 1.

Figure 1:  The CAN protocol specifies only the physical and data link layers

Subsequent standardization by international bodies and the emergence of energetic industry organizations such as DeviceNet and CANopen with their own standards initiatives—in the upper-layers of the protocol stack—have paved the way for the basic CAN protocol to enter a wide variety of markets. CAN-based networks have a significant presence in factory automation, machine control, communications, building automation, and medical devices and systems.

The automotive and transportation segments still dominate unit sales of CAN transceivers and microcontrollers, consistently nabbing 80% of an annual 100-million-unit market with perhaps 20 distinct applications. The 20% of the market shared by all the other segments combined, however, represents thousands of applications most of which do not reach high volume:

• Networking companies such as Cisco Systems, for example, use a CAN sub-network to implement system initialization and hot-swapping on the large PC boards that implement routers. At about 500,000 to 1 million installed nodes per year, router boards number among the larger non-automotive CAN applications.
  
  
• Hospitals control vital operating room components such as OR lights and tables, endoscope lights and cameras, insufflators, X-ray and ultrasound machines, video recorders, and video printers directly from the sterile area using CAN—or, more appropriately, the CANopen protocol.
  
  
• In factory automation, DeviceNet—an upper-layer protocol built on CAN—is one of the world's leading device-level networks for industrial automation. In a recent survey, more than 40% of end users chose DeviceNet over other networks.

Non-automotive applications benefit greatly from the time, energy, and money provided by worldwide automobile manufacturers to keep CAN in step with—or in front of—the technology demands of the time.

In fact, because of the long design cycle of automobile electronics, new capabilities such as gateways that connect networks running at different speeds actually roll out in industrial applications well before they are seen in automobiles, says Geoff Lees, Marketing director for Philips Semiconductors' microcontroller business line.

• Fault tolerance
• Short messages, but high message frequency (more than 10,000/s)
• High bandwidth utilization
• Reasonable transmission speeds
• Several higher-layer protocols available such as DeviceNet, CANopen, and J1939.

CAN uses a sophisticated message acknowledgement system that provides a transmitter with an acknowledgement of receipt right within the message. One of the last bits in a CAN message is an acknowledgment bit that is not written by the transmitter. Instead, it is used by all receivers to send an indication back to the transmitter that this message was received successfully.

If any single node has a receive error, there is a mechanism that allows that node to destroy the message for every node and this results in an automatic re-transmission of the message. As this is implemented in low-level hardware, every CAN node in the network participates in this error checking mechanism, even if it has no use for the message transmitted.

As a result, a transmitter knows that if it got the acknowledgment EVERY node on the network successfully received the message.

By comparison, Ethernet's familiar Collision Sensing Multiple Access (CSMA) protocol allows all nodes equal access to the bus to transmit data. It resolves conflicts by having the nodes back off and rebroadcast after a pseudo-random time delay. The scheme works, but is also inefficient.

During high load conditions, for example, nodes trying to broadcast spend a good deal of their time getting on the bus, backing off, waiting to get on again, and colliding again. As a result, only about 60% of the theoretical bus throughput is ever utilized and Ethernet must go to higher and higher bus speeds to increase throughput.

CAN's protocol, on the other hand, provides nodes with intrinsic priorities so that even when all nodes attempt to access the bus simultaneously collisions and the subsequent back-off/retransmit cycle is virtually eliminated.

An important difference between CAN and Ethernet, for example, is that CAN does not specify a transmitting station or node, only a message. As a result, an Identifier Field is included in each message. In the CAN 2.0 A spec, this field is 11 bits. In the CAN 2.0 B spec, it is 29 bits. Such a message identifier has to be unique within the whole network and it defines not only the content but also the priority of the message.

Here's a simplistic view of how non-destructive arbitration works. The CAN specification defines two bus states: dominant and recessive. Any transmitting node can drive the bus to a dominant state and the bus is in the recessive state when no transmitter is in the dominant state.

In the CAN 2.0 A spec, which is the most widely supported version, an Arbitration Field created from the combination of an 11-bit Identifier and the single Remote Transmission Request (RTR) in the CAN data frame facilitates media access. When a node transmits data, it all monitors its own message, which allows detection of simultaneous transmission.

When a node that is transmitting a recessive bit receives a dominant bit while sending the arbitration field, it stops transmitting. The node with the lower numbered 11-bit identifier wins the arbitration between two nodes transmitting simultaneously.

The newer CAN spec—CAN 2.0 B—increased the Identifier Field to 29-bits in order to accommodate more messages and nodes but the 29-bit field is not supported by DeviceNet.

The net result of non-destructive arbitration is bandwidth utilization of 80% to 90% and very high reliabilty. The scheme of having each node monitor its own broadcast—and the transmission of other nodes—however, limits its maximum throughput to 1 Mbit/s at the standard maximum bus length of 30 meters. On the other hand, the maximum bit rate can be increased by shortening the bus length as shown in Table 1.

CAN's reliability is further enhanced by extensive cyclical recovery checking (CRC). If one CRC match fails it will destroy the message for all nodes.

DeviceNet primarily addresses factory automation applications. As such, economical solutions are the core of its market strategy. It is most often used to connect devices such as valve manifolds, motor starters, limit switches, photoelectric sensors, process sensors, variable frequency drives, panel displays, and operator interfaces to a network.

DeviceNet traces its roots to an application-layer protocol developed by Allen-Bradley but later placed in the public domain. The Open DeviceNet Vendor Association (ODVA) develops and maintains the DeviceNet standard now. The specification must be purchased but it includes an unlimited, royalty-free license to develop DeviceNet products.

Whereas DeviceNet is most widely used in the U.S. and Asia, CANopen plays much the same role in Europe—a higher layer protocol based on CAN. Off-road vehicles, maritime electronics, medical equipment, and railways are all applications that embrace CANopen.

An important service for design engineers provided by both DeviceNet and CANopen is the profiling of both devices and frameworks for specific applications. Profiles promote interoperability by defining standard device models. Various device types are defined such as joysticks, push buttons, motor starters—the list is very long.

Profile-compliant manufacturers provide device-specific data for their products of that type. As long as the vendors comply with the device profile, their products will be logically interchangeable with others that comply with the profile.

Although CANopen and DeviceNet share CAN in the lower levels of the protocol stack, that is pretty much where interoperability ends. Device profiles created for and endorsed by one group do not work with the other.

A joystick provides a good example of a device profile and what it specifies.

One of the first things specified in a CANopen device profile is the description of the device type entry, says Pfeiffer. Any CANopen configuration tool or master can send an "identify your device type" request to any of the nodes on the network. So the joystick needs to be able to reply "I am a joystick."

The joystick device profile also specifies a total of three axes (X, Y, and Z), for each data type—and each being a 16-bit value. For each axis it is specified into which TPDO (Transmit Process Data Object), location and in which CAN message the position data belongs.

This information is enough to ensure off-the-shelf plug-and-play compatibility of any two joysticks from different manufacturers. They will both respond in the same way to the "identify your device type" request and they will both report their values in the same CAN messages at the same location in the message.

Profiles are most attractive for small manufacturers and are a way to impose an open standard on larger manufacturers, who may have CANopen-compliant protocols but try to keep them proprietary.

An example is the application for elevator (or lift) control. The profile does not specify the individual nodes, but rather lists main control tasks, which are called virtual devices in the profile. A single node might implement multiple tasks (multiple virtual devices) depending on system configuration.

For the elevator control system, the tasks or virtual devices are shown in Table 2.

In the microcontroller space, there are a few basic considerations to keep in mind when selecting a device. First, support for both the 2A and 2B standards should be built in because the standards are not interoperable. Specifically, the earlier 2A standard used an 11-bit address identifier while the 2B standard uses a 29-bit identifier.

To minimize unnecessary loading of the microcontroller's CPU, microcontroller vendors have built in additional hardware for filtering and arbitration and some have built the protocols into the serial interface for greater speed.

Filtering can offload the CPU considerably and this is where a de facto and somewhat confusing bit of terminology comes into play—"full" and "basic" CAN. The original CAN specification called for 15 message filters to relieve the load on the microcontroller. Message filters automatically recognize the address of a message and store it in local memory without interrupting the microcontroller. This mode of operations has become known as full CAN.

Basic CAN actually came along after the spec. It reduced the filtering capability to four filters (or address identifiers). The result, of course, is a lower priced microcontroller. Which configuration is best depends on the application.

In a more recent development, some chip vendors have extended functionality to two banks of full CAN so that up to 32 messages can be processed before the CPU has to break in what it's doing. More enhancements are in store, particularly as more microcontroller vendors roll out 32-bit CAN controllers to meet the needs of a highly demanding automotive market.

CAN may be overlooked by some design engineers because of its simplicity and modest bus speeds compared to Ethernet. But considering the fact that it has its roots deep in the automotive industry, dismissing it may be a mistake. The benefits of the automotive connection mean both mass-market semiconductor pricing and rock solid infrastructure support. So it's not surprising that CAN continues to grow in both market size and application diversity.

Contributing writer Jack Shandle is a former chief editor of both Electronic Design magazine and ChipCenter.com. He holds a BSEE degree and has written hundreds of articles on all aspects of the electronics OEM industry. Jack is president of eContentWorks, a consultancy that creates high-value content for publishers, eOEM corporations, and industry associations. His email address is jshandle@earthlink.net.