Will Automotive Ethernet Win?

As internal combustion engines are replaced by electric motors, and mechanical linkages increasingly replaced by electronic messaging, an in-vehicle network is needed to facilitate communication. Ethernet, amended for automotive and other time-sensitive applications, appears to be the network of choice.

But is that choice a done deal? And will Ethernet replace all other in-car networks? The answer, at least so far, isn’t clear.

“There is an argument right now about whether automotive Ethernet is really going to be the bus of choice,” said Joe Mallett, senior marketing manager at Synopsys. “It reduces the number of wires, and anytime you reduce the cable harness, that’s a good thing. But quality of service has been a challenge.”

The overall automotive architecture will strongly influence which direction the network goes. A zonal architecture favors a strong backbone network, where Ethernet appears to have an edge. But final decisions have yet to be made, and even if Ethernet becomes the backbone of choice, there’s still a question about the various local nodes connecting to sensors and displays.

The Society of Automotive Engineers (SAE) has defined four classes of network, labeled A through D. “A is when you have a very little message — like an on/off switch,” said Thierry Kouthon, technical product manager for security at Rambus. “B is intermediate to a few hundred kilobits per second. C will be faster. And D is anything above 1 Mbps. In the traditional car up to the year 2000, that was largely enough bandwidth.”

While the fastest category starts at 1 Mbps, that’s very slow traffic by today’s standards, and the new data requirements are forcing discussions of networks three and even four orders of magnitude faster than that.

It started with infotainment
Much of the current work on in-vehicle networking originally was driven by the needs of infotainment. That implies an external connection to content sources over a network that can handle the needs of audio and video, at the very least.

While plain Ethernet is found in many systems, it can’t handle the time-sensitive needs of audio/video (A/V) because timing is not deterministic. “It has the dreaded collision avoidance detection mechanism,” explained Kouthon. This was the motivation for developing time-sensitive-networking (TSN) features for Ethernet.

“TSN started with AVB [A/V bridging],” said Greg Schlechter, president of the Avnu Alliance and technology marketing strategist at Intel. “And then, in automotive, they said, ‘We need to move A/V around the car.’ And so we adapted it over there. And now industrial’s picking it up. And now aerospace is looking at it.”

TSN refers to a basket of features that may be selected for different applications. As its name suggests, it relates to the ability to deliver time-sensitive traffic with delivery timing guarantees. This is something basic Ethernet cannot do because it’s a best-effort protocol.

TSN features include traffic shaping, bandwidth reservation, latency reduction, pre-emption, and dealing with real-time requirements. These address overall quality-of-service needs for different functions within the vehicle.

But if Ethernet is going to have a role in infotainment, there’s a sense that it might as well be leveraged for as much of the in-vehicle networking as possible. That includes other time-sensitive control functions that plain Ethernet might not handle, but that Ethernet with TSN can handle.

“When you step on the brake, you have so much time before the brake gets there,” said John Swanson, senior product marketing manager at Synopsys. “You don’t want your kid’s game interfering with the network. The asynchronous traffic shaper lets you be much more flexible. If you have enough margin and bandwidth, TSN lets you guarantee everything will get there without having to do all the detailed network engineering.”

An automotive profile for Ethernet with TSN has been established, but the question remains whether this is the best solution for the entire vehicle.

Architecture affects networking
If Ethernet is going to predominate in the vehicle, it needs to be used in safety-critical applications. This is far different than infotainment, and it gets much more complicated. At the highest level, there are two contending architectures, and proponents of each tend to align along commercial offering lines.

“People are experimenting in both directions right now,” said Swanson. “There’s the supercomputer running the car, and there’s the zonal approach.”

Makers of big computing engines favor centralized computing, where the power of high-end processors can be harnessed, locking them into this high-volume opportunity. That means bringing all data into a central location for handling.

The zonal architecture, by contrast, distributes computing between zones and a central hub. A zone refers to a geographic area of the car. For instance, the front left corner of the vehicle could be a zone. A zone may have a variety of functions, and local computing handles each of these functions to the extent possible. A backbone network would connect the zones to the central processor.

Fig. 1: The two main automotive networking options. On the left is a centralized model, with all network endpoints connected to a central processor. On the right is the zonal architecture, with local zones handling some of the processing before delivering the results to a central processor. The networks within the zone remain an open question. Source: Bryon Moyer/Semiconductor Engineering

“If they go down the path of a zonal architectures with heavy central compute boxes in the middle, the Ethernet backbone at gigabit speeds is probably the answer that they’re all looking at,” said Vikram Patel, director of product marketing at Infineon.

