Hook: Most engineering leaders no longer ask whether their next platform needs an Ethernet backbone. They ask how to run an automotive Ethernet migration without stranding a program already under contract. The answer is rarely a clean cutover. It is a sequencing problem: deciding which traffic moves first, how the existing bus network coexists, and how the safety case survives the change.
The trigger is the software-defined vehicle (SDV) transition, and it is a program-level event, not a trend. Domain and zonal architectures collapse 100-plus Electronic Control Units (ECUs) into a handful of high-compute nodes, and those nodes have to talk to each other at data rates the legacy buses were never designed to carry. Advanced Driver Assistance Systems (ADAS) sensor fusion, camera and LiDAR streams, and Over-the-Air (OTA) update payloads all push past what Controller Area Network (CAN) and FlexRay can move.
The decision lands on engineering leaders now because the physical layer choice and the network architecture get frozen early in a platform. Pick the wrong backbone and you carry the cost for the life of the program. Pick well, and the same architecture absorbs the next two feature cycles without a re-spin.
The ceilings are concrete. Classical CAN tops out at 1 Mbit/s. CAN FD (CAN with Flexible Data-rate) lifts the data phase to roughly 5 Mbit/s to 8 Mbit/s, which buys headroom but not a new order of magnitude. FlexRay reaches 10 Mbit/s per channel. Automotive Ethernet starts at 10 Mbit/s and scales to 10 Gbit/s on a single pair. That is the gap a zonal architecture has to cross.
Bandwidth is only half the problem. The deeper issue is architectural. CAN and FlexRay are signal-based and broadcast-oriented: every frame carries fixed message identifiers and most nodes need static prior knowledge of the network. As ECU counts climbed past one hundred, that model turned integration and change management into a combinatorial headache. The shift to service-oriented communication, where ECUs publish and discover services dynamically, needs a routable, IP-based transport. A recent LHP piece on SOME/IP and service-oriented vehicle networks walks through that architectural shift in detail. The takeaway for a program lead: you are not replacing a wire, you are replacing a communication paradigm.
This is where the migration gets practical, and where working engineers earn or lose the harness budget. Automotive Ethernet is a family of physical layers (PHYs), each tuned to a different traffic class, and all running full-duplex over a single unshielded twisted pair to meet automotive electromagnetic compatibility (EMC) limits and cut harness weight.
The engineering discipline is to map each network segment to the cheapest PHY that meets its bandwidth and latency budget, not to standardize on one rate everywhere. A vehicle that runs 10BASE-T1S to the doors and 1000BASE-T1 to the ADAS compute is doing this correctly. Over-provisioning every link to 1 Gbit/s wastes silicon cost and power; under-provisioning the backbone strands the next feature cycle.
Standard Ethernet is best-effort. It will move a camera frame and a brake-relevant message with no guarantee about which arrives first or when. Safety-critical control traffic cannot run on best-effort, which is why automotive Ethernet for anything beyond infotainment means Time-Sensitive Networking (TSN), a set of IEEE 802.1 amendments that make switched Ethernet deterministic.
Three TSN mechanisms carry most of the weight:
For automotive, these are tied together by the IEEE 802.1DG profile, which specifies how the TSN toolbox is applied in vehicles (aerospace has its own profile, 802.1DP). The functional safety consequence is direct: bounded latency under 802.1Qbv and path redundancy under 802.1CB are what let an architect put ASIL-rated traffic (Automotive Safety Integrity Level, per ISO 26262) on the same physical network as infotainment without violating the safety case. TSN is the reason Ethernet earns the right to carry safety-critical messages at all.
A migration plan that says "replace CAN with Ethernet" is not a plan. The real work is the coexistence period, and it is usually measured in years and multiple platform variants.
The pattern most programs converge on is a staged one. The high-bandwidth zonal and compute backbone goes to 1000BASE-T1 or multi-gig first, because that is where the bandwidth pain is. Legacy CAN and LIN (Local Interconnect Network) segments stay in place at the edges and connect to the backbone through zonal gateways that translate between the bus and IP worlds. SOME/IP (Scalable service-Oriented MiddlewarE over IP) typically rides on top as the service layer, and AUTOSAR Adaptive provides the runtime for the high-compute nodes while AUTOSAR Classic continues to serve the deeply embedded ECUs. The network becomes hybrid by design, and stays that way for the life of several platforms.
The cost model engineering leaders should insist on has four lines, not one. Harness savings from single-pair cabling are real but partial. Against them sit the added cost of Ethernet switches and PHYs, the validation cost of a more complex routable network, and the cybersecurity cost of a wider attack surface. That last line is the one teams underestimate: a routable, service-oriented network is far more exposed than a set of isolated buses, which is why ISO/SAE 21434 (the automotive cybersecurity engineering standard) and threat analysis belong in the architecture phase, not after tape-out. The same dynamic shows up in adjacent powertrain programs, as covered in a recent LHP analysis of what ISO/SAE 21434 means for electrification programs.
LHP treats network migration as a systems-engineering problem first and a protocol problem second. The work starts with the architecture decision (domain versus zonal, which traffic classes move when, where the gateways sit) and the traffic budget that drives PHY selection, because those choices constrain everything downstream.
From there, two LHP capabilities carry the validation load. The migrated network has to be exercised under realistic timing and fault conditions before silicon is committed, which is what LHP's hardware-in-the-loop (HIL) test environments are built to do, including fault injection on the TSN scheduling and gateway paths. In parallel, the expanded attack surface is assessed under ISO/SAE 21434 so the cybersecurity case is built alongside the architecture rather than bolted on. The point is to find the timing, redundancy, and security failures on a test bench, not in the field.
Freeze the network architecture and the PHY map early, and make the TSN profile decision (802.1DG) part of that freeze rather than a later detail. Build the cost case across all four lines, not just harness savings, and put cybersecurity in the architecture phase. Above all, treat the move as a three-to-five-year hybrid transition: the program that plans for CAN and Ethernet to coexist gracefully will outrun the one that bets on a clean cutover.
The next concrete step is a network architecture and traffic-budget review against your next platform's feature roadmap. If you want a working session on where Ethernet and TSN belong in your architecture, and how to validate the migration on HIL before you commit silicon, that is a conversation worth having now.
Automotive Ethernet migration is the move from legacy in-vehicle buses (CAN, LIN, FlexRay) to an Ethernet backbone as the primary high-bandwidth network in a vehicle. It is driven by zonal and domain architectures and the bandwidth demands of ADAS, high-resolution sensors, and OTA updates. In practice it is a staged, multi-year transition in which Ethernet carries the backbone and legacy buses persist at the edges through gateways, rather than a single cutover.
CAN FD (CAN with Flexible Data-rate) raises the data-phase rate to roughly 5 Mbit/s to 8 Mbit/s, which extends the life of CAN for many functions. It does not close the gap to the 1 Gbit/s and higher rates that zonal backbones and ADAS sensor fusion require, and it keeps CAN's signal-based, broadcast model. For high-bandwidth, service-oriented traffic, automotive Ethernet (10 Mbit/s to 10 Gbit/s over a single pair) is the scalable path.
Automotive Ethernet is the physical and data-link transport (PHYs such as 100BASE-T1 and 1000BASE-T1). Time-Sensitive Networking (TSN) is a set of IEEE 802.1 amendments layered on top that make switched Ethernet deterministic: 802.1AS for time sync, 802.1Qbv for bounded latency, and 802.1CB for frame redundancy. Plain Ethernet is best-effort; TSN is what allows safety-critical, ASIL-rated traffic to share the network under ISO 26262.
Not in the near term. Most programs run a hybrid network for the life of several platforms. Ethernet carries the zonal and compute backbone, while CAN and LIN continue to serve low-speed body, sensor, and actuator segments through zonal gateways. The engineering goal is to map each segment to the cheapest physical layer that meets its bandwidth and latency budget, which keeps CAN economically sensible at the edges.
It widens the attack surface significantly. A routable, IP-based, service-oriented network is far more exposed than a set of isolated buses, so a vulnerability can propagate where it previously could not. This is why ISO/SAE 21434 threat analysis and a cybersecurity management approach belong in the architecture phase of the migration, and why network security should be validated alongside timing and functional safety rather than addressed after the design is frozen.
Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.
LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.
In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.
When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.
Because in industries where technology must perform as intended, precision engineering matters.
Steve Neemeh : Oct 9, 2025 10:00:01 AM
Artificial Intelligence (AI) is no longer a side feature in vehicle safety and embedded software development. It is rapidly becoming the core driver...
Daniel Stuart : Nov 6, 2020 3:27:49 PM
How does a complex standard like ISO 26262 save my company money? In fact, you have heard just the opposite.
Steve Neemeh : Oct 30, 2024 2:00:00 PM
{% video_player "embed_player" overrideable=False, type='hsvideo2', hide_playlist=True, viral_sharing=False, embed_button=False, autoplay=False,...
Steve Neemeh : Oct 29, 2025 10:15:00 AM
Is there an ISO Standard for AI? The ISO/PAS 8800 standard, Road Vehicles Safety and AI, represents a milestone. It establishes a common vocabulary...
Steve Neemeh : Nov 21, 2025 10:00:00 AM
Steve Neemeh : Apr 17, 2024 4:13:44 PM
Understanding AUTOSAR’s Basic Software Layer The AUTomotive Open System Architecture (AUTOSAR) development platform is a powerful tool for...
Marty Muse