RE: Gen2 ideas

Hi,
My short PPT explanation was incomplete, sorry for that.
Below you can see a randomly selected (by me) node that first is defined as a single value node, and then in the following definition is an uint8 array with five elements.

RearviewMirror.DimmingLevel:
  datatype: uint8
  type: actuator
  unit: percent
  description: Dimming level of rearview mirror. 0 = undimmed. 100 = fully dimmed

RearviewMirror.DimmingLevel:
  datatype: uint8
  elements: 5
  type: actuator
  unit: percent
  description: Dimming level of rearview mirror. 0 = undimmed. 100 = fully dimmed

I agree with Daniel that is technically possible to handle the array case with the new “position” mechanism that is introduced in VSS.
However, I am not fully convinced that is solves it in a perfect way.
To explain that, I would like to discuss the “value”:<something> key pair that is returned on a get.
My view is that for the array node I defined above the response would have the format “value”:[1,2,3,4,5] (1-5 could of course be any uint8 value).
Let us now say that the get is done on the tire pressure node that we have earlier used in the Issue thread where we discussed the positioning solution. The tire pressure “array” there is two dimensional ({left,right}, {row1, row2}). If the response has the same format as above, “value”:[1,2,3,4], I think it is a bit unclear if e. g. the pressure value 2 refers to the left/row2 tire or to the right/row1 tire. Even if this array indexing can be clearly defined, it requires that the client does some logical operations to determine it.
I believe the response above should have the format “value”: {“path.to.tire.pressure.left.row1”:1, …,“path.to.tire.pressure.right.row2”:4}
To make it unambiguous, and easy to interpret by the client.
There is also this difference that in the positioning example there is an explicit path to each element of the array, which is not the case in my proposed array definition (and where I see it only add complexity without any value to have that option).
So thus I think that we should support both ways of defining arrays.

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
Copenhagen, Denmark
volvocars.com

From: Daniel.DW.Wilms@bmw.de [mailto:Daniel.DW.Wilms@bmw.de]
Sent: den 15 maj 2019 09:30
To: rstreif@partner.jaguarlandrover.com; mfeuer1@jaguarlandrover.com; Björkengren, Ulf <ulf.bjorkengren@volvocars.com>; public-automotive@w3.org
Subject: Re: Gen2 ideas

Hi,

> Array data type: Like Magnus, I am not entirely convinced of the "elements" property.
> It might be for backwards compatibility but if "value" now in general is expressed as an
> array that would not help much. An array is not a data type on its own as it holds multiple
> elements of a certain data type. Maybe "value" should be in general treated as an array of
> the data type but the server could unpack it automatically if there is only one element in
> the array e.g. instead of returning [5], it returns 5.
After the discussion we had yesterday, I’d say the extensions [1] could serve exactly this purpose.

Best,
Daniel


  1.  https://github.com/GENIVI/vehicle_signal_specification/issues/81<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGENIVI%2Fvehicle_signal_specification%2Fissues%2F81&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C0a9c3038243d49e7816108d6d907162d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636935021794716021&sdata=hdJ5T%2Bbx3mFiXFAawQP%2F8Vd1DhJLPcqD96Q0oUEWyec%3D&reserved=0>

---
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/<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bmwgroup.com%2F&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C0a9c3038243d49e7816108d6d907162d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636935021794716021&sdata=tREjCmBb2vFaVyAiRUxGffmitSXVPBY4gJj4%2BPHZhD8%3D&reserved=0>
--------------------------------------------------------------------
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 <rstreif@partner.jaguarlandrover.com>
Date: Tuesday, 14. May 2019 at 22:16
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>, "Björkengren, Ulf" <ulf.bjorkengren@volvocars.com>, public-automotive <public-automotive@w3.org>
Subject: Re: Gen2 ideas
Resent-From: <public-automotive@w3.org>
Resent-Date: Tuesday, 14. May 2019 at 22:15

Hi Ulf,

Thanks for thinking about the next step.

I like your proposal. In regards to the slides:


  *   WS/http access restriction: I think that's a good idea. I second it.
  *   Access restriction tagging of resources: That is a good idea too.

     *   I would call the property "access" considering that the settings are "none", "write", "readwrite".
     *   I am missing "readonly" for the "access" property.
     *   For attributes which are readonly by default erroneous settings need to be addressed e.g. write or readwrite on an attribute is not allowed.
     *   Not sure why for branches the property would need to be called differently ("restricted-default"). Why wouldn't it just be "restricted" (or "access" according to my proposal)?
     *   To clarify:

        *   The branch setting would only apply if there is no explicit setting for a leaf.
        *   For branches inside of a branch aka a child-branch, the child-branch setting overrides the parent branch unless the child-branch does not specify it.

     *   Access restriction properties could be provided by OEMs in form of overlays.
     *   Probably need to call out the implicit access defaults for the different element types:

        *   Attribute: read-only
        *   Sensor: read-only
        *   Actuator: write-only
        *   Branch: none
        *   RBranch: none

  *   Array data type: Like Magnus, I am not entirely convinced of the "elements" property. It might be for backwards compatibility but if "value" now in general is expressed as an array that would not help much. An array is not a data type on its own as it holds multiple elements of a certain data type. Maybe "value" should be in general treated as an array of the data type but the server could unpack it automatically if there is only one element in the array e.g. instead of returning [5], it returns 5.
:rjs
________________________________
From: Magnus Feuer <mfeuer1@jaguarlandrover.com>
Sent: Tuesday, May 14, 2019 9:50 AM
To: Björkengren, Ulf; public-automotive
Subject: Re: Gen2 ideas


I like it.



Is there a reason for having a specified element count explicitly called out?



I can understand a max_elements count to put an upper limit on the array size, but the implementation will surely be able to figure out the number of elements that are currently stored in an array?



Regards,



/Magnus F.
-------------------
System Architect Manager
Jaguar Land Rover

Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871

[Image removed by sender. https://ci3.googleusercontent.com/proxy/OfaGrHPlawsuQPtTYPlu2XkJRCrzJtHOGv2OSrFHsvJ6km-xYenAYwOsmmC-X18PrWn7LzA6AM--8oIU05Ifg6GD=s0-d-e1-ft#http://www.jaguarlandrover.com/email/jlr.jpg]
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: Björkengren, Ulf <ulf.bjorkengren@volvocars.com>
Sent: Tuesday, May 14, 2019 5:32:38 AM
To: public-automotive
Subject: Gen2 ideas


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
Copenhagen, Denmark
volvocars.com<https://eur02.safelinks.protection.outlook.com/?url=volvocars.com&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C0a9c3038243d49e7816108d6d907162d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636935021794726030&sdata=8K4BsI2vfjwt05Bp2hnDasMDDAouNAy3m0uireYhk1U%3D&reserved=0>