Skip to main content

Working Group

ELISA Working Groups

By Blog, Working Group, Workshop

Since launch in February 2019, the ELISA Project has created several working groups that collaborate and work towards providing resources for System integrators to apply and use to analyze qualitatively and quantitatively on their systems. Current groups include an Automotive Working Group, Medical Devices Working Group, Safety Architecture Working Group and Tool Investigation and Code Improvement Sub-Working Group to focus on specific activities and goals. 

If you’re interested in learning more about the goals and objectives for these working groups or asking questions, we invite you to the ELISA Workshop on November 8-10. The virtual workshop, which is free to attend, will host speakers from Arm, Codethink, Elektrobit Automotive GmbH, Evidence Srl, Google, Intel, Mobileye, The Linux Foundation, Red Hat and UL LLC.

On Monday, November 8 at 5-6 am PDT, the working group chairs will provide updates on all activities. Led by Gabriele Paoloni, Lukas Bulwahn, Kate Stewart, Shuah Khan, Milan Lakhani, Jason Smith, Jochen Kall and Philipp Ahmann, you can add this to your schedule here.

Additionally, we also recently announced two more working groups:

Open Source Engineering Process Working GroupThis working group aims to examine safety-related claims that we might like to make about Linux as part of a system, and to explore how we can gather and present evidence to support such claims.

Linux Features for Safety-Critical Systems Working Group: This working group will work to bring together kernel developers and producers of safety critical systems to demonstrate use of such features in real systems, and to learn from these experiences together as a community.

If you want to learn more about these two new working groups, we invite you to the session on November 8 at 6-630 am PDT lead by Paul Albertella and Elana Copperman. Add this to your schedule here.

To register or to review the complete schedule, click here:

The ELISA Project Continues to Grow its Global Ecosystem by Welcoming Red Hat as a Premier Member and Banma, Lotus Cars and SUSE

By Announcement, News, Working Group, Workshop

Schedule for the ELISA Fall Workshop on November 8-10 is now live

SAN FRANCISCO – October 20, 2021 – Today, the ELISA (Enabling Linux in Safety Applications) Project, 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, announced that Red Hat has upgraded its membership to premier member and welcomes Banma, Lotus Cars and SUSE as the newest members.

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 by the Linux Foundation, ELISA works with Linux kernel and safety communities to agree on what should be considered when Linux is to  be used in safety-critical systems.

“Linux underpins many applications today that have safety-critical and cybersecurity implications,” said Kate Stewart, Vice President of Dependable Embedded Systems at The Linux Foundation. “By collaborating together, the ELISA members are defining the best practices for use of Linux in these systems. We look forward to continuing to build consensus and welcoming expertise and collaboration from these new members.”

Attend the Fall Workshop

Since its inception, ELISA has hosted quarterly workshops that bring together project members and community contributors to discuss working group updates, trends in functional safety, use cases and more. The next workshop will be held virtually on November 8-10 and is free to attend. Speakers include thought leaders from Arm, Codethink, Elektrobit Automotive GmbH, Evidence Srl, Google, Intel, Mobileye, The Linux Foundation, Red Hat and UL LLC. Register and check out the schedule:

Join the New Working Groups

Since launch, the project has worked to establish a governance model that creates processes and guidance to the focused working groups that aim to provide resources for System integrators to apply and use to analyze qualitatively and quantitatively on their systems. Today, ELISA announces two new working groups:

  • Open Source Engineering Process Working Group: This working group aims to examine safety-related claims that we might like to make about Linux as part of a system, and to explore how we can gather and present evidence to support such claims.
  • Linux Features for Safety-Critical Systems Working Group: This working group will work to bring together kernel developers and producers of safety critical systems to demonstrate use of such features in real systems, and to learn from these experiences together as a community. Learn more about this new working group in this November Workshop session

Learn more about the Global Ecosystem

Red Hat, which is known for its leadership in linux and open source, joined ELISA earlier this year and has been very active in the technical community. With their upgraded membership to Premier, Red Hat welcomes Gabriele Paoloni, Open Source Community Technical Leader at Red Hat, as the ELISA Project Governing Board Chair.

“Red Hat announced our intent to expand our expertise in Linux to safety-critical automotive use cases earlier this year as we work to develop a Linux in-vehicle operating system,” said Francis Chow, vice president, In-Vehicle Operating System, Red Hat. “As such, we’re pleased to extend our participation in ELISA as a Premier member and collaborate with other industry leaders in building up open source software for applications that require extremely high levels of trust and functional safety. We believe a standardized common set of tools and processes can drive innovation toward the software-defined vehicle. ”

Additionally, ELISA welcomes Banma, a Chinese startup specializing in automotive software;  Lotus Cars, a leader in automotive manufacturing in China; and SUSE, a global leader in open source software specializing in enterprise Linux, Kubernetes management, and edge solutions.  These new members join ADIT, AISIN AW CO., arm, Automotive Grade Linux, BMW Car IT GmbH, Codethink, Elektrobit, Horizon Robotics, Huawei Technologies, Intel, Toyota, Kuka, Linuxtronix. Mentor, NVIDIA, Suzuki, Wind River, OTH Regensburg and Toyota.

“Compared with other open software, safety is the key differentiation of automotive OS”, said Sean Xiao, Chief Architect at Banma. “The mission of Banma is to help automotive makers deliver intelligent cars by offering advanced vehicle open software. The ELISA Project combines safety and linux, which offers flexibility and openness, and closely aligns with our goals.”

“For nearly 30 years, SUSE has been a trusted partner supporting systems and essential workloads in some of the most challenging and critical industries in terms of safety requirements, such as automotive and transportation, government, aerospace and defense, industrial and manufacturing, and healthcare,” said Ivo Totev, SUSE COO. “We already collaborate with current ELISA members on important initiatives and are pleased to join ELISA as a formal member to continue to provide innovation in safety-critical domains.”

