-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are attributes read-only or read-write? #633
Comments
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 ( 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 |
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:
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)?
The text was updated successfully, but these errors were encountered: