Android

Android vs. Linux for Automotive TY Kim, APAC Solutions Architect

Definition of Software Architecture

“A software system’s architecture is the set of principal design decisions made about the system.” — Software Architecture, Richard N. Taylor et al.

2

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

Which one counts the most? 3

Typical IVI projects Roles and Responsibility 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

4

Top Down or Bottom Up? Bottom Up * Analysis of existing system * Past project experiences * Engineering capability * Ecosystem

Top Down * Requirement gathering * Architecture design * Cost / Schedule analysis * Project planning

5

SWOT Analysis of Android for Automotive

[Strength] - Platform Maturity - EcoSystem - Open Source

[Opportunity] - Connected Car - Services Platform - Convergence

[Weakness] - Mobile Oriented - Pace of Evolution - Patent Issues

[Threat] - Google Dependency - Support & Maintenance - Smartphone

How to address these? 6

High Level System Description

Pros Cons

7

Design Decisions  System structure  Functional behavior

 Interaction  Nonfunctional properties  Implementation

8

Architectural Documentation

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

9

System Structure Android

10

Linux

 (modified) Linux

 Linux

 Custom set of middleware

 Custom set of middleware

 Dalvik VM + Native Runtime

 Native

 Android Application Framework

 Qt / EFL/ Gtk / Custom

 Android HMI Framework

 HTML5 / Custom

 600K Apps + 500K Developers

 Unknown

Functional Behavior and Interaction Android

11

Linux

 Custom HAL

 Linux Driver

 JNI / NDK / Zygote

 App Framework TBD

 Binder / System Service

 Linux IPC (D-Bus)

 Content Provider / Intent

 Socket, Signal, Daemon

 Activity / View

 Linux Process / Thread

Non-functional Properties Android  Mobile (and TV?) oriented

 Versatile

 Commercially proven architecture

 Flexible architecture

 Wealth of information

 Loosely coupled components

 Tightly integrated components

 Various pace of innovation

 Fast pace of innovation

12

Linux

 Good amount of information

Implementation Android  C / C++ / Java

 C / C++ / HTML5

 Driven by Google with contribution from others

 Community driven

 High quality of code in general

 Roadmap can be known / discussed

 Roadmap unknown

13

Linux

 Quality of code varies

Android Multimedia Framework

14

Android MMF - Stagefright

15

Linux Multimedia Framework

16

Consideration for Reusability  User Interface (Look & Feel):

ISV

 Foundation Technology:

OSV

 Hardware System:

Tier-1

 Product Specification:

OEM

What is changing with: • New Hardware • New Tier-1 • New OEM • New OS • New Features • New HMI • New Model

? 17

HMI

Changes with new UX

Business Logic Custom Middleware

Reuse strategy needed here

Core Middleware OS / Drivers Changes with new hardware

Hardware

Unified Platform? Unified Platform

Low

HMI Business Logic Custom Middleware

Mid

Core Middleware OS / Drivers Hardware

High

18

What is GENIVI? Audio

Graphics

Multimedia

Speech

CE-device

External Access

Connectivity

Positioning

Security

Personal Information Management

Package Management

Networking

System Infrastructure

OS, Linux kernel, drivers and libraries

19

GENIVI Compliance Specific Component

Abstract Component • Defines only it’s interfaces and behavior, but does not refer to any specific implementation – e.g. libc, OpenGL, Bluetooth stack, Telephony Placeholder 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

20

Strictness

• Basis of the GENIVI platform • An actual Linux or Open Source package • E.g. Linux kernel, ALSA Sound, ConnMan, gStreamer Framework

What about Hybrid Platform? HTML5

Android APP

Android

Native APP

Native Lib

Android APP

GENIVI APP

Native APP

Android

GENIVI

Linux

Linux

PFI Tizen In-House

Android APP

Android

Linux

Hypervisor

Linux

CPU

CPU

CPU

Option1

Option2

Option3

 Option1: Native library can be added to Android  Option2: Some commercial Hypervisor Solution  Option3: Heavy modification on Android

How feasible are these options? 21

Other Evaluation Criteria  Development productivity

 Automotive features  Costs  Risks

 Resources  Consistency  Testability  Flexibility

 Differentiation  Longevity 22

SWOT Analysis of Linux for Automotive

[Strength] - Full Customization - Ownership - Open Source Community

[Weakness] - Too much freedom - No control tower - 3rd Party support

[Opportunity]

[Threat]

- Scalability - Industry Support (GENIVI) - Longer lifecycle

- Initial Development Cost - Maturity of Technology - Support & Maintenance

How to address these? 23

Iterative Approach for Platform Design Gap Analysis

Requirement Development

Architecture Design

Validation

Proof of Concept

24

Proof of Concept Design  Implementation of the proposed architecture

 The scope of the work may include: – Fastboot optimization – Selective integration of available IP

– App / HMI framework – Reference UI

25

Validation

Validation Plan

 Feature list

Execute Tests & Benchmarks

 Performance  Interoperability

100

80

 Scalability

60

40

20

0

View and Analyze Results

Improve

send

Collaborate with Developers

26

Identify and Report Issues

27