This past weekend I had a chance to attend the Pre-Conference Workshop of the
2017 Small Satellites Conference in
Logan, UT. I had a few goals going in: learning about the software stacks used in
these satellites as well as their development processes, learning
about the systems architectures and hardware that is in use, and
meeting with my new friend Alex who
has a unique perspective as an industry insider that is interested
in and using Rust. It was a whirlwind of a trip with a with a ton to absorb
without much downtime.
What are SmallSats?
For those that aren’t familiar with the area: Small Satellites
(often called Cubesats, Microsats or Nanosats) come in a variety of sizes,
often some multiple of 10cm x 10cm x 10cm. 1U sats are a single cube,
2U and 3U are two or cubes in a row, and 6U and 8U sats are in a
2x3 and 2x4 configuration. They’ve been around for since the early 80s
but activity has really picked up in the last decade as it’s become
cheaper to develop and launch them.
In addition to the traditional national space agencies, it seems like
every major research university has one or more cubesat programs. There
is growing commercial interest, from Planet Labs,
which already has swarms of dozens of ~3U photo imaging satellites, to venture-funded
startups like analyticalspace that are
in the design phase, and to SpaceX, which is planning a ~4,000 satellite
constellation
to provide worldwide Internet access. There are also new launch
providers such as Rocket Lab which are
building rockets sized for delivering smaller payloads to orbit, and a whole
ecosystem of vendors targeting this market.
The presentations that I saw covered a pretty broad range of satellite missions.
I’ll break up them into a few groups:
Deep Space Probes
These are like traditional deep space probes from
national space agencies, but experimenting with the form factor and new technologies.
They are intended to do real science with a lower budget and many more opportunities.
There wasn’t a ton of detail in presentations about the hardware and software architecture
approach of these types of satellites, probably because they arenot all that different from traditional larger satellites. My impression
is that these missions are very much about minimizing risk because these are usually
one-off designs. Thus, these designs are using traditional space-qualified processors
such as LEON3 and
running existing flight control stacks such as Core Flight System
which is primarily written in C or others running on VxWorks.
Cost for development and flight computing hardware is high, but probably small in the overall
scheme of things. I’ve heard that a development LEON3 processor might go for ~$5K and
flight-rated processors might go for 5-10x that price.
Technology Development Satellites
These are satellites that are built in order
to evaluate and prove out new technologies such as new propulsion systems, communication
systems, or sensors. NASA has a concept called Technological Readiness Level
to indicate the maturity level of a particular technology; these satellites
are a good way to move systems from TRL 6 (fully functional prototype) to TRL 8 (tested
and flight qualified).
It seems that most of these satellites except for the ones specifically designed to test
out new computing architectures have relatively simple flight control systems. They
typically will have a relatively simple mission and limited lifetime, so there isn’t a
huge need for flexibility. My impression is that budgets are much tighter, so there’s more
of a willingness to use lower-end space-rated processors such as the ATmegaS128 or non-rad-hard processors
such as the AVR32
found in the NanoMind A3200
flight computer. I believe that many of these users have a relatively traditional high-reliability embedded development process, using C and some kind of RTOS.
I did see one very interesting presentation on a satellite designed to test out new
computing architectures - A Novel Small Satellite Processor Architecture. The presentation isn’t online
yet, but to summarize, the satellite had one primary commercial FPGA + MCU board, two
secondary commercial FPGA + MCU boards, and then ~4 Raspberry Pi Compute Module 3. No specifics on the software,
but since the main MCUs were Cortex-A9 class, I expect that they are running Linux.
Educational Satellites
These are satellites where the primary purpose is to
give students a chance to work on real projects that will go into space. Here, the process
is just as important as the final outcome, and there are typically even tighter
budget constraints.
From the hardware perspective and software perspective, there’s a real drive to
use platforms that students can get familiar with quickly and less need for long-term
operation, since in some cases these satellites may have an expected lifetime of
weeks or months. Much more talk of Raspberry PI and even Arduino.
Commercial
For the pre-conference workshop, there weren’t any presentations by
commercial smallsat developers, but they were definitely in the audience.
As far as I can tell, most (if not all) commercial smallsat operators are intending to
launch at least small constellations of satellites. They are probably more willing to use
non-space-rated processors, in large part because they may need a lot more
processing power than otherwise available. Also, development costs and timelines
become much more important because of the need to launch before potential competitors
while burning through cash, while losing individual satellites in a constellation is
far less catastrophic than losing a one-of-a-kind deep space mission.
At the same time, the software for these commercial operators will probably be the most
complex of all of these groups, and for now, they will not be able to reuse
software from previous missions as NASA can. So, improving software productivity
and reliability will be much more important for these operators.
What about Rust?
The level of awareness of Rust was pretty much zero, which was expected. The
existing community is very hardware-centric, and there’s definitely a culture
of minimizing risk by keeping software simple and minimizing new development.
There is also some unpleasant history with Ada, with the US Department of Defense trying to force its
use for a period of time. Definitely do not attempt to pitch Rust with “it’s like
Ada, but better!“.
At the same time, there is some awareness that the traditional methods of software
development using C aren’t necessarily going to scale well up to more complex
commercial systems. C++ is the default next step, but there is some concern about
how complicated that language can be.
It’s very early going for Rust in this industry, but here are some ways that it
can make progress over the next 5-10 years:
1 - Make sure that Rust has first-class support on the processors that will be going
into space, particularly university cubesats and commercial smallsats. This includes
LLVM support, library support, and tooling such as debuggers.
2 - Outreach at the university level outside of the traditional CS departments. Make
an effort to build interest in Aero / Astro departments, which may have a different
set of students. Developing a Rust-based flight control system might be a thesis
in itself.
3 - Make incremental inroads in ground support and eventually flying in non-critical
roles. Proving the viability of Rust in these environments will build confidence that
it will be better than C / C++ for critical systems.
4 - For commercial operators, pitch Rust as a better tool for building command
and control protocol handlers and related components. Nobody is going to hack a deep
space mission without first getting access to the NASA Deep Space Network first,
but every commercial operator is aware that getting attacked by hostile
state and non-state actors is a huge and business-ending possibility.
Conclusion
The SmallSat industry isn’t a huge one, but the areas that are growing the fastest
are also the areas that have the need and the potential to adopt Rust over
the next decade. With luck, we will see an appearance on a student’s presentation slide
sometime in the next decade, and the response to “have you heard of Rust?” will be
“yes, but we can’t tell you anything about it except that we’re using it for
something important”.