Automotive Working Group Teleconference

14 Oct 2020



MagnusF, Steven, Arman, Glenn, MagnusG, Ulf, Peter, Daniel, Ashish, Isaac, Joakim, Urata, Jon, Karen, Adnan



[WoT RPC proposal]

Daniel: forgive the rough drawing sketch
... I had some internal discussions in WoT group
... what is still missing is RPC calls and relation to VSS as raised in repository as well
... seems we are deviating already from VSS
... the example in VSC repository already shows lack of alignment
... in VSS we have branches, sensors and actuators
... how do we get this together with RPC idea
... we have VSSo (ontology on top of VSS) although it needs to advance from VSS1.0->2.0
... thing description is thing deployment, description of VSS tree excerpt needed and the RPC call
... we have all the units etc in VSSo. we have data schema and with it can link to VSSo signals
... thing has properties attributes and events. you can have a describeable property
... actions are equivalent of RPC calls as I see them, you have input that triggers action
... actions can either use actionable signals from VSSo
... works for simpler scenarios with small set of clear signals, some cases like cruise control would be more complicated
... we can sort RPC calls based on topic branch. WoT makes it easy to point to underlying signal
... there is existing tooling for WoT including bridging to different underlying protocols
... happy to share a short example
... using a JSON-LD file, where context comes in place you can see here a window and its properties eg position
... you can say the thing is observable. WoT can generate code to HTTP REST, Sockets etc

MagnusF: so this is like a window object description with methods, gettables and settables

Daniel: exactly
... it can include what we can to describe with VSS and separate RPC calls

MagnusF: haven't read on VSSo much, can I use inheretance etc?

Daniel: right, you don't have to use a branch but did so to make it more understandable
... you can have link to branch, use single elements

MagnusF: how to get a notication and needed interface when someone else changes it?

Daniel: this goes through to all thing descriptions. you would refer to notification interface
... I split deployment from modeling in my example you would provide URL to where you would get notification
... as mentioned WoT supports a number of protocols already
... we used our thing description, Node and did some drag and drop to create the interaction

MagnusF: completely different approach, not necessarily bad
... this ties RPC and signals into a more traditional object model

Daniel: exactly

Joakim: there is a vocabulary but those objects or statements are schemaless
... any examples on how to query this?

Daniel: I prepared this last week, earlier example not running at present

MagnusF: Steven, curious your reaction?

Steven: what comes to mind is it changes what we would define as a service. we have been seeing it as a collection of RPCs
... now you are seeing service as collection of objects that belong to that service

Daniel: yes and no. you bind it with logical bundles

Steven: do like how this makes the model more unified

Peter: you mentioned there are a number of protocols already supported
... we have similar API that is agnostic about protocol

Daniel: you need to make the protocol bindings in thing description, doesn't have alternatives easily

Peter: I want to provide developer option to close all windows

MagnusF: still a bit confused on classes vs objects
... for services we didn't really have objects either but here how do we instantiate eg close all windows. how do I get the objects to call?

Daniel: you just describe the API you are calling. you don't really define it since it is done already with its ontology
... then the tooling lets you choose what exists to expose

MagnusF: I'll need to read more on the ontology

Ted: fair warning, Semantic Web and ontologies gets rather academic rather quick, you don't need to delve deep into its background but keep higher level focus

MagnusG: can you provide link to think description playground you are using?


Ted: we have jumped around on protocol preferences, believe we need to have clear requirements and develop some more use cases in detail in order to make more informed decision

Joakim: I use this technology for analytics/queries more than calling functions

Wiki scratch space for use cases

Daniel: it gets hard to get agreement on protocol that everyone would use
... common definition of services (functions) being offered of huge benefit

Peter: yeah

Daniel: perhaps you want to map to an underlying existing API, possible to have different instantiations

Joakim: in W3C Media and Entertainment we defined first an ontology to represent all the information and API later on top of that

Ted: I want VSC to reuse VSS signals as defined. if VSC follows same taxonomy then creating a corresponding ontology using same tooling (needs to be revised for VSS2) is straighforward and you can have signals and service functions in Web of Things playground in creating your thing description

