Skip to main content

Working Group

Open Source Summit North America (Videos)

By Blog, Industry Conference, Working Group

This year, Open Source Summit North America was held as an umbrella conference, composed of a collection of 14 events covering the most important technologies, topics, and issues affecting open source today in June. There were a total of 2,771 attendees with 1,286 of those attending in person in Austin, from 1,041 organizations across 68 countries around the globe. The event attracted a diversified mix of open source community members from across the ecosystem. 54% of attendees were in technical positions, and developers comprised more than a quarter of attendees. You can read the post-event report here. You can also view all of the event playlists on the Linux Foundation Youtube Channel.

The ELISA Project was featured in several sessions and represented by ambassadors and community members at the conference. If you missed these presentations, you can watch the videos below:

Enabling Linux in Safety Applications (panel discussion)Gabriele Paoloni, Red Hat (ELISA board chair) Kate Stewart, Linux Foundation (ELISA Executive Director) Paul Albertella, CodeThink (Open Source Engineering Process) Elana Copperman, Intel (Linux Features) Philipp Ahmann, Bosch GmbH (Automotive) Milan Lakhani, Codethink (Medical Devices) 

Meeting business and safety objectives while building safety critical applications is a huge challenge for any industry, particularly those who have not had previous experience with open source and Linux. ELISA’s charter is to help industries navigate technical and non-technical challenges in order to bring the benefits of open source to safety applications and help organizations provide the rigor needed for certification. This panel features ELISA working group leads who will share their vision of making Linux a prominent player for FuSa applications in several industries. Join us to learn more about the project and how you can contribute to the community’s overall success.

Finding the Path from Embedded to Edge using Product LinesSteffen Evers, Bosch.IO & Philipp Ahmann, Robert Bosch GmBH

Linux is used for many embedded device classes today. However, it is increasingly desirable to connect these devices with each other and with the cloud. Embedded container technology can be used to make this easier by merging server/cloud and embedded technologies. However, it also leads to more challenges e.g. in respect to security, safety, traceability, and SBOMs. Using Linux across multiple device classes and product lines, and adding cloud technology, causes the complexity and efforts to explode.

In this talk, we describe how Bosch, and others, use embedded containers and “reference systems” to avoid redundant work and get a large number of embedded projects under control.

A reference system is an adjustable compilation of tools along with a pre-configured bundle of packages for a common use case and defined set of devices. This reuse significantly reduces development and maintenance costs, and speeds up the time to market. In this way, reference systems can form the base for your product lines.

Bosch uses the in-house Debian-based embedded distribution “Apertis” as the basis for several reference systems, e.g. for automotive infotainment systems. In doing so we push as many efforts as possible from individual projects into Apertis, as the meta-layer. Thereby, the users can focus more on the actual functionality and applications. e.g. one issue that we have addressed in the context of software management is the handling of GPLv3 in embedded devices. Another topic has been mainline support for kernel drivers.

BOF: SBOMs for Embedded Systems: What’s Working? What’s Not? – Kate Stewart

With the recent focus on improving Cybersecurity in IoT & Embedded, the expectation that a Software Bill of Materials (SBOM) can be produced, is becoming the norm. Having a clear understanding of the software running on an embedded system, especially in safety critical applications,  like medical devices, energy infrastructure, etc. has become essential.  Regulatory authorities have recognized this and are starting to expect it as a condition for engagement.  This BOF will provide an overview of the emerging regulatory landscape, as well as examples of how SBOMs are already being generated today for embedded systems by open source projects such as Zephyr, Yocto and others,  followed by a discussion of the gaps folks are seeing in practice, and ways we might tackle them.

Static Partitioning with Xen, LinuxRT, and Zephyr: A Concrete End-to-end Example – Stefano Stabellini, AMD

