<scribe> scribenick: ted

<scribe> Scribe: Ted

New Chair

Ted: I am pleased to announce we have a third chair, Patrick L from VW

PatrickL: danke

Adam: congratulations

F2F next steps

Paul: we came out of the F2F with plans on going forward with an initial focus on data model
... Ulf did a great analysis and sent to the group

Ulf's analysis

Ulf: I tried to find alignment between the two approaches
... initially took view of trying to add VISS to ViWi model and after struggling for some time looked at the reverse option
... my current thinking is starting with VISS as a base and adding ViWi
... then I looked at specifically what would make sense to bring into VISS from ViWi

Paul: Rudi agreed in email and this was Gunnar's thinking at F2F

Adam: it would be useful to look at Gunnar's proposal

PatrickL: I might have an idea why you see VISS are more signals centric and ViWi as more media/resource centric
... we describe the object of a resource and all clients look at the resource to get its current state and can interact with it
... with VISS we have many signals in a tree structure being sent out
... we did not have a problem in our implementation going with a resource type representation

Gunnar: you had goal to put it under one model

PatrickL: yes, we wanted a common way to access
... more controllable. we wanted communication in vehicle to be consistent and for us it wasn't enough to have it on a pure signals base
... we found grouping to be more useful
... we tried an artificial approach on top of CAN before coming to this conclusion

Gunnar: I think we have consensus
... the media interface works very well based on current media information availability
... media is more static

Ulf: it should be possible to augment VSS data model so it can also handle other types of resources in a similar way to how it is done in ViWi
... yes there are differences in the data and agree a single model is more elegant

Gunnar: where it makes sense, yes but think we have different ideas about how
... I am not advocating transforming VISS for media. I think a different model is more appropriate for media

Ulf: I think we should investigate both approaches

Gunnar: VISS is optimized for signals

Ulrich: where do you see this optimization? please elaborate

Gunnar: I see a close relationship to CAN databases and other types of signals, eg from software
... there are Flexray and other types of network with steps towards ethernet
... VISS and car signals on buses is what I meant

Ulrich: for me the separation of signals and collections. if my interest is multi-media, I would look at them differently with different grouping
... if I am a developer wanting to support the driver, you will want different views
... signals should be referenceable in multiple ways

Gunnar: an id gives you less information than a fully qualified name

Ulrich: but with a unique id, I can expose a signal elsewhere in the tree
... in the end the signals being accessed are the same but found in a different place in the hierarchy

Gunnar: I think the flat list will help. vehicleSpeed would mean the same regardless of where it comes from

Ulrich: the value is in the definition and need to agree on a unique name

Gunnar: stepping back with a flattened view and determine what tree might make sense

<PatrickB> don't we have tgis list exactly here: https://github.com/GENIVI/vehicle_signal_specification/blob/master/vss_rel_1.0.csv?

Paul: I am trying to understand the value of having an object id

Ulrich: the important part is to agree on a good name

Paul: is it really flat, . replacing path

Ted: flatter...

Laurent: I couldn't quite figure out how the path/grouping worked initially, now I see the layout
... is there is a limit to path? if not there should be

Gunnar: ViWi only describes what information is available not where as in VISS

Ulrich: I would find it difficult to give a priori depth
... one thing I see in the problem space is multiple sensors representing the same thing as with speed
... there can be multiple location, how will that be handled?

Adam: to me it is about what you want to display to the user. a heads up display would have a logical clustering and therefore which signal

Gunnar: do you mean a filter of which signals get exposed?

Adam: you would want a single, overall vehicle speed

Gunnar: unless there is software averaging them, you want to select a single one

Paul: the concept is the same and hearing you both saying choose one
... makes sense for HMI but what about when sending to the cloud?

Ulrich: would I want to know and how to choose?
... a given source might require less overhead to make that information available or have a different frequency
... how do I choose which given a choice?
... data quality, frequency, accuracy come to mind

Ted: discovery is very important for HMI or edge computing, know what information a given vehicle is willing to expose to that application

[discussion of flattening data]

Magnus: what I remember was the this was mostly for consistent vocabulary

Gunnar: certainly but also to see if there can be independence with the path/location of that signal
... wish we had Benjamin here

PatrickL: we wanted to solve two tasks, settling on a data model and then framework
... regarding the data model we should work on this later since it seems to be influenced by the framework
... one of the first tasks for the framework is structuring the data it wants to handle
... are we going raw signals, more object oriented or other
... once the framework is settled we can focus on both. context switching between them is slowing us down

Gunnar: I proposed at F2F drawing from VISS for the framework
... to get a REST interface in a fairly quick manner

PatrickL: I would like to see influence from the ViWi submission in that proposal

Gunnar: I would like to hear more from the group

Ulf: that is one possible way forward but would try to raise the bar and draw from ViWi
... I had some ideas on how to start that in my email and believe there can be more

PatrickL: my preference would be to look at what we like from both instead of direct comparisons since the latter leads to circular discussions
... this is why I wanted to focus first on the framework
... I want a pure list of the things we like from each and whether we want more object oriented or signals stream related

<LaurentC> Should we be taking at look at the work that has been done (re VSS->REST) by genivi already? https://openconnectivity.org/wp-content/uploads/2016/01/GENIVI-OCF-Mapping.pdf

Gunnar: you could argue the chassis is an object

PatrickL: how about signal or resource based and to focus on these topics on next call

Laurent: one topic is VSS to REST and it reminds me of the work done at Genivi for coordinating with OCF

Ulrich: how about talking about flat list and additional attributes?

PatrickL: can you send to the mailing list?

[adjourned]

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s|@@L|Ulf's analysis|
Succeeded: s/way/way to how it is done in ViWi/
Succeeded: s/ CAN databases/ CAN databases and other types of signals, eg from software/
Succeeded: s/worked/worked initially, now I see the layout/
Succeeded: s/@@a/discovery is very important for HMI or edge computing, know what information a given vehicle is willing to expose to that application/
Present: Marty Ulf Ted Paul Glenn Adam PatrickL Hira Laurent Urata Gunnar Magnus Ulrich
Found ScribeNick: ted
Found Scribe: Ted
Inferring ScribeNick: ted
Found Date: 02 May 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)