Separated signals for actual and target values?

[erikbosch]

By tradition VSS consider that "actuators" have two values - target-value and actual-value, this is described at https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ . An example signal is shown below, you can access both actual seat height and wanted seat height by the signal.

Height:
  datatype: uint16
  type: actuator
  min: 0
  unit: mm
  description: Seat position on vehicle z-axis. Position is relative within available movable range of the seating.
               0 = Lowermost position supported.

In some cases this dual nature is no problem - like when changes are instant or you actually do no really differentiate between actual and target value, like IsDomeOn for lights where the actual value likely represent target value rather than whether the dome light actually is lit or not.

We have some examples in VSS where we have "pure" target values like Charging.ChargeLimit where the actual value is visible by some other signal (in this case StateOfCharge.Current). In this one can argue that the connection between them is a bit vague, like there is no "physical" actuator as in the seat example. We have similar constructs for HVAC temperature, gear box and cruise control.

We are currently discussing internally a use-case where it could make sense to have separated signals as that could avoid some ambiguities and reduce the risk of that someone reads/writes the wrong value, like reads current value rather than target value. I.e. instead of having just something like SubsystemValue (actuator) instead having something like SubsystemValueTarget (actuator) and SubsystemValueActual (sensor)

I am creating this issue to start a generic discussion on when we see having two signals is acceptable or even recommended, and in which cases we see that using the dual nature of actuators as sufficient/recommended. If we see using two signals as acceptable/recommended in some scenarios - should we then possibly have a recommended pattern like <name> [ Actual | Target]

Do we possibly need (in VSS or in downstream projects) a notation that indicates if a signal has two values (target+actual), or just one (like sensors, but also actuators only handling target values). An example below:

Vehicle.Cabin.HVAC.Station.Row1.Driver.Temperature

This is an actuator in VSS that is intended to be used to handle the wanted temperature as defined by the user. But it is not well defined what the "actual" part of the signal actually should contain. Should it always be the same as target value, or should it represent the temperature of the air currently emitted by the HVAC, which might be cooler/hotter than target value trying to achieve/keep target value. Would it beneficial to be able to separate the two types of actuators, possibly like below

Vehicle.Cabin.HVAC.Station.Row1.Driver.Temperature:
  type: actuator
  actuator-type: single # Actual value refers to Target value

Vehicle.Cabin.Seat.Row1.Middle.Height:
  type:  actuator
  actuator-type: dual # Default, Actual value and Target Value may be different.

[erikbosch]

MoM: Quickly presented at meeting

[erikbosch]

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

[erikbosch]

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.

[jdacoello]

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.

[nwesem]

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)