Excellent article, Junko, which I think explains exactly how Ethernet is being and will be introduced into cars. Just as it has in may other control system environments, in spite of early stage frights by system designers.
I don't think the number of Ethernet switches in the car is a good metric for anything, though. A more important number would be the number of Ethernet hosts, i.e. end systems, connecting into the Ethernet network(s). An Ethernet "switch," which refers to a layer two "multiport bridge," is nothing more than a fan-out device in Ethernet nets. That's all. You do gain in survivability and reliability of you create a relatively dense mesh of switches, interconnected by multiple links, providing for redundant paths that can take over almost instantly if one breaks.
However there is not good correclation between the number of switches and the number of Ethernet end system, is my main point. I prefer many switches with not too many ports in each one. Others tend to go for fewer big switches.
Thanks, Bert. You raise some good points about "Ethernet switches" not being necessarily a good metric.
I think these two gentlemen who were asked questions happen to be in the business of developing automotive Ethernet switch chips -- thus they related their answers more to the potential market for their product.
"safety demands are paramount, a long product development cycle is a given" captures the main roadblock of in-vehicle-network.
Looking at it from the angle, if a safety feature which demands high-bandwidth communication is getting a lot of attention from consumers, auto makers will certainly add it together with the infotainment. Question is what the feature is; HD front camera to capture incident in case of accident. ;)
Excellent point. Multiple small switches might provide better fault tolerant than 1 big interconnected switch. Daisy-chain is probably not a very good idea for sure. Will In-Vehicle-Network open up new opportunity of routing technology?
@chanj, make no mistake. HD front, rear and side cameras featured in a car will be driving this, for safety applications. In fact, the high-bandwidth demand for automotive is real and even more paramount, because autmotive companies don't even want to "compress" the video streams captured by HD cameras!
Junko, when I hear things like "don't want to compress video streams" or "must have isochronous network," I flat don't believe it. Sounds close to knee-jerk position statements, bound to evolve as people design these things.
Uncompressed HD video, just one stream, would require 1.5 Gb/s just for black and white video. That's just one stream. A Gigabit Ethernet network wouldn't even be able to handle a single B&W camera.
Junko & Bert: good points. I do agree it will require much more than 1.5Gbps to broadcast color videos. Bert is also right in bringing out a metric that matters which is the number/redundancy of hosts. At the bare minimum, there needs to 2 or more depending on the location in the vehicle and the corresponding failure rates FITs.
Regarding uncompressed video, most industrial ethernet cables & connectors (M6, M12) use gigabit ethernet which will not be sufficient for color video. But then again, video used in navigation can be of lower resolution to utilize what is available as bandwidth.
Thank you Junko for a nice article shedding a bit of light inside the usually top secret automotive Ethernet domain. Also thanks everyone for the interesting discussion. In fact I registered just now to contribute here.
I am currently building an infotainment system for an academic research vehicle (TUM CREATE EVA, www.tumcreate.edu.sg). We are also including HD cameras (front & back). We stumbled across a few problems when using compressed streams, depending on the stream format. When using H.264 streams, there is always a certain buffer needed to decode the stream. This buffer comes with a certain delay. Especially for real-time parking cameras this is deadly.
I could imagine that this is where car manufacturers are coming from when asking for uncompressed video. Their requirement might be a short delay.
We instead use MJPEG coding, which allows us to reduce the stream delay to a minimum.
All in all: Once understood, it is for sure possible to combine the requirements of the automotive industry with the technologies already in the market, to be able to transfer real-time video while using small bandwidth.
One more comment regarding Ethernet switches, as this also touches on my research: The amount of switches is indeed not a good measure, however, comparing Ethernet to CAN, one might consider a switch overhead for the communication system. Those devices of course consume power and weight, which is all unwanted by the automotive industry.
However, I am fully with Bert in rather using many smaller switches instead of one big switch, especially for in-vehicle networks. One big switch would introduce more and longer heavy cables, while multiple smaller switches introduce latency. One needs to compare these elements and decides for a good structure.
@Chan: Daisy-chains are not necessarily bad, they can actually bring advantages, when networked correctly with the rest of the system. Pure daisy-chains I would avoid though. And I fully agree, there will be new topologies and routing strategies necessary for vehicles! The need is definitely there.
One last comment in my own interest: We will be unveiling our purpose-built electric taxi EVA on the Tokyo Motor Show 2013 in November. Feel free to come by TUM CREATE booth, if any of you are there. I would love to discuss these topics in more detail!
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.