This is distinct from organizing by domains, where physical location is no longer the determining factor. Instead, common functions make up a domain, like all of the cameras. Organizing by domains would likely mean central computing, because all shared functions from anywhere in the car would be handled together.

A benefit of central computing is that it has visibility into the entire vehicle, while a zone has visibility only into what’s within the zone. So a zonal architecture implies a split between local computing within the zone, and then further central computing to bring the zones together. For example, processing of a camera feed may be handled locally, with the results sent to a central hub where the results from all cameras can be merged as appropriate.

“The keys to being successful with a zonal architecture are some of the new bridges,” said David Fritz, senior director for autonomous and ADAS at Siemens EDA. “You can go from a localized CAN network in the zone to the zone module. And then you hit the main network, automotive Ethernet.”

One of the key motivators for a zonal architecture is that it reduces cabling. Cabling is turning out to be the heaviest and most expensive component of new vehicles, and so every possible step is being taken to reduce or simplify the connections.

Central computing implies “home runs” from all of the sensors to that central hub if a star network configuration is used. With a zonal architecture, most of those connections are within the zone, and only one connection goes from the entire zone to the center.

“I believe we’re going to see a hybrid, where there’s one supercomputer that knows everything that’s going on and may be driving everything, but the different zones do their own thing,” said Swanson. “Processing a video and getting it onto the network is something that a zone can do, and we don’t have to waste Ethernet traffic sending raw video.”

For simplicity, OEMs would prefer a single network doing everything. As Ethernet involves a large investment in software, leveraging that investment as much as possible brings development efficiency.

“Once you invest in that kind of time-based domain protocol, it’s heavy on software, and there’s an investment there,” said Infineon’s Patel. “So some OEMs see that if you’re going to go into Ethernet, you go all in.”

While that may be a long-term preferred outcome, it’s not clear that it’s practical today.

Different types of network traffic
This boils down to a question of what the networking needs are going to be. The answer is impacted by different kinds of data that must be transported.

In one case, there’s a distinction between regular network data and streaming data. Network data tends to consist of a wide variety of packet sizes and for different purposes moving in many directions on the network. It tends, on average, to be symmetric with respect to the direction of traffic — some coming, some going. Ethernet is broadly seen as a natural choice for such traffic.

In contrast, streaming data, as emitted by sensors, may have no natural demarcations that make packetizing easy. While chunks of the stream can be placed into packets, typically it’s done at some arbitrary interval. In addition, traffic tends to be highly asymmetric and unidirectional.

“You have a lot of data coming from a sensor to the car, and you need maybe a little bit of data in the other direction to configure the sensor,” said Robert Schweiger, director of automotive solutions at Cadence. “For the display, it’s exactly the opposite. You have a lot of data going to the display to show all kinds of things. But it needs no communication to the data source.”

Ethernet is not seen as an efficient networking choice for streaming data. Because Ethernet is inherently bi-directional, that back-channel capacity largely will be wasted. This is probably the starkest example of where the OEM desire for a single network collides with practical considerations.

There’s also the distinction between external data — such as V2X communication with the local infrastructure or the infotainment feed — and internal data, which is both produced and consumed internally. The external communication by necessity will be wireless, meaning that its networking needs will be different from what’s handled internally over wires.

“The radio module will talk to the computer by way of PCIe,” noted Tom Wong, director of marketing, design IP at Cadence.

Bandwidth requirements
Ethernet speeds aren’t required for low-level control messaging. They’re driven by the needs of infotainment, advanced driver-assist systems (ADAS), and telematics.

One of the main challenges for a central scheme is bandwidth, which can easily add up towards 10 Gbps. “We’re quite a ways away from 10 Gbps, let alone 100,” noted Fritz. “With automotive Ethernet, we’re at 1 Gbps.”

But internal needs are likely to exceed that, especially for streaming data to a central processor. Radar data wouldn’t require 1G Ethernet, but a lower-speed Ethernet could work. Cameras could work with Ethernet, and if lidar is added, then the combined camera/lidar data would need high-speed Ethernet.

There are 10 Gbps PHYs out there, but they’re complex — and therefore expensive. And they’re available only as separate chips, not as IP for integration into SoCs.

“From a business point of view, and from the number of PHYs that will go into a car, it might be interesting to have this 10-Gb Ethernet PHY as IP,” said Schweiger. “Most likely, the first incarnations will be external PHY, and later on maybe an integrated version.”

Even if such IP was available, however, there’s still a thermal concern. These drivers heat up, and that heat needs to be managed with a heat sink. It’s less expensive to put a heat sink on a small driver-only chip. It would be more expensive to burden the cost of an entire SoC with heat sinks required only for the Ethernet drivers.

