A vehicle network can gain more bandwidth and still become harder to integrate.
That is the risk in treating Automotive Ethernet as a faster replacement for CAN.
In a CAN-centred architecture, communication is largely built around known messages, identifiers and timing expectations. When Ethernet enters the vehicle, the physical network changes, but so do the responsibilities above it: data distribution, service discovery, diagnostics, timing, gateway behaviour, security and validation all need to be reconsidered.
For E/E architects, networking leaders and programme owners, the migration question is therefore not simply, “Where should Ethernet replace CAN?”
It is: “Which communication responsibilities move, which remain, and what new dependencies are created between them?”
The migration risk is not in changing the bus. It is in changing what the vehicle expects the network to do.
That distinction matters because most near-term vehicle architectures are hybrid. CAN and LIN remain useful at the edge, while Automotive Ethernet increasingly connects domain or zone controllers, high-performance compute and data-intensive functions. NXP, for example, describes zonal architectures that combine Ethernet backbones with CAN/LIN-connected sensors and actuators.
1. The first risk appears when bandwidth is mistaken for architecture
Ethernet solves a bandwidth problem, but bandwidth alone does not define a production network.
A CAN network is typically designed around message schedules and signal ownership. Ethernet introduces IP-based communication, switches, endpoints and service-oriented patterns. AUTOSAR supports Ethernet communication alongside technologies such as SOME/IP and DoIP, which means the software communication model can change as much as the physical network.
For programme leaders, the important early decision is not simply link speed. It is whether existing communication remains message-oriented, is translated through gateways, or is redesigned as services between software components.
That decision affects software architecture, configuration effort, supplier interfaces and the validation plan that follows.
2. Signal ownership can turn into service ownership
In a CAN-centred system, teams often reason about signals, frames and message IDs. In an Ethernet-based architecture, functions may instead consume services exposed over SOME/IP or another service-oriented mechanism.
The migration therefore creates questions that are easy to underestimate:
- Which ECU or software component owns the source data?
- Which service exposes it, and who owns that service contract?
- How are availability, discovery and version compatibility handled?
- What happens when a CAN-originated signal must be consumed by an Ethernet-native application?
This is where gateway design and middleware become architectural concerns rather than plumbing. A gateway can tunnel legacy traffic, translate signals into services, or combine both approaches. Each choice changes timing, software ownership and failure behaviour.
3. Timing does not disappear when the network gets faster
Higher throughput can create the impression that timing will become easier. In practice, timing becomes a system property that must be re-established across a more complex path.
A function may now depend on an edge ECU, a zone controller, an Ethernet switch, a service layer and a central compute application before an action is completed. NXP notes that moving from domain-based CAN-connected architectures toward zonal Ethernet architectures can introduce new delays around wake-up and function availability.
Time-sensitive traffic can therefore require explicit treatment through traffic prioritisation, synchronisation and, where relevant, Time-Sensitive Networking mechanisms.
For E/E decision-makers, the requirement is not “use TSN everywhere.” It is to identify which functions have timing constraints, measure the complete path and apply the appropriate mechanism only where the system needs it.
4. Diagnostics migrate with the architecture
Diagnostics is another area where a transport change can expose a wider system impact.
CAN-based diagnostic paths are mature and well understood. Ethernet introduces Diagnostics over Internet Protocol (DoIP), IP addressing, routing activation and gateway behaviour while many downstream ECUs may still remain on CAN or LIN.
AUTOSAR explicitly defines DoIP mechanisms for routing diagnostic messages between vehicle networks and TCP sockets. That means diagnostic migration must account for both the Ethernet path and the legacy buses behind it.
For teams planning the transition, the question becomes: can a diagnostic session move reliably through a mixed architecture under real network conditions, not simply on an isolated bench?
5. Hybrid gateways become a programme risk if their role is unclear
Most migration programmes will operate with mixed CAN-Ethernet architectures for some time.
That makes gateways strategically important. They may translate signals into services, route diagnostics, aggregate traffic or bridge legacy ECUs into an Ethernet backbone.
But every gateway also becomes a place where timing, configuration and ownership can become ambiguous.
If a CAN signal arrives late at an Ethernet consumer, where is the delay? If a service is unavailable, is the problem in discovery, translation, routing or the source network? If a diagnostic session fails, which side of the gateway owns the fault?
These are not simply network questions. They are integration questions spanning AUTOSAR communication, middleware, ECU configuration and the broader E/E architecture.
6. Validation has to move from link testing to end-to-end behaviour
A successful Ethernet link proves only that two nodes can communicate.
Production readiness requires much more:
- service discovery and recovery behaviour,
- end-to-end latency and jitter under realistic load,
- gateway translation and routing behaviour,
- sleep, wake-up and network-state transitions,
- diagnostic routing across mixed networks,
- time synchronisation where functions depend on a common clock, and
- interoperability across ECUs, switches and software stacks from different suppliers.
This is why Automotive Ethernet migration should be treated as a system-integration workstream, not a physical-network upgrade.
Acsia Technologies brings together Automotive Ethernet, AUTOSAR communication, middleware, network architecture, integration and validation so that these dependencies can be examined across the full path rather than one component at a time.
Three facts to test your Automotive Ethernet migration
Move the Network Without Moving the Risk Downstream
The transition from CAN-centred architectures to Automotive Ethernet is ultimately an E/E and software architecture decision.
When data ownership, service interfaces, timing, diagnostics, gateways and validation are addressed together, Ethernet can support the scalable communication foundation needed for more centralised and software-defined vehicle platforms.
When those responsibilities are treated as separate migration tasks, integration risk is simply pushed later into the programme.
Acsia Technologies supports OEM and Tier 1 teams across Automotive Ethernet, AUTOSAR communication, middleware, architecture integration and validation, helping programmes move from network design to production behaviour with the dependencies visible earlier.
Talk to Acsia about your Automotive Ethernet migration, integration or validation scope.
