ECE497 Car CANBUS

From eLinux.org
Jump to: navigation, search

thumb‎ Embedded Linux Class by Mark A. Yoder


Team members: Daniel Neelappa,

Grading Template

I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!

00 Executive Summary
00 Installation Instructions 
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score:  10/100

(Inline Comment)

Executive Summary

Intro: This project is designed to integrate the Beaglebone Blue with the network within a car. The Beaglebone Blue has a built-in transmitter and receiver for CAN messages. All vehicles in the U.S. manufactured after 2008 have CAN bus networks, and this provides an excellent opportunity to take advantage of the Beaglebone Blue's hardware. While cars have the same CAN protocol, they differ drastically in the messages that send. Each manufacture has their own message encoding, which makes it difficult to decipher what a message does.

Currently, I have the Beaglebone Blue's transmitter and receiver successfully reading my car's messages. I can even send messages through my Beaglebone Blue to my car. My host computer has successfully compiled can-utils. Can-utils is mentioned more below.

While, my Beaglebone blue can communicate with my car, my car is not currently responding to my requests. This is most likely an issue with not knowing the codes laid out by the manufacturer of my car. This has caused a hold on my progress, yet I mention below on some ideas I have moving forward.

It is unfortunate that each car has its own set of codes for diagnostics and normal functions. The upside is that car manufacturers can protect their end users from harm by obscuring the true functionality of each code. This deters hackers from easily sending viruses through multiple cars using a static attach type. Below, I mention some vulnerabilities with this CAN setup. Overall, once I deduce a few commands in my car, I can add new functionalities such as automatic windshield wipers or a diagnostic logger that resides within my vehicle.

Packaging

My project is still in the design and testing phase. As a result, the packaging isn't ready for a final product quality state.

However, here is my current debug setup:


I have attached a photo that shows my current setup. The beaglebone has a CAN port. In the picture, there is a jumper wire that connects to the CAN port and extends to the breadboard. The breadboard has a 16-pin OBDII wire to connect to my car. Most cars have a male OBDII 16-pin port. The wire connecting to the breadboard is a male to female OBDII 16-pin port. CAN is a 2-wire differential voltage transition protocol. Vehicles are mandated to have a standard OBDII connector. While many pins are left open to the manufacturer to choose their intended purpose, there are a few that are standard. There is a standard CAN pin connection. For my project, I connected to pins: CAR OBDII WIRE

CAR OBDII WIRE BEAGLEBONE
Pin 14 CAN Low Jumper
Pin 6 CAN High Jumper
Pin 5 GND of Beaglebone
Standard OBDII Pin-out
Beaglebone Blue Pin layout
CAN Bus Wiring to my Beaglebone Blue

Installation Instructions

First make sure your system on the bone is updated.

sudo apt-get update

Then we will prepare to load a device overlay onto the board.

sudo apt-get install build-essential git-core device-tree-compiler

Clone the following repository:

git clone https://github.com/beagleboard/bb.org-overlays/
cd ./bb.org-overlays/
./install.sh

You should now restart the system after the install. If you look in the /lib/firmware/ directory, there should be an overlay called "BB-CAN1-00A0.dtbo."

We will need to change a line in the boot DeviceTreeOverlay loader config file in order to load the CAN cape that is built into the beaglebone blue. Place the following line into the "/boot/uEnv.txt" file.

nano /boot/uEnv.txt
cape_enable=bone_capemgr.enable_partno=BB-CAN1

Now reboot the system.

We will load the kernel modules into the kernel:

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw

Now that the modules have been loaded, we will configure an interface for our CAN communications.

sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up

The above commands will set an interface up called "can0" with a bitrate of 500k. I have used 500k as the bitrate since most cars are standardized at this bitrate. If you do not receive messages by your car, then try to change the bitrate to 125k or 250k. It may take some debugging to get the right bitrate for your car.

Try this:

ifconfig

You should see a new interface called "can0." If you do, congratulations. You have successfully configured your CAN interface.

You might want to have your interface loaded upon boot-up. This will auto-start the interface we described above:

write the following into the file "/etc/network/interfaces" using sudo privileges:

allow-hotplug can0
iface can0 can static
bitrate 500000


Testing your communication setup:

One of the major tools that I used in this project was called "can-utils." This is a package that can be downloaded from a git repository.

 git clone https://github.com/linux-can/can-utils.git
cd can-utils/
./autogen.sh
./configure
make

Once the compilation process is over, there is a bunch of tools to use for CAN messaging.

See one of the below sections for more information.

Reference: link

User Instructions

Once everything is installed, you will need to go into the directory that you compiled can-utils.

