Written by Paul Albertella, ELISA Project TSC member, Chair for Open Source Engineering Process Working Group and Consultant at Codethink

This blog originally ran on the Codethink website. For more content like this, click here.

In 2016, Codethink started out on a journey to discover how open source software can be safely used to build safety-critical systems — that is, in products where people might be harmed if the software fails to do its job correctly.

Free / libre open source software (FLOSS) projects like Linux have clearly demonstrated the value of collaboration in public when creating software that is — amongst many other things — trusted as the backbone of the web and millions of smart phones. FLOSS projects have also established the essential role of transparency and rapid software updates in dealing with cybersecurity threats. When it comes to safety, however, the difficulties of making a case for using FLOSS in a solution have long been a frustrating obstacle for product developers.

Immediately following Codethink’s announcement about our latest milestone in this journey, I took part in two workshops focussing on safety and open source. This gave me the opportunity to talk about the Trustable Software Framework (TSF) and how we are using it in our development of CTRL OS. I also learnt more from other open source projects about their approaches to creating software where trustability is as important.

The workshops were hosted by Volvo Cars in the Swedish city of Lund, and our hosts also provided several enthusiastic participants. The events were organised by two open source projects that have common goals and challenges, but approach these from different perspectives and with different focuses. The Eclipse SDV project aims to build an automotive software stack to provide “an open technology platform for the software-defined vehicle of the future”. In contrast, the ELISA project is concerned with the use of Linux-based operating systems for safety applications in a range of different domains.

Day 1

Markus Bechter from BMW started the Eclipse SDV workshop by describing the approach to safety being developed for the Eclipse S-CORE or Safe Open Vehicle Core project. The intent is to establish a common set of development processes for components of this project, making the software amenable to safety certification using the ISO 26262 Automotive Safety Standard.

The Trustable Software Framework project was recently accepted into the Eclipse Foundation, so I gave the next presentation. TSF approaches the challenge of using FLOSS in safety more broadly: how can we make a case for using software that has not been developed following a process that conforms to an applicable safety standard? Since this describes the vast majority of existing FLOSS, including many of the tools and dependencies that S-CORE plans to use, an answer to this question is sorely needed, and TSF provides a methodology for making such a case.

After lunch, it was time to welcome a new set of participants and start the ELISA workshop. This began with an introduction to the project for newcomers (see my retrospective from last year’s workshop if you are also new to the project), followed by an Ask Me Anything discussion. Then we had a fascinating talk from David Cuartielles, a founder of the Arduino project who was recently honoured in the European Open Source Awards. After telling us about the latest Arduino (the Portenta x8) and the features of the boards that are relevant for trust, he went on to talk about a topic that he is passionate about: the DESIRE4EU project, which is exploring how to make printed circuit boards that are recyclable, in support of the European sustainable electronics goal.

The rest of the day focussed on the efforts of the ELISA Systems working group to describe and build systems involving Linux in combination with two other FLOSS components: the Zephyr RTOS and the Xen Hypervisor. This led naturally into a discussion of ELISA’s interactions with other adjacent open source communities.

Day 2

Philipp Ahmann and I started the second day with a discussion exploring some common misapprehensions about Linux and safety. We talked about some of the ‘routes’ to certification in the safety standards for pre-existing software, and why these are difficult to apply to open source software. We also explained why the notion of creating a ‘safe’ Linux is misleading, because safety can only really be understood in terms of a system, as opposed to an intrinsic property of a component. This led into discussions of various system models involving Linux, the use of complete redundant systems as part of a larger system design, and the role of hardware components in this, which was a perfect segue to the next session.

Olivier Charrier talked about the role of hardware integration in safety, describing how the responsibilities for achieving specific safety objectives as part of a system design are typically assigned to hardware and software components, and then refined or re-defined in a series of iterations to address the identified gaps. Alessandro Carminati then shared the results of a Linux Features working group investigation to build and analyse a minimal Linux configuration and identify a core set of features that must be considered for any Linux-based system.

After lunch we had a series of ‘special topic’ talks, beginning with interesting talks on PX4SPace — a flight control solution for drones that is being used to build robotic space vehicle solutions — and the SPDX Safety Profile, which extends the SPDX 3.0 ‘knowledge graph’ to include metadata relating to development processes for safety.

