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

2. 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.

3. Software Architecture – Who Cares What? Stakeholder TypesInterests End UserUsability, Functionality, Performance, Reliability CustomerPrice, Support & Maintenance cost, Features, Schedule DeveloperUnderstandability, Clear requirements, Testability Component VendorsSystem interface, Collaboration model, Integration Rules Project ManagerWork partitioning, Resource, Schedule, Budget MaintainerSystem structure, Documentation, Consistency ArchitectConsistency, Clarity of Concept ManagementPrice, Time to Market, Differentiation, Company Strategy 3 Which one counts the most?

4. Typical IVI projects Roles and Responsibility 4 NameRoleWork Scope Semi. VendorBSP for App Processor Multimedia Graphics Reference Hardware Linux BSP OpenGL/OpenVG Media Codec Wind RiverRequirement 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 ISVTelematics ADAS Voice Recognition Navigation Telematics, ADAS, VR, Navigation IHVDevice DriversDevice Drivers in Binary and/or Source Tier-1Systems Integration Device Manufacturing Commercial Hardware Systems Integration Design / Product Validation OEMCar OEMSystem Specification Quality Assurance

5. 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

6. 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?

7. High Level System Description 7 Pros Cons

8. Design Decisions  System structure  Functional behavior  Interaction  Nonfunctional properties  Implementation 8

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

10. 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

11. 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

12. 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

13. 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

14. Android Multimedia Framework 14

15. Android MMF - Stagefright 15

16. Linux Multimedia Framework 16

17. 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 ?

18. Unified Platform? 18 OS / Drivers Core Middleware Business Logic Hardware Custom Middleware HMI Low High Mid Unified Platform

19. What is GENIVI? 19 Audio Graphics Multimedia Speech Connectivity Package Management Package Management Security System Infrastructure Networking External Access External Access CE-device Positioning Personal Information Management Personal Information Management OS, Linux kernel, drivers and libraries

20. 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 3 rd party software provider – e.g. DVD Playback Placeholder Component Strictness

21. 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 Option1Option2 Option3 GENIVI HTML5 How feasible are these options? Linux

22. Other Evaluation Criteria  Development productivity  Automotive features  Costs  Risks  Resources  Consistency  Testability  Flexibility  Differentiation  Longevity 22

23. SWOT Analysis of Linux for Automotive 23 [Strength] - Full Customization - Ownership - Open Source Community [Weakness] - Too much freedom - No control tower - 3 rd Party support [Opportunity] - Scalability - Industry Support (GENIVI) - Longer lifecycle [Threat] - Initial Development Cost - Maturity of Technology - Support & Maintenance How to address these?

24. Iterative Approach for Platform Design 24 Requirement Development Architecture Design Proof of Concept Validation Gap Analysis

25. 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

26. Validation 26  Feature list  Performance  Interoperability  Scalability Validation Plan Execute Tests & Benchmarks Collaborate with DevelopersIdentify and Report Issues View and Analyze Results Improve send

27. 27