VSS feeder component

• todo create a layer concept for the Franca to VSS leaf mapping (model transformation)
• 

• todo design and implement franca service (SomeIP)
• 

• todo check signal to service translation in Adaptive Autosar
• in-progress in CCS project:

• todo create PoC Someip simulation component to playback agreed use cases
• 
  
  • note: we could consider using an Adaptive Autosar node like what we did for the FARACON demo
  • note: VSS data base could be merged into the VSS feeder

• Select and implement feeder input API → how feeder writes data into the "shared database"
• 
• Either it is writing directly into the database (shared with the VSS data server component) or writing into an API provided by the VSS data server. 

VSS data server component

• Implement the connection between the access protocol (GraphQL) and the fetching/writing of data into the database.
• done duplicate of

Define GraphQL schema - what does it look like?

• todo resolve requested data for the APP from the VSS data structure
• 
• ==> This means:  Implement the resolvers function in GraphQL
  Depends on choosing the database implementation first.

• todo change/write data values for requested data leaves
• 
  
  • ==> Same as implementation of 14, but for writing.
  • This means:  Implement Mutation functions in GraphQL

• todo handle the subscription for APPs
• 
• => Implement Subscriptions (according to GraphQL)

• APP implement authentication to access the data server (eg JWT), e.g. json Web token
• 
  
  • relates to Vehicle Signal Authentication
  • description TBD
  • definition of done TBD
  • look at https://github.com/w3c/automotive/issues/322
• todo implement the permissions handling in the data server
• 
  
  • look at on-going discussion in W3C on the dynamic registry https://www.w3.org/2019/11/W3C_Gen2_dynamic_registry.pdf (Geotab proposal)

Define the "signal groups" that make up each permission and give each permission a name.

• Example permission group created by Alexander (in .md file), similar to the layers discussion.  Alexander found it easiest to do Signal→Group mapping
  (this fits the VSS layer principle exactly.) but also to have the opposite view (Group→ Signals) generated by tooling (for human readability)
• vss.permission.xxx (as proposed in VSS layers) was a nice convention, but let's confirm that we are aligned with Google standards on permission names.

• todo finalize permissions layer concept (independent work item)
• 
  
  • description TBD
  • definition of done TBD

Framework Layer / Authentication Service

Stefan Wysocki
(TietoEVRY)

• todo request APP permissions from package manager
• 
  
  • description TBD
  • definition of done TBD

Stefan Wysocki
(TietoEVRY)

• todo generate access token for the APP including the APP permissions
• 

Stefan Wysocki
(TietoEVRY)

Application Layer

1. Implement EV charging status App in Android, with a graphical UI
2. Implement Position/speed/make/model/ any other info, as received from driving simulator (could be simple UI, maybe text).

TODO:  Define what signals we can get from simulator, and try the simulator (Tieto)

• Implement authentication as required by the concept including access token request, etc.
• 

Stefan Wysocki
(TietoEVRY)

• APP implement request/response serialization for the client
• 
• Gunnar: this is probably defined by the communication protocol (defined by GraphQL)

• todo agree on PoC use cases for the implementation
• 

• implement the selected use cases
•