Linux on a Small Satellite

The first step in designing the software architecture was to examine what tools already were available to the developers—in this case, parts of the Linux distribution and other GNU and open-source utilities with well-defined pedigrees that provided needed capabilities. Time and time again, as we were developing the payload control software, we were amazed at the flexibility and amazing number of options that various commands provide.

One example is the GNU compression utility gzip. During a ground contact event, the payload streams data in real time through a series of software pipes. It originates in a file located on the Flash filesystem and then makes its way through various utilities, including a compression stage, and into the satellite bus. We found that it was necessary to tune gzip to select a compression ratio/performance curve that would ensure that the 1MB downlink was filled completely with data packets. gzip inserted into the downlink stream was a relatively late addition, and it allows us to make maximum use of the available downlink bandwidth. The design of command-line utilities using STDIN/STDOUT interfaces allows capabilities such as this to be integrated transparently into the data stream, within the performance capability of our computer system.

Choosing a scripting language is a difficult task—indeed, in the Open Source community, many competent options are available. Perl may have been a good choice, but we were not comfortable with the size of its installation and memory footprint. Python also would have been a great choice, but the development team did not have experience with it. The most powerful shell-scripting language appeared to be bash, although it also is the heaviest in terms of footprint. Our smallest embedded systems could not handle the entire footprint of bash, but the Busybox lightweight shell-scripting interpreter, ASH, proved almost as capable for the tasks that had to be monitored and controlled on those smaller targets.

Although space here does not allow for a complete architecture discussion of the payload control software design, at its core the software is a series of bash scripts designed to support various functions of the payload. The system is designed to take advantage of POSIX-style filesystem security. Upon boot, the first processes run as root as the system starts. As the payload control software begins to come on-line, it starts up as user BOOT. The system can stay in BOOT and provide a certain number of critical system capabilities, including providing binary telemetry streams, file transfers and direct commands. When a sensor mission is about to begin, the system moves to a state of TRANSITION, and all further data collections take place as the OPS user, who has a different set of permissions. At the conclusion of the data collection, OPS is commanded to shut down. Multiple redundant copies of the BOOT directories are designed into the system to provide backup capability in the case of filesystem corruption or other significant error.

bash scripts launch every payload control system function. They create complex filenames we use to keep track of configuration, date and time and other information. They un-gzip and untar commands and files that are uplinked to the satellite. Commands themselves also are bash scripts with simplified functionalities. They call other bash scripts to do the actual data collection or to set environment variables that change the behavior of other scripts.

# Start the data processing pipeline
# (with cpf ignoring SIGINT,SIGTERM)
   eval "cat $dig_data_stream | \
      tee $raw_file | \
      cpf -i -v$cpf_verbosity $cpfparams \
      > $output_file &"
   # Enable the dig channel
   set_hardware 'echo $dig_channel \
     channelEnable ena | mapper 2>&1'

This combination of the bash scripting language, GNU and open-source utilities and custom command-line applications is unique in satellite programs. For TacSat-1, most of the custom code involves the conversion of data from the TCP/IP world to proprietary OX.25 formats to handle sensor data.