Are attributes read-only or read-write?

[ppb2020]

Some attributes in VSS, such as Vehicle.VehicleIdentification.KnownVehicleDamages need to change at some point. The documentation on attributes mentions one way in which this can happen: upon an ignition cycle, a new value may be generated.

I can see three ways in which attributes can be updated:

1. New value generated (just like sensors, assuming some component in the vehicle is tracking this information and generates it upon each ignition cycle).
2. New default value (re-download of the full signal catalog to the vehicle).
3. Writing to the attribute (just like actuators).

The documentation does not cover all these cases. Should it? For example, should it mention attributes can be written to (and thus that permission control on writing to the attribute needs to be addressed by the implementation)?

[erikbosch]

As of today I do not think we say that much in VSS documentation itself on how attribute values themselves are updated. I think that historically have assumed that attribute values are read by the server at startup only, typically from default values in the VSS spec it loads. But as you say there multiple other ways they can be populated, and in my opinion the distinction between attribute and sensor is not always that clear.

If one look at API definitions and implementations they have partially different scope. VISS as an example focus on the "northbound" interface and how values get populated is out of scope. So they say that Only actuator type signals can be updated..

KUKSA.val on the other hand supports both "northbound" and "southbound" interface, and has two distinct set-operations, one to set actual value (setValue in kuksa-client CLI) and one to set target value (setTargetValue in kuksa-client CLI), and there it is possible to use setValue for all types of signals, but setTargetValue only for actuators. Access control can differentiate between setting target value and actual value. That opens for the possibility that it for example is the diagnostics subsystem that provides the Vehicle VIN to the VSS server at system startup using the setValue operation.

I definitely think we should write something more on how you can set/update attributes. It should however not necessarily be part of the core VSS spec itself but possibly part of some deployment/architecture guidelines/documents, and it might be relevant to consider when defining a VehicleAPI.

Then there is a different topic - does the distinction between attributes and sensors still make sense, or would it be better to just use a common term like Readable. We say in https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/attributes/ that an attribute has a default value, but are we really sure that is always the case. Taking VIN as example, can it be assumed that a VSS server implementation actually has a static VIN it reads during startup from a config file, or may it rather be so that it is the diagnostics system that keeps the value and the VSS server either poll it at start or the diagnostics system pushes it to the VSS server.