New in-vehicle networking technology will likely take over as more AI is added, but in the near term designers face challenges integrating new with old.
Key Takeaways
As the “AI everywhere” mantra extends to vehicles, there is increasing pressure on in-vehicle networks to move more data, and to do it faster. This is especially true with software-defined vehicles, which demand more bandwidth, increased determinism, and better security than legacy protocols were designed to deliver.
Automotive Ethernet is emerging as the clear successor, but deeply embedded, low‑cost standards like CAN and LIN are not going away anytime soon. This will be a long transition, marked by hybrid architectures, integration challenges, and the need for complex system-level modeling to make new and old technologies work together.
Today, automotive Ethernet is largely used for infotainment systems, camera feeds in advanced driver assistance systems, autonomous driving, interconnection backbones, and diagnostics. But use cases are expected to grow as software-defined vehicles become the norm. It is relatively straightforward to design and build a brand new SDV with all the latest networks and components. What makes it complicated is integrating new communications protocols with legacy ICs, such as ECUs (electronic control units), sensors, and actuators.
The rising popularity of Automotive Ethernet raises the question of whether it will entirely replace older network protocols for in-vehicle communication, such as CAN (controller area network bus) and LIN (local interconnect network), or whether all the protocols will continue to co-exist, along with SerDes (serializer/deserializer functional blocks).
“Automotive Ethernet will not fully replace CAN, LIN, or FlexRay in the near term as CAN/LIN remains cost-effective and reliable for low-speed, non-critical functions,” said Seung-Taek Chang, SDV solution manager in the Automotive & Energy Group at Keysight. “Ethernet is becoming the backbone for high-bandwidth and time-sensitive applications. My recommendation is for new platforms to use Ethernet as the backbone, with 10BASE-T1S at the edge, and retain CAN/LIN where cost or legacy constraints apply.”
In a zonal architecture, an Ethernet backbone delivers data from actuators, lidar, and radar to a central compute area where all the high-power compute is, as well as the ADAS and infotainment section.
“The backbone is about 1 gigabit per second to 2.5 Gbps,” said Mike Yeager, senior vice president and general manager of Ethernet solutions for Infineon Technologies’ ATV Division. “There’s still proprietary camera and display links that come in either LVDS (low-voltage differential signaling) or FPD (flat panel display link). We’re looking at moving this to a complete Ethernet bridge solution, where instead of having a proprietary camera coming in the lane, we fast forward and have an Ethernet device where we take the MIPI camera, convert it to Ethernet, and then bring it into the system. Now that it’s Ethernet, you can take advantage of higher-level protocols, like time-sensitive networking (TSN). The latency is lower. There’s redundancy that you can have on the links. There are a lot of advantages at the Ethernet level to do this, and we’re doing this both on the camera and the display.”
Fig. 1: A semi-zonal architecture with point-to-point cameras still connected over legacy protocols. Source: Infineon
For example, the company’s camera bridge chips feature Ethernet bridge networking developed with IEEE 802.3DM. “The backbone is up to 10 Gbps,” said Yeager. “We’re still working on 25 Gbps at this point, and talking to the robotics people, this is a really good match. This network allows us to share cameras and shorten cables.”
Fig. 2: Ethernet end-to-end includes cameras and displays over Ethernet. Source: Infineon
TSN keeps data time logs for all the data that needs to come in. “We also have precision time protocol (PTP), which is down to the nanoseconds,” said Benjamin Tan, senior applications engineer at Infineon. “When a data packet comes in, we’re able to log when that data is ingressing, and also egressing, to measure the latency within our own network.”
With these advances, automotive Ethernet could eventually take over safety-critical applications, including vehicle control or automotive radar sensors, which require real-time responses.
“Automotive Ethernet has proven its value in infotainment and ADAS, but its expansion into safety-critical domains, such as steer-by-wire and braking, depends on deterministic performance and fault tolerance,” said Adiel Bahrouch, director of business development for silicon IP at Rambus. “TSN extensions like IEEE 802.1AS provide the timing guarantees needed, while MACsec ensures secure data integrity. The shift to software-defined vehicles amplifies Ethernet’s value, streamlining wiring, reducing weight, and unifying communication protocols securely across domains.”
Overall, the advantages of automotive Ethernet point to a future without older protocols.
“As zonal architectures become more common, Ethernet’s ability to unify disparate domains under a common protocol stack becomes increasingly attractive,” Bahrouch noted. “With multi-gigabit links and synchronized packet delivery, Ethernet is well positioned to handle real-time control loops with the precision required for safety-critical operations. The tipping point will come when Ethernet not only matches but exceeds the safety and reliability benchmarks of traditional automotive networks.”
Still, some designers prefer legacy protocols to Ethernet. “I see a continued transition,” said David Fritz, vice president of hybrid-physical and virtual systems for automotive and mil-aero at Siemens EDA. “More and more sensors and actuators are trying to move directly to automotive Ethernet and try to get away from CAN and CAN FD. We deal with CAN, CAN FD (flexible data rate), LIN, FlexRay — and all of those would be better than just a twisted pair of two wires. I recently argued with somebody who was saying, ‘There are timing-critical aspects in a vehicle.’ And I said, ‘Well, yes, but if you have 100 Gbps of bandwidth, and you’re using 100 megabits, it will get there in time. Why are you so concerned?’ Even then, you can add quality of service on top of that. If I have a big critical packet, I can shut everything else down, and they’ll wait until it gets through. I can guarantee it. We’re dealing right now with a Tier 1 very closely tied to the biggest Japanese OEM, to prove that. We’re taking Arm IP, putting together a hypothetical system, running real workloads on it, and proving the measurements. It’s critical data, and we’re still 95% idle. Of course, it’s going to get there in time. The technology has changed such that your worries previously are not your worries now. For example, going forward, on a higher level, we’re moving towards AI.”
Timeline for CAN disappearance
AI, and the trend toward more GPUs in vehicles, is one reason CAN and LIN may be replaced.
“We’re definitely seeing an increase in performance requirements of the GPUs in vehicles, and that’s driven by a few factors,” said Rob Fisher, senior director of product management at Imagination Technologies. “There’s a centralization of the vehicle architecture. Previously, there were disparate systems around the car with separate ECUs, but more and more, there are cockpit domain controllers, ADAS domain controllers, and central domain controllers that are pulling in multiple functions, and that’s pushing the performance point. That centralization is very much enabled by things like automotive Ethernet because the traditional CAN bus-type architecture, which is a serial bus, doesn’t have the bandwidth you’d need to transmit all of the data necessary into the central location.”
CAN, LIN, and FlexRay are mature technologies, proven in an automotive environment, deeply integrated, and highly cost-effective, but experts agree they don’t have what it takes for tomorrow’s vehicles.
“We are going into the idea that automotive Ethernet will become the replacement,” said Infineon’s Tan. “Specifically, we’re seeing that 10BASE-T1S, running 10 megabits per second, will slowly replace CAN and CAN FD. The whole idea is, in five to 10 years, it will just be straight Ethernet, instead of CAN and LIN.”
Ethernet solutions must deliver clear added value in bandwidth, scalability, and security, while also matching or beating their cost efficiency, noted Rambus’ Bahrouch. “Emerging technologies like 10BASE-T1S illustrate this trajectory, extending Ethernet’s reach into low-cost sensor and actuator domains where it can directly compete with CAN.”
CAN will stick around for some time, in the same way older technologies in other applications have not yet vanished. “CAN could disappear, but sometimes it takes many generations for these things to happen,” said Jon Ames, principal product manager for the Synopsys Ethernet IP portfolio. “If you look at Thunderbolt, connecting up computers and monitors, all of that has Ethernet within it, but Thunderbolt still exists. Sometimes there will be co-existing technologies on the same wire, because you might be embedding one in the other, for example.”
The future also includes faster Ethernet standards and optical. “10BASE-T1S supports multi-drop topologies and is ideal for low-speed sensors and actuators, while optical Ethernet is used for high-speed backbones, such as 10 Gbps or 25 Gbps,” said Keysight’s Chang. “Bridging between 10BASE-T1S, optical Ethernet, and legacy protocols such as CAN and LIN requires gateways or zonal ECUs with protocol translation capabilities. Challenges include synchronization, latency management, and ensuring deterministic behavior across heterogeneous networks.”
Legacy components lag
Many low-cost, automotive-grade components, including ECUs, are designed for older communications protocols. It is not a simple task to get conservative manufacturers to speed up.
“Tier 1s waited quite a few years for the automotive Ethernet standards to be completed and ratified,” said Siemens’ Fritz. “They didn’t want to design something, have a change in the standard, then have parts to cancel because they’re not standard. The standards have happened now, at least. They also needed to have confidence that the SerDes technology that is required is solid and affordable. It doesn’t help to sell a $3 camera if it’s going to require SerDes that costs $15 because there are so few of them on the market. That means market conditions are driving when this transition is going to happen. I believe that as soon as a major car vendor makes this wholesale decision to switch to Ethernet and pushes its suppliers to have automotive Ethernet interface to every ECU, every sensor, every actuator, then everybody else will say, ‘To compete now, I have to do the same thing.’ Somebody just needs to make that bold move.”
The decision will come down to edge nodes such as legacy ECUs, which don’t require a lot of updating or smarts. “It takes a lot of engineering time and engineering power to replace that legacy stuff,” said Infineon’s Tan. “It’s tough with automotive. There are a lot of standards. We need to follow a lot of protocols. For the consumer market, you’re thinking two years into the market. Automotive is fortified.”
The automotive sector is so cost-sensitive that if something is commoditized and it’s good enough, then there has to be a very high incentive for OEMs to change. “You always have to think about what features are going to sell the car,” observed Paula Jones, senior director of mobility, semiconductor, electronics, and ADAS for Infineon. “With the legacy components, changing something over is much harder than starting from scratch. If you started from scratch and designed a car today, you would use the latest protocols and sensors.”
However, in time, the cost of automotive Ethernet and its related components will come down because it is also being developed for other applications. “If you have a technology that’s used everywhere, and you’ve got a whole bunch of engineers working on it, the technology costs less,” said Synopsys’ Ames. “It’s not that hard to make a widget that supports CAN versus Ethernet. One doesn’t use fewer gates than the other one; it costs less. But because you’ve got more technology development and software development for it, the overall cost is low on something that is used in more applications.”
Ethernet versus CAN and LIN is not likely to be a differentiator of models within the same company, for example, high-end versus low-end. “Higher-end cars that have rear monitors for entertainment, or autonomous driving functions, might be first to use the higher performance technologies like Ethernet,” said Ames. “But there’s nothing to say you wouldn’t want to have Ethernet even in the lowest cost cars. Today, you might have some cheap silicon that doesn’t need Ethernet, and therefore, we can knock out our cheaper cars with our cheap silicon. But tomorrow, the cheaper silicon will be Ethernet-based, I’m very sure of that.”
Successful integration needs digital twins
Until one protocol rules them all, designers must find ways to integrate the new networking protocols with legacy components.
“CAN and FlexRay have earned their place in automotive through decades of reliability and cost efficiency,” said Rambus’ Bahrouch. “Their deterministic behavior, low cost, and proven track record make them indispensable in many automotive subsystems. Ethernet, while powerful, must still contend with integration challenges and the need for extensive validation in safety-critical environments.”
Integration and validation work is underway, but not yet solved. “We have been working with Panasonic and Sony and automotive sensor companies for six years now, trying to help with and monitor this transition from something that is CAN-based, or is based on an older protocol technology, to Ethernet,” said Siemens’ Fritz. “Everybody sees that Ethernet, with its twisted pair of wires, enables the data to travel extremely long distances. So you don’t have to worry about weight or wire harnesses, and big problems go away. But until the sensor and actuator companies make that transition, you can only go so far.”
The result is an integration storm. “When you’ve got a simple ECU with about 100 lines of code in it, you make fewer assumptions, and you find a way to work around it,” Fritz observed. “But now you’re talking about millions of lines of code. You’re talking about network processing capabilities, graphical processing capabilities, DSPs, 128 CPU cores, mixed criticality — some of it is mission-critical, and some of it is just streaming videos to kids. The complexity has ballooned to the point that integration has become the biggest problem.”
The military/aerospace sector is also shackled by the integration problem. “At the Pentagon, we’re talking to the Under Secretary of War about what’s happening with F-35 being years late, and things aren’t working,” said Fritz. “Why can’t the software work? Why is the hardware the way it is?”
The problem starts with the LRUs (line replaceable units), which function as the auto equivalent of the ECU, built by companies such as Lockheed, Boeing, and Raytheon.
“They build an LRU to go in this fighter jet, and say, ‘Okay, it works. Great,’” said Fritz. “But once they put all of those together, the plane won’t fly. The reason is, they say, ‘I have to assume that the communication between the LRUs and the sensors and the actuators is going to happen. Therefore, I can test my LRU independent of everything else, and I can have faith that the whole system is going to work.’ Problem is, that’s an engineering fallacy.”
Things can easily go wrong in complex systems, with a dozen different suppliers all making different assumptions. This is where you need a digital twin to model the behavior of the network and components, Fritz explained.
“You put it all together, and you need to be able to model every single one of those LRUs,” he said. “They all need to be communicating over a model of your network that looks at bandwidth, arbitration, and quality of service, and says, ‘If you put a 10 Gbps SerDes in that system, then it looks like you’re going to get a failure 3% of the time. That’s unacceptable, so you’re going to need 50 Gbps.’ You know that before you design the hardware, which means the software and hardware are modifiable until you get to the point where you’ve proven that. When everything comes together, you’re going to pass the requirements.”
Ethernet becomes the essential highway. “Without something like Ethernet to communicate between them, in that system-level modeling, there’s no way at all that’s going to work,” said Fritz. “The whole idea behind software-defined vehicles and products is that you need to model everything — with sufficient levels of fidelity — before you’re set on your hardware and software architectures. That is what SDVs are about, and that’s how you solve the integration problem, whether it’s a jet or a car or a rocket ship.”
AI adds to the integration challenges and piles on complexity. “Everything is having AI put into it, and that AI needs to be fed,” said Fritz. “I’m not talking about training. I’m talking about you have a trained system. You verified it’s going to perform properly. It needs an understanding of what’s happening around it, and that data is still coming from sensors. The result of that AI inferencing or decision making is still going to the actuators. It’s just that an actuator [in mil/aero] could be a flight surface, a flap, as opposed to a steering wheel. All of these systems fit within that same category, and the only thing that changes, really, is that the sensors change and the actuators change. Everything else in the middle still has the same challenges.”
SerDes remains essential
CAN or LIN could be replaced in the future, but SerDes is typically integrated in the automotive Ethernet chip with its own essential function.
“You have to drive the wire with something,” explained Synopsys’ Ames. “Ethernet goes to a single pair. That was the important piece, because if you have to have multiple pairs, it just means the wires weigh more. If you can get down to a single pair, then you’re on par with anything. Having this multi-drop technology means you don’t have to have as many switches, but you can have a single wire that connects to multiple widgets within the car, being a switch, a lamp, or whatever it may be.”
Ethernet and SerDes, therefore, go hand in hand. “The SerDes components are very much entwined with automotive Ethernet, and Ethernet in general,” noted Imagination’s Fisher. “To achieve the bandwidths that are required, it’s very much a SerDes architecture.”
GPUs may also become indispensable to power advanced features.
For example, automotive PHYs and switches may have SerDes such as SGMII or 25GBASE-X. “The idea of the switch is that it’s on the same PCB as the SerDes and your MCU, your CPU, or GPU maybe,” said Infineon’s Tan. “That’s where it’s communicating with it to do all the protocols, to run all the networking for it to do the processing that it needs to do.”
In this sense, automotive networking resembles the data center. “With the rapid adoption of AI from cloud and edge computing to AIoT (AI internet of things) and automotive, automotive system designs are increasingly incorporating high-speed interconnect protocols such as PCIe, UCIe, and Ethernet, mirroring trends in data centers,” said William Chen, product marketing group director for design IP at Cadence. “Currently, Automotive Ethernet and Automotive-grade SerDes are not major players in mainstream data centers, as they are optimized for automotive needs, such as low weight, cost, and EMI/EMC performance. However, there is ongoing technology cross-pollination, particularly around single-pair Ethernet (SPE) and SerDes design techniques.”
While data centers will need higher speed SerDes than automotive, the two sectors will continue to exchange ideas. “Looking ahead, edge computing, industrial and OT convergence, and composable architectures may create opportunities for automotive-style Ethernet or SerDes, especially where low-cost, lightweight cabling is advantageous,” Chen noted. “In core hyperscale data centers, SerDes will likely remain optimized for ultra-high speed, minimal jitter, and power efficiency. The greater influence may come from SerDes innovations — such as equalization and error resilience — feeding back into general high-speed SerDes design, rather than direct adoption of automotive PHYs.”
Conclusion
Overall, the crystal ball is showing more automotive Ethernet than legacy in-vehicle networking protocols. “I’ve seen a lot of folks at the OEMs talking about the future, and they see it going to Ethernet,” said Synopsys’ Ames. “I’m sure if there’s a willingness for it to happen, it will get there. Technology-wise, it could certainly do it.”
But the transition won’t happen overnight. “While Ethernet is designed for next-generation vehicles, legacy protocols will persist for some time and gradually transition over as the safety, reliability, and the economics of Ethernet are on par with the incumbents,” said Rambus’ Bahrouch. “The transition will be gradual as OEMs validate Ethernet’s reliability against legacy systems like CAN and FlexRay, but as the silicon matures, certification frameworks expand, and costs come down, the direction is clear.”
Related Articles
Auto Ethernet 10BASE-T1s Steps Up, With Tbps On The Horizon
High-speed data movement will be required in future vehicles, probably including optical, but challenges persist.
How Fast Can Germany Shift To Software-Defined Vehicles?
Design, manufacturing, and business overhaul are beginning, but the threat from low-cost, feature-rich vehicles from China continues to grow.
Will Automotive Ethernet Win?
Why it is so hard to provide a definitive answer about whether Automotive Ethernet will win, and the other contenders.
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply