Executive Summary

Controller Area Network (CAN) and Automotive Ethernet are two pivotal in-vehicle networking technologies with distinct strengths. CAN, standardized as ISO 11898, has served as the backbone of automotive electronics for decades, enabling reliable, real-time communication between Electronic Control Units (ECUs) at low cost. However, its maximum bandwidth (1 Mbps for Classical CAN, up to ~5 Mbps in CAN FD) and small frame payloads limit its ability to handle the data surge from modern features. Automotive Ethernet, built on the IEEE 802.3 standards adapted for vehicles, offers vastly higher data rates (100 Mbps to multi-gigabit) and a scalable switched architecture to meet the needs of high-resolution sensors, rich infotainment, and advanced driver-assistance systems (ADAS). With Ethernet’s superior speed and support for precise timing (via Time-Sensitive Networking), it is emerging as the backbone for next-generation vehicles, enabling functions only imagined with CAN.

Both technologies will coexist in the foreseeable future, each applied where it fits best. CAN’s deterministic priority-based bus arbitration and built-in error handling make it ideal for powertrain, chassis, and safety-critical control networks that require timely and fail-safe message delivery at low cost. Automotive Ethernet, on the other hand, is being adopted for high-bandwidth domains like surround-view camera systems, radar/LiDAR sensor fusion, connected infotainment, and over-the-air updates. The shift is driven by evolving needs such as autonomous driving and software-defined vehicles – features that demand gigabits of data and precise synchronization across ECUs, which CAN cannot support. Early deployments (e.g. BMW’s use of 100 Mbps Ethernet in the 2013 X5 for camera data) have proven the concept, and today virtually all major OEMs are part of the OPEN Alliance to standardize automotive Ethernet. At the same time, enhancements to CAN (CAN FD and the upcoming CAN XL up to 10 Mbps) are extending its lifespan for mid-speed applications.

In summary, CAN and Automotive Ethernet serve complementary roles in modern E/E (electrical/electronic) architectures. CAN provides robust, low-latency control for many traditional vehicle systems, while Ethernet delivers the bandwidth and flexibility for data-intensive and future-oriented applications. This report provides an in-depth comparison of the two technologies across their architecture, performance, reliability, network topology, power profile, cost, and use cases, highlighting how emerging trends like ADAS and zonal architectures are influencing network design choices.

Automotive Ethernet

Explore the latest advancements in Automotive Ethernet with this fully revised third edition, now featuring 20% new content and deeper technical insights. This edition expands coverage to include in-depth explanations of cutting-edge PHY technologies such as 10BASE-T1S (including multidrop capabilities), as well as 2.5G, 5G, and 10GBASE-T1. It also introduces comprehensive discussions on EMC interference models and the latest Time-Sensitive Networking (TSN) standards tailored for automotive applications.

Learn about modern security concepts, energy-efficient design strategies, and how functional safety requirements are addressed within Automotive Ethernet systems. The book also provides a valuable overview of testing strategies, key implementation lessons, and real-world insights from industry pioneers who have successfully navigated the technical and organizational challenges of deploying this transformative technology.

From electromagnetic compliance and physical layer design to quality of service, VLAN usage, IP-based protocols, service discovery, and overall network architecture—this guide covers it all. Ideal for engineers, technical managers, and researchers working on in-vehicle electronics, as well as professionals involved in the strategic rollout of new automotive technologies. More information…

Architecture and Protocol Design

CAN Bus Architecture: CAN is a multi-master serial bus architecture where all nodes share a two-wire differential bus (CAN_H and CAN_L). The high-speed physical layer (ISO 11898-2) uses a linear bus terminated at both ends with 120 Ω resistors, ensuring signal integrity over a twisted pair. Frames are broadcast to all nodes, identified by an 11-bit or 29-bit message ID that also serves as a priority field for bus arbitration. CAN communication is message-oriented (content identified by ID rather than destination addressing) and operates on a wired-AND logic – any node can transmit if the bus is free, but if two nodes transmit simultaneously, the one sending the higher-priority (lower ID value) frame will win arbitration bit-by-bit without collision. This deterministic arbitration mechanism (defined in ISO 11898-1 data link layer) ensures critical messages get through with minimal delay and no frame corruption. Classic CAN frames carry up to 8 bytes of data, whereas CAN FD (Flexible Data Rate) extends this to 64 bytes and allows a higher bit rate during the data phase for faster payload transmission. Despite these upgrades, the fundamental architecture remains a shared bus – simple and efficient for moderate data loads, but with inherent bandwidth sharing among all ECUs on the bus.

Automotive Ethernet Architecture: Automotive Ethernet refers to a family of Ethernet-based networks tailored for vehicles, using the standard IEEE 802.3 protocols with modifications at the physical layer for automotive conditions. Unlike CAN’s single shared bus, Ethernet uses a point-to-point link topology with full-duplex communication. Each ECU (or domain controller) connects to an Ethernet switch (or multiple switches in a cascaded/star topology) via a dedicated twisted-pair cable (for automotive, usually a single twisted pair is used per link). This switched architecture means multiple transmissions can occur simultaneously on different links, dramatically increasing aggregate bandwidth. Higher protocol layers (TCP/IP, UDP, SOME/IP, etc.) can run on Ethernet, but even at the data link layer, Ethernet frames include source and destination MAC addresses, allowing unicast, multicast, or broadcast addressing of specific nodes – a different paradigm from CAN’s broadcast-only medium. Automotive Ethernet PHYs (physical layers) are designed to be lightweight: for example, 100BASE-T1 (IEEE 802.3bw) and 1000BASE-T1 (IEEE 802.3bp) achieve 100 Mb/s and 1 Gb/s respectively over a single unshielded twisted pair, using specialized encoding to withstand the automotive electromagnetic interference (EMI) environment. These PHYs support only 15 m cable lengths (typical for in-car runs) and operate full-duplex, which eliminates collisions and the need for CSMA/CD on the link. Overall, the Ethernet protocol stack is more complex – it spans the OSI layers, offering features like packet switching, routing, and rich protocol support, which enable gateway ECUs to interface the in-vehicle network with external networks (e.g. internet, diagnostic tools) seamlessly.

Protocol Design Considerations: The simplicity of CAN’s protocol (no explicit node addresses in frames, small payloads, and hardware-managed arbitration) makes it highly efficient for real-time control messaging with minimal software overhead. Every CAN node typically includes a controller that automatically handles bit-level arbitration, error detection, and acknowledgement, offloading these tasks from the CPU. In contrast, Ethernet’s design offloads less to hardware beyond the MAC layer: frames are larger (up to 1500 bytes payload for standard Ethernet, or even larger if using Automotive Ethernet with VLAN tags or jumbo frames) and frame forwarding/routing introduces latency that must be managed with switch QoS settings for time-critical data. However, Ethernet’s design allows mixing of traffic types on one network – for instance, video streams, sensor data, and diagnostics can all coexist, distinguished by higher-layer protocols or VLANs. This gives automotive Ethernet immense flexibility. It leverages widespread IT and industrial standards, meaning automotive engineers can use existing IP-based protocols (like UDP/IP for diagnostics, or audio-video bridging for infotainment) on the vehicle network. In summary, CAN’s protocol design favors real-time control and simplicity (purpose-built for in-vehicle control networks), whereas Ethernet’s design favors universality and scalability, at the cost of higher complexity in managing the network.

Communication Speed and Bandwidth

Bandwidth and Data Rate: One of the starkest differences between CAN and Ethernet is in achievable data rate. Classical CAN (CAN 2.0) supports bit rates up to 1 Mbit/s on high-speed networks (ISO 11898-2), though in practice many powertrain and body CAN buses run at 500 kbps or less to accommodate longer cable lengths and more nodes. CAN FD extends this by allowing a higher bit rate in the data portion of the frame – commonly up to 2 Mbps, and in some implementations 5 Mbps or more on short buses. Emerging CAN XL technology targets up to 10 Mbps with larger frame sizes for future needs. Even so, CAN’s bandwidth is several orders of magnitude lower than automotive Ethernet. Automotive Ethernet standards today begin at 100 Mbps (100BASE-T1) and reach 1 Gbps (1000BASE-T1) on a single twisted pair. High-speed variants like 2.5G, 5G, and 10G Ethernet (802.3ch MultiGBASE-T1) have been standardized for automotive, delivering up to 10 Gbps over shielded twisted pairs. In the lab, even 25–50 Gbps automotive Ethernet solutions are being explored to future-proof for autonomous vehicle data loads. Thus, in raw bit rate, Ethernet utterly eclipses CAN (for example, 10 Gbps vs. 1 0.01 Gbps for CAN-XL).

