Many more things besides auto's use CAN. One of my current projects involves exercise equipment that internally speaks CAN Bus. There is great support in Arduino for interfacing with stuff like this.
At a previous job I interfaced with hospital beds that used CAN Bus internally. Turns out that Ford had laid off a lot of engineers a few years ago and the firm hired some of them to design the next generation bed. They knew CAN Bus, so they used it to control the hydraulics, pneumatics, lift motors, strain gauges, and so on.
Man, that's really cool. I'm really looking forward to all of this CAN Bus stuff being EOL in 10-25 years so I can get my hands on it at tinker with it.
Isn't CAN very limited in terms of bandwidth? Seems like this wouldn't be appropriate for most applications of interest? When I worked at an equipment manufacturer, everyone was very concerned about accidentally saturating the bus, and we even had a very compact data representation.
CAN-FD raised the baud rate to 12mbit. Honestly, in my applications where I have idiotic ascii logs transmitted over CAN due to management idiots, I've only managed to saturate reception buffers rather than the bus.
Noone ever talks about the very significant downsides of CAN:
- CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps.
- a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.
- CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.
- CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates.
So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications.
It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.
Some systems do up to 1mbps. MIDI for example is nowhere near this. It's not the right protocol for media or bandwidth intensive applications but for control systems or reading sensors its often enough.
CAN frames are not standardized. You cannot have a single command to do operations on any car. Each manufacturer has different bit patterns and also it varies between car models. Atleast with Chrylsers I know its true. There should be a lookup based on the car's model with a unified API which I think will happen soon based on the pace of car tech progress. Also note that once the frame is on the bus, it get executed and an ACK will be sent. There is no authentication mechanism in place. So once you put a frame into the CAN bus, there is no way to stop it. This will be the top pain points for car techs to fix.
So this not that thrilling but my BMW r1200gs has this bus. I dropped the bike recently and killed one of the turn signals. Canbus lit up saying you have a light out. I fixed the turn signal and it still lit up. I thought I needed to reset it or something.
Turns out I killed the headlight in the drop as well. Without the canbus it would have been months before I would have caught that. I thought it was a BMW over-the-top thing but it actually helped me, it was the daylight running headlight that went out. Good to have that one.
Like I said, not thrilling, not programming, but an upvote for the Canbus.
My riding school was big on checklisting the bike before every ride: indicators front and back, low beam, high beam, brake light by the lever and the footbrake, horn. Not thrilling either but it's how I found out about my busted horn and busted brake light switch promptly instead of the hard way. In most places riding in traffic is risky enough that it's worth knowing all the bits are working every time.
Can you imagine the havok when terrorists figure out they can program cars to hunt and kill pedestrians in crowded spaces? Currently the terrorist needs to drive the vehicle, which makes it a suicide mission. How much more deadly would it be if it was reduced to just the cost of the car and a low chance of getting caught? How can we defend against this?
You can't. It's not that hard to make a controller that lets you physically turn the wheel using an RC remote, it's just a matter of attaching a servo to some cords pulling it (there's a guide on Instructables).
The reason terrorists don't do that has nothing to do with being hard.
There was a problem in Edmonton ~10 years ago, where criminals would steal a car to get part way home in the winter. Then, they would convert it to a land missile, and launching it across a parking lot, into a mall, in the middle of the night.
Their solution was much simpler: secure the wheel using the seatbelts, jam a big snowball on the accelerator, and use a stick to nudge the transmission from neutral to drive.
You can already do that. How do you think stunt cars work?
just throw in a off the shelf servo to control the steering wheel and two more to run the brakes and gas. Throw in a off the shelf RC controller and you got yourself a giant RC car.
Probably faster than trying to hack a car when you got a perfectly good no authentication interface.
I'm more concerned about the concurrent trends for (a) remotely accessible systems in vehicles, for communication or otherwise, and (b) critical vehicle systems being connected via relatively insecure internal networking to each other and to something remotely accessible.
Put another way, it's not a hostile actor remotely controlling their own vehicle that worries me the most, it's the potential for a hostile actor to identify a vulnerability that lets them remotely control many other people's vehicles simultaneously.
It's also the lack of any way for even a relatively discerning customer looking for a new car to determine how likely any potential purchase is to be vulnerable to such an attack and how likely the manufacturer would be to anticipate and/or respond to such a vulnerability.
Given the generally awful attitude of the auto industry to safety and generally poor processes for handling even recalls for widespread and acknowledged mechanical failures, buying a new car is not looking like a happy experience any time soon.
There are an infinite number of ways that "terrorists can kill people". Remote control cars is only one of them and probably nowhere near the top of the list.
We defend against killer-remote-control-cars like we defend against all forms of terrorism: plain old police and intelligence work to snatch the perps before they have a chance to strike.
I'd argue that a lot of terrorists don't care. They want to do it themselves, die in the process and be glorified by their own. Otherwise they would probably just hide bombs somewhere to detonate them instead of strapping them onto themselves.
Well, humans are capable of improvising better than something automated or pre-positioned. That's the biggest reason. Second, for the terrorist organization itself, people are probably close to free assets (you just brainwash a few more), whereas spending a lot of R&D on developing an automated explosive delivery system and then continuing to patch vulnerabilities in it that governments would use to neutralize it would cost exponentially more.
tl;dr: If you don't care about the sanctity of life, humans are cheap.
I have a hard time imagining self-driving cars merely negotiating the traffic I drive in each day much less deal with the myriad foreign policy and security issues that have led us to this point in time. Imagine the lawsuits if it can ever be proved that a murder was committed by someone hacking an automobile--and I do suspect it has already happened. The drive-by-wire gas pedal and shifter in my car cause me concern. We need better low-tech kill switches and backup mechanisms and way less reliance on fancy tech.
Also, there is no connection between "hacking" the CAN bus in today's cars and doing anything like providing access to adjust the A/C blower level in some future self-driving livery mobile. Why anyone would think there would be even the remotest connection between how CAN bus works today and how some future consumer-oriented interface would work demonstrates dangerous naviete.
The self driving car doesn't need to be perfect, it needs to be better than humans. That is a much lower bar. Self driving cars have already demonstrated their ability to handle traffic better than humans, but there are other situations where they are much worse.
>If your CAN nodes are all authenticated to one another, it's a lot harder to hack.
The problem with that is now how do you do the legitimate good things you want to do? Of course, these kinds of locks usually have their own problems and usually only keep "honest folks" out.
A car could be self-driven while not connecting to any external networks. It still can get fresh traffic or weather data, but with those, you can't take over a car to make it a weapon.
Think Reflected XSS: weaponized string hidden in map data (road name even) in advance, is unwittingly integrated into offline map, triggers when a self-driving car tries to parse the data for that road segment, using a vulnerable library. Antyhing that uses network-contributed data is network-connected, even if the link is currently inactive (Case in point: Stuxnet).
Love CAN, beautifully simple. Of course the "arbitration id" needs to be unique to an ECU, but each can send multiple different ones - the purpose of the ID is to always send the one with the lowest number. When designing the system, this ID defines the priority of each message - e.g. brake lights are more important than radio volume up :)
Hmm, I hope they're not planning on using ROS for the final product... using a non-hard-realtime OS to fully control a car is a spectacularly bad idea.
A bit of a nitpick, but ROS is not an OS, it is a middleware. Who knows, maybe somebody makes a ROS adaptation for a hard-realtime POSIX OS, would be totally possible.
Though I agree, ROS is nowhere near the stability level needed by industrial and automotive products. It's great for prototyping, but one has to keep in mind the inevitable refactoring of the communication layer, and keep the core functionality ROS-independent.
Nvidia drive PX2 uses QNX, I think for an open source solution someone should try to figure out a solution with sel4 running on RISC-V so there could be a full proof that the system supports hard realtime.
Readit News
https://en.wikipedia.org/wiki/CANopen
Many more things besides auto's use CAN. One of my current projects involves exercise equipment that internally speaks CAN Bus. There is great support in Arduino for interfacing with stuff like this.
- CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps.
- a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.
- CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.
- CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates.
So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications.
It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.
http://openxcplatform.com/
Turns out I killed the headlight in the drop as well. Without the canbus it would have been months before I would have caught that. I thought it was a BMW over-the-top thing but it actually helped me, it was the daylight running headlight that went out. Good to have that one.
Like I said, not thrilling, not programming, but an upvote for the Canbus.
Dead Comment
https://www.youtube.com/watch?v=3bZNhMcv4Y8
The reason terrorists don't do that has nothing to do with being hard.
> The reason terrorists don't do that has nothing to do with being hard.
This is false. Remote-controlled VBIEDs are absolutely a thing
Their solution was much simpler: secure the wheel using the seatbelts, jam a big snowball on the accelerator, and use a stick to nudge the transmission from neutral to drive.
just throw in a off the shelf servo to control the steering wheel and two more to run the brakes and gas. Throw in a off the shelf RC controller and you got yourself a giant RC car.
Probably faster than trying to hack a car when you got a perfectly good no authentication interface.
Put another way, it's not a hostile actor remotely controlling their own vehicle that worries me the most, it's the potential for a hostile actor to identify a vulnerability that lets them remotely control many other people's vehicles simultaneously.
It's also the lack of any way for even a relatively discerning customer looking for a new car to determine how likely any potential purchase is to be vulnerable to such an attack and how likely the manufacturer would be to anticipate and/or respond to such a vulnerability.
Given the generally awful attitude of the auto industry to safety and generally poor processes for handling even recalls for widespread and acknowledged mechanical failures, buying a new car is not looking like a happy experience any time soon.
We defend against killer-remote-control-cars like we defend against all forms of terrorism: plain old police and intelligence work to snatch the perps before they have a chance to strike.
tl;dr: If you don't care about the sanctity of life, humans are cheap.
Also, there is no connection between "hacking" the CAN bus in today's cars and doing anything like providing access to adjust the A/C blower level in some future self-driving livery mobile. Why anyone would think there would be even the remotest connection between how CAN bus works today and how some future consumer-oriented interface would work demonstrates dangerous naviete.
If your CAN nodes are all authenticated to one another, it's a lot harder to hack.
The downside is that they're a lot harder to hack, in the good sense of the term.
The problem with that is now how do you do the legitimate good things you want to do? Of course, these kinds of locks usually have their own problems and usually only keep "honest folks" out.
John Deere would love it though.
https://copyright.gov/1201/2015/comments-032715/class%2021/J...
Deleted Comment
Dead Comment
Though I agree, ROS is nowhere near the stability level needed by industrial and automotive products. It's great for prototyping, but one has to keep in mind the inevitable refactoring of the communication layer, and keep the core functionality ROS-independent.