Introducing Space Grade Linux
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.
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.
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 [Ramón Roche]](https://static.lwn.net/images/2025/elce-roche-sm.png)
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 | |
---|---|
Conference | Embedded Linux Conference Europe/2025 |
Posted Sep 9, 2025 15:09 UTC (Tue)
by Arrange1030 (guest, #178702)
[Link] (5 responses)
Posted Sep 9, 2025 16:27 UTC (Tue)
by tbird20d (subscriber, #1901)
[Link]
Posted Sep 9, 2025 22:41 UTC (Tue)
by proski (subscriber, #104)
[Link] (2 responses)
Posted Sep 10, 2025 0:34 UTC (Wed)
by Arrange1030 (guest, #178702)
[Link]
Posted Sep 12, 2025 22:52 UTC (Fri)
by intgr (subscriber, #39733)
[Link]
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.
Posted Sep 16, 2025 15:08 UTC (Tue)
by sam.thursfield (subscriber, #94496)
[Link]
Is there nothing better than Yocto?
Is there nothing better than Yocto?
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?
Is there nothing better than Yocto?
Is there nothing better than Yocto?
Is there nothing better than Yocto?