Electronics Guide

Controller Area Network

Controller Area Network (CAN) is a robust serial communication protocol originally developed by Bosch in the 1980s for automotive applications. Designed to enable reliable communication between electronic control units (ECUs) in vehicles without a host computer, CAN has become the dominant communication standard in automotive systems and has found widespread adoption in industrial automation, medical devices, and other demanding applications.

The protocol's success stems from its combination of real-time capability, fault tolerance, and prioritized message handling. CAN networks can operate reliably in electrically noisy environments, making them ideal for applications where electromagnetic interference is a significant concern. This article explores the fundamental concepts, protocol specifications, and higher-layer protocols that make CAN an essential technology for embedded systems engineers.

Protocol Overview

CAN is a multi-master, broadcast serial bus that uses differential signaling for noise immunity. Unlike traditional serial protocols with explicit addressing, CAN uses message identifiers that indicate the content and priority of messages rather than their destination. All nodes on a CAN bus receive all messages, and each node decides independently whether to process a received message.

The protocol supports data rates up to 1 Mbps for Classical CAN, with bus lengths inversely related to bit rate. Typical automotive applications use 500 kbps, allowing bus lengths up to 100 meters. The CAN FD (Flexible Data-rate) extension increases payload capacity and enables higher data rates during message transmission.

Key characteristics of CAN include:

  • Multi-master architecture: Any node can initiate transmission when the bus is idle
  • Message-based communication: Identifiers describe message content, not source or destination
  • Non-destructive arbitration: Priority-based bus access without message loss
  • Automatic error handling: Built-in error detection and fault confinement
  • Broadcast capability: All nodes receive all messages simultaneously

Protocol Layers

The CAN protocol architecture follows a layered model that separates physical signaling from data handling. Understanding these layers is essential for both hardware design and software implementation.

Physical Layer

The CAN physical layer defines the electrical characteristics of the bus, including voltage levels, timing, and cable specifications. CAN uses differential signaling on a two-wire bus (CAN_H and CAN_L) to achieve excellent noise immunity.

The bus has two logical states: dominant (logic 0) and recessive (logic 1). When any node drives the bus dominant, it overrides recessive states from other nodes. This property enables non-destructive arbitration and acknowledgment.

Common physical layer standards include:

  • ISO 11898-2: High-speed CAN (up to 1 Mbps) with a linear bus topology
  • ISO 11898-3: Low-speed fault-tolerant CAN (up to 125 kbps)
  • ISO 11898-5: Low-power mode for reduced energy consumption

High-speed CAN requires 120-ohm termination resistors at each end of the bus to prevent signal reflections. The differential voltage swing is nominally 2V, providing substantial noise margin.

Data Link Layer

The data link layer handles message framing, arbitration, error detection, and acknowledgment. This layer is typically implemented in hardware within CAN controller chips.

CAN defines several frame types:

  • Data frame: Carries up to 8 bytes of data (64 bytes in CAN FD)
  • Remote frame: Requests data from another node
  • Error frame: Signals detected errors to all nodes
  • Overload frame: Provides extra delay between frames

A standard data frame consists of:

  • Start of Frame (SOF): A single dominant bit marking frame start
  • Arbitration field: 11-bit identifier (standard) or 29-bit identifier (extended) plus RTR bit
  • Control field: IDE bit, reserved bit, and 4-bit data length code (DLC)
  • Data field: 0 to 8 bytes of payload data
  • CRC field: 15-bit cyclic redundancy check plus delimiter
  • ACK field: Acknowledgment slot and delimiter
  • End of Frame (EOF): Seven recessive bits

Message Arbitration

CAN's non-destructive bitwise arbitration mechanism allows multiple nodes to transmit simultaneously while ensuring the highest-priority message succeeds without data loss. This mechanism is fundamental to CAN's real-time capabilities.

When multiple nodes begin transmitting at the same time, they monitor the bus while sending their identifier bits. If a node transmits a recessive bit but reads a dominant bit, it has lost arbitration and must stop transmitting immediately. The node with the lowest identifier value (most dominant bits) wins arbitration.

This process is non-destructive because the winning message continues without interruption or corruption. Losing nodes automatically retry when the bus becomes idle. The arbitration mechanism guarantees that the highest-priority message always gets through first, providing deterministic latency for critical messages.

Priority assignment requires careful system design. Lower identifier values have higher priority, so critical messages such as safety-related signals should use the lowest identifiers. CAN system designers must allocate identifiers to ensure timely delivery of all messages under worst-case conditions.

Message Filtering

CAN controllers implement hardware message filtering to reduce the software burden of processing irrelevant messages. Since all nodes receive all messages on the bus, efficient filtering is essential for system performance.

Most CAN controllers support two filtering mechanisms:

Acceptance filters define which message identifiers a node will receive. Filters typically combine identifier patterns with masks, where mask bits determine which identifier bits must match. This allows flexible configuration ranging from single-message acceptance to receiving all messages.

