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

Return to the regular view of this page.

About Leda

The Eclipse Leda project will provide system image “recipes” to deliver a functional Linux-based image/distribution in the context of SDV (Software Defined Vehicle), by pulling together individual contributons from the SDV and the larger OSS community.

The Eclipse Leda distribution will work with build scripts, package definitions, image build pipelines, etc, with the goal to pull SDV projects and dependecies from the larger OSS community into a working Linux system. Such system images (or other useful forms of delivery, as determined by the project) will be made available for consumption for anyone who is interested in working with the SDV tech stack. These deliveries take the form of container (base) images, installable/flashable image files, etc (again to be evolved by the project team according to community needs). Also in scope is concise and useful documentation for consumers of the project’s deliverables, plus a method of delivering that documentation.

In the context described above - the ambition of SDV to build a technology ecosystem for software-defined vehicle concern - a prime challenge will be the combination of these initially diverse components into a coherent and useful whole: all the software components in the world will not have the impact needed to transform the automotive industry unless we can make them play together coherently an form a functional portfolio. As a first step towards that goal, this proposal (Eclipse Leda) is for a “SDV distribution” project that pulls together individual contributor pieces from SDV and the larger OSS community, to deliver a functional and always-available Linux-based image/distribution with two primary goals:

  • be the crystalization point for functionally integrating diverse SDV-scope projects into a working whole

  • deliver a continually available, always working starting image for developers interested in getting going with the SDV tech stack

1 - Architecture

Runtime Overview

Eclipse Leda SDV Reference Implementation

The runtime overview shows the general layer architecture for the runtime of the SDV edge stack as implemented by the Leda quickstart image. Dotted lines indicate out-of-scope components. They may be non-Edge components (such as cloud services, or SDKs and additional development tooling for vehicle applications). Dotted lines for in-vehicle edge components indicate that they may be used, but are not pre-installed or pre-configured on the Leda quickstart image.

Deployment Overview

Eclipse Leda can be used in different deployment scenarios: on physical hardware, on virtual machines or installed on existing Linux distributions. Depending on the specific deployment, some features may not be applicable. Each deployment option is meant for different uses. The applicabability depend to your specific requirements.

Eclipse Leda Quickstart Deployment View

  • Option 1: Hardware - Suitable for proof-of-concepts, system integration tasks, access to actual physical actuators and sensors. However, an automated setup is much harder to realize, as additional hardware for remote controlling of power supply is needed. The constrained environment of a physical device is good to verify accidental assumptions made by application developers, such as resource consumptions (CPU, memory) or the existence of Linux tools, Kernel modules or device drivers.
  • Option 2: Docker Containers - Good for quick startup and throw-away (ephemeral) uses, such as automated system testing or one-off troubleshooting. The access to physical hardware is limited and more complicated to set up. QEMU provides emulation of devices, such as CAN-Bus. Due to multiple nesting of abstraction technology (Docker + QEMU + OS), additional configuration of networking and device pass-thrus are necessary. It’s easy and cheap to spin-off many separate instances to simulate a whole vehicle system with multiple vehicle computers and simulated ECUs in the same vehicle network.
  • Option 3: Package Installation - Good for existing devices with feature-rich functionality where the original OS should be used. Leda does not support self-update for this deployment option, as it relies on the master OS distribution channels. The constraints of an embedded device are not replicable easily on a PC-style host machine without additional effort. Package installation is good when the focus is on exploring the Vehicle Applications, SDKs, Vehicle Signal Abstractions etc.
Option 1: Hardware Option 2: Docker Containers Option 3: Package Installation
Target use case PoC Automation Existing devices
Cloud communication ++ ++ +++
Automation – +++ ++
Device provisioning ++ ++ +++
Access to hardware +++ - ++
Container isolation +++ ++ +++
Network flexibility +++ - ++
Self update +++ + –
Realistic constrains +++ - -

Build Environment Overview

Eclipse Leda Build Infrastructure View

2 - Features

  • 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
  • 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:

  • Build recipes for a Yocto-based distribution to build SDV-related software components
  • Build recipes for customizations of the target device’s storage structure to enable A/B system updates
  • Build recipes for pre-packaging container images into the device during the manufacturing process to minimize initial online provisioning time
  • A customized minimal setup for use on constrained devices and a full setup with convenient developer tools
  • Ready images for virtual devices, for automated testing and evaluation purposes, eg QEMU ARM-64
  • Ready images for physical devices, for evaluation and demo purposes, eg Raspberry Pi 4

3 - Goals

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.

