Proposals

Eclipse Tocandira is a collection of tools aiming to help industries to remove their barriers on observability. To achieve this goal it uses the cutting edge technologies in the field. You will find the deploy easily configured with Docker, the connectivity with PLCs powered by 4diac, the gathering and storage done by Prometheus and the visualization shown with Grafana.Ec

Eclipse Tocandira was build focusing on:

• Reusability: Every technology chosen for this stack is the cutting edge of its field and the majority of them are well known in the IT world.
• Microservice Based: All services composing this application are truly independent and linked only by configurations, APIs and protocols.
• Cloud Native Architecture: These packages are usually applied for observability in IT world, and are therefore fully compatible with cloud environments, from instances to databases
• Small servers: Its components can run though several machines and consume little resources. It even runs on single board computers.
• Unlimited storage: Enough of charging for every variable read, the limit is only your hardware or the cloud capacity.

Eclipse SDV Developer Console (DCO) integrates necessary sources for software lifecycle management and there by optimizes the complete process from development to release of software. The core of DCO includes services for development, testing, simulations, release and lifecycle management of software. Hereby, DCOs mission is to automize as much as possible by using different concepts of re-usability and standardization by connecting different business roles along the software lifecycle on one source. As our open-source contribution, we focus on simulation of services with DCO.

With DCO you benefit from the concepts of standardization and re-usability. You can directly experience the scenario simulation in your productive environment. For instance simulate vehicle or fleet behaviours or use your own virtual vehicles or simulators to simulate backend services.

DCO comes with an user interface and related endpoints for backend interactions for defining your scenario, creating your simulation setup and to simulate your set of scenarios. In addition, your tool chain can be easily integreated to trigger a simulation with third-party applications, to analyze the simulation result and track the defects with your devops toolchain as well as the integration of applications for reporting and monitoring.

Eclipse Store provides a Java micro persistence layer built for cloud-native microservices and serverless functions written in Java. Eclipse Store is based on the system prevalence architectural pattern. It enables seamlessly storing any Java objects of any size and complexity transaction-save into cloud blob stores such as AWS S3 or any other binary data storage. Therefore, Eclipse Store provides connectors to various relational and NoSQL database systems. ACID transactions are journaled and changes in the system state are regularly saved to disk (deltas only). All transactions are stored in a highly optimized serialization byte format appended to the storage. To reduce startup time and run also with a small RAM capacity, Eclipse Store provides lazy loading. At the system start, only object IDs must be loaded into memory. Related object references (subgraphs) are only loaded and restored in memory on demand by calling common get methods. The Java Streams API is used for searching and filtering data in memory. Eclipse Store provides object versioning, dynamic class loading, and serialization control for handling class changes, ensuring that applications can continue to function even if classes are modified. Eclipse Store runs also on Android mobile, edge, and embedded devices.

Eclipse Heimlig is a Hardware Security Module (HSM) firmware for embedded platforms written in Rust.

As an HSM, Eclipse Heimlig typically runs on dedicated hardware and provides cryptographic services to clients running on other cores. These include:

• Generation and secure storage of cryptographic keys.
• Key use (encryption, decryption, signing, verification) without revealing key material to the client.
• Generation of cryptographically secure random numbers (CSPRNG).

Eclipse Heimlig implements common cryptographic algorithms:

• Symmetric encryption and decryption (AES-CBC, AES-GCM, AES-CCM, Chacha20Poly1305)
• Signing and verification (ECDSA)
• Key exchange (ECDH)
• Hashing (SHA-2, SHA-3, BLAKE3)
• Random number generation (ChaCha20Rng)

Eclipse Serializer is a serialization written from the ground up that works fundamentally differently from Java serialization and other encodings. Eclipse Serializer strictly separates data from code and transfers data only. Through deserialization, no code is executed at all. Thus, injecting and executing malicious code is impossible. Due to this highly-secure design, Eclipse Serializer protects against fatal deserialization attacks and eliminates the biggest security flaw of Java. This makes Eclipse Serializer a highly secure alternative to other serialization. 

Eclipse Xpanse provides a framework to describe and deploy cloud managed services to enable anyone to create them in a open and portable way.

To enable an Open Services Cloud market, the Eclipse Xpanse project provides:

• OCL (Open Services Cloud Configuration Language), a manifest file (json) describing all resources needed for a managed service. The OCL includes artifacts, identity, network, computing, storage, billing, console, etc. resource descriptions.
• Xpanse Runtime, the main component deployed on the cloud infrastructure, exposing an API to load OCL manifest, register and deploy managed services.
• XpansePlugins, specific to a cloud provider/infrastructure backend (e.g. openstack, kubernetes, Cloud Service Providers, etc.) which converts the abstract APIs from the Xpanse Runtime into the specific Cloud Service Providers concrete internal southbound APIs.
• Mockup UI, showing the concept of how Open Services Cloud market can operate.

The Stochastic Cognitive Model (SCM) is a driver behavior model for the use in multi-agent highway traffic simulations. SCM models cognitive processes of human drivers ranging from gaze behavior over situation recognition to decision on a specific action. SCM agents are further parametrized by driver parameters to ensure a range of driver behavior by different SCM agents and thus a high level of realism in the traffic simulation.

Creating a vertical Oniro OH solution has advantages for the Oniro Project. Some of them are outlined below.

• Provides a way to demonstrate Oniro features and technology using functional IoT device examples.
• Simplifies discussion with potential partners when one is able to show a real-world IoT device (albeit not fully-featured) built on top of Oniro by reducing the barrier to entry.
• Allows more thorough integration testing of Oniro components based on real user stories.
• Access to existing ecosystem for applications and services.

For Oniro, we want to provide blueprints of some IoT devices that can be built using Oniro. Eclipse Oniro OH is the first vertical solution add-on to provide this.

TOMLed Editor reduces the cost of development and improves developers’ comfort which might lead to yet better performance: happy people work in more creative and efficient way

Detailed description: https://amadeusitgroup.github.io/eclipse-toml-editor/

Eclipse Service Lifecycle Management (SLM) provides a set of applications to manage the lifecycle of AI (artificial intelligence) services in production environments. The service lifecycle consists of the release, deploy, and operate phase and exits with the decommissioning of the service. It has a connection to the software development lifecycle (idea, design, code, build, test) and the AI model development lifecycle (idea, data acquisition, data analysis, data preparation, model training, model evaluation).

In the context of the service lifecycle three different user groups were identified:

• service developer: a person who is responsible for creating services and providing deployable executables
• service consumer: a person who wants to use services provided by a service developer
• system administrator: a person who takes care of the infrastructure the services are running in and makes sure the services are working properly

For the user group system administrator, it is important to manage IT Resources (Bare Metal / Virtual Machines, Virtual Resource Provider / Hypervisor) and to provide the ability to roll out basic resource configurations (monitoring purpose, service runtime environments, etc.) - so-called capabilities. In order to develop and test the scripts which are used to (un)install and use capabilities the SLM provides a test environment as a sandbox. The test environment allows the provisioning of virtual machines with different operating systems and versions of those operating systems to simulate the circumstances of the real world. By doing so, it is possible to handle heterogeneous IT landscapes and to ensure the functionality of capabilities without interfering with the real world.

When the system administrator releases capabilities, the service developer can develop services building on top of those capabilities. Therefore, system administrators and service developers have to agree on common deployment definition types (e.g. docker-compose or kubernetes definition) which on the one hand the capabilities are able to handle and on the other hand the service developers will provide for their services. When a service developer wants to release a service he can publish the service as a service offering in the SLM. Service offerings provide basic meta-information about the service and service requirements the offerings have regarding their runtime environment (e.g. access to specific hardware, network connection, etc.). 

Based on the capabilities and the service offerings the service consumers can apply configurations on their IT resources and deploy service instances in a self-service manner. In service deployment, the SLM will check which requirements a service offering has and which capabilities and hardware specifications the consumer's IT resources provide. After a match-making process, the SLM will provide a filtered list of resources the service can potentially run on. To finish the deployment the user selects a resource and the SLM will deploy the service.

In order to semantically describe all entities in this context (like resources, capabilities, service offerings/instances, requirements, ...) in a consistent way the SLM utilizes the concept of the asset administration shell (AAS). AAS are used to provide a digital representation of entities and pave the way for interoperability in production environments. The AAS can hold different submodels describing specific aspects of an entity, e.g. providing one submodel showing almost static information about a PC (like hardware specification, operating system) and another submodel showing the current load state/metrics of a PC (like utilization of CPU and RAM). In order to implement this concept, the SLM will use the Eclipse Basyx Framework to provide an AAS Registry (a discovery server for AAS) and AAS Server which host the AAS of entities and their submodels. Finally, the SLM will use the AAS to describe IT (information technology) and OT (operation technology) components in the same way.