Why is CAN still relevant in the automotive industry?

The Controller Area Network (CAN) is a well-established communication protocol widely recognized for its use in automotive and industrial applications. Developed by Bosch in the 1980s, CAN was specifically designed to support real-time control systems, making it an essential technology in automation. Although newer protocols have emerged, it remains a legacy standard that’s integral to many systems.

Over the years, alternatives such as Ethernet, FlexRay, DDS, MQTT, LIN, and MOST have gained traction in the automotive and industrial sectors. Ethernet and FlexRay stand out as the primary competitors to CAN. How does CAN stack up against these modern protocols, and does it still hold relevance in 2024? This article will explore these questions.

What is CAN?

The Controller Area Network (CAN) is a communication protocol designed for real-time data exchange between electronic control units (ECUs) in vehicles and industrial systems. Standardized under ISO 11898, CAN operates as a multi-master serial bus protocol, using a differential serial bus architecture. This design ensures high reliability and noise immunity, which are critical in challenging environments.

The CAN protocol employs a bus topology, linking multiple nodes to a two-wire bus (CAN High and CAN Low), enabling efficient and dependable data transmission.

One advantage of the CAN protocol is its deterministic nature, which ensures that messages are transmitted with predictable timing and priority. This means critical messages are given higher priority, guaranteeing their timely delivery, making CAN an ideal choice for real-time control applications. The protocol use a non-destructive bitwise arbitration mechanism that ensures priority messages are delivered first.

Additionally, CAN includes built-in error detection mechanisms, such as Cyclic Redundancy Check (CRC), to maintain data integrity.

Messages can be transmitted using two-frame formats: the standard frame with an 11-bit identifier and the extended frame with a 29-bit identifier. CAN data rates range from 10 kbps to 1 Mbps, while the more advanced CAN FD (Flexible Data Rate) can achieve data rates of up to 8 Mbps.

Overall, CAN is reliable, deterministic, and scalable, so it’s adaptable for automotive and industrial systems. It’s commonly used in applications that include engine control, chassis systems, transmission control, infotainment, and other real-time communication needs within vehicles. In industrial settings, CAN is employed in programmable logic controllers (PLCs), networked sensors, actuators, and other control devices, adapting to the diverse needs of these systems.

However, while CAN enables real-time machine-to-machine communication in noisy environments, it does have limitations in terms of bandwidth and range. Understanding these limitations is crucial for making informed decisions when choosing a communication protocol.

CAN versus Ethernet

Ethernet is CAN’s main competitor, originally designed for computer networking applications, including local area networks (LANs). As industrial requirements evolved, the need for a communication standard capable of transmitting large volumes of data at higher speeds became apparent, and Ethernet provided a solution.

Compared to CAN, Ethernet offers significantly higher bandwidth and faster data transmission rates, reaching up to 1,000 Mbps. Ethernet also supports larger data frames, allowing more data to be transmitted in a single frame than CAN. While CAN FD can reach data rates up to 8 Mbps, the standard CAN protocol is typically limited to 1 Mbps. Ethernet networks can be configured in various topologies, such as star and bus, while CAN is restricted to a single topology: the bus topology.

Despite Ethernet’s bandwidth, topology flexibility, and frame size advantages, it falls short in some critical regions compared to the CAN protocol. CAN is inherently more reliable due to its multiple error-handling mechanisms, whereas Ethernet’s reliability can be compromised by collisions in shared media.

Additionally, CAN’s deterministic nature — critical for real-time control — is not a given with Ethernet. Ensuring determinism in Ethernet networks requires the implementation of additional technologies like Time-Sensitive Networking (TSN). Deploying an Ethernet network is also more complex and costly.

For most industrial automation applications, CAN is an ideal first choice except when higher data rates or a star topology are required. Ethernet can serve as an alternative when such requirements arise, such as when there’s a need to transmit longer messages or employ a star topology.

CAN versus FlexRay

FlexRay is another significant competitor to the CAN standard, developed for high-speed data communication in automotive applications. FlexRay offers data rates up to 10 Mbps and supports larger data frames, allowing for more information to be transmitted in each frame. Like CAN, FlexRay is deterministic and is designed for time-triggered communication. It also features redundancy to ensure reliable data delivery in safety-critical situations.

