Separated signals for actual and target values? about vehicle_signal_specification HOT 5 OPEN

MoM: Quickly presented at meeting

from vehicle_signal_specification.

Some more aspects - on Actuator/Sensor/Attribute and how they currently are used in implementations

VISS

VISS API is intended only for the "northbound" connection for a VSS server. You can only "update" actuator signals, and it clearly states that if you do a "read" you will get current value (not target value) for an actuator.

Eclipse Kuksa

Kuksa has support to specify if a write or read concerns target value or current value and manages for actuators two values internally.

This brings up an interesting aspect - what value does the current actuator/sensor/attribute categorization serve? As of today it can as seen above be used to control which operations/methods you allow/support on a specific API, and if you should handle it as a "single" or "dual" value internally in the implementation. Historically we have sort of assumed that it is northbound interface that sets the wanted value (like "IsLocked=False") and the southbound interface that reports the actual value, but that may not always be correct. One could for instance imagine that it actually is the backend (i.e. northbound interface) that calculates time to service (Vehicle.Service.TimeToService) and sends it to the vehicle. That signal is today a "sensor" and cannot be set using VISS. I would not really call it an actuator either, as it does not actuate anything.

So would it possibly be better to consider the old designations as legacy designations, and in addition add a new one that just says it is a datapoint with a single value which by default should be accessible with read+write requests

A.B.C:
  type:  datapoint
  datatype: uint8

In an overlay one could possibly then specify alternative access, adapted to current implementation for a specific API. Like if you do not want an API to present a write-method or deny write requests an overlay like below could be used.

A.B.C:
  type:  datapoint
  access: r 
  datatype: uint8

from vehicle_signal_specification.

MoM:

• Stefan: Thinks useful, like cruise control, target speed and target distance, we may not be able to achieve both
• Ulf: If we decide to have different values for target+current, then we shall have name rules, have a postfix added, like Vehicle.Speed (sens) and Vehicle.SpeedTarget (actuator)
• Erik: Taking SpeedRequest/SpeedTarget, that is not a "classic" actuator.
• Ulf: needs consideration to change, the term "actuator" has existed for long. legacy naming.
• Daniel: Something like this could be added in model. You may have button, knobs. We can have a vocabulary for actuators, no limitation adding metadata
• Erik: Conclusion that we in general are positive to having separate signals. We (Bosch) will come back with a PR using this approach for some new signals.

from vehicle_signal_specification.

Let me mention a few relevant points:

• I would not simply call it adding new signal(s), as the term can be misleading.
• In my opinion, VSS is currently a collection of vehicle properties, where:

Property: A quality of an entity. An aspect of an entity that is intrinsic to and cannot exist without the entity. source: SSN ontology

• In a practical implementation, the actual value associated with such a property can be..
  • .. read (i.e., vss type: sensor). Making it a so-called ObservableProperty
  • .. read and written (i.e., vis type: actuator). Making it a so-called ActuatableProperty

With that said, I would like to point out that a property and the value of it at a particular time are two distinct things.
As you know, the actual value is not specified in VSS because that comes later in a real implementation and with instance data. Handling the difference between the target value and the current value for a property may be better suited at the API level, rather than within the hierarchical data model itself.

For example, the VSS specification could describe the property someContext.sunroof.position with a simple integer datatype, while the API would provide methods to set the target position, retrieve the current position, and handle any changes or events related to the sunroof position.

from vehicle_signal_specification.

MoM:
Stefan: can you elaborate
JD: read/write for non-safety critical signal(s) -> observe value while its moving (example seat position) -> vss does not have control over target and actual value. TL,DR introduce field to values instead new signal(s)

from vehicle_signal_specification.