Leda on Eclipse Leda Documentation

Configuration

Fri, 25 Aug 2023 17:03:19 +0300

Config file

The default location for the VUM service on the Leda Distro image can be found at /etc/update-manager/config.json. The location of the config file is specified with the --cfg-file [PATH] flag when starting the binary.

Minimal configuration

A minimal configuration (that is used by the Leda Distro) is the following:

{
    "log": {
      "logFile": "/var/log/update-manager/update-manager.log"
    },
    "domain": "vehicle",
    "agents": {
        "containers": {
            "name": "containers",
            "rebootRequired": false,
            "readTimeout": "30s"
        },
        "self-update": {
            "name": "self-update",
            "rebootRequired": true,
            "readTimeout": "30s"
        }
    },
    "thingsEnabled": false
}

Where:

Milestone 0.1.0-M1

Wed, 12 Apr 2023 14:24:56 +0530

Release artifacts: https://github.com/eclipse-leda/leda-distro/releases/tag/v0.1.0-M1

Artifact	Download	Size
Leda Raspberry Pi 4	eclipse-leda-raspberrypi.tar.xz	578 MB
Leda QEMU ARM64	eclipse-leda-qemu-arm64.tar.xz	381 MB
Leda QEMU x86_64	eclipse-leda-qemu-x86_64.tar.xz	465 MB

Note: You need to uncompress eclipse-leda-raspberrypi.tar.xz multiple times until the plain .wic file is extracted, which can be flashed.

After download, continue with Getting Started

Release Notes

First pre-release of Eclipse Leda quickstart images, based on Yocto LTS release Kirkstone with Long Term Support until at least April 2024.

Communicating with Кanto-CM via gRPC

Tue, 03 Jan 2023 17:24:56 +0530

Kanto container management binds to a unix socket (default: /run/container-management/container-management.sock) and exposes a gRPC interface which can be used to obtain all the functionality of the kanto-cm cli programatically.

The easiest way to access this API through Rust is by creating a new Rust crate:

$ cargo new talk-to-kanto

Dependencies

The most feature-rich gRPC library for Rust right now is tonic. Add the following to your Cargo.toml to make tonic and the tokio async runtime available to your crate. Tower and hyper are needed to be able to bind to the unix socket.

sdv-health

Tue, 03 Jan 2023 17:24:56 +0530

A general utility for monitoring the status of important sdv services/containers/devices.

Checking the status of kanto-cm containers

Kanto CM containers are split into two groups - required and optional. Both groups are checked, but only a warning is issued when an optional container is missing/not working.

General code for checking the status is:

if [ -n "$KANTO_CM_CONTAINERS_OPT" ]; then
	printf -- "$SEPARATOR\n"

	printf -- "${COL_WHITE}[Kanto CM Containers (OPTIONAL)]${COL_NC}\n"
	if [[ ${CM_STATUS} != *"inactive"*  ]]; then
		
		# "Optional containers"
		KANTO_CM_LIST=$(${KANTO_CMD} list)
		# removes tabs, splits on pipe and takes the container name column ($2)
		FOUND_CONTAINERS=($(echo "$KANTO_CM_LIST" | awk -F'|' '{gsub(/\t/, ""); print $2}')) # array with all kanto container names
		# removes tabs, splits on pipe and takes the container status colum ($4)
		FOUND_CONTAINERS_STATES=($(echo "$KANTO_CM_LIST" | awk -F'|' '{gsub(/\t/, ""); print $4}')) # array with all kanto container states
		KANTO_CM_CONTAINERS_ARR=( $KANTO_CM_CONTAINERS_OPT )

		for expectedCtr in ${KANTO_CM_CONTAINERS_ARR[@]}; do
			CTR_IDX=$(get_array_element_index ${expectedCtr} ${FOUND_CONTAINERS[@]})
			if [ ! -z $CTR_IDX ]; then
				status=${FOUND_CONTAINERS_STATES[$CTR_IDX]}
				if [ "$status" = "Running" ]; then
					printf "  * %-40s : $TEXT_OK\n" "${expectedCtr}"
				else
					printf "  * %-40s : $TEXT_WARN (%s)\n" "${expectedCtr}" "$status"
				fi
			else
				printf "  * %-40s : $TEXT_WARN (%s)\n" "${expectedCtr}" "NOT FOUND"
			fi
		done

	else
		printf "  * %-40s : $TEXT_FAIL (%s)\n" "Kanto Container Management" "Unavailable"
	fi

fi

Here it is important to know that kanto-cm list outputs the list of containers in a different order every time it’s called. That is why, kanto-cm list is invoked once and its output is stored in a variable:

Advanced topics

Mon, 09 May 2022 14:24:56 +0530

Git Authentication

For private repositories, we need to separately authenticate against the submodule repositories, as GitHub Codespaces will only inject a token with access rights to the current repository.

Change to the users home directory
```
cd ~
```

Install Git Credential Manager

curl -LO https://raw.githubusercontent.com/GitCredentialManager/git-credential-manager/main/src/linux/Packaging.Linux/install-from-source.sh &&
sh ./install-from-source.sh &&
git-credential-manager-core configure

Configure a credential store typ, e.g. git config --global credential.credentialStore plaintext
Verify with git config --global -l, it should show git-credential-manager-core as the credential helper.

CAN Bus

Mon, 09 May 2022 14:24:56 +0530

Note: The configuration mentioned in this chapter is already enabled in the run-leda.sh script.

QEMU

General documentation about using CAN-Bus in Qemu: https://www.qemu.org/docs/master/system/devices/can.html

Enabling Virtual CAN Bus interfaces (vcan)

No special parameters are necessary for qemu, as vcan is virtual:

runqemu qemux86-64 nographic slirp qemuparams="-m 2048"

Bring interface up:

ip link add dev vcan0 type vcan
ip link set vcan0 up

Enabling CAN Bus interfaces (can)

Standalone CAN within Qemu

To run a standalone CAN setup, qemu must be instructed to emulate a specific CAN hardware device. We will be using the kvaser_pci device in this example:

Cloud Connectivity

Mon, 09 May 2022 14:24:56 +0530

Simulation of cloud connectivity

Container Management starts and subscribes to edge/thing/response
Cloud Connector starts and publishes the following message to edge/thing/response as soon as the connection is online:

{
    "deviceId":"<namespace>:<gatewayId>:<deviceId>",
    "tenantId":"<tenantId>"
}

namespace is azure.edge for Kanto’s Azure Cloud Connector
gatewayId indicates the hostname of the Azure IoT Hub
deviceId is the identifier for the device, this can either be part of the Azure Connection String or part of the device authentication certificate (CN)
tenantId is a configuration setting in the cloud connector

Note: You can simulate the cloud connector trigger by issueing the MQTT message manually on command line:

Concepts

