Use cases

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.

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.

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.

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)

car manufacturer onboarding (self hosted)