Overview

  • Provide an example operating system build and configuration for constrained in-vehicle devices: Suppliers and system integrators want a way to cusomize and optimize the base operating system as much as possible. This is to achieve a high efficiency, high level of reuse and cost benefits of the planned hardware. The build system for the operating system, and the selection of the underlying distribution is key to the convenience for new users, but also commercially a business decision with an impact on the future maintainability of the platform. The Yocto Project has been chosen as an established de-facto standard for customized Linux distributions for embedded systems. Leda provides an OpenEmbedded Meta-Layer, which can be used with many existing SDKs of SoC manufacturers. Additionally, Leda will strive for being easy to install on low-cost “evaluation boards” such as the Raspberry Pi, or development environments such as a virtual machine in the cloud.
  • Integrate software-defined-vehicle Open Source components to showcase the available features and their state of maturity: The SDV ecosystem will grow and a lot of new software projects will be needed to solve the current problems and challenges. The Eclipse SDV ecosystem already contains many software packages, which independently make sense for their set goals. With Leda, we want to increase the integrational aspect, helping project leads, developers, contributors, users and architects to evaluate the SDV portfolio, how it can be integrated with each other and how a possible reference architecture implementation might be loooking like.
  • Demonstrate the use and interaction of open protocols and specifications:
    • Vehicle Signal Specifications from the The Connected Vehicle Systems Alliance (COVESA) to establish a semantically useful abstraction model for vehicle signals.
    • OpenTelemetry specs and components, to show the possibilities of applying DevOps methodologies and technologies to operate, monitor and maintain fleets of vehicles and their distributed software applications
    • Eclipse IoT related specifications for software rollouts and digital twin representations

4 - Roadmap

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

Exemplary future work:

  • Migrate to official Eclipse Kanto releases for Cloud Connector, Container Management and Vehicle Update Manager
  • Include reference implementations from the Eclipse Software Defined Vehicle working group projects:
    • Eclipse Velocitas
    • Eclipse Kuksa
    • Eclipse SommR
    • Eclipse Chariott
    • Eclipse Muto
    • Eclipse Backend function Bindings (BfB)
    • Eclipse SDV Blueprints
  • Include and showcase more features regarding development, operation and monitoring of Vehicle Services and Vehicle Applications

If you have feedback, please use GitHub Issues

5 - Releases

The Eclipse Leda project follows the Eclipse Release process. Please see Eclipse Project handbook for details about the process.

The release plans overview for Eclipse Leda is available at https://projects.eclipse.org/projects/automotive.leda/governance

5.1 - Milestone 0.1.0-M1

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.

Minimal feature set to run software-defined-vehicle applications (such as Eclipse Velocitas apps) using COVESA Vehicle Signal Specification and the Eclipse Kuksa.VAL Databroker on virtual devices (QEMU), in Docker, or on physical consumer-grade devices (Raspberry Pi 4 64-Bit) for development, demonstration and prototyping purposes.

Includes example applications from Kuksa:

  • Example Seat Service
  • Example HVAC Service
  • DBC Feeder replays a Tesla Model 3 CAN-Dump and feeds it into Kuksa.VAL Databroker

Change log

  • Replaced k3s with Eclipse Kanto Container Management
  • Replaced packages licensed under GPLv3 and similar licenses with alternatives
    • Replaced Grub with U-Boot
    • Replaced nano with kibi
    • Removed readline library
    • Removed bash
  • RAUC Updates
    • Bundles available for each image type (Full, Minimal, Rescue)
    • Enabled verity format by default
    • Fixed the compatible configuration string
  • Added and updated Leda utilities
  • Build infrastructure improvements
    • Builds for Dockerized images
    • Switched to a BitBake build using kas for layer management
    • Added automated system tests using Robot framework and Dockerized environments
    • General cleanup of recipes, dependencies and structuring of the meta-leda sublayers to improve reusability
  • Automatic deployment of containers based on container manifests with ad-hoc updates (filewatcher in kanto-auto-deployer)
  • Preparation for AirGap installation of containers
  • General improvements, such as Wifi network management

Known Issues

The following issues were known to the development team before starting the 0.1.0-M1 build cycle. They have been prioritized as non-critical and may be fixed for later releases.

OSS IP Compliance Report

