Android vs. Linux for Automotive

TY Kim, APAC Solutions Architect

Definition of Software Architecture

2

“A software system’s architecture is the set of principal design decisions made about the system.”

— Software Architecture, Richard N. Taylor et al.

Software Architecture – Who Cares What?

Stakeholder Types Interests

End User Usability, Functionality, Performance, Reliability

Customer Price, Support & Maintenance cost, Features, Schedule

Developer Understandability, Clear requirements, Testability

Component Vendors System interface, Collaboration model, Integration Rules

Project Manager Work partitioning, Resource, Schedule, Budget

Maintainer System structure, Documentation, Consistency

Architect Consistency, Clarity of Concept

Management Price, Time to Market, Differentiation, Company Strategy

3

Which one counts the most?

Typical IVI projects Roles and Responsibility

4

Name Role Work Scope

Semi. Vendor •BSP for App Processor

•Multimedia

•Graphics

•Reference Hardware

•Linux BSP

•OpenGL/OpenVG

•Media Codec

Wind River •Requirement Analysis

•BSP/Middleware Enablement

•Applications

•Kernel Drivers create/modify/integrate

•IVI Framework create/modify

•Application create

•Software Integration

•iPod, Fast Boot, Automated Test, App Store/SDK

ISV •Telematics

•ADAS

•Voice Recognition

•Navigation

•Telematics, ADAS, VR, Navigation

IHV •Device Drivers •Device Drivers in Binary and/or Source

Tier-1 •Systems Integration

•Device Manufacturing

•Commercial Hardware

•Systems Integration

•Design / Product Validation

OEM Car OEM •System Specification

•Quality Assurance

Top Down or Bottom Up?

5

Bottom Up

* Analysis of existing system

* Past project experiences

* Engineering capability

* Ecosystem

Top Down

* Requirement gathering

* Architecture design

* Cost / Schedule analysis

* Project planning

SWOT Analysis of Android for Automotive

6

[Strength]

- Platform Maturity

- EcoSystem

- Open Source

[Weakness]

- Mobile Oriented

- Pace of Evolution

- Patent Issues

[Opportunity]

- Connected Car

- Services Platform

- Convergence

[Threat]

- Google Dependency

- Support & Maintenance

- Smartphone

How to address these?

High Level System Description

7

Pros

Cons

Design Decisions

System structure

Functional behavior

Interaction

Nonfunctional properties

Implementation

8

Architectural Documentation

9

A template for documenting software and firmware architectures, Version 1.3, 15-Mar-00, HP

Android

(modified) Linux

Custom set of middleware

Dalvik VM + Native Runtime

Android Application Framework

Android HMI Framework

600K Apps + 500K Developers

Linux

Linux

Custom set of middleware

Native

Qt / EFL/ Gtk / Custom

HTML5 / Custom

Unknown

10

System Structure

Android

Custom HAL

JNI / NDK / Zygote

Binder / System Service

Content Provider / Intent

Activity / View

Linux

Linux Driver

App Framework TBD

Linux IPC (D-Bus)

Socket, Signal, Daemon

Linux Process / Thread

11

Functional Behavior and Interaction

Android

Mobile (and TV?) oriented

Commercially proven architecture

Wealth of information

Tightly integrated components

Fast pace of innovation

Linux

Versatile

Flexible architecture

Good amount of information

Loosely coupled components

Various pace of innovation

12

Non-functional Properties

Android

C / C++ / Java

Driven by Google with contribution from others

High quality of code in general

Roadmap unknown

Linux

C / C++ / HTML5

Community driven

Quality of code varies

Roadmap can be known / discussed

13

Implementation

Android Multimedia Framework

14

Android MMF - Stagefright

15

Linux Multimedia Framework

16

Consideration for Reusability

17

User Interface (Look & Feel): ISV

Foundation Technology: OSV

Hardware System: Tier-1

Product Specification: OEM

OS / Drivers

Core Middleware

Business Logic

Hardware

Changes with new hardware

Reuse strategy needed here Custom Middleware

HMI Changes with new UX What is changing with:

• New Hardware

• New Tier-1

• New OEM

• New OS

• New Features

• New HMI

• New Model

?

Unified Platform?

18

OS / Drivers

Core Middleware

Business Logic

Hardware

Custom Middleware

HMI Low

High

Mid

Unified Platform

What is GENIVI?

19

Audio Graphics Multimedia Speech

Connectivity

Package Management

Security

System Infrastructure

Networking

External Access

CE-device Positioning

Personal Information Management

OS, Linux kernel, drivers and libraries

GENIVI Compliance

20

• Basis of the GENIVI platform

• An actual Linux or Open Source package

• E.g. Linux kernel, ALSA Sound, ConnMan, gStreamer Framework

Specific Component

• Defines only it’s interfaces and behavior, but does not refer to any specific implementation – e.g. libc, OpenGL, Bluetooth stack, Telephony

Abstract Component

• A placeholder that has an established name, defined purpose and must meet specific requirements but the implementation is either:

• Non-existent in open source

• Provided by 3rd party software provider – e.g. DVD Playback

Placeholder Component

Str

ictn

ess

What about Hybrid Platform?

21

CPU

Android APP

Android

Linux

Native Lib

Native APP

CPU

Android APP

Android

Hypervisor

GENIVI APP

CPU

Native APP

PFI

Tizen

In-House

Linux

Android

Android APP

Option1: Native library can be added to Android

Option2: Some commercial Hypervisor Solution

Option3: Heavy modification on Android

Option1 Option2 Option3

GENIVI

HTML5

How feasible are these options?

Linux Linux

Other Evaluation Criteria

Development productivity

Automotive features

Costs

Risks

Resources

Consistency

Testability

Flexibility

Differentiation

Longevity

22

SWOT Analysis of Linux for Automotive

23

[Strength]

- Full Customization

- Ownership

- Open Source Community

[Weakness]

- Too much freedom

- No control tower

- 3rd Party support

[Opportunity]

- Scalability

- Industry Support (GENIVI)

- Longer lifecycle

[Threat]

- Initial Development Cost

- Maturity of Technology

- Support & Maintenance

How to address these?

Iterative Approach for Platform Design

24

Requirement Development

Architecture Design

Proof of Concept

Validation

Gap Analysis

Proof of Concept Design

25

Implementation of the proposed architecture

The scope of the work may include:

– Fastboot optimization

– Selective integration of available IP

– App / HMI framework

– Reference UI

Validation

26

Feature list

Performance

Interoperability

Scalability

Validation

Plan

Execute Tests & Benchmarks

Collaborate with Developers Identify and Report

Issues

View and Analyze

Results

Improve

send

0

20

40

60

80

100

27