RE: VSS and VIWI

Hi All,

I would like add my 2 cents to the discussion (that got side tracked to the use of UUID-v5 :-) and offer a different way of looking a the "ViWi"  tree depth, by just saying that in the context of gen2 it should not be viewed as a hard limitation of the total tree depth. If you keep in mind that ViWi is connected to the notion of a micro-service offering resources in a RESTful manner, then the only thing we care about is that:

There should be a "service-like-subtree" that represent a service (root of the subtree) (I think in VSS speech this would be -- a branch?) under which resources are exposed (an RBRANCH where children can dynamically be added or removed i.e. this part of the tree cannot be statically defined, only the common type used the be leaves can). The additional challenge that these "RBranch"-es  will need array/slice-like addressing capabilities and different subscription semantic.

So by introducing a "SBRANCH" , an entity that can host only RBRANCH nodes we have a way of describing something very Viwi like, using the same rules as are used to described VSS.

If a signal in VSS is cabin.door.row1.right.locked.value then a "viwi style item" would be cabin.infotainment.mediaservice.tracks.{insert uuid of your favourite track here} or cabin.infotainment.mediaservice.tracks.[1-20] and the payload received would be complex object ( a set of property) or a list of said objects. You could also go as far as cabin.infotainment.mediaservice.tracks.{insert uuid of your favourite track here}.title but in that case you would also have to assign a uuid to each title property and this is just overkill, so cabin.infotainment.mediaservice.tracks.{insert uuid of your favourite track here}#title would actually be better. Plus some metadata to get the item count (cabin.infotainment.mediaservice.tracks#count)

Basically the location of the SBRANCH  in the tree doesn't matter, what matters is that below this node you have a guaranteed tree-depth of 2, consisting of only of RBRANCH(es) + Children

The other thing that would be useful is that the SBRANCH cabin.infotainement.mediaservice could offer a direct access end-point (here I am re-using Ulf's concept of stream source) so that one could choose to access it through a global gateway or directly (so as to not overload the gateway).

All the UUID-V5 generation discussion still applies, up to the children of an R-Branch where the uuid generation procedure needs to be adapted to particular nature of the child (for example a child OID would be a uuid-v5 derived from the R-Branch OID and an internal unique identifier and it would only guaranteed to be unique on a running system and not on all systems, contrary to the other signal OIDs)

With Gen2 I thought that it would be useful to crank it up a notch with the remote branch concept(where any sub-tree can be a candidate for direct access) but maybe our description in the pull request missed the mark. 

Best regards,
Laurent

-----Original Message-----
From: Peter Winzell <peter.winzell@jayway.com> 
Sent: 20 August 2019 00:58
To: public-automotive <public-automotive@w3.org>
Cc: peter Winzell <peter.winzell@volvocars.com>
Subject: VSS and VIWI


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

Received on Wednesday, 28 August 2019 07:16:47 UTC