We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


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 pointDescriptionUpdate frequency
OdometerThe mileage in miles or meters24h
Name: Logbook
Purpose:Automated trip logging for business vehicles
Data pointDescriptionUpdate frequency
OdometerThe mileage in miles or metersTrip end
LatitudeVehicle latitudeTrip start/end
LongitudeVehicle longitudeTrip start/end
Name: Charging
Purpose:Services for electric vehicles
Data pointDescriptionUpdate frequency
State of ChargeThe state of charge percentageOn change
Estimated rangeEstimated electrical rangeOn change
Charging statePlugged in or chargingOn change
Charging voltageCharging procedure voltageOn change
Charging ampereCharging procedure ampereOn change
Charging powerCurrent charging power (kW)
Additional energyAccumulated additional energy (kWh)
Name: Discharging
Purpose:Services for electric vehicles
Data pointDescriptionUpdate frequency
Consumed energyTotal consumed energy (kWh)
Saved energyTotal saved energy by braking (kWh)
Name: Fleet
Purpose:Fleet owners, car rental companies
Data pointDescriptionUpdate frequency
OdometerThe mileage in miles or metersTrip end
LatitudeVehicle latitudeOn change
LongitudeVehicle longitudeOn change
Fuel levelFuel level percentage (State of Charge for EVs)On change
Name: Maintenance
Purpose:Aftermarket services.
Data pointDescriptionUpdate frequency
OdometerThe mileage in miles or meters24h
Fuel levelFuel level percentageOn change
DTCDiagnostic Trouble CodesOn change
Next serviceNext service time or remaining kilometers24h
Washer fluidWasher fluid level percentageOn change
Engine oil temperatureEngine oil temperature in Centigrades or FahrenheitOn change
Name: Parking
Purpose:Automated parking payment services and locators
Data pointDescriptionUpdate frequency
IgnitionThe ignition state, on or offOn change
LatitudeVehicle latitudeOn change
LongitudeVehicle longitudeOn change
Name: Pay-how-you-Drive (PHYD)
Purpose:Insurance services based on driving profile
Data pointDescriptionUpdate frequency
OdometerThe mileage in miles or metersTrip end
LatitudeVehicle latitudeOn change
LongitudeVehicle longitudeOn change
AccelerationVehicle accelerationOn change

API access – write

Name: Car rental
Purpose:Car rental and carsharing fleet owners
Data pointDescriptionUpdate frequency
OdometerThe mileage in miles or metersTrip end
LatitudeVehicle latitudeOn change
LongitudeVehicle longitudeOn change
Fuel levelFuel level percentage (State of Charge for EVs)On change
Door locksLock state for each doorOn change
Door positionsPosition state for each doorOn change
Lock/UnlockLocking and unlocking of the doorsWrite
Theft alarmTheft alarm stateOn change
Arm/disarmArming and disarming of the theft alarmWrite
Window positionsPosition state for each windowOn change
  • No labels

2 Comments

  1. 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.

    • It makes sense that data points are scoped with similar data points. This is used in the tree structure in VSS2 and naturally divides data points to technical categories. At High-Mobility we use the naming "Category" or "Capability" and you can see an example here of the "Charging" category with the data points within: https://github.com/highmobility/auto-api/blob/master/charging.yml
    • The Extended Vehicle ISO standard speaks about "Containers". A container is always used by a specific service for a specific purpose. E.g. a container could include the odometer data point when used by Pay-as-you-Drive insurance services. There are no specs about pre-defined containers though so it's just a collection of data points based on individual needs.
    • 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 at the OEM side, 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.

    1. Gunnar Andersson

      Thanks.  As discussed in our project meeting I will add the main ideas of this as more formal definitions on this page.

Privacy Policy | Cookie Policy