Receive buffers store accepted messages until software retrieves them. Controllers typically provide multiple receive buffers with different filter configurations, enabling priority-based message handling. Some controllers offer FIFO buffers for high-throughput applications.

Filter configuration significantly impacts system design. Over-filtering may cause nodes to miss important messages, while under-filtering increases processor load and interrupt frequency. Designers must analyze message flow and timing requirements to determine appropriate filter settings.

Error Handling

CAN implements sophisticated error detection and handling mechanisms that make it exceptionally reliable. The protocol can detect errors with very high probability and automatically manages faulty nodes to prevent them from disrupting network operation.

Error Detection

CAN employs five error detection mechanisms:

  • Bit monitoring: Each transmitter compares sent bits to bus values, detecting bit errors during transmission (except during arbitration)
  • Bit stuffing: After five consecutive bits of the same value, a stuff bit of opposite polarity is inserted. Receivers detect stuff errors when this rule is violated.
  • CRC check: A 15-bit CRC protects frame data. CRC errors indicate data corruption.
  • Frame check: Fixed-format frame segments must follow protocol specifications. Form errors indicate protocol violations.
  • ACK check: Transmitters check for acknowledgment from at least one receiver. ACK errors indicate no receiver acknowledged the message.

When any node detects an error, it transmits an error frame that causes all nodes to discard the current message. The transmitter automatically retries the message, typically succeeding on the next attempt if the error was transient.

Fault Confinement

CAN uses error counters to identify and isolate faulty nodes, preventing a single malfunctioning device from disrupting the entire network. Each node maintains separate transmit and receive error counters.

Nodes transition through three states based on error counter values:

  • Error Active: Normal operation. The node can transmit active error flags when detecting errors. Error counters below 128.
  • Error Passive: The node can still communicate but transmits passive error flags that do not disturb other nodes. Error counters between 128 and 255.
  • Bus Off: The node is disconnected from the bus and cannot communicate. Transmit error counter exceeds 255. Recovery requires deliberate action.

Error counters increment when errors are detected and decrement after successful communication. This mechanism ensures that occasional errors do not permanently degrade node status while persistent problems lead to isolation.

CAN FD

CAN FD (Flexible Data-rate) extends Classical CAN to address growing bandwidth requirements in modern vehicles and industrial systems. Introduced by Bosch in 2012 and standardized as ISO 11898-1:2015, CAN FD maintains backward compatibility while providing significant improvements.

Key enhancements in CAN FD include:

  • Increased payload: Data field expanded from 8 bytes to up to 64 bytes per message
  • Higher bit rates: Data phase can operate at up to 8 Mbps (arbitration remains at Classical CAN speeds)
  • Improved CRC: Stronger 17-bit or 21-bit CRC for better error detection
  • Enhanced stuffing: Fixed stuff bits in CRC field prevent error detection weaknesses

CAN FD achieves higher data rates by switching to a faster bit rate after arbitration, during the data and CRC fields. This approach maintains compatibility with Classical CAN's arbitration mechanism while increasing throughput. The larger payload reduces protocol overhead by allowing more data per frame.

Transitioning to CAN FD requires new controllers and transceivers, but the protocol can coexist with Classical CAN nodes on the same physical bus, provided Classical nodes tolerate the faster signal transitions during CAN FD data phases.

CANopen

CANopen is a higher-layer protocol and device profile specification built on CAN, primarily used in industrial automation, medical equipment, and other embedded applications. Developed by CAN in Automation (CiA), CANopen provides standardized communication mechanisms, device profiles, and application layer services.

Communication Objects

CANopen defines several communication object types:

  • Service Data Objects (SDO): Confirmed read/write access to device parameters using client/server model
  • Process Data Objects (PDO): Real-time data exchange without protocol overhead
  • Network Management (NMT): Device state control and network configuration
  • Emergency (EMCY): High-priority error notification
  • Synchronization (SYNC): Network-wide timing reference
  • Heartbeat/Node Guarding: Device presence monitoring

Object Dictionary

Every CANopen device contains an object dictionary, a standardized structure holding all device parameters and configuration data. The object dictionary provides a consistent interface for device configuration and diagnostics.

Object dictionary entries are addressed by 16-bit index and 8-bit subindex. Standard entries include communication parameters, manufacturer information, and device-specific data. SDO services provide read and write access to any object dictionary entry.

Device Profiles

CANopen defines standardized device profiles for common device types, ensuring interoperability between products from different manufacturers. Profiles specify required object dictionary entries, behavior, and communication patterns for device categories including:

  • CiA 401: Generic I/O modules
  • CiA 402: Drives and motion control
  • CiA 404: Measuring devices and closed-loop controllers
  • CiA 406: Encoders

SAE J1939

SAE J1939 is a higher-layer protocol based on CAN, designed specifically for heavy-duty vehicles including trucks, buses, and construction and agricultural equipment. Developed by the Society of Automotive Engineers, J1939 defines vehicle network architecture, diagnostic services, and standardized parameter definitions.

Protocol Features