Mon, 09 May 2022 14:24:56 +0530

The example build configurations in this repository are based on the official BitBake Quickstart tutorial and have been extended to include Leda SDV components.

Build Setup

To set up your own BitBake build configuration, follow the BitBake documentation and include meta-leda in your bblayers.conf and add the SDV packages into your local.conf.

The Leda build is mainly using the kas tool for a simplified maintenance of the BitBake Configuration files. The kas configuration files are located in kas/

Resource Consumptions

Mon, 09 May 2022 14:24:56 +0530

Baseline (no apps installed)

Baseline: 400 MB

Installed components:

Container Management: runc, containerd, container-management
System Services: systemd, openssh, mosquitto, mosquitto-clients
No cloud connector or edgecontainerd yet.
No self update agent
No containers, no vehicle apps etc.

root@qemux86-64:/bin# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       2.5G  506M  1.8G  22% /

Memory Usage: 200MB

root@qemux86-64:/# free
            total        used        free      shared  buff/cache   available
Mem:           1.9G      329.6M        1.4G       16.6M      222.2M        1.6G
Swap:

Component Details

Dependencies

SDV Health

Mon, 09 May 2022 14:24:56 +0530

Health check

The sdv-health utility displays a status overview of some important dependencies and device configurations for the SDV edge stack. The sdv health utility can be configured using the sdv.conf configuration file.

Usage:

# sdv-health

Example output:

Version Information

The Leda image version and build time will be displayed at the top in the first category:

OS Release: Year and codename of the release version
Image Version: Name of the image and more specific version information, such as the git tag or commit id
Build timestamp in yyyMMddHHmmss notation

Note: The information is read from the system base file in /etc/os-release:

Self Update Tutorial

Mon, 09 May 2022 14:24:56 +0530

This chapter describes the steps necessary to perform a local (without cloud) self update of the operating system.

Self-Update using RAUC Update Bundles

On host: Update bundle sdv-rauc-bundle-qemux86-64.raucb is in current folder

Note: In the development environment, the update RAUC Update Bundle is located in the BitBake machine-specific output folder Example location is tmp/deploy/images/qemux86-64
On host: Start a dummy web server for serving the update file
```
python3 -m http.server --bind 192.168.7.1
```
On host: open two new terminals - one for monitoring and one for triggering the self-update

Transferring Files

Mon, 09 May 2022 14:24:56 +0530

When you want to copy files between the host and the guest, an easy way is to use an SFTP tunnel. With sshfs, you can mount a local directory to a remote directory via SSH.

Pre-Requisites

Installation of needed packages:

Run apt-get install sshfs on your host
Enable CORE_IMAGE_EXTRA_INSTALL += " openssh-sftp-server" in local.conf of your image (e.g. in the local_conf_header section in your kas file)
Verify SFTP connection working with sftp -P 2222 root@localhost

Transfering files from host to guest

When you want to copy files from the host to the guest, an easy way is to use an SFTP tunnel. With sshfs, you can mount a local directory to a remote directory via SSH.

Validating

Mon, 09 May 2022 14:24:56 +0530

Validating the release

Steps to validate if a release is properly working:

Create a new pre-release from your branch
Download the release artifacts onto a clean system.

Do not use your build environment, to minimize the impact of existing environment configuration from BitBake etc.
Run the run-leda scripts to execute Qemu

Note: You should test each of the release archives, for each target machine.
Follow the Device Provisioning guide
Perform some verification tests (see below)

VSCode DevContainer

Mon, 09 May 2022 14:24:56 +0530

Preparation

Obtain the Docker Engine for your distribution and add your non-privileged user to the docker group (sudo usermod -aG docker $USER )
Install Visual Studio Code

Visual Studio Code: Development Containers

Open Visual Studio Code
Open Command Palette (F1) and select Clone repository in Container Volume
Select eclipse-leda/meta-leda and the main branch.
Adapt proxy configurations if necessary (.devcontainer/proxy.sh)

For a clean remote build machine, you may want to set up a development environment on GitHub CodeSpaces

Container Update Agent

Mon, 28 Aug 2023 12:09:24 +0300

About the Container Update Agent (CUA)

The container update agent is a component of kanto container management, that can be enabled in the Container Management’s config.json. When it receives a desired state message on the containersupdate/desiredstate topic it compares the containers (with their current versions and configuration) that are managed by Kanto Container Management and those described in the desired state messages. When it has identified the differences between the two, it resolves them by deleting, downloading, or re-creating containers.

Message Flow

Mon, 28 Aug 2023 09:23:11 +0300

Note: This part of the Leda OSS stack is still in active development and there might be differences between the documented and the current version.

As described in Vehicle Update Manager takes a full update message for all domains, identifies the domains affected, the current component versions, actions to be taken, etc., and delegates those actions to the correct update agent (e.g. self-update/container update).

The update manager (UM) in Leda-distro is configured as specified in UM’s config.json, which on the final image is usually located in /etc/update-manager/config.json. The standard two domains supported are containers and self-update, with the latter requiring a reboot on a successful update.

Milestone 0.1.0-M2

Wed, 12 Apr 2023 14:24:56 +0530

Release artifacts: https://github.com/eclipse-leda/leda-distro/releases/tag/v0.1.0-M2

Artifact	Download	Size
Leda Raspberry Pi 4	eclipse-leda-raspberrypi.tar.xz	578 MB
Leda QEMU ARM64	eclipse-leda-qemu-arm64.tar.xz	381 MB
Leda QEMU x86_64	eclipse-leda-qemu-x86_64.tar.xz	465 MB

Note: You need to uncompress eclipse-leda-raspberrypi.tar.xz multiple times until the plain .wic file is extracted, which can be flashed.

After download, continue with Getting Started

Release Notes

First pre-release of Eclipse Leda quickstart images, based on Yocto LTS release Kirkstone with Long Term Support until at least April 2024.

Kanto Auto deployer (KAD)

Tue, 03 Jan 2023 17:24:56 +0530

TLDR: To deploy a container in the final Leda image, all you generally need to do is add the manifest in the kanto-containers directory and re-build.

Kanto-CM does not provide (currently) a stable feature that allows for the automatic deployment of containers through manifest files similar to k3s’ automated deployment of k8s-manifests found in the /var/lib/rancher/k3s/server/manifests directory.

This can be worked around via a bash script for each container that runs on boot and makes sure it’s deployed. Even though this approach is functional it is not very structured and would require a lot repeating code.

Architecture of Seat Adjuster

Mon, 09 May 2022 14:24:56 +0530

The seat adjuster application interacts with the vehicle through a Vehicle Abstraction Layer created by the KUKSA Databroker, which uses the Vehicle Signal Specification (VSS) to express the current value and in case of actuators also the desired state of the vehicle signal. By developing against the abstraction layer, the application becomes independent from the actual physical seat.