For more information about ELISA, visit

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found 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.


Architecture Working Group: A report on Kernel FFI (Freedom From Interference) and some philosophical musings

By Blog, Working Group

Written by Eli Gurvitz,  ELISA Project Ambassador and Functional Safety Architect at Intel (Mobileye)

In a functional safety system FFI is required when the system consists of elements of different Safety Integrity Levels (ASIL).This is to ensure that elements allocated with a lower ASIL do not interfere with elements allocated with a higher ASIL; if FFI cannot be demonstrated the lower ASIL elements must be upgraded to the higher ASIL.

The Architecture Working Group has been discussing “Freedom From Interference (FFI)” in the last several meetings and is considering two aspects:

  • FFI between user space processes allocated with different ASIL
  • FFI between Linux Kernel components/drivers/subsystems allocated with different ASIL

This blog post focuses on the second bullet.

FFI is a key goal of a possible Safety Concept for Linux because Linux is too complex and has too many features, thus considering Linux as a single element of a certain ASIL would result in a very high functional safety qualification effort. If the application runs in a single threaded process and handles interrupts synchronously, then it may be possible to avoid allocating Safety Requirements to the OS and mitigate all failures with application-level safety mechanisms. But this kind of use requires just a simple OS and Linux is an overkill. Using Linux in the way it was meant to be used means it will be the OS of a multi-core SoC that runs many processes with different requirements of different ASILs.

This mode of use is referred to in ISO 26262 part 6 section 7.4.8:

This section refers to ISO 26262 part 9 Clause 6 “Criteria for co-existence of elements”. This clause states:

The Architecture WG investigation considers the Linux kernel partitioned into  sub-elements of mixed criticality, therefore the goal is to show FFI between the sub-elements. The approach to FFI that is currently being discussed in the Architecture WG was developed by ELISA Project members Mobileye and BMW.  

The first step in demonstrating FFI between safety-related and non-safety-related sub-elements is to identify the sub-elments and to allocate them with an ASIL. Since we are analyzing a SW component, the sub-elements are functional areas (or features) of the kernel, e.g. memory management or file systems, and they are made of C language functions. We classify the C functions according to the allocated ASIL by using the Call Tree Tool.

The goal of Call Tree is to statically generate the tree of function calls departing from a specified input one; hence starting for example from a syscall, Call Tree would generate the tree of all invoked functions. Call Tree scans the Linux source code by using the GNU CFlow utility and generates an SQLite database that contains all functions and their calling relations – this provides an almost full call-tree for every C function. 

To classify every Kernel function we allocate Kernel entrypoints (syscalls and interrupt handlers) with safety requirements and associated ASIL; hence every function falling in a certain tree inherits the ASIL associated with the top level entrypoint. If a function is present in multiple trees, it is then assigned with the highest ASIL across those allocated to the different trees.

For example, if there’s a safety requirement for “safe dynamic memory” then we consider the related system calls – mmap, sbrk – as safety related. The union of all functions in the call trees of mmap and sbrk are considered SR and inherit the ASIL allocated to mmap and sbrk.

Once we have partitioned the Kernel the next step is to consider the possible types of interference. These types are defined in Annex D or ISO 26262 part 6. There are three types of interference:

  • Temporal – interference related to time or scheduling. The most common case is when one kernel thread prevents other threads from getting CPU cycles, thereby causing delays. Another example is a process crashing.
  • Spatial – interference related to space, or memory. For example, a lower ASIL driver  may corrupt a kernel data structure.
  • Communication – normally this type of interference relates to transfer of data between two entities over a communication channel. In our analysis we consider static and global variables and pointers as communication channels between sub-elements of the kernel.

The Architecture Working Group plans to deal with all types of interference and currently we are considering the third type – communication interference. We are looking at areas where the internal state of the kernel can be corrupted because of the interaction between NSR and SR C functions (or more generally, C functions of different ASIL ratings). 

The internal state of the kernel consists of many persistent data structures. These data structures, for example linked lists, are pointed to by global and static variables and pointers. Corruption of these data structures can occur in different ways.

Data structures that are accessed via global variables can be corrupted when a lower ASIL function (for example a driver that is rated as ASIL QM) accesses the same data structure that is also used by an ASIL-B function, as depicted in the diagram below. 

Corruption of data structures that are accessed via static variables can occur when a static variable is used by a higher ASIL (or SR) function but this function is used by a lower ASIL (or NSR) function. The NSR function may pass a faulty argument to the SR function and the SR function may use this argument to modify the data structure. The faulty data structure is later used in a safety-related flow. This failure mode is depicted in the diagram below.

This description is only a preliminary formulation of the concept of communication interference within the kernel. The working group is debating the correct use of terms, the concept itself, the correct use of the Call Tree Tool and the selection of ASIL rated system calls for our sample automotive use case – The Tell-Tale signal.

If you are interested in safety engineering, the Linux kernel, or both, then please join us in these discussions. The nice thing about applying the existing Functional Safety standards to the Linux kernel is that there’s plenty of space and freedom for creativity, as these standards were designed for much simpler HW and very much simpler SW. It is as if there’s a written tradition of Safety architecture – the ISO 26262 standard and an Oral interpretation of it which creates a more modern tradition of Safety. You can be a part of creating this tradition. I should also take back the word “creativity” I used four lines above because it will certainly trigger a hot debate around the question of whether Safety likes “creativity” or hates it. So I’ll clarify that we are trying to be creative in a conservative way.

Learn more about the ELISA Architecture Working Group or any of the other groups in this white paper.