genivis value to the automotive industry

GENIVI´s value in the automotive IVI industry

12th November 2013

Korea Summit meeting

Graham SmethurstGENIVI Chairman

Department Lead – Product and Architecture Definition,

IVI and Connected Drive Systems

BMW Group

19-Nov-13 GENIVI is a registered trademark of the GENIVI Alliance in the USA and other countriesCopyright © GENIVI Alliance 2013

1

The Infotainment Challenge Faced by The Automotive Industry.

Graham SmethurstPresident GENIVI Alliance

25.09.2009

Inconsistent requirements

No common target for the application

content and service

suppliers

OEMs are seeking new supply chain that is more nimble and innovative

Solutions unique to automotive

Customers demand richer

features

Limited consumer alignment

Traditional supply model unable to access a

consumer eco-system

Smaller suppliers lack market resources to enter

a fragmented market

“The current automotive infotainment sector is so proprietary & fragmented it is incapable of supporting an independent eco system”


2

Headunit prices have plateaued.

New development / business model needed.

Significant cost reduction with factor 5 performance improvement

0

200

400

600

800

1000

1200

1400

2000 2003 2005 2008 2011 2012 2013 2014 2015

Radio

Entry Media

Entry Navigation

High Navigation

Architectural

integration


3

Supplier cost per Headunit generation.

The real Tier-1 cost of IVI platform development.

IVI SW Development

Automotive Middleware + operating system +

BSP

Applicationsincl. Application

Framework

Human-Machine Interface

Hardware Development

IVI SW Development

IVI Systems Integration

IVI Systems Validation / optimisation

Effort

10%

30%

60%40%

10%

40%

10%


4

The need to further reduce development costs demands The need to further reduce development costs demands The need to further reduce development costs demands The need to further reduce development costs demands softwaresoftwaresoftwaresoftware inheritance & reinheritance & reinheritance & reinheritance & re----

use.use.use.use.

Middleware

OS

Hardware

Applications

MMI

Middleware

OS

Hardware

Applications

MMI

Entry Media

Entry Nav

Middleware

OS

Hardware

Applications

MMI

ProfiNav

Automotive Middleware

Headunit

MMICustomer value add

“Ground hog day” in head unit development:

• Development of commodity content x3.• BMW specifics re-implemented x3.• Product validation x3• Problems solved with one supplier re-occur with others.• Limited time for innovation and new customer features.

• MMI x1


5

Re-alignment of the value chain is required.

A “Standard” IVI platform is key.

Value PropositionValue PropositionValue PropositionValue Proposition::::

Choice and Flexibility

Richer Feature Set,

Better TTM, reduced TCO,

Scalability.

Proprietary Platform

Open Platform

Platform R&D

Test and Validation

Platform R&D

Services & Solution

(R&D)

Test and Validation

Services &

Solution R&D



• Managed development cost.

• Control over validation costs

• Reduced time to market.

• Increased feature availability.

• Increased competition in the supplier base.

• Reduce the “heavy lifting” that characterises an automotive

infotainment solution.

• Commoditise the non-differentiating elements of an automotive

infotainment solution.

2 to 3 years 2 to 3 years 2 to 3 years 2 to 3 years

Hardware development /

cost down

Consistent software

backbone

Choice of best in class applications

Eco-System Partners

Software Platform

Effort


6

The search for the IVI General Purpose OS.

One size does not fit all.

Functionality

Top Navigation

Entry Navigation

Radio Entry Media

Desk top PCNetbookSmart phone

Consumer

Automotive

Media Player


7

Pre-GENIVI BMW proof of concept (2008)

Evaluate the power of the eco-system

Test the new

delivery model

Critical platform

review by an automotive

first tier

Assessment of the

development efficiency

POC Implement

A Sample functions

MMI graphics and control FM / AM radio

Speech recognition CD-CD playback

Text 2 speech CD-ROM data

Bluetooth hands free profile 2 & 3D navigation

Bluetooth phone book access Google Earth

PIM Uncompromised internet

SMS Picture viewer

iPOD interface (2-wire) Persistence Manager / User Profiles

USB AV (1-wire) CE Device Manager

Podcast Automotive Diagnostics

Personal Radio Power State Manager

Mass storage media player Download Manager

~1300 Software Platform Requirements.

~400 Software Components.

~10 SW Architecture Specifications.


8

Pre-GENIVI BMW POC architecture abstract

Software packages pre-integrated in the platform

Code created to make the platform automotivecompliant.

Licensed code from eco-system partners pre-integrated in the platform.

User interface logic and graphics

Open Source Kernel / Open Source Packages

Code created by the 1st tier.

Today

BMW A-SampleClassic implementationmodel


9

Why create an alliance?

The need for change

Create an eco-system capable and motivated to supplyapplications / services directly relevant to theautomotive industry.

• Benefit

o Reduction in the cost of application / services development, by

licensing from available and relevant solutions.

o Increased innovation rate and feature content by tracking the

consumer sector

o Reduced time to market.

• Consequence

o A middleware solution must be created that meets the “automotive

requirements” and at the same time provides a consistent target for

a developer community, employing technology, tools and methods

that are known to the target developer community.

o The volume of products using the middleware platform must be

sufficient to incentivise the developer community.


10

Enable multiple compliant middleware solutions asthe basis for product development.

• Benefit

o Managed validation cost

o Reduced software platform development cost.

o Commercial competition and choice

• Consequence

o GENIVI projects available via multiple distributors

o Compliance programme

Why create an alliance?

The need for change


11

HW Platform

