CCS Reference Architecture - Work Breakdown Structure

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

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

• Custom code

Keith

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.

• Implement CAN + VSS translation support (e.g. reuse from Bosch code project)

•   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

•  Implement CAN + VSS translation support (e.g. reuse from Bosch code project)

• Then (future) run full vehicle driving simulator

→  continue driving-simulator track
and "playback" simulator in parallel.

not assigned

In-vehicle

Data Package

• Collecting VSS2 data into snapshots and bundles according to Data serialization / value formats

• Presenting data packages to the Data server

• Possibly closely related to the State storage schema

Start with results of Apache NiFi track
to fulfil this need. (no resource / no concrete plan for NiFi at the moment)
 No recent progress

 VISS specification defines how to fetch "historical" collected data.

 VISS server W3C_VehicleSignalInterfaceImpl implementation will record data (if an interface is triggered from the vehicle, use case is "going out of mobile service area").  Also, the messages for fetching data (according to VISS) is implemented. 

Gunnar → Ulf

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)

Use server directory from W3C_VehicleSignalInterfaceImpl

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

OEM Cloud

Vehicle client

• W3C Gen2 protocol (VISS Websocket Pub/Sub)

• Options:
  
  

  • Ulf wrote the client using Go-lang, stored in MEAE-GOT/W3C.

  • Sanjeev involved in writing a client using Javascript.

  • Curl script

  • Custom code + HTTP library (e.g. written in python) custom code + libcurl binding

  • No clear answer.  Depends on use-case.  What is the rate of data for example?

• This program shall also store the data into the data lake program (or directly into the database used as data lake)

Written in Go, some similar code as in W3C Gen 2 reference server

  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 can be set to either to HTTP Get or WebSocket subscription feature.

Ulf

OEM Cloud

VSS2 database

• Selection of libraries and database

  • Define database schema → Start with Ulf's proposal for DB schema

Postgres was discussed.
Use SQLite first.

Currently the translation path to UUID.   Translation is 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.

→ now using Path as ID.  This also simplifies supporting multiple VSS versions (where paths might differ) at the same time.

• Custom control code (Python or C++) → implemented in Go.

• + Sqlite binding, OK for PoC, or other database such as postgresql.

  • Need to define database schema first → proposal is here

 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?  → Agreed, but not as urgent.

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

OEM Cloud

Identity management

• Implementation of end-user login and authentication using OpenID
  
  

  • Lots of candidates.  Responsible implementer should propose a good alternative.

TODO
Later. (Programming language / technology preference could be influenced by the programmer)

--

OEM Cloud

Access management

• Implementation of authorization between end-user and 3rd party application or Neutral Server using OAuth2

• Iyyaz points to the following code

  • https://www.ory.sh/hydra/ taken from https://oauth.net/code/

TODO

Later.  (Programming language / technology preference could be influenced by the programmer)

--

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

GraphQL → Apache Apollo?

•  Has one schema.

•  Proposal (PR in vss-tools) for GraphQL schema generator now exists.

•  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 TODO:  Implement the connection between GraphQL and OVDS database.

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.

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.

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.

The API would be quite transparent if VSS is exposed directly, but the Neutral Server API might expose different functions also.

But enriched functions / anonymized aggregated data might be provided by Neutral Server.

Kevin

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

  New sample app
Connecting directly to OEM cloud for now, via GraphQL.

For connecting to Neutral server instead:

• Example/standard API work needed. The example apps are using High Mobility's API.  → See above

 See above, it is first required to define Neutral Server API.

Kevin