Håkan Sivencrona from Volvo then talked about Safe Continuous Deployment, emphasising the importance of building development processes that deliver an ongoing stream of ‘safe’ software deliveries using DevOps principles, not just one ‘blessed’ release that is never expected to change. Igor Stoppa’s talk on “Resilient Safety Analysis and Qualification” sparked a lively discussion, as he argued that any safety analysis of Linux must be based on a detailed understanding of the code, and that this might be a reason not to rely on more complex features or extensions of the kernel.

We then had a talk by Gustavo Padovan of the Kernel CI project, which recently became an associate member of ELISA. He explained that a key goal of the project is to enable projects and organisations testing the kernel to share their results with the wider kernel community by providing a common framework for reporting results. Recent developments include kci.dev, a command line tool enabling developers and maintainers to interact with Kernel CI, and a YAML config file format to enable Linux subsystems to share tailored test case executions for maintainers and the wider community.

The rest of the day focussed on requirements management and traceability, looking first at ELISA’s BASIL tool, and then at an initiative with the Linux Tracing subsystem to develop a low-level requirements specification approach. The latter involved documenting detailed requirements for each function in the kernel, which would be intended to support complete reimplementation of the functionality without reference to the code. One participant noted that this approach might enable the kernel to be re-written in Rust!

Day 3

I kicked off the last day by reprising my presentation about the TSF from the Eclipse workshop for the ELISA attendees. Once again, the enthusiastic engagement and insightful questions from the participants were very gratifying, and Daniel Krippner helped to illustrate how the framework may be applied in practice by talking through his use of it as part of the Eclipse uProtocol project. Daniel and I followed this with a quick discussion of how Rust is becoming increasingly relevant in the safety sphere, and how this may be relevant for ELISA.

The workshop wrapped up with a discussion on the Open Source Best Practices Standard, an initiative that was launched earlier this year. It included a live survey collecting input from the audience about their awareness of existing standards and suggestions for projects to be considered for examples of best practices.

Key Takeaways

I’ve attended numerous ELISA workshops since the first one in 2019, and it was wonderful to note how many passionate and enthusiastic newcomers we had attending this time. We also had participants from a variety of different backgrounds, including academics from the local university and engineers from the rail, medical and aeronautics industries, as well as the always-prevalent automotive specialists.

ELISA’s increasing engagement with other open source communities, including those from the Eclipse Foundation and Linux Foundation projects, is also good to see. The growing interest in safety-related topics in these communities, building on the already well-established awareness of cybersecurity topics, is also encouraging. After the enthusiastic reception that my talks had last week, I am hopeful that the Trustable Software Framework can help to continue this trend, giving all open source projects a way to start engaging with these topics and to share their thinking and strategies for building trust with other projects and communities.

Stay tuned here for links to the videos and presentations.

Additional Resources:

• Connect with our LinkedIn page
• Subscribe to our Youtube Channel
• Sign up to get our quarterly newsletter
• Subscribe to the mailing lists to talk with community and TSC members

In the last ELISA Project Workshop, hosted at the NASA Goddard Space Flight Center in Greenbelt, Maryland, from December 10 to 12, 2024, speaker Ivan Perez, Principal Research Scientist at NASA Ames Research Center, gave a presentation, “Space ROS.” In this presentation, he offered an overview of Space ROS, an open source framework for developing flight-quality robotic and autonomous space systems. Watch the video below or check out the presentation here.

 

The ELISA Workshop, which had than 30 in-person and 40 virtual attendees, brought together experts from various organizations, including ELISA Project member companies such as Red Hat, and Bosch, as well as representatives from NASA, Wind River, TelePIX, the Linux Foundation and more. This diverse group of professionals engaged in discussions and presentations on advancing Linux systems for space-grade applications.

Check out the ELISA Workshop @ NASA Youtube playlist to watch other videos or access the materials on the ELISA Project’s directory.

Additional Resources:

• Connect with our LinkedIn page
• Subscribe to our Youtube Channel
• Sign up to get our quarterly newsletter
• Subscribe to the mailing lists to talk with community and TSC members

Kernel design documentation is not just an administrative task—it is essential for ensuring reliability, safety, and compliance in mission-critical systems. It serves as a foundation for certification, debugging, maintenance, and future improvements, ultimately reducing risk and increasing system dependability.

In the last ELISA Project Workshop, hosted at the NASA Goddard Space Flight Center in Greenbelt, Maryland, from December 10 to 12, 2024, speakers Gabriele Paoloni, Sr Principal Engineer and Open Source Community Technical Leader at Red Hat; Chuck Wolber and Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation, gave a presentation, “Linux Kernel Design Documentation.”

