THE LINUX FOUNDATION PROJECTS

How AvioNix Supports Reproducibility and Traceability for Linux in Avionics

Session Clip - ELISA Seminar – AvioNix: Infrastructure as Code for Linux in Avionics

The ELISA Project hosted a seminar on AvioNix: Infrastructure as Code for Linux in Avionics, featuring Wanja Zaeske, Research Scientist at the German Aerospace Center, and Erin Vanderveen, Sr. Specialist Functional Engineer at Tweag by Modus Create.

The session focused on a key challenge for bringing Linux into safety-critical aviation applications: open source software is distributed and released in many different ways. Compared to COTS walled-garden safety-critical operating systems, this diversity can create long “getting started” processes, “works on my machine” issues, and the need for robust SBOM tracking.

Erin began with an introduction to Nix, explaining that Nix is not one single tool, but an ecosystem that includes the Nix CLI, Nix daemon, Nix store, Nix language, Nix packages, and NixOS. The talk showed how Nix supports declarative, reproducible, and reliable builds by using explicit build inputs, isolated build environments, and unique store paths.

The session also explained how Nix can help solve common dependency and developer environment problems. With Nix, packages and development shells can be described in a way that allows contributors to enter the same build environment and reproduce the same results across machines.

Traceability was another important theme. Because Nix captures exact dependencies and build inputs, it can support detailed SBOM generation. This is especially useful for safety-critical software efforts where teams need a clear view of what components are included and how they were built.

Wanja then showed how these Nix concepts are being applied in the ELISA Aerospace Working Group through AvioNix, a Nix-based approach for building aerospace demo applications. The demonstration used the ELISA Aerospace Working Group repository and showed how contributors can build applications with a single command, compile the Linux kernel, inspect kernel configuration, and create development environments for debugging and experimentation.

The demo also showed how NixOS can be used to build a fully integrated system that includes a Linux kernel, user space, ELISA Aerospace Working Group demo applications, and a NASA cFS-based monitor. This included a light switch demo application and related monitoring software running inside a QEMU-based system.

A practical troubleshooting example highlighted how Nix can support debugging. The speakers showed how to add GDB, enable debug symbols, access the exact source used during the build, identify missing Linux kernel configuration options, and rebuild the system with the required changes.

The session also covered cross-compilation, an important topic for aerospace environments where development machines and target platforms may use different architectures. Nix provides mechanisms to describe build, host, and target platforms so teams can build software for different hardware configurations more consistently.

A key takeaway from the session was that Nix can scale across the software stack. It can support individual packages, development shells, Linux kernel builds, user space, virtual machines, and integrated system images. For the ELISA Aerospace Working Group, AvioNix provides a practical demonstrator for making Linux-based aviation software easier to build, reproduce, test, debug, and share.

The Q&A highlighted practical ways Nix can support existing engineering workflows while improving reproducibility and experimentation. One attendee asked whether it is easy to branch from an existing Nix package to explore changes. Wanja explained that this can be done by copying the expression into a project tree and modifying it, or by using Nix’s override mechanisms. Since Nix treats packages as functions, teams can create variations of a package, apply patches, or adjust build phases without rewriting the entire package definition. This is especially useful in avionics-related work, where less common architectures may require package-specific changes.

Another question focused on whether Nix can replace CMake. Wanja explained that while Nix can be used as a build system, he would not typically use it to replace CMake in a project that already uses CMake. Instead, Nix can layer around CMake by providing the required dependencies, libraries, and build environment. In the demo, the NASA cFS application still used CMake, while Nix handled the surrounding package and dependency setup.

The discussion also compared Nix with building inside a virtual machine and redistributing the VM image. Wanja noted that a VM image alone does not guarantee reproducibility. Build systems may download missing libraries, pull changing upstream branches, or install dependencies dynamically, which can lead to different results over time. With Nix, the desired system is described through Nix expressions, making the build inputs and dependencies more explicit and easier to understand than a binary VM image.

Attendees also asked how Nix compares with CMake or Bazel when starting a new product. Wanja described CMake and Nix as having different scopes: CMake builds the software, while Nix works more like a meta build system that makes the needed dependencies available. Erin added that Nix and Bazel can also be combined, including through Bazel rules that use Nix packages to provide reproducible dependencies.

At the end of the session, there was also a question about the relationship between Dhall and the Nix language. Erin explained that Dhall and the Nix language are both configuration languages, but separate tools. He also noted that Nix as a whole is more than the Nix language; it also includes the CLI, daemon, store, package collection, and NixOS.

As the community continues exploring Linux for safety-critical aviation applications, AvioNix demonstrates how Infrastructure as Code can help improve reproducibility, traceability, and collaboration across open source aerospace development. The discussion also showed that AvioNix is not about replacing existing tools such as CMake, Bazel, virtual machines, or Linux kernel workflows. Instead, it shows how Nix can provide a reproducible and traceable layer around those tools so aerospace contributors can build, debug, test, and share Linux-based demo systems more consistently.