Effective Throughput: The effective application-layer throughput also differs because of frame payload sizes and protocol overhead. A classical CAN frame carries at most 8 bytes of data, so the protocol efficiency is modest (a significant portion of the 1 Mbps is spent on frame headers, CRC, bit stuffing, inter-frame spacing, etc.). CAN FD improves efficiency with up to 64 bytes of user data per frame, but even at 5 Mbps its throughput is on the order of a few hundred kilobytes per second. In contrast, a single 100 Mbps Ethernet link can carry ~95 Mb/s of payload (over 10 MB/s) after overhead, and 1 Gbps links about 950 Mb/s (~100+ MB/s) – three orders of magnitude higher than CAN. Moreover, because Ethernet in a car uses switches, aggregate bandwidth scales with the number of links and switching capacity. Every point-to-point Ethernet link runs at full speed simultaneously, so the network’s total data capacity can be the sum of all link capacities. For instance, a car might have multiple 100 Mbps camera links feeding into a gigabit backbone – something impossible with a single CAN bus. By contrast, all nodes on a CAN bus share the one bus bandwidth; adding more devices or more messages will proportionally consume the limited 1 Mbps resource. This is why CAN is suitable for short, low-frequency control messages, but not for high-volume data. High-bandwidth payloads (e.g. video, high-resolution radar data, or rich diagnostics) must be transported over Ethernet or specialized high-speed links. In fact, automotive Ethernet’s introduction was largely motivated by the bandwidth needs of modern vehicles – for example, surround-view camera systems streaming video to a parking assist ECU, or an infotainment system transmitting high-fidelity audio and internet data.

Comparison: In summary, CAN’s communication speed is limited (1 Mbps classic, up to a few Mbps with newer extensions), making it suitable for signals like engine RPM, temperatures, sensor statuses, and command messages that come at low rates (e.g. 10–100 Hz). Automotive Ethernet provides 100–1000× more bandwidth, supporting real-time transfer of large data streams such as camera images, over-the-air software updates, and consolidated sensor fusion data. This bandwidth headroom is critical as vehicles evolve with more sensors and data-centric functions. For example, the data from a single forward-looking camera (several Mbps of compressed video) or a lidar point cloud can easily overwhelm a CAN bus but fits comfortably on a 100 Mbps or 1 Gbps Ethernet link. Even multiple HD camera feeds can coexist on a gigabit Ethernet backbone via switching. However, the higher bandwidth comes at a cost of larger frame size and potential latency if not managed (discussed next), whereas CAN’s tiny frames inherently keep latency low for small periodic messages. Engineers must carefully partition what traffic goes on CAN versus Ethernet to balance these trade-offs.

AUTOMOTIVE ETHERNET – THE DEFINITIVE GUIDE

Ethernet—long established as the world’s most widely used local area networking technology—has transitioned from the data centers of OEMs to the very heart of modern vehicles. As the number and complexity of in-vehicle electronic systems continue to grow, Automotive Ethernet has emerged as a robust, scalable solution for high-speed, real-time communication.

Automotive Ethernet – The Definitive Guide delivers comprehensive coverage of the physical layers, protocols, and standards that define Ethernet’s role in automotive networks. This authoritative resource explores key topics such as:

Automotive electromagnetic, environmental, and electrical design requirements
OSI Reference Model and network fundamentals
IEEE Project 802 structure and relevant working groups
Ethernet Physical and MAC layers, including 100BASE-T1, 1000BASE-T1, MultiGBASE-T1, 10BASE-T1S, and others
MAC addressing, frame formats, and associated hardware
Comparisons with legacy automotive networks (CAN, CAN FD, LIN, MOST, FlexRay)
Full TCP/IP protocol suite including IPv4/IPv6, ARP, ICMP, NAT, TCP, UDP, DoIP, and SOME/IP
Media transport protocols including Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN)

This book is a must-have reference for electronics engineers, network architects, test and validation professionals, and automotive developers seeking to understand and implement Ethernet in vehicle systems. It also serves as a vital resource for Ethernet hardware designers and software developers interested in how automotive requirements shape Ethernet’s application and evolution. More information…

Latency and Determinism

CAN Latency and Determinism: CAN was explicitly designed for real-time control, offering very predictable timing for message delivery. Its determinism comes from the fixed-priority arbitration scheme – a message with the highest priority ID will gain bus access as soon as the bus becomes idle, preempting lower priorities without collision. Arbitration is resolved bit-by-bit in microseconds, and the winning message continues without retransmission, which means no bandwidth is wasted. This yields low and bounded latency for high-priority messages even under heavy network load. In practice, engineers can compute the worst-case response time for a CAN message using scheduling analysis, and by assigning message IDs carefully, ensure critical signals (like airbag triggers or engine torque requests) always meet their deadlines. Typical CAN propagation delay for an 8-byte frame at 500 kbps is on the order of 0.2 ms (transmission time) plus a few bit times of arbitration. At 1 Mbps, an 8-byte frame takes only ~0.1 ms on the wire. Jitter can occur if a lower-priority frame is in progress, causing a high-priority frame to wait until the bus is free; however, CAN frames are short, so this delay is limited (worst-case ~135 µs at 1 Mbps for a standard frame). Importantly, there is no uncertain back-off time as in Ethernet’s classical CSMA/CD – collisions are avoided by design. As long as the bus is not overloaded (typically kept < 80% utilization in design), CAN delivers consistent low latency. For this reason, CAN networks easily handle tasks like closing a control loop at 100 Hz or sending a critical shutoff command with millisecond-level latency. In fact, CAN’s real-time performance is one reason it remains used in safety-critical applications like brake control, where deterministic and predictable message timing is crucial.

Ethernet Latency and Determinism: Standard Ethernet (without special provisions) was not originally deterministic. In old shared Ethernet (half-duplex with CSMA/CD), collisions caused random exponential back-off delays, making worst-case latency unbounded – entirely unacceptable for real-time automotive use. However, modern automotive Ethernet uses full-duplex links and switches, so collisions are eliminated at the link level. This means that on each link, when an ECU sends a frame, it does not collide with incoming traffic; and a switch will queue and forward frames without contention on the wire. Determinism then depends on switch buffering and scheduling. A large frame (e.g. 1500 B) can occupy a 100 Mbps link for ~120 µs, during which a high-priority frame might wait unless the switch hardware or protocols prioritize it. To address real-time requirements, the industry has embraced Time-Sensitive Networking (TSN) extensions to Ethernet. Standards such as IEEE 802.1Qav (credit-based shaping), 802.1Qbv (time-aware scheduler), and 802.1AS (precision time synchronization) allow Ethernet networks to provide bounded low latency and jitter for critical traffic. In essence, TSN can reserve time slots or guaranteed bandwidth for certain message streams, much like a scheduled TDMA bus, while still carrying non-critical traffic in other slots. Automotive profiles of TSN (sometimes called “AVB” for audio-video bridging, or simply TSN for control traffic) are being deployed so that Ethernet can meet the strict latency needs of steering, braking, and other real-time control previously on CAN. For example, an Ethernet-based domain control network might guarantee delivery of a brake command within 100 µs end-to-end, by using a time-triggered schedule and high-priority class for that message.

In practice, raw Ethernet latency on a single link can be very low – a minimum size frame at gigabit speed is only a few microseconds on the wire. The propagation delay on typical cable lengths (< 15 m) is negligible (~0.05 µs/m). So the physical layer is fast; the variability comes from queueing and packetization. A comparison: a 50% loaded 100BASE-T1 Ethernet link might incur a few hundred microseconds of latency for a frame to get through, similar to CAN’s magnitude. But under certain conditions (e.g. bursts of large frames), an unscheduled Ethernet network could see latency in milliseconds, which is why deterministic Ethernet techniques are employed for critical signals. With TSN, Ethernet can be made as deterministic as or even superior to CAN in latency for scheduled traffic. For instance, an 802.1Qbv schedule could send a 16-byte high-priority frame every 100 µs with near-zero jitter, something CAN cannot do once its bit rate limit is reached.

