You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
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.
# | Component | Work | Software Components / Implementation details (PoC) | (WIP, future) Software Components / Implementation (Production) | Owner |
---|
| 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
| | Gerald investigating (KUKSA) |
| In-vehicle VSS2 translation (a.k.a. VSS feeder) (laptop simulator) | - Implementation of SOME/IP client?
- or Simulator
- Look if VSI or VSD should play a part
| - Custom code, feed simulated data
|
| Gerald investigating (KUKSA) |
| 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"
| Use server directory from W3C_VehicleSignalInterfaceImpl |
| Ulf |
| 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?
- This program shall also store the data into the data lake program (or directly into the database used as data lake)
| TBD |
|
|
| OEM Cloud VSS2 data lake | - Selection of libraries and database to handle data lake
- Can we get BMW help to define the database schema, and maybe also the implementation?
| - Custom control code (Python or C++)
- + Sqlite binding, OK for PoC, or other database such as postgresql.
|
|
|
| OEM Cloud Identity management | - Implementation of end-user login and authentication using OpenID
- Lots of candidates. Responsible implementer should propose a good alternative.
|
|
|
|
| OEM Cloud Access management | - Implementation of authorization between end-user and 3rd party application or Neutral Server using OAuth2
|
|
|
|
| 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
| GraphQL → Apache Apollo? |
|
|
| Neutral Server Data Marketplace | - Separate instance that consumes the OEM Cloud OAuth2 and GraphQL APIs
|
|
| Kevin |
| 3rd Party Application | - Separate instance that consumes the OEM Cloud OAuth2 and GraphQL APIs
- Separate instance that consumes the Neutral Server/Data Marketplace APIs
|
|
| Kevin |