| # | 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) | - 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
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-106 |
|---|
|
| Custom control code (Python or C++)+ sqlite binding, OK for PoC
→  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.
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-107 |
|---|
|
| | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-108 |
|---|
|
| Keith
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-109 |
|---|
|
→ 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
- New: live_simulator which is feeding a real-time playback of existing timestamped data.
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-110 |
|---|
|
| - live-simulator implemented by Ulf feeds data taken from an existing "ovds" database and feeds it into statestorage.
- Example ovds database to feed live simulator now exists.
Additional options: - Custom code, feeding simple simulated data
- Then (future) run full vehicle driving simulator
→ continue driving-simulator track
and "playback" simulator in parallel. | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-111 |
|---|
|
|
| not assigned | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-112 |
|---|
|
|
| 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
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-113 |
|---|
|
| Protocol defined within the CCS project. Start with results of Apache NiFi track
to fulfil this need.
 No recent progress
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-114 |
|---|
|
| Future development. No support currently to transfer a Data Package in W3C Gen2 | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-115 |
|---|
|
| 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)
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-116 |
|---|
|
| Use server directory from W3C_VehicleSignalInterfaceImpl | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-117 |
|---|
|
Gen2 implementation now uses ovds.db file.
On-demand requests are fetched from database.
Timed subscriptions are also supported, i.e. send updates at regular intervals.
 There is not yet implementation of a trigger to the gen 2 server from the database when a new value is written (SQLite supports trigger in theory). |
| Ulf | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-154 |
|---|
|
|
| 5 | OEM Cloud Vehicle client | - W3C Gen2 protocol (VISS Websocket Pub/Sub)
- Options:
- Sanjeev involved in writing the client using Go-lang.
- 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)
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-118 |
|---|
|
| Written in Go, some similar code as in W3C Gen 2 reference server | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-119 |
|---|
|
Demo includes this function already.. In ccs-client repo.
Client reads data from data server in vehicle via the VISSv2 protocol, and writes it into the OVDS database. Vehicle client current does get-requests on a timer (polling) but could in the future also exercize the subscription feature in the protocol.
| | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-120 |
|---|
|
| Ulf |
| 6 | OEM Cloud VSS2 database | - Selection of libraries and database
- Define database schema → Start with Ulf's proposal for DB schema
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-121 |
|---|
|
Postgres was discussed.
Use SQLite first. 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.
| - Custom control code (Python or C++) → implemented in Go.
- + Sqlite binding, OK for PoC, or other database such as postgresql.
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-122 |
|---|
|
Implemented in In ccs-client repo.
This is the OVDS server.
It exposes a REST protocol that is used by the client, which may be easier since it is a single operation and not having to look into both databases. (See JOIN idea on the left for alternative).
REST protocol can also deliver full time series.  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. | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-124 |
|---|
|
| Ulf | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-125 |
|---|
|
|
| 7 | OEM Cloud Identity management | - Implementation of end-user login and authentication using OpenID
- Lots of candidates. Responsible implementer should propose a good alternative.
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-126 |
|---|
|
| TODO
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
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-127 |
|---|
|
| TODO 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
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-128 |
|---|
|
| GraphQL → Apache Apollo? | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-129 |
|---|
|
Located in vss-graphql repo- Has one schema.
- Does not have tool to regenerate schema =>
 Manually done for now by Kevin/High Mobility. - Has Apollo server in docker
TODO Needs to implement the connection from GraphQL (Apollo) to database.
It could use the REST protocol of the OVDS server,
or directly SQLite database. - ^^ Important to fix!!! ^^
|
| (Alexander Domin)
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-130 |
|---|
|
JIRA TODO: Implement the connection between GraphQL and OVDS database.
|
| 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.
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-131 |
|---|
|
| | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-132 |
|---|
|
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 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 | - 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
| Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-133 |
|---|
|
| | Jira |
|---|
| server | JIRA |
|---|
| serverId | 121ddff2-c571-320f-9e4d-d5b9371533bd |
|---|
| key | CCS-134 |
|---|
|
New sample app
Connecting directly to OEM cloud for now, via GraphQL.
For connecting to Neutral server instead: Example/standajrd standard API work needed. The example apps are using High Mobility's API. → See above 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.
But enriched functions / anonymized aggregated data might be provided by Neutral Server. → See above |
| Kevin |