Real-Time Capability: CAN’s built-in prioritization gives it a natural advantage in simple real-time control loops – there’s hardware-enforced timing and no need for global time sync for basic arbitration. Ethernet requires additional protocol layers to achieve a comparable level of timing assurance. However, those additions (TSN) are now standardized and being built into automotive Ethernet switches and controllers. Many automakers are already using Ethernet for time-critical functions like digital instrument clusters and ADAS sensor fusion, leveraging TSN to ensure low latency updates. In summary, CAN provides determinism by design (event-triggered but priority-driven), whereas Ethernet provides determinism by configuration (time-triggered or priority-shaping through TSN). For current vehicles, critical fail-safe functions (e.g. ABS, steering) often still rely on CAN or FlexRay because of their proven deterministic behavior. Going forward, with Ethernet + TSN technology maturing, it’s feasible that even these functions move to Ethernet backbones with robust scheduling. An example of latency requirements: autonomous driving systems may require certain sensor or actuator data to be delivered within under 1 ms worst-case. CAN would struggle with this if the network is busy or if payloads are large, whereas a gigabit Ethernet with proper QoS can handle multiple such real-time streams simultaneously. Automotive Ethernet thus closes the gap on determinism, enabling the convergence of networks – but it demands careful design and testing to guarantee those real-time properties, something automotive engineers must account for.

Error Handling and Reliability

CAN Error Handling: Reliability has been a hallmark of CAN networks, thanks to comprehensive error detection and fault confinement built into the protocol. Every CAN frame includes a 15-bit CRC and bit-stuffing rules for error detection, and receivers send an acknowledgement bit to confirm a frame was received correctly. If a CAN node detects any form of error (CRC mismatch, format error, bit error, missing ACK, etc.), it immediately transmits an Error Frame – a special sequence that violates the bit stuffing rule and causes all other nodes to detect an error. This error flag disrupts the ongoing transmission (effectively discarding the faulty frame) and notifies all nodes that an error occurred. The transmitter will then automatically retry the message once the bus returns to idle, without higher-level intervention. Each CAN controller maintains internal error counters that increment on transmit or receive errors; if faults persist, nodes transition into error-passive mode (where they stop sending active error flags) and eventually bus-off state, removing themselves from the bus. This mechanism ensures that a malfunctioning node (for example, one with a stuck transmitter or bad hardware causing errors) will effectively shut itself down before it can monopolize or incapacitate the network. The result is a robust network where occasional errors (due to noise, etc.) are detected and frames retried, and serious faults isolate themselves. Additionally, CAN’s differential signaling and limited speed make it resilient to EMI – any noise affecting one line should affect both similarly, so the differential voltage (which carries the signal) remains mostly immune. In low-speed fault-tolerant CAN (ISO 11898-3), if one of the two wires breaks or short-circuits, communication can continue on the remaining single wire (at a reduced speed), which adds to reliability in harsh environments. These features explain why CAN is trusted in powertrain and safety systems where fault detection and containment must be automatic and immediate.

Ethernet Error Handling: Standard Ethernet has simpler error handling at the frame level. Each Ethernet frame carries a 32-bit Frame Check Sequence (FCS) at the end for error detection (CRC-32). If a receiving node (or switch) computes a different CRC than what’s in the frame, the frame is considered corrupted and is silently dropped; it is not delivered to higher layers. There is no built-in automatic retransmission at the Ethernet layer – reliability, if needed, is handled by higher-level protocols like TCP (which will retransmit lost packets) or application-layer logic. This means that raw Ethernet frames are not guaranteed to arrive; however, in controlled automotive Ethernet networks, the error rates on physical links are extremely low when cables and transceivers are within spec. Ethernet links have link-level diagnostics (like continuous idle code transmission, link beat, etc.) that can detect if a link is down or experiencing excessive errors, but they do not have a notion of an “error frame” akin to CAN. If an ECU’s Ethernet interface fails and starts transmitting gibberish, a switch may detect malformed frames or lost link integrity and could shut that port down, but this is vendor-specific behavior rather than part of the Ethernet protocol. Error confinement is thus less intrinsic in Ethernet – one misbehaving device might flood the network with useless traffic unless higher-level safeguards (e.g. network management software or switch rules) intervene. From a reliability standpoint, Ethernet relies on its much higher bandwidth to tolerate some retransmissions (e.g. TCP can recover lost data quickly on a fast link) and on network design (topology) to mitigate faults. For instance, a star topology means a short-circuit on one link typically doesn’t affect others, whereas on a CAN bus a short on the bus can bring down the whole network unless special transceivers are used. Automotive Ethernet transceivers are designed with robust EMC performance and self-diagnostics (many are AEC-Q100 qualified and meet ISO 16750-4 for electrical robustness), but fundamentally, an Ethernet frame will either get through intact or be dropped with no immediate feedback to the sender.

Reliability and Redundancy: In safety-critical systems, redundant networks are often used to tolerate failures. CAN has seen implementations of dual-redundant buses (particularly in aerospace or high-end automotive for x-by-wire systems) – if one CAN bus fails, the backup can take over, with identical messages sent on both. Ethernet similarly can implement redundancy: e.g., some vehicles may use two Ethernet backbones in parallel, or use protocols like HSR (High-availability Seamless Redundancy) and PRP (Parallel Redundancy Protocol) known from industrial networking to send duplicate frames over two paths. These are not yet common in mainstream cars, but as Ethernet starts to carry more safety-critical traffic, such concepts are being adopted in automotive standards. Another aspect of reliability is how each handles bus utilization: a heavily loaded CAN bus (near 100% utilization) will start dropping frames (any node that loses arbitration or sees the bus busy will have to retry, and lower-priority messages may get starved). Ethernet, due to its bandwidth, can typically run at lower utilization fractions for critical traffic, and switches can buffer bursts. That said, an overloaded Ethernet switch queue will also drop packets (similar to internet routers dropping packets on overflow), so network scheduling is important.

Summary of Reliability: CAN’s approach is proactive – detect error, flag it, retry automatically, and isolate the fault if it’s persistent. This contributes to high reliability in the noisy automotive environment, with error rates as low as 1 in 10^–11 bits typically handled gracefully. Ethernet’s approach is to detect and discard errors at the lowest level and rely on system design for any recovery. This is acceptable for non-critical data or where upper layers (like a control algorithm that can handle a missed sensor update) provide tolerance. As vehicles move to Ethernet networks, additional protocols are layered to mimic some of CAN’s reliability – for example, a diagnostic message over UDP on Ethernet might implement its own acknowledgment or sequence count to ensure it isn’t missed. In terms of cybersecurity, neither CAN nor Ethernet was originally secure (CAN has no authentication – any node on the bus can transmit anything – and Ethernet assumes a relatively open environment unless measures like MACsec or IPsec are added). Modern automotive networks incorporate security at higher layers (AUTOSAR Secure Onboard Communication for CAN, and firewalls/intrusion detection or MACsec for Ethernet) but that’s beyond the basic protocol. Notably, Ethernet’s ubiquity means it can leverage proven IT security mechanisms (as one expert put it, “automotive Ethernet can provide accurate timing [IEEE 802.1AS], security [MACsec], and guaranteed delivery [TSN] needed for future vehicles”) whereas securing CAN often requires bolt-on software solutions due to CAN’s limited bandwidth and frame format.

Topology and Scalability

CAN Network Topology: CAN networks traditionally use a bus topology – a single linear bus cable with termination at both ends, and every node’s transceiver connecting to this common line. All nodes see all traffic, using the CAN ID filtering to pick out messages intended for them. This topology is simple but does impose limits: the bus length and number of nodes are constrained by electrical capacitance and signal timing (for example, at 1 Mbps, a typical maximum bus length might be on the order of 40 m with on the order of 30 nodes; slower CAN networks can be longer and support more nodes). Star topologies are generally discouraged for high-speed CAN because splitting the bus can cause signal reflections; however, low-speed CAN (ISO 11898-3) can use star or multiple-star topologies since it has special fault-tolerant transceivers and operates at lower bit rates (125 kbps or below). In practice, a vehicle uses multiple CAN buses to manage different domains – for instance, an engine powertrain CAN, a chassis CAN, a body CAN for comfort electronics, etc. These are connected by gateway ECUs that bridge messages between buses. This multi-bus approach is scalable to an extent, but as the number of ECUs in cars grew (often 50+ ECUs), wiring multiple separate CAN buses became complex to manage. Each additional CAN bus adds wiring and a port on the gateway, and some signals that need to be shared broadly (e.g. vehicle speed) might be repeated on several CAN buses via the gateway, which is bandwidth-inefficient. Still, scaling CAN networks meant adding more parallel buses – a fairly coarse scalability. Each individual CAN bus remains limited in node count and bandwidth, so engineers allocate ECUs to buses such that no bus is overloaded.

