Page History

...

• 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
  server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key CCS-96

  • 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

• /TODO/ Kevin V to document which format to put for which version of the proof-of-concept in the wiki

...

• Gunnar: shows the code repo structure in github, CCS-arch-demo repository
  • repo names correspond to the actual implementation used
  • please look at the various readme files

• 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

...