|Please consider subscribing to LWN|
Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
OpenXC is a software platform created by the US auto maker Ford. The goal is to enable developers to write applications that integrate with the data buses in Ford vehicles. To that end, the company has rolled out a set of open APIs and has defined a family of hardware interfaces to bridge the vehicle-to-computer gap. I recently got the chance to work with one of the hardware interfaces, and, while the capabilities of OpenXC are limited in scope, the project certainly hits the right notes in terms of software freedom and usability. The long-term challenge will be seeing how OpenXC cooperates with the larger open source automotive software ecosystem.
Ford launched OpenXC in January of 2012 in a collaborative effort with Bug Labs, who designed the hardware interface modules. Officially called Vehicle Interfaces (VIs), these modules plug into a car's On-Board Diagnostic (OBD-II) port. On the inside, the VI runs a car-specific firmware that reads from the data bus and translates raw OBD-II messages into JSON objects (in OpenXC's own message format), which it then sends out over Bluetooth.
That setup all sounds good, but naturally one cannot get started with it without a compatible VI (a generic OBD-II dongle is not a substitute, since it does not output OpenXC messages). In mid-2013, when I first started looking at OpenXC, the official VIs were out of production and there was no expected delivery date for more. Nevertheless, I signed up to be notified if new reference VIs were released, and in early March received an email announcing that a fresh batch was available for purchase. When the ordered VI arrived, I took it for a test drive.
The good news is that it is entirely possible to build one's own VI, should the current batch run out again, using off-the-shelf components and the open hardware chipKIT Max32, an Arduino-compatible microcontroller. That option is not an inexpensive one, however, and requires some skill with assembling electronics. Whichever hardware route one takes, the VI must be flashed with firmware tailored to the vehicle on which it will be used. The list of supported vehicles is not long—currently 35 Ford models, the oldest being from 2005. But the firmware is BSD-licensed and the source is available on GitHub.
With the hardware in hand, one can attach it to the car's OBD-II port, pair with it over Bluetooth, and run a quick smoke test to make sure that data is indeed getting sent from the VI.
OpenXC supports both Android and Python development. The Android API is accessible from an open source library that supports Android 2.3 through 4.4. The API provides a high-level VehicleManager service that returns vehicle data objects relayed from the VI. There is also an auxiliary app called OpenXC Enabler that starts the vehicle service and pairs with the VI whenever the Android device is booted.
The Python interface is a bit lower-level; a module is available (just for Python 2.6 and 2.7 at the moment) that provides classes for the supported OpenXC data types as well as callbacks, basic logging functionality, and a facility to relay vehicle data to a remote HTTP server. The Python module also supports connecting to the VI over a serial or USB connection (as opposed to Bluetooth alone), and there is a set of command-line tools that can be used to monitor, dump, and trace through messages.
Both the Android and Python interfaces provide access to the same set of vehicle data, which is limited to a set of measurements (e.g., vehicle_speed, accelerator_pedal_position, headlamp_status, etc.) and a set of events (at the moment, just steering-wheel button presses). Exactly which measurements and events are available varies with the vehicle model; my own test car is a Mustang, which does not support the full set (omitting such measurements as steering_wheel_angle and fuel_level).
But Ford's documentation is detailed enough that the same set of measurements could also be read by a simpler device that plugged into the same OBD-II port; there are in fact other devices that expose much the same functionality to other automotive Linux projects. Tizen IVI, for example, can utilize the OBDLink MX to monitor the same data. There are other devices that can not only read messages from the vehicle's Controller Area Network (CAN) bus (which, for the record, is the bus protocol used by Ford behind the OBD-II port), but can write to it as well.
Given that there are other options, the question for developers is whether or not OpenXC offers advantages over interfacing directly with the vehicle bus. It certainly does simplify Android app development—and, if there was any lingering doubt about its usability, the project maintains a list of known OpenXC apps, which cover uses as diverse as indicating the optimal shift moment (which is a relatively straightforward calculation) to parking collision warnings (which necessitates significant hardware modifications, including the addition of a camera). Hooks are also in place to tie in to Android devices' other useful hardware features (such as location data).
The app-development story, however, is limited to Android, at least for now. Apple iOS support appears to be out of the question, since (as it was explained on the mailing list) Apple requires the presence of an Apple authentication chip in order to make low-level Bluetooth connections. As one might expect, there has so far been no word about any of the alternative mobile platforms (Firefox OS, Ubuntu, or even Windows Phone).
The case for Python development with OpenXC is not quite as clear-cut. The Python interface is designed to run on a more full-featured computer, which puts it into competition with in-vehicle infotainment (IVI) projects like GENIVI and Tizen IVI. An application-level API for accessing vehicle data is certainly appealing, but it could be a hard sell for Ford to convince other automakers to adopt OpenXC's message format and semantics rather than to draft something that is vendor-neutral from day one. Several pages on the project web site suggest that Ford is interested in pursuing this goal, encouraging users to (for example) tell other car makers that they want to see OpenXC support.
And there is competition. The most plausible candidate for such a vendor-neutral API is probably the World Wide Web Consortium (W3C) Automotive Business Group's Vehicle API, which recently became a draft specification. Ford does not have any official representatives sitting in with the group, although there are a few individuals representing themselves who are Ford employees. Most of the IVI development projects are also designed to support sending messages over the automotive data bus, which OpenXC does not yet address. There are hints in the project wiki and mailing list that further expansion is a possibility, but competing projects like Tizen IVI's Automotive Message Broker have already implemented message-writing functionality.
OpenXC also has a hurdle to overcome on the hardware side. The reference VI is quite large, especially given the fact that it must fit into a socket which, by informal industry standard, juts down below the steering column toward the driver's legs. OBD-II ports are not designed for permanent hardware installation, both due to their location and the fact that most of them do not latch into place; an innocent knee can easily dislodge the VI several times over the course of a drive.
That said, OpenXC is a commendable developer program for several reasons. The entire stack, including the VI firmware, is available as free software, which is refreshing and—judging from the list traffic—also seems to attract quite a few developers. In contrast, for example, support for the OBDLinks dongle mentioned earlier had to be reverse-engineered by the interested open source developers. Ford has also released quite a bit of information about its vehicles and their CAN Bus usage to the public, as well as other useful resources like vehicle data traces. In an industry as competitive as the automotive business, this level of openness is not the norm; the developer programs of other car makers generally require some type of non-disclosure agreement and maintain a tighter grip on their specifications.
The main goal of OpenXC seems to be making it possible to write third-party applications that utilize Ford vehicle data. That is, OpenXC is not aimed at system integrators or equipment manufacturers, but at individual, do-it-yourself hackers. On that front, it is easy to get started with, and worth exploring if one has a compatible car. Whether OpenXC can grow to encompass broader uses and more ambitious goals remains to be seen.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds