|
|
Subscribe / Log in / New account

Introducing Space Grade Linux

By Jake Edge
September 9, 2025

ELCE

A new project, targeting Linux for the proverbial final frontier—outer space—was the subject of a talk (YouTube video) at the Embedded Linux Conference, which was held as part of Open Source Summit Europe in Amsterdam in late August. Ramón Roche introduced Space Grade Linux (SGL), which is currently incubating as a special interest group (SIG) of the Embedding Linux in Safety Applications (ELISA) project. The idea is to create a distribution with a base layer that can be used for off-planet missions of various sorts, along with other layers that can be used to customize it for different space-based use cases.

By way of an introduction, Roche said that he is from Mexico and is the maintainer of a few open-source-robotics platforms; he comes from many years in the robotics industry. He is the general manager of the Dronecode project and is the co-lead of its Aerial Robotics interest group. Beyond that, he and Ivan Perez are co-leading the Space Grade Linux SIG.

Linux and space

Roche asked the audience a series of questions about space, ending with: "is Linux in space a worthwhile dream?" The audience responded affirmatively, but it was a trick question. "The answer is 'no', it's actually a present reality, not a dream." He then went through a list of projects using Linux in space including the James Webb Space Telescope, SpaceX Starlink satellites, the Ingenuity helicopter on Mars, the International Space Station (ISS), and more. He noted that Starlink is the largest deployment of Linux in space, already, with a plan for up to 30,000 Linux-based satellites in its constellation.

[ISS exploded view]

From his slides, he showed an exploded view of the different parts and pieces of the ISS (seen above), which demonstrated that it consists of "tons of modules, from different agencies distributed across the world, much like open source". That kind of project requires a bunch of standards so that the various modules can fit and work together. The result can look rather chaotic, as his slide of the ISS interior with cables and gear seemingly haphazardly scattered about (seen below), showed. "There's a lot of Linux running in there", he said.

[ISS interior view]

He asked if anyone knew what was driving the increase in space activity recently; Tim Bird, who is part of the project, suggested "lower cost to orbit", which Roche said was "exactly right". He put up a "flywheel" diagram and a graph of payload cost by kilogram that came from a blog post by Max Olson. The former shows how all of the different improvements in the process—increased safety, lower development costs, cheaper launches, higher customer confidence, and so on—feed right back into increasing the number of launches.

But the main factor driving launches is the decreased cost to deliver payloads to space. In the 1960s, the cost for a kilogram to orbit was up to $20,000, in a 20-ton rocket. In 2020, the SpaceX Starship, at 17 tons, was estimated to be able to deliver a kilogram for $190; if Starship ends up being mass produced, so there are, say, 50 of them, that estimate drops to around $60. "That means that anyone can, eventually, deploy to space, which will mean that the industry will only grow."

Linux in space

"If Linux is already in space, and deployments will only increase, what are we doing here?" One of the problems is that there is a lack of standards—which Linux is being used—that is hurting the industry, Roche said. The SIG did an informal survey of the distributions being used in space missions, which showed the fragmentation; most were using Yocto-based distributions, but there were many others, including Android, Arch Linux, Red Hat, and Ubuntu, as well as non-Linux solutions such as RTEMS, Zephyr, FreeRTOS, and others.

[Ramón Roche]

In truth, most of the deployed missions are one-off designs that are not being reused; "we're not yet in an era where there are mass-produced deployments out there". There is almost no portability of code (or hardware) between missions, nor is there any "cross-vendor knowledge transfer". Vendors are not working out standards between themselves to make space-mission designs reusable in various ways.

There are a number of space-environment considerations to keep in mind. For example, there is no traditional networking in space, he said. Communication is slow with periodic loss-of-signal events. Right now, those overseeing devices in space need to have system-administration skills in order to send commands and retrieve telemetry from them. Going forward, that should be fixed, he said, because not everyone in mission control will have those skills. There are hardware-related concerns, as well, including radiation-induced failures of various sorts, NAND memory bit flips, and power consumption.

The idea behind SGL is to harness the "main characteristic of open source", community, in order to build a Linux distribution for space. Fostering an ecosystem for Linux in space is also planned; the first steps are to gather the relevant stakeholders to ensure that all of the important use cases are known. The plan is for SGL to be modeled on Automotive Grade Linux (AGL).

The approach is to have a Yocto base layer with the base configuration, then add other layers on top. SGL uses the MIT license for its code, with a developer certificate of origin required for contributions. It is planned to support specific hardware platforms as well.

The primary objectives of the project include reducing both costs and errors in building space-based devices. Instead of reinventing the wheel for each new mission, SGL will provide reusable software that will help minimize the development time, thus getting devices to space more quickly. Many space missions have similar requirements; they need an operating system that meets safety requirements, is radiation-resistant, and so on.

There is also a goal of reducing resistance to using Linux in space. Part of why the Linux Foundation is involved is to help overcome concerns about using open-source software for space missions. Beyond that, the project wants to facilitate high-performance workloads in space by ensuring that the base layer will work on next-generation boards and processors for spacecraft.

Status

Currently, the meta-sgl repository has a skeleton layer for Yocto that is focused on configuration of the kernel and other components for handling single-event upsets (or errors). Some of the areas that are being investigated and addressed are watchdog timers and fault detection, filesystem reliability with respect to radiation and power loss, over-the-"air" (really space) updates, bootloader and startup integrity, and others. The project is also working with other groups that are already deploying Linux in space to gather real-world requirements, which will be used to set priorities.

The three main user-space applications that are used in space right now are the NASA Core Flight System (cFS), NASA F Prime, and Open Robotics Space Robot Operating System (Space ROS), Roche said. They each have a "collection of middleware modules that the different missions utilized to be able to achieve autonomy". SGL is deriving requirements from those other platforms in order to ensure that its base layer covers those needs.

The hope is that the first demos for SGL will be given at the next Open Source Summit, he said, which will show one or more of those applications running on actual hardware. In addition, there were will be simulations of spacecraft based on SGL running on that hardware.

The BeagleV-Fire board is the current target hardware. It is similar to a Raspberry Pi, he said, but is based on the RISC-V architecture. It is "very affordable and we're choosing this so that everyone on the team can have it and we can deploy and test easily".

Looking at the roadmap, the first two items, the Yocto skeleton layer and the continuous-integration/continuous-development (CI/CD) pipeline, have both been completed. The initial documentation is a work in progress, while software bill of materials (SBOM) creation is awaiting some other work before it will be generated along with other build artifacts. Then there are a number of areas that are currently under investigation, including hardware testing, using fault injection in QEMU to test radiation resistance, the user-space layers, and the SGL demo.

The ELISA project is hosting the SGL SIG and is helping to provide it with the structure of a Linux Foundation project. There are monthly Zoom meetings, a mailing list, a Discord channel, and an organization GitHub repository for meeting minutes and the like. There are over 20 companies and organizations that have participated in the project so far, he said.

The NASA Goddard Space Flight Center hosted an ELISA workshop in December 2024. There were 30 in-person attendees and 40 virtual participants. The presentations and slides are available from the workshop. The initial direction of the SGL project was formulated during the workshop. The intent is to spin out SGL into its own foundation, with its own governance, but there is a need for funding in order to make that happen, Roche said.

He fairly quickly went through the responses to a survey that the project had completed around the time of the workshop. It only had 20 responses, so there are plans to do another sometime soon. It showed that half the respondents were from the space industry, around 32% were from aerospace, while automotive and other were both around 9%. Two-thirds of the respondents were using Linux for space-based projects. The survey questions covered areas like development tools, init daemons, flight software, security practices and standards, CPU architectures, hardware platforms, and more. The graphs of the responses can be seen in the "bonus content" in his slides.

Q&A

In response to a question from someone who was somewhat surprised about mid-mission software updates, Roche said that some projects are definitely doing that. Bird described some of the current practices, noting that spacecraft in low-earth orbit are often not updated, since they only have around a five-year lifespan due to orbital decay. On the other hand, "SpaceX notoriously does a lot of updating of their software". Beyond that, "we haven't seen Linux in deep space a whole lot yet"; only four or five projects have gone beyond low-earth orbit with Linux, he said.

Another question was about how SGL could provide software for wildly different mission types, such as for both the Ingenuity helicopter and a module for the ISS. Roche said that the idea is that the base layer will provide things that every mission type needs, such as radiation hardening, and then optional layers providing functionality like autonomy and automation services. Projects would put together whichever layers they need to fulfill their mission objectives.

It would seem that AGL and SGL might be able to work together and even share code, another attendee suggested. Roche said there was some overlap between the projects, so it would make sense to work together. The base requirements and configuration are different between the two, however. SGL is definitely trying to follow the model that AGL used, both to develop the distribution and to help create an ecosystem around it.

Safety certification for space was the topic of another question. It is something the SGL project would like to pursue, Roche said; if there is a mission that is interested in getting certified, SGL would like to work with it on that. Bird noted that there are tiers of safety certification for space, with manned missions having the most stringent requirements. "Somehow those tiers get relaxed in the face of cost." SpaceX is running Linux on manned missions, and Linux does not meet "all of the safety protocols that NASA has had for decades"; somehow the company is making that work, he said.

There was some palpable excitement in the room; Linux and free software in space is something that resonated with many attendees. The SGL project is in the early stages and will need contributions, both of time and money, to further its goals. After achieving world domination, Linux seems poised to continue its expansion: to low-earth orbit, the moon, planets, asteroids—and beyond. Can the 8th dimension be all that far behind?

[I would like to thank the Linux Foundation, LWN's travel sponsor, for supporting my trip to Amsterdam for the Embedded Linux Conference Europe.]

Index entries for this article
ConferenceEmbedded Linux Conference Europe/2025


to post comments

Is there nothing better than Yocto?

Posted Sep 9, 2025 15:09 UTC (Tue) by Arrange1030 (guest, #178702) [Link] (5 responses)

Are there any recent projects that are in the same niche as Yocto?

Is there nothing better than Yocto?

Posted Sep 9, 2025 16:27 UTC (Tue) by tbird20d (subscriber, #1901) [Link]

Buildroot has been used for a lot of Linux-based space missions. When I talked to people doing Linux-based cubesats at the SmallSat conference a few years ago, many of them had not heard of Yocto. A lot of projects get their kernel and distro from a satellite bus supplier (which usually includes the flight computer), and don't build the kernel themselves. In my experience, fiddling with details of the OS is a low priority task, relative to the custom development that is done for whatever payload the mission is carrying.

Is there nothing better than Yocto?

Posted Sep 9, 2025 22:41 UTC (Tue) by proski (subscriber, #104) [Link] (2 responses)

NixOS is somewhat in the same niche. It's harder to learn (it involved learning a special purpose functional language), but it's very rewarding. Reproducing builds are very valuable. Even more so in the environment where radiation can cause bit flips.

Is there nothing better than Yocto?

Posted Sep 10, 2025 0:34 UTC (Wed) by Arrange1030 (guest, #178702) [Link]

I'm already using Nix, and a minimal system config weighs in at almost 4GB. I guess I can try not-os next.

Is there nothing better than Yocto?

Posted Sep 12, 2025 22:52 UTC (Fri) by intgr (subscriber, #39733) [Link]

> Reproducing builds are very valuable. Even more so in the environment where radiation can cause bit flips.

Surely at this point we're talking about systems that will be built on Earth and merely *deployed* to space -- there's no radiation in the build environment.

Reproducible builds are great when delivering packages to distrusting downstream users. It wouldn't hurt but it matters less if the same organization is responsible for both build infra and deployment.

Is there nothing better than Yocto?

Posted Sep 16, 2025 15:08 UTC (Tue) by sam.thursfield (subscriber, #94496) [Link]

BuildStream is an attempt to design a build tool that is more robust than BitBake. And Freedesktop SDK works as a corresponding "reference distribution." At this stage, BuildStream is being used in production in some places, but has only a small community and very minimal investment. You'll find it interesting as a way to explore software integration with a different set of core concepts to BitBake.


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds