W3C home > Mailing lists > Public > public-automotive@w3.org > June 2018

Re: Auto WG 2018-06-19

From: Bartsch, Patrick, Dr. (I/EE-341) <patrick.bartsch@audi.de>
Date: Tue, 26 Jun 2018 06:37:19 +0000
To: "Streif, Rudolf" <rstreif@partner.jaguarlandrover.com>
CC: Björkengren, Ulf <ulf.bjorkengren@volvocars.com>, public-automotive <public-automotive@w3.org>
Message-ID: <022D7797-65BA-42E2-89FD-766AC507B986@audi.de>
Hi all,

Assuming we had multiple media source as described by Rudi, will these source communicate via the same interface (technology). If so, how does accident detect whether it talks to an aggregator service or a single source? If not, which technology will be used if sources are distributed over multiple devices, e.g. a main unit, a secondary unit and the cloud?

Media might not be the most relevant use case for the future as more and more people move to streaming music, but I believe Rudi and Ulf picked a good service category to tackle some distribution problems ;)

thanks guys!


Best regards,

Dr.  Patrick Bartsch
Technologie / Design MMI-Systeme
AUDI AG
I/EE-511
D-85045 Ingolstadt
Tel.: +49-841-89-766175<tel:+49-841-89-766175>
Mobile: +4915257766175<tel:+4915257766175>

patrick.bartsch@audi.de
www.audi.com<http://www.audi.com/>

Sitz/Domicile: Ingolstadt
Registergericht/Court of Registry: Amtsgericht Ingolstadt
HRB Nr./Commercial Register No.: 1
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Matthias Müller
Vorstand/Board of Management: Rupert Stadler (Vorsitzender/Chairman), Bernd Martens, Thomas Sigi, Axel Strotbek, Dietmar Voggenreiter, Hubert Waltl

Wichtiger Hinweis: Die vorgenannten Angaben werden jeder E-Mail automatisch hinzugefügt und lassen keine Rückschlüsse auf den Rechtscharakter der E-Mail zu.
Important Notice: The above information is automatically added to this e-mail. This addition does not constitute a representation that the content of this e-mail is legally relevant and/or is intended to be legally binding upon AUDI AG.


On 22. Jun 2018, at 19:04, Streif, Rudolf <rstreif@partner.jaguarlandrover.com<mailto:rstreif@partner.jaguarlandrover.com>> wrote:

Hi Ulf,

In the case of media I agree that the tree should be public next to the car tree.

I am not quite sure about the distributed server part either, however, this might be one example how this could be perceived: For media you could have many potential media sources including on-line sources. The meta-data for the media consequently will be provided by different servers. The idea of a media branch with media meta-data would exactly be that the media would be represented by the tree in a common format without the client having to know about the specifics of the source/server.

BR,
:rjs


On Wed, Jun 20, 2018 at 12:42 AM, Björkengren, Ulf <ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>> wrote:

Hi,



Thank you for the kind reception of my presentation yesterday.

I realised afterwards that maybe I did not clarify my choice of placing the rbranch/element example under the Private branch. I do not think that is the correct position in the tree, it should be in the public part of the tree. My only thought for placing it under Private was that it is a less strictly controlled part of the tree, thereby appropriate for test purposes. Also, I assume that the official tree at VSS GitHub will typically not include any element nodes under the rbranches, as they seldom will contain OEM-common data (at least not on the Media branch). In this example I wanted to show the relation between rbranch and element nodes, thus the presence of these.



Regarding the question of whether/how the distributed server concept can be handled by this, for my part I miss some details that I think may have bearing on an answer to that.

Is there any document describing how it is modelled?

Is it expected that a client will have knowledge of that the server is distributed, and address the different server parts separately, or shall that be abstracted for the client?

How does the relationship between the server parts look, are they equal peers, or is there a hierarchical relationship?

I think it is necessary to have a good understanding of how that concept is to be modelled before it is possible to try to answer how it can be handled in a VSS context.



BR

Ulf



Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A<https://maps.google.com/?q=Frederikskaj+10A+%0D%0ACopenhagen,+Denmark&entry=gmail&source=g>
Copenhagen, Denmark
volvocars.com<http://volvocars.com>

From: Björkengren, Ulf [mailto:ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>]
Sent: den 19 juni 2018 22:52
To: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: RE: [Minutes] Auto WG 2018-06-12

Hi,

Attached are the slides on my presentation in the coming meeting.

BR
Ulf


Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A<https://maps.google.com/?q=Frederikskaj+10A+%0D%0ACopenhagen,+Denmark&entry=gmail&source=g>
Copenhagen, Denmark
volvocars.com<https://emea01.safelinks.protection.outlook.com/?url=volvocars.com&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C060148865ad846c52c4208d5d626b099%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636650384809935951&sdata=HwGea4mj3%2B3Sz81vkyLPA64sH2JBgjuIDpSVgim20Qw%3D&reserved=0>

From: Björkengren, Ulf [mailto:ulf.bjorkengren@volvocars.com]
Sent: den 18 juni 2018 14:21
To: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: RE: [Minutes] Auto WG 2018-06-12


Hi,



Attached is another patch, to be applied on top of the one I previously provided.

It contains two fixes, one for taking care of element references from within an element node, and the other an attempt of updating the README.md file to reflect the addition of rbranch and element node types.

The former fix builds on formatting the references into a VSPEC list object, see in the Private.vspec file.

The latter probably needs more work to be complete. The concept of domains (or services in VIWI terminology) is introduced, but not sufficiently described. The naming of the two mentioned, Car and Media, and their node position in the VSS tree (mandatory directly under tree root?), can be discussed.



A comment not related to the above, more than it came out of my work on updating the picture in Figure 2 of README, is that in this picture signal and attribute nodes are shown mixed under a common branch, which is not the structure actually used in the VSPEC specifications, where attribute nodes are gathered under a branch node named Attribute, and signals under another named Signal.

Of these two alternative ways of including attribute nodes in the tree, I think the way shown in Figure 2 is the more elegant, eliminating the dependency between the tree structures under respective top node. However, I think to implement that in an unambiguous way, the nodes should have a mandatory attribute “role”, having one of the values “sensor”, “actuator”, or “attribute”.

But this should maybe be discussed on the VSS mail thread, and not here?



Attached is also the file containing Figure 2 in README, if you do not want to put time in applying the patch, but still want a graphical overview of the rbranch/element concept.



BR

Ulf



Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A<https://maps.google.com/?q=Frederikskaj+10A+%0D%0ACopenhagen,+Denmark&entry=gmail&source=g>
Copenhagen, Denmark
volvocars.com<https://emea01.safelinks.protection.outlook.com/?url=volvocars.com&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7Cb2001930d6a9467cee7c08d5d51620b6%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636649213389196645&sdata=X5xtUOCeQ7AoPZLGEBZwZV4TXsZBSPy6LhtvD3mKCVM%3D&reserved=0>

From: Björkengren, Ulf [mailto:ulf.bjorkengren@volvocars.com]
Sent: den 13 juni 2018 10:13
To: Streif, Rudolf <rstreif@partner.jaguarlandrover.com<mailto:rstreif@partner.jaguarlandrover.com>>; T Guild <ted@w3.org<mailto:ted@w3.org>>; public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: RE: [Minutes] Auto WG 2018-06-12


Hi,



The patch attached to this mail is my attempt to create a proof-of-concept of the idea to enhance VSS with the resource-element model from VIWI.

