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> 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>:
>
> 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
>
> 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>
>
> Sent: Wednesday, August 21, 2019 09:47
>
> To: Kevin Gavigan <kgavigan@jaguarlandrover.com>
>
> Cc: Ulf Bjorkengren <ulfbjorkengren@geotab.com>; Winzell, Peter <
>
> peter.winzell@volvocars.com>; ted@w3.org <ted@w3.org>; Peter Winzell
>
> <peter.winzell@jayway.com>; public-automotive <
>
> 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> 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
> <ulfbjorkengren@geotab.com>]
>
> Sent: 21 August 2019 10:25
>
> To: Rudolf J Streif <rudolf.streif@ibeeto.com>
>
> Cc: Winzell, Peter <peter.winzell@volvocars.com>; ted@w3.org; Peter
>
> Winzell <peter.winzell@jayway.com>; public-automotive <
>
> 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> 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> 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> 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>
>
>    W3C Automotive Lead
>
>    http://www.w3.org
>
>
>
>
>
>
>
>
> --
>
> Ulf Bjorkengren
>
> Geotab
>
> Senior Connectivity Strategist | Ph. D.
>
> Mobile     +45 53562142
>
> Visit     www.geotab.com
>
>
>
> --
> -----
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3386 x700
>
>
>

Received on Tuesday, 27 August 2019 14:40:51 UTC