Back in the early 1980s, cars were starting to move beyond pure mechanics. Electronic fuel injection was replacing carburetors, ABS was entering production, and comfort features like power windows were popping up. The problem? Each new electronic function came with its own wiring. Vehicles were quickly turning into heavy, messy bundles of copper. In 1986, Bosch came up with a solution — the Controller Area Network (CAN). Instead of running separate wires for every function, ECUs could now share a common communication bus. Just two wires could handle messages for dozens of controllers, and thanks to CAN’s
built-in priority system, safety-critical signals like braking always got through first. By 1991, CAN was standardized as ISO 11898, and through the 1990s it became a staple in engine, transmission, and safety systems. Automakers loved it because it was reliable in noisy automotive environments and cheaper than point-to-point wiring. The 2000s brought complexity — premium cars had 50, even 70 ECUs. Classical CAN (1 Mbps, 8-byte payload) was solid but starting to show its limits. Bosch answered in 2012 with CAN FD (Flexible Data Rate), extending payloads to 64 bytes and boosting speeds up to 8 Mbps. That upgrade kept CAN relevant for ADAS and over-the-air updates. Today, CAN works alongside LIN, FlexRay, and Ethernet. Ethernet carries camera feeds and infotainment data, but CAN remains the backbone for deterministic, safety-critical tasks like braking and stability control. And it’s still evolving — with Secure CAN and AUTOSAR’s security layers, it’s adapting to the connected, autonomous future. More than three decades on, CAN hasn’t just survived — it’s still the nervous system of modern vehicles.
Unlike protocols that focus on point-to-point communication, CAN is multi-master,
broadcast-based, and message-oriented:
● Multi-master: Any ECU can transmit when the bus is free.
● Broadcast: Every ECU “hears” every message, but only acts if it’s relevant.
● Message-ID Based: Messages don’t carry source/destination addresses — only
identifiers that also encode priority.
This ensures fairness, reliability, and predictability — all at low cost.
A typical CAN network consists of:
1. Nodes (ECUs): Each ECU is a node that generates or consumes data (e.g., engine
ECU, airbag ECU).
2. CAN Controller: Manages frame formatting, arbitration, error detection.
3. CAN Transceiver: Converts controller signals into differential voltages on CAN_H
and CAN_L.
4. CAN Bus: Twisted-pair wiring carrying signals across the network.
5. Termination Resistors: 120Ω resistors at both ends of the bus to prevent
reflections.
Understanding the CAN frame is essential:
● Identifier (11-bit in Classical CAN, 29-bit in Extended CAN): Defines both
message content and its priority. Lower ID = higher priority.
● Control Field: Indicates data length.
● Data Field: Up to 8 bytes (64 bytes in CAN FD).
● CRC Field: For error detection.
● ACK Field: Receivers acknowledge correct reception.
● End of Frame: Marks message completion.
Every bit in this structure contributes to determinism and reliability.
The arbitration mechanism is what makes CAN deterministic:
● If two ECUs transmit at once, they send their identifier bit-by-bit.
● Dominant bits (logic 0) override recessive bits (logic 1).
● The ECU with the lower identifier continues, while others back off gracefully.
This ensures zero collisions and no wasted bandwidth, while guaranteeing that urgent
messages (like airbags or braking) always get through first.
CAN is known for reliability because it builds error handling right into the protocol:
● Bit Error: Detected when the transmitted bit differs from the bus state.
● Stuff Error: More than five identical bits in a row triggers an error.
● CRC Error: Ensures integrity of the data field.
● Acknowledgment Error: Triggered when no node acknowledges a message.
If a node repeatedly fails, CAN uses fault confinement: the faulty ECU moves into
error-passive or bus-off mode to avoid corrupting communication
Classical CAN served vehicles well for decades, but modern cars with ADAS and
over-the-air updates need more bandwidth. This led to CAN FD (Flexible Data Rate):
● Payload: Up to 64 bytes (vs. 8 bytes in Classical CAN).
● Speed: Arbitration at Classical speed (1 Mbps) but data phase up to 8 Mbps.
● Compatibility: CAN FD nodes can coexist with Classical CAN nodes.
CAN FD is now the default for modern automotive networks, bridging legacy ECUs with
next-gen high-bandwidth needs.
Even with Automotive Ethernet entering cars, CAN isn’t going away — it’s evolving:
● Mixed Networks: Ethernet handles high-bandwidth data (cameras, infotainment),
while CAN manages deterministic control loops.
● Secure CAN: With cars becoming connected, CAN is being extended with
authentication and encryption layers to prevent hacks.
● Lightweight IoT Applications: Beyond cars, CAN is finding use in industrial
automation, robotics, and even medical devices.
The CAN protocol is much more than an old automotive standard — it’s a masterpiece of engineering simplicity. By prioritizing messages, detecting errors instantly, and surviving harsh environments, CAN became the nervous system of modern vehicles. And with CAN FD and secure extensions, it’s not just surviving in the Ethernet age — it’s adapting to power the next generation of connected, autonomous machines.
