I attended a Meeting the 9th March 2011 organised by the Syntec Numérique on the GENIVI project in Paris, and I’d like to share with you a summary of this presentation. Thanks to Fabien and Philippe for proof-reading this summary, all the remaining mistakes being mine.
The GENIVI project
Presenters: Fabien Hernandez (Software Architect) PSA and Philippe Colliot (Technical Lead) PSA.
Context
GENIVI (http://genivi.org) is a non-profit industry alliance committed to driving the broad adoption of an In-Vehicle Infotainment (IVI) reference platform. GENIVI will accomplish this by aligning requirements, delivering reference implementations, offering certification programs and fostering a vibrant open source IVI community.
It is based on features, code and certification program. It is driven by car manufacturers. It has been setup due to increased customer demand.
GENIVI aims to provide a common middleware developed by all project members. (costs and bugs reduction).
Car manufacturer need to differentiate as well. Basic features are shared (such as video player), and they concentrate for differentiation on GUI and additional apps. Each manufacturer alone doesn’t have critical mass, but sharing these common bricks will allow each of them to reduce costs. Especially on the non-visible parts.
GENIVI should support multiple HW platforms (based on Intel, ARM, MIPS processors) and 15% of GENIVI members are chip manufacturers.
The solution is developped in layers (module oriented). The middleware is packaged to satisfy all profiles (entry, 2D navigation, high end 3D …)
Car life cycle: 3/4 years. Consumers world: 6/12 monthes.
History of GENIVI
Car Infotainment was historically achieved using black boxes.Now the move to Open Source is due to evolution of features, costs, develpment life cycles, competitive landscape and customer requests and thus motivated the GENIVI project creation. For example: For car navigation, systems used to cost more than 2kEUR. Tom-tom put it down a lot. Also PSA was managing multiple different closed source platforms up to now, from various providers (QNX, Windows, VxWorks, …) blocking them in their evolution (as solutions are sized at minimum).
Intel and BMW started to work on Linux with WindRiver. First PoCs occured in 2007. Following that the AUTOSAR consortium was created in 2007 (standardization body). A Split happened and BMW worked then with Magneti Marelli for another PoC. In April 2009, first announce was made in Geneva (the GEN of GENIVI 
) of the GENIVI alliance, including BMW, Intel, Wind River, Magneti, GM, Delphi, PSA and Visteorrn. Goal is to have 6 monthes releases. End of 2010, the alliance released the Apollo release based on Meego. In May 2011, new version will be delivered (Borg in Dublin), with more compliance. Could be based on Meego or Ubuntu or something else. Adoption of Qt-Core as a brick, but it was not in compliance standard at start.
Since that more members including manufacturers (Renault, Nissan, Hyundai, Jaguar/Land Rover but some less active), First Tiers (Alpine, Bosch, Clarion, Mitsubishi, Pioneer) and Silicon manufacturer (Ti, freescale, Nvidia, ST, Samsung, ….) + lots of other !! (132 incl. Altran, Cisco, Accenture, Garmin, LG,
Nokia, Tata, Valeo, … but not HP yet !!!)
These members are mainly located in EMEA (80% activity) + AMS. Lots of M2M modules.
Some discussions have started with Google for the Android Consortium, and with the CE4A for the Terminal Mode (communication with external devices such as phones). Not ready yet to use standard devices for car control. Also there is a willingness to keep control on what runs in the the car, by the car manufacturers, even if they are open to allow additional application execution on the GENIVI platform.
Software development
GENIVI is organized with Expert groups. A PMO coordinates it. Solution Archhitects perform the Architecture Coordination.
From the design made, it goes to Execution Teams for coding (could be: feature addition to existing FLOSS bricks, or code creation if nothing is ready), and Maintenance teams for maintenance tasks.
The platform consists of 80% of existing FLOSS components (without modification), 15% of modules to be adapted (conman e.g.), 5% of specific code to be developed. But 100% of FLOSS code at the end.
It’s up to the point to allow car drivers to add/modify apps in the car (re-using the Meego concept).
The Baseline Integ. Team provides a GENIVI environement (a la distribution) to allow other teams to work.
The alliance has categorized 3 levels of licenses (Apache and GPLv2 are green). For code creation either L/GPL or Apache or BSD is used, depending on interfaces. Contributions not yet completely controled under the Governance model (case of conman of Meego recently). Intellectual Property is transmitted to the Alliance.
Governance
There is also another IVI module with Meego, which is hosted by the Linux Foundation. So not yet possible for GENIVI to be hosted here as well. The alliance has not considered joinnig an existing foundation (Eclipse, Apache) to benefit from Governance and tooling.
Governance in place on what enters in GENIVI as for now. as well as code scanning.
FOSSology and BlackDuck are among the tools used for validation and are still under evaluation.
I asked whether there are possibilities to share best practices and governance docs in the future. It has not yet been decided, but seems possible.
The Alliance is also looking at conformity around CGL and LSB.
Finance
It costs 5 kUSD to enter in the consortium (minimum fee for an Associate member). Many levels of contributions (and access to deliveries) exist with appropriate power of decision.
The Business model remains to be clarified completely.
The budget is around 800 kEUR yearly. With some permanent members to manage infra mainly.
Life cycle
GENIVI will be a market reality in 2013.
The Life Cycle is 3/4 years for development, but up to 15 years for the car.
I underlined the possibility for the GENIVI alliance to work with OPEES to share long life cycles best practices with the aerautics sector. (Side note: Ericsson joined OPEES recently)
Importance for PSA
Separated developments are not cost effective anymore. So PSA wants to put emphasis on what differentiates them and share what is not.
More requirements are put on providers in fact with the GENIVI offering. As a consequence it activities will evolve around integration capabilities, buying
capabilities, partners management, … At the end the car manufacturer is impacted by errors, where ever they come from. Its image is the one people remember.
Technical Constraints
- Using networks such as CAN, MOST, Flexray, 1394 Auto, Ethernet AVB
- Wake up time constraints (< 200ms)
- Energy management linked to usage conditions (driving, parked, …)
- HW constraints (# of accesses to flash memory )
- Temperature constraints
- Boot time constraints
- Ergonomy constraints, especially when driving, and accessibility
- Safety constraint (connection to critical car components, even audio e.g. could be dangerous)
- Real time treatment required. back drive radar, or camera.
- Security constraints (virus, openness, …) – ISO 2626-2 standard to be considered.
- Studies also around Virtualization, micro OS, …
Question: What about car update from Internet during the night ? Answer: these types of studies are ongoing.
Of course, not everything will become easy and nice in one day. But after looking at a 
