ALS: First signs of actual code

Left unchecked, talks about supply chains and long-term industry shifts could easily dominate a business-focused event like the Automotive Linux Summit, but they were balanced out in the 2012 schedule by several sessions that dealt with actual code. Leading the charge at the September 19-20 event in Gaydon, UK was the GENIVI Alliance, which announced three new automotive software projects that will be accessible to those outside GENIVI's member companies. There were also presentations from Yocto and Intel, along with some advice on where automotive Linux still needs contributors. In most cases, the actual code remains just out of reach, but it is still progress.

GENIVI announcements

GENIVI, of course, is a collaboration of more than 150 companies, including automakers, equipment suppliers, silicon merchants, and software consultancies. Its purpose is to hash out a common Linux-based platform for in-vehicle infotainment (IVI) systems, which the various members can build products on with a minimum of duplicated effort. But GENIVI operates behind closed doors; apart from the block diagrams found in slides and blog posts there has not historically been any access to the actual specification for those people not working with GENIVI itself. Moreover, GENIVI has an atypical approach to being an "open source platform": it is committed to using software available under open source licenses, but it does not make that software available to non-members.

The lack of a public specification document and the unavailability of the software have real implications for the Linux community, because GENIVI has long maintained that it would draw upon existing projects wherever possible — but new work would also be necessary to fill in gaps in the stack. At ALS, Pavel Konopelko estimated that the GENIVI platform would consist of 80% existing "community" code, 15% community code extended by GENIVI to meet specific requirements, and 5% purely original work. Some of that work has already seen the light of day, such as the AF_BUS patches, but several other pieces have remained absent.

On the first day of ALS, though, GENIVI announced [PDF] three specific projects that it will open up for public consumption. They are an IVI audio management layer, an IVI screen layer manager, and a logging and tracing framework for use with diagnostic messages. The three projects are set to be hosted on Linux Foundation infrastructure, although so far the sites and code repositories have not appeared. There is a description of each of the components available now on the GENIVI web site, which sheds a bit more light on their scope — although the explanations are not always crystal clear.

The audio manager, for example, implements an API for routing audio that is independent of the hardware and software routing frameworks underneath. That would appear to place it above PulseAudio in the typical Linux stack, while providing the same API if a hardware audio routing mechanism is available instead. The GENIVI specification does not make PulseAudio mandatory; it only mandates (as an "abstract component") that an audio router be provided. The audio-routing problem in IVI includes use cases not encountered in desktop setups, such as alarms (triggered by bumper proximity sensors, for example) that interrupt any other audio streams, and routing sound from a single media source to multiple rear-seat entertainment (RSE) units. The hardware-or-software approach described for the audio manager suggests that there are GENIVI members intent on producing vehicles where such audio routing is handled by onboard hardware.

Similarly, the screen layer manager is described as handling hardware-accelerated compositing, but by implementing an API that can deal both with software video sources like applications and with direct hardware sources like reverse-view cameras. The description of this component also observes that existing IVI implementations tend to build such layer management functionality directly into their GUI front-end (which, in IVI circles, is usually referred to as a Human-Machine Interface or HMI). Since HMI is generally reserved as one of the vendor-specific "differentiating components" in a product, a standard screen layer manager will presumably reduce duplication.

The last component of the three is the Diagnostic Log and Trace (DLT) project, which is described as an abstraction layer for several different diagnostic logging protocols. It is said to support system- and user-level logging, predefined control messages, and callbacks, and to connect to syslog or other existing logging systems.