To control the position of the driver seat, the seat adjuster sets the target value of the Vehicle.Cabin.Seat.Row1.Pos1.Position signal in the KUKSA Databroker.

CAN-Bus extensions

Mon, 09 May 2022 14:24:56 +0530

The Eclipse Leda quickstart image has CAN-Bus kernel modules and some CAN hardware drivers pre-installed. However, some hardware configuration needs to be adapted at boot time depending on the specific CAN-Extension being attached to the device.

On Raspberry Pi, there is a /boot/config.txt file where you can configure the dtoverlay options accordingly.

Note: After modification, the device requires rebooting for the changes to take effect.

MCP2515 based modules

Products:

Waveshare RS485 CAN HAT for Raspberry Pi

dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000

MCP2518FD based modules

Products:

Features

Mon, 09 May 2022 14:24:56 +0530

Publish/Subscribe messaging infrastructure for cloud connectivity by Eclipse Kanto
- local messaging for applications and SDV system components via an MQTT message broker
- connection to a backend messaging hub, such as Azure IoT Hub or the IoT Suite
- device identification and authentication for cloud connectivity by using TLS device certificates
Container runtime
- An OCI-compliant container orchestration for vehicle applications and services by Eclipse Kanto
- containerd.io as the default container runtime. Both layers of container runtimes can be exchanged with other implementations
A Vehicle Update Manager to orchestrate deployments of Vehicle Applications, configurations and base operating system updates
An example Vehicle Seat Service implementation to showcase
- the Eclipse Velocitas programming model,
- the Eclipse Kuksa.VAL vehicle databroker and
- the Covesa Vehicle Signal Specification
- the communication with basic vehicle communication networks such as CAN-Bus (CAN Feeder)
A Self Update Agent for firmware-over-the-air (FOTA) updates, using an A/B deployment strategy
- Integration with RAUC
An OpenTelemetry collector and example configurations to collect and publish logs and metrics of containerized Vehicle Applications to the cloud backend for further processing

The features of the reusable build recipes implemented as an OpenEmbedded metalayer meta-leda are:

KantUI

Mon, 09 May 2022 14:24:56 +0530

The KantoUI tool is a text-based user interface for conveniently managing containers in the Kanto Container Management. It supports simple navigation using keyboard and mouse to select a specific container. Commands to start, stop, remove and re-deploy containers are available along with a functionality to retrieve the application logs of a selected container.

Kanto User Interface

Usage:

kantui

Example output:

Command Line Options

Print command line help:

root@qemux86-64:~# kantui --help
kantui 0.2.0
A TUI for Kanto CM that allows easier management of deployed containers. Requires root.

USAGE:
    kantui [OPTIONS]

OPTIONS:
    -c, --config-file-path <CONFIG_FILE_PATH>
            Set a custom path for the kantui configuration file [default:
            /etc/kantui/kantui_conf.toml]

    -h, --help
            Print help information

    -V, --version
            Print version information

Note: All config values can be overridden through env variables prefixed with KANTUI_,
e.g. KANTUI_STOP_TIMEOUT=5 overrides the timeout before SIGKILL is sent to be 5 seconds.

Keyboard commands

Arrow keys Up and Down to select a container
Arrow keys Left and Right to select a column
Enter to change the sort ordering of the currently selected column
S to start the selected container which is currently not running
P to stop the selected container
R to remove a container
L to show the log output of a container
D to redeploy an existing container (rereads deployment descriptor)
Q to quit kantui

Note: The mouse can be used to select ui items when holding the Shift key.

Manual Provisioning

Mon, 09 May 2022 14:24:56 +0530

Follow these steps to do a manual device provisioning:

Generate the device certificate (eg using openssl) and sign it with your CA.
Log in to Azure Portal, Go to Azure Iot Hub and create a new device
Select the proper authentication type, e.g. X.509 Self-signed or X.509 CA Signed
Copy the device certificate (cert file and key file) to the device to /data/var/certificate
Restart cloud connector service or container.

Create a device in Azure IoT Hub

For the device to be connectable, it needs to be known to the cloud service first. In these steps, we will create a new device identity by using Azure IoT Hub.

Metalayer

Mon, 09 May 2022 14:24:56 +0530

Initializing BitBake environment

Initialize the build environment and start the build for QEMU:

kas build kas/leda-qemux86-64.yaml

Building specific recipes

General usage:

kas build kas/leda-qemux86-64.yaml --target <recipename>

Metalayer Structure

 meta-leda-bsp
 \-- classes                      // Reusable BitBake Classes, eg for offline container image pre-caching
 \-- conf                         // Distribution specific configurations, eg version numbers, release codename
 \-- recipes-bsp                  // Board Support Packages, eg specifics for QEMU and Raspberry Pi
 meta-leda-components
 \-- classes                      // Reusable BitBake Classes, eg for offline container image pre-caching
 \-- conf                         // Distribution specific configurations, eg version numbers, release codename
 \-- recipes-sdv
   |-- eclipse-leda               // Build recipes for Eclipse Leda Incubator components
   |-- eclipse-kuksa              // Build recipes for Eclipse Kuksa
   |-- eclipse-cyclonedds         // Build recipes for Eclipse CycloneDDS
   |-- northstar                  // Build recipes for Northstar Container Runtime
   |-- packagegroups              // Grouping packages
   \-- sdv-base                   // SDV Base Bundle: fstab, can0.network
     |--- base-files
     |--- SDV Core Utilities
     \--- SDV Utilities
   |-- sdv-containers             // Container images recipes for pre-caching / airgap installation
     |--- Cloud Agent
     |--- Data Broker
     |--- Feeder CAN
     |--- OTel Collector
     |--- Self Update Agent
     |--- Vehicle Update manager
     |--- Example Seat Service
     \--- ...
   |-- sdv-core                   // SDV Core Bundle
     |--- SDV RAUC Bundle         // RAUC Update Bundle Manifest
   \-- tools                      // Convenience tools for the "full" image, eg nerdctl and kantui
 meta-leda-distro
 \-- classes                      // Reusable BitBake Classes, eg for offline container image pre-caching
 \-- conf                         // Distribution specific configurations, eg version numbers, release codename
 \-- recipes-containers           // Container related configuration recipes (containerd, nerdctl)
 \-- recipes-core                 // Core recipes (base-files, systemd)
 \-- recipes-kernel               // Kernel configuration, eg kernel modules, logging, virtio
 \-- recipes-sdv-distro           // Image definitions
 \-- wic                          // WIC Kickstarter files - Partition layouts
meta-leda-distro-container
 \-- classes                      // Reusable BitBake Classes, eg for offline container image pre-caching
 \-- conf                         // Distribution specific configurations, eg version numbers, release codename
 \-- recipes-sdv                  // Build containers with Yocto

Base Bundle

