The intent of the proposed Eclipse Leda Incubator is to foster collaboration in the Eclipse Software Defined Vehicle (SDV) ecosystem, and hopefully results in work proceeding to contribution by their original authors into upstream projects. The Eclipse Leda Incubator would not make any releases itself.
The Eclipse Leda Incubator project hosts software-defined vehicle components which are fitting into the general Eclipse Leda scope, but do not fit to either being part of Leda itself, which should be upstreamed into other projects in the future, or which are still highly experimental and should not be considered for any kind of production use.
Eclipse Leda Incubator provides a place for experimental components from the software-defined vehicle ecosystem.
While the software defined vehicle ecosystem is starting up, new ideas for software components emerge and should be experimented with by the community.
The goal of Eclipse Leda is to integrate SDV components into a ready and defined quickstart image, to be able to show case certain higher-level use cases on a base ground. At the same time, the development community needs a way to try out experimental components in the same way, but without interfering with the stable release cycles of the parent project.
All components mentioned in the initial contribution are already implemented and ready for contribution.
Robert Bosch GmbH
ETAS GmbH
The initial contribution contains the following experimental components:
-
Self Update Agent (SUA) is a software component responsible for performing system-level updates. Underneath it is using the RAUC framework via D-Bus calls, but it is designed in a way that switching to other updating solution shall be possible. SUA may be controlled by an external higher-level orchestration component via defined MQTT messages, which carry necessary for update data, such as version and URL of the update bundle. Update process feedback and the end result are also communicated via defined MQTT messages. Software Update Agent is implemented in C++ and configured to be running inside of a container.
-
OpenTelemetry Collector for Leda: An OpenTelemetry Collector offers a vendor-agnostic implementation of how to receive, process and export telemetry data. The OpenTelemetry collector for Leda is a custom distribution built using the OpenTelemetry Collector Builder (https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder) and it includes only a subset of the subcomponents available from OpenTelemetry Collector Contrib project (https://github.com/open-telemetry/opentelemetry-collector-contrib). Additionally, a set of configuration files will be provided as well, these configuration files target the main SDV telemetry-collecting use cases like logging from Vehicle Services, logging of containerized Vehicle Applications, metrics of the host system (e.g. cpu/memory utilization...), metrics per containerized Vehicle Application, tracing.
-
OpenTelemetry Exporter for Leda: A bridge between the OpenTelemetry data in OTLP format to SDV-defined message envelope format, component is implemented in Rust.
-
SDV Cloud Connector for Azure IoT Hub is a fork (extended and adapted) of the generic Eclipse Kanto's Azure connector (https://github.com/eclipse-kanto/azure-connector) that is being able to process cloud-to-device and device-to-cloud messages as defined for the Software-Defined Vehicle cloud backend. The SDV cloud connector will come up with pluggable architecture that will allow easy transformation of the incoming cloud-to-device command messages (SDV message envelope) to a format suitable and understandable by the rest of the in-vehicle components and vice-versa. It shall be possible to map SDV messages to and from Eclipse Hono/Eclipse Ditto messages using simple configuration, rules written in JSON; thus allowing this component to work together with other Eclipse Kanto components too.
-
Vehicle Update Manager (VUM) is an extended and adapter version of the Eclipse Kanto's Container Manager (https://github.com/eclipse-kanto/container-management) that is being able to handle new desired state for the software on the whole vehicle device. The desired state comes as a multi document YAML content and it includes a list of Kubernetes resources (Deployments, Pods, Services, ConfigMaps, custom resources, etc.). VUM detects the system-level update custom resource and passes it for further processing to the Self Update Agent. The remaining resources are forwarded to a Kubernetes control plane and handled like the well-known kubectl command - creating new resources, updating existing ones or deleting old ones that are no longer present in the desired state manifest. VUM also monitors the self-update agent and the control plane, and compiles and report the current state of the device, again as a list of Kubernetes resources.
- Log in to post comments