Static partitioning enables multiple domains to run alongside each other with no interference. They could be running Linux, an RTOS, or another OS, and all of them have direct access to different portions of the SoC. In the last five years, the Xen community introduced several new features to make Xen-based static partitioning possible. Dom0less to start multiple static domains in parallel at boot, and Cache Coloring to minimize cache interference effects are among them. Static inter-domain communications mechanisms were introduced this year, while “ImageBuilder” has been making system-wide configurations easier. An easy-to-use complete solution is within our grasp. This talk will show the progress made on Xen static partitioning. The audience will learn to configure a realistic reference design with multiple partitions: a LinuxRT partition, a Zephyr partition, and a larger Linux partition. The presentation will show how to set up communication channels and direct hardware access for the domains. It will explain how to measure interrupt latency and use cache coloring to zero cache interference effects. The talk will include a live demo of the reference design.

RTLA: Real-time Linux Analysis Toolset – Daniel Bristot De Oliveira, Red Hat

Currently, Real-time Linux is evaluated using a black-box approach. While the black-box method provides an overview of the system, it fails to provide a root cause analysis for unexpected values. Developers have to use kernel trace features to debug these cases, requiring extensive knowledge about the system and fastidious tracing setup and breakdown. Such analysis will be even more impactful after the PREEMPT_RT merge. To support these cases, since version 5.17, the Linux kernel includes a new tool named rtla, which stands for Real-time Linux Analysis. The rtla is a meta-tool that consists of a set of commands that aims to analyze the real-time properties of Linux. Instead of testing Linux as a black box, rtla leverages kernel tracing capabilities to provide precise information about latencies and root causes of unexpected results. In this talk, Daniel will present two tools provided by rtla. The timerlat tool to measure IRQ and thread latency for interrupt-driven applications and the osnoise tool to evaluate the ability of Linux to isolate workload from the interferences from the rest of the system. The presentation includes examples of how to use the tool to find the root cause analysis and collect extra tracing information directly from the tool.

Boeing joins the ELISA Project as a Premier Member to Strengthen its Commitment to Safety-Critical Applications

By Announcement, News, Working Group, Workshop

Boeing to lead New Aerospace Working Group

SAN FRANCISCO – August 11, 2022 –  Today, the ELISA (Enabling Linux in Safety Applications) Project announced that Boeing has joined as a Premier member, marking its commitment to Linux and its effective use in safety critical applications. Hosted by the Linux Foundation, ELISA is an open source initiative that aims to create a shared set of tools and processes to help companies build and certify Linux-based safety-critical applications and systems.

“Boeing is modernizing software to accelerate innovation and provide greater value to our customers,” said Jinnah Hosein, Vice President of Software Engineering at the Boeing Company. “The demand for safe and secure software requires rapid iteration, integration, and validation. Standardizing around open source products enhanced for safety-critical avionics applications is a key aspect of our adoption of state-of-the-art techniques and processes.”

As a leading global aerospace company, Boeing develops, manufactures and services commercial airplanes, defense products, and space systems for customers in more than 150 countries. It’s already using Linux in current avionics systems, including commercial systems certified to DO-178C Design Assurance Level D. Joining the ELISA Project will help pursue the vision for generational change in software development at Boeing. Additionally, Boeing will work with the ELISA Technical Steering Committee (TSC) to launch a new Aerospace Working Group that will work in parallel with the other working groups like automotive, medical devices, and others.

“We want to improve industry-standard tools related to certification and assurance artifacts in order to standardize improvements and contribute new features back to the open source community. We hope to leverage open source tooling (such as a cloud-based DevSecOps software factory) and industry standards to build world class software and provide an environment that attracts industry leaders to drive cultural change at Boeing,” said Hosein.

Linux is used in all major industries because it can enable faster time to market for new features and take advantage of the quality of the code development processes. Launched in February 2019, ELISA works with Linux kernel and safety communities to agree on what should be considered when Linux is used in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.

“Linux has a history of being a reliable and stable development platform that advances innovation for a wide range of industries,” said Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation. “With Boeing’s membership, ELISA will start a new focus in the aerospace industry, which is already using Linux in selected applications. We look forward to working with Boeing and others in the aerospace sector, to build up best practices for working with Linux in this space.”

