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.
@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.
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.
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.
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.
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.
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?)
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.