CAN Protocol Explained: Frames, Arbitration & Error Handling

CAN protocol data frame structure with arbitration and error handling

INTRODUCTION

Controller Area Network (CAN) is one of the most widely used communication protocols in automotive embedded systems. Designed for reliable, real-time data exchange, CAN allows multiple Electronic Control Units (ECUs) to communicate over a shared bus without a central controller.

This article explains CAN protocol fundamentals, including CAN frames, arbitration mechanism, and error handling, using simple language and practical engineering context.

What Is CAN Protocol?

CAN (Controller Area Network) is a message-based serial communication protocol developed for robust communication in noisy environments. It is widely used in:

  • Automotive ECUs
  • Industrial automation
  • Medical devices
  • Robotics

CAN enables multiple nodes to transmit and receive messages on a two-wire differential bus (CAN_H and CAN_L).

Why CAN Is Used in Automotive Systems

CAN is preferred in vehicles because it offers:

  • High reliability
  • Real-time communication
  • Error detection and recovery
  • Reduced wiring complexity
  • Multi-master capability

Modern vehicles can have 50–100+ ECUs communicating using CAN.

CAN Bus Topology

CAN uses a linear bus topology.

  • All ECUs are connected to the same bus
  • No master-slave concept
  • Each node can transmit when the bus is free

This architecture ensures flexibility and fault tolerance.

CAN Frame Types

CAN communication is based on different frame types.

1. Data Frame

Used to transmit actual data between nodes.

2. Remote Frame

Requests data from another node.

3. Error Frame

Sent when an error is detected.

4. Overload Frame

Introduces delay between frames.

CAN Data Frame Structure (Classical CAN)

A standard CAN data frame consists of the following fields:

1. Start of Frame (SOF)

  • 1 dominant bit
  • Signals start of transmission

2. Arbitration Field

  • Identifier (11-bit or 29-bit)
  • RTR bit
    Defines message priority.

3. Control Field

  • DLC (Data Length Code)
    Indicates number of data bytes.

4.Data Field

0 to 8 bytes (Classical CAN)

5. CRC Field

Error detection using checksum

6. ACK Field

Receiver acknowledgment

7. End of Frame (EOF)

7 recessive bits

Standard vs Extended CAN Frames

FeatureStandard CANExtended CAN
Identifier Length11-bit29-bit
Message IDs2048536 million
UsageBasic systemsComplex networks

CAN Arbitration Explained (Most Important Concept)

CAN uses bit-wise arbitration to decide which node transmits.

Dominant vs Recessive Bits

  • Dominant bit = Logical 0
  • Recessive bit = Logical 1

If a node transmits recessive but reads dominant, it loses arbitration and stops transmitting.

How Arbitration Works

  • All nodes start transmission together
  • Node with lowest ID (highest priority) wins
  • No data loss occurs

This makes CAN a non-destructive arbitration protocol.

Example of CAN Arbitration

  • ECU-A ID: 0x100
  • ECU-B ID: 0x080

ECU-B wins because 0x080 < 0x100, giving it higher priority.

CAN Error Handling Mechanism

CAN is designed to detect and handle errors automatically.

Types of CAN Errors

  • Bit error
  • Stuff error
  • CRC error
  • Form error
  • Acknowledgment error

Error Detection Techniques

• CRC checking
• Bit monitoring
• Frame format validation
• ACK verification

Error Frame Transmission

When a node detects an error:

• It sends an Error Frame
• Current message is discarded
• Transmission is retried automatically

This ensures data integrity.

Error Counters in CAN

Each CAN controller maintains:

  • Transmit Error Counter (TEC)
  • Receive Error Counter (REC)

Based on these counters, a node enters different states:

CAN Node States

  • Error Active
  • Error Passive
  • Bus Off

Bus-Off nodes are disconnected to protect the network.

CAN Bit Stuffing

To maintain synchronization:

  • After 5 consecutive identical bits
  • A complementary bit is inserted

This avoids clock drift issues.

CAN Baud Rates

Common CAN speeds:

  • 125 kbps
  • 250 kbps
  • 500 kbps
  • 1 Mbps

Speed depends on cable length and network design.

Real-World Automotive CAN Examples

Engine ECU

  • RPM
  • Temperature
  • Fuel data

ABS ECU

  • Wheel speed
  • Brake status

Body Control Module

• Door status
• Lighting control

CAN vs Other Automotive Protocols

ProtocolSpeedUse Case
LINLowBody electronics
CANMediumPowertrain, body
FlexRayHighSafety-critical
EthernetVery HighADAS, infotainment

Why CAN Is Still Relevant

Even with CAN-FD and Automotive Ethernet, Classical CAN remains widely used because of:

  • Simplicity
  • Cost efficiency
  • Proven reliability

Conclusion

CAN protocol is the backbone of automotive embedded communication. Its robust frame structure, intelligent arbitration, and powerful error handling make it ideal for real-time, safety-critical systems. Understanding CAN frames, arbitration logic, and error mechanisms is essential for any embedded or automotive engineer.

FAQs

    Exit mobile version