Linux distribution + Kernel

HW Platform

AUTOSAR

OEM / Tier-1

customisationsGENIVI Components

Gateway

Lifecycle

…

Early Fkt

User interface & Application Developments Infrastructure services

Development

GENIVI Architectural Context.Focus on the pre-competitive middleware.

Headunit

Infotainment Controller Vehicle Controller

OEM Base Components


12

The GENIVI Operating PrincipalGENIVI is a Hybrid of Industry alignment activities and Open Source implementation projects.


13

So how does the traditional proprietaryautomotive development model work ?


14

High

Entry Nav

Entry Media

Radio

Supplier A, Microprocess X, OS 1

Supplier B, Microprocess Y, OS 2

Supplier C, Microprocessor Z, OS 3

• Development of commodity content x3.

• OEM specifics re-implemented x3.

• Product validation x3

• Problems solved with one supplier re-occur with others.

• Limited time for innovation and new customer features.

• MMI x3

Generation 1

High

Entry Nav

Entry Media

Radio

Supplier A, Microprocess X, OS 2

Supplier B, Microprocess Y, OS 3

Supplier D, Microprocessor Z, OS 1

• Development of commodity content x3.

• OEM specifics re-implemented x3.

• Product validation x3

• Problems solved with one supplier re-occur with others.

• Limited time for innovation and new customer features.

• MMI x3

Generation 2

Time

Re-use

• Complexity• Resource• Project Risk• Cost

1. Use open source withoutupstreaming or contributing

Pro Con

Re-use of forked

development a crossown volumes

Repeated funding offorked proprietarydevelopment

Shared development / inheritance fromupstream

Limited product volume

Development transparancy

Isolated from communiityinnovation

Close the gap alone

2. Engage in both GENIVI and the open source Communities - Establish a sustainable development network

Pro Con

Shared development, increasingapplicability of upstream sources

Speed to firstimplementation

Shared maintenanceLoss of full control in community activity

Home for shared code

Re-use from open source code andinnovation

Critical mass influence in open source projects and other consortia

Development transparency


15

So how does the open source developmentmodel work in automotive?

Time

• Re-use• Resource• Project Risk• Cost

Complexity

Time

• Resource• Project Risk• Cost

Complexity

Re-use

Open Source Community & Consortia

Collaborations


16

ConsortiumCollaboraion

Open source

Collaboraion

GENIVI Alliance The Home Of Open Source IVI development

Public Baselines

GENIVI Alliance will launch 2 public baselines:

Baserock GENIVI Baseline git://trove.baserock.org/baserock/baserock/morphs

Yocto GENIVI Baselinegit://git.yoctoproject.org/meta-ivi

GENIVI has moved all of it code development activities into open source projects hosted by GENIVI.http://projects.genivi.org/projects


17

Community / Consortia Collaborations

Autosar

• Autosar DLT specification made available to GENIVI.• Code implementation in a GENIVI hosted open source

project.

• GENIVI open source DLT used in BMW productionheadunit as the primary debug interface

• Mapping between Franca IDL and AUTOSAR SWC Template (GENIVI Common IDL project)

• Communication protocol between GENIVI and AUTOSAR software (GENIVI INC Transport project)

• GENIVI hosted project to implement and maintain code.


18

Community / Consortia Collaborations

W3C Automotive Business Group formed.GENIVI represented by LGE, Magneti Marelli, PSA, JLR, BMW, Visteon :

• Work is in progress to define exemplary use cases for the Vehicle Data API• LGE and QNX work to merge different existing proposals for the Vehicle Data API into a draft standard• Liaison with ISO

• TC 204: Intelligent transport systems• TC 22: in-vehicle transport information and control systems


19

Working to standardise Ethernet audio/video networking in the car.• Identify needs and implement solutions for the automotive domain:

eg. Fast Startup, System optimizations for robustness and integrity, BOM-cost reductions, GENIVI API integration

• Deliver guidance to idevelopers when implementing a stack for automotive usage

Contact person: mailto:[email protected] (Ethernet Networking Team Lead)

The relationship between GENIVI and product development

ProductDevelopment

GENIVI

GENIVI Alliance Product Development

• Specification of non-

differentiating

requirements.

• Architecture /

Component definition.

• Component selection,

modification, code

implementation.

• Development baseline

• Compliance

programme

• Product definition.

• Commercial partner contracts.

• Mandated GENIVI compliance

• GENIVI code re-use.

• Implementation & integration of OEM specifics.

• Upstreaming of enhanced/ bug fixed code.

• Donation of new code.

• Product delivery


20

The relationship between GENIVI, a member reference and a product.

GENIVI Development baseline

Hardware

Apps

User Interface

Hardware

Apps

User Interface

GENIVI compliantmember

reference

Hardware

Apps

User Interface

GENIVI compliantproduct

GENIVI Compliance

Optimisation / functional showcase

Optimisation / customisedOEM product


21


22

Summary

• The repeated effort and cost of vehicle infotainment development / maintenance demanded a new approach.

• GENIVI has :

1. fundamentally changed the way in which automotive infotainment solutions are developed and maintained, not just for one company but across the industry.

2. created a community that shares the development and maintenance load across multiple companies.

3. created an automotive community that is open to collaborate with other alliances and consortia to enable the integration of the car within „the network of things“

4. started to remove unnecessary fragmentation whilst enabling innovation – compliance programme + works with GENIVI

Thankyou

Differentiation based on a strong community platform.

Join us : http://www.genivi.org/

genivis value to the automotive industry

Documents