20200512-Virtual-Technical-Summit-AASIG-VehicleAPI-VHAL-Workshop-Minutes

# Introduction

Philippe Robin welcomed everyone and shares the agenda and his expectations (aligned with the next paragraphs names)

Alexander Domin as a moderator describes the agenda (slide 2)

TODO

## Project overview & proof-of-concept demo

# Main part

Alexander shows the current overview and status.

Architecture on slide 3 showing Android HU + other ECUs that can be reused for other operating systems as well.
On Android: App that represents the ui and representation of gathered data from Data Server

Alexander explains the headunit layers.

App with Manifest containing permissions (concept). App is implementing UI and business logic. Rely on data from boardnet. We introduce a data server (GraphQL server) that will connect to vehicle network (SOME IP, LIN, etc.). Data server will translate OEM data from network to VSS specification compliant data - this is specifically VSS Feeder component. Presented components are logical components - not necessarily separate entities.

Authentication service protects data from unwanted access - generate tokens (JSON Web |Tokens) for application - it needs to file requests to access data. Package Manager component is an AOSP component - it serves information about application permissions granted during app installation. Based on those permissions data server will be able to determine if to grant access to data or not.

Alexander presents work split based on work packages identified during last February f2f meeting.

Feeder is about to connecting data server to IP network. Runtime configuration. Deployment describing mapping between CAN, SomeIP, signal world to VSS standard. Plan to work on helping developers to make this glue logic.

Ongoing work packages on slide 4.

Current contributor does not mean to own the domain - contribution on all areas are welcome!

*Request for contributors*
(slide 4): VSS Database concept is lacking contributors.
Requesting other parties to join in this or creating application using GraphQL to access Vehicle Properties

Q: Does VSS server provide Authorization to vehicle data access, similar to standard Android permission model?
A: Yes, similar to standard Android model, certain permissions (added for VSS access) can be granted to app, only difference is that the enforcement of permissions are on graphql server side.

Q: Did you consider passing the VSS information to the Vehicle HAL from Google? A: We will answer this later during presentation

Q: how would it be possible to have VSS database running on basic ECUs? are you considering some kind of powerful ECU like a central unit communicating with small ECUs?
A: Not decided yet, good question, no plans related to HW, rather investigating APIs and needed operations to achieve this, depends on translation effort from vendor-specific standards to VSS. Nothing specific in mind when comes to ECU power.

• VSS Database: storage and caching - need low latency, we need to investigate what kind of storage suits here.
• VSS data server - more complex than key - value. More complex queries will be allowed with this API. Obeys authentication and authorization mechanisms.
• Authentication Service - who and which kind of data can access.
  • typesafe API framework for interacting with data server.

Stefan Wysocki explains and then shows the demo:

• `vss-feeder` module means `VSS Feeder` component on the diagram (slide 3)
• `vss-graphql` means `Apollo GrapQL` component on the diagram (slide 3)
• `db` which is json database (for now) and means `VSS Database` component on the diagram (slide 3)
• Project setup on Docker
• OpenDS simulator used for providing Vehicle data
• Vss-Feeder connects to simulator, retrieves the properties and save it in database
• Apollo GraphQL Server enables to play around with GraphQL query
• Able to query data from car by GraphQL query based on schema generated from VSS standard

Stefan explains relation between OpenDS and VSS feeder - it's our input. Later on we are translating data from OpenDS to VSS standard. Apollo GraphQL is responsible for resolving queries from apps. It asks from database server requested values. data-feeder and data-server are separate binary running.

Apollo brings some playground that can act as test app. Can be accessed as localhost:4000 and allows to write queries directly. VSS is structuring values in tree structure.

• Example: current gear: vehicle->drivetrain->transmission->gear.

Apollo playground gives you some hints about available leafs and provided types. Structuring is an advantage over standard Android solution. Queries can contain requests for many values from different branches. One can see that values are read in runtime from simulator (on playground). You can subscribe for changes. Values can be monitored without polling - advantage over Android model.

Alexander jumps in and explains VSS is a standard specified in YAML files available on GitHub. It is a JSON like specification - this file can be translated to GraphQL schema (showing schema for GraphQL). Explains how VSS schema translates to GraphQL schema.

