Meeting minutes
Two calls occurred in the Automotive Working Group today and represented in this minutes file. First was on VISS version 2 features with VISS version 1 implementers Bosch and Renesas, second was regular Working Group call
Introductions
Renesas and Bosch additions to VISS version 1
Yusuke shares screen for presentation
Yusuke: personal mobility requires connectivity
… regarding W3C activity we have started to think about centralized, service architecture
… there are three main issues, network availability, massive amount of data and integration and optimization of services
… we created some different designs on how to connect to the cloud
… taking advantage of edge and cloud computing
… we're participating in R-Car consortium with ~250 partners
… VISS is used as universal interface
… used with a connected SDK
… we have a CAN generator for simulating
… we are are collaborating with various cloud providers
… Renesas R-Car starter kit is available in MS Azure IoT environment
… possible to create services around R-Car
… CCPF starter kit for application development, some of the requirements come from the customer
Ted: the connection SDK for off-boarding data?
Yusuke: yes
Stephen: simulator adds in some private data
Yusuke: yes such as DMS (driver monitoring system)
Ulf: the signals you mention like DMS, is that something you want to bring into the [data] standard (VSS)?
Yusuku: current thinking is to share with partners
Stephen: we are not a DMS supplier, so hard for us to define the signals
… we can be helpful in identifying what should be added
Ulf: makes sense but we need to work together to fill the gap
Ted: we were not encouraging
contributions of new signal definitions while refactoring VSS and have
since only added a few around eg EV, we want to start creating more for
ADAS, DMS etc and welcome help in enlisting contributions
… anything you can share about access control in R-Car?
Hisao: we have security capabilities but this was a trusted environment and not needed at this point
Sebastian: we are coming from VSS data point, we want the abstraction inside the vehicle
… and bring it all the way up to the cloud
… we have a VISSv1 server (Kuksa.val) and use if for various efforts on IoT events and bringing to MS cloud
… components fill out the data tree and we have some test clients we can provide
[example setting vehicle speed from command line]
major additional features in draft VISS version 2
Sebastian: we have a rudimentary way to connect to the cloud
… we have a MQTT server for exposing VSS as well
… as Ted mentioned, VISS deferred on security. we are using JWT
… token restricts what you can access
… we want to be able to control access on individual signal level
… we wanted to keep it as simple as possible and kept permissions flat
… inside the vehicle we do not have model of roles
Ulf: version 2 uses a role based access control model
… there is more need for authorization server in the vehicle to determine which signals are allowed for a given role
… you can also get granular per signal
… using policy documents, which adds complexity and flexibility
Sebastian: I see need for roles at some point. in our architecture we don't see that needed within the vehicle
Ulf: agree, different flavors
Ted: some of that comes from the different use cases and allowing for connections from the cloud in addition to in-vehicle
Sebastian: we consider ourselves compliant with v1 and some additions
… v2 has some advanced things for filtering which may also be something we don't want
… v2 scope is larger and valid but maybe want some different feature levels
Ulf: I agree, not everything needs to be implemented but can have common set for compliance
Ted: we should start a couple issues to further discussion - filtering essential and optional; two flavors of access control for trusted (simpler) and untrusted environments/uses
Ulf: we do have a reference implementation which fulfills 100% of the spec which may help consideration
GENIVI AMM
GENIVI AMM meeting is next week (similar to W3C TPAC) and as people will be attending that we should cancel other W3C+GENIVI calls. earlier today decided to cancel VSS/VSSo call, will do same for Best Practices on Monday and WG call on Tuesday
Daniel and I will hold the VSSo/Microsoft DTDL call on Monday though since it was rescheduled from yesterday
update on Ted leaving W3C, interim plan
Replacement Team (Staff) Contact discussion ongoing, delayed by vacation
A part time industry vertical 'champion' from automotive industry is being considered, discussion started
Philippe Le Hegaret (aka PLH, W3C Project Manager) to fill in for the meantime and thought he might be on today's call
We may want to review, reschedule and condense call schedule - number of breakout calls after we recharter, have a new Team Contact, and to accommodate Sebastian's schedule
PLH encouraging us to republish VISSv1 as CR as a couple minor edits occured and then, seek horizontal review and force privacy issue in order to advance to PR
PLH also encouraging us to publish VISSv2 as FPWD, not delay for input from Bosch or others (eg Renesas) since it can be revised
Requested MIT guest account status so hopefully the WebEx/Zooms don't break
Management I believe will make a decision on their next call on May 5 about Ted taking on co-chair role from Geotab
We might want to do an early release of In-Vehicle Application Best Practice then too
Advisory Committee approved our charter, review ended end of last week. We may delay announcing releasing it to contain updates on Team Contact and Chair
Issues
https://
Ted summarizes Bosch/Renesas/W3C VISSv2 call https://
Ulf: agree, our usage of role based approach doesn't match with their scope
⦠I don't think it would be so easy to remove role piece
https://
Ted: any of the filter mechanisms missing/hard coded and not implemented?
Ulf: curve logging isn't implemented but defined, otherwise all there
⦠that is a stub
Ted: I want supportive arguments for including or excluding subscription filters from required and optional lists
⦠we may also want to support undefined filters, presumably client and server will be aware of them outside of our spec
Ulf: as it is right now the whole access control chapter is written as optional, we can certainly do same for filters
MagnusG: only concern I have is we need a way to communicate what features are available on server (discover)
Ulf: yes some sort of negotiation or discovery
MagnusG: otherwise we will end up in regular incompatibility issues where a third party application may not be prepared to handle different server implementations
Ulf: we do have to come up with such a mechanism
Gunnar: it is important specifications clarify behavior when there are optional features
MagnusG: agree, one point is to communicate capabilities to a client, another is an appropriate error message or way client can react
Ted: maybe similar to getMetaData, in some cases we may have a default alternate eg filter if requested one is unavailable such as curve degrading to delta change if curve not implemented
Ted: we have two approaches at present for MQTT, VISS over MQTT and VSS in MQTT. didn't learn what Renesas is doing there but do recall interest expressed by them in MQTT
MagnusG: we should look at other protocols, we are looking at https://
Ted: any main benefits?
MagnusG: it automatically clusters, so scaling useful and you do not need to do routing
Ted: issue maybe then is how we support arbitrary protocols, if we can shield from client which is used and implementation may support different ones for performance or other reasons
⦠make us future proof for future, as yet to be defined, protocols
Ulf: largely should work, you might need a little bit outside as I did for MQTT experiment but payload is essentially the same
MagnusG: I could go for idea of additional protocols as extensions, not part of main specification
Ulf: agree
https://
https://