JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
Page History
| Info |
|---|
November 2021 - the development of these frameworks was halted. Suggestions made to the Bosch developers to consider building on top of existing frameworks such as DAPR, that might provide similar functionality. |
Git repositories (unmaintained, see above): iot-event-analytics, vehicle-edge.
Announcement about this significant open source project creation initiated by Bosch can be found in this blog post
...
The docker compose file of vehicle edge shows the following dependencies (which order containers must be started)
Containers overview and quick references
| Container name |
|---|
Purpose
| Container image / Dockerfile | Original source code | |
|---|---|---|---|
| Hal-interface |
pipeline/Dockerfile.amd64
imported from Jenkins build server
e.g. kuksa-val-<hash>-amd64.tar.xz
mosquitto-remote
mosquitto-local
built from mosquitto/Dockerfile.amd64
Purpose of components (containers)
...
| This typically collects signals from a low level vehicle-specific signal source such as CAN bus. For each technology, a different hal interface can be provided. | ||
| Hal-interface-adapter |
...
This implements the necessary translation from the specific signal interface to the standard one used in this framework (VSS). (In CCS terms these have been referred to as "vss-feeder" components, something that feeds the system with VSS formatted data, from some source, that might not be VSS formatted, i.e. a translation occurs) | |||
| test-talent |
...
Shows an example of a "talent" i.e. a cooperating agent in the system |
...
. A talent is.... |
...
| pipeline | Main component of IOT-event-analytics? - details TBD |
...
| built from pipeline/Dockerfile.amd64 | |
| configmanager | Setting up the system together with pipelines? - details TBD Written in |
...
| kuksa-val | Keeps the current value store and sits between VSS2IOtea and the hardware-specific parts. Kuksa.VAL exposes data using the VISS protocol (v1, websocket) , but also provides other protocols like MQTT. |
...
| amd64/kuksa imported from Jenkins build server e.g. kuksa-val-<hash>-amd64.tar.xz | ||
mosquitto-remote mosquitto-local |
MQTT brokers (well-known implementation and not unique to this project). |
...
built from mosquitto/Dockerfile.amd64 | ||
| platform = ? | Only an adapter between VISS and IoTea. |
...
| built from platform/Dockerfile.amd64 | |||
| vss2iotea | built from kuksa.val2iotea/Dockerfile.amd64  |
Software Components (not always 1-to-1 mapped to a container)
| Software Component name | Provided interface | Link to source code | Programming language | Other info about framework/environment |
|---|---|---|---|---|
| (these names might need update) | (is it a library with a header file, a process exposing a socket, a REST Web API, another well defined protocol) | (important libraries/frameworks/technologies used beyond the choice of programming language) | ||
| Hal-interface | ||||
| Hal-interface-adapter | ||||
| test-talent | ||||
| pipeline | ||||
| configmanager | Javascript (Node JS) | |||
| kuksa-val | (git-repository) (releases) | |||
mosquitto | (git repository) | C | ||
| platform = ? | ||||
| vss2iotea | Javascript (Node JS) |
File/storage mappings
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:
...
Overview
Content Tools