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