A door module that reports switch states and drives a window motor needs a few hundred bytes per second. A forward-looking camera feeding an object detection stack needs tens of megabits per second, sustained, with bounded jitter. Both are ECUs. Both sit in the same vehicle. They should not sit on the same kind of network, and the mistake we see most often is a team picking one bus for the whole platform because that is what the last project used.
This article walks through how CAN (including CAN FD) and automotive Ethernet actually differ — in timing behaviour, bandwidth, wiring, silicon cost, tooling, and what each implies for functional safety work. We are not going to declare a winner. In most real vehicles the answer is both, and the interesting engineering question is where you draw the line between them.
What each network was actually designed to do
CAN was designed in the 1980s to replace point-to-point wiring harnesses with a shared two-wire bus for control signals. Everything about it follows from that goal. It is a multi-master broadcast bus with arbitration by message identifier: lower ID wins, and the winner transmits without any retry delay. Frames are small — 8 data bytes in classical CAN, up to 64 in CAN FD. There is no addressing of nodes, only labelling of messages, so any node can listen to any signal without the sender knowing or caring.
Automotive Ethernet, in the 100BASE-T1 and 1000BASE-T1 variants that matter in vehicles, was designed to move bulk data over a single unshielded twisted pair. It is switched and point-to-point: every node has a link to a switch, and the switch decides where frames go. Frames carry up to roughly 1500 bytes of payload. Nodes have MAC and usually IP addresses. It assumes a protocol stack above it.
That difference in design intent is the whole story. CAN is optimised for many small, frequent, prioritised control messages with predictable worst-case timing. Ethernet is optimised for throughput and for carrying general-purpose protocols. Neither is a degraded version of the other.
Bandwidth and payload: the easy comparison
Raw numbers first, because they settle a lot of arguments quickly.
- Classical CAN: 1 Mbit/s maximum, and in practice 500 kbit/s on most powertrain and chassis buses, 125–250 kbit/s on comfort buses. 8 data bytes per frame.
- CAN FD: arbitration still at the nominal rate, data phase typically 2–5 Mbit/s. Up to 64 data bytes, which cuts per-byte overhead dramatically.
- CAN XL: data phase into the 10–20 Mbit/s range with payloads up to 2048 bytes. Useful, but adoption and tooling maturity are still catching up.
- 100BASE-T1: 100 Mbit/s full duplex over one twisted pair.
- 1000BASE-T1: 1 Gbit/s. Multi-gig automotive PHYs exist for sensor backbones but bring cost and thermal considerations.
Once you need to move a compressed video stream, a lidar point cloud, a map tile update, or a full firmware image in a service-bay time window, CAN is out. Not slow — structurally wrong. Fragmenting a 40 MB image into 8-byte frames burns bus time and CPU cycles for no benefit. This is the clearest decision boundary in the whole comparison: if the ECU's job is data, use Ethernet.
Latency and determinism: the comparison people get wrong
Plain Ethernet has higher throughput and worse worst-case timing than CAN. That surprises people who equate speed with responsiveness.
On CAN, priority is baked into the identifier. A high-priority frame waits, at worst, for the current frame in flight to finish, then wins arbitration. At 500 kbit/s a classical frame is roughly 250 microseconds, so worst-case blocking for your highest-priority message is bounded and small, and you can compute it on paper. This is why brake, steering, and airbag signals have lived happily on CAN for three decades.
On a standard Ethernet switch, a small urgent frame arriving behind a 1500-byte frame already being forwarded waits for that transmission to complete. At 100 Mbit/s that is about 120 microseconds per hop — fine — but queueing across multiple hops with bursty traffic can stack up, and without configuration the switch has no idea which of your frames matters. The mitigations exist and are mature:
- IEEE 802.1Q priority tagging, so the switch can order egress queues sensibly. This alone solves a lot.
- Credit-based shaper (802.1Qav) for reserved-bandwidth streams such as audio and video.
- Time-aware scheduling (802.1Qbv) for hard cyclic windows, at the cost of network-wide time synchronisation via gPTP (802.1AS).
- Frame preemption (802.1Qbu / 802.3br) so a large frame can be interrupted by an express frame.
All of that is TSN, and it works. But be honest about what it costs you: switch silicon that supports the features, a validated time-sync domain, a configuration toolchain, and a verification effort to prove your schedule holds. If your only reason for Ethernet is determinism, you have probably chosen the harder path. If you need bandwidth and determinism together, TSN is the right tool.
Cost, wiring, and the physical layer
CAN wins on unit economics at low node cost, and it is not close. A CAN controller is integrated into nearly every automotive microcontroller family. The external part count is a transceiver, two termination resistors, and some protection. A CAN transceiver is a low-cost, high-volume commodity part. A microcontroller with two or three CAN FD channels is cheap and widely available.
Ethernet costs more per node. You need a PHY, magnetics or a capacitively coupled interface depending on the standard, a MAC (usually on-chip on the larger MCUs and all SoCs, absent on small ones), and if you have more than two nodes, a switch. Automotive switch ICs with TSN support are meaningfully more expensive than CAN transceivers. Add EMC work: single-pair Ethernet at 1 Gbit/s over unshielded cable is achievable but demands careful connector choice, controlled routing, and real time in an EMC chamber.
Topology also matters for harness design. CAN is a linear bus — one trunk, short stubs, terminated at both ends, and you can hang another node almost anywhere along it. Ethernet is a star; every node needs its own run back to a switch. On a large vehicle that trades harness copper for switch ports, and the total-cost answer depends on your specific layout. Zonal architectures exist largely because that trade tipped: an Ethernet backbone between zone controllers, with CAN and LIN fanning out locally to sensors and actuators.
Functional safety and security
Both networks appear in ASIL-rated systems. Neither gives you safety for free. Under ISO 26262 the communication channel is treated as potentially unreliable, and you add end-to-end protection above it — sequence counters, CRC over the payload, timeout monitoring, data ID. AUTOSAR's E2E library exists precisely for this, and it applies whether the transport is CAN, Ethernet, or FlexRay. The practical differences:
- CAN has decades of field data, well-understood failure modes, and mature analysis techniques for bus loading and worst-case response time. Argument construction is familiar territory for assessors.
- CAN's built-in error detection, error counters, and bus-off behaviour are well characterised, but a stuck-dominant fault takes down the whole segment. Bus topology means shared failure.
- Ethernet's point-to-point links contain physical faults to one link, which is genuinely valuable for availability. A failed cable removes one node, not a segment.
- Ethernet brings a larger attack surface and a bigger software stack. If the ECU is reachable from a telematics unit or a diagnostic port, you are now doing IP-level security work: MACsec or IPsec, firewalling at the gateway, secure boot, and intrusion detection. ISO/SAE 21434 work grows accordingly.
- CAN's lack of authentication is a real weakness, addressed with SecOC (Secure Onboard Communication) — which consumes payload bytes you may not have in classical CAN, another argument for CAN FD.
A practical decision framework
When we sit with a team on this, the questions run roughly in this order.
- What is the largest single data object this ECU must send or receive, and how often? If anything exceeds a few kilobytes at a regular rate, Ethernet is on the table.
- What is the tightest end-to-end deadline, and what is the consequence of missing it? Sub-millisecond control loops with safety consequences point to CAN FD, or to Ethernet with TSN if bandwidth forces your hand.
- How many nodes, and where are they physically? Many small nodes spread along a path favour a CAN bus. A few data-heavy nodes near a controller favour Ethernet.
- Does anything need IP? Diagnostics over IP, SOME/IP service discovery, OTA update flows, or an on-board web interface all argue for Ethernet.
- What does the MCU you already selected support? Retrofitting Ethernet often means a bigger part, more flash, more RAM, and a different software stack. That is a schedule and BOM decision as much as a network one.
- What is your team's tooling and experience? CAN debugging with a decent bus analyser and DBC files is straightforward. Debugging a TSN schedule or a SOME/IP service binding is a different skill set.
A common, sane outcome looks like this: CAN FD at 2 Mbit/s for control and status between chassis and body ECUs; 100BASE-T1 for cameras, radar aggregation, and the infotainment link; 1000BASE-T1 only where the sensor data genuinely demands it; a gateway or zone controller routing signals between domains with a defined, tested signal mapping. LIN stays for cheap actuators. Nobody rips out CAN because Ethernet arrived.
Where the gateway logic lives, and why it deserves attention
Mixed networks mean translation, and translation is where subtle bugs breed. A signal that arrives on CAN every 10 ms and is republished as a SOME/IP event needs a defined policy for what happens when the source goes quiet, when it arrives faster than expected, or when the Ethernet side is momentarily congested. Timeouts, last-known-good handling, and E2E counter regeneration all need explicit design decisions, and they need to be captured somewhere a reviewer can check them against the safety concept — not left implicit in gateway code.
Budget review time for the signal database and the gateway mapping specifically. In our experience that document, more than any hardware choice, determines whether integration goes smoothly or turns into weeks of chasing intermittent stale-data faults on a bench. If you want a sense of how we approach that kind of systems work, our project write-ups cover a few embedded and data-heavy builds.
When you do not need Ethernet at all
Worth saying plainly, because it saves money. If your ECU handles discrete inputs, motor or solenoid control, temperature and current sensing, and reports state to a vehicle controller — CAN FD is enough. It will be enough for the life of the product. Adding an Ethernet PHY so the design is "future-proof" adds cost, EMC risk, firmware complexity, and validation effort in exchange for a capability nothing in your requirements asks for. We would rather see that budget spent on better diagnostics coverage or a proper HIL setup.
Conversely, if any part of the ECU's job involves perception data, model inference on sensor streams, or shipping data off the vehicle, do not try to squeeze it onto CAN. The same reasoning applies once you start moving that data into cloud pipelines — something our AI and ML engineering team deals with regularly on the analytics side of vehicle and industrial telemetry.
If you are working through this decision for a specific ECU and want a second pair of eyes on the bandwidth budget, timing analysis, or the gateway design, get in touch. We are also happy to talk about how an embedded engineer or two working as part of your team can fit alongside your existing platform group rather than replacing it.