Other ELISA Project members include ADIT, AISIN AW CO., Arm, Automotive Grade Linux, Automotive Intelligence and Control of China, Banma, BMW Car IT GmbH, Codethink, Elektrobit, Horizon Robotics, Huawei Technologies, Intel, Lotus Cars, Toyota, Kuka, Linuxtronix. Mentor, NVIDIA, SUSE, Suzuki, Wind River, OTH Regensburg, Toyota and ZTE.

Upcoming ELISA Events

The ELISA Project has several upcoming events for the community to learn more or to get involved including:

  • ELISA Summit – Hosted virtually for participants around the world on September 7-8, this event will feature overview of the project, the mission and goals for each working group and an opportunity for attendees to ask questions and network with ELISA leaders. The schedule is now live and includes speakers from Aptiv Services Deutschland GmbH, Boeing, CodeThink, The Linux Foundation, Mobileye, Red Hat and Robert Bosch GmbH. Check out the schedule here: Registration is free and open to the public.
  • ELISA Forum – Hosted in-person in Dublin, Ireland, on September 12, this event takes place the day before Open Source Summit Europe begins. It will feature an update on all of the working groups, an interactive System-Theoretic Process Analysis (STPA) use case and an Ask Me Anything session.  Pre-registration is required. To register for ELISA Forum, add it to your Open Source Summit Europe registration.
  • Open Source Summit Europe – Hosted in-person in Dublin and virtually on September 13-16, ELISA will have two dedicated presentations about enabling safety in safety-critical applications and safety and open source software. Learn more.

For more information about ELISA, visit

About the Linux Foundation

Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: Linux is a registered trademark of Linus Torvalds.


Join us at ELISA Project September Events

By Blog, Industry Conference, News, Working Group, Workshop

Launched in February 2019, the ELISA (Enabling Linux in Safety Applications) Project works with Linux kernel and safety communities to agree on what should be considered when Linux is used in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.

If you’re new to the project and would like to learn more about the community, ELISA has several upcoming events in September that you can attend to meet ambassadors or project members, receive updates about technical milestones and goals of each of the working groups and ask questions or get involved. Focused Working Groups include Automotive, Linux Features for Safety-Critical Systems, Medical Devices, Open Source Engineer Processes, Safety Architecture, Systems and Tool Investigation and Code Improvement and they are always looking for more participants.

September events:

  • ELISA Summit – Hosted virtually for participants around the world on September 7-8, this event will feature overview of the project, the mission and goals for each working group and an opportunity for attendees to ask questions and network with ELISA leaders. View the schedule here. Registration is free and open to the public.
  • ELISA Forum – Hosted in-person in Dublin, Ireland, on September 12, this event takes place the day before Open Source Summit Europe begins. It will feature an update on all of the working groups, an interactive System-Theoretic Process Analysis (STPA) use case and an Ask Me Anything session.  Pre-registration is required. To register for ELISA Forum, add it to your Open Source Summit Europe registration.
  • Open Source Summit Europe – Hosted in-person in Dublin, Ireland, and virtually on September 13-16, ELISA will have two dedicated presentations about enabling safety in safety-critical applications and safety and open source software. Learn more.
  • ELISA Workshop – Hosted in-person in Manchester, England, at Codethink offices. This workshop offers an opportunity for active ELISA contributors and members to have interactive discussions on predetermined topics and have side-by-side working sessions. Learn more.

Introduction to ELISA (Video)

By Blog, Working Group, Workshop

The Spring ELISA Workshop, which took place on April 5-7 virtually, had more than 130 global registrants that learned more about the various working groups, hot topics related to enabling linux in safety applications and networked with ambassadors. If you missed the workshop, you can check out the materials here or subscribe to the ELISA Youtube Channel and add these sessions to your watch list.