Ethernet Network Topology: Automotive Ethernet uses a star or star-of-stars topology anchored by one or more Ethernet switches. Each switch port connects via a point-to-point twisted pair to one ECU. This means any given link is just between two devices (ECU-to-switch or switch-to-switch), which isolates physical layer issues and simplifies wiring for complex connectivity. A single central switch can connect many devices (typical automotive Ethernet switches have 4–8 ports, and high-end ones up to 16 or more). For larger networks, switches can be cascaded or arranged in multiple star clusters connected by an Ethernet backbone link. This topology is highly scalable – adding a new Ethernet ECU may only require running a new cable to a switch and perhaps adding a bigger switch or an extra switch if ports run out. There is theoretically no strict limit to the number of nodes in an Ethernet network, as MAC addressing supports millions of devices, though practical limits are set by switch sizes and network management. The point-to-point nature also means a cable failure usually only disconnects that one node rather than bringing down the whole network (which is a clear advantage over a single-bus CAN). On the other hand, the reliance on switches means the network has active elements – the switches – that must themselves be reliable and are single points of potential failure for the nodes connected to them (mitigated by using multiple switches or redundant paths in critical systems).

Scalability Considerations: In terms of bandwidth scaling, CAN is confined to one channel – adding more traffic will increase latency and approach a hard throughput ceiling ~ at 100% bus load (which is generally avoided). Ethernet, by contrast, can handle multiple concurrent communications. For example, a 1 Gbps Ethernet network could be simultaneously streaming a 1080p video from a camera to an ECU (maybe 100 Mbps), sending diagnostics to a service tool (some kbps), and carrying real-time control data (a few Mbps reserved via TSN), and still have ample capacity left. Additionally, as more sensors and actuators are added for autonomous driving, Ethernet networks can be segmented with VLANs or separate switches such that high-bandwidth domains don’t flood low-bandwidth ones. This fine-grained scalability is a big attraction of Ethernet. A notable development is the concept of zonal architectures: instead of many separate CAN networks for each function, future cars are moving to a layout where each physical zone of the car (front, rear, cabin, etc.) has a local hub (zonal ECU) connecting to devices in that zone via short CAN/LIN links, and all those zonal hubs tie into a central Ethernet backbone. This significantly reduces the length and complexity of wiring harnesses and scales the network in a structured way. Ethernet as a backbone makes this possible, as it can carry data for all domains over a unified network with proper scheduling. In contrast, trying to centralize all communication on CAN would be impossible bandwidth-wise.

Network Size and Nodes: A single CAN bus might practically support on the order of 20–30 ECUs before issues arise (and only a handful can talk at high frequency without saturating the bus). Ethernet networks can easily support dozens of ECUs on one switch or cascaded switches, limited mainly by cost and required bandwidth. For instance, a luxury car might have 10+ Ethernet ECUs (cameras, LIDARs, radar modules, central computer, cluster, etc.) on a Gigabit Ethernet network. Some electric vehicles have reportedly moved nearly all ECUs onto Ethernet – e.g. Tesla uses automotive Ethernet to interconnect all its ECUs, essentially replacing traditional CAN for most in-car communications. That showcases the scalability and topology flexibility: Tesla’s architecture can be like a web of switches and links rather than dozens of separate CAN buses. However, most manufacturers still use a hybrid: multiple CAN buses for less data-intensive zones and an Ethernet network for the heavy data. The scalability advantage of Ethernet is also evident in software terms: Ethernet supports common networking protocols (IP, service discovery, etc.) which scale to large networks, making it easier to manage a growing number of devices and functions via standard tools. CAN requires more manual configuration as the network grows (like ensuring no two nodes use the same message ID, bus loading calculations for each new message, etc.). In short, CAN’s topology is inherently limited but simple, whereas Ethernet’s topology is highly scalable but needs more planning (switch configuration, network architecture design) as it scales up.

Power Consumption

Node Power Usage: CAN and Ethernet transceivers differ significantly in complexity and speed, which affects their power consumption. A typical high-speed CAN transceiver (operating at 5V supply) consumes only a few tens of milliwatts when active and much less in standby. Moreover, only one CAN node actively drives the bus at a time (the one transmitting), while all others are just receivers, which is an energy-efficient scheme for a lightly utilized bus. Many CAN controllers also support sleep modes and wake-up patterns – for example, body control modules can go to low-power sleep and wake up only when a specific CAN frame (or even a specific wake-up pattern in newer CAN transceivers) is seen on the bus. This means that CAN networks can be kept mostly quiescent when the vehicle is off, only waking periodically or on certain events, minimizing battery drain. In contrast, an automotive Ethernet PHY (especially 100 Mbps or 1 Gbps) is more complex – it continuously drives the link with encoded symbols even when no data is being sent (for link maintenance), and the clock rates are much higher (tens of MHz for 100BASE-T1, 125 MHz symbol rate; hundreds of MHz for Gigabit). This results in higher baseline power usage. A 100BASE-T1 transceiver might consume on the order of 100 mW or more, and a gigabit transceiver a few hundred mW, not including the switch’s power usage. Ethernet switches (the active components in the network) also consume power per port for PHY and switching logic, which adds to the total.

Comparative Studies: Research comparing energy consumption of CAN vs Ethernet has shown CAN’s clear advantage for low data rates. In one study, a standard Ethernet controller was found to consume 2.5× more power than a CAN controller under comparable conditions, even when using Energy Efficient Ethernet (EEE) features. FlexRay (another automotive network at 10 Mbps) had power usage closer to Ethernet, whereas CAN was the lowest. The same study noted that an Energy Efficient Ethernet (EEE) mode – which allows an Ethernet PHY to go into a low-power idle state between frame bursts – can reduce Ethernet power, but even then it was similar to FlexRay and still significantly above CAN’s consumption. In practical terms, a CAN bus interface might draw only a few mA when active, whereas a 100BASE-T1 Ethernet PHY might draw tens of mA. Over tens of ECUs, this difference can matter, especially in an electric vehicle where every watt of continuous draw affects range when the car is off. Automotive Ethernet is addressing this: modern PHYs do support low-power standby modes, and wake-on-LAN capability (where an ECU or switch port can power down and only wake the MAC upon detecting a specific wake-up packet). Standards like IEEE 802.3az (Energy Efficient Ethernet) are crucial here – they introduce low-power idle, though the trade-off is added latency when waking the link. CAN, by virtue of being slower, inherently uses less dynamic power; its transceivers often have analog filtering and don’t require high-speed DSP or echo cancellation that Ethernet PHYs do.

Network-Level Power Considerations: The topology influences power as well. In a CAN bus, if no node is transmitting, the bus is in recessive state and virtually no differential voltage is being driven – the transceivers are mostly idle. On an Ethernet network, the switches are typically always on, and each link continuously sends idle symbols to maintain link synchronization. Thus a fully Ethernet-based network might have a higher base power draw even when no application data is being exchanged. Automakers manage this by turning off certain network segments when not needed. For example, an Ethernet camera and its link might be off until the ADAS system requests camera data. CAN also allows segments to be powered down (via gateway logic isolating parts of the network), but more often CAN nodes themselves decide to sleep. Another factor is wake-up time – CAN nodes can wake almost instantaneously upon bus activity, whereas an Ethernet PHY might need a few milliseconds to renegotiate a link if it was completely powered down. To mitigate battery drain in parked cars, designs often use a dual-network strategy: a low-power bus (like LIN or a low-speed CAN) remains active to listen for key-on or remote unlock events, while the main Ethernet backbone stays off until needed. This way, the high-power Ethernet parts are off most of the time when the vehicle is not running.

