JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
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. |
Announcement about this significant open source project creation initiated by Bosch can be found in this blog post
This page collects detailed information about the IoT-event-analytics and Vehicle-Edge projects to explain the different components they are made up of so that, together with other components, we can build a full map for the desired CVII Technology Stack.
The projects implement a high-level vehicle data abstraction strategy as follows:
The framework's main purpose is to allow vehicle applications to communicate with each other, and with vehicle platforms, using a common data model, here implemented with the VSS.
The abstraction layers of app to platform in more detail:
The platform is useful for processing data before it is transferred to cloud infrastructure, thus being part of an edge-processing strategy. The vehicle is then considered an edge device.
IoT-event-analytics (a.k.a. IOTea) implements an event processing and agent network platform. It orchestrates the flow of events between communicating agents (Talents) where the business logic of that interaction can be programmed using several different languages.
Vehicle Edge sets up a complete software stack around IOT-event-analytics by adding services such as an MQTT broker, and other components. Vehicle-edge uses containers to set up a network of communicating parts.
The docker compose file of vehicle edge shows the following dependencies (which order containers must be started)
For convenience, each container maps a config file or directory to a location in the host file system, so that the configuration can be conveniently edited.
With few exceptions, each container only sees its own config location and do not share any storage:
A starting example of all configurations is provided.
Interfaces
From the fact that these components are executing in different container namespaces and do not share storage, we can derive(?) that interaction between the parts are all using network protocols.
More analysis is required on what APIs are provided by each and how communication occurs:
Kuksa.VAL exposes the VISS protocol and this is the main "API" for others to interact with Kuksa.VAL
TODO: Determine the (network?) protocols. Specifically, what functionality does each component provide and consume?
And which component communicates with which other one?