At the workshop, Shuah Khan, Chair of the ELISA Technical Steering Committee (TSC) and Kernel Maintainer and Linux Fellow at the Linux Foundation, joined Kate Stewart, ELISA TSC member and co-chair of the Medical Devices Working Group, to kick off the workshop with an introduction to the ELISA Project.

You can view the video below, which is intended for new community members interested in the project and those who aren’t regular participants in the working groups.

We invite you to join a working group to learn more! Click here to check out the working groups and subscribe to their mailing lists and calendars to join meetings.

ELISA’s New Systems Working Group

By Blog, Working Group

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.


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.

ELISA Welcomes 3 Mentees!

By Blog, Mentorship, Working Group

The Linux Foundation has had a robust mentorship program for years that invests in new talent and diversity that helps the open source community – no matter what the focus or project – thrive as a whole. Since its formal launch in 2019, the LFX Mentorship has graduated more than 190 mentees and has hosted almost 100 mentorship programs. 

This Spring, the ELISA Project is hosting two mentorships that will help developers gain real-world knowledge in a hands-on learning experience with Linux and open source. It also provides a more defined path for ELISA to connect with the next generation to inject more talent into their developer base.

The Spring Mentorship session, which kicked off in March, paired mentees with leaders from Codethink, the Linux Foundation and Mobileye. The ELISA Project is excited to welcome  Irenge Jules Bashizi, Shefali Sharma and Wenhui Zhang as the newest mentees in the ELISA community. Please see below for more details about their mentorships and mentors. As they settle into their new roles, we hope to feature their mentorship journey in upcoming blog posts. 

Mentorship: Analysis of eBPF (extended Berkley Packet Filter) Verifier

To make eBPF programs “safe”, the Linux kernel validates all eBPF code before loading. However, the current validator has many known limitations, leading to rejection of working programs. 

Focus in this mentorship will be: 

  • In-depth analysis and review of the eBPF validator, and its use to validate eBPF programs.
  • Code enhancements to the validator to improve usability.
  • Identify use cases for kernel profiling in safety critical applications.
Elana Copperman

Mentor: Elana Copperman, Chair of the Linux Features for Safety-Critical Systems Working Group and System Safety Architect at Mobileye (part of Intel)

Elana provides support for designing safety features in Mobileye products, including system boot; drivers; and Linux infrastructure. Before working at Mobileye, she worked as a Security Architect for Cisco-Il (formerly NDS) and more recently as a security consultant for major European automotive concerns on behalf of various Israeli startups. Research interests focus on software engineering methodologies and security engineering.

In particular, focusing on expanding open source and Linux-based tools to support safety critical and life saving product development.

Irenge Jules Bashizi

Mentee: Irenge Jules Bashizi

Jules is a Computer science student at University of Manchester. He is a certified Linux System administrator.  Jules is interested in improving his skills in Kernel engineering by contributing to the Linux Kernel community by submitting patches. This internship offers him a unique opportunity tailored to improve and contribute.  As a hobby, Jules enjoys jogging..

Mentee: Wenhui Zhang

Mentorship: Discovering Linux kernel subsystems used by OpenAPS

OpenAPS is an open source Artificial Pancreas System designed to automatically adjust an insulin pump’s insulin delivery to keep Blood Glucose in a safe range at all times. It is an open and transparent effort to make safe and effective basic Automatic Pancreas System technology widely available to anyone with compatible medical devices who is willing to build their own system.

What happens when an OpenAPS workload runs on Linux? What are the subsystems and modules that are in active use when OpenAPS is running? What are the interactions between OpenAPS and the kernel when a user checks how much insulin is left in the insulin pump?

The ELISA Medical Devices Working Group set out to answer these questions. Understanding the kernel footprint necessary to run a workload helps us focus on the  subsystem and modules that make up the footprint for safety.

The mentee will:

  • Use Linux kernel tracing and strace tool to discover Linux kernel subsystems used by OpenAPS. 
  • Find Linux system calls supported on various architectures. 
  • Write a blog/whitepaper on the findings which will aid ELISA Medical Devices WG to focus on the  subsystem and modules that make up the footprint for safety.

