<scribe> scribenick: ted

<scribe> Scribe: Ted

ISO TC204 ITS diagnostics data flow inquiry (from Ken)

ISO TC204 ITS diagnostics data flow review request

SU12: Vehicle Maintenance

Ted: while this is a plausible flow another maybe more likely than per service incident is owner provides consent once to regularly share data with service provider. not sure whether inquiries to vehicle for additional data points will be permitted from independent service centers

Ulf: do we have support in VSS for diagnostic data?
... we don't have much, is it sufficient?

MagnusF: is handling diagnostic routines in or out of scope?

Ted: to Ulf's planned to improve diagnostics in VSS, maybe via RPC for MagnusF's question?

MagnusF: they are highly specialized and would be manufacturer specific but to the extent we can generalize

Gunnar: I would start first as whether we can handle with a regular node and not have to create additional features
... it can be proprietary branch

MagnusF: reseting DTC required
... it is a very interactive setup, we should be able to decode DTC codes and DID data

Gunnar: this can fall into RPC service catalog

MagnusF: it would be a combination of both

Gunnar: agree, want to use VSS as far as possible

MagnusF: sometimes you want to cascade interactions as in this scenario

Gunnar: Franca in YAML style could achieve what you want

MagnusF: I think we have a path forward
... agree there will be other flows, legislation in US (right to repair) at least may require access for independent garages

Gunnar: it can considered an example

Ted: thanks all, I'll relay:
* potential for alternate flows in addition to one in diagram, unlikely to be single, common solution but that could be influenced by regulators
* diagnostics improvements pending in VSS data model pending in GENIVI after EV
* diagnostics are usually very vehicle specific, clearing codes and calling specific routines not simply querying signals
* we have proposed spec work on RPC from JLR and we will include diagnostics use cases for RPC function catalog work

Compression in Gen2

HTTP compression

HTTP1.0 has compression

Per message compression for Web Sockets, alt schemes

Ulf: we were discussing cost of data transmission and they see uncomperssed JSON as too expensive
... their use case was wanting to follow a car with high frequency lat/long and speed
... we should support some compression
... Ted mentioned existing solution in HTTP

MagnusF: I think it should be on the link layer instead of the protocol itself
... won't work for video data. solution is to do on-board processing/edge computing that pre-processes data and sends to backend server
... we manage to compress long/lat down to 1.8 bytes with 10m resolution
... lower volume/high quality is solution

Ulf: that is absolutely one solution, you're saying outside of Gen2
... that is one way of doing it and do not think it would hurt that much
... it exists in most libraries for HTTP

MagnusF: if we don't need to expand our specification extensively

MagnusG: what about Web Sockets? for REST is one thing

Ulf: it has support also
... deflate is also supported in WS, maybe not as ubiquitous and standard

MagnusG: negotiation on whether it is used will be part of the handshake (content negotiation)

Ulf: sounds like plausible and not dead

MagnusG: if it is in standard HTTP do we need to do anything?

Ted: @@sampling and curve algorithm - can find a Youtube video from Neil
... HTTP has long supported compression although not used as widely, offset/tradeoff of increased client and server cpu to save bandwidth
... we use it for some of our more populare DTD and other schemata, seldom updated (years) and many millions of requests/day (also do tarpitting and auto-blocking logic...)
... @@simple sentence wrt conneg and server may support

MagnusF: I think this needs to be optional. most devices in the car will be underpowered

Ted: Peter relayed they are using gzip in mqtt for vss data

Adnan: for third parties we are looking at ExtVeh and data points requested
... you can do a search on 'BMW data catalog'
... we are looking at graphql which is showing interesting results
... some are looking into mqtt

Ted: graphql more on cloud end?

Adnan: yes but aware it is being used/considered elsewhere

Gunnar: I can confirm
... I get pointed to different people for some questions :)

Adnan: we are transparent on what we are doing in GENIVI

Gunnar: mapping to mqtt seems an obvious choice

Adnan: from AutoSAR point of view some are looking at SomeIP...

Gunnar: we have done some initial analysis and would like to be part of that discussion
... we have an initial implementation of VSS in SomeIP

Adnan: SomeIP story is evolving

Gunnar: scope creep!
... CCS is very similar to ExtVeh
... filling in some details

De-identifying data

Ulf: this topic keeps coming up, PII should not be brought up to the cloud
... some static is easy like VIN to hash
... long/lat is harder. if you de-identify this data you have two options, you can modify the position from where it actually was and/or modify the temporal aspect
... if you do that you loose quite a bit of value and eliminate a number of possible use cases, eg analyzing traffic congestion
... wondering about another solution and discussed with some colleagues who see it as feasible
... instead of moving vehicle data up to common repository, we keep the data in identifiable, raw data at each OEM in VSS
... then you can make aggregate queries (eg graphql) and thereby de-identified
... the aggregated results represents multiple vehicles and not individual ones
... our gut feeling is it would be possible to do this
... de-identification only applied to the aggregated results
... this may be useful in our graph project and GENIVI CCS

Ted: offboard and protect PII, use it for calculations and then de-id
... various schemes on [more] safely storing encrypted data https://www.w3.org/2019/09/13-w3ctransport-minutes#item08

Ulf: yes, need to have access to the raw data in sandbox and before exposing de-identify PII

[adjourned]

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Sebastian/Sebastian_Schildt/
Present: Ted MagnusG Ulf Glenn Thomas_Stimm Adnan Gunnar MagnusF Sebastian_Schildt
Found ScribeNick: ted
Found Scribe: Ted
Inferring ScribeNick: ted

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)