CAN Bus vs. Ethernet

If you’re new to automotive, CAN (Controller Area Network) may seem like a foreign concept—but if you know anything about ethernet, you probably already know enough to understand CAN.

In this blog, we’ll do a quick comparison of CAN vs. Ethernet and go over some of the strengths and weaknesses of both in the context of automotive systems.

‍

CAN and Ethernet: Why both? 

Both CAN and Ethernet are found in settings such as automotive, medical systems, and industrial automation. They both achieve essentially the same goal: interconnecting different devices and enabling those devices to communicate, and both are layer 1 & 2 network protocols responsible for node-to-node data transfer and error checking. 

Bosch developed CAN in the 1980s specifically to support the growing number of computers in a car. At the time, Ethernet was primarily suited to office and computing environments and was not yet adapted to meet the specific needs of automotive systems. Over the years, however, Ethernet technology evolved, and is becoming more prominent in modern cars, particularly for systems that require higher bandwidth like infotainment systems and advanced driver-assistance systems (ADAS).

While both serve the purpose of facilitating communication between devices within vehicles, there are several key differences that set CAN and Ethernet apart. 

Comparison: When CAN was created, ethernet wasn’t a competitive solution in automotive, which is why a new protocol was needed. Things have changed as we discuss below, which has created a push towards ethernet being used more in cars.

‍

Physical Wire and Data Rates 

CAN: CAN uses a single twisted pair of wires and can operate at speeds up to 1 megabit per second. A newer extension called CAN-FD extends that up to 15 megabits per second. 

Ethernet: Ethernet can also use a single pair of wires, but typically uses four or eight wires instead. Four wires support up to 100 megabits per second and eight wires support all the way up to 10 gigabytes per second. 

Comparison: The number of wires is important in keeping weight and cost down, but less so today than when CAN was first created. Ethernet provides higher speeds, but requires more wires.

‍

Network Flow and Congestion Control

CAN: CAN comes with half-duplex communication and no real congestion control. Half-duplex means that a device can either send or receive, but can’t do both simultaneously. No congestion control means there is no way to manage or mitigate the impact of network traffic congestion once the network’s capacity is exceeded. 

Ethernet: Ethernet supports full-duplex flow control, so devices can both send and receive simultaneously. Ethernet includes superior congestion control, including collision detection and carrier sense multiple access so that devices know when the line is free, and even the ability to ask neighboring devices to pause transmission. 

Comparison: CAN was designed around the idea that devices would all cooperate nicely when trying to communicate compared to ethernet.

‍

Network Addressing 

CAN: CAN uses identifiers that describe the message priority and purpose, but there is no specific identifier for a device. A sender essentially adds a message ID and broadcasts the message on the bus, while receivers filter all bus messages to only those IDs they care about. 

Ethernet: Unlike CAN, ethernet uniquely identifies each device on the network with a MAC address, enabling both broadcast and the ability to directly send data to a specific recipient.

Comparison: Ethernet was designed for devices to talk directly to each other, while CAN was meant more like a publish-to-anyone-who-cares model of communication. 

‍

Prioritization and Quality of Service

CAN: CAN shines when you have short messages and need real-time performance. In CAN, data frames can be up to 8 bytes, with the new CAN-FD extensions allowing up to 64 bytes. The message priority is encoded directly in the message ID field, where lower numerical values correspond to higher priorities. 

That means if two nodes begin communicating at the same time, the node with the lowest identifier has the highest priority and will win the arbitration and continue to send, while the other backs off. 

Ethernet: Ethernet frames, however, can carry a whopping 1500 bytes by default, and even more if jumbo frames are enabled. Prioritization and quality of service is handled through the IEEE 802.1Q extension that introduces VLAN tagging and priority fields in messages. Ethernet can also meet real-time guarantees through the Time Sensitive Networking standard.

Comparison: Overall, CAN messages are relatively short, and that short size minimizes the time each message occupies on the bus and reduces overall delays before other messages can be sent. Ethernet’s larger frames allow each packet to carry more information, which is better for information-heavy services.

‍

Security and Application Development

CAN: CAN requires special network support drivers and libraries on most OSes. On Linux, a popular library choice is the `vcan` kernel module and the SocketCAN library. SocketCan allows applications to send and receive data over a normal unix RAW socket. 

It’s important to note that CAN-oriented development does not assume or typically include the presence of higher-level protocols like TCP/IP, and provides no built-in security, so if you need reliable communication or built-in security features CAN isn’t the best choice. 

Ethernet: Ethernet boasts high interoperability and compatibility across a vast range of operating systems and networking environments. In addition, ethernet assumes the utility and integration with higher level protocols like TCP/IP, and developers typically use those higher level protocols to read and write data rather than dealing with raw ethernet frames directly.

Comparison: Unlike CAN, ethernet supports a wide range of security protocols at various layers, including encryption, authentication, and network access control, and better enables security at the application layer as well. 

‍

CAN vs. Ethernet: TLDR

CAN: CAN provides inherent real-time capabilities with its arbitration and error handling features, making it ideal for low-data-rate, high-reliability environments where immediate response is crucial. These environments typically also use weaker embedded devices with single purpose-built software like deploying an airbag. 

Ethernet: Ethernet has much higher data rates with reasonable real-time performance, making it especially attractive for modern, high-bandwidth services like autonomous driving and infotainment. These environments typically also need faster, modern computers running a full-blow operating system and software stack.

‍

Secure Your Automotive and OT Software

Whether you're using the CAN Bus or you're using an ethernet network, you have to protect the software that runs on top. Mayhem is an application security platform that helps organizations build more reliable software, get better coverage, and find new zero-day vulnerabilities before attackers do. 

Get a demo to learn how Mayhem can help secure your automotive and OT software and comply with regulations like ISO 21434.

‍