JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
...
Gunnar: Alex (BMW) is still waiting for a colleague to review his example before publishing it
Kevin: shows the tool chain Gunnar and he proposed to go from VSS2 to graphql schema, look at the model transformation workflow attached to
Jira | ||||||
---|---|---|---|---|---|---|
|
grey boxes corresponds to the open source implementation of the neutral server components that High-Mobility will provide
Kevin: explains the workflow and also a possible alternate workflow from VSS2 to 3rd party client (i.e. w/o going through the neutral server)
Kevin: for the demonstrator we will focus on the EV charging datapoints in order to show attractive use cases
discussion on the data packages and distance w.r.t. the data structures used by CVIM and Sensoris
CCS data packages (look at the high-level architecture diagram here) should be generic enough so that they can be mapped to any specific project data structures
Ulf: this format does not fit very well with Gen2, IMHO this is not seen in the vehicle but Gen2 protocol transfer, but rather in in the OEM cloud
Gunnar: this The picture does not show it used for the transmission to the cloud but in the vehicle only. The format might be used in the car but not for the transmission to the cloud, the , or not... but I think it is OK to indicate the idea of this would be there (to support historical values). The format is not fixed yet, this format can be used inside the vehicle for storage purpose for instance, this still it needs to be refined further
Gunnar: the in-vehicle state storage does could use SQL but might also not need to use a SQL format in my opinionit (it is a simple key-value if not multiple time stamps are stored).
Kevin: I will document which format to put for which version of the proof-of-concept in the wiki
...
Philippe: jira will be structured according to a list of generic components corresponding to the HL diagram
Gunnar: explains how docker is usedcould be used to package each part (SW components) for development help, or maybe for production, e.g. CCS-arch-demo/tree/master/docker/sqlite repository
shows the OEM-database implementation using SQLite
shows the test files
will continue to package the components according to they become available
Gunnar: the next step is to get program the create table command for the datalake from Ulf
Ulf: I started implementing the datalake using SQLite
Ulf: I talked to Sanjeev and I will implement a framework around the datalake and expose an API that the client will use to interface with Gen2
Gunnar: what will be the type of API between the vehicle client and the datalake
Ulf: I am actually working on a server that both the client component and the resource management component can use for accessing the datalake, it it written in REST
Gunnar: I am wondering what we will get from having REST APIs between those componeentscomponents, I am wondering whether there could be something simpler
Ulf: IMHO this is simple enough
Gunnar: both Sanjeev and you are working in Go, aren't you ? If one part was done in a typical web language like node.js I could see how a REST interface might be easier to consume. But especially with the same language other communication methods likely exist.
discussion on how to make interfacing simpler
Ulf: we might reconsider this later
Gunnar: it seems to me as some extra work, but we will see it soon then if it is almost done now anyway.
Webinar & virtual summit workshop content: gathering of topics
...