Camera and radar data, high-resolution displays, and over-the-air updates all need far more bandwidth than any CAN variant offers.
CAN FD's 64-byte frames and multi-megabit data phase (see CAN FD Explained) is a large step up from classic CAN, but a single forward-facing ADAS camera can produce tens of megabits per second on its own - before adding a full surround-view camera set, radar, lidar, or a high-resolution infotainment display. That's office-network territory, which is exactly where automotive Ethernet borrows from: the same IEEE 802.3 Ethernet used everywhere else, adapted for the automotive environment.
| Office Ethernet | Automotive Ethernet | |
|---|---|---|
| Cabling | 4-pair (Cat5e/6) | Single unshielded twisted pair (100BASE-T1, 1000BASE-T1) |
| Priority | Best-effort by default | Deterministic timing via Time-Sensitive Networking (TSN/AVB) |
| Topology | Switched star, flexible | Fixed, designed against EMC and weight constraints |
The single-pair physical layer (100BASE-T1 and faster variants) is the key automotive-specific piece - it gives Ethernet-class bandwidth over cabling that's a similar weight and cost to a CAN pair, which matters a great deal at vehicle scale.
Raw Ethernet just moves packets - it doesn't define what a "vehicle speed" service looks like on the wire, the way a CAN identifier or a J1939 PGN does. SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the automotive standard that fills that role for Ethernet-based systems: services are published, discovered, and subscribed to dynamically (an infotainment module can discover "is a rear-camera service available on this network?" instead of every consumer needing a fixed, pre-agreed message list.
This is a meaningfully different design philosophy from CAN's fixed, broadcast-everything model - closer to how a modern web API is structured than to a DBC-defined message table - though CAN's traditional gateway/backbone role for chassis and powertrain data isn't going away; Ethernet is layered in for the systems that specifically need its bandwidth.
Most current vehicle architectures run both: a CAN (or CAN FD) backbone for the traditional powertrain/chassis/body domains, and an Ethernet backbone for ADAS, infotainment, and high-bandwidth sensors, bridged through a central gateway. Diagnosing or logging a modern vehicle increasingly means understanding both networks and where a given signal actually lives, not assuming everything is reachable from a single CAN tap.
Automotive Ethernet capture is a newer area of the ONAC platform's hardware roadmap, extending the same capture-and-decode philosophy behind ONAC Network Studio's CAN tooling to SOME/IP service traffic - relevant wherever a diagnostic or data-logging engagement needs visibility into the ADAS/infotainment domain, not just the CAN backbone.