Contains the recipes to build and install the minimal set of dependencies for the SDV stack on the edge device. With these minimal components, the SDV stack should be able to bootstrap itself.

RAUC Integration

Mon, 09 May 2022 14:24:56 +0530

Leda integrates RAUC as a reference implementation and example configuration. It allows the evaluation of the concepts, mechanisms and involved software components in an emulated, virtual environment or on physical devices.

Checking the RAUC Status

Get the current RAUC boot status:

rauc status

Example output:

root@qemux86-64:~# rauc status
=== System Info ===
Compatible:  Eclipse Leda qemu86-64
Variant:     
Booted from: rootfs.1 (SDV_B)

=== Bootloader ===
Activated: rootfs.1 (SDV_B)

=== Slot States ===

o [rootfs.1] (/dev/sda5, ext4, inactive)
        bootname: SDV_B
        mounted: /
        boot status: good

x [rootfs.0] (/dev/sda4, ext4, booted)
        bootname: SDV_A
        boot status: good

Forcing to boot the other slot

To manually force the device to boot into another slot, mark the current booted slot as bad, mark the other partitions as active and perform a reboot:

Kantui

Tue, 03 Jan 2023 17:24:56 +0530

The k8s ecosystem comes with a lot of utilies that allow for the easier management of containers (such as k9s). The kantui util aims to be a “nice” text user interface that lets the user start/stop/remove/get logs of deployed containers in kanto-cm.

Development notes

This tool is again based on the ideas in Communicating with Кanto-CM via gRPC.

It spins up two threads - an UI thread (drawing/updating UI) and an IO thread (communicating with kanto-cm via gRPC). The communication between these two threads happens over an async-priority-channel with ListContainers request having a lower priority than Start/Stop/Remove/Get Logs (“user interaction”) requests.

Building with kas/manually

Mon, 09 May 2022 14:24:56 +0530

After setting up your VSCode DevContainer or GitHub Codespace you can proceed with the actual build process. Here you have two choices - either using the kas-build system or setting up the build manually.

Building with kas

This is the easiest way to build leda semi-automatically

cd /workspaces/meta-leda-fork/
Open the VSCode terminal and run kas build
Note: you can alter the build options by modifying the .config.yaml file in the trunk of the repository

Building manually

You can also build Leda manually if more customization of the build process is required.

Dependencies

Mon, 09 May 2022 14:24:56 +0530

Dependency	Type	License	URL
poky	OpenEmbedded Metalayer	MIT	https://www.yoctoproject.org/software-item/poky/
meta-virtualization	OpenEmbedded Metalayer	MIT	https://git.yoctoproject.org/meta-virtualization
meta-networking	OpenEmbedded Metalayer	MIT	https://git.yoctoproject.org/meta-networking
meta-rauc	OpenEmbedded Metalayer	MIT	https://github.com/rauc/meta-rauc
meta-openembedded	OpenEmbedded Metalayer	MIT	https://git.openembedded.org/meta-openembedded
meta-security	OpenEmbedded Metalayer	MIT	https://git.yoctoproject.org/meta-security
meta-rauc-community	OpenEmbedded Metalayer	MIT	https://github.com/rauc/meta-rauc-community
meta-raspberrypi	OpenEmbedded Metalayer	MIT	https://git.yoctoproject.org/meta-raspberrypi

Develop Seat Adjuster

Mon, 09 May 2022 14:24:56 +0530

The following pages show how to execute the explained setup using Eclipse Velocitas and Eclipse Leda 0.1.0-M2:

On a high level, you need to perform the following steps described in more detail in this guide:

Use the Eclipse Velocitas template repository to develop, build and deploy your version of the seat adjuster example.
Run Eclipse Leda, for example, as container or with other options like QEMU, physical hardware, etc..
Manage the Eclipse Kanto container runtime to deploy your seat adjuster application.

Goals

Mon, 09 May 2022 14:24:56 +0530

The project aims to provide an integration point for Open Source components for the Software Defined Vehicle ecosystem.

In a complex architecture, there are many different ways of implementations and alternative solutions possible.

For embedded vehicle computer systems and their software stack, there are a lot of requirements to consider, depending on the actual use cases:

Integration and High-Level Testing (System Integrators, Suppliers)
Proof-of-Concept projects (Integrators, OEMs, ISVs)
Experiments and Hackathons (Developers, Research)
Development phase (Developers, OEMs)
Open Source Collaboration (Developers, OEMs, ISVs, Open Source Organizations, Standardization Organizations)

Some of the requirements derived from the above are taken into account for Leda’s quickstart setups. Thereas some other requirements can only be met once the project is in a nearer production environment and by customizing the target device image. The following document will list some of these requirements and give an explanation on why they are set as goals in the Leda quickstart distribution.

Orchestration

Mon, 09 May 2022 14:24:56 +0530

Container Management

The container management will respond to the cloud connectivity status message by initially sending a list of containers:

Container Management responds with a list of containers in the topic e/<tenantId>/<gatewayId>:<deviceId>:edge:containers

{
    "topic": "<tenantId>/<gatewayId>:<deviceId>:edge:containers/things/twin/commands/modify",
    "headers": {
        "response-required": false
    },
    "path": "/features/SoftwareUpdatable",
    "value": {
        "definition": [
            "org.eclipse.hawkbit.swupdatable:SoftwareUpdatable:2.0.0"
        ],
        "properties": {
            "status": {
                "softwareModuleType": "oci:container",
                "installedDependencies": {
                    "ghcr.io%2Feclipse%2Fkuksa.val%2Fdatabroker.<uuid>:0.2.5": {
                        "group": "ghcr.io/eclipse/kuksa.val/databroker",
                        "name": "<uuid>",
                        "version": "0.2.5"
                    },
                    "ghcr.io%2Feclipse%2Fkuksa.val.services%2Fseat_service.<uuid>:v0.1.0": {
                        "group": "ghcr.io/eclipse/kuksa.val.services/seat_service",
                        "name": "<uuid>",
                        "version": "v0.1.0"
                    },
                    "ghcr.io%2Feclipse-leda%2Fleda-contrib-cloud-connector%2Fcloudconnector.<uuid>:latest": {
                        "group": "ghcr.io/eclipse-leda/leda-contrib-cloud-connector/cloudconnector",
                        "name": "<uuid>",
                        "version": "latest"
                    },
                    "ghcr.io%2Feclipse-leda%2Fleda-contrib-self-update-agent%2Fself-update-agent.<uuid>:build-20": {
                        "group": "ghcr.io/eclipse-leda/leda-contrib-self-update-agent/self-update-agent",
                        "name": "<uuid>",
                        "version": "build-20"
                    },
                    "ghcr.io%2Feclipse-leda%2Fleda-contrib-vehicle-update-manager%2Fvehicleupdatemanager.<uuid>:latest": {
                        "group": "ghcr.io/eclipse-leda/leda-contrib-vehicle-update-manager/vehicleupdatemanager",
                        "name": "<uuid>",
                        "version": "latest"
                    }
                }
            }
        }
    }
}

