Automotive Working Group Teleconference

22 Sep 2020



MagnusF, Adnan, Arman, Isaac, Gunnar, Ulf, MagnusG, Daniel, Steven


<scribe> Scribe: Ted

<scribe> scribenick: ted


TPAC Agenda


Ulf: maybe we should have discussion on Gen3

Ted: agree, look at what we deemed out of scope for Gen2 and consider a Gen3 or extension
... goal will be to finalize and adjust days based on individuals' availability

Service or Signal discovery

Ulf: I invented the naming in the Gen2 specs, this is a variation of getMetaData from VISS
... but now when we have a service catalog work started maybe should not use that
... might be better as signal discovery, you want to know as a client what signals there are

Ted: +1 from me to use signal to avoid confusion
... last time we also went on tangent of whether restricted signals should be reported back to client

Gunnar: agree
... we can leave the other topic for now

Ulf: whether a node is restricted or not should be made clear
... we have a policy document with scope list that enables signal discovery as well for certain roles
... we have that mechanism right now

Ted: can that be applied to private branches as well, since they may be sensitive ones there as well

Ulf: absolutely

Issues 326 and 340

New name proposal

Ulf: I was again reflecting on the new service catalog work and relate on naming



MagnusF: how about VSS-protocol, protocol for transporting the data

Gunnar: I am also partial to VISS2 or VISS version 2
... I don't see why it needs to change
... what is a model, what is a catalog...

MagnusF: we will face the same things with VSC
... I still like the -protocol appendix
... we want to avoid confusion for those seeking compliance and certification

Gunnar: just this last week I had two presentations and do not want to replace existing acronyms/names and would like some consistent
... we should come up with something for RPC as Ulf has done in his comment


MagnusF: I don't feel strongly, VISS2 may be same protocol for both signal and rpc instruction

Ted: agree that is a high level design goal

Ulf: I'm happy with how we furthered this

Gunnar: as I listen to this, I hear we have open question on relation between Gen2 and RPC
... I am opposed to renaming VSS and VSC but could see those two combining

MagnusF: collapse of signals and services

RPC input

protocol in synch

@use VSS in VSC

MagnusF: I agree
... inverse is not true, you can service not associated with signal

Ulf: agree as well

Ted:I have heard concern from a couple different people we are jumping to solution without understanding problem more
...early eval of RPC protocols, not decision time. we would at most prototype and play/contrast
...align with Gen2 architecture as we expect it to be intertwined with RPC
...use VSS in VSC, not new set of signals
...more use cases, further understanding of problem trying to solve. Glenn cited several and sent SAE doc to list
...need stakeholders coming from other side, who would likely be using this RPC service and accompanying catalog


Ted: I am reaching out to some companies but if you can connect me with current or prospective partners, that would help. If they are existing W3C Members, may be easier to readily engage them as already through legal obstacle

Gunnar: hope people can be free to express to the group at large. on RPC protocol we still need to be clear on which is proposed

Issues 326 and 340



Ulf: 326 we discussed last time and think I got an action on updating, use the same handling of error information in WS and HTTP
... I updated the spec accordingly which is 340
... I also did some minor cleanup

Ted: I will review those


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/09/28 16:46:57 $