W3C

Automotive Working Group Teleconference

20 Oct 2020

Agenda

Attendees

Present
Adnan, Gunnar, Glenn, Ted, Arman, Steven, Peter, Ulf, MagnusF
Regrets
MagnusG
Chair
Peter
Scribe
Ted

Contents


<scribe> scribenick: ted

<scribe> Scribe: Ted

Ulf on whats missing in VISS v2

Peter: Ulf wanted to give us his impression on what is missing in VISS v2

Ulf's slides

Ulf: we didn't get time to discuss last week so doing now instead
... Gen2 is quite complete functionality wise, needs some polishing and possibly mild rewrites of some chapters
... that said there are a few things I want to bring up
... I would like to see Gen2 have historic data, previously captured
... use case I could see is for when vehicle looses coverage/connectivity
... this can be done with our existing set of queries. you would use $history and provide a period of time desired
... using ISO8601 for time period
... if Gen2 instance doesn't support it sends the latest value
... this doesn't require activation within the car, client request recording of data
... vehicle should be able to detect it lost connection from client and can send data in the meantime, optimize for amount of data cached

Peter: what is being stored? latest subscription?

Ulf: no, vehicle would detect lost client connection and will retain data collection
... sampling frequency choice of the vehicle

Ted: Gen2 could recognize client didn't close properly and collect data based on existing subscriptions, persistent subscription
... wonder about vehicle having historic data collection desired

Ulf: we shouldn't speculate on what it might store

Ted: otherwise you have no guarantee the data you want will be something the Gen2 implementation chooses to collect historic for

Peter: does this handle legal permissions?

Ulf: if implementation doesn't support or request violates a policy, doesn't have to return the data
... this would be an optional feature

Gunnar: I see Ted's suggestion as independent
... if you are saying we will not write it is required to store historical signals

Ulf: implementation will decide whether to send current data or historic

Gunnar: if the persistent feature is implemented that can influence historic data availablility
... I am still in the camp that we should go further with data collection jobs
... if we have any record features, historic can be available. not fan of syntax but let's work on the idea

Ulf: I interpret this as some interest
... I'll start with an issue to further the discussion
... next idea is multiple data parts from different parts of the tree
... a client often doesn't want one data point but multiple scattered across the tree. we already have subtree capabilities
... if they are in different places you might want them closer for convenience. I would like to retrieve in one request
... we can do this by augmenting the path expression with a query

Adnan: if I understand correctly, you want to combine in a single request?

Ulf: yes

Adnan: it might be easier as payload of request instead of complex parameterized querystring in URI

Ulf: that would be more POST than GET
... this would be candidate for discussion as an issue

Ted: we can also look at existing query schemes such as xpath/xquery

Ulf: next is signal discovery, syntax with $spec=0 being undefined levels
... instead of using query component of URL's query syntax (RFC 3986), we may want to use fragment syntax
... use #reservedword
... I'll create another issue
... we already discussed last topic from my slides

Recap Conf

Peter: what are the major takeaways from last week?

W3C Auto TPAC meetings

Ted: working on draft charter

Call for consensus VISS

VISS version pull request

Ted summarizes steps

Best Practices

Peter: I wanted to see if there was more input on that
... it is a difficult but necessary task

Best Practices wiki

Peter: wanted to hear others' thoughts

Ted: a breakout call with interested parties like we do RPC
... I know Arman and Isaac are interested, want to hear others' thoughts

Arman: should include the links I mentioned last week and sent you

Ted: will add those to last day's minutes

https://www.unece.org/trans/main/wp29/introduction.html

https://e-estonia.com/solutions/security-and-safety

Glenn: the public data set for testing interop for OBD2 may be worth testing against
... there is issue of bad actors utilizing that existing data port. tools we develop can control data access and prevent inappropriate use of
... OBD wireless activities are being discussed in EU and NA but what we are doing is most practical and we want to test is across multiple vehicles
... EV are not required like ICE vehicles to have that port

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/20 20:00:28 $