“Imagine you’re putting a bunch of high-speed Ethernet PHYs into an SoC, and you’ve got five different channels all driving 20- or 30- or even 50-foot-long cables,” said Cadence’s Wong. “The SoC heats up, so the low-cost packaging for the SoC gets thrown out of the door. You have to go to a heat sink package, and the cost goes up not because of the silicon, but because of the package and heat sink.”

Bandwidth needs may be less than 10 Gbps — for example, 2.5 or 5 Gbps — but it’s expected that dedicated devices will not be available for those speeds. Instead, one would jump from 1 to 10 Gbps, but dial back the clocks to the needed rate. That said, a central architecture may exceed even 10 Gbps of needed bandwidth, putting it out of reach for even the most advanced PHY chips today.

This is an additional reason why the zonal architecture is most in favor today. High-bandwidth activity can be handled locally, with higher-level data — which is naturally compressed compared to raw data — requiring less bandwidth to be communicated to a central processor.

Given this arrangement, it’s broadly (but not universally) expected that Ethernet would act as the backbone network that all of the zones would use to communicate with the central hub. The remaining question is what happens within the zones, and the answer to that isn’t clear.

Zonal conflict
Within a zone, there are a number of different functions being performed. The ones that resist Ethernet the most are the streaming ones, which today tend to be dominated by MIPI-based protocols. While MIPI’s D-PHY and C-PHY dominate in cellphones, the organization has come up with a serial A-PHY version that can handle a reach of up to 15 meters in a vehicle. The new ASA group, meanwhile, has put forth a different serial standard to handle automotive camera and display data. It’s not clear which of these will dominate.

Availability and multiple sources are an important consideration. “We do not want to have one supplier,” said Schweiger. “We want to have five of them or even more, so that we do not run into supply chain issues.”

Swanson concurs. “A lot of the OEMs want to stick to the standards, but they want the standards to enable them to play their vendors off against each other.”

For slower control-related messaging, CAN has dominated historically, and it could still exist within the zone. Alternatively, the new 10-BASE-T1S gives a twisted-pair multi-drop option that runs up to 10 Mbps.

“10-BASE-T1S is actually architected as a CAN replacement,” noted Swanson. It’s nowhere near fast enough for the streaming data, but it could work fine for control.

“When you control your comfort ECU — the one that leans your seats, up down, and backwards — that is pretty much an on/off switch,” noted Kouthon. “You don’t need Ethernet for that. It will be overkill. The truth is that legacy networks like CAN or LIN are adequate.”

But there may be yet another alternative if an asynchronous Ethernet version surfaces. “There are people in favor of promoting so-called asynchronous Ethernet communication,” said Schweiger. “So you have broad bandwidth in one direction, reduced bandwidth in the other direction.”

While it’s not clear exactly what that would be, it would presumably have the benefit of leveraging much of the work done to implement the current automotive Ethernet portions of the vehicle, unifying the networking to a greater extent.

There’s also the question of scale. Some see the interface decision for cars being driven by what’s being done in cellphones, which sell in much higher volumes. If camera makers focus exclusively on the formats that go into cellphones (which, today, are MIPI), then that might trump the other preferences that the Tier-1 suppliers or OEMs may have.

Security and reliability
Security is an obvious concern within vehicles, given the public way in which some vehicles have been breached. MacSec, a layer-2 security protocol, is expected to be deployed within vehicles, and its availability adds to the reasons why Ethernet is a leading contender.

“MacSec, which is a line-rate technology, has almost no impact on latency or bandwidth,” said Kouthon. “It can be used to authenticate all the sensors with the central control unit, so that now you know that you’re receiving the real camera feed from the actual camera of the vehicle. You’re not receiving it from a man in the middle.”

But there are two main streams to protect in the car — the internally generated traffic, which in theory, can’t be breached without a physical connection somehow, and the flow of data entering the car via the external wireless connection.

The wireless signal connects both to safety-critical V2X communications, as well as the non-critical infotainment stream. These flows also will need to be protected at higher levels of the stack.

A zonal architecture may provide higher security by itself. “If you have zones limited by gateways, that increases the security level,” said Kouthon. “It’s easier to manage security when you have segmented VLANs, where you know who is authorized to talk to another sub-network.”

Reliability, meanwhile, is important for safety-critical aspects of the network. Noise that’s bad enough to corrupt messages could have a serious impact.

“If you lose your screen, it’s annoying but it’s not safety critical,” explained Patel. “But if the ADAS system, which relies on secure connectivity, sends the wrong message or the message is corrupted, that’s a catastrophe.”