Q: are you working with low level APIs such as VSOMEIP in order to get the data ?
A: this might be out of scope of this standardization group, however that's the plan. This simulator is for non production. Explains about various possible feeders that can be developed for many solutions even OEM custom ones.

Q: I think Franca is kind of Model tool that we can use for translate those interfaces
A: Alexander - what we identified during f2f and in Detroit - additional architecture approach - showing additional VHAL communicating with Apollo GraphQL. In genivi we can provide component (VHAL) basing on AOSP VHAL HIDL and GraphQL interface basing on VSS.

Q: can the Google boxes (green) be replaced by another OS, e.g. Apple ... ?

## Topics discussion

Alexanders shows slide 6 to extend the view of current state.

• Idea: Provide support for applications using already established CarAPI by Google
• WRide generic component (Vehicle HAL) to be reused since GraphQL is standardized and HIDL is standardized

Q: Whether 3rd party applications will be allowed to access Vehicle data from VSS?
A: Depends on OEM if it will grant permissions to 3rd party app

• mapping between VSS and AOSP VHAL spec - where to store it?
• inconsistencies between standards (unit conversion like in tank capacity: VSS in l or %, AOSP in ml)
  • gaps to be identified and proceed with actions
  • maybe we should convince Google to change something and look at the experience bundled in VSS contributions (OEMs already discussed the VSS format)
• authentication - reminds about concept of querying Package Manager about app permissions by Authentication Service. How to create tokens for apps using Car API - investigation to be conducted ?
• create VHAL component - PoC and further on should there be a reference implementation or what ?

Q: Is it viable to provide a kind of VssAuthentication service library/.jar to Application layer and reduce changes at framework layer ?

A: Stefan: we discussed similar. Bundling authentication library with apps can be challenging.

A: Alexander: we need to protect secret, thus we would like to put it into framework layer. We need this kind of discussions in future.

Q: as a corollary to the previous question, would it be feasible to encapsulate the communication from the app to both the authentication service and the graphql server within a contentprovider ?

A: Already discussed, we are also considering this kind of approach, it is covered in the "Internal Data Server Architecture" concept

### Permission groups specification.

Alexander: Deeper catch on security. We need to protect our data. Stefan was looking in concept of permission model of Android.
We discussed with Gunnar and Stefan that we would like to have similar perm model in Manifest with different prefix: (e. g. *vss.permission.AMBIENTLIGHTING_READ*). This what Package Manager is working with and storing. We don't have group of perms for VSS leafs. We need to find out syntax to specify this, where to store spec and how to handle. What I was trying to do: Apollo GraphQL directives - processed when data is served.

Alexander: explains the example for ambient light in GraphQL schema and how directives can be used to check perms from token.* vspec file is YAML file with VSS specification. Here comes VSS layers (depl files(?)). Combining vspec file and depl file we can get GraphQL schema with perms directives.

Gunnar: You find easier to apply perm for signal instead of perms to signal. But your depl file is a perfect example of VSS layers.Alexander: as Stefan pointed all the groups below the leaf. That's probably not best approach.

Gunnar: this can be solved with tooling but we should not base on that and think about just text editor as first point of act.

Q: What is the advantage of having both VSS & Android VHAL solutions in parallel? If we have Android VHAL anyway Apps can access it.

A: Both ideas has been already considered and discussed (see reference "internal data server" and "custom HAL" concept diagrams)

A: Gunnar: VSS is something which aims at being as wide as it is possible (other ECUs, cloud connected services outside of the car). In VSS there are thousands of definition, Android has only a minimal subset of those values. Google could extend its list but we doubt to be full VSS spec. VSS could be better suited to industry demands, seems to be better alternative or a useful complement to Android.

>>>>>>>>>>>>>>>>>>>>> INSERTION POINT

### Translation of permission groups.

Alternatives:

1. permission groups resolved inside server

2. permission groups translated to allowed attributes in Authentication Service on Android

### JWT Token what will be included and how it will be done? And generation process?

JWT might use asymmetric encryption to resolve the problem with sharing the secret between both parties

(disscusion about security)

## Technical readiness level assessment and discussion on how and when to reaching out to Google
Alexander has described the 2 points that can be discussed separately with Google.

# Wrap up
Meeting ends with feedback gathering + request for contributions

Reminder about weekly calls