Aerospace and Electronic Systems Magazine October 2017 - 11

Leppinen
Linux has many useful general-purpose facilities available,
such as file systems, data bus interfaces, process scheduling, and
interprocess communication. The POSIX abstractions have existed
for decades, and most POSIX compatible software can be made to
run on the embedded Linux system. Generic spacecraft software
modules-handling, for example, attitude control-targeting Linux
could be written and distributed commercially or noncommercially
across projects. As mentioned, SpaceX has reused the same software in their launch vehicle and orbital spacecraft. Linux could
thus make it easier to produce hardware-independent satellite software systems.
Shell scripting in Linux can substitute on-board control procedures that are traditionally used to automate spacecraft operations
[1]. This approach was used for example in TacSat-1 [9].

DRAWBACKS AND MITIGATING THEM
Choosing Linux limits the choice of hardware; the processor must
have a memory management unit, and 8-bit and 16-bit processors
are mostly ruled out. The exception is μClinux, which can run on
16-bit processors without memory management units [6]. However, this is becoming a nonissue: for example, many mobile phones
use 32-bit and 64-bit processors with very low power consumption. Low-power 32-bit processors can be used in place of 8-bit
and 16-bit ones.
Birrane, et al. [5] noted problems in the package dependencies
of many Linux programs they wanted to port to their systems. The
programs were dependent on underlying packages, which contained
much more features and code than what the actually needed program
would use, thus leading to code bloat. When using nontailored Linux
distributions, much of the available software might be unused in the
actual application. If this extra software is flown, it either must be
verified and validated along with the actually used software, or it
must be verified that the extra software is never used during flight.
While possibly time consuming, it is possible to remove the additional quality assurance burden by tailoring the custom distribution
to completely remove any unused extra software [6]. As processing
hardware increases in capability, the performance cost of using a
general-purpose OS may become nearly negligible. The existence
of "extra" software is not a performance problem if the system has
enough spare memory and processing capability; it may be less expensive to pick more capable hardware than to carefully hand-tailor
the distributions. On the other hand, it is also possible to customize
Linux to run on very little resources [9].
A major drawback is that Linux has not been designed to be
an RTOS. However, additions exist to make Linux more real-time
friendly. In some cases, the number of hard real-time constraints
can be reduced with design changes; and for those hard real-time
constraints that remain, one option is to use a dedicated controller
to handle them, or to use some real-time Linux variant. To handle the hard real-time problem, projects such as RTLinux, RTAI,
xLuna, and μITRON have used a similar architectural solution of
using a separate microkernel below the Linux partition, which runs
Linux as the idle task of the microkernel, thus Linux is executing
when no other higher priority tasks (presumably with hard realtime constraints) are blocking it [7].
OCTOBER 2017

Craveiro, et al. [7] and Rufino, et al. [32] describe the AIR
project, which has studied ARINC 653 standard compatible
methods of using Linux kernel in safety-critical hard real-time
systems. Their method is based on time-space partitioning. A
simplified version of the AIR architecture is shown in Figure 7.
In this scenario, a microkernel running on the on-board computer
executes partitions sequentially, and each partition contains its
own data and executable code. One partition may then contain
Linux kernel, while other partitions run ordinary RTOS kernels.
The scheduling of partitions is strictly deterministic: each partition is cyclically allocated a fixed time slice. This determinism
allows the development of hard real-time systems, while benefiting from the availability of Linux: Craveiro, et al. especially
note that this allows using much of the software developed for
Linux without tediously porting it to an RTOS, and additionally
the scripting capability of Linux is made available, without specifically porting an interpreter. However, it must be made certain
that the use of Linux does not affect the consistency and safety
of the time-space partitioning. The authors also note that the AIR
architecture ensures a fixed amount of processing time for the
Linux partition and real-time partitions during each cycle, while
earlier implementations that run Linux as the idle task may block
Linux applications indefinitely if the higher priority tasks are under heavy load [7].

DISCUSSION
While early use of Linux in space was experimental, SpaceX and
Planet have already successfully used it in commercial missions.
They are possibly the most influential space industry entities to
have declared using Linux in their avionics. Their success will
likely influence the rate of Linux adoption elsewhere in the indus-

Figure 7.

Linux kernel and time-space partitioning. Adapted from [7].

IEEE A&E SYSTEMS MAGAZINE

Table of Contents for the Digital Edition of Aerospace and Electronic Systems Magazine October 2017