Container Management answers with an additional message for each container in the topic e/<tenantId>/<gatewayId>:<deviceId>:edge:containers

{
    "topic": "<tenantId>/<gatewayId>:<deviceId>:edge:containers/things/twin/commands/modify",
    "headers": {
        "response-required": false
    },
    "path": "/features/Container:<uuid>",
    "value": {
        "definition": [
            "com.bosch.iot.suite.edge.containers:Container:1.5.0"
        ],
        "properties": {
            "status": {
                "name": "seatservice-example",
                "imageRef": "ghcr.io/eclipse/kuksa.val.services/seat_service:v0.1.0",
                "config": {
                    "domainName": "seatservice-example-domain",
                    "hostName": "seatservice-example-host",
                    "env": [
                        "VEHICLEDATABROKER_DAPR_APP_ID=databroker",
                        "BROKER_ADDR=databroker-host:30555",
                        "RUST_LOG=info",
                        "vehicle_data_broker=info"
                    ],
                    "restartPolicy": {
                        "type": "UNLESS_STOPPED"
                    },
                    "extraHosts": [
                        "databroker-host:host_ip"
                    ],
                    "portMappings": [
                        {
                            "proto": "tcp",
                            "hostPort": 30051,
                            "hostPortEnd": 30051,
                            "containerPort": 50051,
                            "hostIP": "localhost"
                        }
                    ],
                    "networkMode": "BRIDGE",
                    "log": {
                        "type": "JSON_FILE",
                        "maxFiles": 2,
                        "maxSize": "1M",
                        "mode": "BLOCKING"
                    }
                },
                "createdAt": "2023-02-02T08:46:33.792687313Z",
                "state": {
                    "status": "RUNNING",
                    "pid": 13627,
                    "startedAt": "2023-02-02T09:51:08.049572297Z",
                    "finishedAt": "2023-02-02T09:50:51.752255799Z"
                }
            }
        }
    }
}

Run the build

Mon, 09 May 2022 14:24:56 +0530

Run the full build

To setup the environment and build the Leda image, please refer to: Setup development environment.

Running QEMU from existing build

Use kas shell -c "runqemu qemux86-64 ovmf kvm nographic" <kas-configs> to execute the image.
Replace qemux86-64 with one of the other qemu machines, such as qemuarm64
Use the keyword slirp to enable user-networking which does not require root privileges on the host. tun is default but requires setup on the host.
Continue with Device Provisioning

Variations of runqemu command line

Use runqemu ovmf
- ovmf will enable the UEFI support for IA32 (x86) and X64 (x86-64) guests, for testing the dual-boot capabilities and SDV Self-Update mechanisms
All other options are now part of the default Leda distribution configuration (see leda-qemu-settings.inc)
Continue with Device Provisioning

Running QEMU in the background

To start QEMU in the background enter, use nohup and bring the process into the background.

SDV Device Info

Mon, 09 May 2022 14:24:56 +0530

Displays the current device configuration, such as Device ID.

Note: Requires the Cloud Connector component to be configured and running.

Usage:

sdv-device-info

Usage

Synposis: ./sdv-device-info [options] [command]

Full help:

root@qemux86-64:~# sdv-device-info --help
sdv-device-info v0.2
Usage: /usr/bin/sdv-device-info [options] [command]
Show SDV device configuration information
Example: /usr/bin/sdv-device-info show

Commands:
 show                 : Display configuration (default command)
 help                 : This message
 env                  : Format output for use in scripts

Options:
 --ansi | -a      : Don't use colored output.
 --norestart | -n : Do not automatically restart services
 --verbose | -v   : Enable verbose mode.
 --help | -h      : This message.

Use in scripts

To use device information on other scripts, it may be useful to source the device information variables into the current environment variable context:

Container Metrics

Mon, 09 May 2022 14:24:56 +0530

Container Metrics

Container-level metrics, such as CPU utilization or memory usage, can be retrieved on-demand and continuously by enabling the container metrics events. This is done by sending a request to the topic command//<namespaceId>:<gatewayId>:<deviceId>:edge:containers/req/<correlationId>/request:

Enable Container Metrics with a frequency of 5s:

{
    "topic": "dummy-namespace/dummy-gateway:dummy-device-id:edge:containers/things/live/messages/request",
    "headers": {
        "timeout": "10",
        "response-required": true,
        "content-type": "application/json",
        "correlation-id": "3fdc463c-293c-4f39-ab19-24aef7944550"
    },
    "path": "/features/Metrics/inbox/messages/request",
    "value": {
        "frequency": "5s"
    }
}

Example command line:

mosquitto_pub -t command//dummy-namespace:dummy-gateway:dummy-device-id:edge:containers/req/3fdc463c-293c-4f39-ab19-24aef7944550/request -m '{"topic":"dummy-namespace/dummy-gateway:dummy-device-id:edge:containers/things/live/messages/request","headers":{"timeout":"10","response-required":true,"content-type":"application/json","correlation-id":"3fdc463c-293c-4f39-ab19-24aef7944550"},"path":"/features/Metrics/inbox/messages/request","value":{"frequency":"5s"}}'

Container Metrics answers with an additional message for each container in the topic e/<tenantId>/<gatewayId>:<deviceId>:edge:containers

{
    "topic": "<tenantId>/<gatewayId>:<deviceId>:edge:containers/things/twin/commands/modify",
    "headers": {
        "response-required": false
    },
    "path": "/features/Container:<uuid>",
    "value": {
        "definition": [
            "com.bosch.iot.suite.edge.containers:Container:1.5.0"
        ],
        "properties": {
            "status": {
                "name": "seatservice-example",
                "imageRef": "ghcr.io/eclipse/kuksa.val.services/seat_service:v0.1.0",
                "config": {
                    "domainName": "seatservice-example-domain",
                    "hostName": "seatservice-example-host",
                    "env": [
                        "VEHICLEDATABROKER_DAPR_APP_ID=databroker",
                        "BROKER_ADDR=databroker-host:30555",
                        "RUST_LOG=info",
                        "vehicle_data_broker=info"
                    ],
                    "restartPolicy": {
                        "type": "UNLESS_STOPPED"
                    },
                    "extraHosts": [
                        "databroker-host:host_ip"
                    ],
                    "portMappings": [
                        {
                            "proto": "tcp",
                            "hostPort": 30051,
                            "hostPortEnd": 30051,
                            "containerPort": 50051,
                            "hostIP": "localhost"
                        }
                    ],
                    "networkMode": "BRIDGE",
                    "log": {
                        "type": "JSON_FILE",
                        "maxFiles": 2,
                        "maxSize": "1M",
                        "mode": "BLOCKING"
                    }
                },
                "createdAt": "2023-02-02T08:46:33.792687313Z",
                "state": {
                    "status": "RUNNING",
                    "pid": 13627,
                    "startedAt": "2023-02-02T09:51:08.049572297Z",
                    "finishedAt": "2023-02-02T09:50:51.752255799Z"
                }
            }
        }
    }
}

