This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Incubator

The Leda Incubator project is a place for new software-defined-vehicle related software components which are in incubation state.

The goal of the 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 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.

1 - Cloud Connector

The cloud connector is used in the context of Device Provisioning and cloud backend connectivity.

Overview

Leda Cloud Connector for Azure IoT Hub is a fork (extended and adapted) of the generic Eclipse Kanto’s 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.

Cloud Connector Fork Relationship

Runtime

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 and Eclipse Ditto messages using simple configuration, rules written in JSON; thus allowing this component to work together with other Eclipse Kanto components too.

Cloud Connector Runtime View

Source Repository

Source Repository: https://github.com/eclipse-leda/leda-contrib-cloud-connector

Building and Deployment

The Cloud Connector can either be installed natively into the system image by using the respective Yocto recipe leda-contrib-cloud-connector_git.bb, or the cloud connector can be deployed as a container.

Native Installation

A native installation has the advantage that no additional container runtime is required. In some vehicle system architectures, there are separate devices for connectivity and for general computation. The actual physical device for connectivity may hence have less ressources available which then requires a native installation of such core components.

  • Add the recipe to the image in your Yocto configuration:
    IMAGE_INSTALL += "leda-contrib-cloud-connector"
  • Override the configuration in /etc/cloud-connector/config.json
  • Create the device certificate
  • The cloud-connector can be managed (start, stop, restart) using systemd: systemctl restart cloud-connector

Container Installation

When the connectivity components can be deployed on the more generic compute module, where a container runtime is available, the cloud connector can also be deployed as a container. This is the default for the Eclipse Leda quickstart images.

Initial deployment and configuration steps are:

  • On first start, the auto deployment will deploy and start the cloud connector container automatically, but with invalid default values or missing device certificates.
  • The user needs to adapt the device authentication to suit his needs, e.g. creating and providing a device certificate. Check the /data/containers/cloud-connector.json deployment descriptor for the correct location of the certificate files.
  • After this configuration has been done once, the container needs to be restarted using the Kanto CLI: kanto-cm restart -n cloud-connector

2 - OpenTelemetry Integration

The OpenTelemetry integration shall be used to connect the edge device’s application log files to an existing DevOps infrastructure on the cloud side.

Status: Open for initial contribution

Background

The legacy approach to logging of vehicle applications is outdated and prevents application developers from retrieving near-time information on the application’s health in a fleet. Existing log or remote diagnostic systems for vehicles may still use a “file upload on remote request” approach.

For a more streamlined and updated way of accessing applications logs, the idea is to expore the use of current Cloud DevOps methods and technologies and apply them to remote vehicle edge system devices.

Goals and Wishlist

  • Collect logs from containerized applications (and system logs) on the edge device
  • Control the edge’s log manager configuration remotely and on-demand:
    • Enable and disable
    • One-shot activation schedules
    • Changing log levels
    • Apply filtering or sampling configurations
    • Trigger logging based on locally evaluated, dynamic conditions (IF condition=true THEN stream logs and metrics of app X for 15 minutes)
  • Retrieve and stream log messages from the edge device to an existing cloud backend (e.g. Grafana, Loki, ELK, Prometheus). The point here being that the endpoints should be vendor-neutral and use open standard protocols.
  • Retrieve application logs in different ways:
    • streamed near-time debug/trace logs for application developers in development and testing environments
    • streamed error logs for fleet operators for production environments
    • packaged, file-based logs for offroad (offline) vehicles
  • Retrieve container metrics, such as CPU, memory, disk i/o, network usage and other I/O This is interesting for application developers, for system integrators and for fleet operators to optimize their products and services.
  • Enable distributed tracing of application requests using span IDs, trace IDs or correlation IDs For future troubleshooting and support purposes, an integration of cloud-side applications and edge-side applications into commercial operation of distributed vehicle systems may become necessary.

Source Repository

Source Repository: https://github.com/eclipse-leda/leda-contrib-otel

3 - Self Update Agent

The self update agent is used in the context of OTA Self Updates.

Overview

The Self Update Agent (SUA) as part of the Eclipse Leda Incubator project proposal is a software component responsible for performing updates of system-level components of the connectivity device, such as

  • Boot Loader
  • Operating System
  • Device Firmware
  • Hardware Drivers
  • … other parts of the system, which cannot be deployed as containerized packages or may require a reboot of the device.

Self Update Agent Scope

Implementation and Deployment

SUA 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.

Self Update Agent Runtime Deployment Diagram

Building

SUA can either be installed natively into the system image by using the respective Yocto recipe leda-contrib-self-update-agent_git.bb, or can be deployed as a container.

Native Installation

A native installation has the advantage that no additional container runtime is required. In some vehicle system architectures, there are separate devices for connectivity and for general computation. The actual physical device for connectivity may hence have less ressources available which then requires a native installation of such core components.

  • Add the recipe to the image in your Yocto configuration:
    IMAGE_INSTALL += "leda-contrib-self-update-agent"
  • The self update agent can be managed (start, stop, restart) using systemd: systemctl restart self-update-agent

Container Installation

When the component can be deployed on the more generic compute module, where a container runtime is available, the self update agent can also be deployed as a container. This is the default for the Eclipse Leda quickstart images.

Initial deployment and configuration steps are:

  • On first start, the auto deployment will deploy and start the self update agent container automatically.
  • The self update agent will then connect to the locally running mosquitto server, awaiting update requests.
  • The default configuration will use the location /data/selfupdates/ to write and read update files.

Source Repository

Source Repository: https://github.com/eclipse-leda/leda-contrib-self-update-agent

4 - Vehicle Update Manager

The vehicle update manager is used in the context of OTA Software Updates.

Overview

Vehicle Update Manager (VUM) is an extended version of the Eclipse Kanto Container Manager that is being able to handle new desired state for the software on the whole vehicle device.

Vehicle Update Manager Scope

Implementation

The desired state comes as a multi document YAML content and it includes a list of container resources:

  • Container
  • Configuration

VUM detects the system-level update custom resource and passes it for further processing to the Self Update Agent.

VUM also monitors the self-update agent and the control plane, and compiles and report the current state of the device.

Source Repository

Source Repository: https://github.com/eclipse-leda/leda-contrib-vehicle-update-manager