Ethernet seems a logical choice for in-vehicle networking due to speed and cost advantages. How is the automotive industry leveraging Ethernet today?

TAN: Ethernet, of course, has been extremely successful in the consumer and enterprise space, but is also used in many other applications. One of the first areas that it moved into was on the industrial side where basically it was shown that you can take this IP-based, non-deterministic, loose network and use it to control real-time systems and critical systems. It moved into industrial where it was adopted for PROFINET, SERCOS III, and DeviceNet, but a number of different industrial technologies. It also went into the smart grid for electrical distribution. The model there was to take standard Ethernet and then develop the upper level protocols that work on top of the IP to allow real-time operation.

In the car, what drove interest in Ethernet was really the need for bandwidth. I believe BMW was the first company that was very vocal about this. They looked at the situation back in 2007 and said, “In the mid-2010s we’re going to have so many processors running so many lines of code that if we use the existing proprietary technology, if there’s any reason to flash the software, a BMW owner’s going to have to bring in their car for two days to be able to flash everything.” That’s a huge problem, and there you give them credit for looking forward to bring in a new technology, and naturally they looked at Ethernet.

The first thing they found is that, from a protocol standpoint, Ethernet was pretty good, but the physical layer of the vehicle network itself didn’t match the requirements for Ethernet because the physical layer for a car is extremely unique and robust: you have EMI concerns; you have ruggedness concerns; your cables go under water and get dirty and shake; and the weight even of a cable, even of a screw for these car manufacturers, adds to the cost in terms of miles per gallon.

That’s where the industry was before they moved into Ethernet, so two things had to happen. One thing was the development of single-pair Ethernet (100BASE-T1) through the IEEE, and then the development of Gigabit Ethernet (GbE), the 1000BASE-T1.

Once you bring Ethernet into a system, whether it’s automotive, industrial, smart grid, or energy infrastructure, you find that there are many, many other advantages and new capabilities that are enabled by that kind of bandwidth. Even 100 Mb Ethernet that’s bi-directional, configurable, and IP-based gives you a lot of capability, and is very different from anything that’s been in the car before. If you look at CAN or LIN or MOST, each of those had a very specifically defined architecture designed for specific applications in the car, but where MOST was for infotainment, CAN for control signals, and LIN for safety, with the advent of Ethernet you can take CAN signals, for instance, encapsulate them in IP packages, and send them through your CAN network. This opens up an explosion of new applications.

Today everybody’s talking about how, by the mid 2020s, there will be various levels of autonomous cars. Well, the technology’s there today, of course, we just have to look at what Google’s doing or what Audi did two CESs ago when a car drove itself from San Francisco to Las Vegas. But taking that and making it into a production car that you can buy for your kids as their first car when they get out of school, that’s a huge difference, right? It’s not just having the technology, but it has to meet automotive requirements and automotive costs, too.

The GbE that we’re developing is the backbone or infrastructure to connect the different domains in the car – what was traditionally an infotainment domain, an advanced driver assistance system (ADAS) domain, a body electronics domain, and a control domain – and connecting them all together. The next step is using that information to connect with the other sensors that are required for autonomous vehicles. All of these can act together and give you the performance you need.

The second step is not just connecting the inside of the car, but connecting the car to the cloud. Your car becomes an extension of the Internet of Things (IoT). Just recently I changed the lock on my house to one that’s Apple HomeKit compatible so I can use my phone and see whether or not my front door is locked. My car should be able to tell me the same thing, and, in fact, there’s more information I want from my car. Is it locked? What’s the temperature inside? Is it low on gas? If you get locked out, wouldn’t it be great to be able to grab your phone and get in there and open it up? All these things are really useful.

That’s what Ethernet gives you. It’s this really flexible backbone so that if there is a new application, that new application can be added to cars. You need the flexibility that the architecture you build today can allow your car to support features that haven’t even been thought of yet. As it is, it’s really hard because an architect is going to be designing maybe five to seven years in advance of release, and they have to already be thinking what the marketing guy that’s selling a Ford Fiesta going to want for their infotainment system in seven years, which is pretty much impossible.

Ethernet presents concerns about packet loss. How does automotive-grade Ethernet reduce packet loss that could have huge ramifications on vehicle safety?

