¶ CAN
¶ 1.1 General Concept
CAN (Controller Area Network) is a communication bus that enables data exchange between a vehicle's Electronic Control Units (ECUs) without the need for a central controller.
All nodes are connected to the same bus and operate as equal participants. Any ECU can initiate data transmission, and every message is broadcast to the entire network.
CAN messages are not addressed to a specific recipient. Instead, each ECU independently analyzes incoming messages and decides whether to process or ignore them.
CAN is defined by the ISO 11898 family of standards and serves as the primary communication mechanism in most modern vehicles.
Important: Not every automotive communication bus is CAN. Other protocols, such as LIN, J1708, and VAN, use different architectures and communication principles.
¶ 1.2 Architecture
A typical CAN network consists of a single communication bus to which all ECUs are connected in parallel.
Physically, the bus consists of two wires:
- CAN_H
- CAN_L
Data is transmitted using a differential signal, providing high immunity to electrical noise.
Two 120 Ω termination resistors are installed at the ends of the bus. They are required to match the transmission line impedance and prevent signal reflections.
A CAN network may include many ECUs, for example:
- Engine Control Unit
- ABS
- Instrument Cluster
- Telematics Device
- Other vehicle systems
Regardless of their function, all ECUs receive the same stream of CAN messages.
¶ 1.3 Broadcast Communication
CAN communication is based on the broadcast principle.
When an ECU transmits a message:
- every device on the bus receives it;
- each ECU examines the message identifier;
- each ECU independently decides whether to process or ignore the message.
The transmitting ECU does not know which devices will use its data.
Example:
The Engine Control Unit broadcasts the engine RPM. The same message may be used simultaneously by:
- the Instrument Cluster to display the RPM;
- a Telematics Device to transmit the data to a server;
- other vehicle systems for their own internal logic.
¶ 1.4 No Master/Slave Architecture
CAN does not use a master/slave architecture. The network is fully decentralized, allowing any ECU to start transmitting whenever the bus is available.
However, only one message can be transmitted on the bus at any given time. If multiple ECUs attempt to transmit simultaneously, they compete for bus access. Unlike traditional communication systems, this situation does not result in a collision. Instead, CAN resolves it automatically using a built-in arbitration mechanism.
¶ 1.5 Arbitration (Conflict Resolution)
CAN arbitration is based on the message identifier: the lower the ID value, the higher the message priority on the bus.
If multiple ECUs begin transmitting simultaneously, they participate in a bit-by-bit arbitration process. Each node transmits its own identifier while simultaneously monitoring the bus state. If a node transmits a recessive bit (logical 1) but detects a dominant bit (logical 0) on the bus, it immediately stops transmitting.
As a result, the node with the lowest message ID wins the arbitration and continues transmitting, while the remaining nodes simply wait until the bus becomes available. A key advantage of this mechanism is that no data corruption occurs: the winning message is transmitted successfully, and the other nodes do not interfere with the transmission.
This mechanism guarantees that high-priority messages experience minimal delay, even when the bus is heavily loaded.
Example:
| ID | Priority |
|---|---|
| 0x0F | Higher |
| 0x10 | Lower |
→ The message with ID 0x0F will be transmitted first.
| Start bit |
10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Node 15 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| Node 16 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | Transmission stopped | |||
| CAN Bus | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
¶ 1.6 Practical Considerations
When working with a real vehicle, it is important to remember that there is rarely only one CAN bus. Most vehicles contain multiple independent CAN bus segments operating at different baud rates and serving different vehicle systems.
In practice, this means that a successful connection depends not only on physical access to the wiring, but also on selecting the correct bus speed and connection point. If you connect to the wrong bus segment or use an incorrect baud rate, no CAN traffic will be detected.
¶ Practical Exercise
- Download the sample log:
- Open CAN Spy.
- Select Log player as the Source and open the downloaded log.
- Click Start to begin log playback. CAN messages will appear in the Messages window.
If the Messages window is hidden, enable it from the View menu.
Sort the messages by identifier and examine their transmission frequency.
Keep in mind that the message identifier itself does not define how often a message is transmitted. The transmission frequency is determined by the logic of the corresponding ECU. The message ID only determines arbitration priority and has no direct relationship with transmission frequency.
¶ Module Summary
A CAN bus should be viewed as a shared communication medium without a central controller, where all devices receive the same stream of messages. Each ECU independently decides how to interpret those messages, while access to the bus is managed by the arbitration mechanism.
Understanding this communication model is essential for analyzing CAN logs and learning how CAN parameter decoding works.
¶ References
- CAN Bus for Beginners: https://canhacker.ru/cannewbie/
- CAN bus: https://en.wikipedia.org/wiki/CAN_bus
(The English version is recommended, as it provides the most comprehensive information.)
Back to Contents
CAN Data Structure