Shefali Sharma has started working on the project to advance the work Shuah and Milna have shared in their recent blog here

Mentor: Milan Lakhani, Co-Chair of the Medical Devices Working Group and Systems and Software Engineer at Codethink

In open source, Milan’s contributions to Linux kernel are aimed at achieving ELISA project goals. Other than that, he has previously worked in the Trustable and community – mainly STPA analysis on design and writing requirements and tests and also some patches to help with making a webapp and porting. 

There are a lot of aspects and opportunities to really learn through experience and take responsibility to make an impact on a highly approved, tested and growing Closed Loop Open-Source insulin delivery system that is really helping to reduce issues of people with type 1 diabetes. There should also be some variety in the tasks and the approach that the mentee can do. Milan is excited to share his skills and knowledge with STPA (our method of safety analysis for the system), the OpenAPS system and codebase (OpenAPS is the medical device itself) and Linux kernel.

Shuah Khan

Mentor: Shuah Khan, ELISA Project TSC Chair and Linux Foundation Fellow

Shuah is an experienced Linux Kernel developer, maintainer, and contributor. She has extensive experience in open source development, actively working across Linux Kernel sub-systems.

She currently maintains the Kernel Selftest, USB over IP, and cpupower tools. She is an active contributor to the Linux media sub-system.

Shuah has a passion for mentoring and educating the next generation. She loves mentoring and training engineers new to open source and helping them become committers and reviewers.

Shefali Sharma

Mentee: Shefali Sharma

Shefali is a third year Computer Science Engineering student from Meerut Institute of Engineering and Technology, Meerut, India. She likes to explore new technical domains. She is very excited to work on the OpenAPS project as it will give her an opportunity to use her technical skills for the welfare of others and to get involved in the Linux kernel community. Apart from this she is also interested in DevOps and Machine Learning.

Established Working Group Updates

By Blog, Working Group, Workshop

Planning is currently underway for the ELISA Project Spring Workshop, which takes place virtually on April 5-7. If you haven’t yet, you can submit a CFP here (by Friday, March 4) or register to attend here.

As we prepare for the next workshop, we’ll be taking a look at the most popular sessions from the November event. A full recap by Philipp Ahmann, ELISA Project Ambassador and TSC member can be found here.

In this video, Shuah Khan, ELISA Project Chair of the Technical Steering Committee, kicks off the November Workshop with an overview of the TSC and introductions to a few of the Working Group Chairs for updates. Watch the video to learn more about the focused working groups for Safety Architecture, Tool Investigation and Code Improvement, Medical Devices and Automotive.

To join a working group click here:

To attend the April 2022 Workshop, register here:

Discovery Linux Kernel Subsystems used by OpenAPS

By Blog, Working Group

Written by Shuah Khan, Chair of the ELISA Project Technical Steering Committee, and Milan Lakhani, member of the ELISA Medical Devices Working Group

Key Points

  • Understanding system resources necessary to build and run a workload is important.
  • Linux tracing and strace can be used to discover the system resources in use by a workload.
  • Once we discover and understand the workload needs, we can focus on them to avoid regressions and evaluate safety.

OpenAPS is an open source Artificial Pancreas System designed to automatically adjust an insulin pump’s insulin delivery to keep Blood Glucose in a safe range at all times.

It is an open and transparent effort to make safe and effective basic Automatic Pancreas System technology widely available to anyone with compatible medical devices who is willing to build their own system.

Broadly speaking, the OpenAPS system can be thought of performing 3 main functions. Monitoring the environment and operational status of devices with as much data relevant to therapy as possible collected, predicting what should happen to glucose levels next, and enacting changes through issuing commands, emails and even phone calls.