In summary, CAN is very efficient in power usage for the amount of data it delivers, making it suitable for always-on networks (e.g. security systems, sensor monitoring while the vehicle is off). Ethernet consumes more power due to high-frequency electronics and continuous communication requirements, but techniques like EEE and careful network power management are narrowing the gap. Still, from a systems perspective, a car with dozens of Ethernet links must account for a higher electrical load. This is an implicit cost of meeting the bandwidth demands. In an EV, for instance, engineers might calculate how an all-Ethernet architecture affects the 12V battery cycling. It’s worth noting that for high-bandwidth needs, the energy per bit might actually favor Ethernet – sending 1 MB of data over CAN (which could take many seconds and a lot of ECU active time) might use more total energy than sending the same 1 MB in a fraction of a second over Ethernet. But for routine control messaging, CAN’s tiny data payloads are delivered with minimal energy. Each technology is thus optimal in a different regime: CAN for low data rates at minimal power, Ethernet for huge data transfers at acceptable power efficiency but higher fixed overhead.

Cost Implications

Component and Node Cost: Cost is a critical factor in automotive design. CAN has long been valued for its low cost per node. A CAN controller is often integrated into microcontrollers (many automotive MCUs come with one or more CAN ports on-chip), and high-volume CAN transceiver chips can cost on the order of $0.50 to $1 in bulk. The wiring for CAN is just a simple twisted pair, often unshielded, with relatively low requirements (no high-speed connectors or precise impedance matching beyond the termination resistors). Overall, adding an ECU onto a CAN bus has minimal cost impact. Automotive Ethernet nodes are more expensive, mainly because of the required PHY and (in many cases) higher-performance MCUs or switches. An ECU with Ethernet needs a dedicated PHY chip (or a more complex System-on-Chip that includes one) for 100BASE-T1 or 1000BASE-T1, plus magnetics or coupling capacitors for the interface. Ethernet PHYs in automotive grade might be a few dollars each – several times a CAN transceiver cost. Additionally, the ECU’s processor might need to handle Ethernet frame buffering and the TCP/IP stack, which can necessitate more memory and processing power, indirectly raising the cost. As Texas Instruments noted, “Ethernet would be an ideal choice to replace CAN bus, but Ethernet’s cost per node is higher, so it will augment rather than fully replace CAN” in cost-sensitive applications. This is exactly what we see: critical low-speed functions remain on CAN to avoid burdening them with the cost of Ethernet hardware.

Infrastructure and Tooling Cost: Beyond the ECU, network infrastructure costs differ. CAN requires no active infrastructure component; the bus itself is just wiring. In contrast, a purely Ethernet network requires one or more switches, which are active devices adding cost. A switch with multiple ports could be a dedicated chip (there are automotive Ethernet switch ICs available, but they cost a few dollars and require board space and power). The wiring harness might be lighter with Ethernet (single pair per link and possibly fewer total wires if networks are consolidated), which can reduce cost in terms of copper and weight (weight reduction also has a fuel economy benefit). It’s a trade-off: more electronics vs. less cabling. Some estimates claim that using a single-pair Ethernet can reduce cable weight by up to 30%, which can indirectly save cost, but the savings in material must offset the added electronics. Manufacturing and connectors also factor in – CAN uses simple connectors (often 2-pin or part of multi-pin connectors), whereas Ethernet might use specialized automotive connectors that ensure proper pairing and EMC (e.g. MATEnet or TE’s automotive RJ-45-like connectors), which are somewhat pricier.

Development and Validation Cost: Another cost aspect is the development and testing. Since CAN is slower and simpler, it does not require very expensive test equipment; an engineer can analyze CAN signals with relatively low-cost CAN analyzers or even basic oscilloscopes (CAN’s 1 MHz bit rate can be debugged with a $1k oscilloscope). Ethernet’s high frequencies (especially gigabit rates) require high-bandwidth oscilloscopes, network analyzers, and specialized tools to debug signal integrity or timing issues. For example, validating a 10 Gbps automotive Ethernet link might entail instruments costing hundreds of thousands of dollars. Compliance testing is also an added step – the OPEN Alliance and IEEE provide compliance tests for automotive Ethernet PHYs (for interoperability, EMC, etc.) that manufacturers must perform. CAN, being mature, has a very stable conformance testing regime and simpler physical layer requirements. In short, Ethernet can introduce higher engineering costs for development and validation.

That said, Ethernet also brings economies of scale from the IT world. The Ethernet hardware in cars leverages huge volumes of Ethernet technology (though the automotive single-pair PHYs are a niche, the core technology is adapted from mass-market Ethernet). As automotive Ethernet adoption rises, the cost per port is dropping. In modern luxury vehicles, the value added by using Ethernet (enabling advanced features) outweighs the few extra dollars of cost. Additionally, consolidating multiple legacy networks (CAN, LIN, MOST, FlexRay) into Ethernet domains could reduce the total number of electronic modules or gateways, potentially saving cost at the system level despite a higher cost per node.

Cost of Deployment vs. Functionality: From an OEM perspective, CAN wins on cost for simple functions – you wouldn’t use Ethernet to connect a seat adjustment motor or a window switch; a CAN (or LIN) is far cheaper and sufficient. On the other hand, for a surround-view camera system that might replace several mirrors or add safety value, the cost of an Ethernet link and a switch is justified. A practical example: mid-2010s BMW models introduced Ethernet for camera systems – the added cost was acceptable in a high-end car to achieve parking assist features. Over time, cost reduction is helping Ethernet trickle down to mid-range cars for features like OTA updates and advanced infotainment. We also see Tier-1 suppliers integrating multiple functions into single domain controllers to save cost; these often rely on Ethernet to communicate with the rest of the vehicle. So the cost analysis must consider overall E/E architecture: a centralized architecture with Ethernet might reduce the total number of ECUs (since one domain controller can replace several smaller ones), potentially saving cost even if the remaining ECUs are individually more expensive.

In summary, CAN remains the cost-effective choice for many low-to-medium bandwidth needs, with minimal hardware and integration cost. Ethernet has a higher upfront cost per node and added complexity, but it enables high-value features that CAN cannot, and its cost is trending down as adoption increases. The decision often comes down to value: if a feature or domain absolutely requires high data rates or network flexibility, the cost of Ethernet is justified; otherwise, CAN (or CAN FD) will be used to keep things simple and cheap.

Common Automotive Applications

Both CAN and Ethernet are used extensively in vehicles today, but in different application domains aligned with their strengths. Below is an overview of where each network finds common use in automotive systems:

Powertrain and Chassis Control (Engine, Transmission, ABS, etc.): These critical control domains have traditionally been the stronghold of CAN. Classical CAN at 500 kbps or 1 Mbps connects the engine control module, transmission control, and other drivetrain sensors/actuators. The deterministic, robust nature of CAN is well-suited for real-time engine management, throttle control, stability control, and braking systems. For example, the engine ECU broadcasts RPM, throttle position, etc., over CAN to the transmission and traction ECUs. ABS modulators send wheel speed sensor data over CAN to the stability control system. The data rates are low (tens of signals, updated in the order of 10–100 Hz), well within CAN’s capacity. Even when newer architectures arise, these time-critical controls often remain on CAN for safety and redundancy – brake-by-wire and steer-by-wire systems in some high-end cars used FlexRay (for its dual-channel redundancy), but many have also implemented fail-operational dual-CAN networks for steering or braking. The low latency and priority-based arbitration of CAN make it ideal here. A real-world example is the Bosch ESP system (electronic stability program) which uses CAN to coordinate braking intervention among engine and brake controllers. As CAN FD becomes available, some powertrain networks are upgrading to CAN FD to send larger datasets (e.g. detailed diagnostics or more sensor data) but still preserve compatibility and real-time behavior.
Body and Comfort Systems: These include lighting, climate control, seat control, door modules, wipers, etc. CAN (particularly lower-speed CAN or even LIN sub-networks) is widely used for body control due to its cost efficiency. A body CAN bus (often running at 125 kbps or 250 kbps) links various body control modules – for instance, the central body controller can send a message to all door modules to lock/unlock doors, or read status from window lift switches. The bandwidth needs are small (a few bytes for a command, infrequent messages), and cost sensitivity is high (these features appear even in economy cars). CAN fulfills these needs easily. In fact, many of these actuators and sensors are on LIN (Local Interconnect Network, a simpler UART-based network) which then gateways into CAN at a higher level. Automotive Ethernet is rare in this domain today because it would be overkill to use a 100 Mbps link to, say, a seat heater module. The trend is to keep using CAN or LIN for these, possibly connected to a zonal controller that then links to Ethernet. So body and comfort remain a CAN domain for the foreseeable future, with LIN/CAN keeping cost and complexity low.
Infotainment and Telematics: This domain has seen a migration from legacy specialized networks to Ethernet. In older vehicles, infotainment systems might use MOST (Media Oriented Systems Transport, an optical network) or separate analog links for audio/video. Today, Ethernet is becoming the unifying network for infotainment due to high data requirements. For example, the head unit (center infotainment processor) might connect via 100BASE-T1 or 1000BASE-T1 Ethernet to the digital instrument cluster to share display content, to seat-back screens in rear entertainment systems, and to the amplifier for audio (using the Automotive Audio Bus over Ethernet or AVB protocols for low-latency audio). A telematics control unit (which provides connectivity to the cloud) also often interfaces via Ethernet to the head unit or the vehicle gateway, enabling high-speed data transfer for services like live traffic, OTA updates, etc. Infotainment traffic includes video streams, high-fidelity audio, GPS map data, and internet traffic – clearly in the tens of Mbps range, which only Ethernet can handle. Use case: A 360° parking camera system in a car might feed four camera video streams to a central unit that stitches them into a surround view; those camera ECUs often send video over 100 Mbps Ethernet links to the infotainment domain controller. Another example is Diagnostics over IP (DoIP): when the car is in service, a technician’s tool can connect (via the OBD-II port Ethernet interface) to the car’s Ethernet network and perform diagnostics or reprogramming at high speed (much faster than the older ISO 15765 CAN-based diagnostics). In fact, DoIP (ISO 13400) is now used by many OEMs for flash programming ECUs during production and service. Some mid-2020s cars route an Ethernet cable to the OBD port for this purpose. On the same note, a lot of ADAS data logging for development uses Ethernet because engineers need to record high-bandwidth sensor data from test vehicles.
ADAS (Advanced Driver-Assistance Systems) and Autonomous Sensors: This is arguably the fastest-growing area for automotive networking, and where Ethernet really shines. ADAS includes features like surround-view cameras, radar and lidar sensors, driver monitoring cameras, etc., and a central ADAS or autonomous driving computer that processes these inputs. The data from these sensors can be massive. A single forward camera raw output can be 1.2 Gbps (uncompressed 720p 60fps, for example), though typically compression or pre-processing reduces what is sent. Radar units might output target object lists over CAN (if low-end), but high-resolution radars and lidars output point clouds or dense data that require high bandwidth. Automotive Ethernet is increasingly used to link these sensors: many radars and cameras now include a 100 Mbps or 1000 Mbps Ethernet interface (often using the UDP protocol to stream data to the central unit). Tier-1 suppliers have developed radar units that output via Ethernet to simplify integration. It’s common for a central ADAS ECU to have a multi-port Ethernet switch connecting 4–6 cameras and 1–2 radars, aggregating their feeds. For instance, Tesla’s Autopilot Hardware units use Ethernet or similar SerDes links to gather camera feeds into the main computer. The rear-view camera is another example – early implementations used analog video or LVDS links, but now some use Ethernet to send video to the display head unit or ADAS processor. Real-world OEM examples: BMW’s surround view system in the 7-Series (around 2014) was one of the first, using 100 Mbps BroadR-Reach Ethernet for cameras. Hyundai also adopted BroadR-Reach for driver assistance cameras around the same time. More recently, Audi’s zFAS ADAS domain controller (in Audi A8) uses multiple Ethernet ports to intake sensor data. Meanwhile, CAN is still used in ADAS, but mainly for low-bandwidth control – for example, the ADAS ECU might send a CAN message to request the brakes to actuate (since the brake actuator is on CAN) or to report status/warnings to the instrument cluster. CAN is also a fallback path for redundancy: if the high-speed sensor link fails, some minimal info might be sent over CAN (e.g. “sensor fault” or low-rate data). In autonomous prototypes, Ethernet networks with gigabit links (and sometimes fiber optics for longer runs or EMI immunity) are the norm to ship data from numerous sensors to a computer in the trunk.
Vehicle Gateway and Connected Vehicle Functions: Modern cars have a central gateway ECU that interconnects all networks (CAN, LIN, Ethernet, FlexRay if present, etc.) and often serves as a firewall to the outside world. This gateway increasingly has an Ethernet port (or multiple) as one of its “sides” – for example, a gateway might connect to a CAN powertrain bus, a CAN body bus, and also to an Ethernet backbone that links to the infotainment and ADAS domains. The gateway often manages traffic between CAN and Ethernet (for instance, translating a CAN message from the engine into an Ethernet message for a remote display, or vice versa). As vehicles become connected (vehicle-to-cloud, V2X communication), Ethernet is also utilized to carry data from cellular/Wi-Fi modems (usually in a telematics box) into the vehicle network at high speed. Over-the-air software updates are a good example: downloading a 1 GB update over a cellular connection would then be distributed inside the car. The internal distribution is far faster and more efficient over Ethernet (perhaps using TCP/IP) than it would be over CAN.

To highlight the roles: CAN excels in real-time control for powertrain, chassis, and simple body functions, due to its reliability and low cost (found in virtually every ECU handling engine, transmission, airbags, etc.). Automotive Ethernet excels in high-data and high-performance domains like ADAS and infotainment, enabling functionalities that were previously impossible or required separate proprietary links. The two often work in concert – for instance, an ADAS controller might use Ethernet to get camera/radar inputs, process a decision, then send a high-priority command over CAN to a braking ECU to apply brake pressure. This multi-network interplay is common in today’s vehicles.

Limitations and Bottlenecks

While both CAN and Ethernet are indispensable, each has its limitations and potential bottlenecks in automotive use:

Limitations of CAN:

Bandwidth Ceiling: The most well-known limitation of CAN is its limited bandwidth. Even CAN FD maxing out around 5–8 Mbps cannot handle large data transfers. This becomes a bottleneck when ECUs need to exchange a lot of information. For example, trying to transmit a live video feed or a detailed radar scan over CAN would be futile – the data would either be too slow or would completely saturate the bus, blocking out other traffic. Practically, CAN buses reaching above ~50% utilization start to pose performance concerns (collision and latency for lower-priority messages increase significantly). Thus, CAN is ill-suited for the “data tsunami” of modern vehicles. The surge in sensor data and OTA updates simply cannot be accommodated by CAN’s capacity, which is a driving force behind moving to Ethernet.
Message Size and Segmentation: Classic CAN’s 8-byte payload means large datasets must be fragmented into many small frames. Even with CAN FD’s 64-byte payload, something like a 1 MB firmware update requires thousands of CAN frames, which is slow and burdensome (taking perhaps minutes over CAN vs seconds over Ethernet). Moreover, sending many back-to-back CAN frames can hog the bus if of high priority. There is also more protocol overhead (each chunk has its own ID, CRC, etc.). This small frame size is a bottleneck for efficiency – roughly only 50–60% of the bits on the bus in a standard CAN frame are actual data bits. Ethernet frames, by contrast, can carry over 1500 bytes with about 98% efficiency for large transfers. So CAN is inherently less efficient for bulk data.
Network Length and Node Count: CAN’s performance degrades with bus length and heavy node loading. At higher bit rates, the allowed cable length shrinks (to maintain signal timing). Although in-vehicle segments are short, if one tried to network an entire vehicle with one CAN bus (which some older cars did), the physical length and number of stubs could cause reflections and errors, limiting reliability. That’s why multiple CAN buses are used – but that introduces gateways and complexity. So scalability is a limitation: you can’t just keep adding devices to a single CAN bus indefinitely. There’s also a limit to the number of unique message IDs (standard CAN: 2,048 IDs if using 11-bit) which can become a logical limitation in very large systems (though extended CAN 29-bit mitigates that with over 500 million IDs, rarely an issue).
Latency under Load: Although CAN is prioritized, if the bus is near saturation, lower-priority messages can experience significant delays or even get dropped if transmit buffers overflow. In worst-case analyses, a message could be delayed by the transmission of all higher priority messages. For example, if a low-priority diagnostic message is trying to get through while the bus is busy with many sensor broadcasts, it might wait tens of milliseconds. For real-time control, engineers avoid such loads, but it’s a limitation to keep in mind – CAN’s determinism holds only up to a certain loading point.
Security and Addressing: CAN has no inherent authentication or encryption. This means any node can spoof any message if it gains bus access, and critical systems trust those messages. This limitation has become evident with car hacking incidents (attackers remotely injecting CAN messages via a compromised infotainment ECU). It’s a vulnerability rather than performance bottleneck, but a limitation of the protocol that modern designs need to overcome via higher-layer security (which consumes bandwidth and CPU). Additionally, CAN being broadcast means every node receives all frames, which might be unnecessary and creates minor overhead in software (though hardware filtering helps). There’s no concept of logical segmentation or VLANs like in Ethernet.

