In the last six weeks or so, I’ve given three talks about open source / free software in automotive. [That means “cars.”]
It’s sort of a new thread for me to play out on the conference circuit, at least as a speaker, but it is actually an area that I have found personally interesting for ages, and in which I’ve been a secret hobbyist for a while—at a very amateur, “enthusiast” level. But after having followed the topic and having read up on it, last fall (i.e., November 2013) I decided to dive in and start experimenting with a Linux-based automotive computer build in my car.
That’s one of the talks I spoke about earlier: I gave a “build talk” about the project at the Automotive Linux Summit in Tokyo in early July. The goal was to relate my real-world experience (surprises, pitfalls, etc.) to the developers and strategists at ALS in the hope that it would be beneficial to them. I gave another talk at ALS about automotive security, but it consisted of “research” rounding up other people’s research and published studies about software security problems in car computers. I highly recommend the “just talk about other people’s hard work” methodology as a talk-development approach; it’s far less time-consuming than doing all the tests and paper writing oneself, and you also don’t have to apply for grants.
The third talk was at GUADEC, the annual GNOME project conference. It started out, in theory, as another “my build and what you can learn from it” talk idea, but it quickly became clear to me that I needed to do more: provide some context for the audience that didn’t already pay attention to the automotive corner, and offer some reasons why they should look into it and maybe even get involved. The GUADEC team ended up asking me to make that talk a keynote, which was definitely a surprise, but obviously lots of fun, too.
I tried to include some words on where I thought GNOME developers could get involved in automotive projects (especially since many of those projects already use GNOME libraries, even if they aren’t interacting too much with GNOME-proper upstream), and some ideas on how GNOME could be more “garage friendly.” More on that later. Nobody threw any vegetables, and a lot of people asked questions afterward, so I think it went well on the whole.
Interestingly enough, while working on the GNOME talk I kept running into the realization that a lot of full-time Linux folks weren’t really up to speed on the scope and makeup of the automotive Linux space. It’s understandable—most of the work now is pre-production and it may be a while before products hit the showroom floor. But that also makes it the best possible time for free-software people to get involved. The better you make it right now, the better it’ll be when it arrives at the dealer.
The other big take away, for me, was that evidently I’m a shamefully bad example of a tech hobbyist because I haven’t done a running “build log” on some personal blog site or on Instructables, detailing the ups and downs of shoehorning a homemade IVI system into a recent Mustang. So I’m vowing to do better on that front. But I can tell you this much: a lot of what goes into posts like that won’t make a lot of sense unless I dole out some background info, like I did at GUADEC. I apologize if you happen to catch this blog via Graphics Planet and you don’t care about the topic at all — but there is some interest UI/UX work a little later on in the process, I promise.
ALS and the landscape
Anyway, here are the broad strokes if you’re just hearing about automotive Linux for the first time. The Linux Foundation has done this “ALS” conference for three(ish?) years now. ALS attendees tend to be drawn from three major projects: GENIVI, which is a multi-company consortium founded by folks in the automotive industry, Automotive Grade Linux (AGL), which is a working group coordinated by the Linux Foundation, and Tizen IVI, which is a distribution project run mainly by Intel and Samsung people. And there are, of course, plenty of other participants.
These projects overlap a lot in their areas of concern, naturally, but there are also big differences in what they want to accomplish, which makes a difference if you’re picking and choosing as an outsider.
GENIVI is focused on defining a platform-level Linux system that the participating companies can use as a specification to build their automotive products against. GENIVI defines components needed for in-vehicle infotainment (IVI; that’s the head-unit computer that the driver and passenger fight over while they’re barreling down the road) systems, so that car makers and suppliers don’t have to reinvent the wheel every time or argue endlessly about design specs. I.e., everybody uses GENIVI, so It Works. Naturally, the alliance has to write components that don’t already exist, so they do that: they have open source code at projects.genivi.org
But GENIVI is not defining the entire system; they are stopping right below the application API layer. Apparently that’s something that different members want to head in their own direction on, and potentially compete on. So GENIVI’s Linux builds tend to be more like “starting points for a company making a product in house.” They even use Yocto.
Tizen IVI, on the other hand, is designed to be a fully functional Linux distribution. It’s supposed to be something an OEM can grab and mold a product out of.
In that sense, it competes with GENIVI, I guess, but Tizen also has this interesting “cross-device-profile” concern. The larger Tizen project wants to make a Linux stack for consumer electronics products of all types (phone, smartwatch, TV, smartfridge, smartcoffepodmachine, etc) that can offer the same app-level API to third-party app developers. That is, you write yer Angry Flapbird game once, and it runs on all the devices. So Tizen IVI is very much concerned with that app layer that GENIVI isn’t. Tizen IVI may differ a lot under the hood from Tizen Mobile, but it’s the same on top. The app-level API is based on HTML5 and a lot of W3C standards.
Last but certainly not least is AGL. AGL is technically a “workgroup,” which means that it’s a bunch of companies that want to get together for some common purpose; they can work on whatever they decide to. At the moment, their most visible effort is the AGL Reference Linux distro, which is a fully installable Linux distribution that you can put in a car. It’s probably not quite the same as you will see in production vehicles, but it’s the closest thing to fully realized IVI of the existing projects. It’s based on Tizen IVI with a lot of additions. The additions include a suite of actual IVI apps (music player, navigation, vehicle status, phone hands-free tethering, etc).
Developing more such applications is another one of AGL’s focus areas; right now they’re putting feelers out for people to write apps; it’s actually a good opportunity if you want to do development. The other thing to remember, though, is that AGL may have broader interests than just IVI: they could decide to delve right into engine-control stuff as well, which is an entirely different space. Fuel injection, timing, traction control, etc.—all that stuff is computerized, and I hear interest from the hallway track in using Linux to virtualize, containerize, and improve these systems. It’ll be interesting to see.
All that background aside, I did actually talk about my personal “shadetree mechanic” project at both ALS and GUADEC. What I have is something on a very PC-like microITX motherboard, stuffed into the trunk space of a 2005 Mustang GT. How well does it work? Well, that depends on what your criteria are. I’ll give this one teaser thought, as I contemplate writing up a Proper Build Log like the wise & benevolent Makers Of Olde tell us we have to do:
If you make careful hardware choices, you can put together a functional Linux-based IVI system in your own car. If, that is, you have a reasonably modern car, sufficient time (or, alternatively, money) to put into the build from both the hardware and software sides, and if you’re willing to get your hands dirty. Literally dirty. And figuratively.
BUT. The first thing you’ll learn is that there is no such thing as a generic car or a generic car computer. The PC may be pretty standardized, but it also makes a lot of assumptions—like having a flat surface, with decent airflow, and a normal AC-DC power supply, and room to put stuff where you want it. None of those things hold true in a car, and every single choice you make, starting from where you think you’ll put the actual computer part physically in your vehicle, radically alters all of your decisions further down the line.
So it’s one individual builder’s story, and everyone else’s will differ greatly. But I also think the experience is useful for other FOSS developers to hear about, since whether you know it or not, automotive computer products are making their way to the mass market. And we don’t want Linux to be late to the party, having not thought about what it will look like when there’s a full-on computer in the car parked outside the house. How do we expect that computer to relate to our other computers? To connect to the network at our house? To interact with the portable devices we own and might bring with us? To the documents we ferry around?
It’d be good to have answers to those questions when the tidal wave of car PCs hits. Estimates are it’s less than a year and a half from now before the first official GENIVI systems hit showrooms. Proprietary software will take several iterations to get all this stuff right, and it will compete within itself, pretty fiercely. But I hope we won’t let them have the open road all to themselves.