Automotive Working Group Teleconference

07 September 2021


Ashish, Carine, Gunnar, Isaac, MagnusG, Peter, Ted, Ulf

Meeting minutes

Implementation notes

Peter: brief report for now, I started an implementation based on fork from VISSv2 reference implementation
… goal is to have it running in a vehicle soon. I'm using another open source project to feed southbound signals
… bimi (sp?) broker which started at Volvo but now elsewhere and flexray
… I'm using a record/playback mechanism for testing VISS via bimi
… setup a 'vehicle' on a rpi
… Ulf's implementation is working, using dockerized composition from Magnus which is also working
… the plan here is to use this to populate VSSo in the cloud

Ted: presumably Joakim will jump in on VSSo part?

Peter: yes, guess that is it for now

Ulf: glad this is being used

Peter: hope to have more progress in a few weeks and a vehicle with hardware that can support it

Gunnar: when mapping signals from flexray to VSS, are you using a configuration file to map?

Peter: I have some ideas on how to do that. that is one of the challenges here, low level work
… there are lexical similarities between the models that may facilitate

Ted: that is going to be a common problem for others, would be great if we can generalize it
… we have to do that often ourselves

Ulf: it is arduous indeed, think Peter was looking for automated mapping

Peter: that is my thought based on similarity of naming, not sure how far you can go with it

Ulf: not all the way but a good start

Gunnar: we have a similar exercise elsewhere, eg for Android

Peter: there are a number of useful tools out there, hopeful we might be able to achieve something
… there may be gaps between the mappings, eg additional signals not in VSS

Ted: immediate solution is to use private branch and encourage contributing those for consideration back to VSS

Issues and PRs

Ulf: perhaps we can first hear from Isaac on his thoughts or progress on revision from last time

Isaac: too early to present, should have more by next week
… perhaps a summary for the callers here worthwhile

Ulf: let's defer and cover next week


Ulf: first off thanks to Gunnar for helping sort out PR mess last week



Ulf: we were inconsistent in providing timestamps and concluded we should be uniform
… getSuccessResponse had timestamps for data points but not the time for the response itself
… this PR contains more than just timestamps as I noticed the format for the responses was using old way of representing data points
… it is possible to return multiple data points in one response
… I addressed both in this PR
… I consider this a minor PR and propose we adopt it

Ted: agree, let's go with it



Ulf: this relates to tokens in transport, how they can be used
… there was only one example but we have different types of requests
… this one should be fairly straight forward as well, using tokens for slightly different requests
… the main thing here is "A token header can be combined with all types of update requests"
… this one is fairly straight forward. unless people feel more is needed, suggest we accept this change as well. it meets and resolves the raised problem
… I encourage people to read through the other PR on their own as I wasn't part of it

Ted: let's discuss that one next week


[closing 387. 399 only half addressed at present]


Ulf: while we have multiple underlying datatypes in VSS but in the actual JSON payload it is sent as a string
… I claim there is value in having it as a string
… crea7or pointed to C locale and JSON RFC, my leaning is to the latter
… I could produce a PR but want to get input first

Gunnar: doesn't it need quotes to be strings in JSON?

Ulf: quotes make clear it is a string but not required

Gunnar: this comes from JS typing

Ulf: my question is are we ready to consider a PR adding this

Peter: I think its needed
… ran into exactly this with southbound translation

Ted: perhaps try to get some feedback from Sebastian first


Ulf: that is a good point, agree consistency would be better

Ted: agree

Peter: seems straight forward

Ulf: I'll address and use arrays


Ulf: the question is should it be possible to set more than one signal in a request
… at the time I wrote it, thought so but now hesitant

Ted: for locking all doors, same node as suggested, makes sense but not across nodes
… access control per signal write could prevent. think child window/door lock - don't let the kid in the backseat unlock all doors

Gunnar: I wonder if such policies (access control) would take care of it

Ted: agree

MagnusG: how are we handling error response if eg one is refused?

Ulf: it could be all fail and underlying system should revert
… that may be a pain for implementations

Gunnar: yeah we would have to support transaction rollbacks
… recall the previous discussion that setting a target value may take some time, not produce immediate results
… you might need to eg read back repeatedly to see progress of window being lowered

Ulf: some of this belongs more in VSC than VISS
… the client can check results and act accordingly

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).


Succeeded: s/how are we handling for get?/how are we handling error response if eg one is refused?/

No scribenick or scribe found. Guessed: ted