The goals for this session were to:
A) Share the latest findings and ideas from the Safety Architecture WG towards the high level next steps discussed at Linux Plumbers Conference
B) Create more detailed next steps and respective forums

View the video below:

The ELISA Workshop, which had than 30 in-person and 40 virtual attendees, brought together experts from various organizations in person and virtual, including ELISA Project member companies such as Red Hat, and Bosch, as well as representatives from NASA, Wind River, TelePIX, the Linux Foundation and more. This diverse group of professionals engaged in discussions and presentations on advancing Linux systems for space-grade applications.

Check out the ELISA Workshop @ NASA Youtube playlist to watch other videos or access the materials on the ELISA Project’s directory.

Additional Resources:

• Connect with our LinkedIn page
• Subscribe to our Youtube Channel
• Sign up to get our quarterly newsletter
• Subscribe to the mailing lists to talk with community and TSC members

Written by Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation, and Philipp Ahmann, Senior OSS Community Manager at ETAS and Chair of the ELISA Project Technical Steering Committee

Overview

In Lund, Sweden, Volvo recently hosted the ELISA workshop, aligning with their strong commitment to improving safety. The event was a perfect match for the ELISA community, attracting a full capacity of 30 in-person attendees and engaging over 15 virtual participants. The workshop not only provided valuable discussions and brainstorming sessions but also offered attendees a taste of Swedish hospitality with delightful breaks and lunches – facilitating a lively “hallway track”. The lively conversations sometimes made it challenging to stick to the schedule, but the energetic atmosphere fostered productive exchanges of ideas.

Insightful sessions extract

Presentation: Constant Flow of Increasing Challenges for a Safety Manager

With Håkan Sivenkrona we had an inspiring presentation from our hosting company Volvo, which also will lead into a follow up seminar dedicated to Safety Elements out of Context (SEooC). In today’s dynamic environment, standards are constantly evolving. It is crucial for both proprietary and open systems to adapt to this shifting landscape and embrace continuous safety compliance. As a community, we must come together to explore ways to consistently deliver a Safety Case in the future. Safety systems need to be ready for the usage of open source developed software and open source software need to be enabled to fulfill the demands of various directives, security and safety standards. Public expectations and established best practices will further drive safety innovation.

Link to slides: https://drive.google.com/file/d/1Zl2cC7HgJl4A3uGvbukFVdg-wsdn6kh4 

Presentation: SPDX safety profile and implications on code and traceability

During this session, we discussed the important factors that need to be considered and integrated into the Safety Cases moving forward. We also explored the efforts of the System Package Data Exchange project in capturing metadata to enhance this process. In addition to the Linux kernel and user space software, it is crucial to understand the origin of datasets, model training, and services for effective safety analysis in the future. By automating the generation of this information, we can ensure better traceability of requirements when there are changes in the inputs to the Safety Cases.

Link to slides: SPDX safety profile update.pdf

Presentation: safety mechanisms to be considered to meet ASIL levels in Automotive

Naresh Ravuri from Magna, provided an excellent overview of the work that they’ve been doing to tackle the top level safety goals from OEM perspective. They emphasized the importance of identifying a critical path even when all requirements are derived. The decomposition of the use case plays a crucial role in ensuring that if one part fails to perform a task, another part can take over. It is essential to have a deep understanding of the Linux system to avoid incorrect system decomposition. Additionally, considering the data-driven path is vital for conducting a thorough analysis. Lastly, it is important not to overlook the impact of the build (compiler) and runtime environments (libraries) on the overall system.

Link to slides: Safety mechanisms to be considered to meet ASIL levels in Automotive.pdf

Presentation: ELISA in the world of Software Defined Vehicles

Almost the whole Automotive Industry is currently looking into software defined vehicles with high performance computers (HPCs). During the ELISA workshop the participants discussed this from a practical point of view and what it means to “let it crash”. Coming from Cloud Native it was presented how to plan for potential system failures and how to recover from that. The architectural assumptions are important and how a system is tailored and methods for splitting critical resources from less critical system parts. The presentation was brought to the community by EMQ who are serving multiple automotive customers with MQTT solutions. 

Link to slides: SDV – “let it crash” in connected vehicles.pdf

Discussion: core parts of the kernel – initial focus on the “TINY” configuration

During the workshop, the approach of starting with the “TINY” config and gradually adding or removing components was discussed.  By clearly defining the core set of the linux kernel, it becomes easier to prioritize important aspects which are crucial for the safety argumentation of the kernel. While initially it was considered to avoid hardware and architecture specific code, this may not be feasible. By extending the “TINY” configuration with other components, not only does it enhance the system, but it also demonstrates a methodology for improving the overall functionality of the kernel. 