To disable Container Metrics, send a request with frequency of 0s:

Deploy Seat Adjuster

Mon, 09 May 2022 14:24:56 +0530

We now want to deploy the application to a target device. You may follow the remainder of this guide on a separate device like a RaspberryPi, but you can emulate such a device on your development machine too. Either way, we use Eclipse Leda in version 0.1.0-M2 as the target system, which is a Linux-based distribution with pre-installed SDV components like the KUKSA Databroker and Eclipse Kanto for container management. For more details on how to download and run Eclipse Leda, follow the respective guides:

Roadmap

Mon, 09 May 2022 14:24:56 +0530

Initial Open Source contribution expected by Q2 2022 (Done)
A first milestone build is expected end of 2022 (Done)
Plan for the first release cycle to be created in Q1/2023 (In Progress - Q2/2023)
Release cycles are planned every 3-6 months
Release planning will be conducted together with corresponding Eclipse projects

Backlog

The Leda team maintains a backlog roadmap using GitHub projects at https://github.com/orgs/eclipse-leda/projects/1/views/1

Future Work

The project intends to be the integration and collaboration platform for Software defined Vehicle functionality.

Robot Keywords

Mon, 09 May 2022 14:24:56 +0530

In the Leda Robot Tests, keywords are used for reusable functionality. Common keywords are defined in resources/docker-snapshot/dockerfiles/leda-tests/leda_keywords.resource

The goal is to treat the Leda Quickstart image as a black box, utilizing as much as possible with public APIs.

Interaction with Self Update Agent

Trigger to start update: Send a “Desired State Request” to the target, to install a RAUC Update Bundle
Connect and Subscribe to Listen: Wait for the asynchronous messages which indicate a successful installation of an update

Arbitrary Commands

Nevertheless, during implementation of test cases, it may be necessary to execute lower level processes for system level tests. For that, a fallback is possible to execute arbitrary test commands via remote SSH connection. These commands are executed through another docker container running in the same Docker network (leda-network) and allow access to the target QEMU instances:

Rust Tests

Mon, 09 May 2022 14:24:56 +0530

Note: The Rust tests are being replaced with test cases implemented in Robot.

Cross Compiling to X86_64 on Ubuntu 20.04

There is currently a step to cross-compile tests to X86_64. In order to successfully run the step, you need to make sure that the following artifacts are available on the runner:

rustc + cargo: curl https://sh.rustup.rs -sSf | sh
docker: follow https://docs.docker.com/engine/install/ubuntu/ and afterwards https://docs.docker.com/engine/install/linux-postinstall/
build-essential: sudo apt-get install build-essential
cross (0.1.16): cargo install cross --version 0.1.16
jq: sudo apt-get install jq -y

You may restart your current shell so that all components are available as env vars.

SDV Provision

Mon, 09 May 2022 14:24:56 +0530

The provisioning helper script can be used to manually perform a device provisioning with a cloud backend.

It is meant as a convenient tool for developers, who wish to connect their device to a selfmanaged cloud backend directly. In a production environment, the device provisioning functionality is implemented either by the Cloud Connector component.

The provisioning script currently supports the following backend and authentication options:

Azure IoT Hub
- Connection String
- Device Certificates
Azure IoT Device Provisioning Service
- Device Certificates

Usage

The sdv-provision script is interactive and asks for the type of backend and authentication option:

Container Registries

Mon, 09 May 2022 14:24:56 +0530

When deploying containerized applications, the container runtime will pull container images from a (remote) container registry.

The pulled container images and their layers are then stored in a local storage.

Private Container Registries

To be able to pull container images, the container runtime needs access to the container registry. Some container registries require authentication. The Kanto Container Manager can be configured to use credentials when accessing remote container registries.

In the Leda images, the sdv-kanto-ctl tools allows to easily add authentication to the container manager configuration:

Contribution Guidelines

Mon, 09 May 2022 14:24:56 +0530

Thanks for considering to contribute to Eclipse Leda. We really appreciate the time and effort you want to spend helping to improve the project.

In order to get you started as fast as possible we need to go through some organizational issues first, though.

Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation Development Process and operates under the terms of the Eclipse IP Policy.

GitHub Workflow

Mon, 09 May 2022 14:24:56 +0530

Manually creating a Release triggers the release workflow.
The release workflow calls the build workflow.
The build workflow indirectly depends on the sstate cache being prebuilt manually (see optimizations below)
The build workflow runs a full build of the SDV-Image-All disk image for all target machines.
A separate job is used for each target machine, to ensure an image build for a target machine can finish within 6 hours.
Each build contains the creation of SBOM artifacts and the check for CVEs. The SBOM artifacts are in SPDX JSON format and packaged per target machine’s disk image (SDV-Image-Full to include all packages).
The OSS License Scanning (using the OSS Review Toolkit) is done asynchronously on a separate fork, as it currently uses a proprietary infrastructure. The ORT-based infrastructure of Eclipse is planned to be used in the future. The web report is attached as a build artifact on the internal fork and not accessible by public currently.
Once the build workflow’s jobs are finished, the release workflow will finalize by attaching the release artifacts as assets to the release.

Note: While the build workflow and release workflows are in progress, the GitHub release page of that release does not show any other assets besides the source archives. The release artifacts (eclipse-leda-.tar.xz) will only be visible once all workflows have finished.

Provisioning with sdv-provision

Mon, 09 May 2022 14:24:56 +0530

Meta-leda and the Leda-quickstart image provide a utility sdv-provision that simplifies the device provisioning procedure.

Connecting to the device

Since the procedure includes copying and pasting device IDs, it is recommended to connect to the device over a ssh connection. sdv-motd provides an easy way to find your device’s ip. More information on connecting via ssh can be found here.

Provisioning via a connection string

Device-side

After connecting via ssh run sdv-provision.

SDV MotD

Mon, 09 May 2022 14:24:56 +0530

The sdv-motd script provides an alternative motd profile, which displays some additional information after login.

The script does not have any command line options.

Example output:

CAN Forward

Mon, 09 May 2022 14:24:56 +0530

The can-forward help script can be used to forward an existing CAN-Bus interface on the host system to a container process.

Note: Warning! The script does not yet support Kanto (or containerd) as a container runtime. It has been implemented for k3s.

Usage

root@qemux86-64:~# can-forward --help

