Automotive Ethernet (100BASE-T1) vs. CAN FD in Next-Gen Zonal Electronic Architectures

Key Takeaways

CAN FD remains a practical choice for control-oriented communication, including body electronics, powertrain subsystems, and many distributed ECUs

Automotive Ethernet provides substantially more bandwidth for camera data, sensor aggregation, infotainment, and high-speed in-vehicle backbone networks. 

Zonal architecture changes how ECUs are connected, allowing local wiring to converge at zone controllers and data to move across a high-speed Ethernet backbone.

Ethernet does not automatically replace CAN FD. The right architecture often combines both, with selection based on traffic volume, timing requirements, safety needs, and system cost.

Why Are Automotive Networks Changing?

A modern vehicle may contain multiple cameras, radar sensors, driver assistance systems, displays, powertrain controllers, and dozens of other electronic modules. These systems do not generate the same type of traffic. A door controller may send a few status messages, while a camera can produce a continuous stream of image data.

Traditional CAN networks handle many control tasks efficiently, but their available bandwidth becomes restrictive when large amounts of sensor data must move between ECUs. CAN FD extends the original CAN protocol with payloads of up to 64 bytes per frame and a faster data phase, commonly reaching 5–8 Mbps depending on the network design. It is a meaningful improvement over Classical CAN, but it is not designed to serve every high-bandwidth data path in a modern vehicle.

Automotive Ethernet addresses a different requirement.100BASE-T1 delivers 100 Mbps, while 1000BASE-T1 delivers 1 Gbps over a single balanced twisted pair. These links provide the capacity needed for high-speed communication between cameras, domain controllers, gateways, and other data-intensive systems. The relevant physical-layer standards are defined within the IEEE 802.3 Ethernet family.

Automotive Ethernet vs. CAN FD: Technical Comparison

Actual network performance depends on bus loading, frame format, topology, protocol overhead, and implementation. Neither nominal bit rate nor physical-layer speed alone determines end-to-end latency.

Why Zonal Architecture Favors Automotive Ethernet

In a traditional distributed architecture, functions are often connected through separate networks arranged around individual systems. As more features are added, wiring routes and connections can become complicated. A zonal architecture groups connections by physical location within the vehicle.

For example, a zone controller near the front of the vehicle can connect nearby lighting, body-control modules, and selected sensors. It can handle local communication while forwarding higher-volume traffic to a central computer or another zone over an Ethernet backbone.

This approach can reduce duplicated long-distance wiring and simplify how new functions are integrated. Single-pair Ethernet also helps reduce cable bulk compared with conventional multi-pair data links. However, the actual reduction in harness weight depends on the vehicle's starting architecture, power distribution, cable lengths, connector count, and redundancy requirements. A fixed percentage should not be assumed for every design.

The main benefit is architectural flexibility: local control networks can remain close to their devices, while high-bandwidth data uses links designed to carry it.

Where CAN FD Still Makes Sense

Does Automotive Ethernet completely replace CAN FD? In most practical architectures, it does not.

CAN FD remains attractive when a system exchanges short commands, status updates, sensor values, or actuator requests. Its message-based communication model is well suited to distributed control, and its mature ecosystem supports established automotive development and diagnostic practices.

Braking and steering systems illustrate an important distinction. Their communication requirements depend on the specific safety architecture, not simply on whether a network has low latency. CAN FD may be suitable for particular control paths, but the network alone does not guarantee functional safety or deterministic end-to-end behavior. The complete design must address fault handling, timing, redundancy, and the relevant safety requirements.

Ethernet can also support time-sensitive communication through technologies such as Time-Sensitive Networking (TSN). Therefore, it is inaccurate to describe Ethernet as inherently unsuitable for real-time automotive systems. It requires appropriate network design, configuration, and validation.

How to Select a 100BASE-T1 PHY Transceiver

For engineers evaluating a 100BASE-T1 PHY transceiver, headline bandwidth is only the starting point. Check the following before committing to a component:

Host interface: Confirm compatibility with the selected MAC interface, such as MII, RMII, RGMII, or SGMII, as supported by the specific PHY.

Automotive qualification: Verify AEC-Q100 qualification, operating temperature range, and suitability for the intended environment.

EMC and signal integrity: Review electromagnetic emissions and immunity requirements, cable characteristics, termination, and PCB layout recommendations.

Power management: Check sleep/wake-up support, standby consumption, and wake-up behavior if the vehicle requires low-power networking.

Diagnostics and safety: Review link diagnostics, fault reporting, time synchronization features, and any functional-safety documentation needed by the system.

Supply continuity: Check lifecycle status, package, approved sourcing channels, and long-term availability before selecting a production PHY.

For example, NXP's TJA1103 is a 100BASE-T1 PHY with automotive-oriented diagnostics, sleep/wake-up support, and timestamping features. It is one reference point for evaluating the feature set required by an application, not a universal drop-in replacement for every Ethernet PHY.

Key Questions Engineers Should Ask

Question 1: Why is the automotive industry moving toward zonal Ethernet architectures?

The main drivers are increasing sensor-data volume, more centralized computing, and the need to simplify vehicle wiring. Ethernet provides a high-speed backbone, while zonal controllers help organize connections by physical location. The benefits depend on how the entire electrical/electronic architecture is designed.

Question 2: Does CAN FD have a bandwidth limitation in modern ECUs?

Yes, when an ECU must transport large continuous data streams. CAN FD is effective for control messages, but its data rate and frame capacity make it a poor fit for raw multi-camera video or other high-volume sensor streams. Ethernet is generally better suited to these workloads.

Question 3: Should a new design use 100BASE-T1 or 1000BASE-T1?

Choose 100BASE-T1 when 100 Mbps is sufficient for the traffic, distance, and integration requirements. Consider 1000BASE-T1 when the data volume or expected future demand justifies gigabit bandwidth. Also evaluate switch ports, host interfaces, power consumption, EMC performance, and total system cost.

Question 4: Is Ethernet always cheaper because it uses one twisted pair?

Not necessarily. Single-pair cabling can reduce cable bulk, but the full cost includes PHYs, switches, connectors, validation, software, and network management. A small control network may remain simpler and less expensive with CAN FD.

Final Recommendation

For next-generation zonal electronic architectures, treat CAN FD and Automotive Ethernet as complementary technologies. Use CAN FD where compact control messages, established network behavior, and cost-effective distributed communication are the priorities. Use 100BASE-T1 or 1000BASE-T1 for high-throughput links connecting cameras, gateways, domain controllers, and other data-intensive ECUs.
When sourcing automotive networking components, compare the complete part number, host interface, qualification, EMC performance, power requirements, diagnostics, and lifecycle status-not just the advertised data rate. For a proposed PHY replacement or second-source option, verify the datasheet and system compatibility before approving it for production.