Basically there is no notion of to or from really. When you push the vol+ button on the steering wheel there is a controller that sends a message trying over and over again until there is no collision. That message has an ID in it early on. In this case it will be like I dunno $412 okay. That means audio controls or something. A bit later is some length and then the data, say the data is $C.
The infotainment unit is listening to everything just as the controller for the steering wheel controls is and everything else on the bus (it has to, because of how collision detection works). When the controller in the steering wheel sees that $412 ... $C it goes, well isn't that nice, me or someone else sent the vol+ message out finally, cool, I'll stop sending that now. When the radio sees that message with an ID of $412 it goes, oh that's an audio control message command, I should pay attention to that. Then it looks at the length and data and sees $C. It goes oh that means someone pressed vol+, I'll make it louder.
But here's the thing, there might be a knob too for volume and there really is just one board doing the infotainment. It's not like the old days where it's a potentiometer, it's not even wired directly into the board that handles infotainment. All the IO pins that board has are already used-up handling the screen, CAN bus, and other things. When you twist it, it also sends the same $412 ... $C over CAN from it's controller! The radio did not know what sent it, and that's by design in CAN bus.
There might be mobile phone integration, it can do CAN too, say also a $412 with with a different payload (and possibly length) that might mute on call. Also there may be a touch screen, but that will not do a thing over CAN if you press the vol+ there, just do it's normal IO from screen to SoC on the board.
Am I doing a better job of explaining? The take away is lots of things can send the same message and lots of things might be interested in that message and that is how it is intended. To some extent you can mitigate this in hardware. You can make long runs or some shorter star shaped topologies as long as you get the termination right. For the star shaped topologies you can stick gateways in there. The controllers can be setup to filter on certain conditions and the bus is the limit for filtering if you are using a programmable part. What I mean by bus is the limit is things like there is no notion of to and from.
That's what you get in CAN bus cause that's how it works. You can thank Bosch for that.
Thanks. I bet like most things in this world, this design grew organicly.
It seems like a good design in a very noisy environment and it does allow the car manufacturer to easily add in new controls ( volume up for example ) in different locations that do the same thing.
And thank you for the polite response, I appreciate it. One further nice thing about CAN, because of how it works electrically (basically logically zero always wins) it is trivial to have messages (and message types, I only described the most common data type) of different priorities. So a low numbered ID always wins. That also allows a trivial DOS, oa bit blaster that repeats something like 000000100001...CRC... might not even trigger an error detection. It really is quite a nifty thing, amazing it works so well too.
Thanks for the detailed explanation. So it's a completely trusted bus architecture. And what you absolutely shouldn't do in that scenario is expose it directly to Wi-Fi and 3G, which is exactly what it sounds like they did. I hope that this exploit gets manufacturers treating this issue with the importance it deserves, but my cynicism says they'll largely ignore it until people die.
That looks like an absurd amount of complexity/overengineering just to save some wire. I suppose "put everything on one bus" could be turning into some sort of anti-pattern.
Consider how much wire would be required to route every button directly. There would be tens of pounds of extra metal, plus impossible bundles of hundreds of wires to route around the car.
CAN is great for its purpose, but handling untrusted actors is not part of that purpose.
What should happen is a non-CAN hardware gateway that only passes valid commands to CAN buses.
It was a lot of wire saved. A 1985 Mercedes has a chassis wire harness that is almost three inches in diameter at its thickest point. They wouldn't have done it if it hadn't been a bargain.
Basically there is no notion of to or from really. When you push the vol+ button on the steering wheel there is a controller that sends a message trying over and over again until there is no collision. That message has an ID in it early on. In this case it will be like I dunno $412 okay. That means audio controls or something. A bit later is some length and then the data, say the data is $C.
The infotainment unit is listening to everything just as the controller for the steering wheel controls is and everything else on the bus (it has to, because of how collision detection works). When the controller in the steering wheel sees that $412 ... $C it goes, well isn't that nice, me or someone else sent the vol+ message out finally, cool, I'll stop sending that now. When the radio sees that message with an ID of $412 it goes, oh that's an audio control message command, I should pay attention to that. Then it looks at the length and data and sees $C. It goes oh that means someone pressed vol+, I'll make it louder.
But here's the thing, there might be a knob too for volume and there really is just one board doing the infotainment. It's not like the old days where it's a potentiometer, it's not even wired directly into the board that handles infotainment. All the IO pins that board has are already used-up handling the screen, CAN bus, and other things. When you twist it, it also sends the same $412 ... $C over CAN from it's controller! The radio did not know what sent it, and that's by design in CAN bus.
There might be mobile phone integration, it can do CAN too, say also a $412 with with a different payload (and possibly length) that might mute on call. Also there may be a touch screen, but that will not do a thing over CAN if you press the vol+ there, just do it's normal IO from screen to SoC on the board.
Am I doing a better job of explaining? The take away is lots of things can send the same message and lots of things might be interested in that message and that is how it is intended. To some extent you can mitigate this in hardware. You can make long runs or some shorter star shaped topologies as long as you get the termination right. For the star shaped topologies you can stick gateways in there. The controllers can be setup to filter on certain conditions and the bus is the limit for filtering if you are using a programmable part. What I mean by bus is the limit is things like there is no notion of to and from.
That's what you get in CAN bus cause that's how it works. You can thank Bosch for that.