Type Limitations?

[jsyvanen]

Hi Community,

First time engaging here on this project, looking forward to it and thanks in advance.

The spec currently defines 4 options for the type field: sensor,actuator,attribute,branch.

I am having a hard time cleanly classifying a few different types of vehicle data into the above schemata.

• Aggregates: averages, sums, etc. defined over a time series. For example I can see that Vehicle.Powertrain.FuelSystem.AverageConsumption in the current spec is classed as a sensor type. But this seems somewhat strange: it is an aggregate calculation done over a series of readings from a sensor(s).

• Higher-Order Events: take a collision for instance. A collision is not a sensor reading, it is something that is inferred from one or more sensor readings or a series of sensor readings (eg. from accelerometer readings). I can see that a struct datatype could be helpful in creating a data definition for a collision, but none of the existing type options seem like a good fit.

Clubbing the above into the existing type of options feels strange, any guidance/feedback would be appreciated.

In my mind it raises the question of whether we should:

• add to the existing type options --> for instance it seems intuitive to me to keep sensor type reserved for point-in-time sampling of underlying values instead of as something that can/should also express things computed over time/space as in the case of an aggregation.
• publish/guide on best practices for mapping different "types" of information to the existing type options --> eg. we could say that Vehicle.Powertrain.FuelSystem.AverageConsumption is a point-in-time sensor reading from a sensor whose underlying values are a continuously updated stream of average consumption values.
• more tightly define the intended scope of VSS to exclude above mentioned "types" of vehicle data, and possibly others --> This seems unnecessary and harsh.

[SebastianSchildt]

Hi,

so for VSS a sensor describes a value a Vehicle senses/knows and that is usually consumed/read by applications or functions. It is not has no relation to a specific hardware implementation. Often there are examples where one OEM realises s fuction by putting a sensor measuring the underlying physical quantity directly, where others - or cheaper variants opt for a derived value.

So it is best to think of sensors as something that is usually read, and an actuator so ething that might also be influenced by an app or function.

But it seems this might need to be better documented. And of course as all things VSS it can bediscussed , whether this might need to be changed

[jsyvanen]

Hey Sebastian,

Thanks for that explanation. I think you are suggesting a broader definition of sensor than what is in common usage (at least outside of automotive) which typically refers to the sensing of physical phenomena as you mention. The definition you suggest gives a very broad semantic umbrella to the existing types which I suppose is good from a flexibility and initial adoption POV.

However, my fear with a liberal position on semantics of a signal as "anything that can be read/written on/by a vehicle" would be that if/when OE specific implementations start to proliferate their specific extensions and overrides it will transform what used to be interoperability challenges between OEs and/or other existing standards into interoperability challenges within the VSS standard itself. I am looking at what just such an OE specific implementation would look like now. What is the community's thinking on this? Is it a fair characterisation of a potential issue?

To continue with the simple example of AverageConsumption within the existing standard catalog I can see in FuelSystem.vspec an in-line yaml comment (not the official comment attached to the signal) which says "The period used to calculate average consumption is OEM-specific". Widespread use of that same signal label with different underlying periods for calculating AverageConsumption would I think open up a potentially difficult interoperability challenge, no?

Having a wider array of VSS types but being strict about their usage could maybe help with the above type of issue. What do you think? Or perhaps we could encode this kind of information into the VSS description or comment fields in some structured/smart way, but I feel that wouldn't be as rigorous.

Thanks in advance. Happy to discuss/contribute on this topic if the community thinks it deserves attention.

[erikbosch]

It is a recurring discussion if the terms sensor/actuator/attribute are good, or if there are some better terms. As you say, people often think of sensors and actuators as something mechanical/physical. Some has advocated to remove it all together and just call it "signal" or "data", others have proposed to use terms like "ActuableProperty" and "ObservableProperty" to indicate if it something that you as a client/app may change or just observe. This topic was briefly discussed at the last All member Meeting in October, but no conclusion. Regardless of the terms we decide to use (or not to use), I think we must discuss what purpose they serve. Are they just for information purposes or will actually implementations behave differently depending on the used value? Like if we have both "sensor" and for example "derived", would an implementation behave differently? Proposals are most welcome.

Concerning AverageConsumption - I think is a good example of how VSS evolves. Originally the informal comment was not there. When improving definition of some other signals I noticed that the signal is ambiguous but just added the informal comment. But I see this as a possible area for improvement. It would be possible to give a more specific definition, or even to add multiple signals. Then it can be discussed if we need a specific signal for displayed value.

• Vehicle.Powertrain.FuelSystem.AverageConsumptionDisplayed (The value to display, likely one of the values below)
• Vehicle.Powertrain.FuelSystem.AverageConsumptionSinceStart (Since start of current trip)
• Vehicle.Powertrain.FuelSystem.AverageConsumptionSinceTripmeterReset
• Vehicle.Powertrain.FuelSystem.AverageConsumptionLifetime (during lifetime of vehicle)

