August 19, 2026

The controller area network (CAN) bus was originally developed by Bosch in the 1980s for applications in automotive electronics but use cases have expanded to include industrial equipment, agricultural machinery, medical devices, elevators, robotics, marine systems, energy systems and smart mobility devices. CAN continues to be highly relevant thanks to its simple wiring, immunity to interference in electro-mechanically challenging environments, deterministic and priority-based communication, and overall reliability that has been proven for decades. Even in the IoT, cloud and AI era, CAN remains essential for vehicles and machines as their communication backbone.

CAN allows a user to connect with a vehicle or a machine, collect operational data from distributed controllers, bridge legacy field systems to cloud platforms, and support diagnostics control and telemetry. Today CAN is rarely a headline feature in a product, but it continues to be a critical enabler of interoperability, reliability, maintainability, certification readiness and long product lifecycles.

What is CAN bus?
Designed as a multi-master serial communication protocol, CAN bus allows multiple electronic control units (ECUs) or nodes to communicate over the same bus. Instead of having point-to-point wiring between every device, CAN bus allows that all nodes share a common two wire communication bus. Basic characteristics include differential signaling using CAN_H and CAN_L, message based rather than device address-based communication, collision handling via arbitration, high noise immunity and real-time friendly behavior.

The aim of developing CAN bus was to eliminate direct wiring between every component because this is bulky, expensive and hard to troubleshoot. The aim was also to allow efficient but resilient communication. In automotive and industrial systems, vibration, electro-mechanical interference (EMI), electrical noise and temperature extremes need to be controlled while supporting the long operational lifespans of vehicles. CAN bus results in fewer wires, standardized communication, robust fault handling and message prioritization for time-critical functions.

Classic CAN supports data rates of just 1Mbps with a payload of just 8 bytes. CAN Flexible Data rate (FD) supports 5-8Mbps with a payload size up to 64 bytes. This is more than adequate to support sensors, controllers, actuators, displays, telematics units, battery systems and controllers because gateways exchange messages over one shared network. While classic CAN remains common, CAN FD is increasingly being adopted in modern connected systems.

How CAN works
The principles of CAN bus are simple. All devices are connected to the same bus, any node can transmit when the bus is free and messages do not target a device address directly, carrying an identifier that indicates what the message says and its priority. If two nodes start transmitting at the same time, CAN bus uses non-destructive arbitration which allows the higher priority message to continue while the lower priority node waits and retries. This is why CAN bus is so well suited for control systems thanks to ensuring urgent messages such as alarms or braking-related data get through first.

Key technical features include a two-wire differential bus which helps reject common-mode noise and ensures the technology is suitable for harsh environments, multi-master architecture which ensures no single central host is required for every exchange, and message prioritization. In addition, CAN features error detection and fault confinement, high reliability, efficient cabling and standardized physical and data link layers.

A CAN message includes:

• The identifier, which defines the message meaning and priority
• The data field, which carries the payload
• The CRC which checks data integrity
• The ACK which confirms data reception

CAN bus communication is message-centric and distributed across the bus in contrast to Ethernet, which usually routes packets between endpoints. This makes CAN especially suitable for embedded control networks which can support different identifier formats depending on the system complexity.

ODM approaches to CAN
Original device manufacturers (ODMs) continue to support CAN because of the substantial benefits it offers. CAN is well-established and benefits from fast integration into existing ecosystems, so ODM can utilize CAN interface to meet customers’ needs for compatibility with installed equipment. There is also reduced wiring complexity which means fewer interconnects compared with point-to-point designs. A further benefit is high reliability in harsh environments which makes CAN ideal for industrial automotive and outdoor deployments.

In addition to these benefits, CAN bus has long-term component and ecosystem support, a modular systems design, strong diagnostics capabilities and support for retrofit and modernization. There is also significant gateway potential with CAN-to-cloud, CAN-to-Bluetooth Low Energy (BLE) and CAN-to-Modbus options.

CAN bus does have limitations, predominantly in its lower bandwidth and payload limits, especially in the classic CAN variant. In addition, careful bus design is required with interoperability dependent on higher-layer protocol alignment. Debugging can also be difficult without proper tools and message documentation.

Although CAN may not meet the bandwidth demands of high-throughput applications and requires a gateway layer for highly distributed cloud-native messaging, it continues to be a strong solution for many use cases. For systems that require reliable, embedded communication, CAN often remains the best fit.

Why is CAN still relevant in IoT?
Edge devices across IoT still need robust local communication so IoT has not replaced CAN, instead, in many systems, IoT builds on top of CAN. There are still many environments in which reliability matters more than bandwidth, systems are distributed across machines or vehicles and where latency and determinism matter. CAN often acts as the operational network at the edge while IoT connectivity handles external connectivity such as cloud connections, remote diagnostics, fleet management, over-the-air workflows and analytics.

CAN use cases in IoT include:

• Fleet and vehicle telematics where vehicle or subsystem data can be read from the CAN bus
• Industrial equipment monitoring where the CAN connects to controllers, drivers and sensors and gathers machine status and alarms
• Battery management and energy systems in which CAN is used in battery packs, chargers and inverters
• Agricultural machinery where CAN’s robustness and ecosystem maturity is a benefit
• Robotics and automation where CAN supports real-time control and status reporting between subsystems
• Marine and specialty vehicles in which CAN deliver noise-resistant, dependable communication

Far from being an old technology nearing obsolescence, CAN is showing its strength as a mature, trusted and still-growing backbone for embedded communication. Already integrated into many IoT products, CAN is the layer that connects the physical machine, while gateways and cloud platforms create business value on top. ODMs that understand both CAN hardware design and IoT integration can help customers build reliable and scalable products faster, with robust resilience that sets them up for long-life operational cycles.

To find out what CAN is able to do for your IoT devices, visit: https://www.ikotek.com/contact/