Automotive Grade Android (AGA) Niclas Lindmark Swedspot

Transcription

1 Automotive Grade Android (AGA) Niclas Lindmark Swedspot

2 Collaboration is a key issue! If it fails, it might look like this...

3 Transforming from todays closed solutions to open solutions Existing App App App Smart phones / retrofit devices Open platform App App App App In-vehicle platform The future with AGA Vehicle integrated device Open platform App App App Existing Vehicle integrated & closed Vehicle centric

4 Automotive Grade Android - AGA VISION CORNER STONES AGA Open-innovation ecosystem for in-vehicle software and connected services Open-source Piggy-back on a dynamic and large eco-system Light-weight framework that stays in sync with Android Where developers and system builders meet A marketplace for developers A standardized framework for system builders

5 Customer Offer for Developers Developer Zone an open and shared community an open portal enabling downloads of artefacts and information SDK software libraries and interfaces enabling infotainment application development for vehicles Developer Guidelines a collection that eases how to write safe and automotive adapted applications Simulation Environment tools for developers enabling test without having access to a real target environment Reference Platform the AGA SDK is deployable on hardware

6 FMS Signals in AGA API Configuration and Identification: VIN, Brand, Model, FuelType Running Status VehicleSpeed, Pedal position Maintenance: batterystatus, Odometer, malfunctionindicator, Personalization DriverIdentification, seatadjustment, mirrorpan/tilt Driving Safety AirbagStatus, ABS enabled/engaged Climate Temperature, RainSensor, WiperStatus, Vision and Parking LaneDepartureDetection, ParkingBrake,...

7 Customer Offer for System Builders A framework that is maintained and further developed by a community Compatibility with a large set of Apps developed for AGA Well-defined interface for easy integration with hardware Security/policy enforcement Comprises security mechanisms to ensure only safe operations are permitted Reference implementation

8 OAA and AGA Android Auto SDK (OAA) AGA SDK Audio Messaging Navigation Vehicle signals Hardware buttons Policy management Driver distraction

9 Genivi vs AGA Genivi Adoption of IVI-platform based on Linux Bottom-up approach IVI builders first Complete IVI AGA Open innovation in vehicle Top-down approach developers first Extends Android with interfaces for automotive

10 Stop

11 Many services for open innovation Many stake holders Short tail and long tail OEM / dealer workshops Finance / insurance companies Vehicle/fleet operator Goods / people owner/forwarder Driver / passengers Authorities / road operators Many opportunities to offer customer value! Open innovation is key to be cost-effective Dynamic Service Planning Remote diagnostics Remote SW updates Breakdown services Vehicle management Security/safety services Pay-as-you-drive solutions Vehicle management Driver time management Security/safety services Traffic, transport management Goods tracking CO2 reporting Transport management Infotainment (Internet) Navigation & traffic info. Driver security (e-call) Vehicle management Security/safety services Traffic management Messaging Vehicle centric services Transport and person centric services

12 Automotive Grade Android - Architecture Applications Applications Applications Northbound i/f Automotive Grade Android Southbound i/f OEM integration Northbound interface Read from vehicle Write to vehicle React on driver distraction changes SDK Build ROMs Emulator Simulator Documentation Southbound interface Integrate vehicle data Integrate hardware buttons Set access policies Change driver distraction level

13 Broadcast Automotive Grade Android Technical Architecture 3PP Get API using my Certificate Application SDK Automotive Manager Get VIL Implementations Certificate, Proxy Port,... Tube Automotive API Tube Gets Config Package Manager App Manager Policy Manager To Android Policy Decision Point Hardware button controller Proxy Signal Configuration Driver Distraction VIL VIL VIL VIL VIL OEM OEM Policy Implementation OEM Button integration OEM Signal Integration OEM Signals Properties Configurtion OEM Driver Distraction Implementation

14 Developer Zone Continuous integration Repo Wiki

15 Developers Zone status Developer Zone in operation Repository: Gitolite Continuous Integration: Jenkins Wiki and tracking: Redmine Developer Zone Code available HMI Developer Zone FFI SICS-project co-operation Simulation Environment Support for FMS signals

16 Summary Business Drivers The connected eco-system will grow rapidly when installed base of open innovation platforms reach critical mass Automotive Grade Android can piggy back on the existing large Eco-system Open integrated platforms will be there but there will be many different kinds from various OEM s initially - to enable the connected eco-system and open collaboration The app store model is well suited to manage the collaboration model between OEM s, aftermarket suppliers and 3PP service providers, especially when a wider range of aftermarket services are required The existing app store 70/30 split model might work, but for B2B it might need to offer additional business models