In general we are in VSS-project happy to remove ambiguity from signals, so any pull request proposing improvements in this area is welcome.

[ppb2020]

Indeed, we have been having similar discussions on "high-order events", for example related to "raw" signals (hands on wheel, eyes on road, etc.) vs. synthesized signals (driver fatigue level, driver attention level), where some of these are not physical sensor based but instead software-based. However, one can consider that even a software based signal is also a "sensor", in the sense of a synthetic sensor.

Some signals, such as Vehicle.Speed, although generated somewhere in the hardware are actually synthesized signals, (likely) based on a set of attributes such as wheel size and sensors such as wheel rotation speed. We don't seem to differentiate much between these and others. In fact, Vehicle.Speed could be made more precise by adding, say, a GPS component to the calculation, while also considering whether the vehicle's ignition is on (e.g., vehicle being towed) or sliding down an icy hill (brakes are fully on, ignition is on, but vehicle is moving).

From that perspective, it's not clear if we need to differentiate these signals based on source, given that the client application likely does not care whether the value is calculated, generated by a model, or a "raw" signal. Thus, the use of the term "sensor" is not particularly egregious to me (in fact, BlackBerry commonly uses "software sensor" and "synthetic sensor" for model-based signals).

I have some thoughts, shared in another discussion, related to model-based signals as well as other signals that do not have a strict definition, as to whether they should be part of the COVESA set of signals. It seems to me that we'd like the COVESA set of signals to have a clear and unequivocal definition, leaving the less clearly defined signals to be added as overlays, given the entity adding the signal likely has its own interpretation as to what that signal means to them. For example, it is possibly difficult to define what "driver fatigue level" is and what it means, thus this could be left for a vehicle manufacturer to add their own version of the signal given they would have their own interpretation of it.

[jsyvanen]

Hey Both,

Thanks for the insightful responses.

At least in the context of this issue I would suggest that the purpose behind any changes/additions to the signal names themselves or to the type, description, or comment fields needs to have the aim of making the VSS semantically well-defined for humans and machines alike.

From my current POV I agree @ppb2020 with your statements:

we'd like the COVESA set of signals to have a clear and unequivocal definition, leaving the less clearly defined signals to be added as overlays
given that the client application likely does not care whether the value is calculated, generated by a model, or a "raw" signal

The game of trying to keep up with semantics of novel OE specific signals won't be productive and the focus of VSS should remain on having clear semantics for a core set of signals. Those semantics can be clear even if the underling method of calculation is not fully known and/or is varied across implementations.

A follow up question though would then be as to what the intended scope of the interoperability under COVESA VSS is? Is it that:

• all aspects of VSS implementations should be interoperable with eachother (inc. their particular overlays) or
• only the standard catalog portions of the implementations should be interoperable

I think the answer is the latter? Or is it something not clearly decided by the community? If it is the latter, I think the scope of my concern in this thread is somewhat reduced. I.e. a would-be VSS implementer (like me) can take liberties in their extensions/overrides within overlays so long as the standard catalog portion of their implementation remains faithful to the pre-defined signals.

However, (and not intending to sound alarmist I am just playing out the thought) the concern the above position on interoperability raises in my mind (based on the would-be OE implementation I am currently looking at) is that if the standard catalog isn't accommodating enough to capture at least a large portion of OE signals in good faith the implementation can become more overlays than standard catalog. If we add to that a lack of conventions/standards for how overlays should be done I think VSS would have a pretty big interoperability challenge on its hands anyways. Eg. for applications it would get harder and harder to avoid dependency on signals that are in overlays which are idiosyncratic to a particular VSS implementation... and I imagine once things start down that road it is hard to reel it back in. Obviously the evolution of the VSS standard catalog by the community would be intended to prevent this state-- totally understand that, just playing out the scenario based on my current understanding.

Based the above I think something that could help is having agreed upon conventions for both the evolution of the VSS standard as well as for overlay implementations. Perhaps something like this exists in the community already in some form?

To go back and continue with the AverageConsumption example: when an application reads the value of that field the app needs to know what it means, the more exactly it knows it the better, at least in general. Granted of course that it would be infeasible to surface all aspects of the underlying implementation into the VSS node. @erikbosch the more specific signal names you mentioned would certainly help with this thank you-- I'll have a think on those.

Taking it one step further, below is just an example of how a convention for aggregations could help ensure that the signal name and type information would remain semantically well defined and transparent (without surfacing too much detail), both to humans and machines alike, and whether in the standard catalog or in an overlay.

This is just an example to get some ideas out and demonstrate the (potential) power of a convention:

