Page History

The ecosystem supports a wide range of use cases tailored to meet the needs of various stakeholders.

1. Use case groups

1.1. Predictive Maintenance

Real-time diagnostics allow service providers and fleet managers to identify potential failures before they occur. This reduces downtime, optimizes repairs, and enhances vehicle reliability.

1.2. Personalized Insurance

Driving behavior data enables insurers to calculate premiums tailored to individual drivers, rewarding safe behavior and lowering costs.

1.3. Navigation and Traffic Management

Live location data improves route optimization, helping reduce travel time and fuel consumption. Aggregated traffic data assists city planners in reducing congestion.

1.4. Urban Planning and Sustainability

Governments and municipalities access anonymized vehicle data to plan infrastructure, optimize traffic flows, and monitor emissions.

1.5. Emergency Response

Crash and hazard alerts allow emergency services to respond faster and more accurately, potentially saving lives.

1.6. Fleet Management

Fleet operators monitor performance metrics across vehicles, ensuring cost-effective operations and compliance with maintenance schedules.

1.7 energy management

1.8. Data Marketplace

OEMs, researchers, and service providers can buy and sell data on a neutral marketplace, enabling innovation and revenue generation.

2. User Stories and Associated Tasks

2.1. Car Owners (Drivers)

Car owners (as the name suggests) own the car. They do the basic settings and onboarding activities for their car. They do not neccessarily drive the car! Data produced during the ride of a car, are produced by the driver and the driver should sit in the driver seat (perfect analogy) for the use of his data. So we will need to distinguish between them.

2.1.1. use cases

1. As a car owner, I want to onboard my car(s) to enable myself to control my produced data.
2. As a car owner, I want to control who accesses my car’s data so that I can protect my privacy
3. As a car owner, I want to review what data is accessible from others.
4. As a car owner, I want to execute my rights according to GDPR or similar laws.
5. As a driver I want to enable/disable data transfer per individual ride.
6. As a driver/car owner I want to have easy readable consent declarations and purpose definitions so that I easily can decide if I can consent to this.
7. integrate home eco-system, bigger eco-system
8. as a driver/owner I would like to see where and how my data is used

2.1.2. tasks

• Develop a user-friendly consent dashboard for granting/revoking access.
• Notify users about data usage and provide transparency logs.

2.2. Car Manufacturers and data aggregators

Car manufacturers and data aggregators are the ones that are providing the underlying infrstructure for the data collection. They pay the bill for the data collection and would like to monetize the data potentially. Let use the more generic term data aggregator for the sake of simplicity.

The European Data act require to enable customers to take care over their data. This is applicable to the raw data collected. If this data is used (if consent was granted) to build anonymous datasets, they do not fall under this regulation. Such datasets can be prepared and sold to data consumers. As a side effect on the regulation, raw data should expire in a certain time, otherwise cost will skyrocket with increasing data. (This still needs legal checks)

2.2.1. use cases

1. As a data aggregator, I want to monetize vehicle data so that I can create new revenue streams
2. To do so, I want to advertise my datasets on the platform so that the usefulness can be recognized by interested parties
3. As a data aggregator, I want to publish my terms and conditions under which I engage in a business relation on this platform
4. As a data aggregator, I require buyers to accept the terms and conditions
5. As a data aggregator I need the possibility to transfer data to a different aggregator.
6. track consent
7. different payments (recurring, one time, per case or individual contracts)
8. I would like to receive payments
9. I would like to monitor the usage

2.2.2. tasks

• Implement secure APIs for third-party data access.
• Develop a pricing model for data packages.
• Integrate payment systems for data monetization.

ACEA issued a position paper where several use cases where outlined from OEM pov. You can find it here. 

2.3. Service Providers

They are interested to create value out of the data and build business models and valuable use cases for multiple customers. They need access to data to fulfill their promise.

2.3.1. use cases

1. As a service provider, I want to access vehicle diagnostics data so that I can offer predictive maintenance
2. As a service provider, I want to search in all datasets, based on criteria, to find datasets, that are useful for my current work
3. As a service provider I want to onboard a new service with it's data requirements and have an agentic search for matching datasets introduced.
4. As a service provider, I want to publish data specifications to interested parties so that I can get specific datasets which I require for my current work.
5. I would like to have a contact responsible for the data set

2.3.2. tasks

• Create APIs for requesting diagnostic and real-time vehicle data.
• Ensure data requests comply with user consent and SLAs.

2.4. Regulators

2.4.1. use cases

As a regulator, I want to audit data-sharing activities so that I can ensure compliance with laws

2.4.2. tasks

• Maintain tamper-proof logs of all data transactions.
• Provide reporting tools for regulators to analyze data usage.

2.5. Developers

2.5.1. use cases

As a developer, I want access to sample datasets so that I can prototype innovative applications

2.5.2. tasks

• Provide sandbox environments with anonymized datasets.
• Document APIs and offer technical support for integration.

Consent cases

W3C has already started the collection of consent cases. We use this as a starting point and build on this. It can be found here.

Use cases are vital to understand the interaction between the members of the ecosystem. For every required interaction services and orchestration will need to map this use cases to state changes in the ecosystem.

user use cases

The following diagram shows a subset of possible interactions between the members of that ecosystem. The diagram is not complete and serves illustrative purposes only. During the project, this diagram should become complete.

Image Removed

use cases - communication centered

There are various use cases someone can think of. The idea is to collect them and group them around how the data access must be organized to generate the value out of it.

1. "ghost driver warning" all cars in the vicinity of the "ghost driver" shall be warned
2. road block ahead - same as above
3. weather/road condition warning - is not as immediate as the use cases above
4. driving behaviour statistics
5. ...

For different use cases different access methods to the data must be available.

emergency broadcast

The immediate (low latency) warning must be triggered by car2car or car2x as a broadcast, receivers determine their position to determine the correct reaction.

Additionally should the cloud be used to broadcast the data to a broader audience as a warning.

weather warnings, data collection ...

The higher latency data access should be relayed via the cloud and distributed from there to preserve bandwith.

single use cases

The following use-cases will be required (open list):

1. OEM onboarding
2. service provider onboarding
3. data source onboarding
4. service onboarding

In the OEM cloud we assume the following:

1. a managed set of cars
2. a managed set of users and drivers
3. a mapping from user/drivers to cars
4. a consent registry and
5. storage of consent data

In the service provider cloud we assume the following

1. a managed set of users
2. a managed set of subscriptions
3. a mapping from services to subscriptions and users

This represents the initial thoughts on this ecosystem. Over the time new requirements may evolve.

car owner onboarding (OEM cloud)

In this use case the car owner registers his car in the manufacturers cloud. This step is required to allow mapping from users to a car. Also it is required because users must provide consent to data collection for a purpose, not cars! Usually done at the car dealer. There can be multiple users for a car, managed in profiles probably. For data collection all users need to consent.

Image Removed

service user onboarding (3rd party service provider ecosystem)

A car owner registers himself for the use of the service. The service provider needs to onboard the user in his ecosystem and link the user and his car to the car manufacturers cloud environment. The following figure describes the flow.

Image Removed

service user onboarding (OEM cloud, direct car access)

service user onboarding (OEM cloud, indirect car access)

service onboarding (OEM cloud)

A new service requires an onboarding as well. Differences between service offerings may require changes in the contracts as well. To access more data, will require customers consent and the ccapability of the OEM cloud to provide the data.

The service provider will have to provide all the required data, add requested datapoints and billing information (and others).

car manufacturer onboarding (hosted)

...