ELISA Medical Devices WG team has set out to discover the Linux kernel subsystems used by OpenAPS. Understanding the kernel footprint necessary to run a workload helps us focus on the  subsystem and modules that make up the footprint for safety. We set out to answer the following questions:

  • What happens when an OpenAPS workload runs on Linux?
  • What are the subsystems and modules that are in active use when OpenAPS is running?
  • What are the interactions between OpenAPS and the kernel when a user checks how much insulin is left in the insulin pump?

So how do we discover the Linux kernel subsystem in use? The Linux kernel has several features and tools that can help discover which modules and functions are being used by an application during run-time. Using these tools, we can gather the system state while the OpenAPS workload is running to determine which parts of the kernel are being used.

Let’s talk a bit about kernel states. The kernel system state can be viewed as a combination of static and dynamic features and modules. Let’s first define what static and dynamic system states are and then explore how we can visualize the static and dynamic system parts of the kernel.

Static System View comprises system calls, features, static modules and dynamic modules enabled in the kernel configuration. Supported system calls and Kernel features are architecture dependent. System call numbering is different on different architectures. We can get the supported system call information using the auditd package tool. ausyscall –dump prints out the supported system calls on a system. You can install the auditd package by running “sudo apt-get install auditd” on Debian systems. Linux kernel script scripts/ can be used to check if current architecture is missing any function calls compared to i386. scripts/ < list> can be used to list the Kernel feature support matrix for a system or list –arch=arm for example lists the Kernel feature support matrix of the ‘arm’ architecture

Dynamic System View comprises system calls, ioctls invoked, and subsystems used during the runtime. A workload could load and unload modules and also change the dynamic system configuration to suit its needs.

OpenAPS Static View

Let’s first look at the OpenAPS sources to understand the workload from a static view. The OpenAPS workload is a collection of  python libraries, python-dev, software-properties-common, python-software-properties, python-numpy, python-pip, nodejs-legacy and npm. You can have a look at the OpenAPS repositories in with the two main ones being and . The initial dependencies that the user installs can be seen here 

One easier way to understand its runtime characteristics is watching the system state while a workload is running. We determined that the following methodology and tools would work well for us to observe the system activity. 

What is the methodology?

The first step is gathering the default system state such as the dynamic and static modules loaded on the system. lsmod command prints out the dynamically loaded modules on a system. Statically configured modules can be found in the kernel configuration file. Understanding the default system is necessary to determine the changes if any made by the workload.

The next step is discovering the Linux kernel footprint used by OpenAPS by enabling event tracing before starting the workload, gathering dynamic modules while the workload is running. Once the workload is stopped, gather the event logs, kernel messages.

Once we have the necessary information, we can extract the system call numbers from the event trace log and map them to the supported system calls.

Putting our methodology to test

Our initial plan was to use strace to trace system calls and signals used by OpenAPS commands in strace. strace runs the specified command until it  exits. It intercepts  and  records  the  system  calls  which are called by the process and the signals which are received by the process. It gives insight into the syscalls OpenAPS commands use. However, we realized quickly that OpenAPS employs setup scripts to launch its workload. As a result, using strace was not an option.

We modified OpenAPS in to enable event tracing before OpenAPS starts its workload (processes, shell scripts).  This approach gives us an overall information about OpenAPS. We will develop a higher level view and then dive into individual OpenAPS commands..


diff –git a/bin/ b/bin/

index 261da95b..5ae666e2 100755

— a/bin/

+++ b/bin/

@@ -1269,6 +1269,11 @@ if prompt_yn “” N; then

 fi # from ‘read -p “Continue? y/[N] ” -r’ after interactive setup is complete

+# ELISA enable event tracing

+echo “ELISA: Enable event tracing on all events”

+echo 1 > /sys/kernel/debug/tracing/events/enable

+cat /sys/kernel/debug/tracing/events/enable


 # Start cron back up in case the user doesn’t decide to reboot service cron start