Joakim: there are many metadata formats for media on the web but we wanted to say what the relationships were and to make it easier for developers withou knowing 25 different formats
... here I am imagining OEMs have their legacy signals, naming of functions and this can be a layer on top

Daniel: layer is only in terms of communication
... you point to the underlying REST API

Joakim: reason I mentioned EV charging the other day, it is becoming more important
... it would be good if we could do something in this group for the different players to be able to jump in
... we want to make it easier for our partners to tie in

Ted: maybe see if you can have Adnan replay the video

Daniel: we have a paper about it

VISS call for concensus

Ted: basically after Peter and Daniel approve my pull request to VISS and Peter sends out a Call for Concensus we can more VISS from Candidate Recommendation to Proposed Recommendation

Access Control

Ulf: from my point of view I see it as complete and a working design
... working on implementing it in our Gen2 implementation, prompted a small pull request Ted already approved
... minor details, so far see this as working, not seeing additional issues

Data sampling

Glenn: we sent GENIVI a licensing agreement for our curve logic algorith, we will want an open source and open standard to accompany it


Ted tries to describe it

Ulf: what you can use to describe it is it allows you to throw away many data points
... the ones you keep allow you to reconstruct to a reasonable error threshold the full picture

MagnusF: I have done this under another name for aerospace
... you do not need full resolution but just the diff, in fewer bits. you don't know full location but the delta

Ulf: that is not in this algorithm

Ted: initially my interest was in metadata on how sampling by an app is done when offboarding so it has more value in the cloud, also degree precision etc
... adding sampling methods to Gen2 reduces complexity of client applications, convenience to developer

[Ulf presents sampling characteristics slides]

Ulf: it affects things like data quality, bandwidth and maybe other things
... if you want as client to be able to read sampling characteristics available in the vehicle, you may want to also be able to set it
... should it be per signal, group or for all signals sent to a given client app?
... it could also be set vehicle wide
... perhaps even be able to support all of the above. how to perhaps provide that control

[example using #sampleMethodX]

(for per signal or group of signals)

Ulf: WebSocket could readily support or HTTP header
... setting it per vehicle, it should be a node in the tree
... then could be Vehicle.Connectivity.Data.SamplingCharacteristics

Peter: per vehicle is interesting, would that be for all signals exposed by Gen2?
... per signal I see more valuable
... to try to not overcomplicate would be a goal

Ted: I could see benefit of doing so for the vehicle so all Gen2 clients are limited in what data they consume. maybe default but overrideable
... HTTP doesn't make sense unless you requested earlier and want to keep subsequent request open, strains HTTP with timeouts. WebSocket on the other hand quite natural for this

Ulf: if we are to introduce in Gen2 it would need a chapter

Ted: wonder what methodologies we want interval, simple delta (eg +10), curve, event

Ulf: we already have interval and delta
... for subscriptions
... per signal for delta
... we might have another already

Ted: others interested?

MagnusF: clear need as long as we can keep it simple and easy to understand for developers

naming Gen2

Ted reviews discussion and options

Gunnar: I want to object to CVIS since it is close to CVII

MagnusF: I would go for VISS version 2
... it is established, doesn't clash

Gunnar: there was some concern on Service being in name given Vehicle Service Catalog

Ted: could change that S but that might cause confusion

Ulf: changing it to Signals would help

Gunnar: then it is too close to VSS
... how about VIPS - Protocol

MagnusF: I like that

Ulf: then you loose connection to VISS

Peter: my vote keeping VISS

Adnan: relation to signals a bit strange, made some suggestions
... CVIS maybe

Gunnar: CVII is perhaps turning into a significant initiative

Arman: Connected a bit redundant to interface, no strong opinion

Daniel: VISS version 2

Glenn: no strong preference, defer to Ulf

Gunnar: VIPS

Karen: don't mind CVIS as it compliments CVII more than causes confusion
... VSS has some history

MagnusF: VIPS

MagnusG: no strong opinion VISS or CVIS although latter has prior meaning for me

Peter: VISS

Urata: no strong opinion understand VSS and VISS a bit confusing but VISS2 natural for me

Steven: equal for VIPS as Protocol part helps or VISS2

Ulf: CVIS as well, VIPS as 2

Ted to send finalist to survey


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 19:52:47 $