On the Stanford Solar Car Project -- a mostly-undergrad student group -- we always built our cars with two physically separate CAN buses, one for nonessential features and one for the motor controller.
That way, we limited our surface area for catastrophic bugs: the only things connected to the safety-critical CAN bus were the motor controller itself and the throttle board.
This for a one-off experimental vehicle.
CAN is a very simple, unauthenticated bus. Any device can send a message that every other device on the bus will receive. Messages are typically just a few bytes long, binary encoded.
The idea of attaching an internet-connected infotainment computer to the same CAN bus as the brakes is absurd. Doing so on a production car, even more so.
--
The Ford story is disappointing but not totally new.
> CAN is a very simple, unauthenticated bus. Any device can send a message that every other device on the bus will receive.
True, but in practice messages that are deemed important are secured at higher OSI levels, and the identity of important bus participants is cryptographically checked during vehicle startup.
> The idea of attaching an internet-connected infotainment computer to the same CAN bus as the brakes is absurd. Doing so on a production car, even more so.
Which is why all vehicle architectures I'm familiar with have a bunch of CAN (and other) buses.
Maybe it used to be different, and I certainly know only a few bus architectures, but they make a honest attempt at securing the important bits at least.
Industry engineers may not get everything right, but they're not that stupid. Cut them some slack.
IMO there should be separate infotainment and hi-speed system CAN buses. It's lunacy to place engine control on the same bus as something with internet access that doesn't get upgraded, like, ever. I don't care how well it's tested.
Agreed – FYI: Tesla Model S (and likely X and 3) vehicles use a locked-down gateway (offering specific API actions, which result in CAN communication, etc) between their Ethernet network and CAN [1]
That's how it is on my car, but at the same time my car basically has no fancy electronics.
I understand software engineers pulling stunts like this, because there isn't actually a regulated engineering license, but I'd honestly have expected automotive engineers to be vehemently opposed to putting the stereo on the same system as the brakes.
It's not the software engineers that are the problem it's the automotive design managers who decide that there will be one computer and one buss.
The DOT should have standards for this stuff. Infotainment system shouldn't have control authority or share critical buses with the engine and braking/traction control system.
I wonder if some of this is to do with weight reduction. To have seperate buses must add a lot of extra equipment and wiring.
This means more weight and more power required to operate the electrics and in turn means lower MPG, higher fuel consumption and a more expensive car to design and manufacture.
The net outcome is a less competitive car in a competitive market.
I've worked with software engineers working on the CAN bus, and I had the same questions as you. According to them it has to do with the amount of cabling needed as well as electrical interference. A car has a lot of cabling going all over (a couple of hundred meters in total was the number I got), and if you can put as much of it as possible on the same bus(es), you save yourself a lot of problems.
So I suppose weight could be a factor, but space seems to be the big one.
I mean "a lot" in computer terms is like 4 lbs of equipment but since the brake pads on a truck weigh in at more than that I assume its not weight related.
Most modules have some feature or other that needs to communicate with infotainment or another module that needs to communicate with infotainment. Error reporting is the big one, but there's lots of little ones too. The brake module, for example, may be involved in tire pressure sensing, and also takes configuration for traction control and reports activation.
It's hard to find an appropriate segmentation for an air gap without sacrificing features, and most customers won't trade features for "security".
You are right of course. But still. Once you can talk over the CAN bus you can spoof pretty much anything, if I recall correctly. You could at least have some intermediary module on both buses that acts as a proxy. Then if someone hacks your radio they can't pretend to be the ECM.
The infotainment system should only be allowed to read values from the modules related to the actual driving. Configuring things like traction control will just have to be done via a system separate from the infotainment system.
I understand that it a little wasteful to not use that big touch screen in the center console to do configuration of the driving experience, but there's no safe way to do so.
> Modern electronic cars use a single bus (CAN bus) that connect all electrical systems. The brakes, the engine, the wipers, the stereo...
Not true.
The automotive bus architectures I know first hand (admittedly far from all of them of course) have multiple CAN buses, plus other bus technologies as well (MOST/LIN/Ethernet).
I don't think it would even be possible from a bandwidth/latency standpoint to push everything across a single CAN bus.
I had Hughes as a lecturer in University (Chalmers, Sweden) and we heavily utilized quick check in our Haskell courses. He’s a great lecturer and a brilliant mind, I do think they still teach new CS students Haskell with QuickCheck as a first course.
There should be at least two if not more CAN buses in a modern vehicle. The NHTSA should mandate that safety critical systems be on their own (redundant) network.
Yeah, that's a terrible idea. You should have at least three separate communication channels, and the most critical should be as isolated as possible from the others.
Critical (e.g. brakes, steering, engine control) important (AC, heat, dashboard) and then everything non-essential.
The people that design cars need to be software engineers but instead they're behaving like mechanical engineers.
This seems like just a mind boggingly bad architecture — is there any real reason that a system should be designed this way or is this organization simply the result of poor thinking applied incrementally to inconvenient realities?
Luckily it is a very well-tested system, it was one the first commercial use cases for QuickCheck [1], but still...
One of the bugs that John Hughes found was an integer overflow that transformed a lowest-priority message into a highest-priority message. [1] https://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/quviq...