The Getting Started page has specifics about the use of the CAN (controller area network) bus that is a standard part of all recent cars from the EU and US. A vehicle interface is used to translate between the CAN bus and a USB or serial port. The main Android library is now available, and there's this interesting explanation of why this particular platform was chosen:
The requirements for the host device are quite flexible, but it's important that OpenXC rally around a single platform to maximize compatibility and momentum. Ideally, the platform should be accessible to a wide range of programmers from novice to expert, and it should use a popular programming language. The barriers to understanding and developing for vehicles are high enough (e.g. learning about CAN and about UI appropriate at 70mph) that learning a new niche programming language should be avoided. The platform should also use widely-available hardware to minimize the burden that individual developers must bear to start creating applications.
Android is a massively popular application development environment. Since the vehicle interface is only a small part of any OpenXC application, this means that more general questions can be directed to the existing community of Android developers.
The open hardware part of OpenXC is also supported by Android. All Android devices running version 3.1 or later have support for USB devices, and many tablets include a full-size USB port. OpenXC hardware modules like sensors and in-vehicle UI can use USB to connect to applications. Combined with the affordability and increasing popularity of Android-based tablets, the likelihood that an interested developer already has or can acquire one is high.
Android, an open source project, lends itself well to custom hardware that would likely be used if OpenXC hosts are mass produced. Some of the most expensive components of a tablet (battery, LCD screen, GPS receiver, etc.) can be left out to hit an ever lower price point.
The use of Android means that there are potentially many developers that have the skills to begin exploring this system immediately; it's also relatively easy for newcomers to get up to speed quickly using established Android training materials. But will they be able to?
The idea seems to be to take the dataflows from car sensors and use them in new apps. These might be displays of real-time or historic information, or they may involve pulling in information from elsewhere. For example, an obvious source is OpenStreetMap: this would allow the car's real-time position to be placed in a geographical context by linking to other information that is position-based. The existence of OpenStreetMap provides a readily available and completely free resource that will enable developers to play around with data mashups of this kind without needing to worry about costs or licensing.
Things get even more interesting when there are enough other vehicles around that have similar OpenXC systems installed. Communications between cars, either using normal 3G or even open spectrum, would allow road conditions ahead to be passed along a chain of vehicles so that car systems – and hence the driver – knows of hold-ups, accidents or adverse weather ahead. These would be far more up-to-date than anything else online, because they would be gathered on the spot by sensors in vehicles.
The next stage would be to allow vehicles to pass key information to each other autonomously – for example, when the car in front brakes, a message could be sent to those behind to prepare for it. That's not a new idea, but what's interesting is that OpenXC could provide part of the framework that realises it. However, to implement this option would require two-way access to CAN, and that's deeply problematic. Once people can hack car's performance or braking to optimise some aspect of interest, they will but the question then becomes what happens when accidents occur that may have been caused or influenced by those hacks?
Vehicle manufacturers will be extremely reluctant to contemplate this possibility, and will doubtless do everything they can to stop it happening. But of course that just makes the challenge more interesting, and it's probably inevitable that hacks, however illegal they may be deemed through legislation, will be devised that allow precisely this two-way control. Google's driverless car has already raised some of these issues, with safety measures being imposed on it that are the 21st-century equivalent of someone walking in front with a red flag. That doesn't augur well for open car systems of the future, and suggests that we will see clashes between what hackers can implement and what the authorities will permit.
Beyond this kind of traffic-based communication, later iterations of OpenXC-enabled systems might be plugged into the much vaunted Internet of Things (IoT), allowing even more complex dataflows and interactions with net-enabled objects surrounding vehicles and their occupants. The fact that the IoT is almost certain to be based on open source, and probably Linux, will make such integration even easier.
So, limited as it is, the OpenXC project is extremely interesting because it creates precisely the kind of important but undeveloped platform that Linux needs to provide new stimulus to ambitious hackers. Although apps are likely to be rather tame to begin with, I predict that we will eventually be amazed by what coders can do here – as they build, once more, on the power of Linux.