Use cases

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)