W3C home > Mailing lists > Public > public-automotive@w3.org > January 2020

Re: VSS Layers introduction

From: Rudolf J Streif <rudolf.streif@ibeeto.com>
Date: Tue, 21 Jan 2020 09:02:26 -0800
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Cc: Gunnar Andersson <gandersson@genivi.org>, W3C Public Automotive <public-automotive@w3.org>
Message-ID: <f83a9a86-1971-989f-35fe-232a17f43e0d@ibeeto.com>
In addition:


The entire concept of layers allow "legoization" of VSS. Rather than
building a monolithic VSS and then remove pieces from it a Gen2 VSS
should be built from layers to begin with:


* start with a vehicle base layer that defines nodes for a generic vehicle
* add a propulsion layer for ICE, electric or both for hybrid (or a
separate layer for hybrid)

* ...


You get the idea. We can still support a remove/exclude directive but I
think its use should be the exception only and not the rule.


:rjs


On 1/21/20 8:49 AM, Rudolf J Streif wrote:
>
> What exactly is the use case for removing entire subtrees from
> something that is standardized in the first place? It counteracts
> standardization if that can freely be done.
>
>
> I made one example about ICE vehicles vs electric vehicles. That might
> actually warrant separate vspec trees for electric and ICE vehicles.
> But...
>
>
> Now we have include directives which essentially operate on files. If
> we convince ourselves that we need removal of trees and nodes we could
> actually use exclude or remove directive in vspec files:
>
>
> #remove Vehicle.Cabin.Infotainment
>
>
> :rjs
>
>
> On 1/21/20 8:35 AM, Magnus Feuer wrote:
>> Ack on the problems of specifying overlay rules as metadata. Let's
>> drop that.
>>
>> However, we still need to be able to wipe subrees and completely
>> replace them with an overlay. 
>>
>> We could do it from the command line, which is not an ideal solution
>> but would work:
>>
>>
>> $ apply_vss_overlay.py \
>>     --master=VehicleSpecification.vspec \
>>     --delete "Vehicle.Cabin.Infotainment" \
>>     --overlay=my_overlay.ovspec
>>
>> Better?
>>
>> /Magnus F.
>>
>>
>>
>>
>> -------------------
>> /System Architect Manager/
>> *Jaguar Land Rover*
>>
>> *Email*: mfeuer1@jaguarlandrover.com
>> <mailto:mfeuer1@jaguarlandrover.com> 
>> *Mobile*: +1 949 294 7871
>>
>>
>>
>> Jaguar Land Rover North America, LLC
>> 1450 NW 18th Ave, Portland, OR 97209
>> -------------------
>> Business Details:
>> Jaguar Land Rover Limited
>> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF 
>> Registered in England No: 1672070
>>
>> This e-mail and any attachments contain confidential information for
>> a specific individual and purpose.  The information is private and
>> privileged and intended solely for the use of the individual to whom
>> it is addressed.  If you are not the intended recipient, please
>> e-mail us immediately.  We apologise for any inconvenience caused but
>> you are hereby notified that any disclosure, copying or distribution
>> or the taking of any action in reliance on the information contained
>> herein is strictly prohibited.
>>
>> This e-mail does not constitute an order for goods or services unless
>> accompanied by an official purchase order.
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rudolf J Streif
>> *Sent:* Tuesday, January 21, 2020 07:33
>> *To:* Magnus Feuer; Ulf Bjorkengren
>> *Cc:* Gunnar Andersson; W3C Public Automotive
>> *Subject:* Re: VSS Layers introduction
>>
>> I thought about using an attribute to define what an overlay does
>> before. I came to the conclusion that it is not that good of a
>> solution as it makes adoption of somebody else's overlay tree quite
>> complex as you have to go through every single file and look if you
>> like the overlay or not.
>>
>>
>> If the whole concept of it is really necessary, and I am not quite
>> sold on that in the first place, then there should be a toplevel way
>> of doing it.
>>
>>
>> :rjs
>>
>>
>> On 1/20/20 12:17 PM, Magnus Feuer wrote:
>>> Late to the party, as per usual.
>>>
>>> We do very much need layers. As Ulf and Rudi pointed out, we need to
>>> think about removing both metadata and whole branches, for example
>>> when a single instance of something needs to be replaced by an
>>> enumerated list of instances. 
>>>
>>> A somewhat silly example is if we have multiple IVI systems, which
>>> necessitates the following change: 
>>>
>>> ...Infotainment.[subtree] -> ...Infotainment.1.[subtree],
>>> ...Infotainment.2.[subtree]...
>>>
>>> In this case the existing "...Infotainment.[subtree]" needs to be
>>> deleted since it would interfere with the enumerated list of IVIs.
>>>
>>> One (somewhat over-engineered) solution would be to add metadata
>>> (attribute) to the overlay file's the branch, specifying how the
>>> overlay should be applied:
>>>
>>> #
>>> # I am an overlay file that modifies an existing tree.
>>> #
>>> - Vehicle.Cabin.Infotainment:
>>>   type: branch 
>>> *  overlay: replace* # or one of  extend, modify, modify_and_extend. 
>>> *
>>> *
>>> - Vehicle.Cabin.Infotainment.1:
>>>   type: branch
>>> ...
>>>
>>> The overlay attribute can be one of:
>>> *extend*
>>> The overlay extends an existing branch in the signal spec, but does
>>> not modify existing signals. If an existing signal is re-defined by
>>> the overlay, an error is thrown.
>>> Metadata can be added to existing signals.
>>>
>>> *modify* 
>>> The overlay modifies existing branches and signals in the original
>>> spec. If a signal (or branch) does not exist in the original, an
>>> error is thrown.
>>> Metadata can be added to existing signals.
>>>
>>> *modify_and_extend [default]*
>>> The overlay can both modify existing branches and signals, and
>>> create new one.
>>>
>>> *replace*
>>> The entire branch is cleared from the original specification, and
>>> only the structure defined in the overlay will be used.
>>>
>>> Would that work?
>>>
>>> /Magnus F
>>>
>>>
>>> -------------------
>>> /System Architect Manager/
>>> *Jaguar Land Rover*
>>>
>>> *Email*: mfeuer1@jaguarlandrover.com
>>> <mailto:mfeuer1@jaguarlandrover.com> 
>>> *Mobile*: +1 949 294 7871
>>>
>>>
>>>
>>> Jaguar Land Rover North America, LLC
>>> 1450 NW 18th Ave, Portland, OR 97209
>>> -------------------
>>> Business Details:
>>> Jaguar Land Rover Limited
>>> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF 
>>> Registered in England No: 1672070
>>>
>>> This e-mail and any attachments contain confidential information for
>>> a specific individual and purpose.  The information is private and
>>> privileged and intended solely for the use of the individual to whom
>>> it is addressed.  If you are not the intended recipient, please
>>> e-mail us immediately.  We apologise for any inconvenience caused
>>> but you are hereby notified that any disclosure, copying or
>>> distribution or the taking of any action in reliance on the
>>> information contained herein is strictly prohibited.
>>>
>>> This e-mail does not constitute an order for goods or services
>>> unless accompanied by an official purchase order.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rudolf J Streif
>>> *Sent:* Monday, January 20, 2020 10:44
>>> *To:* Ulf Bjorkengren
>>> *Cc:* Gunnar Andersson; W3C Public Automotive
>>> *Subject:* Re: VSS Layers introduction
>>>
>>> Hi Ulf,
>>>
>>> > I like that the VSS layers model as I understood it takes as input
>>> "layer files" with the same filename, but different extension,
>>> located in the same directory as the
>>> > vspec file that they are to update.
>>>
>>> Actually that is not how it currently works. The overlay files can
>>> have different names and are in different directories. What is
>>> important is the branch name of the nodes and that they files are
>>> included at the right position in the tree. That means, yes, you can
>>> have a file with a different name (including extension) in the same
>>> directory and include it there or you can have a full directory tree
>>> starting at the root. And of course anything between these two
>>> "extremes".
>>>
>>> > With this model we will have the existing tool(s) that transform
>>> the vspec YAML format to other formats (JSON, csv, etc), and new
>>> tool(s) that use the YAML layers to
>>> > modify the YAML vspec files.
>>>
>>> The converter tools already handle that.
>>>
>>> > Adding or overriding metadata in nodes should be straight forward.
>>> Removing metadata in nodes needs a little more design thinking,
>>> maybe with a separate "remove-
>>> > tool" and layer files?
>>>
>>> Removing nodes from the default tree through an extension tree is a
>>> use case that has not yet been discussed.
>>>
>>> > What to me seems more complicated is to add or remove nodes, is
>>> that something that should be supported?
>>>
>>> Adding nodes is supported. The whole scheme is actually pretty
>>> simple if a node already exists when an extension/layer file is
>>> processed then the fields get updated (or added for that matter if a
>>> field does not yet exist e.g. CAN DB field). If a node does not yet
>>> exist it will be added.
>>>
>>> :rjs
>>>
>>> On 1/20/20 5:36 AM, Ulf Bjorkengren wrote:
>>>> I like that the VSS layers model as I understood it takes as input
>>>> "layer files" with the same filename, but different extension,
>>>> located in the same directory as the vspec file that they are to
>>>> update. 
>>>> With this model we will have the existing tool(s) that transform
>>>> the vspec YAML format to other formats (JSON, csv, etc), and new
>>>> tool(s) that use the YAML layers to modify the YAML vspec files. 
>>>> Adding or overriding metadata in nodes should be straight forward.
>>>> Removing metadata in nodes needs a little more design thinking,
>>>> maybe with a separate "remove-tool" and layer files? 
>>>> What to me seems more complicated is to add or remove nodes, is
>>>> that something that should be supported?
>>>>
>>>> On Fri, Jan 17, 2020 at 7:31 PM Rudolf J Streif
>>>> <rudolf.streif@ibeeto.com <mailto:rudolf.streif@ibeeto.com>> wrote:
>>>>
>>>>     Actually this statement is not quite correct:
>>>>
>>>>     1) Potential for *any number of* layers. (As of now the private
>>>>     branch
>>>>     acts as a *one* additional "layer" that can override and add
>>>>     data, as
>>>>     you now described)
>>>>
>>>>
>>>>     It's not limited to a branch called 'private'. What branch is
>>>>     merged and
>>>>     where is defined by an include in the toplevel
>>>>     VehicleSignalSpecification.vspec. Now of course this begs the
>>>>     question
>>>>     what happens if there are multiple includes that modify/amend
>>>>     the same
>>>>     nodes when there are conflicts? The answer is: "the last one
>>>>     wins" as
>>>>     the includes are processed in order of appearance in
>>>>     VehicleSignalSpecification.vspec. That essentially constitutes an
>>>>     implicit priority.
>>>>
>>>>     Layer priority is probably something that you want to add to
>>>>     the slide
>>>>     "Additional design challenges".
>>>>
>>>>     :rjs
>>>>
>>>>     On 1/16/20 9:52 PM, Gunnar Andersson wrote:
>>>>     >
>>>>     > Thanks for pointing that out, Rudi.
>>>>     >
>>>>     > (continued...)
>>>>     >
>>>>     > On Wed, 2020-01-15 at 09:32 -0800, Rudolf J Streif wrote:
>>>>     >> Functionality of appending and/or modifying a node from one
>>>>     branch
>>>>     >> with
>>>>     >> a node from another branch with the same signal path is already
>>>>     >> available in VSS.
>>>>     > [trimmed]
>>>>     >
>>>>     >>
>>>>     https://github.com/GENIVI/vehicle_signal_specification/commit/518dfbeb2a434c9c55ec27e06c84f6e8caf941bd#diff-4a931512ce65bdc9ca6808adf92d8783
>>>>     >>
>>>>     > That's great and shows that this thinking was there from the
>>>>     beginning.
>>>>     > That commit indeed provides an implementation that is a
>>>>     starting point
>>>>     > for the behavior that this proposal looks for.
>>>>     >
>>>>     >>> The commit message states:
>>>>     > [trimmed]
>>>>     >
>>>>     >> Now that does not cover everything from Gunnar's slides (in
>>>>     >> particular
>>>>     >> there is no wildcard support) but it's a starting point.
>>>>     > Yes.  And a few other differences that come to mind.  These
>>>>     are things
>>>>     > that might be added on top of the current model, *if* the
>>>>     layers idea
>>>>     > were adopted:
>>>>     >
>>>>     > 1) Potential for *any number of* layers. (As of now the
>>>>     private branch
>>>>     > acts as a *one* additional "layer" that can override and add
>>>>     data, as
>>>>     > you now described)
>>>>     >
>>>>     > 2) A proposal of layers as parallell files in the same
>>>>     directory tree
>>>>     > -- with different file suffix --  (it would complement the
>>>>     current
>>>>     > model that places /private as a parallel directory subtree)
>>>>     >
>>>>     > 3) The presentation hints at some additional higher level
>>>>     concepts that
>>>>     > would allow defining metadata about the layers themselves.
>>>>     > and as a corrollary it also suggests that we are effectively
>>>>     defining
>>>>     > some varying file types.  I.e. they might not be formally
>>>>     .vspec" files
>>>>     > but something else.   (The current /private "layer" does not
>>>>     explicitly
>>>>     > make a distinction, and basically assumes ".vspec" files to
>>>>     be there).
>>>>     > I'm not sure how important that is but it seemed useful to me.
>>>>     >
>>>>     >
>>>>     > Best Regards,
>>>>     > - Gunnar
>>>>     >
>>>>     > P.S. Since we are now talking about VSS specifics, I expect
>>>>     the details
>>>>     > of this will be sorted out using GitHub issues, but if it is
>>>>     in the
>>>>     > interest of the W3C participants then of course by all means
>>>>     feel free
>>>>     > to continue the discussion here.
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     > It's a great start however.
>>>>     >
>>>>     >> :rjs
>>>>     >>
>>>>     >> On 1/14/20 12:26 PM, Gunnar Andersson wrote:
>>>>     >>> As requested today, here is a link to the
>>>>     introduction/rationale
>>>>     >>> slides
>>>>     >>> for "VSS Layers".   
>>>>     >>>
>>>>     >>> A small caveat, this presentation is a work in progress and
>>>>     >>> describes
>>>>     >>> the rationale on a very fundamental level.  The idea is
>>>>     simple of
>>>>     >>> course, and very generic, because it is useful/needed in a
>>>>     whole
>>>>     >>> bunch
>>>>     >>> of areas, not only for access control even if that that was
>>>>     one of
>>>>     >>> the
>>>>     >>> driving areas.
>>>>     >>>
>>>>     >>> There of course needs to be some work to tie this into the W3C
>>>>     >>> protocol
>>>>     >>> specifics by means of examples etc.  We concluded today
>>>>     that it is
>>>>     >>> basically in line with what is needed in Ulf's recent
>>>>     >>> implementation
>>>>     >>> work as well as previous similar things that Daniel
>>>>     mentioned had
>>>>     >>> been
>>>>     >>> tried in his organization in the past, so hopefully this is
>>>>     useful,
>>>>     >>> even if it does not today provide all the concrete examples
>>>>     in the
>>>>     >>> W3C
>>>>     >>> protocol context.
>>>>     >>>
>>>>     >>> Happy to have the discussion about comparing this to previous
>>>>     >>> similar
>>>>     >>> ideas and to define more of the details.
>>>>     >>>
>>>>     >>> Thanks,
>>>>     >>> - Gunnar
>>>>     >>>
>>>>     >>> [1]
>>>>     >>>
>>>>     https://at.projects.genivi.org/wiki/pages/viewpageattachments.action?pageId=40402952&sortBy=date&highlight=VSS+composable+layers+-+draft+20200114.pdf&&preview=/40402952/47711024/VSS%20composable%20layers%20-%20draft%2020200114.pdf
>>>>     >>>
>>>>     >>> or shorter:
>>>>     >>> https://bit.ly/2TnrV05 <https://bit.ly/2TnrV05>
>>>>     >>>
>>>>     >
>>>>     -- 
>>>>     -----
>>>>     Rudolf J Streif
>>>>     CEO/CTO ibeeto
>>>>     +1.855.442.3386 x700
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Ulf Bjorkengren
>>>> *Geotab*
>>>> Senior Connectivity Strategist | Ph. D.
>>>> Mobile 	+45 53562142
>>>> Visit 	www.geotab.com <https://www.geotab.com/>
>>>>
>>>> 	
>>>>
>>> -- 
>>> -----
>>> Rudolf J Streif
>>> CEO/CTO ibeeto
>>> +1.855.442.3386 x700
>> -- 
>> -----
>> Rudolf J Streif
>> CEO/CTO ibeeto
>> +1.855.442.3386 x700
> -- 
> -----
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3386 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Received on Tuesday, 21 January 2020 17:02:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 21 January 2020 17:02:36 UTC