• for aggregations use a new key subType eg. sensor-derived-aggregation to indicate that the signal name needs to be parsed/interpreted in a specific way.
• create a signal naming convention for aggregations. Potential inspiration source is from another (old) DDL/DML: ANSI-SQL. Aggregations are indicated by the OVER and/or GROUP BY keywords. First comes the aggregate function (avg., sum, max, etc.) then the data field to be aggregated and then the aggregation window.

The parsing/interpretation would then work like this:

• Vehicle.Powertrain.FuelSystem.AverageConsumptionOverCurrentTrip

  • First step split last placeholder string on Over keyword, first half becomes the source signal and aggregate function, and second half becomes the aggregation period.

  • Second step we then further split the first string in order to separate the aggregation method (Average) and source signal (Consumption). So @erikbosch AverageConsumptionOverCurrentTrip would be interpreted in a structured way as being composed of:

    • Source Signal: Consumption
    • Aggregation Method: Average
    • Aggregation Window: CurrentTrip

Or the above could be added as additional keys to the node explicitly, perhaps this is even easier.

If we then further added a set of standard aggregation methods and windows then defining new aggregations would be (more) consistent and semantically transparent whether within the standard catalog or in implementation specific overlays.

If this is a topic that people think warrants broader discussion I am happy to pull it out of this thread and raise it in another way.

[doganulus]

A follow up question though would then be as to what the intended scope of the
interoperability under COVESA VSS is? Is it that:

• all aspects of VSS implementations should be interoperable with eachother (inc. their particular overlays) or
• only the standard catalog portions of the implementations should be interoperable

I think the answer is the latter? Or is it something not clearly decided by the community? If it is the latter, I think the scope of my concern in this thread is somewhat reduced. I.e. a would-be VSS implementer (like me) can take liberties in their extensions/overrides within overlays so long as the standard catalog portion of their implementation remains faithful to the pre-defined signals.

However, (and not intending to sound alarmist I am just playing out the thought) the concern the above position on interoperability raises in my mind.

The implementer needs to deliver its vspec files together with their system. The standard catalog helps reduce the amount of custom definitions, providing the most common signal definitions, but it is impossible to cover every use case here. Therefore, the VSS project should avoid trying to be complete in the standard catalog.

Besides, this is how it works for Internet services using JSON Schema, for example. The service implementer provides the schema for their system. If you want to interact with that service, the schema says how to interact with it in a standard, machine-readable way. I regard the VSS project in that angle.

[jsyvanen]

The standard catalog helps reduce the amount of custom definitions, providing the most common signal definitions, but it is impossible to cover every use case here.

Yes agree and it makes sense.

this is how it works for Internet services using JSON Schema, for example. The service implementer provides the schema for their system. If you want to interact with that service, the schema says how to interact with it in a standard, machine-readable way. I regard the VSS project in that angle.

This is a very minimalistic notion of interoperability, one that I think wouldn't have any aspirations for shared semantics which VSS does. I think the project needs to be more than this... i.e. more akin to your first remark.

Eg. imagine two separate VSS implementation teams who deliver vspec files with their systems where the signal contents of their vspec files are 75% overlays implemented without any naming or other conventions applied. Such teams will still have most of the work in front of them if they want to be interoperable despite having used the VSS standard. Signal names and their descriptions will need to be interpreted manually, mapped across implementations (where possible), etc. In such a (hypothetical) scenario I feel VSS could have provided more common ground as a standard for the implementations to converge on. It is something I'll be thinking about as we progress on our current project and perhaps there will be something to contribute back and share in a while.

[doganulus]

This is a very minimalistic notion of interoperability, one that I think wouldn't have any aspirations for shared semantics which VSS does. I think the project needs to be more than this... i.e. more akin to your first remark.

I am a bit pessimistic in that regard to achieving the high levels of interoperability you have mentioned. Simply, there will be many stakeholders, different organizations, and different approaches. Forcing them to use a particular signal name/subset would be unrealistic in practice. Hence, I am more focused on a schema-like approach first.

I mean, it's nice if everyone uses the same signals, but when I look at other fields, I don't see it. For example, the standard C++ library has an implementation of std::string, but it does not prevent some others from designing/using other implementations like boost::string for valid technical reasons. This means we do not have industry-wide interoperability even for strings and this is the common case. So, when the VSS project has a standard catalog, we should expect that people/organizations will have valid reasons to use their own signal definitions. Therefore, it is good to think about what the VSS project offers for them in these cases.

[jsyvanen]

I am a bit pessimistic in that regard to achieving the high levels of interoperability you have mentioned. Simply, there will be many stakeholders, different organizations, and different approaches. Forcing them to use a particular signal name/subset would be unrealistic in practice.

Ye I understand what you are saying and indeed there is a certain ambitiousness to this and I think VSS can do a lot of good despite, but I do believe VSS could achieve more consensus on key interoperability related points which would strengthen the whole project.