17 The connected eco-system Connected drivers Connected people and goods Connected fleet operators Connected society Connected OEMs & suppliers Connected dealers & workshops Connected goods and people

18 Use Case: Truck OEM App store model Description The OEM factory fit in-vehicle units in new trucks The OEM provide cloud portal with back-end and app-store Customer offer The OEM market its own brand as leading in-vehicle integrator and cloud-portal Controlled access and management of vehicle data Safe use of systems while driving Customer specific business integration and accessories by local suppliers Enabling safe use of third party apps and services in the in-vehicle infotainment systems System and Services Upgradeable on aftermarket Business driver Additional revenue from IVU and own services Enabling additional revenue from connectivity services at low cost Increase business innovation and technical innovation

19 Use Case: After Market Connectivity Supplier Description The AM Connectivity Supplier provide a complete customer adapted solution, integrates the in-vehicle unit towards the OEMs open interface, provide cloud portal with a back-end and an app-store and services Customer offer Customer specific solution Controlled access and management of vehicle data Safe use of systems while driving Enabling Android apps from Google Play to be used in the in-vehicle system Business driver Revenue from complete solution (products and services) app-store, IVU and own services Enabling 3PP connectivity services at low investment

20 Use Case: App service supplier Description The App service supplier provide a complete customer adapted services Customer offer Customer adaptation of generic service Business driver Revenue from connectivity services

21 OAA and AGA The Open Automotive Alliance has presented a non-ivi solution, similar to MirrorLink and CarPlay, where you connect your Android device via USB to access Android applications. It is called Android Auto. The IVI system can be Android Auto enabled using Automotive Grade Android The Automotive Grade Android is an IVI solution based on Android, that extends the APIs to include access to Vehicle data and driver distraction information

22 GENIVI and AGA The Genivi IVI solution is based on open source software, but does not include a defined API that provides access to Vehicle data and driver distraction information The Automotive Grade Android is an IVI solution based on Android, that extends the APIs to include access to Vehicle data and driver distraction information

23 Summary Our vision is to develop an open innovation global eco-system for invehicle software and connected services based on open source. Developers Zone for Automotive Grade Android is launched for open source on September 4th 2014 developer.lindholmen.se Hosted by, Lindholmen Science Park Governance of Dev Zone by Combitech AB

24 Governance of Open Source The governance model used by an open source project encapsulates all the hard questions about a project. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivates based on the project? What compliance requirements are there, and how are these enforced? Governance determines who has influence and control over the project/platform beyond what is legally deemed in the open source license: it is not enough to understand the open source license used by a project. It is the governance model that determines whether or not decision making within an open source project is open, accessible, and transparent to all users or whether it is concentrated amongst a specific set of users.

25 Governance overview Governance model Access Development Project Roles Decision Process Contribution Process Support Derivates Community AGA

26 Governance of AGA, proposal based on the Open Governance Index (OGI) criterias Access: developer support mechanisms, availability of latest source code, public roadmap, and transparency of decision making Development: Decision and Contribution processes that ease the ability of developers to influence the content and direction of the project Derivatives: the ability for developers to create and distribute derivatives of the source code Community: a community structure that does not discriminate between developers

27 Governance - Access Source code is freely available to all developers, at the same time. Source code is available under a permissive OSI-approved license: Apache 2.0 Developer support mechanisms: project mailing lists, forums, bug-tracking databases, source code repositories, developer documentation, and developer tools are available to all developers. The project backlog is available publicly. Transparency of decision mechanisms project meeting minutes/discussions are publicly available such that it is possible to understand why and how decisions are made relating to the project.

28 Governance Development 1(2) Transparency of contributions and acceptance process the code contribution and acceptance process is moderated by the maintainer, with progress updates of contributions. Transparency of contributions to the project possibility to identify from whom source code contributions originate. Accessibility to become a committer all developers can potentially become committers and are accepted by the maintainer Transparency of committers all committers to the project can be identified.

29 Governance Development 2(2) Project Roles and Responsibilities User, Maintainer, Contributor, Project Management Committee, Board Decision Process Roadmap and project backlog management Contribution Process Use of developer zone resources Support

30 Governance - Derivatives No trademarks are used to control how and where the platform is used via enforcing a compliance process prior to distribution. This is managed by the respective member companies Are go-to-market channels for applications derivatives constrained by the project in terms of approval, distribution, or discovery? No

31 Governance - Community Structure Flat community structure, i.e. no tiered rights depending on membership status Maintainer role elected by the Board

32