The vehicle interface (VI) is a device that plugs into the OBD-II port (and thus to the CAN bus), reads and translates OBD-II requests and CAN messages into a standard cross-vehicle format. The translated messages can be sent over USB or Bluetooth, so they can be read by any computer or smartphone.
The host device connects to the vehicle interface and reads the translated vehicle data (e.g. an Android tablet or Python environment on a laptop). OpenXC developers can write applications on this device using the data.
This architecture diagram illustrates how the VI, Android device and the car are connected. In this example, the status of the parking brake is broadcast on the vehicle’s CAN bus. The VI receives the signal, translates it into a generic format and sends it out over USB to an Android App.
Modern automobiles are laced with a number of microcontrollers and sensors that monitor and control everything from the throttle position to the ambient air temperature. These devices typically communicate over a wired in-vehicle network like a CAN bus.
(Creative Commons, Ford Motor Company)
Compared to something like the network of the Internet, CAN is relatively simple and low-level. CAN is a 2-wire network, and vehicles typically have two or three separate CAN buses running at speeds ranging from 125Kbps (medium speed) to 500Kbps (high speed). The protocol used to send data between nodes on the network is roughly equivalent to a link layer protocol like MAC or ARP. It’s a broadcast network and only one node can send data at a time. It handles message priorities at the bit level which makes it a good choice for vehicle networks, when you absolutely, positively, must make sure the brake pedal status is sent.
CAN network traffic is organized into frames (or messages) that have:
Within the 64 bits of data of each CAN message there are typically multiple data points, e.g. the steering wheel angle, a quality factor for the sensor, the center point of the steering wheel, etc. Each of these bit fields is known as a CAN signal.
The exact format of these bit fields and messages are typically considered sensitive information by vehicle manufacturers. The OpenXC VI allows these companies to keep that information private, but still give consumers and developers access to the data contained within. Even for engineers inside the companies, dealing with a standard data format across many vehicles is often preferable to keeping track of a database of CAN message and signal definitions.
The CAN bus is one of the primary components of OBD-II, a vehicle diagnostic standard mandatory for all cars sold in the United States since 1996. The OBD-II standard sends and receives messages on the CAN bus. If you’ve ever watched your mechanic plug a tool in somewhere underneath your steering wheel, or seen a vehicle monitoring app for your smartphone, that’s OBD-II in action. You’ll always find the port by the driver’s knees.
This means that every vehicle in the United States has a very accessible place to connect to the same network used by all of the vehicle’s subsystems. At the very least, all gasoline engine cars in this country (and most hybrids and electric vehicles in practice) support parts of the On-board Diagnostics standard data set. You can read this data set with OpenXC, but with OpenXC the same port may also give you access to much richer data from your car. With either support files from your automaker or some knowledge of how to decipher the messages on the network, you can significantly expand the data available to your applications.
Diagnostic messages work slightly differently than the CAN messages used by all other in-vehicle systems. When you turn on your car, the CAN bus is very busy with so-called “normal” messages. For example, the engine control unit (ECU) continuously sends a CAN message with the engine speed (in RPM). The cluster listens for this message on the bus and updates the tachometer arm when it receives a new value. The cluster doesn’t have to query for anything.
Conversely, diagnostic messages use a request/response style. An OBD-II scanner, or an OpenXC running the OBD-II firmware send specially formatted diagnostic command messages over the CAN bus. Nodes on the network that can output diagnostic information are listening for these messages, and send out the requested status information over CAN when asked. There’s no point in sending these messages when nothing is attached and capable of interpreting the results, so these messages are not sent continuously to minimize the level of traffic on the network.
The diagnostic request protocol is relatively standard across vehicle manufacturers, but beyond the standardized (and mandated) OBD-II parameters, the diagnostic message identifiers and formats are also largely proprietary.
Diagnostic messages are fully supported by the open source vi-firmware and ready-to-go binaries are available that scan your car for all supported PIDs.
Now that we agree on terminology, continue to set up the VI.