Written Philipp Ahmann, ELISA Ambassador and TSC member and Business Development Manager at Robert Bosch GmbH
Many projects share architectural elements, including container technologies, RTOS requirements, or virtualization, but safety concerns mainly touch single-point elements of such a system rather than sticking everything together. This construction of full system architectures is created by distributors or within companies towards a product. Due to their complexity, these systems utilize the work results of various related projects, either open source or proprietary.
As a result of these recent discussions with industry partners and the open source software (OSS) community, the ELISA Technical Steering Committee (TSC) approved the formation of the Systems Work Group in June 2022.
Although the use of these systems heavily differs, their system architecture elements are repeating. As mentioned, the embedded systems world often ends up with a heterogeneous architecture mixed with RTOS and Linux, virtualization and containers. This is true for medical, industrial, automotive and other industries. These systems have to fulfill certain compliance requirements, including a proper Software Bill of Material (SBOM). It is needed to tailor them for various product lines, to enable a quick project start, reduce maintenance and training efforts and ensure faster product ramp ups. Lastly, these systems typically connect with cloud services for features like monitoring, over the air update, or feature extensions, to increase their maintenance time and to architect higher care for safety as well as dependability, reliability and safety.
Working Groups, Project interaction and Architecture
The Systems WG explicitly encourages the collaboration of companies and OSS projects to develop a reference system as a workbench. It will target a community, which either also works toward enabling safety use cases with open source software or which plans to make use of open source mixed-criticality system elements as a base for their product lines.
Currently, the ELISA project already interacts with following community projects:
Taking these puzzle pieces from different projects and bringing them together in a reproducible showcase with goals such as proper SBOM generation is not established in any other open source project so far. There is a lack of an umbrella work group within the extended embedded and edge domain, which provides a reference architecture and a reproducible, dependable system to serve as a blueprint to explore new use cases, functions, or modules. It goes well in line with the recent trend toward software defined vehicles and the first steps into software defined industries, but is not limited to this.
Although the reference architecture may include elements like hypervisors or containers, which have explicitly not been part of ELISA so far, it should enable other working groups to showcase their work on process, features, and tooling with the implementation of a reference system. It can also create ideas and show potential risks or hazards due to a better system understanding; a systems-based understanding of an architecture later on used in a similar way in real world products.
As an important remark, the working group starts with a reference system fully based on “as- is” open source technology. Only a few of the elements contained in the reference system have been developed with considerable safety in mind. This means the created system will act as an example and stimulus environment for mixed criticality Linux based use cases, but is not at all safe or certifiable.
Instead, it should enable users to exchange certain elements like the container technology, RTOS, or hypervisor technology. This will require a modular design, good documentation and a way to reproduce the system with easy to follow steps.
Next steps and Beyond
The starting point for the reference system is based on the work Stefano Stabelini presented during the Open Source Summit North America, hosted in Austin, TX, June 21-24, called “Static Partitioning with Xen, LinuxRT, and Zephyr: A Concrete End-to-end Example”. As a next step, the system architecture presented in this tutorial will be further extended by adding the Yocto Project as build tooling for all system elements and enhancing the base Linux operating system by adding Automotive Grade Linux towards the end of this year. A full SBOM shall be generated as well.
Through early 2023, it is planned to extend the system to a physical hardware next to the existing QEMU image, and to also to add container technology, along with cloud connections represented. By doing so, it is possible that a Debian-based Linux may be used as a guest VM or within a container to pick up a wider community.
The work will be documented in a way that showcases why and how the system is configured as it is, while the underlying tooling will enable reproducibility by a few steps as checkout, build and deploy.
Summary
Along with proper documentation on tailoring and reproduction of the showcase, the reference system can serve as a workbench to challenge concepts and implementations from ELISA and other open source projects. It can be used as a quick start to test new ideas during proofs of concept and to let others easily experience achievements of the ELISA project working groups dealing with Linux features, tooling, architecture and more. It is there to foster collaboration of a wide range of open source projects and enables learning from real world scenarios close to later product line architectures.
Join us
The new Systems WG hosts weekly meetings on Mondays at 15:00 UTC (8 am PT/11 am ET). To receive the meeting invitation (and working group posts), simply subscribe to the mailing list. The meeting invitation will be sent to you after subscription. Also feel free to reach out to one of the ELISA ambassadors to learn about further ELISA activities.