TAN: The basis of that answer comes from industrial, because before automotive picked it up, the industrial guys found ways to take their old PROFIBUS-type technology and replace it with Ethernet. In those scenarios, if you’re using Ethernet to control a robotic arm and lose one of your data packets, the arm could go where it shouldn’t be and that could be extremely dangerous as well as very bad for manufacturing. So a number of real time protocols were developed that basically sit on top of the IP and allow deterministic, real-time control over a fundamentally non-deterministic network. One of the base technologies was an IEEE standard called the 1588 precision time protocol (PTP), and that protocol allowed different nodes on the network to exchange their times so they could operate synchronously (Figure 1). That’s robust enough for a very controlled environment, but the next step is to make sure you don’t lose packets because Ethernet by nature is bursty, meaning an event happens where you send as much data as you can, use the full bandwidth, and nothing is sent, or you have two events at the same time each fighting for bandwidth.

[Figure 1 | The IEEE 1588 precision time protocol was designed to synchronize Ethernet-based embedded systems for real-time operation.]

Fortunately, there’s a subset of standards called IEEE 802.1AS that was developed for audio video bridging (AVB) and whose interoperability is governed by the AVnu Alliance. Originally, these standards were designed for professional concert venues because, again, you need to have accurate timing but that’s not good enough if every note is at the same time but the audio doesn’t get to one of the speakers because it’s blocked by another packet indicating status or something. What AVB does is allow you to allocate bandwidth on your network dynamically so that you have the bandwidth you need to protect time-dependent streaming flows (Figure 2).

[Figure 2 | The Audio Video Bridging (AVB) portion of IEEE 802.1AS was developed to ensure the delivery of time-dependent streaming flows to various network nodes through traffic shaping.]

AVB technology is now being adapted for automotive and industrial applications by a new set of 802.1 sub standards called Time-Sensitive Networking (TSN) that are moving away from the audio/video route (Figure 3). TSN takes it to the next level to guarantee traffic protection and delivery. For instance, in a car system today, you would use AVB with these TSN extensions in your software for your switches and your PHYs, and then all of your input data is guaranteed 50 Mbps, or whatever the required bandwidth is. But then, if you turn off the input system, that bandwidth becomes completely available if you want to do a one-time flash to update all of your processors, for example. So it’s not as limiting as saying that we have a completely segregated network just for video, say, but instead it allows you to protect the video that needs to be protected and to take advantage of the full use of the system as well. The other part of that is that you do hit your limits, and that’s where GbE becomes really valuable because if you have different networks operating at 100 Mb speeds and connect them over GbE, you don’t need to worry about the high-level data that’s being aggregated getting lost in transfer.

[Figure 3 | The new Time-Sensitive Networking (TSN) group of IEEE standards extends the determinism of AVB for Ethernet-based networks by dedicating network resources to particular nodes/applications.]

The automotive guys didn’t have to do anything other than adopt the technology that had already been designed and proven for industrial and for audio. This is one of the areas Marvell Semiconductor has been a technology leader in developing both PTP and also the AVB TSN, and we implement a lot of the more computationally difficult parts of those protocols directly in our hardware (Figure 4). So this makes it much easier to make the software and administrate the network and it also makes the network much faster, reducing latency so they can operate fast enough for the requirements of a car where you’re sending video as you’re driving along the road or something like that.

[Figure 4 | Marvell’s automotive Ethernet reference platform with integrated MATEnet connectors for Automotive Ethernet from TE Connectivity includes two 1000BASE-T1 PHY, two 100BASE-T1 PHYs, two standard Ethernet PHYs, and a built in switch supporting Audio/Video Bridging and Time-Sensitive Networking (TSN) protocols.]

Will automotive-grade Ethernet keep pushing bandwidth like we’ve seen in traditional network infrastructure?

TAN: I was in Munich for the Automotive Ethernet Congress and during the first keynote speech, there was a question to the crowd about exactly that: Are we done here with 1GB? It was very clear from the number of hands in the crowd that there’s a lot of interest in higher speed Ethernet. It’s interesting, because what I see is that in two to five years time, the most sophisticated IT professionals in the world will be working at the major car companies. They will be doing the most amazing things with real-time and TSN and future technologies. Going forward it will get faster because they moved directly from 100 Mb to GbE in a short period of time and there’s already interest in compelling applications for higher speed solutions. 10 GbE in the car is very much a possibility in the next decade or so. Absolutely.

Marvell Semiconductor

www.marvell.com/solutions/automotive

@marvellsemi

LinkedIn: www.linkedin.com/company/3772

Facebook: www.facebook.com/MarvellSemiconductor

YouTube: www.youtube.com/user/marvellmedia

Google+: plus.google.com/111540192483002553954