JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
This template should be used to implement the majority of the services, there might be exceptions that are not known yet.
The following table gives an overview which services are required.
Service name | description | implementation status |
---|---|---|
user service | this is a crud-service whicht maintains the user base for the whole eco-system. It allows user to onboard, change data and be deleted. It requires a database to store the data permanently | |
right management | this right management deals only with the right of the users of the system. Not the cloud management. | |
identity federation | this is used to enable login with a foreign identity (like gmail, facebook). The user identity is matched to an internal id. | |
data store service | is a crud service that allows the management of a data source. | |
data source management | This is a crud service to onboard a data source. This can be a car or another IoT device. These sources needs to be linked with an individual (the owner) and the corresponding data store usually the manufacturer owns. | |
registry | is used to register components of the system (nodes and services) and is used for runtime resolution of requests | |
audit trail | legal compliance needs proof. This service writes an audit trail of events that can be used in trials as a proof | |
usage service | this service simply counts the usage of resources as a metrik. This can be used for billing later. | |
billing | based on usage and negotiated rates, a monthly bill can be generated. | |
monitor | this service monitors the system and based on thresholds will trigger alarms or countermeasures | |
logging | this services receives log messages from all services (per node) and will store them within the node |
As for all µ-service based architectures it is important to cut the services in a way that on one hand the
size of the service stays maintainable but on the other hand that they are not too simple (too many services).
A concept called orchestration makes out of the services a workflow. For example, if a user from the type of a
data collector is onboarding the orchestrator will ask to onboard a data source as well. These workflows
will be described in the following sections.