The wrong question is "will Ethernet replace CAN?"

A better question is:

Which traffic belongs on Ethernet, and which traffic still belongs on CAN, CAN FD, or LIN?

Automotive Ethernet grew because vehicles need more bandwidth, more centralized compute, camera and sensor aggregation, software update paths, diagnostics, logging, and service-oriented communication. CAN remains useful because control signals are often small, periodic, robust, and tied to simple embedded controllers.

Modern vehicle networks are layered. Ethernet may be the backbone. CAN FD may handle rich control domains. Classical CAN may remain on stable low-bandwidth control segments. LIN may sit under body controllers for low-cost actuators.

What 100BASE-T1 and 1000BASE-T1 mean

The T1 naming matters. Automotive Ethernet is not just office Ethernet with a different connector.

Common examples:

  • 100BASE-T1: 100 Mbit/s over a single twisted pair
  • 1000BASE-T1: 1 Gbit/s over a single twisted pair
  • 10BASE-T1S: 10 Mbit/s single-pair Ethernet for shorter multidrop-style use cases

The physical layer, cabling, EMC requirements, wake/sleep behavior, and compliance testing are automotive-specific. OPEN Alliance specifications and test suites exist because interoperability matters when ECUs, switches, PHYs, and harnesses come from different suppliers.

How Ethernet changes the mental model

CAN is message-oriented and broadcast. A frame ID represents meaning and priority.

Ethernet is packet-oriented and switched. Depending on the stack, you may care about:

  • source and destination MAC addresses
  • VLAN tags
  • IP addresses
  • UDP or TCP ports
  • service IDs
  • timing and synchronization
  • switch configuration
  • packet capture and filtering

The CAN question is often:

What does CAN ID 0x321 mean?

The Ethernet question may be:

Which ECU is talking to which service, on which VLAN, with which timing and payload?

That is a different debugging style.

Gateway thinking: where CAN and Ethernet meet

A gateway may translate or route between:

CAN signal -> Ethernet service payload
Ethernet command -> CAN frame
CAN FD diagnostic response -> Ethernet diagnostics client
LIN local state -> CAN body frame -> Ethernet gateway

This is where database discipline matters. If a CAN signal is used by an Ethernet service, the CAN DBC is still part of the system contract.

Example:

CAN message:
  ID: 0x321
  Signal: VehicleSpeed
  Scale: 0.01
  Unit: km/h

Gateway service:
  Publishes VehicleSpeed to an Ethernet consumer

If the DBC scale changes from 0.01 to 0.1, the gateway can publish wrong data even if the Ethernet transport is perfect.

Capturing Automotive Ethernet traffic

On normal Linux Ethernet interfaces, use standard packet tools.

Capture everything:

sudo tcpdump -i eth0 -w vehicle-ethernet.pcap

Capture with visible packet summary:

sudo tcpdump -i eth0 -nn -tt

Capture UDP only:

sudo tcpdump -i eth0 -nn udp

Capture a specific host:

sudo tcpdump -i eth0 -nn host 192.168.10.20 -w ecu-traffic.pcap

Inspect in Wireshark:

wireshark vehicle-ethernet.pcap

Real Automotive Ethernet benches may need media converters, taps, switch mirror ports, or hardware that supports 100BASE-T1 or 1000BASE-T1. Do not assume a laptop RJ45 port can plug directly into a T1 link.

Comparing CAN logs and Ethernet pcaps

A CAN capture often looks like:

(1779476701.123456) can0 321#6813FFFF401F0000

An Ethernet capture is usually a pcap with layered protocol data.

The useful workflow is to align events:

CAN capture timestamp:     speed signal changes
Ethernet pcap timestamp:   gateway publishes updated speed service payload
Application log timestamp: consumer receives updated speed

That lets you answer whether the problem is:

  • CAN signal decode
  • gateway mapping
  • Ethernet transport
  • service serialization
  • application consumption
  • timing or scheduling

Why DBC quality still matters in Ethernet vehicles

Even in a vehicle with Ethernet backbone, CAN and CAN FD databases still matter because many edge signals originate on CAN buses.

DBC errors can propagate upward:

Wrong CAN scale -> wrong gateway value -> wrong Ethernet payload -> wrong application behavior

Clean DBC review is still a quality gate for:

  • sensor values
  • actuator states
  • diagnostic state
  • gateway inputs
  • HIL simulation
  • logging pipelines
  • fleet data interpretation

DBC Utility fits here as a focused database review tool, especially when you need to compare revisions before a gateway, logger, or data platform consumes the updated definitions.

CAN vs Ethernet debugging habits

Useful CAN habits:

  • inspect IDs
  • check payload length
  • verify bitrate
  • decode with DBC
  • watch periodicity
  • compare message revisions

Useful Ethernet habits:

  • capture pcaps
  • inspect VLANs and IP addresses
  • filter by protocol and port
  • check service endpoints
  • verify switch mirror configuration
  • correlate with CAN logs

The best vehicle network engineers learn both styles.

Practical engineer summary

Automotive Ethernet is not a marketing replacement for CAN. It is a necessary backbone technology for higher bandwidth, switched topologies, central compute, diagnostics, and software-defined vehicle architectures.

CAN, CAN FD, LIN, and Ethernet will coexist because real vehicles contain different traffic classes. The quality problem is not choosing one bus for everything. The quality problem is maintaining clean contracts between buses, tools, DBC files, logs, and software.

References