A modern car carries dozens of small computers: one for the engine, one for the brakes, others for the airbags, windows, dashboard and climate control. They constantly need to share information. The reason they can do it without a wiring harness the size of a tree trunk goes back to a protocol Bosch presented in 1986: the Controller Area Network, better known as CAN bus.
The wiring problem Bosch set out to solve
By the early 1980s, cars were gaining electronic control units (ECUs) quickly, and each new feature tended to bring its own point-to-point wires. Every extra connection added copper, weight, cost and another connector that could corrode or fail. Bosch began work on a shared serial bus in 1983. In February 1986 it presented the Controller Area Network at the SAE Congress in Detroit.
The idea was simple to describe and hard to engineer: put every ECU on one shared twisted pair of wires and let them all talk, reliably, in a vehicle full of electrical noise from ignition systems, motors and alternators.
Semiconductor makers followed quickly, with the first CAN controller chips from Intel and Philips arriving in 1987. The first production car built around CAN was the 1991 Mercedes-Benz S-Class (W140), and the protocol was standardised internationally as ISO 11898 in 1993.
How CAN bus arbitration works
The feature that made CAN last is how it decides who gets to talk. On most shared buses, if two devices transmit at the same moment, both messages are corrupted and both have to back off and try again. CAN avoids that with non-destructive bitwise arbitration.
Every message starts with an identifier. On the wire, a 0 bit is "dominant" and a 1 bit is "recessive": if any node drives a 0, the whole bus reads 0. While transmitting its identifier, each node listens to the bus at the same time. The moment a node sends a 1 but reads back a 0, it knows a higher-priority message is on the wire, stops sending, and waits to retry.
The result is that the message with the lowest identifier always wins, and it goes through intact with no delay. Nothing is lost and no bandwidth is wasted on collisions. Priority is built into the physics of the bus, which is exactly what you want when a brake message and a seat-heater message happen to start at the same instant.
Differential signalling and built-in error handling
CAN uses two wires, CAN_H and CAN_L, driven as a differential pair and terminated with a 120-ohm resistor at each end of the bus. Noise that hits both wires equally cancels out, because the receiver only looks at the difference between them. That is why CAN copes so well near motors, relays and long cable runs.
The protocol also has error detection built in: a CRC on every frame, acknowledgement bits, bit stuffing checks, and fault confinement that eventually takes a misbehaving node off the bus so one bad board cannot bring down the whole network. Classic CAN runs at up to 1 Mbit/s with up to 8 data bytes per frame; the newer CAN FD, introduced by Bosch in 2012, allows up to 64 bytes and faster data phases.
CAN bus beyond cars: industrial IoT and embedded systems
CAN escaped the car decades ago. You will find it in agricultural and construction machinery, elevators, medical devices, marine electronics, robots and factory automation, often through higher-level protocols such as CANopen and J1939. In the US, CAN has been mandatory on the OBD-II diagnostic port of new cars since the 2008 model year, which is why a cheap OBD-II dongle can read live engine data.
For IoT development, CAN is closer than many people think. The ESP32 includes a CAN-compatible controller (Espressif calls it TWAI), and pairing it with a small transceiver such as the SN65HVD230 is enough to put a Wi-Fi-connected microcontroller on a CAN network. That opens up projects like:
- Fleet telematics: reading vehicle data and forwarding it to a cloud dashboard.
- Industrial monitoring: bridging machines on a CAN network to MQTT for remote alerts.
- Robotics and motor control: coordinating multiple motor drivers over one noise-resistant bus.
- Thesis prototypes: engineering students in the Philippines building vehicle, e-trike or solar-charge monitoring systems.
Designing a CAN-connected device
Getting CAN right is mostly about the physical layer and the firmware. Terminate both ends of the bus and only the ends. Keep stubs short. Use twisted pair. Pick a sensible identifier scheme, since your ID choices are also your priority choices. In firmware, handle bus-off recovery and filter incoming IDs in hardware so the microcontroller is not flooded with frames it does not need.
If you are planning a device that has to live on a CAN network, or bridge one to the cloud, Fluidwire can help with the PCB design, firmware and IoT development services needed to take it from prototype to production. Tell us about your project and we will help you scope it.
Forty years after Bosch showed it in Detroit, the same two-wire idea is still quietly deciding, bit by bit, which message gets to speak first.
Top comments (0)