We were able to gather traces with the above modification to As mentioned earlier, the ausyscall tool dumps out mapping for syscalls and their corresponding syscall table numbers. The mapping is architecture dependent for some system calls. The trace data includes NR followed by a number in the trace file. These are the syscalls that are run during the time the tracing was on. Using the tracing and system call information, we determined the system calls used by the OpenAPS workload. In addition we used scripts/ to check for system call support status on RasPi.

What did we do to gather traces and system state?

  • Start OpenAPS workload with modified the modification to enable tracing
  • Let the workload run for 30 minutes
  • Discard last 5 minutes of trace from analysis to account for interference (rsync and plugging devices) with trace file extraction
  • Stop OpenAPS.
  • Extract trace file from the system – cat /sys/kernel/debug/tracing/trace > trace.out
  • Run lsmod after OpenAPS workload starts to gather module information
  • Run “ausyscall –dump > syscalls_dump.out

Analyzing traces:

  • Map the NR (syscal) numbers from the trace to syscalls from the syscalls dump.
  • Categorize system calls and map them to Linux subsystems.

Findings and observations:

Kernel module usage:

Module NameUsage count  (OpenAPS)Usage count (default)
cmacNot loaded1
ecdh_generic1 (bluetooth)2 (bluetooth)
ecc1 (ecdh_generic)1 (ecdh_generic)
spidev2Not loaded
i2c_bcm28351Not loaded
spi_bcm28350Not loaded
i2c_dev2Not loaded

Subsystem usage:

Subsystem# of calls

Updated System view:


This tracing activity was a good way of identifying which parts of the kernel are used by OpenAPS. This helped to generate the Updated system view, so it is useful for our goal to do an STPA analysis of OpenAPS Operating System activity. We plan to theoretically analyse how these different subsystems can interact unsafely, while using fault injection and mocked components to collect more traces.

As mentioned earlier, the approach we used so far gave us a higher level of information about the OpenAPS usage. It isn’t ideal that this higher information doesn’t tell us the system usage by individual OpenAPS commands. As an example, we won’t be able to clearly identify which system calls are invoked when a user queries insulin pump status.

We are in the process of gathering fine grained information about individual OpenAPS commands and important use-cases. As an example, what subsystems are used when a user queries the insulin pump status. We are  using the strace command to trace the OpenAPS commands. We will share our findings in our next blog on this topic.

SPDX-License-Identifier: CC-BY-4.0

This document is released under the Creative Commons Attribution 4.0 International License, available at Pursuant to Section 5 of the license, please note that the following disclaimers apply (capitalized terms have the meanings set forth in the license). To the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.

To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.

The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.

Analyzing Open Source Interactions in Linux Based Medical Devices

By Blog, Working Group

Written by Kate Stewart and Jason Smith, ELISA Project Medical Devices Working Group Members

The ELISA Project has several working groups with different focuses including Automotive, Linux Features for Safety-Critical Systems, Medical Devices, Open Source Engineering Process, Safety Architecture and Tool Investigation and Code Improvement. The Medical Devices Working Group consists of experts in Linux, medical, and functional safety applications that work together on activities and deliverables intended to help the safe development of medical devices that include Linux-based software.  These activities include, but are not limited to, white papers describing best practices and safety requirements for medical devices using operating systems such as Linux, and conducting safety analyses of open source medical device projects that use Linux such as OpenAPS.

The safety of medical devices is very important, and can be influenced to a great extent by any software that is contained in the medical device.  Failure of software in a medical device can unfortunately cause harm to persons or worse, as demonstrated in the incidents involving the Therac-25 several decades ago.  Therefore, if a medical device is using an operating system such as Linux, the performance and safety of Linux then comes under scrutiny.

In the context of medical device safety standards such as IEC 62304, when Linux is incorporated into a medical device, it is considered to be something called Software of Unknown Provenance (SOUP).  In this case, the medical device manufacturer incorporating Linux into their device did not develop Linux and therefore does not fully know what level of quality processes were used to develop Linux in the first place.  Standards like IEC 62304 allow the usage of SOUP such as Linux; however, IEC 62304 requires that risks associated with the failure of SOUP have been considered and addressed by the manufacturer.

