An Introduction to the CAN Bus: How to Programmatically Control a Car
I recently collaborated with my friends at Voyage to enable programmatic control of the A/C systems within a Ford Fusion. Voyage is working to bring about the end-goal of self-driving cars: a world where anyone, anywhere can summon a car directly to their doorstep, travel securely to their destination, all for an utterly low price. For Voyage, it’s imperative that they give their Riders access to control key car functions from the backseat, since there’s a day not too far from now when there won’t be a human driver to do it for them.
How we retrofit a Ford Fusion to become self-drivingnews.voyage.auto
An Introduction to the CAN Bus
A modern car has tons of control systems, functioning in many ways like micro-services do in web development. Think of airbags, braking, cruise control, electrical power steering, audio systems, power windows, doors, mirror adjustment, battery and recharging systems for electrical cars. These systems need to be able to communicate and read state from one another. In 1983, a team at Bosch began development of the CAN (Controller Area Network) Bus to solve this elaborate problem.
Think of the CAN bus as a plain network where any system in the car can listen and send directions to. It integrates all of these sophisticated components in an elegant way, permitting for many of the modern features we all love in vehicles today.
Self-Driving Cars and the CAN Bus
Since the tempo of development of self-driving cars has picked up dramatically, the word CAN bus has become popularized. Why? Most self-driving car companies aren’t building their own vehicles from scrape, and need to find ways to programatically control the car after the fact.
By switch roles engineering the CAN bus of a vehicle, it enables an engineer to issue directives to the car via software. The most necessary guidelines, as you can imagine, are steering (angle) and acceleration and braking.
Using sensors like LIDAR (vision), the car is then able to see the world like a superhuman. The PC within the car can then make decisions to fire off guidelines to the CAN bus to steer, accelerate, brake and more.
Not every car is ready to become self-driving, and there is a reason that Voyage chose the Ford Fusion (drive-by-wire!). You can read more on that topic below.
Dozens of established carmakers, technology companies, and startups are working furiously on autonomous vehicles. But…blog.caranddriver.com
Hacking the CAN Bus of a Ford Fusion
To get began hacking the climate control systems in the Ford Fusion, I opened my dearest book (The Car Hacker’s Handbook) and got to work. Before we dive in, let’s take a look at Chapter two of The Car Hacker’s Handbook to describe three significant concepts: Bus protocols, the CAN bus, and CAN frames.
Then, once you have an understanding of a vehicle’s communication network, you’ll learn how to intercept data and…opengarages.org
The CAN Bus
CAN has been a standard on US cars and light trucks since 1994, but it wasn’t made mandatory until two thousand eight (2001 for European vehicles). It runs on two wires: CAN high (CANH) and CAN low (CANL). CAN uses differential signalining which means that when a signal comes in, CAN raises the voltage on one line and drops the other line an equal amount. Differential signaling is used in environments that must be fault tolerant to noise, such as in automotive systems and manufacturing.
That said, the packets that travel over a CAN bus aren’t standardized. Each CAN bus packet contains four key elements:
- Arbitration ID The Arbitration ID is a broadcast message that identifies the ID of the device attempting to communicate, tho’ any one device can send numerous Arbitration IDs. If two CAN packets are sent along the bus at the same time, the one with the lower Arbitration ID wins.
- Identifier extension (IDE) This bit is always o for standard CAN.
- Data length code (DLC) This is the size of the data, which ranges from zero to eight bytes.
- Data This is the data itself. The maximum size of the data carried by a standard CAN bus packet can be up to eight bytes, but some systems force eight bytes by padding out the packet.
Format of Standard CAN Packets
CAN Frames
In order to turn the A/C on and off we need to find the right CAN bus (a car can have numerous). The Ford Fusion has at least four documented buses, three of them running at 500kbps (High Speed CAN) and one of them at 125kbps (Medium Speed CAN).
The OBD-II port exposes two of those buses: HS1 and HS2, but they are firewalled on this car and don’t permit you to spoof directions. With help from Alan from Voyage we flipped the problem (and the OBD-II port) inwards out and found naked access to HS1, HS2, HS3 and MS. The solution was on the back of the OBD-II port where all those buses arrive to a device called the Gateway Module.
Since the A/C can be modified via the car media interface (SYNC) we went straight for the MS bus.
But how do we get our computer to be able to read and write CAN packets? The reaction is SocketCAN, a set of open source CAN drivers and a networking stack contributed by Volkswagen Research to the Linux kernel.
We can connect three wires from the car, GND, MSCANH, MSCANL to a Kvaser Leaf Light HSv2 ($300 on Amazon) or to a CANable ($25 on Tindie) and get a computer with a latest Linux kernel to stream the CAN bus as a network device.
After it is loaded, we can use candump can0 and begin looking at the traffic:
However, this is equivalent to looking at the amplitude of a sound signal, it is very hard to characterize what’s going on and detect patterns. We need the equivalent of frequency analysis for this problem, and gratefully it exists and is called cansniffer. cansniffer shows a list of IDs and helps concentrate only on what switches in the data section of the CAN framework. As we figure things out about specific IDs, we can use it to filter out what we don’t need and only enable what we think is related to our problem at mitt.
Here is an example of cansniffer on the MS bus. We are filtering out everything and only letting CAN id three hundred fifty five , three hundred fifty six and three hundred fifty eight display up. Meantime, I am pressing the temperature adjust buttons on the car and we can see the 001C00000000 that represents the button shove pop up at the very end.
The next step is to connect the A/C functionality to our PC running inwards the car. The PC runs the Robot Operating System (ROS), and fortunately there is a module that makes this effortless for us since we’re using SocketCAN. socketcan_bridge turns our CAN framework into a message in a ROS topic. Good!
Here is an example of how the decoding is done:
The resulting data is stored in a CelsiusReport.msg:
After pressing all the relevant buttons in the car we end up with a list:
And we can then just send strings to the ROS knot and have it translate it to the car’s specific codes:
The Result
We are now able to issue the same CAN codes to the CAN bus that pressing the physical temperature up & down buttons would. This gives us the capability to remotely switch the temperature of the car, all from an app while sat in the backseat. Success!
This is just one petite step toward building an amazing Rider practice within the Voyage self-driving taxi. I was excited to work with them on this project. Interested in doing the same? See if there’s a fit for you.