- From: <Daniel.DW.Wilms@bmw.de>
- Date: Tue, 27 Aug 2019 19:54:00 +0000
- To: <rudolf.streif@ibeeto.com>
- 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: <9506CD7F-8574-4D27-8D84-2BDF1D922A5C@bmw.de>
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 19:54:29 UTC