At this stage, all three projects are (so to speak) "announcement-ware," but assuming that the code and infrastructure follows, they represent a major step forward for GENIVI. If one looks at the GENIVI platform block diagram (for example, the version on slide 9 of Konopelko's presentation [PDF]), there are quite a few components still designated placeholders or abstract requirements. It is hard to see how the missing pieces fit into the 80-15-5 percentages cited, but at least the availability of some GENIVI-authored components should help bring the whole picture into clearer view for those not part of the GENIVI Alliance.

Yocto, Intel, and others

There are indirect ways in which one can explore a GENIVI system already, however, by downloading some member company's GENIVI-compliant operating system. There are a few free options, such as Ubuntu's IVI remix and Tizen IVI. Holger Behrens from Wind River presented another possibility, the Yocto project's meta-ivi layer. Meta-ivi is a Yocto component that will pull in dependencies for GENIVI compliance.

It is designed to be used with Poky, the Yocto build environment, and pulls in the mandatory components of the latest GENIVI reference releases, plus the meta-systemd layer, a separate Yocto component that adds systemd. The current release of meta-ivi dates from May 16, 2012, and is based on the GENIVI 2.0 specification and Yocto 1.2 (an update is due in mid-October to bump the code up to Yocto 1.3 and GENIVI 3.0). It builds and configures the GENIVI and systemd layers, plus a few standard components to fill in GENIVI's optional components (e.g., PulseAudio and GStreamer).

Currently, building a meta-ivi system requires login credentials for GENIVI, because it pulls from the alliance's Git repository. Behrens said repeatedly that this requirement is likely to go away as GENIVI opens up access to outsiders, but for the moment there is no way around it. A bigger limitation, he said, was that currently meta-ivi is designed only for ARM's Versatile Express A9 boards. This is strictly a developer-power issue, he added, imploring interested parties to contribute with "board support, board support, and board support."

Luckily, there were some software options available today, as well. Intel's Kevron Rees presented his work on the Automotive Message Broker (AMB), a vehicle communication abstraction layer. The project is an extension of his previous effort, Nobdy. It provides a source/sink model for applications to connect to vehicle data sources (from OBD-II diagnostic messages to sensor output) without worrying about the underlying mechanics source of the data. It allows multiple sinks to subscribe to messages from the same source, and the message routing engine (which Rees said was modeled on GStreamer) allows for intermediate nodes that could perform transformations on the data, such as filtering or message throttling.

The current version of AMB supports GPS, OBD-II, and CAN bus sources (the latter of which he demonstrated using a video gaming "steering wheel" controller). Only two sinks are implemented at the moment, D-Bus and Web Sockets. The D-Bus output, he explained, was an obvious choice because it provides a property and signaling system for free, and allows Smack-based security policies. The lack of security in Nobdy was one of the principle reasons he decided to undertake a rewrite. The demonstration was short but entertaining; it utilized a dashboard display application called GhostCluster to report mock speed and direction information from the game controller, and allowed access to faux rear-view cameras, which were implemented with webcams.

Jeremiah Foster of Pelagicore also discussed the paucity of software available to interested developers in a session examining progress between the automotive industry and the open source community. Foster is the baseline integration team leader at GENIVI, but as he explained, he spent quite some time beforehand working on the community side as the Maemo "debmaster." The talk included several points about how the automotive industry and traditional open source differed, such as the long-term partnerships in place between automakers and tier-one suppliers. Some of the disconnects are changing already, he said, such as the automotive industry's understanding of how to work with software licenses, but others remain unclear, such as the lines of legal responsibility in cases where software contributes to an accident.

A key point, he said, is that automakers do recognize that rewriting software stacks for every new product is incredibly wasteful, and there are opportunities for developers and agile software companies to do big business during the transition. He then outlined a number of areas where interested developers could work on automotive-related problems.

The first was fast boot, which is required by regulations (such as requiring that a rear-view camera start showing live video to the display less than two seconds after startup). GENIVI has adopted systemd to tackle this requirement, he said, though it is not yet complete. Another systemd-derived feature is "last user context" (LUC), in which a car remembers and restores environmental settings for multiple drivers (such as audio and temperature preferences, plus physical options like mirror and seat adjustment). LUC remains a subject where considerable work is required.

There are also several standard Linux components that automakers and software vendors frequently replace with proprietary components because the open source versions are incomplete, he said. These include BlueZ, ConnMan, and Ofono. All three are missing features and require testing in more configurations. Similarly, IVI systems require some mechanism for data persistence, such as remembering recently-accessed files or playlists. Existing solutions like SQLite have not proven popular with IVI vendors, who would be happy to see additional work.

Finally, he said, there remains a lot of work to be done porting and packaging existing automotive software for the distributions used by developers. The existing IVI distributions (such as Ubuntu and Tizen's IVI flavors) tend to start with a minimalist system and add automotive-specific packages, but this results in a system that developers cannot use for everyday work. The majority of Linux developers, he said, would rather port new software than change distributions. Consequently, bringing the IVI software to existing distributions will attract more developers than will continuing to roll out IVI-only embedded distributions. Bringing automotive packages to desktop distributions could also help the community build its own answer to the pieces that commercial vendors prefer to keep proprietary, like HMI.

Although it was good to hear that GENIVI is opening up more of its code, the three projects announced are just a beginning. GENIVI and other automotive Linux players do seem to recognize that there is a void to be bridged between the industry and the community, though. If the alliance does indeed make its Git repositories publicly accessible, that will break down a major barrier to entry for the potentially enormous talent pool of volunteer contributors.

[The author would like to thank the Linux Foundation for travel assistance to ALS.]

---

(Log in to post comments)