Open erikbosch opened 4 months ago
MoM: Quickly presented at meeting
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
MoM:
Let me mention a few relevant points:
signal(s)
, as the term can be misleading.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
type: sensor
). Making it a so-called ObservablePropertytype: actuator
). Making it a so-called ActuatablePropertyWith 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.
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)
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.
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 caseStateOfCharge.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 likeSubsystemValueTarget
(actuator) andSubsystemValueActual
(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