Limitations of Automotive Ethernet:

Complexity and Determinism: As discussed, Ethernet is not naturally deterministic without TSN. This complexity is a limitation in the sense that using Ethernet for time-critical control requires careful configuration (scheduling, traffic shaping) and possibly additional hardware support. This raises the bar for development – engineers must handle switch configurations, timing verification, etc., which was not needed with CAN. If misconfigured, an Ethernet network could introduce unpredictable latency (e.g., if a low-priority large file transfer is not properly segregated, it could delay a critical control packet). Thus, achieving consistent low latency on Ethernet requires overcoming the protocol’s limitations with auxiliary standards.
Fault Domain and Diagnosis: While a point-to-point topology isolates faults to a link, diagnosing Ethernet issues can be more complex. A CAN bus failure (like a short to ground) can be probed with a multimeter and usually affects the whole bus, making it evident. An Ethernet network issue might stem from a specific port, cable, or an subtle issue like a switch forwarding rule – requiring more sophisticated network diagnostics (packet sniffers, link tests) to troubleshoot. Additionally, rebooting an Ethernet ECU or hot-plugging isn’t as straightforward in a running car network (though cars typically aren’t hot-plug environments, a failing node might cause strange network behavior rather than just go silent).
EMC and Cabling: Automotive Ethernet’s high-frequency signals (especially gigabit and above) demand careful cable design and routing to meet electromagnetic compatibility (EMC) requirements. Unshielded single-twisted-pair is used to save weight/cost, but it relies on complex encoding (like PAM3 for 100BASE-T1) and echo cancellation. If not engineered correctly, an Ethernet link could be more susceptible to certain types of noise or could emit more noise. CAN’s lower frequency and differential swings are very robust in the automotive EMC realm. So one limitation or challenge for Ethernet is ensuring signal integrity in the noisy automotive power environment (though standards have largely addressed this). There is also the 15 m length limit on most automotive Ethernet PHYs – while not typically an issue inside a car (few cable runs approach 15 m), it’s a limitation to note (CAN can run 40 m at 1 Mbps, or over 100 m at lower speeds).
Power and Sleep/Wake: As noted, Ethernet has higher idle power draw, and bringing an Ethernet network from sleep involves more complexity (link renegotiation, possibly re-syncing time protocols) compared to CAN where any node can wake and start talking almost instantly. For features that need to be always listening (e.g., passive entry systems, alarm systems), leaving an Ethernet network up isn’t practical, so additional low-power hardware or networks are needed. One can view this as a limitation: Ethernet alone cannot be the sole network in a car without power implications; usually a low-power bus remains for wake-up. In contrast, a car could theoretically be designed solely with CAN buses (and some are, historically) and manage power fine.
Cost and Legacy Integration: Another practical limitation is that many existing sensors and actuators in the automotive world speak CAN (or LIN). Moving everything to Ethernet would require redesigning countless components with new interfaces, which is happening gradually for high-end components but not for cheap sensors. So in near term, Ethernet’s limitation is that it can’t interface natively with some legacy components, requiring gateways or additional bridging circuitry. This is not a technical limitation of Ethernet per se, but a constraint in deployment – the ecosystem of CAN devices is huge and mature, whereas Ethernet-enabled automotive devices are still catching up.

Bottlenecks in Use Cases:

Each network can become a bottleneck if misapplied. For instance, if someone attempted to implement a high-resolution video feed over CAN, the CAN bus would be a severe bottleneck, not just slowing that feed but starving other messages – clearly an inappropriate use. Conversely, using Ethernet for a simple sensor network of, say, 20 temperature sensors each sending 2 bytes per second would be overkill; the sensor nodes would need more expensive hardware, and the network utilization would be a tiny fraction, but you’d still incur the overhead of maintaining links, etc. The bottleneck there might actually be cost or power rather than bandwidth.

In some architectures, the gateway ECU becomes a bottleneck. For example, if a lot of CAN traffic has to be forwarded over a single Ethernet link or vice versa, that gateway could max out its CPU or the link. Designers must ensure the gateway has enough throughput (some use multi-core processors or dedicated routing logic). The trend of domain controllers also means a single Ethernet link might carry a whole domain’s traffic, so if that link is not sized properly (e.g., using 100 Mbps where 1 Gbps is needed), it becomes a choke point.

In conclusion, CAN’s limitations lie in its speed, data capacity, and scalability, making it a bottleneck for high-data or highly expanded networks, whereas Ethernet’s limitations lie in its complexity, power, and integration overhead, which can be bottlenecks for time-critical simplicity and cost. Automotive network architects increasingly adopt a hybrid approach to avoid each network’s pitfalls: use CAN (or LIN) where its simplicity suffices and is advantageous, and use Ethernet where data demands dictate – all orchestrated such that neither network is overloaded beyond its comfort zone.

Emerging Trends and Future Outlook

The landscape of automotive networking is evolving rapidly to accommodate next-generation vehicle requirements. Several key trends are influencing how CAN and Ethernet will be used in the future:

1. Zonal Architectures and Centralized Computing: Automakers are transitioning from distributed ECUs (many separate controllers for each function) to domain controllers and now towards zonal architectures. In a zonal architecture, the vehicle is divided into zones (front-left, front-right, rear, etc.), each with a zonal controller that interfaces with local sensors/actuators and connects to a high-speed backbone (almost invariably Ethernet) to communicate with a central vehicle computer. This shift is largely driven by the need for a software-defined vehicle – where functions are implemented in software on powerful processors rather than fixed-function ECUs. Ethernet is the enabler here: using Ethernet as the backbone, a zone controller can publish data from, say, all sensors in its zone onto the network, and any other controller or application can subscribe to that data. This decouples hardware from software function. Zonal architectures significantly reduce wiring (since you no longer run dozens of dedicated wires or separate CAN buses crisscrossing the car; instead one or two Ethernet cables from each zone carry everything). This not only saves weight and cost but is essential for updatability and flexibility. With Ethernet and IP-based communication, adding a new feature might just be a software update that uses existing network data, whereas with traditional CAN networks, adding new features often meant adding new messages, perhaps even new ECUs or bus reconfigurations. OEMs like Volkswagen, GM, and others have announced moves to zonal E/E architecture in their upcoming platforms. Implication: CAN will still exist in these architectures, mainly within the zone for directly controlling devices that need simple, reliable comms (likely short CAN or LIN links from a zonal controller to door locks, motors, etc.), but Ethernet will carry the inter-zone traffic. In essence, CAN becomes more of a local bus, and Ethernet becomes the system’s nervous system.

2. High-Bandwidth ADAS and Autonomous Driving: As vehicles add more automated driving capabilities, the sensor set expands (high-res cameras, long-range radars, lidar, ultrasound, etc.) and so does the data fusion requirement. The trend here is the adoption of multi-gigabit networks and advanced communication protocols. For instance, automotive Ethernet is expected to move to 10 Gbps and beyond for connecting high-end sensors (some LIDARs already output multi-gigabit data streams). New standards like IEEE 802.3cy (25 Gbps over automotive cable) and even optic fiber Ethernet for automotive are under discussion. In parallel, techniques like compression and smarter signal processing are used to manage data volumes, but ultimately the network capacity is being pushed upward. Autonomous vehicle prototypes often use 10 Gbps Ethernet or fiber optics (like Ethernet or PCI Express over fiber) for their internal networks. We can expect future production cars that offer Level 4 or Level 5 autonomy to incorporate multi-gig Ethernet backbones, possibly with ring or mesh topologies for redundancy. This doesn’t eliminate CAN – even a self-driving car still needs a CAN (or equivalent) for low-level control and as a fallback, but the data backbone will be Ethernet. In fact, one CEO in the industry noted that features of autonomous and software-defined vehicles “would only be possible with the introduction of automotive Ethernet to transport the exploding bandwidth…and provide accurate timing and security”, underlining Ethernet’s central role in the future.

