And of course, I couldn’t resist making again comments 😉
Posts Tagged ‘LSB’
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
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.
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.
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.
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.
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.
- 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.
Following Fosdem 2010, I’m more and more convinced that in order for our community to progress more rapidly and deeply, we need some more standards to build upon.
I’ve participated to an excellent talk around the joint translation effort of packages cross-distributions, and we clearly need more initiatives like that.
A first one I’m thinking of is a Changelog format standard. The FSF is pretty evasive on it, and many major FLOSS programs have completely different format. I think we now have the sufficient maturity to delegate to the Linux Foundation the realization of a ChangeLog format standard that will contain all the info needed and able to be processed automatically. We need at least for each modification the version, the date and the authors, maybe a tag/id, then lines describing what has been done. I’m sure some other clever people will find more useful info to add, but that should not make 20 pages of specifications. And after that it’s defined, every GNU program could adopt it, as well as the Linux kernel, Apache projects, … and that would help a lot in order of automatic processing of them (for creating some content in packages, to rewrite svn2cl, cvs2cl and create git2cl, hg2cl which would then be more obvious).
Of course, we should also work at improving the LSB and its FHS. Too many packages today place tools in different places for no good reason IMO. Again maturity is high enough to standardize all those places, making cross-distribution work much easier, as well as ISVs work ! Why would partprobe be in /bin on one distro and /usr/sbin on another 😦
There are sufficient reasons to have differences. And we all like that. But we shouldn’t create artifical ones ! So each time it’s possible, we should group and remove all those useless differences which do not bring added value, but create more hassle to deal with Linux. Using the mailto:firstname.lastname@example.org mailing list is a very good start which should be encouraged.