The follow up of the initial discussion on “TINY” will be split across various working groups inside ELISA. The Linux Features working group is already exploring suitable reference hardware like an ARM 64 bit QEMU. The Architecture Working Group will start the analysis based on their input. The build and booting of the reference hardware integrated into a CI is subject to the Systems WG.

Discussion: state of available tooling

The tooling for analyzing the Linux kernel is constantly improving. While there are already several tools integrated into the kernel, we are also exploring the inclusion of additional analysis tools that have shown their usefulness. If you’re interested in understanding call graphs, you can check out the ks-nav tool work available at: https://github.com/elisa-tech/ks-nav

Why ks-nav is important can be extracted also from the slides and get some workshop feeling by clicking on the embedded YouTube links: State of ks-nav.pdf

Summary of workshop and main takeaways

The good mixture of participants continue to bring new ideas into the discussion when meeting in person. In particular the pointing to use of the TINY Linux configuration for the core was brought in by a first time Linaro representative. It is always important to widen the spectrum.

While there is still a long way to go until we have proven processes for enabling Linux in Safety Applications, there are starting to emerge some excellent ideas and as we refine them, we should be able to formalize them. It’s very easy for folks to make destructive statements, but we’re seeing that the open dialog can be turned into a more positive outlook, as illustrated by the engineering approach for safe systems with linux, where discussion landed on defining a design element and building up from there.

It is important to remember that a closed source OS may be as vulnerable as Linux in working with an open source ecosystem. However in Linux we have an open system and can actually see how it operates. Maybe in other closed OS and in company development the same issues show up, but nobody knows about it, as there is no expert and possibility to analyze.

The automotive industry is increasingly interested in utilizing Linux for high-performance computers in vehicles. The complexity of the software-defined vehicle, centralized compute units, and complex system architectures pose challenges for traditional product development using closed-source proprietary real-time operating systems (RTOS). Linux, on the other hand, is capable of meeting these demands, which is why its adoption in the automotive industry is expected to continue to grow, but they still need the path of safety argumentation and certification. 

Interesting enough even with slightly different motivation also Aerospace observes wider usage of high performance computers and at same time a wider usage of Linux demanding safety certification. Maybe the next workshop will be hosted in the wider (aero-)space ecosystem to serve the other vertical branch in ELISA more. So, stay tuned for when and where our next Workshop will be. 

Still, a lot of work is needed to have a safety argumentation for Linux, but we are making progress.

Thanks to hosts