While there is a strong desire to use unshielded twisted pair cabling for both cost and weight reasons, there’s too much EMI within the vehicle, and shielded twisted pair appears to be required to protect against that noise.

Automotive Ethernet interop
There’s also more work being done to improve the TSN features being leveraged in automotive Ethernet. Ethernet is an OSI layer 2 protocol, attaching to a variety of PHY (layer 1) options. For standard Ethernet — as used in office networking, for example — layer 3 is typically IP, and layer 4 is usually TCP, but occasionally UDP.

So while Ethernet features in many applications, it’s just one layer in the overall networking stack. But today’s notion of “automotive Ethernet” takes a layer-2 concept and assigns it to the entire stack. In fact, this appears to have worked its way into the thinking as the TSN features were standardized.

“Every communications protocol in automotive has been a full stack up until Ethernet,” said Schlechter. “In automotive Ethernet, they’re actually talking about some of the transport.”

Fig. 2: The 7-layer OSI networking stack. On the left, a typical desktop computing stack is shown up through the transport layer. On the right, the TSN features have spanned what would have normally been layers far outside the scope of Ethernet. Source: Bryon Moyer/Semiconductor Engineering

The TSN features were specified at a level that provides interop between systems, and it included elements that may traditionally reside on higher layers. The full stack tends to be implemented in software for the upper layers, with hardware dominating at layer 1 and parts of layer 2. It turns out that, while systems may interoperate, the TSN specifications haven’t been set at a level that allows silicon chips to interoperate clearly.

The result has been different “flavors” of Ethernet for these different markets. “There’s an automotive profile, an industrial profile, a service-provider profile, and an aerospace profile,” said Swanson. “There might be some others. And we’re also talking to the 5G folks to make sure all this stuff works together.”

That’s inconsistent with the original Ethernet, however. “That’s not how Ethernet works,” said Schlechter. “There really shouldn’t be those things in front of the word ‘Ethernet’. It’s just ‘Ethernet.’”

The economics of automotive chips improve if chipmakers can sell a chip into more than one market. “Even though you have these different verticals using it, at the end of the day, sometimes the same component can go into these different markets,” said Schlechter.

Others agree. “Today in standard Ethernet, a MAC (media access controller, at the bottom of layer 2) is a MAC is a MAC, and what we want to get to with TSN is just another MAC,” said Tom Weingartner, silicon validation task group chair for the Avnu Alliance and marketing director for the deterministic Ethernet technology group at Analog Devices. “But the specifications don’t necessarily say, ‘You need to change that MAC this way so that everybody’s MAC works together.’”

Much of this isn’t about compliance per se, because most of these TSN features are optional. “This is the way the economies of scale with Ethernet come,” noted Schlechter. “Every time anybody uses Ethernet, there are a hundred things you don’t use.”

But where capabilities exist, it’s hard to compare chips to see which ones have the necessary features and performance. So efforts are underway in the Avnu Alliance to further specify features at a level that will promote, or at least clarify, interoperability between different silicon implementations of the TSN features.

“Sometimes we just need the common yardstick,” observed Schlechter.

Conclusion
Automotive networking is still very much an open discussion. It has enough visibility with the OEMs that Volkswagen has spun off a group specifically to deal with networking. The odds now are in favor of a zonal architecture with Ethernet as the backbone, although that’s not assured, and some OEMs may go in a different direction.

Bandwidth needs will continue to grow for the foreseeable future, although they may level off at some distant point in the future. “It could be 5 years, it could be 10 years, but we are going to get to level 5 — hands-off, mind-off, eyes-off, go to sleep and the car’s moving,” said Wong. “And that represents the highest practical bandwidth requirement.”

Within zones, there are numerous possible networks that can be included. For the time being, that variety is likely to remain. The question is whether they’ll migrate over time to some version of Ethernet. It’s not going to happen quickly, because for design risk reasons changes will come incrementally as needed.

“The OEMs are definitely interested in consolidating on a single network because it makes everything simpler,” said Swanson. “But you’re not going to go to a single network overnight.”

And how far Ethernet pervades the car won’t ultimately be known for many years.

Related
Vehicle Communications Network Is Due For Overhaul
Security is becoming bigger risk as vehicle automation increases; fixes and alternatives are in the works.
Data Centers On Wheels
Automakers shifting to HPC chips for improved performance and lower system cost.
Changes in Auto Architectures
From driver-centric to driverless functionality.
Big Changes Ahead For Connected Vehicles
Tapping into multiple services, both inside and outside a car, requires a rethinking of everything from architectures to security.
Battle Brewing Over Automotive Display Protocols
Different options and standards will take years to sort out.