Usage:  /usr/bin/can-forward {-h} {-p PID} {-c container} <hw_can>

  hw_can          Host CAN hw interface to forward. Default: can0
  -c container    Attemmpt to get netns PID from a running container: (docker, ctr). Default: seat_service
  -p PID          Use provided PID for transferring vxcan interface (e.g.: docker inspect -f '{{ .State.Pid }}' container)
  -h              Prints this message

The script performs the following steps:

Interact with Seat Adjuster

Mon, 09 May 2022 14:24:56 +0530

We interact with the seat application through MQTT messages to emulate the behavior of an offboard application. To see the responses from the seat adjuster app, subscribe to the MQTT topic `seatadjuster/#``.

mosquitto_sub -t 'seatadjuster/#' -v

To initiate the moving of the seat, publish an MQTT message for the seat adjuster application to set the position to 1000 (which is the equivalent of 100%):

mosquitto_pub -t seatadjuster/setPosition/request -m '{"position": 1000, "requestId": "12345"}'

You may need to open a second terminal session to send the message. In the QEMU setup, you can do this through an SSH connection from the host machine by running ssh -p 2222 root@localhost.

Kanto Auto Deployer (KAD)

Mon, 09 May 2022 14:24:56 +0530

Automatically deploys containers to the Kanto Container Management based on deployment descriptors from a given path. All deployment descriptors in the manifests folder will be deployed (created and started) on startup of the service. The directory will then be monitored for creation of/changes to manifests and those changes will be redeployed.

Usage

Usage:

$ kanto-auto-deployer --help
kanto-auto-deployer 0.2.0
Automated deployment of Kanto Container Management Manifests

USAGE:
    kanto-auto-deployer [OPTIONS] [MANIFESTS_PATH]

ARGS:
    <MANIFESTS_PATH>    Set the path to the directory containing the manifests [default: .]

OPTIONS:
    -d, --daemon                   Run as a daemon that continuously monitors the provided path for
                                   changes
    -h, --help                     Print help information
    -s, --socket-cm <SOCKET_CM>    Set the path to the Kanto Container Management API socket
                                   [default: /run/container-management/container-management.sock]
    -V, --version                  Print version information

Example:

SDV Container Exec

Mon, 09 May 2022 14:24:56 +0530

The sdv-ctr-exec wrapper allows to execute arbitrary user commands in existing containers. Kanto Container Management cli tool (kanto-cm) only allows to manage the lifecycle of a container, but does not allow to specify or override the entrypoint or command definitions of an existing container. The ctr command line tool of containerd allows the execution of additional tasks in a running container.

Usage

As a convenient tool, sdv-ctr-exec allows the simple execution of arbitrary commands inside of containers. This is especially useful for non-service-containers, or containers which have additional binaries (e.g. cli tools) embedded.

Privacy Information

Mon, 09 May 2022 14:24:56 +0530

Your privacy is important to us. The following Information is to provide you with all information relevant to data protection in order to be able to use the software, in a data protection compliant manner. It is provided as an information source for your solution-specific data protection and data privacy topics. This is not intended to provide and should not be relied on for legal advice.

Your Role

First things first: when you choose and use our software, you are most likely acting in the role of data controller, if personal related data is being processed. Therefore, you must ensure that the processing of personal data complies with the respective local legal requirements, e.g. when processing data within the scope of General Data Protection Regulation (GDPR) the legal requirements for a controller from the GDPR.

CAN Setup for Seat Adjuster

Mon, 09 May 2022 14:24:56 +0530

Within the seat adjuster guide, we so far mocked the behavior of the actual vehicle. In the following, we give an overview of how to create a virtual CAN-bus and interact with it to send CAN-frames for moving a seat.

Instead of the mock service you use the seat service as a provider, which is another pre-installed container acting as the connection between the KUKSA Databroker and the underlying hardware. More specifically, it subscribes to the target value of the Vehicle.Cabin.Seat.Row1.Pos1.Position signal, can send CAN-frames, and updates the current value of the signal in small steps until it is equal to the target value. For more details, visit the Kuksa.val.services repository, which hosts the code for the seat service.

Cheatsheet

Mon, 09 May 2022 14:24:56 +0530

This cheat sheet gives you an overview of common command line commands to interact with the tools available on the quickstart image.

General Commands

Category	Task	Command
General	Overall info	`sdv-health`
	Show device info	`sdv-device-info`
	Device provisioning	`sdv-provision`
	Switch Keyboard layout	`loadkeys de`
System	System load	`htop`
	Disk free	`df -h -t ext4`
	Memory free	`free -h`
Network	Interfaces summary	`networkctl`
	Ethernet status	`networkctl status enp0s2`
	Routing table	`route`
	Active listeners	`netstat -l -n -t`
	Multicast for Some/IP	`route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0`
Kanto-CM	Show all containers	`kanto-cm list`
	User interface	`kantui`
	Service logs	`journalctl -f -l -t container-management`
	Auto deployments	See `/data/var/containers/manifests/`
	Development deployments	See `/data/var/containers/manifests_dev/`
	Restart a container	`kanto-cm restart -n <containername>`
	Manage config	`sdv-kanto-ctl`
	Shell in container	`sdv-ctr-exec <containerId> <command>`
	Add Private Registry	`sdv-kanto-ctl add-registry -h <host> -u <user> -p <pass>`
ContainerD	Show images	`ctr --address /data/run/containerd/containerd/containerd.sock --namespace=kanto-cm i ls`
	Import local archive	`ctr --address /data/run/containerd/containerd.sock --namespace=kanto-cm i import <docker.tar>`
	Prune containers	`nerdctl system prune --all`
Mosquitto	Show all messages	`mosquitto_sub -v -t '#' -h localhost`
	Send message	`mosquitto_pub -t '<target/topic>' -h localhost -m '{"foo":"bar"}'`
	Connectivity status	`mosquitto_rr --quiet -h localhost -t 'edge/thing/request' -e 'edge/thing/response' -m ''`
RAUC Self Update	Current boot status	`rauc status`
	Switch to other boot slot	`rauc status mark-active other`
CAN-Bus	CAN Dump	`candump -l any,0:0,#FFFFFFFF`

Configuring NTP

A failed download of container images may be caused by out-of-sync clock, thus failing the TLS certificate validation. A hardware device without hardware clock (such as the Raspberry Pi) relies on network time. In some (corporate) networks, there might be rogue NTP servers and it might be necessary to override the NTP sources.

Security Policy

Mon, 09 May 2022 14:24:56 +0530

This project implements the Eclipse Foundation Security Policy

https://www.eclipse.org/security

Reporting a Vulnerability

Please report vulnerabilities to the Eclipse Foundation Security Team at security@eclipse.org

Supported Yocto Versions

Version	Supported
Yocto 4.x (Kirkstone)	Yes
Yocto 3.4 (Honister)	EOL
Yocto 3.3	Untested
Yocto < 3.3	No