The Medical Devices Working Group is in the process of developing a white paper summarizing requirements from IEC 62304 pertaining to SOUP to assist medical device manufacturers.  If you have experience in Linux, medical, or functional safety applications, the Medical Devices Working Group welcomes your input on this white paper.

One of the interesting challenges with medical devices is that often most of the source for the system is restricted, and not openly available.  This presents a challenge when trying to do analysis on how Linux is being used in such systems.   

The OpenAPS project is a hobbyist project to create a feedback system between an insulin pump and glucose monitor to aid the Type 1 diabetes users to build systems to help manage their blood glucose levels.  That the project is open source means that we can see the code and have a starting point for analysis. 

The Medical Devices Working Group has been using System Theoretic Process Analysis (STPA) to analyze the system, which they call a “rig”, and the Linux system interactions within it.  A rig consists of the Raspberry PI (running Linux and algorithms), glucose monitor (commercial) , insulin pump (commercial), and some data logging device.  How to set up a rig and use it is documented by the OpenAPS project, which has significantly aided our analysis. 

At this point,  we’ve applied the STPA analysis through a couple of levels and have iterated on the analysis a few times (STPA process helped us identify some factors we’d not considered in diagraming the system initially). The team is now working on collecting traces of the system interacting with the Linux kernel.   Tracing will let us continue to take the STPA analysis into the kernel subsystems.    

We are interested in learning of other open source projects using Linux in the context of a medical device.   If you know of such a project, or are interested in working with our team of volunteers,  please feel free to reach out at

ELISA’s New Linux Features for Safety-Critical Systems Working Group

By Blog, Working Group, Workshop

Written by Elana Copperman, ELISA project ambassador, Chair of the Linux Features for Safety-Critical Systems Working Group and System Safety Architect at Mobileye (Intel)

The Linux Features for Safety-Critical Systems (LFSCS) WG aims to feed into the OSEP and other WGs, working together as a team.  LFSCS invites engineers, architects and integrators who actually develop and deploy Linux-based safety-critical systems to contribute from their practical experience and knowledge.  In particular, to identify existing Linux kernel features that may be leveraged for use in safety-critical systems.  

For example:

  1. Mechanisms for protection of various memory types;  e.g. protection from faults due to uninitialized variables or stack overflow.
  2. Dynamic analysis for multi-threaded systems; e.g. tests based on tools such as TSAN or ASAN.
  3. Kernel profiling using ebpf-based tools; e.g.  perf-tools or bpftrace
  4. AER (Advanced Error Reporting) for fault handling; e.g. PCIe fault handling
  5. Safety extensions to Linux drivers; e.g. fault handling support and bridging the gap between hardware-based safety features and application layer fault handling.

The WG mailing list is open to registration here, and we are seeing an amazing group of contributors who can demonstrate use of such features in real systems, and help ELISA to learn from these experiences.  Initially, we will investigate existing features but will also propose enhancements to such features and to work as a community to design / implement / deploy kernel patches.  The goal of such patches will be to help make those features more amenable for use in safety critical systems.  Our Github playground is here.

The alliance with ELISA, and with the new Open Source Engineering Process Working Group in particular, is a critical aspect of this effort.  We will be working together to help ensure that those patches and features can be used by designers and integrators producing safety critical systems.

 The scope of this WG does not include safety qualification or any safety claims on how the integrator can or should use these features or patches.  The only claims that would be made are a description of the feature and its functional impact.

The WG will be formally kicked off at the upcoming ELISA workshop (November 8-10). We will be giving an overview of the working group and answer any questions on November 8 at 3 pm CET.  We will be scheduling weekly meetings following the workshop.  If the technical challenge of enabling real change in deploying open source Linux-based software for safety critical systems excites you, come join and help us meet the challenges!

You can still register for the Fall workshop, which is being held virtually and is free to attend. All registrants will be able to watch the sessions on-demand. Register here today!