Hacker News Reader

Comment by outworlder | Hacker News Reader

We can simplify the wire mess today by using more CAN bus devices.

What is ethernet bringing to the picture?

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

> What is ethernet bringing to the picture?

Over 3 orders of magnitude faster datarates.

CAN FD: up to 5Mb/s

Automotive Ethernet: up to 10 Gb/s

Why would you need 10 Gb/s speeds in a car

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.

And hack/steal, right?

10 Gb/s is not all that much for cameras. Enough for one 60 Hz 4k 14-bit depth camera transmitting raw bayer data.

60 Hz * 3840 * 2160 * 14bit is 6.96 Gbps.

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.

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.

Larger packets and bandwidths.

Bandwidth: you can't ship backup camera video or entertainment system audio over CAN, for example.

CAN was meant for short, real-time packets. 8 bytes in initial configuration. CAN FD allows 64 byte packets.

You spend a LOT of protocol doing packet fragmentation and assembly using CAN--which then negates a lot of the real-time guarantees.

CAN should be used for the short safety critical stuff. Ethernet should be used for everything else.

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.

> What is ethernet bringing to the picture?

More speed and zonal architecture:

* https://www.electronicdesign.com/markets/automotive/article/...

* https://www.bosch-mobility.com/en/solutions/control-units/zo...

I'll bet a hidden factor here is development and testing.

They can probably develop for a car ethernet lan with a desktop pc and car "peripherals".

Not that there aren't canbus cards for pcs, but still.

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.

CAN to PC adapters are a few hundred dollars, it isn't causing much friction.

With ethernet you can probably run the car software in containers.

I can imagine a container to simulate each hardware unit, a small inter-contaner lan, and develop code that way.

Reminds me when my Opel resetted itself while driving on the highway. Oh, the adrenaline...

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.

1. https://netmodule-linux.readthedocs.io/en/latest/howto/can.h...

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

Central bus instead of many point to point connections. Look at how much fewer cabling the cybertruck has.

CAN is also a bus, that's not really a point in favor of ethernet.

Ethernet can do both bus and switched. High speed switches enables a lot of architecture not easily enabled by CAN.

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.

Industrial Ethernet (PROFINET) also has priorities and bandwidth reservation: https://en.wikipedia.org/wiki/Profinet#Technology_of_Class_C...

Bitrate and max devices for CAN are limited.

Bandwidth?

Reply on news.ycombinator.com