We would like to express our gratitude to Volvo Cars, especially Robert F, for organizing the venue and hosting us. We also appreciate the walking tour of Lund, the delicious meals, and the fascinating tour of MAX IV (https://www.maxiv.lu.se/). During the tour, the MAX IV team showcased their research using beamlines and accelerators. We learned that Linux is widely used as the IT infrastructure throughout the research site, although it is not considered safety-critical. These examples further demonstrate the trust and widespread adoption of Linux.

As hallway and networking is important when meeting face to face, Volvo arranged a great dinner for the participants where a lot of topics from MAX IV, as well as “the digital safety belt” and the directions of the ISO26262 were discussed and which role Linux plays in all of this. Like Volvo has released their patent on the safety belt for the sake of saving people’s life over making money with a patent many years back, let us hope that the same will happen to software in vehicles and make open source software like Linux the next “digital safety belt”. 

Contribute

If any of these topic areas is of interest to you,  please feel free to sign up for the mailing lists at https://lists.elisa.tech; show up at one of the working group meetings; and contribute to the discussion.

Join us at the Linux Plumbers for the “Safe Systems with Linux” micro conference – if you have a topic to propose for discussion, the CFP is open until July 10th; sign up to attend at: https://lpc.events/event/18/page/226-attend.

Written by Philipp Ahmann, Chair of the ELISA Project TSC, and Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation 

On October 16-18, ELISA Project gathered at the Red Hat Munich office for an in-person workshop. The event had a great mix of attendees, including both familiar faces and first-time participants, with representatives from non-member companies such as Canonical, Volvo, MBition, Harman, and Valeo. While the workshop was primarily focused on automotive companies, there was also one participant from NASA.

Discussions centered around the core part of Linux, with a need to define what constitutes a core or minimal configuration. It was suggested that distro providers be consulted to determine their kernel configurations. The topic may continue in the architecture working group. A guide and methodology to strip down the kernel to a smaller use case and system-adjusted setting could also be useful.

A major part of the workshop was the discussion around BASIL, a new tool for tracing requirements code and tests that was proposed in the Berlin workshop earlier in the year. Introduced by Red Hat and open sourced just before the event, it has gained interest among other members, including SUSE. SUSE presented their approach on Automotive SPICE SWE processes for complex Open Source Software to get an argumentation around QM state of Linux and components in use of these systems. It is seen as promising by others and will be taken forward. It can be a path towards quality management argumentation of Linux systems.

Nvidia presented a more technical discussion on the kernel level, with a systematic approach to using the Linux kernel in safety scenarios. This was also interesting for Windriver and Elektrobit. The idea is to have a shared list of risk factors and potential interference between system elements. It is a bit of a direction like CVE to CWE if you want to compare it to security.

A session about the SPDX-SIG on Safety focused on requirement traceability with code and tests and gave a good fit to the discussions around BASIL. This was in line with the ELISA’s discussions around enhancing SBOMs to support safety argumentation and evidence.

Sessions were held on how to catch up newcomers, and understand member needs, the ELISA big picture, outreach to adjacent communities, and current challenges to comply with different aspects of the ISO26262 were held as well.

The workshop concluded with a strategy and path towards 2024. ELISA will take a stronger driver towards tools and documentation, with good documentation around PREEMPT_RT being one of these elements. It is further important to show the results so that others can better understand where ELISA is reaching and where it fits into their industrial use cases.

Overall, the workshop was a great success, with many interesting discussions and presentations. The ELISA looks forward to the next workshop and continuing to drive innovation in the Linux ecosystem.

Testimonials

“I am thrilled to have attended the ELISA workshop in Munich, where I gained valuable insights into the complexities of achieving functional safety for Linux, particularly in the automotive industry. The engaging presentations and collaborative discussions with industry experts highlighted the importance of strong collaboration in addressing this challenge.” – Bertrand Boisseau (Canonical)

“I found the ELISA workshop to be very educational and engaging. The speakers were really skilled and had a great understanding of both safety and Linux aspects. I will closely follow ELISA and hope to engage with more OEM presence” – Robert Fekete (Volvo Cars)

How to get involved

ELISA hosts workshops on a bi-annual basis. Check out the list of workshops and sessions in the ELISA Workshop Series and workshop-related blog posts and videos.

• Wondering when and where the next ELISA workshop will be held? Keep an eye on upcoming ELISA events.
• Interested in getting involved in ELISA? Introduce yourself, ask a question and follow along on Technical Forum, check out the Working Groups and start participating.
• Questions? Check out the FAQs and reach out to info@elisa.tech.  

Written by Philipp Ahmann, Chair of the ELISA Project TSC and Technical Business Development Manager at Robert Bosch GmbH 

In June, the ELISA Project’s core contributors and affiliates came together for three days at the Bosch IoT Campus in Berlin, Germany. We discussed recent achievements, project branding and perception, upcoming goals and next steps.

Quick recap on the three days

The workshop kicked off with a discussion about ELISA’s big picture document. The document serves as an entry point for new contributors to find their path through the ELISA deliverables and approach. It will be a living document which gets updated and enhanced when major achievements are reached. It is structured into 3 major parts and complements the project charter and mission.

• The project objective
• The ELISA approach (ongoing work to meet the project objective)
• Using and putting ELISA results into practice

The second session focused on the creation of a pragmatic guide to best practices for open source contributors to facilitate safety analysis in the future. In this session, Kate Stewart, Vice President of Dependable Embedded Systems and and ELISA Ambassador, shared an overview of existing tools which help to make the kernel development work more discoverable, creating certain traceability, and to make analysis “more provable.” The session addressed a few next steps which the project has to look into: 

• Capturing current Kernel requirements
• Using Linux features
• Testing Frameworks

Some parts of the topics were directly addressed as part of the second day agenda. In the first session, the safety analysis approach uses a combination of risk analysis, fault injection, and a high degree of automation. Part of it is also the System Theoretic Process Analysis (STPA). This was already successfully applied within Codethink and taken forward within the Open Source Engineering Process (OSEP) Working Group. The motivation to go in this direction was also made visible and which initial work has been started.

In the following session certain limits of a traditional STPA when applied to the Linux Kernel were pointed out by Red Hat. Additional tool support may be needed which was one reason to create the ks-nav tool. The objective of this tool is to analyze the Linux kernel for safety by presenting diagrams of call trees. In this way an understanding of the interactions and dependencies among different parts of the kernel can be gained for safety analysis. To speed up the development and make the tool more visible, the ks-nav tool resides now in an own repository within the ELISA github organization.

After that, the workshop participants had a longer discussion, whether manpage derived requirements and manpage driven testing can improve the argument towards usage of Linux in safety-critical applications. 

• It describes a large part of the software components of Linux usage in products
• It is the established format to describe and learn the software functionality provided by Linux.
• It is used by a large audience.

The workshop participants agreed that there is still a lot of work to map the current kernel implementation to the existing manpages and to close the gaps between both. This will be a great contribution to the whole kernel community. Overall the ELISA project plans to take major actions in the field of Kernel documentation improvements.

In the afternoon session “targets for upstreaming to Linux kernel for the remainder of the year” the topic of upstreaming documentation within the user and admin guide of the Kernel was put into practice. The current activities of the Linux Features for Safety Critical Systems (LFSCS) WG were presented to the workshop participants. Shuah Khan (Linux Foundation Fellow) together with Elana Copperman (Mobileye, LFSCS WG lead) illustrated the different configuration parameters of the PREEMPT_RT patches which are now almost completely upstreamed. However, it turned out that the documentation of the parameter and configuration towards desired usage have large room for improvements. As many safety-critical products rely on certain real time capabilities, ELISA judges this topic as high priority and very important.

RT Linux in Safety Critical Systems: the potential and the challenges – Elana Copperman & Shuah Khan

The 3rd day concentrated heavily on internal ELISA activities, project health and growth. There was a session revisiting the project messaging along with a session about review of change management workflow, and a proposed approach document to go to the working groups/TSC for approval. In another session the participants brainstormed ideas for community growth and engagement, adjacent community outreach and mutual alignment.

Although the sessions focused on internal work, especially the contributions by affiliated workshop participants representing e.g. Eclipse Software-Defined-Vehicle, ETAS, MBition and NXP added new perspectives, led to good takeaways and made the workshop a success.

Major Workshop Takeaways

During the various sessions and at the end of each day takeaways from the participants were collected and discussed. An extract of major takeaways are listed below:

• Rework and structure Kernel documentation is an important element of ELISA
  • Strong risk of diverging, in case you write documentation by another person than the maintainer of the code.
• Start identifying critical subsystems of the Linux kernel to enhance user documentation similar to “workload” and “realtime” documentation.
• Identification of the “core” part of the kernel that is present in all set of config images
  • Looking at user APIs for the “core” parts, may be a useful focus for doing detailed analysis that others can use, and build from
  • Any analysis has to be tagged to specific release, as changes are happening through time.
  • Getting the API and subsystem analysis of key pieces upstream, combined with recommendations on testing to demonstrate the user space APIs are consistent. (Maintainer need to agree)
• ELISA is not providing a safe Linux, but there are interesting tools supporting Safety with using Linux
• If you push a patch to the Linux kernel you have to follow rules (e.g. checkpatch). Maybe there can be kernel tools to improve the safety part of Linux, e.g. that the proposed change/config is in line with the safety guidelines
• The kernel alone does not make the operating system, you need other components to create a particular system.
• Open Sourcing the Red Hat requirement tool would be a great benefit for the wider open source safety community
  • Use the requirements tool to export SPDX safety linkage SBOMs for the Linux Kernel
• Reach out to Eclipse SDV and AGL with SOAFEE to talk about an example system as part of Systems WG
  • SDPX and System SBOM may be of interest for Eclipse Foundation (SDV)
• OEM may be a must have to work on a real use case in certain domains (especially automotive).
• The puzzle pieces on the table may not yet be complete and people may use puzzle pieces differently
  • Workshops are a good place to learn how the different pieces fit together, SBOM, OSEP, ARCH…

Getting involved

The ELISA Project is open to anyone to participate. While membership is not required for participation, we always love to welcome additional  members to join us in the mission of  enabling Linux in safety applications and to collaborate with other members who are committed to this effort.

If you are interested to learn more about ELISA or want to participate in one of the working groups or recently started activities, just send  an email to the technical forum mailing list. Or you can get advice on where to contribute best by joining the Technical Steering Committee (TSC) meeting which is held every other Wednesday at 13:00 UTC.

Last but not least the next in person workshop is only a few months away. ELISA members currently plan to meet again most likely in Munich, Germany, October 16- 18. Please join the mailing list and/or subscribe to @ProjectElisa or our LinkedIn page or our Youtube Channel to learn more about the next workshop.