cd can-utils/

If you want to see all messages on a CAN bus interface called can0, try this:

./candump can0

This will list all messages on the bus at one time as a stream. This is very useful to have a sense of what data is being sent and where. It may be useful to send this data to a file to further analysis later on.

./candump can0 > log.txt

Sometimes, you might only want to see one message id address.

./candump can0,367:7FF

This command translates to receiving messages on the can0 interface with ID= 367. The :7FF is used to list all messages that are associated with ID=367.

./canbusload can0@500000 -r -c

The above command can be used to determine the current load of the bus as a percentage. The -r and -c are just formatting arguments. It is important to have @500000 after the interace name. This is used to calculate the percentage. 500K is the bit-rate of this interface's communication layer.

If you want to send a message, try this:

./cansend can0 367#020101

The above message transmit the message "020101" to address "367" on can interface "can0." All values above are in Hex.

Highlights

Research Insight:

From the tools mentioned above, I was deciphering the messages from my car.

An initial attempt was to achieve a steady-state conditioning of node ID's on the bus. I would insert a timer for ten seconds and collect the ID's on the bus and store them in a list. After the system reached steady-state and didn't record any new ID's, I pressed the windshield wiper button in my car. Unfortunately, no new ID showed up on the console. This was a result of not fully understanding how the CAN protocol in a car is setup. Instead of triggering a new message ID for each action triggered, cars share ID's and blast then across the bus. So, this method I tried would not be able to capture the signals sent for a button press unless it had a new ID, which is uncommon.

I searched wikipedia for some standard codes and I found this: wikipedia PID's This allows me to pull diagnostic information from my car.

Combing through the CAN messages from my car, I noticed one reference ID=367 that seemed to show the servo positions of the windshield wipers. ID 367 also gave a similar message when I pressed the window up button. It seems that ID 367 controls multiple servos throughout the car.

Here are some videos that I took while I was working: Reading a Can network "can0": link

Decoding and viewing windshield servo positions: link

Show bus load example:link

Sending a message and porting can0 to a text-file: link

The previous video sent a message at ID = 7DFh. This should activate the OBDII diagnostics, yet for my car, it did not work. Instead it caused several errors to be generated. It may be possible that ID=7DFh was a warning address as most of the errors in the car trigger on an address between 700-900h. Error on the car: link

Theory of Operation

In a high level overview, I am using my beaglebone blue's CAN communicator to talk to my car. The board is running a kernel module that loads on boot time. The OS loads a network profile "can0" as an interface to use in the user mode. Once this is configured, I am ready to read and send CAN messages. I am using a software bundle called "can-utils." This is downloaded and compiled on the bone through the Debian distribution. I use commands like "./candump can0" to list all messages on the can interface or "./cansend" to send a message.

Work Breakdown

For all the tasks below, I (Daniel Neelappa) was working alone. From time to time, I would talk to Dr. Yoder to gain feedback and insight on the project. Most of my knowledge and a large part of this project was directed through research from online sites.

  • Research CAN protocol
  • Research beaglebone blue CAN capabilities
  • Implement Wiring of OBDII Pin layout
  • Run CAN logging software for listing messages
  • Researching standard diagnostic codes
  • Intercept CAN messages from a diagnostic tool, Estimated Completion: A week after break when the diagnostic tool arrives via mail.

The last item is a future todo. That is the next step that I want to take to better understand what codes are needed to get diagnostic information.

Future Work

I don't feel like I'm done with this project at this moment. I was unable to decode the messages of my car, even the standard OBD codes that should be common across all cars. I have purchased a OBD scanner. I plan on hooking it up to my beaglebone and have a "man in the middle connection" that will find out what codes to send via my beaglebone. I plan on setting up an extension wire from the beaglebone's breadboard to connect to a wire that will attach to the OBDII scanner. Unfortunately, I will not be able to get the scanner in the mail in time for the presentation; however, I will continue the project when I get back from break. My future hopes is to make a diagnostic panel in my car that displays my car's speed or other information onto the windshield (HUD). I was thinking about making an automatic windshield wiper that senses rainfall; however, this would require intercepting and sending non-diagnostic codes. I don't think this last part is possible at the current state as it could be extremely dangers if I get the wrong decoded message. The information system (HUD) on the windshield is still possible as it uses diagnostic codes.

Conclusions

So far, this has been a great project to work on. I would say that the project is still in the research side. Moving forward, I don't feel like I'm done with this project and would like to continue it past this term. I will be performing more as detailed in the future work section.



thumb‎ Embedded Linux Class by Mark A. Yoder