Proposals

Eclipse Epicyro implements Jakarta Authentication, a technology that defines a low-level SPI for authentication mechanisms, which are controllers that interact with a caller and a container’s environment to obtain the caller’s credentials, validate these, and pass an authenticated identity (such as name and groups) to the container.

Eclipse Epicyro provides default implementations of these authentication mechanisms and algorithms, as defined and mandated by the Jakarta Authentication specification.

Eclipse BlueChi is built around three components:

• The hirte service, which is the primary controller that runs on the primary node
• The hirte-agent services, which run on each managed node and are the agents that talk locally to systemd to instruct systemd to act on services
• The hirtectl command line, which is used by administrators to test, debug and manually manage services across nodes

Eclipse BlueChi is meant to be used in conjunction with a state manager (a program or person) that knows the desired state of the systems. This design choice has a few consequences: 

• Eclipse BlueChi does not know the desired final state of the systems; it only knows how to transition between states, such as how to start, stop or restart a service on one or more nodes 
• Eclipse BlueChi monitors and reports changes in the services that are running and alerts the state manager when a service stops or when the connection to a node is lost, but hirte itself does not act on these notifications
• Eclipse BlueChi does not handle the initial setup of the system; the system boots into a desired state and hirte handles the transitions from this state

The state manager program integrates with hirte over D-Bus. The state manager tells hirte to perform actions or to receive the outcome of actions. Eclipse BlueChi monitors services and nodes via D-Bus and reports state changes back to the state manager. Administrators can use the hirtectl interface to avoid interacting directly with hirte via D-Bus.

Eclipse Langium is a toolkit for domain-specific languages (DSLs) that is fully built with TypeScript. It provides a text parser with integrated cross-reference resolution and a language server for smart editor support. You can use Langium to build custom text languages that can be automatically processed. For example, you can execute user-defined behavior with an interpreter, or generate executable code, documentation, or other output formats. Such a custom language can

• empower non-technical persons to provide data, logical constraints, executable behavior, or similar concepts,
• greatly reduce the manual effort to create artifacts such as source code or documentation,
• strengthen the communication between stakeholders with a formal language.

Eclipse Langium aims to enable DSL development in a web-based technology stack. When used in the context of a desktop app (e.g. VS Code, Eclipse IDE, etc.), Langium runs on the Node.js platform. Additionally, it can run in a web browser to add language support to web applications with embedded text editors (e.g. Monaco Editor). The interface between Langium and the text editor is the Language Server Protocol (LSP).

The entry point of a Langium project is the grammar language – similarly to how Eclipse Xtext works. A grammar file describes the concrete syntax by instructing the parser how to read input text, and also the abstract syntax by defining object types and their properties. The resulting abstract syntax tree (AST) is created by the parser that Langium provides based on the grammar declaration. The AST is the basis for all further operations, including cross-reference resolution, validation, code generation and much more.

In addition to editor support through LSP, a Langium-based language implementation can be used as a library to implement automation processes: interpret (execute) language instances, generate different artifacts, transform into specific modeling formats, and so forth – there are vast possibilities that can be explored depending on your project context and the specific problems you would like to address.

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.

The Eclipse Documentation for Jakarta EE project hosts documentation intended for programmers interested in developing and deploying Jakarta EE applications. It covers the technologies comprising the Jakarta EE platform and describes how to develop applications using Jakarta EE components and deploy them on the Eclipse GlassFish and other popular runtimes.

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.

The Eclipse Dataspace TCK will consist of a modular test harness that can be extended to verify multiple Dataspace protocols and standards. The core framework is written in Java but can verify runtimes and services implemented in other programming languages. The framework is designed to be run in various contexts, such as a development command line, a continuous integration pipeline, or an online service.

The Eclipse Dataspace TCK's first compliance extension will be for the IDS Datasapce Protocol (https://github.com/International-Data-Spaces-Association/ids-specification). This compliance extension will test all normative statements in the protocol specifications. Specification implementors will be able to run the tests against their software to assist in development and to provide an independent mechanism to validate conformance.   

Eclipse XFSC (Cross Federation Services Components) develops the software components necessary to set up a federated system that interconnects several participants in a data and service infrastructure with each other, aiming to develop new data-driven services and innovative products. Such ecosystems consist of joined interconnected data and infrastructure ecosystems, aggregated in so-called Federations that are individually orchestrated and operated with the help of Federation Services, part of Gaia-X.

It consists of several components (mainly microservices) enabling federations in data ecosystems and providing interoperability across federations.

The Eclipse XFSC Toolbox provides a set of services for the functional implementation of Self Sovereign Identities, W3C credential management, Trust Services, database functions for knowledge graphs, usage policy negotiation and a core Low Code Engine. The main purpose is the operational uptake of federations as decentralized ecosystems.

Eclipse XFSC is to be seen as the implementation of a suite of solutions – providing for the minimum technical requirements to empower Federations to become operational and to allow organizations to participate in a world of Self Sovereign Identity and data ecosystems. The Eclipse XFSC toolbox defines a range of components necessary to fulfil the Gaia-X’s objective of building trust and interoperability, and ensuring participants retain sovereignty over their data. Concretely, the first set of services delivered are:

Identity & Trust

These services empower federations to authenticate and authorize participants in a federation, for example via credential validation, and cover technology functionalities to ensure a consistent level of trust between all Participants of a federation.

• Authentication & Authorization Service (AAS)
• Personal Credential Manager (PCM)
• Organization Credential Manager (OCM)
• Trust Services (TRU)
• Notarization Service (NOT)

Self-Description/Catalogue

The Federated Catalogue is the repository of one Federation, enabling participants to find other participants’ information and service offerings in the shape of the Self-Descriptions. The toolbox provides the basic code for each Federation to build their own Federated Catalogue. Once a service offerings has been found, the toolbox also provides services that can facilitate contract negotiations and keep track of data transactions within Federations. These will empower Participants to determine and keep track of how their data is used through different transactions.

• Federated Catalogue (CAT)
• Self-Description Wizard (SD-Wizard)
• Data Contract Transaction (DCT)
• Data Exchange Logging Service (DELS)

Tooling

The Toolbox also contains services supporting federations with handy functionalities to organize itself. E.g., the Portal serves as a sample integration layer showcasing the Federation Services and providing user-friendly access to these services. A Workflow Engine is delivered aiming at improving complex application networking, e.g., the implementation and configuration of Onboarding & Accreditation workflows for federations. Furthermore, it contains functionalities for sample service orchestration and provisioning as well as compliance monitoring based on EUCS metrics.

• Portal (POR)
• Workflow Engine (WFE)
• Continuous Automated Monitoring (CAM)
• Orchestration (ORC)