Open Source Summit Europe 2024

Creating and maintaining a safety critical project comes with a lot of challenges. A central issue is keeping your documentation, starting from planning and guideline documents, down to requirements, safety analysis, reviews and tests, consistent and up to date. These artefacts often have their own lifecycle and are natively managed in different tools, with usually great traceability capabilities regarding dependencies between these artefacts as long as you stay within one tool or within a (usually propriety) tool family of one single tool vendor. Currently the resulting traceability gaps between these tools are handled either by the popular engineering tools like MS Excel or methods like “search for identical names”, depending highly on manual maintenance.

Using SPDX relationships, the upcoming Safety Profile in SPDX 3.1 will provide a model to represent all these dependencies as a knowledge model that can be used both to analyse possible impacts after a change (be it because of a security update or functional variants of your product), provide evidence of completeness and compliance as a Safety SBOM or simply keep track of your product variants.

In Safety Critical applications it is mandatory to ensure Sw Requirements traceability to Sw Specifications, Test Cases, Test Results, Bugs and more.
The process leading to this goal is usually complex and time-consuming and it is essential to understand the state step by step and highlight what remains to be done.
Moreover, for the intrinsic nature of a software project, we need to ensure traceability and test verification following any evolution in the ecosystem of the project.

BASIL The FuSa Spice, is an open source sw that provides a quality management solution aimed to address the above mentioned challenges for SW developments that are code driven and equally for the ones requirements driven.

We will see how to implement in BASIL Sw Requirements traceability to the source Code and to existing upstream Test Cases, how to execute them, how to navigate Test Results and artifacts and how to link failures to a bug in a bug tracking system.

We will also go into the details of a pipeline implementation based on the BASIL HTTP Api to understand how changes in one or more work items can be managed through automation with the goal of implementing a continuous certification framework.

Git monorepos that are under heavy load quickly become inefficient or even inaccessible. This impacts client operations of all types (e.g., git-upload-pack, git-receive-pack), especially during search-for-reuse phase.
Currently, the only countermeasures are a full GC or a geometric repacking on a regular basis or based on metrics.

As the repo history grows, running a full GC takes longer, is more expensive, and risks introducing additional workload at inopportune times (e.g., running GC during a burst of repository activity may bring nodes to a standstill).
In this talk, we will introduce an AI-driven approach to maintaining the performance of large Git monorepos that undergo heavy workloads.
The AI model will explore and learn different strategies, including partial repacking, bitmap regeneration, empty directory removals, and more, by evaluating its success using reinforcement learning.

In order to make functional safety claims on SW components, having a clear understanding of the underlying software architecture is crucial. However, if SW architectural documentation is missing, understanding how software operates and how its parts fit together can be challenging. For the Linux kernel and many other OSS SW, such documents are absent and instead, analysts must rely on code, which can be hard to read.
ks-nav is a tool designed to help in reverse engineering and understanding the code by generating diagrams that highlight the interactions between code elements and sub-elements.

ks-nav relies on binary images instead of source code analysis to get rid of the uncertainty introduced by configurations, compiler optimizations, and any other toolchain related issues. Additionally, using the MAINTAINERS file, it precisely pinpoints subsystems, enabling users to delve into their interactions with clarity.

This session focuses on:
* Why understanding the code is critical in FuSa activities;
* How ks-nav works, how it addresses the various challenges of analyzing the code;
* An example of how ks-nav can be used to support an expert-driven FMEA for a specific use case.

The increasing computation power of embedded CPUs has revolutionized industries such as Automotive, Aerospace, or Industrial by enabling centralized and enhanced use cases, software-defined functionalities, and increased automation. The challenges of this increased complexity are often addressed by incorporating Open Source Software, particularly Linux, virtualization and RTOS. As these industries are heavily regulated by quality and safety-integrity standards, the certification of these highly complex systems becomes crucial.

Starting from the similarities and overlaps in system architecture design across use cases, this talk will explore the demands imposed by safety integrity standards in various industries. To develop these systems and adhere to required processes, the integration of tools and a high degree of automation is essential.

The authors show how Open Source projects bridge the gap between open source and safety-criticality, introducing tools and processes, and showcasing collaborative efforts in creating reproducible example system architectures. These systems can serve as a foundation for companies and projects adopting Open Source in safety-critical applications.

Bringing an existing codebase into MISRA compliance is known to be a difficult, risky and time-consuming task. Yet, when a product needs a functional safety certification and rewriting the software is out of question, this is a necessity. Such an endeavor requires facing multiple tradeoffs and, consequently, lots of experience both on the codebase and on MISRA. The choices between deviating the guideline, and the (often, many) ways in which code may be changed and deviations may be formulated, are tough and with consequences that are not immediately evident. The situation is particularly interesting in the case of open-source software, where additional challenges have to be faced. In this presentation, we illustrate our experience and the several lessons learned while undertaking MISRA compliance work in open-source projects, most notably the Zephyr RTOS and the Xen hypervisor, both used in many embedded systems. Key take-home points include: effective deviation strategies and mechanisms; dealing with the MISRA C essential type model (guidelines related to that account for many of the violations in existing codebases); interaction with open-source communities.

This session is about often unexpected and sometimes intricate defects that may either occur infrequently, seemingly randomly, or only in very specific corner cases.

These defects are often overlooked by developers, and most tests may not discover them either, despite how widespread they are, often lurking in plain sight, waiting to strike at the most unfortunate moment.
In this session, we will take a look at some code examples, we will talk about the sometimes surprising ways in which things can go wrong, and about how to avoid repeating the same mistakes.