While FlexRay provides similar benefits to CAN, including higher data rates and larger frames, it’s more complex and costly to deploy. The protocol uses a dual-channel bus topology compared to CAN’s single-channel approach.

FlexRay is a clear alternative in automotive applications requiring higher data rates or larger frames. However, due to its simplicity, reliability, and cost-effectiveness, CAN is still the preferred choice in most automotive applications and FlexRay’s use in industrial automation remains limited.

CAN versus MOST

The Media Oriented Systems Transport (MOST) protocol is designed specifically for automobile multimedia and infotainment systems. With data rates up to 150 Mbps and support for more extensive data frames, MOST can be deployed in bus and ring topologies.

Although MOST offers real-time data communication capabilities, it has significant drawbacks compared to CAN. While CAN is better for real-time communication and time-critical applications, MOST is suitable for multimedia purposes. It’s not deterministic compared to CAN, and is more complex and costly to implement — which makes sense, since it was developed for synchronization and handling multimedia data.

So, even though MOST has gaining popularity, it cannot replace CAN in most cases. MOST remains confined to multimedia automotive applications and is unsuitable for broader real-time communication needs.

CAN versus. LIN

The Local Interconnect Network (LIN) protocol was developed for low-bandwidth communication within in-vehicle networks. Unlike CAN (which supports higher data rates), LIN operates at data rates between 20 kbps and 100 kbps, with a maximum message length of only 8 bytes. LIN shares the same bus topology as CAN but would benefit from enhanced reliability and determinism.

The primary advantages of LIN are its simplicity and cost-effectiveness, making it a suitable choice for applications where low-bandwidth communication is sufficient and cost is a consideration. However, LIN cannot compete with CAN in terms of performance, reliability, or functionality. LIN is typically only implemented as an expense-cutting measure or to simplify the electronic design of in-vehicle networks where high bandwidth and real-time communication are not essential.

CAN versus MQTT

Message Queuing Telemetry Transport (MQTT) is a lightweight messaging protocol primarily used for device-to-device communication in Internet-of-Things (IoT) networks. Operating on a client-server model with a publish-subscribe mechanism, MQTT is designed for low-bandwidth connections and offers variable message lengths. However, it lacks the real-time capabilities, determinism, and higher data rates the CAN protocol provides.

While MQTT is effective for simple, low-cost communication in IoT applications, it’s unsuitable for applications requiring real-time data transfer or where data integrity is crucial. In contrast, CAN is well-suited for such real-time and time-critical tasks, making it a more reliable option for embedded projects that demand higher performance.

CAN versus DDS

Data Distribution Service (DDS) is a protocol specifically designed for high-performance, real-time data distribution in distributed systems. Like CAN, DDS is deterministic and ensures reliable data exchange through advanced Quality of Service (QoS) features. DDS supports multiple topologies, including request-reply and publish-subscribe, and offers higher data rates and variable message lengths to accommodate different application requirements.

While CAN is typically used in localized systems with homogeneous devices, DDS is more scalable and can be employed in heterogeneous environments. DDS’s advanced features and flexibility make it suitable for more complex, distributed systems, whereas CAN remains a robust choice for real-time communication within localized, homogenous networks.

CAN versus DDS

DDS offers a range of advanced features, particularly for distributed systems. It’s ideally suited to applications like industrial IoT, defense, healthcare, and smart grids. In contrast, CAN remains the go-to standard for smaller-scale industrial automation, automotive systems, and embedded applications.

Although DDS excels in complex, large-scale environments, CAN continues to be the more practical and economical choice for many automation applications where the capabilities of DDS would be excessive.

Why does CAN remain popular?

Protocols like MOST, LIN, and MQTT serve specific niches that complement rather than replace CAN in many applications. Ethernet and FlexRay are viable alternatives, but only when higher data rates or larger data frames are required. DDS, with its specialized design, is best suited for distributed systems.

Despite the advancements of these other protocols, CAN continues to prevail in automotive and localized industrial applications as the ideal solution for cost-effective, real-time machine-to-machine communication.

Getting started with CAN

The CAN protocol continues to be widely used in automotive, industrial automation, and embedded applications. If you’re interested in exploring CAN, simple projects using Arduino are one way to get hands-on experience. For example, try setting up data communication between two Arduino boards over the CAN protocol to experience its functionality.