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.