Notes from Small Satellite Conference 2017

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.


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.


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”.