Important: When you use the quickstart images for non-volatile setups, it is essential to reconfigure the system and harden it.

Configuration Items

Disable system user (root) password and login
Disable SSH login with password
Adding a new Linux user with restricted permissions
Adding SSH key based authentication
Container Secrets
- Device identity certificates for cloud connection
- Access credentials for private container registries

Device Identity for Cloud Connector

Method	Implementation	Intended use
Pre-Shared Symmetric Key	Azure IoT Hub Connection String	Development
Certificates	X.509 Certificates	Production

SDV Kanto-Ctl

Mon, 09 May 2022 14:24:56 +0530

Manage the Kanto Container Management configuration via CLI.

Note: Requires jq to be installed.

Features:

Add and remove container registries (for authentication purposes)
Set primitive values in configuration
Restart container-management.service on configuration changes
Automatically back up configuration file
Display changes to user

Usage

Synposis: ./sdv-kanto-ctl <command> [<options>]

Full help:

$ ./sdv-kanto-ctl --help
Eclipse Kanto Container Manager Configuration Utility
See https://eclipse.dev/kanto/docs/references/containers/container-manager-config/
Usage: ./sdv-kanto-ctl <command> {options}
Commands:
        add-registry -h <hostname> -u <username> -p <password>
                Adds or replaces a container registry authentication configuration
                -h or --hostname: Configure the hostname of the container registry (e.g. hub.docker.io, ghcr.io, ...)
                -u or --username: Configure the username
                -p or --password: Configure the password
        remove-registry -h <hostname>
                Removes the specified container registry
                -h or --hostname: The hostname of the container registry
        remove-all-registries
                Removes all configured container registries
        list-registries
                Prints all configured container registries
        show-config
                Print the container management configuration
        set <key> <value>
                Set a primitive configuration value. Key in JSON Dot-Notation
                Examples: ./sdv-kanto-ctl set containers.registry_configurations.MyRegistry.credentials.password foobar
                          ./sdv-kanto-ctl set things.enable true
Options:
        --no-reload : Do not reload the configuration and restart the container-management service automatically
        --ansi : Don't use colored output.
        --verbose | -v : Enable verbose mode.
        --help : This message.

Example: Private Container Registries

Blueprint Selector

Mon, 02 Oct 2023 12:43:16 +0000

A Rust application that reads all blueprint files in a directory and provides the user with an interactive (supports filtering) menu to select the one to be deployed on the edge device via MQTT. If no directory is provided the default one on a Leda Quickstart Image is: /data/var/containers/blueprints.

The “blueprint” files are desired state messages, that have the extension “.blueprint.json” (configurable) and an additional metadata header (required):

{
  "blueprintMetadata": {
    "name": "<NAME>",
    "description": "<Short Description>"
  },
  "activityId": "correlation-id",
  "timestamp": 1235466
  "payload": {} // This is the desired state message
}

The metadata header will be used to construct the list of options presented to the user. You can find example blueprints under the example_blueprints directory in the leda-utils repository.

Release Plan 0.1.0

Wed, 12 Apr 2023 14:24:56 +0530

The release plan is available at https://projects.eclipse.org/projects/automotive.leda/releases/0.1.0

Release Date

-Thursday, June 1, 2023- - We didn’t meet the planned release date. Work is in progress on IT build infrastructure and OSS IP and license compliance.

New: Tuesday, August 1, 2023

Deliverables

The team plans to deliver the following features:

Leda Quickstart Images for Qemu (x86_64, arm64), Raspberry Pi and Docker
Yocto / OpenEmbedded meta-layer for better reusability of the Eclipse SDV Vehicle.Edge stack in customized distributions for constrained devices
User documentation (Reference, Example Use Cases)
Automated system tests using Robot Framework
IP scanning with Eclipse Oniro Compliance Toolchain
Pre-Integrated Eclipse SDV Vehicle.Edge stack

The core SDV.EDGE stack in Leda would contain the following components for the first release (based upon availability):

Connecting to Wi-Fi networks

Tue, 03 Jan 2023 17:24:56 +0530

Here we will describe the basic steps on how to identify and connect to a WiFi network in interactive or headless mode.

Initial steps (identifying wlan interfaces)

Start by running:

$ ip a
 ...
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether <MAC> brd ff:ff:ff:ff:ff:ff
...

Note: Usually the name of the interface would be wlan0. It might however follow the newer “predictable interface names” standart. Then the interface name would start with wl* with the remaining characters identifying a physical bus/chip/number/etc corresponding to the interface. For simplicity we will wlan0 in all examples below.

Mon, 01 Jan 0001 00:00:00 +0000

Download latest Eclipse Leda release
Run Eclipse Leda
- on emulated Qemu devices or
- on Raspberry Pi 4
Configure device, e.g. provision the device
Explore the device tools
Develop your first Vehicle App using Eclipse Velocitas template
Deploy a Vehicle App to the device

Mon, 01 Jan 0001 00:00:00 +0000

ORT Scan Report

Leda on Eclipse Leda Documentation

Configuration

Config file

Minimal configuration

Milestone 0.1.0-M1

Release Notes

Communicating with Кanto-CM via gRPC

Dependencies

sdv-health

Checking the status of kanto-cm containers

Advanced topics

Git Authentication

CAN Bus

QEMU

Enabling Virtual CAN Bus interfaces (vcan)

Enabling CAN Bus interfaces (can)

Standalone CAN within Qemu

Cloud Connectivity

Simulation of cloud connectivity

Concepts

Build Setup

Resource Consumptions

Baseline (no apps installed)

Component Details

SDV Health

Health check

Version Information

Self Update Tutorial

Self-Update using RAUC Update Bundles

Transferring Files

Sharing a directory with the guest

Pre-Requisites

Transfering files from host to guest

Validating

Validating the release

VSCode DevContainer

Preparation

Visual Studio Code: Development Containers

Container Update Agent

About the Container Update Agent (CUA)

Message Flow

Milestone 0.1.0-M2

Release Notes

Kanto Auto deployer (KAD)

Architecture of Seat Adjuster

CAN-Bus extensions

MCP2515 based modules

MCP2518FD based modules

Features

KantUI

Kanto User Interface

Command Line Options

Keyboard commands

Manual Provisioning

Create a device in Azure IoT Hub

Metalayer

Initializing BitBake environment

Building specific recipes

Metalayer Structure

Base Bundle

RAUC Integration

Checking the RAUC Status

Forcing to boot the other slot

Kantui

Development notes

Building with kas/manually

Building with kas

Building manually

Dependencies

Develop Seat Adjuster

Goals

Orchestration

Container Management

Run the build

Run the full build

Running QEMU from existing build

Variations of runqemu command line

Running QEMU in the background

SDV Device Info

Usage