In order to drive discussions on security / access control, sensitivity in terms of privacy, and many other aspects, it is important to be able to categorize vehicle data in groups (including multiple and overlapping views / filters / layers). Analysis of this activity is started on this wiki page
In the GENIVI Technical Summit (November 2019), it came to discussion, how different vehicle datasets could be defined in order to provide OEM guidelines.
"To define datasets that can be provided for specific purposes/use-cases to have consistent coverage from OEMs (bundling of data per use-case)"
It should be kept in mind that different services have different data needs, and might need an expanded dataset in order to function. Still, sorting data points into different bundles makes the data use cases clearer compared to listing individual data points. Apart from these first data bundles, we should also consider different categories based on data sensitivity, privacy and regional laws.
Proposed Definitions
- Data Category = Data that belong together as part of a common technical scope.
In the tree structure of VSS we see this natural subdivision using branches. In VSS a lot of the structure is mirroring the physical structure of a car, but occasionally other things like the organisational structure of automotive development companies or other divisions have also been influencing the category hierarchy. Categories could include larger groups that share a particular common characteristic, e.g. "Privacy sensitive data". - ExVe Container = Grouping together previously unrelated data for a new purpose or to support a certain function or use-case (which suggests that ExVe Container definitions are frequently created, possibly short-lived, possibly locally defined, etc.) The Extended Vehicle ISO standard speaks about "Containers" for this purpose. We prefix the term with ExVe because "container" is a very frequent and overloaded term.
- Example: A pay-as-you drive insurance application may need approximate positional data (approximate for privacy) and the odometer data and some engine usage parameters. Those would normally
- Such containers could also group together data that affect access permissions, or a logical group of information that a user gives consent to share.
Most services need data points from across different technical categories. E.g. a service might need charging.state_of_charge and engine.oil_temperature. It could be said that they need to access two different data categories. It could also be said that they need to access a "Container" that includes these two different data points. To build up consistency inside companies, but also across, it makes sense that common use-cases have pre-defined containers. These are typically called "Data bundles" or "Data buckets", which is like a template of a container that has other meta information attached to it like purpose of use, pricing and rate limits.
(When we speak about transferring measured values that are bundled together, note the related definition of a Snapshot)
Example Categories and Containers:
Personalised vehicle data – read-only
Name: | Pay-as-you-Drive (PAYD) |
Purpose: | Insurance services based on the vehicle mileage |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | 24h |
Name: | Logbook |
Purpose: | Automated trip logging for business vehicles |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | Trip end |
Latitude | Vehicle latitude | Trip start/end |
Longitude | Vehicle longitude | Trip start/end |
Name: | Charging |
Purpose: | Services for electric vehicles |
Data point | Description | Update frequency |
State of Charge | The state of charge percentage | On change |
Estimated range | Estimated electrical range | On change |
Charging state | Plugged in or charging | On change |
Charging voltage | Charging procedure voltage | On change |
Charging ampere | Charging procedure ampere | On change |
Charging power | Current charging power (kW) |
|
Additional energy | Accumulated additional energy (kWh) |
|
Name: | Discharging |
Purpose: | Services for electric vehicles |
Data point | Description | Update frequency |
Consumed energy | Total consumed energy (kWh) |
|
Saved energy | Total saved energy by braking (kWh) |
|
Name: | Fleet |
Purpose: | Fleet owners, car rental companies |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | Trip end |
Latitude | Vehicle latitude | On change |
Longitude | Vehicle longitude | On change |
Fuel level | Fuel level percentage (State of Charge for EVs) | On change |
Name: | Maintenance |
Purpose: | Aftermarket services. |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | 24h |
Fuel level | Fuel level percentage | On change |
DTC | Diagnostic Trouble Codes | On change |
Next service | Next service time or remaining kilometers | 24h |
Washer fluid | Washer fluid level percentage | On change |
Engine oil temperature | Engine oil temperature in Centigrades or Fahrenheit | On change |
Name: | Parking |
Purpose: | Automated parking payment services and locators |
Data point | Description | Update frequency |
Ignition | The ignition state, on or off | On change |
Latitude | Vehicle latitude | On change |
Longitude | Vehicle longitude | On change |
Name: | Pay-how-you-Drive (PHYD) |
Purpose: | Insurance services based on driving profile |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | Trip end |
Latitude | Vehicle latitude | On change |
Longitude | Vehicle longitude | On change |
Acceleration | Vehicle acceleration | On change |
API access – write
Name: | Car rental |
Purpose: | Car rental and carsharing fleet owners |
Data point | Description | Update frequency |
Odometer | The mileage in miles or meters | Trip end |
Latitude | Vehicle latitude | On change |
Longitude | Vehicle longitude | On change |
Fuel level | Fuel level percentage (State of Charge for EVs) | On change |
Door locks | Lock state for each door | On change |
Door positions | Position state for each door | On change |
Lock/Unlock | Locking and unlocking of the doors | Write |
Theft alarm | Theft alarm state | On change |
Arm/disarm | Arming and disarming of the theft alarm | Write |
Window positions | Position state for each window | On change |
2 Comments
Unknown User (kevinval)
Gunnar Andersson and Unknown User (benjamin_klotz) here's my thoughts on naming conventions. I'll use "data points" as the wording which would mean "signal" or "attribute" in VSS2 terms.
First off I think we need to distinguish between technical categorisation of data points and categorisation based on purpose.
Gunnar Andersson
Thanks. As discussed in our project meeting I will add the main ideas of this as more formal definitions on this page.