U.S. Air Force’s Plug-and-Play Satellites
Satellite design doesn’t have to be rocket science
Illustration: John MacNeill
When you buy a mouse for your computer, removing the packaging is probably the hardest part of integrating it into your home system. Once you plug in the USB cable, you click on the mouse, and it just works. For it to “just work,” of course, a great many things have to happen in the background: Via the USB cable, the mouse’s circuitry receives power, initializes, and is recognized by the computer as a valid device. Then the driver software takes over, identifying the device as a mouse and not, say, a printer or a keyboard. Finally, a rapid succession of electrical messages traverses the cable, and these messages are translated into commands that then move the cursor smoothly across your computer screen. The fact that you don’t need to know any of this to operate a mouse is by design: The mouse’s computer chips and embedded software conceal the device’s complexity.
This was not an isolated case—indeed, it’s universal. So eight years ago, a few of us at the Air Force Research Laboratory (AFRL) set out to find a better way. Along with a small cadre of researchers from industry, government, and academia, we have been studying the example of the personal computer and “plug-and-play” concepts from other industries in search of lessons we could apply to the task of building better spacecraft. Traditionally, satellite designers strive to increase raw performance or system capabilities by turning to faster processors or more sophisticated sensors. But we took a very different approach, concentrating instead on slashing the time it takes to go from inception to launch. Our goal was, well, lofty: to build a working satellite in just six days.
We not only succeeded in the lab, we also laid the groundwork for others. Our plug-and-play concept is now being incorporated into several satellite projects, including a tactical battlefield spacecraft being developed by Northrop Grumman Corp. for the U.S. military. The basic architecture is also a perfect fit for spacecraft that carry an eclectic mix of instruments, such as weather and environmental monitoring satellites, and those that have an inherently modular design, such as communications satellites. And although our initial efforts have been aimed mainly at small satellites (that is, those weighing less than 450 kilograms), the plug-and-play architecture should work just as well regardless of the system’s size.
Meanwhile, parallel trends in satellite design and in manufacturing should make the adoption of plug-and-play satellites more palatable to the otherwise quite conservative aerospace industry. These include the enormous popularity of the miniature satellites known as CubeSats. Legions of college students and other space enthusiasts have worked on these tiny orbiters, in the process seeding the notion that spacecraft design need not be a high-overhead endeavor. The other development is 3-D printing, which allows quick production of three-dimensional objects directly from digital designs; embraced by the DIY crowd, this kind of rapid, on‑demand manufacturing is also the perfect complement to plug-and-play satellite design.
For decades, aerospace engineers and program managers have grappled with the growing complexity and expense of the systems they send into orbit. But despite many efforts to streamline and standardize, the development process has become only more protracted and expensive. In the 1990s, NASA administrator Daniel S. Goldin used the phrase “faster, better, cheaper” to herald the agency’s series of Earth-observing satellites and interplanetary probes. By the end of the decade, though, a number of these stripped-down missions had failed to meet their original cost and schedule marks. In fact, three of the Mars missions launched under this banner—the Mars Observer, Mars Climate Orbiter, and Mars Polar Lander—failed altogether.
You might think that satellites are expensive because of their exotic components. Those aren’t cheap, of course, but the vast majority of the cost is actually associated with labor. Spacecraft developers compulsively check, cross-check, and cross-cross-check every detail. Some teams even include people responsible for tracking down the exact date and facility where each transistor, capacitor, and integrated circuit was made. A former NASA engineer once boasted to me that every transistor on one spacecraft he helped design was backed by a file drawer’s worth of documentation.
And there are a lot of components—in some satellites, the mission-critical computers are triplicated. In a process known as triple-modular redundancy, the three computers compare computations, and if one of them is at odds with the other two, the majority prevail. In some cases, the software for each computer is created by a different team, to reduce the chance that all three computers will fail at the same time while performing the same task.
A couple of other labor-intensive strategies also add to the cost. One is the use of legacy components. The thinking is that components that have been flown on existing spacecraft pose a lower risk. But reusing component designs from prior missions often requires significant reworking of hardware interfaces and flight software. It’s kind of like trying to construct a jigsaw puzzle from the pieces of old puzzles: To make the pieces fit, you have to fashion additional unique pieces to fill in the gaps and hold the whole thing together.
The planning process is also quite inefficient, laborwise. The typical spacecraft is designed and built as though there will be no significant changes, even though requirements inevitably evolve, especially in protracted developments. Imagine what your architecture bills would be like if you were building a house and every time you decided to change a major appliance or a piece of furniture, you had to redesign the entire building.
We have a better idea, which we call Monarch, for “modular open network architecture.” It harnesses the basic idea of plug-and-play systems, in which even complex systems can be formed quickly and reliably by arranging a number of existing building blocks. The architecture is open, not proprietary, and uses publicly available interfaces, akin to the USB and Ethernet standards found in computers.
USB and Ethernet allow you to build personal computers modularly and then combine them into networks. A computer’s components are basically black boxes: Usually you only need to know a component’s function—whether it’s a mouse, keyboard, Web camera, or whatever—and what connector it requires, but not how it’s internally constructed.
With Monarch, a spacecraft’s components can similarly be thought of as black boxes—only instead of mice or keyboards, they may be gyroscopes or scientific instruments. These components, all of which have standard connectors, can be easily combined to form a Monarch system. A bigger, more complex spacecraft would simply have more black boxes than a smaller, simpler one.
Monarch allows for just three classes of black boxes. There are endpoints, which are components that perform a function, such as thermometers, cameras, and radios; routers, which connect two or more components; and hosts, which are comparable to the central processing unit of a PC. The host runs a variety of open-source “apps” that let it control the components. These apps are more complicated than typical iPad or Android apps, but like them, each is a relatively small program that carries out a specific function. For example, a spacecraft guidance app enables the satellite to track its position and motion and uses control algorithms to make any necessary adjustments to the thrusters. Another app gathers telemetry, by which the satellite constantly monitors its health and status in a form suitable for downlinking to ground control. That’s basically all there is to Monarch: Components are combined to form a satellite system, and the system’s apps use those components to carry out the satellite’s mission.
When our group first came together in 2004, we devoted a number of months to carefully considering the best way to connect the Monarch components. When, say, a new communications device is added to the satellite, how would the host and router know what it is and what to do with it? Personal computers use software drivers to do this job; the driver acts as a sort of bridge between the operating system and the component. But we didn’t want to use drivers, which need to be updated every time a component changes. If you’ve ever had to track down a driver for your new printer only to discover that it doesn’t yet exist for the operating system you use, you know how annoying that can be. So instead we embedded a bit of code in each Monarch component that tells the host and router whether what’s just been connected is a high-frequency radio receiver, an antenna, or a gyroscope.
In rethinking our components, we channeled the American inventor Eli Whitney. By championing the concept of interchangeable parts in guns, Whitney revolutionized the firearms business. Of course, a modern satellite can have a far wider assortment of components than did the guns of Whitney’s day, but the general idea still holds: When the parts are standardized and share a common interface, they can be quickly assembled; any defective or outdated part can be easily removed and replaced without having to start from scratch. And the labor required—and therefore the overall cost—is kept low.
After laying the basic groundwork for the Monarch architecture, the next step was obvious: to see if we could use it to do what we’d set out to do—that is, design and build an actual, working satellite in six days. We created a test bed within the space electronics branch of the AFRL, located at Kirtland Air Force Base in Albuquerque. Here we cobbled together an inventory of “plug-and-play” components from spare parts left over from old space missions. The assortment included reaction wheels, used to rotate the spacecraft; torque rods, used to stabilize the spacecraft; and sun sensors, which measure the spacecraft’s orientation toward the sun. We reworked these hand-me-downs by adding circuitry to them to match our Monarch connectors and programmed the interfaces to communicate using the Monarch protocols. We also fashioned standard walls for our six-day spacecraft: hinged panels that look like pegboards (with rows and columns of holes every 5 centimeters) and into which up to eight components can be quickly and easily connected and networked. The final satellite would consist of six of those panels, studded with two or three dozen components.
Our inaugural system was called the Plug-and-Play Satellite-1, or PnPSat-1. During a series of exercises, we quickly put together a variety of plans representing prospective satellite designs; these were based loosely on the architectures of existing traditional satellites, such as TacSat-2, a small imaging satellite developed by AFRL and launched in 2006. A typical PnPSat session would start with a mock design activity, using a fairly crude approximation of the design tools that a future plug-and-play spacecraft team would presumably have at its disposal. From this design activity would emerge the satellite’s flight software and bill of materials—that is, the list of Monarch components needed. We would also come up with a set of instructions, such as the sequence in which to connect components to panels and panels to each other.
After we hammered out the design, we had to actually assemble the bird. Our team functioned kind of like a NASCAR pit crew, with the carefully scripted instructions guiding our moves. In our initial trials, we mainly used mock-ups of the various components, and the assembly took around 4 hours. Eventually, though, we were working with actual hardware aimed at a flight-capable orbiter, and we got the assembly time down to just over an hour. The sessions were exhausting, but we knew the clock was ticking, and that made the work exciting and a lot of fun.
Our PnPSat-1 was built to demonstrate plug-and-play principles, including whether or not they result in a space-worthy craft. To that end, the satellite was scheduled for launch in August 2008, but it got bumped from the roster several months before liftoff—maybe not such a bad outcome, considering that the SpaceX Falcon 1 rocket it would have ridden on failed just after launch.
Monarch is now being used in the design and construction of several satellites. The 400-kg tactical battlefield spacecraft being developed by Northrop Grumman is called the Modular Space Vehicle (MSV). It will have a variety of swappable radio and electro-optical payloads, including communications modules and tactical intelligence, surveillance, and reconnaissance units. The 24-month effort to develop, build, and test the MSV should yield a launch-ready vehicle by the end of 2013. If it proves successful, the plan is to turn over future manufacture of the MSV to a satellite “factory,” called the Rapid Response Space Works, in Albuquerque. One day, the plan goes, a battlefield commander will be able to order up a dedicated spacecraft, and the factory will have it ready in a matter of months or even weeks, rather than years.
Our biggest accomplishment may have been roiling the satellite design community. Some of our colleagues have been excited by what we’ve done, while others have questioned its significance and indeed the whole notion that you can design an entire satellite around a plug-and-play architecture. Clearly, we’ve touched a nerve, and that’s good, because it’s helping raise fundamental questions about how spacecraft should be built. It’s bolstering the efforts of our group and of other spacecraft designers striving to make greater use of standardization to reduce the costs of satellites and space launches.
One of those workers is Bob Twiggs, a former Stanford professor who’s now at Morehead State University, in Kentucky. Years ago, to teach students about satellites, Twiggs came up with the idea of CubeSats. These diminutive spacecraft have since become a viral phenomenon, with hundreds of groups worldwide (including high schools and Kickstarter-funded teams) building them.
The typical CubeSat is a simple 10-cm-per-side cube weighing no more than 1.33 kg and yet containing all the essential elements of an autonomous satellite, including power, communications, and a useful payload. For those not content with just one cube, double- and triple-high CubeSats are available. You can go the other way as well: Twiggs’s latest project, the PocketQub, breaks up a single CubeSat into eight bite-size chunks.
One of the main reasons for the growing popularity of the CubeSat is the dispenser that carries the tiny spacecraft into orbit and spits it out into space. Officially known as a Poly-Picosatellite Orbital Dispenser—but more commonly referred to by its acronym P-POD (pronounced “peapod,” of course)—it looks like a surplus munitions container. Developed by Jordi Puig-Suari at California Polytechnic State University, the P-POD can house up to three CubeSats, and the ruggedized container can be readily added to practically any launch vehicle, taking advantage of the fact that most rockets have unused carrying capacity. To date, at least 40 CubeSats have been successfully launched, with another hundred or so planned in the next five years. The CubeSats now in orbit are accomplishing such tasks as studying radio-wave propagation through the ionosphere and measuring cosmic-radiation flux at low earth orbit.
The CubeSat and Monarch concepts share the common vision of a simplified, standardized architecture that allows spacecraft to be designed quickly and at low cost. But most CubeSats are not plug-and-play, so they are subject to scaled-down versions of the same problems that afflict big satellites, such as the need to integrate customized components that lack a standard interface. With CubeSats, these problems are mitigated by the satellites’ simplicity and the fact that they’re typically built by small, tight-knit teams. There’s no reason, though, that a Monarch approach can’t be applied to CubeSats, and in fact our group has created several dozen briefcase-size plug-and-play versions of CubeSats, which we use for training purposes. We can pull apart the pieces and switch them out in minutes. Just as Eli Whitney wowed members of the U.S. Congress by quickly disassembling several rifles and then reassembling them from the pile of parts, our demonstrations typically leave observers amazed.
Three-dimensional printing has great potential for both Monarch and for CubeSats. This rapid manufacturing method, being developed largely outside the aerospace industry, allows essentially any shape to be produced quickly out of a variety of materials, including plastics, metals, ceramics, cement, even sugar. A group of academics and enthusiasts led by Gil Moore, a retired U.S. Air Force Academy professor, is now working on two 3-D-printed CubeSats. For the first, called Rampart, they’re printing the satellite’s primary structures, deployable solar cell arrays, and even a propulsion tank directly from computer-aided-design drawings. The material they’re using is Windform XT, a nylon with carbon microfibers, which is very strong and doesn’t emit much gas—both desirable qualities for space applications. The group’s other CubeSat, called PrintSat, was created mainly to measure Windform XT’s performance in space and has already been selected by NASA for launch as early as next year.
Of course, many satellite parts, such as motors and complex microcircuits, can’t be produced using current 3-D printers. Most can print in only one material, and building something complicated like a satellite or a smartphone requires hundreds of materials. Within about five years, though, that may be possible. We’re now collaborating with researchers at the W.M. Keck Center for 3D Innovation at the University of Texas at El Paso, which has amassed one of the world’s most impressive armadas of 3-D printing equipment. Some of the center’s most interesting efforts involve printing in mixed materials, to construct things like electronic blocks. By printing the dielectrics and conductors and then using pick-and-place machinery to position the tiny electronic components, it should be possible to form customized electronic assemblies on demand.
A company in Orlando, Fla., called nScrypt is pushing that concept even further. Its engineers believe that in five years or so they will have built a single machine capable of printing and assembling an entire smartphone, including the electronics, the wireless components, and the display. Once that happens, we will be very close indeed to being able to quickly and conveniently print all the components for an entire Monarch spacecraft.
So can Monarch, CubeSats, and 3-D printing usher in a new era of satellite design, one that slashes the billion-dollar costs and colossal inefficiencies that plague today’s projects? Disruptive concepts are always a tough sell, particularly in the aerospace community, where technology adoption strategies are described with phrases like “crawl, walk, run.” But the business-as-usual alternative—big spacecraft that vastly exceed their budgets and take years to build—is unsustainable. If there’s a way to build well-engineered, capable spacecraft at a fraction of the cost and time, we need to give it a try. We have nothing to lose—and billions of dollars to save.
This article originally appeared in print as "Plug-and-Play Satellites."
About the Author
James C. Lyke, a senior member of the IEEE, is technical advisor to the U.S. Air Force Research Laboratory’s Space Electronics Branch, in New Mexico, where he and his group have been developing modular satellites that are less expensive and quicker to build than traditional orbiters. “Coming up with the satellite architecture was pretty hard,” he says. “But convincing a risk-averse aerospace industry to even consider our approach has been even harder.”