You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Current »

EA Block Diagram foe the External Data Server Proof-of-Concept


1

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

OwnerComment
2

VSS feeder component

AASIG-37 - Getting issue details... STATUS

Stefan WysockiSee vss-feeder repository
3
  • todo create a layer concept for the Franca to VSS leaf mapping (model transformation)
  • AASIG-39 - Getting issue details... STATUS


4
  • todo design and implement franca service (SomeIP)
  • AASIG-40 - Getting issue details... STATUS


5
  • todo implement feeder as PoC


6
  • todo check signal to service translation in Adaptive Autosar
  • in-progress in CCS project: CCS-88 - Getting issue details... STATUS


7
  • todo create PoC Someip simulation component to playback agreed use cases
  • AASIG-42 - Getting issue details... STATUS
    • 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


8
  • Select and implement feeder input API → how feeder writes data into the "shared database"
  • AASIG-43 - Getting issue details... STATUS
  • 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. 


9

VSS data server component

AASIG-44 - Getting issue details... STATUS



10
  • Implement the connection between the access protocol (GraphQL) and the fetching/writing of data into the database.
  • AASIG-45 - Getting issue details... STATUS done duplicate of AASIG-48 - Getting issue details... STATUS


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


12

Define GraphQL schema - what does it look like?

AASIG-47 - Getting issue details... STATUS

Alex.See vss-graphql repository
13
  • todo resolve requested data for the APP from the VSS data structure
  • AASIG-48 - Getting issue details... STATUS
  • ==> This means:  Implement the resolvers function in GraphQL
    Depends on choosing the database implementation first.
  • ==> Adjust resolver to fetch the data from SQLite.


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


15
  • todo handle the subscription for APPs
  • AASIG-50 - Getting issue details... STATUS
  • => Implement Subscriptions (according to GraphQL)


16


17

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

AASIG-53 - Getting issue details... STATUS

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


18
  • todo finalize permissions layer concept (independent work item)
  • AASIG-38 - Getting issue details... STATUS
    • description TBD
    • definition of done TBD


19

Framework Layer / Authentication Service

AASIG-54 - Getting issue details... STATUS

Stefan Wysocki
(TietoEVRY)

Will update the description and DoD for this component
20
  • todo request APP permissions from package manager
  • AASIG-55 - Getting issue details... STATUS
    • description TBD
    • definition of done TBD

Stefan Wysocki
(TietoEVRY)


21
  • todo generate access token for the APP including the APP permissions
  • AASIG-56 - Getting issue details... STATUS

Stefan Wysocki
(TietoEVRY)

Implementation of the module deployed on the platform. Buildable by Android buildystem (Android.bp)
22

Application Layer

AASIG-57 - Getting issue details... STATUS

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

^^ Decision to implement number 2 first.

Alexander: There are helpers to access GraphQL from an Android project.  You add a plugin to your gradle project to include it.  Some classes will be generated based on the GraphQL schema we specify.  https://github.com/apollographql/apollo-android

Stefan: The app skeleton is in the aasig_dev_platform (Only on Stefan's fork still?)




23

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

AASIG-58 - Getting issue details... STATUS

Tieto?
24
  • Implement the APP permissions based on permissions defined/proposed in VSS layers
  • AASIG-59 - Getting issue details... STATUS  
    • description TBD
    • definition of done TBD


25
  • Implement authentication as required by the concept including access token request, etc.
  • AASIG-60 - Getting issue details... STATUS

Stefan Wysocki
(TietoEVRY)

Will be provided as a part of "Authentication Service" to showcase the exposed API
26
  • APP implement request/response serialization for the client
  • AASIG-61 - Getting issue details... STATUS
  • Gunnar: this is probably defined by the communication protocol (defined by GraphQL)


27
  • todo agree on PoC use cases for the implementation
  • AASIG-41 - Getting issue details... STATUS


28
  • implement the selected use cases
  • AASIG-62 - Getting issue details... STATUS



Support / Infrastructure

  1. Testing
    1. Stephen Lawrence I can contribute to the effort to integrate the PoC into the Genivi LAVA Automated testing if the group decides to use it.
    2. AASIG-67 - Getting issue details... STATUS
  2. Integration
    1. Stephen Lawrence : I would be happy to provide best effort support for integration on R-Car h/w where needed.


Interfaces

VSSDatabase :  Decision to first use SQLite as the intermediate storage. 
(Note. Reuse potential with CCS project)

  • SQLite is also a kind of inter-process communication between VSSFeeder and Apollo GraphQL server.
  • VSSFeeder needs to be adjusted to fill data into SQLite ( AASIG-37 - Getting issue details... STATUS ) and Apollo needs to be adjusted to get data from SQLite.  (That is  AASIG-48 - Getting issue details... STATUS )




  • No labels