Report scan-report-web-app_0.1.0-M1.html

  1. Incorrectly detected license “biosl-4.0”

    • Rule: OCaaS Policy A9 License with no classification
    • Message: The license LicenseRef-scancode-biosl-4.0 found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is not categorized and / or evaluated for usage.
    • Evaluation: This license seems to be detected incorrectly by the tool being used, as it is an internal, proprietary license which is not used in the Eclipse Leda project.

  2. Incorrectly detected license “GPL-1.0” for ORT configuration file

    • Rule: OCaaS Policy C1 Strict Copyleft
    • Message: License GPL-1.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
    • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under GPL-v1.0

  3. Incorrectly detected license “GPL-2.0-only” for standard Leda license header (which is Apache Software License)

    • Rule: OCaaS Policy C1 Strict Copyleft
    • Message: License GPL-2.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
    • Evaluation: The scan tool incorrectly detects the Apache License header as GPL-2.0 license text

  4. Incorrectly detected license “proprietary”

    • Rule: OCaaS Policy C3 Commercial
    • Message: License LicenseRef-scancode-proprietary-license found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as commercial and requires special handling.
    • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under proprietary licenses.

5.2 - Milestone 0.1.0-M2

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.

Minimal feature set to run software-defined-vehicle applications (such as Eclipse Velocitas apps) using COVESA Vehicle Signal Specification and the Eclipse Kuksa.VAL Databroker on virtual devices (QEMU), in Docker, or on physical consumer-grade devices (Raspberry Pi 4 64-Bit) for development, demonstration and prototyping purposes.

Includes example applications from Kuksa:

  • Example Seat Service
  • Example HVAC Service
  • DBC Feeder replays a Tesla Model 3 CAN-Dump and feeds it into Kuksa.VAL Databroker

Change log 0.1.0-M2

  • Remove skopeo dependency from packagegroup-sdv-tools.bb
  • Fix typo in SRCREV_FORMAT for pahocpp
  • dd kernel config for RAUC stream mode to raspberrypi4-64 and qemuarm64
  • Adding extra space in RPi for RAUC updates
  • Backport Go 1.20 from Poky Mickledore
  • Adding seatadjuster-app
  • seatadjuster-app distribution

Change log 0.1.0-M1

  • Replaced k3s with Eclipse Kanto Container Management
  • Replaced packages licensed under GPLv3 and similar licenses with alternatives
    • Replaced Grub with U-Boot
    • Replaced nano with kibi
    • Removed readline library
    • Removed bash
  • RAUC Updates
    • Bundles available for each image type (Full, Minimal, Rescue)
    • Enabled verity format by default
    • Fixed the compatible configuration string
  • Added and updated Leda utilities
  • Build infrastructure improvements
    • Builds for Dockerized images
    • Switched to a BitBake build using kas for layer management
    • Added automated system tests using Robot framework and Dockerized environments
    • General cleanup of recipes, dependencies and structuring of the meta-leda sublayers to improve reusability
  • Automatic deployment of containers based on container manifests with ad-hoc updates (filewatcher in kanto-auto-deployer)
  • Preparation for AirGap installation of containers
  • General improvements, such as Wifi network management

Known Issues

The following issues were known to the development team before starting the 0.1.0-M1 build cycle. They have been prioritized as non-critical and may be fixed for later releases.

OSS IP Compliance Report

Report scan-report-web-app_0.1.0-M1.html

  1. Incorrectly detected license “biosl-4.0”

    • Rule: OCaaS Policy A9 License with no classification
    • Message: The license LicenseRef-scancode-biosl-4.0 found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is not categorized and / or evaluated for usage.
    • Evaluation: This license seems to be detected incorrectly by the tool being used, as it is an internal, proprietary license which is not used in the Eclipse Leda project.

  2. Incorrectly detected license “GPL-1.0” for ORT configuration file

    • Rule: OCaaS Policy C1 Strict Copyleft
    • Message: License GPL-1.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
    • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under GPL-v1.0

  3. Incorrectly detected license “GPL-2.0-only” for standard Leda license header (which is Apache Software License)

    • Rule: OCaaS Policy C1 Strict Copyleft
    • Message: License GPL-2.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
    • Evaluation: The scan tool incorrectly detects the Apache License header as GPL-2.0 license text

  4. Incorrectly detected license “proprietary”

    • Rule: OCaaS Policy C3 Commercial
    • Message: License LicenseRef-scancode-proprietary-license found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as commercial and requires special handling.
    • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under proprietary licenses.

5.3 - Release Plan 0.1.0

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):

  • Eclipse Kuksa.VAL: Data Broker
  • Eclipse Kanto: Container Management, Vehicle Update Manager
  • Eclipse Leda Incubator: Cloud Connector (Azure), Self Update Agent, Utilities (e.g kantui)

The following components are not yet released in public or did not yet finished the project review, and may only be added to the release on shorter notice:

  • (Eclipse Backend-Function-Bindings)
  • (Eclipse SommR)
  • (OTA Client)

Compatibility

Compatibility to previous versions is not considered for this first release.

Internationalization

No efforts towards i18n are done in this release.

Target Environments

  • Linux (virtual, qemu)
  • Raspberry Pi 4 (consumer grade)