External Data Server Proof-Of-Concept - Work Breakdown Structure

Work Breakdown Structure for the External Data Server Proof-Of-Concept

• The TODOs listed below were added to the EA block-diagram, look at ExternalDataServerPoC-WBS.pptx
• After addition of a description of work and definition of done to each TODO, these TODOs will be entered into Jira.

VSS feeder component

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

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

• todo design and implement franca service (SomeIP)

• todo implement feeder as PoC

• todo check signal to service translation in Adaptive Autosar

• todo agree on PoC use cases for the implementation

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

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

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

Framework Layer / Authentication Service

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

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

Application Layer

1. EV charging status App
2. Position/speed/make/model/ any other info, as received from driving simulator
   1. todo: Define what signals we can get from simulator, and try the simulator (Tieto)

• Implement the APP permissions based on permissions defined/proposed in VSS layers
  • description TBD
  • definition of done TBD

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

• todo APP implement request/response serialization for the client

• todo implement the selected use cases