3. Time-Sensitive Networking (TSN) and Deterministic Ethernet: The future will likely see converged networks where a single Ethernet network in the car carries everything from engine control messages to video streams, partitioned logically. TSN is the key to this convergence. Work is underway (e.g., IEEE 802.1DG automotive profile for TSN) to standardize how to configure a TSN Ethernet network for mixed criticality traffic in cars. The goal is that Ethernet can deliver the same level of determinism as CAN for critical control by reserving time slots or using preemption to send small high-priority frames without delay. Already, features like frame preemption (IEEE 802.3br) allow a large Ethernet frame to be interrupted mid-transmission to send a high-priority frame, analogous to CAN’s arbitration but in a full-duplex context. This will further ensure that worst-case latencies are bounded and low. Industry consortia like AVnu and the OPEN Alliance are working on compliance and interoperability so that different vendors’ switches and controllers can implement TSN and still work together. In effect, we are likely to see a future where an automotive Ethernet network can truly replace the timing-guarantees of CAN for most signals, thereby allowing more ECUs to ditch CAN and use Ethernet exclusively. However, because CAN is so ingrained and reliable, it may persist as a redundant bus for ultimate fail-safety (for example, a minimal CAN bus could exist to handle limp-home messages if the Ethernet network fails).

4. Evolution of CAN – CAN FD and CAN XL: On the CAN side, the protocol is not standing still. CAN FD is now common in new models (providing higher throughput for things like ECU reprogramming and transport of larger signals). The next iteration, CAN XL, is in development, aiming for up to 10 Mbps and a larger data field (2048 bytes) with improved error handling. CAN XL is partially an answer to the question: how to support more data without losing CAN’s simplicity and real-time behavior. It incorporates a 48-bit ID and protocol type field to better interoperate with higher-layer protocols. Even though 10 Mbps is far below Ethernet, it could serve as a middle-ground for cases where Ethernet is too costly or power-hungry but CAN FD is not quite enough. We might see CAN XL used in sub-networks or as a backup bus. For example, a future vehicle might use a 10 Gbps Ethernet backbone but also have a CAN XL bus running in parallel for certain critical messages or as a secondary path. The ISO 11898 standard family will evolve to cover these new versions, ensuring backward compatibility where possible. The continued evolution of CAN shows that it will remain relevant – its future role may be more niche (used in smaller domains or specialized functions), but it’s not going to disappear overnight.

5. Software-Defined Vehicles and OTA Updates: The term software-defined vehicle (SDV) implies that much of a car’s behavior can be changed by software updates or upgrades after production. A robust in-vehicle network is fundamental to this concept. If an OEM wants to enable new features via software (for instance, enabling higher performance mode in an EV, or adding a driver assist feature), they need a high-speed network to deliver data and coordinate functions. Ethernet with IP-based communication is advantageous because it allows for a service-oriented architecture: ECUs can offer services that can be discovered and used by new software functions. We see the automotive industry adopting technologies like SOME/IP (Scalable service-Oriented Middleware over IP) which essentially treats the car’s network similar to an IT network with services. This trend dovetails with Ethernet, as SOME/IP runs on Ethernet (TCP/UDP). Meanwhile, CAN is being integrated into this paradigm via gateways – e.g., a service on Ethernet might proxy to a CAN message – but it’s not as natural. Over-the-air (OTA) updates also rely on having fat data pipes inside the car; downloading new firmware to 10+ ECUs simultaneously is dramatically faster over Ethernet. For instance, if each ECU’s image is 100 MB, updating that over a 500 kbps CAN could take hours and may not be feasible in a consumer setting, whereas a gigabit Ethernet can do it in seconds. Therefore, the push for SDV strongly favors Ethernet adoption, and we will likely see even mid-range vehicles move to an Ethernet backbone to support these capabilities. Tesla again is an example, as they heavily use OTA updates and have an Ethernet-based architecture allowing them to update almost any module quickly and even run diagnostics remotely – features that were hard to imagine with a pure CAN network.

6. Integration of Vehicle-to-Everything (V2X) and External Networks: Cars are no longer isolated – they communicate with cloud servers, infrastructure, and other vehicles. The in-car network thus must interface with these external links. V2X units (which might use IEEE 802.11p or C-V2X protocols) often feed data into the car’s Ethernet network so that information like “intersection collision warning” can be distributed to relevant ECUs (e.g., to trigger alerts via the cluster or pre-charge brakes). Similarly, as high-speed 5G comes into cars, the data rates (potentially multi-gigabits via 5G) mean the internal pipe must handle that – again pointing to Ethernet. This influences the architecture by possibly having an Ethernet hub that connects not just internal ECUs but also the telematics modem and V2X transceiver. CAN cannot realistically carry an external internet data stream (imagine streaming a video to a car’s rear-seat tablet – that’s going to ride on Ethernet/IP).

7. Backward Compatibility and Coexistence: An emerging challenge is how to integrate new Ethernet networks with legacy CAN-based devices. We see gateway ECUs becoming ever more crucial – they will speak CAN to old-school devices and speak Ethernet to new devices. There’s a trend of unified gateway or vehicle central computer which has a myriad of interfaces (multiple CAN FD channels, LIN, Ethernet, etc.). Over time, as legacy devices are phased out, perhaps that gateway simplifies. But for the next decade, most vehicles will have a bit of both. A concrete outlook is that by 2030, industry analysts predict that the average vehicle will have several Ethernet ports and much higher in-vehicle data usage, but CAN will still handle a lot of the fundamental control tasks, especially in entry-level vehicles or non-critical peripheral functions.

8. Tooling and Ecosystem Maturity: We anticipate improved tooling for Ethernet similar to what CAN enjoys (CANalyzers, etc., but for Ethernet and SOME/IP and TSN). This is already underway – companies like Vector, ETAS, etc., have tools for automotive Ethernet analysis. As these become commonplace, engineers will gain more confidence and familiarity with Ethernet, accelerating its adoption. The OPEN Alliance (One-Pair Ethernet Alliance) continues to drive standards to ensure multi-vendor interoperability for PHYs and protocols, which will mitigate early adopter risks.

Future Outlook Summary: The future is clearly moving towards network convergence on Ethernet for in-vehicle communication, especially as vehicles become more like “computers on wheels” requiring high data throughput and seamless connectivity. CAN will not vanish – it remains extremely well-suited for certain classes of problems and offers a simplicity that is hard to beat for small-scale networks. But its role will gradually become more peripheral. As one article headline put it, “Ethernet will increasingly function as the automotive network backbone, offering a higher performing, more secure, and more efficient alternative to CAN”. In the long run, we might envision a vehicle where most ECUs are on an Ethernet network (with deterministic channels for controls), and only a few tiny microcontrollers (for sensors/actuators) use CAN or LIN locally. This is analogous to how modern industrial automation has moved – fieldbuses (like CAN) at the very edge for simple devices, and Ethernet as the main plant backbone.

In conclusion, the evolving needs of autonomous driving, connectivity, and software-defined functionality are decisively steering automotive networking towards Ethernet, due to its sheer capabilities and flexibility. CAN, enriched by CAN FD and CAN XL, will continue to play a crucial role in its niche – providing ultrahigh reliability, low-cost control communications. Automotive engineers will thus be working in a heterogeneous network environment, leveraging the right tool for each job: maintaining CAN for its strengths in determinism and simplicity in small-scale networks, and deploying Ethernet for its unmatched bandwidth and feature-rich protocol support in the larger system. This complementary usage ensures that future vehicles meet their performance goals while balancing cost, safety, and legacy considerations. The ultimate goal is to deliver a unified driving experience where all these networks operate transparently to enable smarter, safer, and more connected vehicles.