- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Tue, 27 Aug 2019 13:26:56 -0700
- To: Daniel.DW.Wilms@bmw.de
- Cc: ted@w3.org, mfeuer1@jaguarlandrover.com, kgavigan@jaguarlandrover.com, ulfbjorkengren@geotab.com, peter.winzell@volvocars.com, peter.winzell@jayway.com, public-automotive@w3.org
- Message-ID: <b09f6d15-3d92-7ce9-a0ed-997f5e125ca6@ibeeto.com>
Thanks, Daniel. My plan is to submit a pull request with the change to
UUID5 later this week.
Rudi
On 8/27/19 12:54 PM, Daniel.DW.Wilms@bmw.de wrote:
>
> Hi Rudolf
>
>
>
> > Hence my proposal to use uuid5 with OID which allows the uuid re-computed from the path.
>
> > That would make the database for creation of the uuid obsolete, which I think is a good
> thing.
>
> +1, sorry I misunderstood you.
>
>
>
> > We can still create the database for reverse lookup from uuid to OID.
>
> Definitely, that would be nice to have.
>
>
>
> Best regards,
>
> Daniel
>
>
>
>
>
> ---
>
> *BMW Group*
> Daniel Wilms
> Forschung, Neue Technologien, Innovationen
> E/E Architektur, Technologien (LT-3)
> Parkring 19
> 85748 Garching
>
> Postanschrift:
> 80788 München
>
> Tel: +49-89-382-60577
> Mail: daniel.dw.wilms@bmw.de <mailto:daniel.dw.wilms@bmw.de>
>
> Web: http://www.bmwgroup.com/
> --------------------------------------------------------------------
> Bayerische Motoren Werke Aktiengesellschaft
> Vorstand/Board of Management: Harald Krüger (Vorsitzender/Chairman),
> Milagros Caiña Carreiro-Andree, Markus Duesmann,
> Klaus Fröhlich, Pieter Nota, Nicolas Peter,
> Peter Schwarzenbauer, Oliver Zipse.
> Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:
> Norbert Reithofer
> Sitz und Registergericht/Registered in Germany: München HRB 42243
>
> --------------------------------------------------------------------
>
>
>
>
>
> *From: *Rudolf Streif <rudolf.streif@ibeeto.com>
> *Date: *Tuesday, 27. August 2019 at 16:40
> *To: *"Wilms Daniel, LT-3" <Daniel.DW.Wilms@bmw.de>
> *Cc: *Ted Guild <ted@w3.org>, "Mr. Magnus Feuer"
> <mfeuer1@jaguarlandrover.com>, "kgavigan@jaguarlandrover.com"
> <kgavigan@jaguarlandrover.com>, "ulfbjorkengren@geotab.com"
> <ulfbjorkengren@geotab.com>, "peter.winzell@volvocars.com"
> <peter.winzell@volvocars.com>, "peter.winzell@jayway.com"
> <peter.winzell@jayway.com>, "public-automotive@w3.org"
> <public-automotive@w3.org>
> *Subject: *Re: VSS and VIWI
>
>
>
> Hi Daniel,
>
>
>
> Correct, uuid1 is used for any parent of a node who does not have a
> uuid yet. If the tree is sorted then this will be the root node. This
> uuid1 is then used as the name space of the child node to compute its
> uuid5. Or if the parent node has a uuid5 then this one is used as the
> name space.
>
>
>
> In any case, to achieve reproducible uuid's for all nodes it relies on
> the database. If the database is not there at all or if it is not
> consistent then different uuid's get recreated. That is the same
> problem as with the original numbered id's. The only advantage over
> the original numbered id's is that with uuid's there will be no
> collision (at least mostly unlikely dependent on the hash algorithm).
>
>
>
> Hence my proposal to use uuid5 with OID which allows the uuid
> re-computed from the path. That would make the database for creation
> of the uuid obsolete, which I think is a good thing. We can still
> create the database for reverse lookup from uuid to OID.
>
>
>
> :rjs
>
>
>
> On Mon, Aug 26, 2019, 22:43 <Daniel.DW.Wilms@bmw.de
> <mailto:Daniel.DW.Wilms@bmw.de>> wrote:
>
> Hi,
>
>
>
> However, the current UUID algorithm used for VSS is uuid1
>
>
>
> I think uuid1 is just used for the first node without parent. Then
> we use uuid5. Here’s the discussion around the topic:
>
> https://github.com/GENIVI/vehicle_signal_specification/issues/102
>
>
>
> Best,
>
> Daniel
>
>
> Am 26.08.2019 um 19:29 schrieb Rudolf J Streif
> <rudolf.streif@ibeeto.com <mailto:rudolf.streif@ibeeto.com>>:
>
> As ViWi uses uuid already, why not use those from VSS
> instead of
>
> SHA256 as our hash?
>
> I used SHA256 as an example only. Any hash would work.
>
> However, the current UUID algorithm used for VSS is uuid1
> (host ID and
> time are used as a seed for the UUID, see
> https://github.com/GENIVI/vehicle_signal_specification/blob/magnusfeuer-issue-102/tools/vspec.py).
> That is actually not much of an improvement over the previous
> signal ID
> which was just a continuous integer number. The UUIDs change
> with every
> run of the generator. Switching to uuid5 would solve that problem.
>
>
> uuid.uuid5(uuid.NAMESPACE_OID, 'Vehicle')
>
> UUID('67d1ec7f-1400-5ba5-a0e1-56f3720e1514')
>
> uuid.uuid5(uuid.NAMESPACE_OID, 'Vehicle.ADAS')
>
> UUID('58719aa7-8beb-5e57-a66c-cc47a0a22eef')
>
> uuid.uuid5(uuid.NAMESPACE_OID, 'Vehicle.ADAS.ABS')
>
> UUID('82e5577f-f272-5f46-aa48-de357c78623f')
>
> uuid.uuid5(uuid.NAMESPACE_OID,
> 'Vehicle.ADAS.ABS.Error')
>
> UUID('bab61463-3a6c-5c27-a39e-753fc83d6b72')
>
> :rjs
>
> On 8/26/19 7:03 AM, Ted Guild wrote:
>
> On Wed, 2019-08-21 at 17:40 +0000, Magnus Feuer wrote:
>
> Late to the game, as per usual.
>
>
>
> JLR is engaging with the VSS-part of our effort and
> (at least
>
> currently) less with its sibling projects. We would
> prefer if the
>
> core structure of the tree, such as the strategy for
> specifying
>
> physical seat position, arrays, etc, can be stabilized
> within the
>
> coming months.
>
>
>
> Up until then I am all for changes and will do what I
> can do carry
>
> them out.
>
>
>
> As for SHA256, I humbly point you to:
>
> https://github.com/GENIVI/vehicle_signal_specification/issues/102
>
> As ViWi uses uuid already, why not use those from VSS
> instead of SHA256
>
> as our hash?
>
>
>
> From the generated JSON file:
>
>
>
> "Lateral": {
>
> "description": "Vehicle acceleration in Y
> (lateral
>
> acceleration).",
>
> "datatype": "int32",
>
> "type": "sensor",
>
> "uuid": "5c28427f79ca5fe394b47fe057a2af9b",
>
> "unit": "m/s2"
>
> },
>
>
>
> So signal ID has already been replace with a UUID.
>
>
>
> If we, in this thread, agree to change the scheme I
> will happily do
>
> the 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 Streif <rudolf.streif@ibeeto.com
> <mailto:rudolf.streif@ibeeto.com>>
>
> Sent: Wednesday, August 21, 2019 09:47
>
> To: Kevin Gavigan <kgavigan@jaguarlandrover.com
> <mailto:kgavigan@jaguarlandrover.com>>
>
> Cc: Ulf Bjorkengren <ulfbjorkengren@geotab.com
> <mailto:ulfbjorkengren@geotab.com>>; Winzell, Peter <
>
> peter.winzell@volvocars.com
> <mailto:peter.winzell@volvocars.com>>; ted@w3.org
> <mailto:ted@w3.org> <ted@w3.org <mailto:ted@w3.org>>;
> Peter Winzell
>
> <peter.winzell@jayway.com
> <mailto:peter.winzell@jayway.com>>; public-automotive <
>
> public-automotive@w3.org
> <mailto:public-automotive@w3.org>>
>
> Subject: Re: VSS and VIWI
>
>
>
> I fully agree with Kevin. It is the nature of mapping
> that some
>
> information and/or functionality is not available
> anymore. Just think
>
> geographic maps. That does not render them useless.
>
>
>
> The idea I proposed is to use a hash to encode the
> entire path from
>
> root to leaf. That is actually not that novel for VSS.
> Well, the hash
>
> is but from the beginning we had a processor that
> simply assigned a
>
> number to the nodes. Obviously the numbering is not
> that great as it
>
> can change when the table is recreated. The hash is
> much better for
>
> that.
>
>
>
> My example encoded the entire path from root to leaf.
> Ulf is correct
>
> that with that you cannot access a whole part of the
> branch anymore.
>
> But what can be done with an entire path can be done
> with any node in
>
> the path.
>
>
>
> Regardless, what Kevin says holds true, the limitation
> is the limited
>
> depth of ViWi. Accordingly it would be best to analyze the
>
> limitations and see how it can be overcome rather than
> work around
>
> it.
>
>
>
> :rjs
>
>
>
> On Wed, Aug 21, 2019, 03:48 Kevin Gavigan <
>
> kgavigan@jaguarlandrover.com
> <mailto:kgavigan@jaguarlandrover.com>> wrote:
>
> Hi,
>
>
>
> [Apologies for only engaging when debate and
> discussion are well
>
> underway]
>
>
>
> more complex VSS branch structures (depth
> more than 3, with sub-
>
> branches) will have to be represented as multiple
> 3-level VIWI
>
> branches.
>
>
>
> Believe the issue is a more general one (and the
> above is an
>
> example of the complexity that is introduced as a
> consequence of
>
> the ‘3-level limit’.
>
>
>
> If the logical (directed, acyclic) object graph
> (that is being used
>
> to represent an instance in a particular domain)
> naturally has more
>
> than 3 logical levels (which many do), then any
> specification that
>
> defines an API that assumes up to 3 levels will
> need to return data
>
> that has either been adapted in some way (e.g. as
> Rudi proposed)
>
> or will need to return a complex object graph when
> querying reaches
>
> level 3, and this complex object will require
> further parsing to
>
> obtain a value nested arbitrarily deep within the
> object.
>
>
>
> Hence same limitations and/or mapping problems
> will arise
>
> regardless of the domain that the object graph is
> concerned with
>
> (not just with VSS).
>
>
>
> So believe the 3 level limit is key here…
>
>
>
> [Didn’t mean to stir things up, just to argue that
> (imho) problem
>
> is a general one….]
>
>
>
> Regards and best wishes,
>
>
>
> Kev
>
>
>
> From: Ulf Bjorkengren
> [mailto:ulfbjorkengren@geotab.com]
>
> Sent: 21 August 2019 10:25
>
> To: Rudolf J Streif <rudolf.streif@ibeeto.com
> <mailto:rudolf.streif@ibeeto.com>>
>
> Cc: Winzell, Peter <peter.winzell@volvocars.com
> <mailto:peter.winzell@volvocars.com>>; ted@w3.org
> <mailto:ted@w3.org>; Peter
>
> Winzell <peter.winzell@jayway.com
> <mailto:peter.winzell@jayway.com>>;
> public-automotive <
>
> public-automotive@w3.org
> <mailto:public-automotive@w3.org>>
>
> Subject: Re: VSS and VIWI
>
>
>
> Rudi, I must give you credit for directly coming
> up with a
>
> technically viable alternative.
>
>
>
> However, I am not sure it is equally practically
> viable.
>
> A few examples on the top of my head:
>
> - when problems occur, the trouble shooting gets
> considerably more
>
> complex.
>
> - more complex VSS branch structures (depth more
> than 3, with sub-
>
> branches) will have to be represented as multiple
> 3-level VIWI
>
> branches.
>
> - As SHA256 is one-way, decoding a SHA256 encoded
> expression back
>
> to VSS may involve large tables to be searched.
>
> - Addressing all leaf nodes below Row4, Pos1
>
> (Vehicle.Cabin.Seat.Row4.Pos1.*) will break the
> general encoding
>
> pattern.
>
>
>
> Another problem with trying to map VSS onto VIWI
> is that the VIWI
>
> leaf nodes (elements) residing under one and the
> same branch
>
> (resource) shall be "logically equivalent" (the
> same type). As this
>
> restriction does not exist in VSS, a mapping will
> lead to
>
> confusion, or worse.
>
>
>
> In my view, a solution like this will be so full
> of compromises
>
> that it becomes a bad software solution. And we
> all know where they
>
> typically end up.
>
> My view is that the VIWI data model can be
> mapped/ported to VSS,
>
> the other way around is not possible without
> getting into
>
> "suboptimal" solutions.
>
> As it seems to me that it is not possible for the
> group to get
>
> consensus on porting the VIWI data model to VSS, I
> cannot see any
>
> other way forward than splitting the development
> up into two
>
> tracks, creating two standards.
>
> BR
>
> Ulf
>
>
>
> On Tue, Aug 20, 2019 at 11:02 PM Rudolf J Streif <
>
> rudolf.streif@ibeeto.com
> <mailto:rudolf.streif@ibeeto.com>> wrote:
>
> Hi Peter,
>
>
>
> As you say there are a couple of possible
> locations where the
>
> hash can
>
> be calculated:
>
>
>
> * Client: that could be done with a client lib
> to hide that
>
> process from
>
> the developer which is desirable
>
>
>
> * Server: as you say, if the length of the
> path is more than 3
>
> elements
>
> the server calculates the hash
>
>
>
> * Proxy: all requests are sent to a proxy
> server that computes
>
> the hashes
>
>
>
> Since I have not deployed ViWi and don't know
> what the reason for
>
> the
>
> limitation is I cannot tell what the best
> method would be (and
>
> most
>
> likely there's no one-fits-all solution).
>
>
>
> :rjs
>
>
>
> On 8/20/19 1:52 PM, Winzell, Peter wrote:
>
> Hi interesting, So that would keep the VSS
> model and we would
>
> have URIs like
> Vehicle/256Hash(x.y.z.w.u)/vssleaf_i
>
> So, then the server would keep a table of
> the hashed branch
>
> which would generate x.y.z.w.u construct the
> correct treepath
>
> down to the leaf as in this example…and
> through its internal data
>
> table match the branch with the actual vehicle
> signal and return
>
> the response. So, hiding the actual hash
> compute from the 3party
>
> developer we can do with a client API, or we
> need to add it
>
> somehow to the VIWI protocol( if long ass tree
> branch in request
>
> try hash else return some error) ? What are
> your thoughts there?
>
> Br
>
> Peter Winzell
>
>
>
>
>
>
>
>
>
> On 8/20/19, 1:26 PM, "Rudolf J Streif" <
>
> rudolf.streif@ibeeto.com
> <mailto:rudolf.streif@ibeeto.com>> wrote:
>
> Out of curiosity: what is the reason of
> the tree depth
>
> limit to 3 for
>
> ViWi? Is that a technical limitation of
> some sorts?
>
>
>
> The reason for VSS's essentially
> unlimited tree structure
>
> is
>
> extensibility. The tree can grow
> horizontally and
>
> vertically as needed.
>
> When we created VSS we found this very
> useful. We purposely
>
> tried to
>
> avoid any limitations.
>
>
>
> Another way of possibly overcoming the
> tree depth
>
> limitation and
>
> potentially providing a more automated
> way of mapping is to
>
> use hashes
>
> for the branches of the tree that are
> omitted. So for
>
> Peter's example:
>
>
>
> To replace
>
>
>
> Vehicle.Cabin.Seat.Row4.Pos1.Isbelted
>
>
>
> with a SHA256
>
>
>
>
>
> /Vehicle/103890db1712299c242c7613e0195d56bd99155dab18e1ad1477a15
>
> 2b2ab3337/Isbelted
>
>
>
> Obviously this is not human-readable
> anymore and since
>
> SHA256 is a
>
> one-way function the REST server can
> only do a comparison
>
> to check for
>
> the resource but that comparison is
> rather quick. A lookup
>
> table for
>
> reverse lookup could easily be created
> with the VSS
>
> processors.
>
>
>
> :rjs
>
>
>
> On 8/20/19 9:59 AM, Winzell, Peter wrote:
>
> Hi Ted,
>
> So, could this alternate URI be
> exemplified ? As this
>
> would keep the VSS model intact?
>
>
>
> Br
>
> Peter Winzell
>
>
>
>
>
>
>
> On 8/20/19, 5:22 AM, "Ted Guild"
> <ted@w3.org <mailto:ted@w3.org>> wrote:
>
>
>
> Regarding tree depth, one idea is
> to support
>
> alternate URIs so you can
>
> have paths that correspond to tree
> branches and for
>
> those to either
>
> transparently proxy or redirect.
>
>
>
> We remain extremely focused on
> vehicle signals, they
>
> are of greater
>
> interest for more participants than
> the other
>
> 'domains' we'll want to
>
> have in-vehicle services for. We
> want the protocol to
>
> be able to be
>
> able to accommodate them as well.
>
>
>
> On Mon, 2019-08-19 at 15:58 -0700,
> Peter Winzell
>
> wrote:
>
> Hi All!
>
> Some thoughts for tomorrows’
> meeting. Looking at
>
> the VIWI submission
>
> and the VIWI data model and how to
> keep VSS intact.
>
> For me it seems that the we would
> try to map the
>
> VSS data model
>
> against the viwi.service.car
> definition.
>
>
>
> In VIWI we have a number of
> vehicle data objects
>
> defined such as
>
> car/info. infoObjects where we are
> able to retrieve
>
> the VIN is one
>
> such object:
>
>
>
> /car/info/<vinidentifier>
>
>
>
> In VSS:
>
> Vehicle.VehicleIdentification.VIN
>
>
>
> In Vss the vin number is defined
> as the tree branch
>
> Vehicle.VehicleIdentification.VIN
>
>
>
> Vehicle — |
>
> —|
>
> VehicleIndentification
> —|
>
>
>
> VIN
>
> —|
>
> …
>
> …
>
>
>
> In this case we have two tree
> structures with the
>
> depth 3. This
>
> seems to match pretty well ?
>
>
>
> However, VIWI limits the depth of
> the tree
>
> structure to 3 , which in
>
> the following example makes VSS
> incompatible with
>
> the current VIWI
>
> data model :
>
>
>
> In VSS:
>
> Vehicle.Cabin.Seat.Row4.Pos1.Isbelted.
>
>
>
> In this case we would try to match
> this we would
>
> have to define 3
>
> more vehicle data objects:
>
> /Vehicle/Cabin/Seat
>
> - available seat objects
> would be
>
> returned by a GET
>
> request, row would be one such
> object which links
>
> to the
>
> /Vehicle/Row/Rowobjects
>
> - available row objects
> returned by a GET
>
> request. Which
>
> links to positionObjects
>
> /Vehicle/Pos/Positionobjects
>
> — Isbelted element
>
>
>
> This would keep the tree limit -
> in my view this
>
> would transform the
>
> VSS data model into something not
> VSS although we
>
> have some sort of
>
> mapping ?. The other way around is
> not possible
>
> since this would make
>
> the current VIWI model
> incompatible with present
>
> in-vehicle
>
> implementations if I understand
> correctly. So I now
>
> see us spitting
>
> the spec into two separate tracks
> where we have
>
> VISS/VSS and VIWI
>
> submitted as the W3C signal
> specification. I have a
>
> feeling that both
>
> tracks will suffer from adapting
> to each other/ and
>
> in the end we
>
> could end up with something of
> inferior technical
>
> quality. For Volvo
>
> cars we see VSS as a key element
> to the W3C
>
> submission and we want to
>
> continue this work going forward.
>
>
>
> Br
>
> Peter Winzell
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Ted Guild <ted@w3.org
> <mailto:ted@w3.org>>
>
> W3C Automotive Lead
>
> http://www.w3.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Ulf Bjorkengren
>
> Geotab
>
> Senior Connectivity Strategist | Ph. D.
>
> Mobile +45 53562142
>
> Visit www.geotab.com <http://www.geotab.com>
>
>
>
>
> --
> -----
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3386 x700
>
Received on Tuesday, 27 August 2019 20:27:31 UTC