- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Wed, 22 Jan 2020 07:13:19 -0800
- To: Daniel.DW.Wilms@bmw.de, mfeuer1@jaguarlandrover.com, ulfbjorkengren@geotab.com
- Cc: gandersson@genivi.org, public-automotive@w3.org
- Message-ID: <571028c9-52e0-c9eb-ec44-bc784ca1d83e@ibeeto.com>
> I disagree that it counteracts standardization. I think it’s pretty hard to foresee the correct granularity for the layers. Electric vs ICE is easy to separate as you can > dismiss entire logically connected subtrees, but number of proximity sensors, seats or doors might complicate the layer logic. I don't see why it would complicate the layer logic. It actually already works that way for modifications and additions. In general the arguments for allowing layers to add nodes are the same as the ones allowing layers to remove them. Subtraction is a complement addition. :) :rjs On 1/21/20 11:54 PM, Daniel.DW.Wilms@bmw.de wrote: > > > The entire concept of layers allow "legoization" of VSS. > > But this is only the case, if you allow new nodes through the layers. > That’s something I really would not recommend. > > > > > 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. > > > > > 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 disagree that it counteracts standardization. I think it’s pretty > hard to foresee the correct granularity for the layers. Electric vs > ICE is easy to separate as you can dismiss entire logically connected > subtrees, but number of proximity sensors, seats or doors might > complicate the layer logic. > > > > I would keep the taxonomy as is together and use its terms as > vocabulary you can choose from in your realization. At the end, each > vehicle only supports a subset of it and I don’t see the reason why > this breaks the standard. Access rights will limit the supported > subset even further. The protocol shouldn’t break if you ask > something, which isn’t there. But assuming that everything is present > is too hard of an assumption I’d say. > > > > Beste Grüße / Best regards, > > Daniel > > > > --- > > *BMW Technology Office Israel* > > Daniel Wilms > > Research Engineer > > > > phone: +972 54 34 20 806 > > mail: _daniel.dw.wilms@bmwgroup.com <mailto:daniel.dw.wilms@bmwgroup.com>_ > > > > postal address: > > BMW Technology Office Israel Ltd > > 121 Menachem Begin Road > > LABS Mailbox numbers: 93-95 > > Tel Aviv > > Israel 8067318 > > > > > > > > *From: *Rudolf J Streif <rudolf.streif@ibeeto.com> > *Date: *Tuesday, 21 January 2020 at 7:03 PM > *To: *Magnus Feuer <mfeuer1@jaguarlandrover.com>, Ulf Bjorkengren > <ulfbjorkengren@geotab.com> > *Cc: *Gunnar Andersson <gandersson@genivi.org>, W3C Public Automotive > <public-automotive@w3.org> > *Subject: *Re: VSS Layers introduction > *Resent-From: *<public-automotive@w3.org> > *Resent-Date: *Tue, 21 Jan 2020 17:02:36 +0000 > > > > 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 > > > > Image removed by sender. > > 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 > > > > Image removed by sender. > > 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 > >>> > > > -- > ----- > 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 -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700
Received on Wednesday, 22 January 2020 15:13:28 UTC