Page History

...

Value measurement formats

Monday,  May 25 - Communication Framework

Second call only - US friendly time 16:00 CET

Agenda

• sync between CCS and AASIG VHAL projects
• GraphQL server implementation

Participants

• Gerald, Kevin, Gunnar, Philippe

• apologies: Ulf

Minutes

Vehicle data simulation

• Stefan W and Gunnar had a sync meeting on the vehicle data simulation earlier today, this simulation approach could be used jointly bu the CCS and AASIG projects

• Stefan's notes

  No Format

  Learning from Ulf input: VSS to DB Adapter is “flattening” the vss tree structure to be easly stored in the database. The code is available https://github.com/GENIVI/ccs-w3c-client For usecase: querying min, max, avg value of the property – not in scope for graphql queries for Data Server Historical values not needed that is why we do not need to have complex database, unlike CCS more relies on data storage. Topic to discuss for tomorrow?: Do we consider relying not only on cached/stored/updated values in database updated periodically by vss feeder or foresee the need of “on demand” requesting the fresh data. This 3 ways of accesses are not considered as vss leaves def, but might be specified using VSS Layers. Then VSS feeder/Data Server (discuss on the role) can act accordingly (use cached or request for fresh value). To reuse VSS Feeder across CCS and AASIG PoC demos agreed the following: Temporarily descope “on demand request of the fresh data from sensor/ecu): Use sqlite as database for storing vehicle properties, then all three parties could write/read from it in common way (w3cgen2 + Apollo grapqhl + vss-feeder). Flat the structure of VSS tree to a unique key in the database (like using a string containing full tree path to leaf as a key). Tasks to be added to the backlog: Rework current vss-feeder and Apollo grapqhl resolver to use sqllite to retrieve/store data @Ulf Bjorkengren<mailto:ulfbjorkengren@geotab.com> I guess similar task needs to be performed on w3cgen2 side as well

GraphQL generation

• Below comments are extracted from

  Jira
  server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key CCS-96

  updated by Kevin

  • Client with example queries have been created in Swift: https://github.com/highmobility/vss-graphql-client-swift. Based on this we should see if the VSS GraphQL schema should be modified to simplify 3rd party usage.

  • High-Mobility is now waiting for VSS pull request related to Electric Vehicle signals to be reviewed and merged. Then the GraphQL schema can be generated and used for the EV use-case 3rd party service.
• Gunnar : it is good to have anoter component to be added to the set of components

NiFi

• Sanjeev will look at other ways to transmit data from the cars to the OEM cloud, we have no idea whether it impacts the architecture we have yet

MQTT

• Gunnar: MQTT handles only the way you describe the topics and the subscription to those topics , but the payload content is not defined, it is not a major work to do in my opinion
• Gunnar: MQTT is popular, should on the list of TODOs for the future
• Gunnar: I will write a mapping doc from VSS to MQTT, please add this to the backlog

Monday,  May 18 - Client Implementation, Vehicle Data

...