CAN is slow. At best it's around 1Mbit, but you get into electrical limitations. So you have to run multiple CAN buses in parallel and carefully manage bandwidth limitations.
My Chevy Volt had 4 different CAN buses and one additional LIN bus.
This can all be replaced with just two Ethernet buses: for safety-critical and non-critical uses. And the gigabit speed provides plenty of bandwidth for any reasonable sensor traffic, even including camera feeds.
The current architecture was justified in 90-s when LIN PHYs were an order of magnitude cheaper than even CAN PHYs. Now Gigabit Ethernet PHYs cost less than a dollar.
It's unlikely that the multiple CAN buses are being used to increase speed by, say multiplexing them. In general, vehicles use multiple CAN buses for enhanced security. For example: things like diagnostic ports are often on their own CAN buses so data can't be directly injected into onboard systems.
All but one CAN bus in my Volt were connected to the OBD port. The unconnected bus controlled the high-voltage battery contactors and some other critical stuff.
The "main" bus was saturated with data, more than 80% of bandwidth utilization at 512kbs. And it kinda had a mix of everything, from street names to be displayed on the dashboard to ECU messages. The other two buses had some random messages, with no rhyme or reason for the split ( https://vehicle-reverse-engineering.fandom.com/wiki/GM_Volt ).
FSD will benefit from high-resolution (4K or above) camera feeds (for things like reading signs and detecting small obstacles). You can do this in a 10Gbps network and have tons of headroom for every other function the car will perform.
Why would you not? Tesla is sending even the infortainment data stream through that bus. It's incredibly helpful having all data travel on a singular wire because you can tap in at one point and read it all out. Makes the entire system significantly easier to debug, understand and develop against.
It's a good thing we invented video compression and hardware codecs/encoders a long time ago.
What you'll actually be sending is a high bitrate mpeg stream, probably 54Mbps or thereabouts, you could probably fit 50x camera streams on a shared 10Gbps bus.
Ethernet can handle real time now even in bus configurations!
10BASE-T1S is a new standard geared for automotive. It uses physical layer collision avoidance instead of classic Ethernet exponential backoff. This provides deterministic maximum latency.
Though you can get max latency guarantees with switched Ethernet and the appropriate switch QoS and hardware.
This sounds like the real answer. Replacing an automotive standard with Ethernet is going to reduce friction onboarding junior webdevs with MacBooks, and enable a more stable higher turnover labor intensive organization.
You can already do this trivially with Linux vcan[1] so I don't buy this argument.
I think the bigger factor is that innovation in the CAN ecosystem has been lagging behind Ethernet for decades now. Only reason it's had such staying power is industry inertia.
The relative cost is probably a factor (which overlaps with inertia of course, but if the thing you already have implemented is also cheaper, you aren't going to hurry up and change).
CAN has desirable electrical properties (e.g. hardware-level prioritization) if you have life-critical devices and non-life-critical devices on the same network. But it's painful to deal with from a software point of view, compared to IP-based protocols, for anything that doesn't require the properties of CAN.
My Chevy Volt had 4 different CAN buses and one additional LIN bus.
This can all be replaced with just two Ethernet buses: for safety-critical and non-critical uses. And the gigabit speed provides plenty of bandwidth for any reasonable sensor traffic, even including camera feeds.
The current architecture was justified in 90-s when LIN PHYs were an order of magnitude cheaper than even CAN PHYs. Now Gigabit Ethernet PHYs cost less than a dollar.