Today it is possible, with a little bit of planning and some careful preparation, to send your computer architecture research into space.

We are in the early days of a new space race that is making it possible to launch things to space more easily, more cheaply, and more flexibly than in even the recent past.  Computer architecture and systems research is essential to the success of this new space race.  This blog post is about how to put results from systems/architecture conferences, like ASPLOS, to work for space systems.

What’s up with space right now?

The cadence of rocket launches is increasing as a new industry of private space launches flourishes.  The size, shape, cost, and capability of things launched into space are changing.  The changes are significant and are going to enable more participation in the design, deployment, and use of space systems by people not in the space industry, per se.

To understand how things are changing, it is useful to understand how things were for a long time.  Even recently, a satellite was the size of a city bus, was designed for a cost of hundreds of millions of dollars, was to be launched and used for a single purpose, and was manually controlled from the ground by a human operator (e.g., https://landsat.gsfc.nasa.gov/satellites/landsat-9/). The satellite would be built primarily to collect data using a sensor. Once the data are all collected, the satellite beams them down to Earth at a few megabits per second for processing.   It’s a very cool end-to-end system: we can see the Earth from above using a space camera and use the data to respond to disasters, find missing ships at sea, optimize cities, fight forest fires (and lots of other neat applications).  Unfortunately, all that works only if that satellite happens to be looking at the right place at the right time, and only if the satellite’s operator is clued-in about what they’re looking for enough to instruct the satellite to capture the valuable data.  One important consequence of this operating model is that each different application needs its own satellite, ground equipment (with caveats), and operator, so that each satellite knows which signals to sense at each moment.

That’s how space was, but satellites are very different now than they were then.  Today, satellites can be a lot smaller.  CubeSats come in stack-ups of a “unit” size, which is a 10x10x10cm box full of whatever you want; a “3U” is 30x10x10cm.  PocketQube satellites are 5x5x5cm — 1/8th the size of a CubeSat, and stack similarly; a “3p” is 15x5x5cm.  ChipSats take the concept of a small satellite to the extreme, for instance, a 2x2cm planar device.

There are lots of advantages to going small in the world of satellites.  Each satellite is much cheaper to build and launch.  Build costs include mechanical design and bigger things are trickier to make.  Commercial launch costs scale up quickly with mass and volume, and smaller devices cost less money to put on a rocket and launch.  With all of these new form factors and the now-more-pervasive availability of commercial launch services, it is possible to conceive of, design, build, and launch a 1U CubeSat or 3p PocketQube for around the price of an economy car; cost per ChipSat can be tens of dollars to design and hundreds to launch, depending on the launch format.

Another major dimension of space systems design that is changing with these new form factors is the degree to which each satellite is designed for extreme reliability.  If your satellite costs nearly a billion dollars to build and launch it had better work.  If your satellite costs five grand, then it starts to make sense to launch 10 and hope for the best.  Cheap nanosatellites allow designers to embrace quantity over quality, and leverage low-cost, widely available COTS components for many subsystems that, in monolithic satellites, would be spectacular feats of engineering with exorbitant cost.  For instance, instead of using a bespoke, radiation-hardened PowerPC RAD750 CPU that runs at 400MHz and has a “space industry price tag”, a nanosatellite can use a cheap microcontroller and other readily available hardware.

Of course there are challenges posed by simplification and shrinking of space systems.  One of the most interesting ones is the energy supply.  Satellites get energy through solar panels and store the energy in batteries (although in my lab, we are working to change this trend with batteryless satellite bus designs).  The smaller a satellite is, the smaller its solar panels are, and the less power the satellite can extract from its environment.  Deployable solar arrays can collect more power, but are undesirable because of their mechanical complexity.  Aside from energy, a satellite built around COTS components is susceptible to radiation-induced faults; here, small, cheap satellites rely on reliability through satellite-level redundancy and on already-mature “terrestrial” fault tolerance techniques.

Space Systems Make it to ASPLOS

At this point, you might rightly be wondering why you’re reading about tiny space systems on the SIGARCH blog.   The reason is that nanosatellite systems are highly-constrained edge sensing and computing systems.  Making space systems better requires answering many research questions of interest to the architecture community.  At CMU, Ph.D. student Brad Denby and I wrote a paper that we published in ASPLOS 2020 that makes clear why small satellites are a great example of constrained edge computer system design.  In our paper, we describe “Orbital Edge Computing”, which entails adding sophisticated and capable computer hardware to satellites to process sensed data locally, instead of sending any data to Earth.  The advantage to this model is that the satellite (mostly) avoids relying on communication links back to Earth.  Communication is a particularly painful bottleneck in space systems because it depends on the availability of ground stations to receive data.  Ground stations are geographically sparse, and offer only brief, low-bandwidth communication opportunities.

Orbital edge computing, on the other hand, uses on-board processing to find the interesting data, and sends down those interesting data only.  Orbital edge computing makes much better use of the fleeting communication channel by (ideally) not using it at all.  Of course, the basic edge-computing observation is not ours, and is not specific to satellites.  The same principle enables drones, sensors, mobile robots, and lots of other tiny devices to optimize their use of ultra-limited communication channels through local computing.

Space systems have several unique traits that influence the model and system design for edge computing.  The first thing is that space systems operate on pretty big data sets: 4K visual and hyperspectral imaging data collected continuously along the entire ground-track of the satellite. A satellite orbiting at 450km sees a new frame every 1.7s, and this interval effectively establishes a deadline for frame processing, which is a difficult computer systems design challenge.  Second, in tension with the data size, satellite systems are highly energy-constrained, with the need to collect all of the energy that they use to compute.  Solar panels on a 3U cubesat might collect 5-7W of power in favorable conditions.  If the system is locally rotating (which it might be right after being deployed), that power level may drop significantly.  Processing high-rate, 8K frames of hyperspectral data on a constrained power budget is a difficult computer systems design challenge.  Third, a satellite system has highly regular physical dynamics, by virtue of the simplicity of orbital mechanics. These regular dynamics affect energy supply, sensor data availability, and directly determine how a system and architecture schedules computing and actuation in a satellite.  Our orbital edge computing work argues for incorporating GNSS global positioning, and an on-board computational simulation model of orbital mechanics, energy, and computing, to give a satellite geospatial awareness.  Supporting such a model efficiently and at the right level of abstraction is a difficult computer systems design challenge.  Incorporating data size and rate, energy constraints, and orbital mechanics into a comprehensive scheduling system is a very difficult computer systems research challenge.    We are still working to solve the computer systems design challenges related to orbital edge computing.  The problem space is broad and exciting and I am hopeful that we will see more work addressing this problem at computer architecture and systems conferences..

As long as I have you reading about space systems, here are several open problems in the domain that I think are very interesting for computer systems researchers.

• Creating or adapting machine learning models that are sufficiently accurate for visual inference tasks and that also operate on a fixed energy budget, with the ability to adapt to changing energy, communication, and application timing constraints.
• Managing what we refer to as “computational nanosatellite pipelines”, or collections of nanosatellites that work together to sense data and run distributed computation on those data.
• Designing hardware, system software, and applications for highly energy constrained, highly resource constrained, multi-tenant satellite systems with sufficient performance to meet space system application demands.
• Rationing energy to meet the needs of control and actuation, despite high energy costs for actuation operations (such as pointing and station-keeping), while at the same time responding to increasing uncertainty in the control loop, stemming from integrating ML results into control computations.
• Distributing and federating the responsibility of learning machine learning models online across a constellation of satellites.  A constellation may need to maintain geospatially localized models and satellites may need to work together to learn a single model with sufficient accuracy to meet application demands; coordinating sensing, data movement, training, and coordination is a prerequisite to this goal.
• Quantifying and developing low-overhead hardware and software techniques to mitigate  faults and data errors in memory and processing components stemming from the high radiation environment in Earth’s orbit.

Is space systems research computer systems research?

Space-based sensor systems in nanosatellites are an emerging, highly constrained edge computing domain that presents a long list of interesting research problems for computer systems researchers.  This domain is in need of close cooperation and collaboration between space systems researchers and computer systems researchers.

Space systems engineers bring knowledge of the domain that amplifies the efforts of computer systems researchers: What orbital deployment parameters are realistic?  What are the physical constraints imposed on components in a satellite? What applications matter and to whom?   What costs and risks are acceptable, given the cadence and complexity of each launch?

Computer systems engineers bring edge computing and hardware/software optimization expertise that brings to bear the value of emerging small satellite platforms: What computing, communicating, and sensing can we do on a satellite’s power & energy budget? How does a high level application spec map onto a satellite constellation efficiently? What hardware is optimal given some assignment of priority to cost, mass, volume, thermal characteristics, energy consumption, and performance?

Working together to exchange answers to these basic questions, computer systems researchers can increase the impact and rate of progress for space systems researchers and space systems researchers can provide a new application domain full of interesting research challenges.  Working with an amazing collaborative group of students and faculty and CMU, we are beginning to build this bridge, culminating most recently with the Tartan-Artibeus-1 computational nanosatellite built in our lab being launched to orbit earlier this year aboard SpaceX Transporter-3.

If you are a computer systems researcher, now is a great time to get into the new space race!

Space-X Transporter-3 Rocket which shuttled a payload of nanosatellites to orbit in January 2022. Image Credit: SpaceX

About the Author: Brandon Lucia is a Professor in the Electrical and Computer Engineering Department at Carnegie Mellon University.  His lab does research on programming languages, software systems, and computer architecture, focusing especially on intermittent and physically constrained computing, with applications to energy-harvesting systems on Earth and in space.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.