Eclipse Software Defined Vehicle

Eclipse OpenXilEnv is a lightweight SIL/HIL environment that allows running embedded software functions on a PC without a target platform and compiler.

Eclipse OpenXilEnv will provide a configurable graphical user interface and an API for automation.

Use case scenarios:

• Software in the Loop
• Model in the Loop
• Open Loop
• Hardware in the Loop
• Module tests
• Network tests
• Complete digital twin test
• Manual tests
• Automated tests
• Rapid prototyping
• Offline calibration

Some highlights are:

• Easy integration of the code under test
• Clean separation in own executables (memory protection) Communication over a network layer
• Platform independent (Windows/Linux)
• User interface (Qt) with a lot of display items (text, oscilloscope, tacho, ...),  items for manual intervention (text, slider, knob, ...)  and calibration items for single, curve and map parameters
• Tree view of all static parameter and variables (debug information)
• Can be extensively automated with a remote procedure call interface (Python) or a build-in script interpreter
• GUI less variant exist for automation (Headless Variant)
• Parallel execution (multi core) of test code 
• Support of FMUs with FMI2.0 interface (64 and 32 bit)
• Residual bus simulation of non-existing CAN (FD) bus members
• Recording and replay in stimulation is possible with text or MDF3 files
• Debug information parser (dwarf)
•  A small A2L parser is included for calibration.A XCP over ethernet port to connect a calibration system
•  Parallel execution (multi core) support with barriers for synchronisation.

OpenXilEnv was developed and maintained at ZF for the last 25 years and used in numerous projects.

Eclipse Autowrx is the open source implementation of digital.auto (http://digital.auto), an industry-wide initiative enabling the automotive industry to establish a new, digital-first approach for the creation of next-generation customer experiences and data-driven mobility services. Designed as an open ecosystem with a very use-case-centric approach, digital.auto is bringing together automotive original equipment manufacturers (OEMs), suppliers and partners to drive transformation of the industry. The global initiative builds on two key pillars of automotive technology development: the software-defined vehicle (SDV) and standardized vehicle APIs. Eclipse Autowrx aims to combine existing standards with appropriate methods and best practices to translate technology into business value. Co-initiators include Robert Bosch GmbH as well as software companies Dassault Systèmes and LeanIX. The initiative is hosted by Heilbronn-based Ferdinand-Steinbeis-Institut (FSTI) as a neutral, non-profit facilitator and was launched in November 2022.

The ultimate goal of Eclipse Autowrx is to support digital value creation for OEMs in close alignment with the development of the physical elements of the vehicle.

The Eclipse SDV Blueprints project hosts different blueprints of how to apply technologies developed in the scope of the projects of the Eclipse SDV working group (sdv.eclipse.org). This makes it possible to highlight the capabilities and features of the software provided by the Eclipse SDV working group and explore potential for collaboration and integration of these technologies.

A blueprint is an examplatory use case implementation based on artifacts created in the scope of participating SDV projects and adjacent OSS technologies together with some blueprint specific code that ties it all together.

Adopters of a blueprint can then see all the moving parts and can participate in the future development of the software to ensure it meets their future needs as well. With these blueprints, the goal is not to define how everyone will tackle these problems, but to get something usable out, see how people make use of it, and to get feedback on it. This feedback can either be channeled backed into the blueprint or forwarded to the utilized projects.

Eclipse Ankaios manages multiple nodes and virtual machines with a single unique API in order to start, stop, configure, and update containers and workloads. It provides a central place to manage automotive applications with a setup consisting of one server and multiple agents. Usually one agent per node connects to one or more runtimes that are running the workloads.

Eclipse Ankaios follows the UNIX philosophy to have one tool for one job and do that job well. It does not depend on a specific init system like systemd but can be started with any init system. It also does not handle persistency but can use an existing automotive persistency handling, e.g. provided by AUTOSAR Adaptive.

The workloads are provided access to the Eclipse Ankaios API using access control and thus are able to dynamically reconfigure the system. One possible use case is the dynamic startup of an application that is only required in a particular situation such as a parking assistant. When the driver wants to park the car, a control workload can start the parking assistant application. When the parking is finished, the parking assistant workload is stopped again.

Eclipse Ankaios also provides a CLI that allows developers to develop and test configurations. In order to gain compatibility with Kubernetes, Eclipse Ankaios accepts pod specifications.

A cloud connector can use the Eclipse Ankaios API to connect to a cloud-based software update system, which allows an OEM to manage a fleet of vehicles and provide new states to Eclipse Ankaios in order to update single or all applications. The cloud connection is optional, Eclipse Ankaios also works as standalone component.

In order to support the Automotive SPICE process, Eclipse Ankaios comes with requirements tracing supported by OpenFastTrace.

Connecting Automotive Apps and Services, Everywhere

A software defined vehicle requires the design and development of software entities  (uEs) that are distributed by nature and deployed in many different os/hw environments such as vehicle-mechatronics, vehicle-high-compute SoCs, mobile phones, infrastructure, the cloud, etc.... 

Every environment have their own software development languages, deployment platforms, and communication protocols making application and service development for connected vehicles very complex. Currently there are no common protocols that cross automotive and cloud boundaries as many of the existing messaging/RPC solutions come with various pro's and cons not to mention their own "baggage" (i.e. it works in the cloud but not for safety critical ASIL-D use cases and vice versa. Furthermore, given the lack of connections between the embedded automotive and Internet/cloud worlds, there is no standard way to safely discover, connect, and communicate with software between these environments so OEMs are left with implementing proprietary solutions.    

The purpose of this project shall be to provide the reference Android implementation of uProtocol that runs on top of AAOS (Android Automotive OS)