- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Mon, 26 Aug 2019 09:26:48 -0700
- To: ted@w3.org, Magnus Feuer <mfeuer1@jaguarlandrover.com>, Kevin Gavigan <kgavigan@jaguarlandrover.com>
- Cc: Ulf Bjorkengren <ulfbjorkengren@geotab.com>, "Winzell, Peter" <peter.winzell@volvocars.com>, Peter Winzell <peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org>
- Message-ID: <f19b8088-41f1-f2ee-5541-0c182c4266be@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]
>>> 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 Monday, 26 August 2019 16:27:15 UTC