This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.
View the complete Table of Contents →
This post focuses on why we use CAN Bus rather than on the technical details of arbitration. For a deeper technical discussion, see my post, CAN Bus Arbitration: Ingenious by Design.
The Problem Is Not Sending Data
Sending digital data from one device to another is relatively easy.
The more interesting problem begins when many devices need to communicate over the same network.
Imagine a machine containing twenty electronic control units. One monitors temperature. Another controls a motor. Another reads operator controls. Another detects faults. Another handles safety functions.
They all share the same communication bus.
Now two of them decide to transmit at exactly the same time.
Who goes first?
That question sounds almost trivial, but it represents one of the fundamental problems of any shared communication system.
And the way CAN solves it is one of the reasons I have always considered the Controller Area Network such an elegant protocol.
No Traffic Cop Required
One possible solution would be to appoint a master.
Every device could wait until the master gives it permission to transmit. That certainly creates order, but it also creates additional communication overhead and makes the network dependent on that master.
Another approach is to allow devices to transmit whenever they want and deal with collisions when they occur.
That can work as well. But when two transmissions collide, the data is generally lost and must be transmitted again after some form of delay.
CAN takes a different approach.
There is no central controller deciding whose turn it is.
Every CAN node is allowed to begin transmitting when the bus becomes available.
If only one node starts transmitting, there is obviously no problem.
But if several nodes start at essentially the same moment, CAN does something remarkably clever.
It lets them settle the matter while they are transmitting.
The Message Determines Its Priority
Every CAN message contains an identifier.
That identifier serves several purposes, but one of its most important functions is establishing the message’s priority during bus arbitration.
The important distinction here is that CAN prioritizes the message, not necessarily the device.
A single electronic control unit might transmit many different messages. A critical fault message from that controller can therefore have a much higher priority than a routine status message transmitted by the very same controller.
That makes enormous sense in a distributed embedded system.
The network does not really care which device considers itself important.
It cares which information is important.
Nobody Has to Ask Permission
Suppose three controllers are waiting to transmit.
The bus becomes available, and all three begin transmitting at almost exactly the same time.
There is no master telling them what to do. There is no preliminary negotiation. There is no separate request asking for permission to use the network.
Instead, the CAN controllers compare what they are transmitting with what is actually appearing on the bus.
Because of the electrical characteristics of CAN’s dominant and recessive bits, one message gradually wins the arbitration process.
The lower-priority transmitters recognize that another message has higher priority and stop transmitting.
The winning transmitter simply continues.
And this leads to what I consider the most important part of CAN arbitration:
The winning message was never destroyed.
There was contention for the bus, but there was no destructive collision.
The highest-priority message continues as though nothing unusual happened.
The other nodes simply wait for another opportunity.
Why That Matters
Consider what this means in a real machine.
A controller may be waiting to report that a switch changed state.
Another may be ready to transmit routine engine information.
At almost exactly the same moment, a third controller may need to report a potentially dangerous condition.
All three may attempt to transmit.
CAN does not need software somewhere in the system to examine those three requests and decide which one is most important.
If the message identifiers have been designed correctly, the network already knows.
The safety-critical message wins arbitration and continues immediately.
The routine messages wait.
This is priority-based communication implemented directly in the protocol.
Priority Without a Central Authority
This is another characteristic of CAN that deserves more appreciation.
CAN is fundamentally a distributed network.
There does not need to be one controller coordinating normal communication between all the others.
A new node can be added to the network without asking a central communication manager for a transmission slot. Each controller follows the same rules, monitors the same bus, and participates in the same arbitration mechanism.
That was an extraordinarily practical design decision for automotive electronics, where many independently developed electronic control units had to coexist.
But the same principle is equally useful in industrial machinery, agricultural equipment, medical systems, robotics, and countless other embedded applications.
The network can grow while the fundamental communication concept remains the same.
Not All Data Is Equally Important
There is another lesson hidden inside CAN arbitration.
In many embedded systems, not all information deserves equal access to the network.
A temperature value that changes slowly may be transmitted every second.
An operator pressing an emergency control may require immediate attention.
A diagnostic counter might be useful but certainly should not delay a critical control message.
CAN allows the network designer to reflect those differences directly through message identifiers.
That does require thoughtful network design. Giving everything a high priority obviously defeats the purpose.
But when priorities are assigned intelligently, CAN provides something extremely valuable: predictable access to the communication medium for the messages that matter most.
An Elegant Solution to a Difficult Problem
It is easy to describe CAN as simply another serial communication technology.
Technically, of course, it is one.
But descriptions like that miss much of what made CAN so successful.
CAN was designed for networks consisting of many independent electronic controllers operating in real time, often in electrically harsh environments, where communication cannot simply stop because two devices happened to speak at the same moment.
Bus arbitration is a perfect example of that design philosophy.
Multiple controllers may attempt to transmit simultaneously.
No central master has to intervene.
No separate negotiation phase is required.
The highest-priority message continues without being destroyed.
The lower-priority messages withdraw and try again.
And most of this happens automatically inside the CAN controller, without the application programmer having to manage the process.
That is an impressive amount of network management hidden behind what appears to the software developer as a simple message transmission.
Follow CAN Bus Embedded Development
New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.
View the complete Table of Contents →
A Comprehensible Guide to Controller Area Network
The error detection, error handling, automatic recovery, and fault-confinement mechanisms discussed in this article represent only an overview of the sophisticated reliability features built into CAN. These subjects are covered in substantially greater technical detail in my book, A Comprehensible Guide to Controller Area Network. The book examines the individual CAN error-detection mechanisms, transmit and receive error counters, Error Active and Error Passive states, Bus Off behavior, and the underlying principles that allow CAN to maintain reliable communication even when errors and malfunctioning nodes occur.
A Comprehensible Guide to Controller Area Network focuses exclusively on Classical CAN; it does not cover CAN FD. In addition to error management and fault confinement, the book provides an in-depth treatment of CAN communication, message frames, bus arbitration, bit timing, physical-layer considerations, and the other mechanisms that make CAN particularly well suited for embedded and real-time applications. It is intended as a comprehensive technical reference while remaining accessible to engineers and developers who want to understand not merely how to use CAN, but how the protocol actually works. More information…