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.
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: ?
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.
Apache License is more preferred by participants.
# | Component | Plan / Activities | Status of chosen software components (Implementation details of PoC) | Alt. SW components / Implementation for Production Systems (WIP, future) | Owner |
---|---|---|---|---|---|
1 | In-vehicle State storage (laptop simulator) |
|
→ Implemented by a shared sqlite database file. The "API" is simply interacting with the database using SQL statements and/or sqlite bindings. Note: statestorage executable in a one-shot thing that sets up the database. The gen2-server accesses the actual database directly using sqlite binding. |
|
→ Ulf |
2 | In-vehicle VSS2 translation (a.k.a. VSS feeder) |
|
Additional options:
→ continue driving-simulator track | not assigned | |
3 | In-vehicle Data Package |
| Protocol defined within the CCS project. Start with results of Apache NiFi track | Future development. No support currently to transfer a Data Package in W3C Gen2 | Gunnar |
4 | In-vehicle Data server |
| Use server directory from W3C_VehicleSignalInterfaceImpl Gen2 implementation now uses ovds.db file. | Ulf | |
5 | OEM Cloud Vehicle client |
| Written in Go, some similar code as in W3C Gen 2 reference server Demo includes this function already.. In ccs-client repo. Vehicle client current does get-requests on a timer (polling) but could in the future also exercize the subscription feature in the protocol. | Ulf | |
6 | OEM Cloud VSS2 database |
Postgres was discussed. Currently the translation path to UUID is currently in a separate database, compared to the signal database. A future possibility is two tables in a single database, making it possible to use SQL JOIN statements. |
Implemented in In ccs-client repo. Should we split up the software into more logical repositories? | In production more likely to be an object store database instead of a RDBS. Sanjeev looking at Apache ecosystem and Hortonworks/Cloudera platform capabilities. | Ulf |
7 | OEM Cloud Identity management |
| TODO | -- | |
8 | OEM Cloud Access management |
| TODO Later. programming language preference could be influenced by the programmer | -- | |
9 | OEM Cloud Resource Management |
| GraphQL → Apache Apollo?
| (Alexander Domin) JIRA TODO: Implement the connection between GraphQL and OVDS database. | |
10 | Neutral Server Data Marketplace |
| In vss-graphql-client-swift repository Has programming framework/example (in SWIFT) to access data via graphql.
TODO: Expose a neutral-server API to third party applications. Nothing in particular to develop → It would just be a proxy (for the GraphQL and/or REST) – same technologies as our current OEM connection would be used by the Neutral Server. | Kevin | |
11 | 3rd Party Application |
| New sample app For connecting to Neutral server instead: Need discussion/definition of what the open API should be. The API would be quite transparent if VSS is exposed directly, But enriched functions / anonymized aggregated data might be provided by Neutral Server. → See above | Kevin |