NXP: 3 Phases of Automotive Ethernet

One concern related to automotive Ethernet efforts is power management. "Ethernet will need to adopt a methodology similar to partial networking, which is available in CAN bus today," Hank said. When a variety of ECUs are attached to an Ethernet backbone, not everything needs to be powered on all the time. "You should be able to shut down part of the network in order to save energy. A rear-view camera, for example, should be powered off when a car is moving forward."

The fact that "the Ethernet is not time triggered" is another concern. Hank wrote in an NXP whitepaper published on our site in March: "Ethernet has not been developed for TDMA networking, and one topic that still needs to be addressed for automotive systems is a suitable solution to achieve the required real-time performance and Quality of Service."

The AVnu Alliance's audio/video bridging (AVB) task group already includes measures to ensure the timely delivery of media streams. As Hank explained in the whitepaper (written for the Automotive AVB Gen2 Work Group), latency time improvements are a major target for this group.

First applications for Time-Triggered Ethernet took place in Avionic systems with highest safety level requirements. Defined in SAE AS6802 and different to Audio/Video Bridging, TTEthernet is based on a distributed clock-synchronization algorithm that finally results in an exact schedule with deterministic behavior.
Although the integration of both AVB and TTEthernet is possible, further investigations are needed to allow its use in automotive applications where multimedia streams, real-time control data as well as diagnostic information and software updates will be transmitted on the same network..

The goal is to shorten latency in automotive Ethernet and make it closer to that of FlexRay.

Does the emerging Gigabit Ethernet for automotive applications mean that the currently de facto 100Mbit/s BroadR-Reach automotive Ethernet will be eventually replaced? Not really. Hank told us that, aside from higher-resolution uncompressed video, and more powerful and complex processing applications, Gigabit will be overkill in data paths for radar information or audio, for example. There will be costs associated with Gigabit Ethernet, so carmakers will limit its use to applications that absolutely require more bandwidth muscle.

When asked where Ethernet switches will be placed inside a car and how many will be needed, Hank said, "It is still an ongoing debate, as we work on the concept." Presumably, one could design one big switch box and place it at a central location in a car. But carmakers are more likely to opt for smaller, delocalized switches. "I think they want more flexibility."

NXP is fully on board with BroadR-Reach-based automotive Ethernet. Stephan Rave, the company's product marketing manager responsible for advanced networks, told us its first BroadR-Reach phy chips are sampling now.

Hank said that, though the BroadR-Reach draft specification is very close to being final, "the Open Alliance SIG will still need to finalize the spec, so that all the changes are made clear and every chip is developed based on the clear spec." The next step for the Open Alliance SIG is to establish a compliance test, so that OEMs will be assured of interoperability.

I can see why NXP or Broadcome push for :automotive Ethernet...but are the car companies really behind this? what is wrong with CAN? (it is probably more expensive to deploy as Ethernet volumes are much larger, but technically?)

I think, a problem with CAN is that it is too slow. The OEMs need a faster solution e.g. for camera systems and other bandwidth consuming applications. And I think, they need a faster solution because they get problems to flash all the ECUs of a car at the production time.

Krisi, car companies are definitely embracing Ethernet in places where CAN or FlexRay can't address. For all those cameras now attached to a car for driver's assistance, CAN nor FlexRay can cut it due to the higher bandwidth required. Further if you want to update software in ECU, it could take like 30 min. If you do it over CAN. (remember flas memory is getting bigger and bigger.)
So moving to Ethernet is a natural progression for Car OEMs. The question is how far Ethernet will penetrate inside a car and what needs to happen before that becomes a reality.

Migrating to Ethernet has been the trend for decades now. Even the telcos, who were often nay-sayers, have done this. ATM and SONET migrating to Ethernet as we speak.

No need to do this instantly. CAN buses can remain for strictly timed, local bus roles, until the subsystems are updated. At which point, my bet is, CAN buses will also be replaced by Ethernet.

A way to solve the latency problem is to create local Ethernets, generously overprovisioned, and make sure they remain overprovisioned. Which means, you make sure that wide bandwidth traffic does not intrude. You'll get good bandwidth and low latency, at a lower price than attempting to create fancy new synchronous buses.

The number of Ethernet switches required depends 100 percent on what the Ethernet(s) have to do. My own preference is always many small switches, properly distributed to be close to the client devices, to achieve robust reliability and survivability. You don't want that single point of failure, in other words. Signals should have redundant paths, and just like OBD-II monitors the emissions devices in the car, the Ethernet network(s) would also be monitored at all times, and failures reported.

The solution using "generously overprovisioned local Ethernets" will not work in many situations (as replacement for FlexRay/CAN or even LIN). Such approach can work for i.e. telcos but in automotive it has limited applicability.

There are devices which need to be hard real-time and moreover you have to prove that you can achieve this hard real-time property (ISO 26262). A "good bandwidth" does not guarantee this.

@Bert: good points. I agree there is no immediate rush to implement Ethernet replacing CANs. In addition to the many good points you raised, there is also the issue of existing Ethernet PMDs to co-exist / replace CANs which have proven their robustness and reliability over the years in the automobile environment. There is of course industrial Ethernet physical media but their suitability to automobile environment has to be proven for reliability.

In my opinion also ,just the over-provisioning will not solve the latency problem of Ethernet. So CAN kind of network will still be required for critical systems such as ECU, ABS... A good combination of CAN and Ethernet could be a median solution.