How often are attributes allowed to change?

[erikbosch]

A vehicle might have some attributes that may change during lifetime. For example, the owner might change tire size, or gross weight might be changed for tax or driving license reasons. This is typically changes that happens at most a few times a year.

Does this fit well with our current view on attributes, that they e.g. can be specified when the vspec file is installed (see e.g. https://genivi.github.io/vehicle_signal_specification/rule_set/data_entry/attributes/)? Or should they rather be sensors if they might change during the lifetime of the vehicle.

[UlfBj]

As I mentioned in the meeting yesterday I think it is not how often the value is changed that shall decide whether it shall be an attribute or sensor, but rather the "mechanism" for its retrieval and update.

The value associated to a sensor/actuator VSS node comes from capturing the value of the corresponding sensor/actuator device.

The value associated to an attribute VSS node is typically read from "system memory".

This system memory can very well be the VSS tree itself (if the implementation supports updates of the tree). The value could then initially be set using the VSS layering tool. How subsequent updates are done I think should be out of scope for the VSS spec. In the VISSv2 reference implementation (https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl) updates will be supported via an interface that is separate from the VISSv2 interface.

[erikbosch]

I am not sure if the difference on the "mechanism" for retrieval and update needs to be that different for sensors and attributes. I guess it very much depend on your implementation and your context. I do not think that we can assume that attribute values always will be read from system memory. Could it not as well be e.g. a Diagnosis System that pushes information to the VSS-server on every start-up?

As an example, for tires it could be possible that size information in the future will be dynamically loaded by reading a RFID (see e.g. https://www.automotive-iq.com/chassis-systems/articles/radio-frequency-identification-rfid-is-coming-to-a-tire-near-you). Then a possible implementation could be a "TireManager" that reads information from the tires and publish/push it to the VSS server. The VSS-server might opt to persist the value, so it can be reused in subsequent power cycles. If the VSS-server does not get any information from the "TireManager" it use the default values specified in the vspec file.

I am thinking if we should change the documentation slightly to make it more visible that attribute values might change, maybe something like below.

https://github.com/GENIVI/vehicle_signal_specification/blob/master/docs-gen/content/rule_set/data_entry/attributes.md

Current:

The value set for an attribute by a vspec file can be read by a consumer without the need of having the value sent out by a publisher. The attribute, in effect, is configuration data that can be specified when the vspec file is installed.

Potential update:

The value set for an attribute by a vspec file can be read by a consumer without the need of having the value sent out by a publisher. Attribute values can also be provided by publishers, similar to sensors. The latter can be useful for attribute values that are likely to change during the lifetime of the vehicle.

[UlfBj]

@erikbosch , I find your argumentation and documentation proposal reasonable. Maybe one should try to further "quantify" the difference between sensors and attributes in the Potential update? Something like:

The value set for an attribute by a vspec file can be read by a consumer without the need of having the value sent out by a publisher. 
Attribute values can also be provided by publishers, similar to sensors. 
The latter can be useful for attribute values that are likely to change during the lifetime of the vehicle. 
However, this change should typically not be more than once per ignition cycle, or else it should be defined as a sensor instead.

[SebastianSchildt]

I agree with the points brought up. The distinction only makes sense, if it makes a difference in "Implementation", that is does an attribute has different behavior . Similarly to Ulf, kuksa.val also does not allow setting attributes using VISS means. (And it shouldn't because, once we allow that in VISS or other technologies, I would argue lets use "sensor" for everything and drop the "attribute" thing)

I like the suggestion that attributes do not change during an ignition cylce (and maybe also might be persisted by implementations across ignition cycles)