🚗 Introduction to CAN Protocol

The Controller Area Network (CAN) protocol is a message based communication protocol designed for in vehicle communication among various Electronic Control Units (ECUs). Initially developed by Bosch, CAN has become the de facto standard for robust, efficient, and noise-resistant communication in automotive systems.

❓ Why CAN?

Modern vehicles feature numerous ECUs that require reliable communication. The CAN protocol was developed to fulfill these needs, offering the following advantages

📡 Asynchronous & Multimaster: Any node can initiate communication.
🧠 Noise Immunity: Uses dual twisted pair wiring (CAN High and CAN Low) for differential signaling.
⚡ Low Latency: Small data frame size (max 8 bytes) ensures quick transmission.
🔧 Robustness: High immunity to electrical disturbances.

🔍 Key Features of CAN

⏩ Speed

CAN supports up to 1 Mbps with bus lengths up to 40 meters.
Typically used at 500 kbps in industry.
Frame transmission:
- If a frame is ~125 bits, then ~2000 frames/sec can be transmitted at 500 kbps.

🧱 Data Frame Structure

A CAN frame consists of 2 parts:
- PCI (Protocol Control Information)
- Data Field (0 to 8 bytes)
Data is always in bytes (not bits).
Standard format uses an 11-bit identifier; extended format uses a 29-bit identifier.

🔌 CAN Bus

Uses dual twisted pair wires:
- CAN High
- CAN Low
Logic levels:
- 1 = Recessive
- 0 = Dominant
Terminated with 120-ohm resistors at each end for impedance matching.

🛠️ CAN Architecture and Topology

Microcontrollers communicate using CAN controllers and transceivers.
CAN follows a bus topology, ensuring all nodes receive every message.

🧭 Communication Properties

🔗 Wired vs Wireless

CAN is a wired protocol.
Wireless alternatives include Bluetooth and Wi-Fi.

🧵 Serial vs Parallel

CAN is a serial communication protocol (1 bit at a time).
More immune to noise than parallel communication.

⏱️ Synchronous vs Asynchronous

CAN is asynchronous.
Transmission can begin at any time, no dedicated clock signal needed.

📡 Broadcast Nature

CAN is broadcast/multicast.
All nodes see all messages; filtering is done at the receiver end.

📦 Message Based Communication

CAN is message based, not node based.
Each message has:
- Message ID (for identification and priority)
- Data (0–8 bytes)

🛑 Message Filtering

CAN controllers filter messages using Mask and Filter values:

1if ((Message_ID & Mask) == (Filter_Val & Mask)) {
2  // Accept message
3} else {
4  // Ignore message
5}

🔄 Communication Modes

Simplex: One way communication.
Half Duplex (CAN): Nodes can transmit and receive, but not simultaneously.
Full Duplex: Not supported by CAN.

✅ Acknowledgement Mechanism

CAN uses an acknowledgement field within each frame.
No extra ACK frame, reducing bus load.

📡 CSMA CA Protocol

CAN uses Carrier Sense Multiple Access with Collision Avoidance:

Node senses bus.
If idle, it transmits.
Collision avoided using message prioritization via IDs.

⚠️ Node Failures

Temporary Failure: Node corrupts its own frame.
Permanent Failure: Node stops transmitting/receiving.

🧱 Types of CAN Frames

CAN uses 4 different types of messages

1. 📤 Data Frame

This is the only Frame actually used for data transmission. In most cases, the data source node sends the data frame.
It hast two types, standard and extended. The standard hast 11 identifier bits, and the extended has 29 bits.
The CAN standard requires that the base data frame MUST be accepted and the extended frame MUST be TOLERATED. In ohter words, it will not break the protocol or transmission.

2. 📥 Remote Frame

The remote frame is used when the data description node requests the data from source.

3. ❌ Error Frame

The error frame has two different fields, the first is given by the ERROR FLAGS and contributed by the different stations, and the second is the ERROR DELIMITER, simply indicating the end of the error message.

4. ⏳ Overload Frame

The Overload frame has two fields. These are the Overload Flag and the Overload Delimiter.
The Overload frame is triggered when either by the internal conditions of a receiver or the detection of the dominant bit (0) during transmission.

🧠 CAN Bus Packet layout

There are two types of CAN packets, Standard and Extended. The Extended packets share the same elements as the standard packet, but the extended packets have additional space to include IDs.

🧬 Standard Packet

Every CAN packet has four critical sections.

These are

Arbitration ID is the ID of the device sending the packet.
Identifier Extension this bit is always 0 for standard CAN.
Data Length Code (DLC) indicates the size of the data, from 0 to 8 bytes.
Data is the data in the message. As mentioned, it can be up to 8 bytes.

🧬 Extended CAN

Extended CAN packets are the same as standard CAN packets, but they are chained together to create longer IDs. Extended CAN is backwardly compatible with standard CAN. This means that if a sensor was not designed to accept Standard CAN packets, this system would not break.
Allows more than 512 IDs (up to 2^29).
Uses IDE bit to distinguish:
- 0 → Standard
- 1 → Extended
Adds SRR (Substitute Remote Request) bit as well.

🛡️ Security

Due to CAN being low level protocol, ti does not have any Security feature built in.

It has NO encryption or authentication by default. This can lead to man in the middle (MitM) attacks (no encryption) and spoofing attacks (no authentication).

Manufacturers, in some cases have implemented authentication Mechanisms on mission critical system, such as modifying software and controlling brakes, but all Manufacturers have not implemented them. Even in the cases where passwords have been implemented, they are relatively easy to crack.

📚 Conclusion

The Controller Area Network (CAN) protocol is foundational in automotive communication systems. Its robust architecture, real time capabilities, and noise resistant design make it ideal for modern and future vehicles. Understanding CAN at the bit, frame, and bus levels is essential for both embedded developers and automotive cybersecurity professionals.