The recommended signals list will have two sampling guidelines, curve based with error threshold parameter and event/time/distance based. Variation of vehicle architectures will likely lead to even different sampling conventions used, for instance the accuracy of a sensor may be lower than a measurable threshold or broadcast rate lower than desired sampling frequency for time based.
This suggests we need to be able to represent the alternatives in both the guidelines and the collected data results as metadata.
In the guidelines we can either have two or more different directives
Example:
We want Vehicle.Powertrain.CombusitionEngine.Speed (RPM) ideally collected with some smart (curve logic) to detect and notify about significant change in data point or every 30 seconds.
In an overlay for this signal we can add either one or two name/value parameters.
Vehicle.Powertrain.CombusitionEngine.Speed:
datatype: uint16
type: sensor
unit: rpm
description: Engine speed measured as rotations per minute.
sampling: +-1500; 0.033Hz
Semi-colon separation can be used similar to language and content negotiation HTTP headers (text/html; text/plain) where the client's preferred order is given and the system responds based with what it has as content or capability.
Alternately we can split over multiple lines.
curve-sampling: +-1500
sampling: 0.033Hz
Knowing how the data was collected should be relayed back to the cloud server, at least once - the first time the vehicle sends a sample to that server or upon change. YAML, JSON or other representation of VSS less uncessary metadata not expected to vary from the VSS definition such as type, unit, description, datatype can be relayed to the server.
The recommended signals list will have two sampling guidelines, curve based with error threshold parameter and event/time/distance based. Variation of vehicle architectures will likely lead to even different sampling conventions used, for instance the accuracy of a sensor may be lower than a measurable threshold or broadcast rate lower than desired sampling frequency for time based.
This suggests we need to be able to represent the alternatives in both the guidelines and the collected data results as metadata.
In the guidelines we can either have two or more different directives
Example:
We want Vehicle.Powertrain.CombusitionEngine.Speed (RPM) ideally collected with some smart (curve logic) to detect and notify about significant change in data point or every 30 seconds.
In an overlay for this signal we can add either one or two name/value parameters.
Vehicle.Powertrain.CombusitionEngine.Speed: datatype: uint16 type: sensor unit: rpm description: Engine speed measured as rotations per minute. sampling: +-1500; 0.033Hz
Semi-colon separation can be used similar to language and content negotiation HTTP headers (text/html; text/plain) where the client's preferred order is given and the system responds based with what it has as content or capability.
Alternately we can split over multiple lines.
curve-sampling: +-1500 sampling: 0.033Hz
Knowing how the data was collected should be relayed back to the cloud server, at least once - the first time the vehicle sends a sample to that server or upon change. YAML, JSON or other representation of VSS less uncessary metadata not expected to vary from the VSS definition such as type, unit, description, datatype can be relayed to the server.