Page History

Philippe Robin welcomed everyone and introduces the agenda and his expectations

74 attendees

hands over the mic to Kevin Valdek

50 attendeesAlexander Domin as a moderator describes the agenda (slide #2)

slide deck for this workshop is here

## Project overview & proof-of-concept demo

Architecture on slide #3 shows Android Head Unit + other ECUs that can use other operating systems.
On Android: App represents the UI and provides a representation of data gathered from Data Server

Alexander explains the head unit 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 (e.g. 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 whether to grant access to data or not.

Alexander presents the work split (slide #4) based on work packages identified during last February f2f meeting.Feeder is about connecting data server to network. Runtime configuration. Deployment describing mapping between CAN, SomeIP, signal domain to VSS standard. Plan is to work on helping developers to make this glue logic.

Being a current contributor does not mean he/she owns the work item completely- contribution on all topics are welcome !

Alex requests for contributors in particular for the following work items

• VSS database concept creation
• app creation using GraphQL to access vehicle data

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.

Note: other useful link - Vehicle Data Model Overview & Gap Analysis including VSS is there

• `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

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

Apollo playground gives you some hints about available leafs and types provided. 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.

Code repos

Authentication Service implementation

• Sources: https://github.com/stefanwysocki/aasig_dev_platform/tree/develop/vendor/genivi/modules/VssAuthenticationService

External Data Server implementation

• Data server: Publishing of GraphQL comprehensive example done
  • Sources: https://github.com/GENIVI/vss-graphql
• VSS feeder: Basic functionality is working
  • Sources: https://github.com/GENIVI/vss-feeder

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 ... ? the question can be: is the concept only valid for Google?

A: Alexander - I guess could be similar. Left side could be reusable across platforms (Virtual ECU containing data server).
A: Gunnar - Right side green boxes is something that Google requires and is not valid for other systems. However overall approach (data server with VSS standard with GraphQL interface) is not bounded to Android only.

followed by short discussion

Q. the question could be - why not considering 100% open source not linked to Android, which is not 100% open

A. Android is 100& OSS, Google addons are not (and BSP addons can be closed source)

## Topics discussion

Alexanders shows slide #6 to extend the view of current project status and get a common understanding of the GENIVI Google VHAL architectural concept.

• the idea is to provide support for applications using already established CarAPI from Google
• and to write a 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 apps

A: Alexander: it's up to OEMs. We can see app evolution on mobile phones. If we provide APIsto these guys, we can expect maybe not as much but still a good amount of innovation. We need to create permission groups for internal devs (more attributes) and ext devs (less). Permissions model is the key and afterward it's up to OEMs what to do next.

A: Gunnar: This project is about helping automotive industry to be successful with Android that is actually demanded and we are focusing our current solution on AOSP

• 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 the 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 which is an option for the software architectural design

### Permission groups specification.

Alexander: Deeper catch on security (slide #8). 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 "internal data server" and "custom HAL")

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.

Q: Rather than building an adapter for a VSS feed into the AA VHAL (which hides VSS), have you considered building an alternative VHAL for AA (that does not have to be compatible with the existing AA VHAL) that uses VSS for the native data model?

A: Gunnar: please look at slide #17(Google VHAL + OEM Extensions inside) - We went forward with the assumption that companies would like to run Google Services on Android and would like to certify their solutions. Others maybe won't be compliant but we would like to be generic and compliant with Google's rules. This is why we need to implement AA VHAL.

Q: you need to expose VSS and not just use it as an intermediate language.

A: Alexander shows slide #17 - Access via Customized HAL - Google VHAL + OEM Extensions - which is an early architectural proposal that contains a service exposing VSS.

Alexander: back to permission groups, Alex shows on slide #11 the seq diagram -app -> getToken() -> Authentication Server -> getPackageInfo -> Package Manager -> read manifest -> Manifest file. App gets token basing on their perm and needs to pass this token to data server (Apollo GraphQL) with a query. Data server will then validate the query based on perm model from VSS layer (.depl file).

Slide #13 shows a different approach : instead of .depl file, permission groups file (json) contains the list of signals below perms. JSON file will be parsed by Authentication service.

Alex: there are two options:

1. permission groups are resolved inside the server

2. permission groups are translated into allowed attributes in the Authentication Service on Android

Discussion about token handling

Gunnar: change in groups description shouldn't imply change of behavior

Alexander: challenge with writing those spec files. I prefers permission groups in json files.

Gunnar: why not YAML?

Alexander: there is no library for YAML on AOSP, there is for JSON. Do we force YAML implementation on platform?

Gunnar: or do we create a compilation step for translating permission groups.

Alexander: we can switch.

Gunnar: about change of behavior on sequence chart - we can take a look at it other time.

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

Discussion about shared secret, asymetric signing with private key, token time out, one time usage.

Alexander describes the following 2 points that could be discussed with Google

• VSS as an alternative or complement to Google Vehicle Properties
• Access to vehicle data via GraphQL instead of Key Value pairs

Kevin: this is the presentation Gunnar and I delivered in the Automotive World webinar last week, recording is available

•  Introduction
  • slide #4: Project charter
    • Even though cars are connected, they are limited to specific OEM/brands
    • A lot of ideas and start ups introducing new services…
    • We want to harmonize these activities… Define building blocks with flexibility for common solutions… Define data exchange and access
  • slide #5: Vehicle data
    • not limited to specific types but clustered by anonymity (personalised, pseudonymized, anonymized)
  • slide #6: Services / Needs
    
    • up-to-date data, typically telematic through a cloud server, but also bulk on big data
• Data Model
  • slide #9: Common data model
    • the industry needs this (different implemenations for each OEM… This is to avoid this situation)
    • Gap analysis in the CCS project (CVIM, SensorIS, ISO20078, Android Automotive, VSS) in 2019
  • slide #10: Vehicle Signal Specification (VSS)
    
    • VSS is at the core of the CCS project
  • slide #16: Value exchange formats
    • proposed protocol to group and exchange VSS data
• Framework:
  • slide #18: capture data in vehicles
    • ECUs speaking VSS2 (SOME/IP, DDS, HTTP/REST) or current bus translation
  • slide #19: cloud transfer & storage
    • Transfer/Storage with the W3C defined protocol Gen2,  "Gen2" is a vehicle API over HTTPS and WebSockets + data lake based possibly on object storage in a later stage
    • Buffering (high frequency, poor connectivity…) to take into account
  • slide #22: Neutral servers and data marketplaces opportunity included (in accordance to ISO20078) or simple 3rd party access

discussion on framework architecture

• Iyyaz Baber: What about a noSQL DB in the cloud?
• Kevin: We could. In the end, the proof-of-concept came from our experience with relational DB, there is no restriction
• Ulf: the server exposes an API. As long as it follows the API, the DB could be of different types.
• Gunnar: this would depend on the data (time series fitting into a relational DB ?).
• Teddy Zhai: When you say: “Cloud is Client, and in-vehicle is Data Server”, do you mean in a logical view or technological view? It means, for example, Data Server needs to open ports and listen on them.
• Ulf: it's both, the data servers needs to open ports and listen, and response to requests (standard client-server model)
• Gunnar: it can vary from this current proof-of-concept architecture to a production-ready solution. Typically there could be an SSL tunnel set up by OEMs
• Teddy: This is a major architecture decision in our view. It would be great if GENIVI can provide a threat model for it.
• Gunnar: I think in the later stages of proof-of-concept development, it is worthwhile to address these questions about how to set up private networks between some parts (e.g. OEM to car). If we end up using SSL/TLS then the GENIVI Security team has previously published a best practice document for SSL/TLS which avoids a lot of security pitfalls.
• François Fischer: data model - you can add SAREF/Autopilot
• Philippe: we had a look at SAREF proposal in September 2019 (SAREF Automotive - https://www.w3.org/2019/09/trans-data-ws/SAREF.pdf) and estimated that it was more on the long term (5+ years) goals, it might be worth rechecking the status of SAREF work

• Francois: I coordinated a project about IoT and automated driving, i.e. AUTOPILOT and we pushed data models to SENSORIS and SAREF, see https://autopilot-project.eu/

• Gunnar: there are datasets included in the current VSS work, we expec to use an Electric Vehicle (EV) use case and data set for the proof-of-concept demo implementation
• Gunnar:  our objectives are to get fast results, identify technologies and components that need to be standardized

Demo #1 - OEM cloud

• Ulf: shows a Cloud and Connected services demo involving 3 components:
  • data server (W3C Gen2),
  • data base (Open Vehicle Dataset Server a.k.a. OVDS)
  • CCS vehicle client
• Data server can be accessed through multiple protocols (HTTP, WebSockets) with VSS(2) data (but open to use other compatible domains - with a service manager)
• Data base is a SQL database with a VSS-to-DB adapter
• CCS client sits in between and creates a list of all VSS leaf nodes and issues read/write requests to the Gen2/OVDS servers

Demo #2 - Vehicle data generation

• Stefan Vysocki (from the GENIVI AASIG Vehicle Data / VHAL project) shows a demo of a vehicle data feeder using a vehicle simulator and a GraphQL server
  
  • simulator used in the demo is OpenDs, a frame example is given (could be VSS too)
  • the demonstration iincludes the simulator interface and a GraphQL server to retrieve values from the simulator
• Kevin Valdek: Could we use a fleet instead  ?
• Stefan: Yes, by configuring multiple ports
• Stephen Lawrence: Could you containerize the simulator and automate tests ?
• Stefan: It is partially containerized, no issues.

Discussion on technology options

• Gunnar introduces the topic
• How to generate data
  • Usefulness of an easy to run driving simulator
    • it would be nice to use the simulator as a driving game and generate data
    • Iyyaz: I go for it !
    • Gunnar: which operating system would you use ?
    • Iyyaz: ubuntu, linux or windows 10
    • Christian: having vehicle data would be useful to test our APIs !
    • Stephen Lawrence points out that CAN can-utils has the basic cansend to send can msgs, look at https://github.com/linux-can/can-utils, and https://manpages.debian.org/stretch-backports/can-utils/cansend.1.en.html
    • How important is the sanity of the data ? Could we do statistical analysis on random data? What about randomly generating data ?
    • Gunnar: Is that sending a random generated data you mean?
    • Stephen: can-utils also has cangen for random data
    • Stephen: it seems also that candevstudio may  have some generation capability, look at CANdevStudio repository
• Alternative technologies
  • Why not using MQTT between the vehicle and the cloud (rather than other than W3C Gen 2) ? with MQTT there is a need to define the payloads
  • using maybe a NoSQL data base
  • Abhijeet: mentions the use of a replica of the car like AWS Car Shadow and like the Ditto digital twin - Device as a service: Ditto project from Eclipse https://www.eclipse.org/ditto/
• How to do high-volume tests ?
• Evaluating the performances ?
• What about security ?

Demo #3 - GraphQL client on top of a VSS schema

Kevin shows a demo

Discussion

• How to have data anonymization ?
• there is consent here
• What about the identification?
• Here we could have many types of identifiers, such as what a brand allows you to access (a certain fleet for instance)
• What happens when the user removes consent (need to do something on the 3rd party side) ?
• These are great use cases, we should look into them.
• How do we categorize what is to be anonymized and what is not ?
• Since privacy is partially region-based, it might be better to have configuration outside of the VSS