- 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