You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 23
Next »
Implementation roadmap
- milestone 1 - Spring GENIVI Virtual Tech Summit (12-14 May)
- milestone 2 - internal milestone (early Q3 - 17 July)
- milestone 3 - Fall All Member Meeting, Leipzig, Germany (last week of October)
- milestone 4 - CES 2021 (January 2021)
Communication framework architecture
This page lists the different components and tasks to be completed for the architecture discussed on the Vehicle data exchange protocols page. The table references to the following diagram, with components that are considered in scope for the PoC highlighted with green color.
Components
Vehicle
Definitions:
StateStorage and VSSFeeder is expected to be combined into one component in the implementation.
SignalStoreIF : Done by reading/writing sqlite database transactions, and using the notification feature to notify components that update occurred.
StateStorage: Essentially implemented by sqlite instance
SignalFeedIF: This is an internal implementation detail now since StateStorage/VSSFeeder is essentially one program
OEM Cloud
ValueStoreIF: ?
ValueQueryIF: ?
Interface details
(OEM Cloud) GraphQLDatabaseIF: (Interface between VSS2-Database ↔ Resource Mgmt (GraphQL server)
The interface is expected to be accessing the database itself. In order to give the GraphQL server full freedom to query data intelligently, it should connect directly to the SQL database.
Description of work
Apache License is more preferred by participants.
# | Component | Work | Software Components / Implementation details (PoC) | Software Components / Implementation for Production Systems (WIP, future) | Owner |
---|
1 | In-vehicle State storage (laptop simulator) | - Custom code + in-memory database (+ persistence) + connection to feeder
- Either locally cached during uptime of system or
- Stored and indexed in a database to allow access to historical data
- Selection of database
- Implementation of database schema
CCS-106
-
Getting issue details...
STATUS
| - Custom control code (Python or C++)
- + sqlite binding, OK for PoC
→ state_storage implementation by Ulf
CCS-107
-
Getting issue details...
STATUS
|
CCS-108
-
Getting issue details...
STATUS
| Keith
CCS-109
-
Getting issue details...
STATUS
→ Ulf
|
2 | In-vehicle VSS2 translation (a.k.a. VSS feeder) (laptop simulator) | - Implementation of SOME/IP client?
- or simple simulator
- or Vehicle Driving Simulator (LG? OpenDS? or GENIVI GitHub version?)
- = set up simulator, make it drive around track, get list of available signals, write code to convert signals to VSS...
- Signals are fed over DDS to AutoWare or Apollo autonomous driving stacks.
- Sim needs a high-end graphics machine
- Look if VSI or VSD should play a part
CCS-110
-
Getting issue details...
STATUS
| - Custom code, feeding simple simulated data
then (future) run full vehicle driving simulator
CCS-111
-
Getting issue details...
STATUS
|
| Keith
CCS-112
-
Getting issue details...
STATUS
|
3 | In-vehicle Data Package | - Collecting VSS2 data into snapshots and bundles according to Value measurement formats
- Presenting data packages to the Data server
- Possibly closely related to the State storage schema
CCS-113
-
Getting issue details...
STATUS
| Protocol defined within the CCS project
Start with results of Apache NiFi track to fulfil this need.
CCS-114
-
Getting issue details...
STATUS
| Future development. No support currently to transfer a Data Package in W3C Gen2
CCS-115
-
Getting issue details...
STATUS
| Gunnar |
4 | In-vehicle Data server (laptop simulator) | - Data server implementation for W3C Gen2
- Reference implementation exists in GitHub MEAE-GOT
- Ulf can work together with someone how to connect to an existing API of "state storage"
- (also talk to Kuksa project - VISS+REST server)
CCS-116
-
Getting issue details...
STATUS
| Use server directory from W3C_VehicleSignalInterfaceImpl
CCS-117
-
Getting issue details...
STATUS
|
| Ulf
CCS-154
-
Getting issue details...
STATUS
|
5 | OEM Cloud Vehicle client | - W3C Gen2 protocol (VISS Websocket Pub/Sub)
- Options:
- Investigate Sanjeev's work for reusable client
- Curl script
- Custom code + HTTP library (e.g. written in python) custom code + libcurl binding
- Client directory from MEAE-GOT/W3C ?
- No clear answer. Depends on use-case. What is the rate of data for example?
- Sanjeev: It would make sense to write also client in Go.
- This program shall also store the data into the data lake program (or directly into the database used as data lake)
CCS-118
-
Getting issue details...
STATUS
| Written in Go, some similar code as in W3C Gen 2 reference server
CCS-119
-
Getting issue details...
STATUS
Demo includes this function already.. In ccs-client repo. Reads data from data server in vehicle and writes it into the database.
|
CCS-120
-
Getting issue details...
STATUS
| Ulf |
6 | OEM Cloud VSS2 database | - Selection of libraries and database
- Define database schema → Start with Ulf's proposal for DB schema
CCS-121
-
Getting issue details...
STATUS
Gunnar: I have some experience setting up Postgres, so this is a reasonable option. Ulf: A Go library to support Postgres exists, so this is only a small rewrite. | - Custom control code (Python or C++)
- + Sqlite binding, OK for PoC, or other database such as postgresql.
CCS-122
-
Getting issue details...
STATUS
Implemented in In ccs-client repo. | In production more likely to be an object store database instead of a RDBS. Sanjeev looking at Apache ecosystem and Hortonworks/Cloudera platform capabilities.
CCS-124
-
Getting issue details...
STATUS
| Ulf
CCS-125
-
Getting issue details...
STATUS
|
7 | OEM Cloud Identity management | - Implementation of end-user login and authentication using OpenID
- Lots of candidates. Responsible implementer should propose a good alternative.
CCS-126
-
Getting issue details...
STATUS
| Later. programming language preference could be influenced by the programmer
|
| -- |
8 | OEM Cloud Access management | - Implementation of authorization between end-user and 3rd party application or Neutral Server using OAuth2
CCS-127
-
Getting issue details...
STATUS
| Later. programming language preference could be influenced by the programmer
|
| -- |
9 | OEM Cloud Resource Management = Data server API | - Implementation of basic API management
- Resource Mgmt is the ExVe naming.
- Implementation of a GraphQL API using the VSS2 schema
- Interface to the client, is of course defined by GraphQL+schema.
- Interface to database (GraphQLDatabaseIF) is described above
CCS-128
-
Getting issue details...
STATUS
| GraphQL → Apache Apollo?
CCS-129
-
Getting issue details...
STATUS
Located in vss-graphql repo - Has one schema.
- Does not have tool to regenerate schema.
- Has Apollo server in docker
|
| (Alexander Domin)
CCS-130
-
Getting issue details...
STATUS
|
10 | Neutral Server Data Marketplace | - Separate instance that consumes the OEM Cloud OAuth2 and GraphQL APIs
- We could implement a very simplistic neutral server using the published API of High Mobility, but an open implementation.
- Security, consent and other complicates things. Leave those details out.
CCS-131
-
Getting issue details...
STATUS
|
CCS-132
-
Getting issue details...
STATUS
Repo link? In vss-graphql-client-swift repository Has programming framework/example (in SWIFT) to access data via graphql. - This could show a way for 3rd party applications to access the OEM/GraphQL interface directly but possibly a more limited REST-API is more realistic for 3rd part app access
TODO: Expose a neutral-server API to third party applications.
|
| Kevin |
11 | 3rd Party Application | - Example applications exist on High Mobility's GitHub
- One instance that consumes the Neutral Server/Data Marketplace APIs
- Use an example application from HM
- For example an app that just shows the data (written in Node.js)
- One instance that consumes the OEM Cloud OAuth2 and GraphQL APIs
- Modify the application to use the OEM API directly
CCS-133
-
Getting issue details...
STATUS
|
CCS-134
-
Getting issue details...
STATUS
Example/standard API work needed The example apps are using High Mobility's API. Need discussion/definition of what the open API should be. The API would be quite transparent if VSS is exposed directly, but the Neutral Server API might expose different functions also. The apps could however be used with modification. |
| Kevin |