Automotive Working Group Teleconference

26 Nov 2019


Harjot, Ulf, Glenn, Arman, Benjamin, Adnan, Isaac_Aguido, Joakim, Ted, Gunnar



Project description and goals


Ted gives high level intro

Glenn: use cases that benefit individuals can span multiple vehicle manufacturers
... road use indicator is one such example

Ted gives a high level overview of what the project's goals are, collect and represent some signals in VSSo to support an interesting and impactful set of use cases

Joakim: we want to be able to share anonymized data in collaboration with other using this common data model
... it is doable. it is a process...

Glenn: in the last couple weeks we have been advised on addition requirements with the proposed protocol and going through a vetting process
... we may be able to provide it for consideration towards an industry best practice and preparing it to share with this group
... we can bring a legal representative for us give a presentation

Joakim: that would be helpful

Review use cases and available signals


<gatkinso> re: sharing data see CISCO TRUST LINK https://www.cisco.com/c/en/us/about/trust-center.html

Ted: you'll see various succinct use cases and corresponding signals needed to support them
...there may be some missing signals so do please look over and add additional you think would be useful

Harjot: to what detail were you looking for in the use cases?

Ted: we can develop the selected ones in more detail including what sort of benefits the questions may have in the real world

Harjot: some of these use cases require bidirectional communication. also a challenge trying to get harmogenous data across different sets

Gunnar: can you elaborate on bidirectional communication?

Harjot: mostly around resetting thing in IVI

Gunnar: my understanding is you are looking to collect data and be able to run applications against it and demonstrate queries

Glenn: relates to GENIVI meeting recently, in addition to collect data there are some use cases for sending signals back to the vehicle
... suggestion was to bring it to SAE and there is some coverage there

Gunnar: the use cases where you have to affect the car itself are fewer than the reading and analysis
... you can define actual remote APIs and keep it out of the data exchange category

Ted: for now we should keep the project scope to simple reads. should we have time later and can support some mock/fake vehicles to write to we can look into more

... I am rethinking trying to narrow down our desireable use cases and see what use cases we can support with the signals we can get

Glenn: I think Ulf has a list of signals for specific use cases
... we have started looking at how to bring some signals from our format to VSS
... a few of the signals are found in several as Ted illustrated and may help the use case selection
... certainly will be good to get something with actual GPS

Joakim: there are various recipes we should work on for uploading format to be supported

Gunnar: maybe we should start with the use cases

Adnan: what would be useful in the use cases is details on frequency of requests, number of vehicles

Joakim: that is interesting and yes having that detail would help

Glenn, Gunnar and Ted discuss the sensitivity of GPS even if we strip time and all identifying information

Ted: could do some sort of offsetting algorithm, undisclosed minutes,degrees long/lat so we can look at eg hard braking in a made up geofenced area

Ted suggest updates to wiki on granularity, starting inquiries into what signals you could potentially get

Joakim and Adnan to start making internal inquiries, easier if more specific

Graph engine selection


Ted: kind of early to be discussing the datastore engine given we are still in process side but why not
[summarizes email thread with Benjamin]

Benjamin: you basically summarized what I described, happy to help toward an rdf+sparql

Joakim: what graph db would you suggest?

Benjamin: there are some stacks around W3C specs, rdfs, shex, sparql - I was thinking of hypergraphql


Benjamin: you can have great specifity
... neo4j meant to be industry compatible

Joakim: I am more familiar with sparql et al too, how do you even import the db into neo4j with the ontology

Benjamin: there are some ways and proprietery internally
... the tools are there
... agree with Ted to try both approaches
... depends on the data requirements we want to express

Next steps

Glenn: we would be prepared in two weeks to have a draft policy document on data collection

Updates to wiki - signal granularity

Sparql et al Recipe in mail thread or on server from Benjamin for Ted to follow

Joakim and Adnan to make initial inquiries

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/11/26 20:39:03 $