CAN FD and Automotive Ethernet: Faster Networks for Smarter Vehicles

Standard CAN — The Foundation

Standard CAN bus has been the backbone of vehicle communication since it was introduced by Bosch in the 1980s and became mandatory on US vehicles in 2008 through OBD-II requirements. Every module on a vehicle — the ECM, TCM, ABS module, BCM, instrument cluster, HVAC module — communicates with every other module over a shared pair of wires. This is the high-speed CAN network that your scan tool talks to when you plug into the OBD-II port.

Standard CAN runs at up to 500 kilobits per second. Each message frame carries up to 8 bytes of data. For the needs of 1990s and 2000s vehicles — sharing engine RPM, vehicle speed, coolant temperature, gear selection, ABS wheel speeds — 500 kbps was more than adequate. Modules send short messages frequently, the network is never close to capacity, and everything works smoothly.

But modern vehicles are fundamentally different machines. ADAS cameras generate continuous video streams. Radar sensors send complex point-cloud data. High-resolution displays need fast data updates. Reprogramming a modern ECM over the diagnostic port used to take 20 minutes with standard CAN — now modules have much larger software images. The math stopped working. 500 kbps is a bicycle lane when you need a highway.

Why More Bandwidth Was Needed

To understand why higher-bandwidth networks are necessary, consider the data rates involved:

• A forward-facing ADAS camera generates compressed video data at rates that can reach tens of megabits per second
• A surround-view camera system (four cameras, 360-degree view) multiplies that requirement by four
• Lidar sensors on some ADAS applications generate point clouds at hundreds of thousands of data points per second
• Modern ECM software images can be 10-50 megabytes — at 500 kbps, that takes 160-800 seconds just for raw transfer before accounting for protocol overhead

Standard CAN cannot carry this data volume. It was never designed to. Engineers needed two solutions: a faster version of CAN for the existing module communication network, and a much faster network for the high-bandwidth sensor data. CAN FD and Automotive Ethernet are those solutions.

CAN FD — Flexible Data-Rate

CAN FD solves the bandwidth problem for existing CAN networks while maintaining backward compatibility with the existing physical infrastructure. The same twisted-pair wiring, the same basic protocol structure — but two key improvements in how data is encoded within each message frame.

Larger payload: Standard CAN carries 8 bytes of data per message frame. CAN FD carries up to 64 bytes per frame. Same number of messages, eight times more data per message. This alone significantly increases effective throughput.

Higher data phase speed: CAN FD uses a clever trick called flexible data-rate (the FD in the name). The arbitration phase of the message — where the network determines which module gets to transmit — still runs at standard CAN speed for compatibility. But the data phase — the actual payload — can switch to a much higher bit rate, up to 5 Mbps. The frame signals a bit rate switch at the start of the data phase and switches back at the end. Modules that only understand standard CAN see the arbitration phase normally and then see the high-speed data phase as an error — but the network design keeps CAN FD and standard CAN nodes on separate network segments with gateway modules translating between them.

The result: CAN FD can carry roughly 10x more data per unit of time than standard CAN while requiring no new wiring. Most 2020+ vehicles use CAN FD on at least some of their internal networks, particularly for high-priority control module communication.

Automotive Ethernet

For the truly high-bandwidth applications — camera video, lidar point clouds, and fast module reprogramming — CAN FD is still not fast enough. This is where Automotive Ethernet comes in.

Regular Ethernet (the kind in your home or office) uses 4 twisted pairs and runs at 100 Mbps or 1 Gbps. It works well but the 4-pair wiring adds weight and cost in a vehicle with hundreds of meters of total wiring. Engineers developed Automotive Ethernet (standardized as 100BASE-T1 and 1000BASE-T1) to achieve the same speeds using a single twisted pair. The physical layer technology is different from regular Ethernet, optimized for the automotive environment: extended temperature range, vibration tolerance, and electromagnetic compatibility in a high-noise electrical environment.

100BASE-T1 runs at 100 Mbps over one twisted pair. 1000BASE-T1 runs at 1 Gbps over one twisted pair. Compare these to standard CAN at 0.5 Mbps — Automotive Ethernet is 200 to 2,000 times faster. This is the network that can carry an ADAS camera video stream with headroom to spare.

