WORK-IN-PROGRESS
15.00 | # 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. 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* | ||
Q: Does VSS server provide Authorization to vehicle data access, similar to standard Android permission model? 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?
| ||
Stefan Wysocki explains and then shows the demo:
Explains relation between OpenDS and VSS feeder - it's our input. Later on we are translating data from OpenDS to VSS standard (unit conversion e. g.). Apollo GraphQL is responsible for resolving queries from apps. It asks from dbs 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. Structurization is advantage over standard Android solution. Queries can contain requests for many values from different branches. Visible that values are read in runtime from simlutor (on playground). You can subscribe for changes. Values can be monitored without polling - advantage over Android model. | ||
Q: are you working with low level APIs such as VSOMEIP in order to get the data ? Q: I think franca is kind of Model tool that we can use for translate those interfaces | ||
## Topics discussion | ||
### Google Vehicle Properties Implementation based on GraphQL Service. | ||
Alexanders shows slide 6 to extend the view of current state.
Q: Whether 3rd party applications will be allowed to access Vehicle data from VSS? Work breakdown structure:
| ||
Q: 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, and covered as "Internal Data Server Architecture" concept | ||
### Permission groups specification. | ||
Side questions 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) | ||
### 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 # Wrap up Reminder about weekly calls |