J1939 uses 29-bit extended CAN identifiers with a specific structure:

  • Priority (3 bits): Message priority (0 highest, 7 lowest)
  • Extended Data Page and Data Page (2 bits): Parameter group selection
  • PDU Format (8 bits): Determines addressing mode
  • PDU Specific (8 bits): Destination address or group extension
  • Source Address (8 bits): Transmitting node address

Unlike base CAN, J1939 uses source addressing, with each node having a unique 8-bit address. The protocol supports both peer-to-peer and broadcast communication.

Parameter Groups

J1939 organizes data into Parameter Groups (PGs) identified by Parameter Group Numbers (PGNs). Each PG defines a specific set of Suspect Parameter Numbers (SPNs) representing individual data elements. This standardization enables interoperability between components from different manufacturers.

Common parameter groups include engine data, transmission information, vehicle speed and distance, and diagnostic messages. The J1939 Digital Annex defines thousands of standardized parameters covering virtually every vehicle function.

Transport Protocol

J1939 includes a transport protocol for messages exceeding 8 bytes, supporting payloads up to 1785 bytes. The protocol segments large messages into multiple CAN frames with flow control and reassembly at the receiver.

Two transport modes are defined:

  • Broadcast Announce Message (BAM): One-to-many transmission without acknowledgment
  • Connection Mode: Point-to-point transmission with flow control and acknowledgment

Diagnostics

J1939-73 defines diagnostic message formats compatible with OBD-II requirements. Diagnostic trouble codes (DTCs) follow a standardized format enabling universal diagnostic tools to read fault information from any J1939-compliant vehicle.

Implementation Considerations

Successful CAN implementation requires attention to both hardware and software aspects.

Hardware Design

CAN hardware design involves selecting appropriate controllers and transceivers, designing the physical bus, and ensuring proper termination and grounding.

  • Transceiver selection: Choose transceivers appropriate for the target bit rate and environment. Consider protection features for automotive and industrial applications.
  • Bus topology: High-speed CAN requires a linear bus with termination at both ends. Stub lengths must be minimized to prevent signal reflections.
  • Termination: Use 120-ohm resistors at each bus end. Split termination with capacitors can improve EMC performance.
  • Grounding: Proper ground connections are essential for noise immunity. Consider ground loops in systems spanning multiple enclosures.

Software Development

CAN software development encompasses driver implementation, message handling, and application logic.

  • Driver architecture: CAN drivers typically provide interrupt-driven reception, transmit queuing, and filter configuration interfaces.
  • Message scheduling: Periodic message transmission requires careful scheduling to avoid bus overload and ensure timely delivery.
  • Error handling: Applications should monitor error states and implement appropriate responses to communication failures.
  • Protocol stacks: Higher-layer protocols like CANopen and J1939 are available as commercial and open-source implementations.

Applications

CAN's reliability, real-time performance, and cost-effectiveness have driven adoption across numerous industries:

Automotive: CAN is the standard for vehicle networking, connecting engine controllers, transmission systems, body electronics, and safety systems. Modern vehicles contain multiple CAN networks for different subsystems.

Industrial automation: CANopen and DeviceNet (based on CAN) are widely used for connecting sensors, actuators, and controllers in manufacturing environments.

Heavy vehicles: J1939 is the standard for trucks, buses, and off-highway vehicles, providing diagnostics and inter-system communication.

Medical devices: CAN networks connect components in medical equipment where reliability is critical.

Building automation: CAN-based systems control HVAC, lighting, and access control in commercial buildings.

Marine and aerospace: Specialized CAN variants serve marine electronics and aircraft systems where weight and reliability are paramount.

Troubleshooting

Common CAN network issues and diagnostic approaches include:

  • No communication: Verify power, ground, and bus connections. Check termination resistance (should measure approximately 60 ohms end-to-end).
  • Intermittent errors: Look for loose connections, inadequate grounding, or noise sources. Use an oscilloscope to examine signal quality.
  • Bus-off conditions: Identify the faulty node by disconnecting nodes one at a time. Check for software bugs causing excessive errors.
  • Message delays: Analyze bus load and message priorities. High bus loads can cause excessive latency for low-priority messages.
  • EMC issues: Improve shielding, verify termination, and check ground connections. Consider common-mode chokes on bus lines.

CAN analyzers are invaluable for debugging, providing message logging, bus statistics, and error analysis. Many analyzers support protocol-specific decoding for CANopen, J1939, and other higher-layer protocols.

Summary

Controller Area Network remains the dominant choice for embedded communication in demanding environments. Its combination of real-time performance, fault tolerance, and proven reliability has made it indispensable in automotive and industrial applications. Higher-layer protocols including CANopen and J1939 extend CAN's capabilities for specific application domains, providing standardized communication and device interoperability.

Understanding CAN fundamentals, from physical layer characteristics to error handling mechanisms, enables engineers to design robust communication systems. As embedded systems grow more complex and interconnected, CAN continues to evolve with extensions like CAN FD while maintaining the proven core protocol that has served the industry for decades.