If you clone the latest from VSS GitHub (https://github.com/GENIVI/vehicle_signal_specification<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGENIVI%2Fvehicle_signal_specification&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C2793768778fb4089d15508d5d105c92c%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644745133618180&sdata=lYjUDsFgPgz980iWY3O%2Fyh0ps9rOdIvf46UnFl60peE%3D&reserved=0>), you can then apply this patch.



I have added rbranch and element nodes to the Private.vspec file, copying Media Collections data from VIWI.



By following the instructions in the README file in the c_native directory, you will create a c native formatted tree containing all the legacy car VSS signals, and the new nodes on the Private branch, stored in the vss_rel_1.0.cnative file in the tools directory.

The instructions also builds a tree-parser that when executed reads the vss_rel_1.0.cnative file, and creates a double linked tree in memory, allowing traversal of the tree through commands provided to the parser.



There are some glitches in this code, I have e.g. seen some strings that are incorrectly zero terminated.



The referencing from an element to other elements, which I propose to do using the “id” property of the referenced elements, are not transferred correctly to the native tree. To fix it, I think it requires further modification in the vspec.py file, to begin with.



The child property declaration in the rbranch is done using one key per property descriptor, associated to a list of values of this property descriptor for all properties. This is different from how I showed it in the earlier mail sent to the list. I do not know if this is better, but this is how I managed to solve it when coding it.



A possible next step could be to add commands to the tree parser to add/remove element nodes, and to do (simple) queries. The tree parser UI is really bad, it could be improved a bit too.



BR

Ulf



Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A<https://maps.google.com/?q=Frederikskaj+10A+%0D%0ACopenhagen,+Denmark&entry=gmail&source=g>
Copenhagen, Denmark
volvocars.com<https://emea01.safelinks.protection.outlook.com/?url=volvocars.com&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C2793768778fb4089d15508d5d105c92c%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644745133618180&sdata=80J%2FhnLKtpcfXDPFo3gut5suJiySzLxKJgVPpqpqlDY%3D&reserved=0>

From: Streif, Rudolf [mailto:rstreif@partner.jaguarlandrover.com]
Sent: den 12 juni 2018 16:48
To: T Guild <ted@w3.org<mailto:ted@w3.org>>
Cc: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Re: [Minutes] Auto WG 2018-06-12

Thank you, Ted.

Ulf and I have been discussing his proposal for VSS and bridging the gap between RSI for quite a while in email exchanges. I am on board extending VSS to support a model that allows using VSS data model and RSI data model interchangeably. VSS was intended to be simple and flexible supporting easy transformation into other data models. That's what the various converters are intended for.

Best regards,
:rjs

On Tue, Jun 12, 2018 at 7:19 AM, Ted Guild <ted@w3.org<mailto:ted@w3.org>> wrote:
https://www.w3.org/2018/06/12-auto-minutes<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2F06%2F12-auto-minutes&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C1f4e392ef92a42aa0d9108d5d073a590%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644117482390096&sdata=Bj1tYyT0aS5CSPJvXwHBIhqqmFCyCcog3fu%2B6NTKJAo%3D&reserved=0>

In particular please see and read the links from two topics both of
which we will delve into on subsequent calls.

Ulf's proposal

AGL analysis of VISS and ViWi

--
Ted Guild <ted@w3.org<mailto:ted@w3.org>>
W3C Automotive Lead
http://www.w3.org<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C1f4e392ef92a42aa0d9108d5d073a590%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644117482390096&sdata=L%2BrAFll1%2FGjfL2Q73jHukuA2N7ENO%2F4XNLToQ8tOXJs%3D&reserved=0>



--
Rudolf J Streif
System Architect
Oregon Software Technology Center

M: +1.619.631.5383
E:  rstreif@partner.jaguarlandrover.com<mailto:rstreif@partner.jaguarlandrover.com>

<image001.jpg>


<image001.jpg>
UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
US: 1419 NW 14th Ave, Portland, OR 97209<https://maps.google.com/?q=US:+1419+NW+14th+Ave,+Portland,+OR+97209&entry=gmail&source=g>
jaguar.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjaguar.com%2F&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C1f4e392ef92a42aa0d9108d5d073a590%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644117482390096&sdata=LyIJbaeowGFiUyWSCepvsZktNIu%2FwcecRuZ9gjfATBY%3D&reserved=0> | landrover.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flandrover.com%2F&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C1f4e392ef92a42aa0d9108d5d073a590%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636644117482390096&sdata=QV%2Fi2sK%2F2YM5xd5L1RNpc5DMFSE8iKlukiSZLYOHPh8%3D&reserved=0>

Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK
Registered in England No: 1672070

CONFIDENTIALITY NOTICE: This e-mail message including
attachments, is intended only for the person to whom it is addressed &
may contain confidential information. Any unauthorised review; use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies
of the original message.




--
Rudolf J Streif
System Architect
Oregon Software Technology Center

M: +1.619.631.5383
E:  rstreif@partner.jaguarlandrover.com<mailto:rstreif@partner.jaguarlandrover.com>

[https://teamtalk.jaguarlandrover.com/img/I-PACE.gif]


[http://www.jaguarlandrover.com/email/jlr.jpg]

UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
US: 1419 NW 14th Ave, Portland, OR 97209
jaguar.com<http://jaguar.com/> | landrover.com<http://landrover.com/>

Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK
Registered in England No: 1672070

CONFIDENTIALITY NOTICE: This e-mail message including
attachments, is intended only for the person to whom it is addressed &
may contain confidential information. Any unauthorised review; use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies
of the original message.


image001.jpg
(image/jpeg attachment: image001.jpg)

Received on Tuesday, 26 June 2018 06:37:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:05 UTC