BMW was the first manufacturer to use Automotive Ethernet in production vehicles — in 2013, for the diagnostic interface on the F-series vehicles. It allowed dramatically faster reprogramming and large data transfers. GM moved to Ethernet as the backbone network architecture on 2020+ vehicles. Most major manufacturers are transitioning their highest-bandwidth connections to Ethernet.

How Modern Network Topology Works

Modern vehicles do not use a single network for everything. They use a layered architecture:

• Automotive Ethernet backbone — connects domain controllers (high-powered central computers), ADAS processors, infotainment systems, and the diagnostic interface. Handles high-bandwidth data.
• CAN FD — connects powertrain, chassis, and body control modules where 5 Mbps is sufficient and backward compatibility with existing module designs is valuable.
• Standard CAN (500 kbps or 125 kbps) — still used for lower-priority body systems, instrument clusters, and modules that do not require high data rates.
• LIN bus (Local Interconnect Network) — very low speed (20 kbps), used for simple one-way or slow communication: seat motors, mirror adjusters, individual switch inputs.
• Gateway modules — translate between network types. The OBD-II port connects to a gateway that can route scan tool requests to the appropriate network segment.

Understanding this architecture helps when diagnosing communication faults. A U-code in multiple modules on the same CAN bus segment points to a bus fault (wiring or termination). A U-code in a module that connects via Ethernet points to an Ethernet link fault or the domain controller it connects to. The symptoms and physical diagnosis are different for each network type.

What Techs Need to Know for Diagnosis

For everyday diagnostic work, the important practical points:

Scan tool communication still works. The OBD-II diagnostic interface on modern vehicles typically uses standard CAN or CAN FD for scan tool communication — not Automotive Ethernet. Your scan tool connects and reads codes normally on CAN FD vehicles. The faster internal networks are between specific modules and are not directly accessible through the OBD-II port on most applications.

Software updates are faster. If your scan tool connects via the Ethernet diagnostic interface (some OEM and J2534 interfaces support this), large module reflashes that used to take 20+ minutes can complete in 2-3 minutes. The reprogramming process is the same — just faster.

New communication fault codes. On CAN FD and Ethernet-equipped vehicles, you may see U-codes referencing CAN FD errors, Ethernet link faults, or network configuration issues that do not exist on older CAN-only vehicles. The physical diagnostic approach is similar — check wiring, check connectors, measure bus voltage — but the expected values and the tools needed for Ethernet diagnosis are different.

Termination resistors still matter. CAN FD networks use termination resistors just like standard CAN — typically 120 ohms at each end of the bus. Measuring termination resistance (should read approximately 60 ohms between CANH and CANL with all modules connected) is still a valid first step for CAN FD bus faults. Automotive Ethernet uses different termination — check manufacturer specifications.

Tools and Equipment

Most professional-grade scan tools (Snap-on, Autel, Launch, and similar) support CAN FD protocol on 2020+ vehicles. If your scan tool has trouble communicating with a newer vehicle that you know should be supported, check for firmware updates for your interface — CAN FD support was added to many tools after initial release.

For Ethernet-specific diagnosis (not yet a common shop requirement as of 2026 but coming), you need a network analyzer or oscilloscope capable of decoding 100BASE-T1 signals. Standard oscilloscopes can be used to verify signal quality on Automotive Ethernet networks, but decoding requires specific software or dedicated automotive network analyzers. This level of diagnosis is currently primarily in dealer environments with OEM tools.

The Bottom Line

CAN bus is not dead — it is evolving. CAN FD increases the speed and data capacity of the familiar CAN network while keeping the same wiring. Automotive Ethernet handles the high-bandwidth applications that CAN cannot touch. Modern vehicles use both, layered into a tiered network architecture with gateway modules connecting them. For technicians, the practical impact is faster reprogramming, new types of communication fault codes, and the need to understand which network segment a module lives on before diagnosing a communication fault. The physical diagnostic fundamentals — check wiring, check connectors, measure bus voltage, check termination — still apply. The tools and expected values are evolving alongside the technology.

Frequently Asked Questions