The Space Reviewin association with SpaceNews

One approach to smallsat standardization is to develop modular spacecraft, mixing and matching components as needed, like the SCOUT spacecraft program under development by AeroAstro. (credit: AeroAstro)

Smallsats and standardization

You’re reading this today thanks in large part to standards. From TCP/IP and Ethernet to Unicode and HTML, standards—de facto and de jure—make it possible to take millions of computers, network them together, and exchange information with a minimum of difficulty. They’re not something the average person thinks much about, but they are essential to the development and growth of any industry, including satellite manufacturing.

The issue of standards is something the growing community of small satellite, or smallsat, developers is now taking on. With a few exceptions, most smallsat projects have been one-off efforts, which fit their largely experimental or educational roles. Now, though, the increasing capabilities of smallsats have attracted the attention of others, particularly in the US military, who see operational roles for smallsats as part of a new “responsive space” paradigm. In those cases, it makes sense to develop some degree of standardization, taking advantage of economies of scale and related benefits. However, what smallsats components or architectures should be standardized, and how, remains a major topic of debate.

The meaning of standards

The issue of smallsat standards was the theme of last month’s 19th Annual AIAA/Utah State University Conference on Small Satellites in Logan, Utah. The conference brought together hundreds of smallsat developers around the world, who spent much of the four days debating the relevance of standards to their various efforts and how standards could—or could not—further their work.

The first question, of course, is what people mean by smallsat standards. Given the wide range of organizations that build smallsats, and the diversity of missions, it makes little sense to develop a single standard design to be used on all missions. However, at the subsystem and interface level, there are a number of standardization efforts, or at least proposals, being considered.

Some are proposing ways to make modular smallsats: plugging together various independent components together to create a complete smallsat, in perhaps no more than a few days’ work.

At the lowest levels, this means developing standards for mundane yet critical items like communications formats and interfaces. In some cases this can be done by simply adopting, with little or no modification, existing formats and standards used in computers and consumer electronics. For example, there is growing use of Internet Protocol (IP) as a means of communicating with smallsats, such as with CHIPSat, a small astronomy satellite built by SpaceDev for the University of California Berkeley under a NASA contract. The ubiquity of IP, noted Jeff Janicik of smallsat technology company Innoflight, makes it possible to use commercial off-the-shelf (COTS) hardware and treat the spacecraft as simply a node on a network.

Similarly, smallsat developers are looking at ways to adapt a commonplace computer interface, USB, for use on spacecraft. The SPA-U format (SPA stands for “Space Plug-and-play Avionics”) uses the USB standard for transferring data and command and data handing, but with a custom 9-pin connector rather than the typical USB connectors found in consumer devices. Similar efforts are underway using Ethernet and SpaceWire, an existing high-speed system designed for spacecraft. The goal of the effort, as the acronym suggests, is to make it possible to plug in spacecraft components and allow them to communicate with one another without the need for custom interfaces or formats.

Other efforts, though, are more ambitious. Rather than simply focusing on communications formats and interfaces, some are proposing ways to make modular smallsats: plugging together various independent components together to create a complete smallsat, in perhaps no more than a few days’ work. In such an approach, as described by Quinn Young of Utah State’s Space Dynamics Laboratory, there would be a “one-to-one relationship” between each spacecraft function and the corresponding component. This would make it possible to reduce costs over the long term by manufacturing individual modules in bulk, and also make it easy to replace modules to incorporate new technology or other innovations.

That’s the approach being taken by one company, AeroAstro, and its SMARTBus system. SMARTBus is designed to be a modular spacecraft architecture where individual subsystems, from power to communications to attitude control, are placed in separate modules. Spacecraft designers could then mix-and-match, choosing the components they need for a specific mission, then integrating the modules using a plug-and-play system. AeroAstro is developing the SMARTBus architecture for two smallsat missions for DARPA and the Air Force Research Laboratory (AFRL).

Benefits and drawbacks

Smallsat developers see many potential advantages of adopting standards. With standardized components, or at least standardized ways of connecting components, developers believe that they can build spacecraft more quickly and less expensively than possible today. Standards, they argue, can also reduce the risk associated with building something the first time, and can make it easier to insert new technology. Defined, published standards can also permit more competition, driving down costs.

For standardization to succeed, the components need to be used multiple times to offset the up-front costs of developing the component, while at the same time advances in technology threaten to render the component obsolete.

Modularity in particular also offers developers a capability not available today: to build a complete spacecraft from components in a matter or days, a feature that is of interest to the US military as it develops its responsive space architectures. One project by the Naval Research Laboratory (NRL) and the Applied Physics Laboratory (APL) of Johns Hopkins University seeks to develop a standardized bus for responsive space applications. The goal, said Andy Lewin of APL, is to be able to build a bus in advance, store it, and then integrate it with a payload and launch when needed. Separately, James Lyke of AFRL offered the notion of what he calls “DellSat”: the ability to build a complete spacecraft from components in six days or less, in much the same way that Dell manufactures customized PCs on a “just-in-time” basis.

However, standards and modularity have their drawbacks, which stem primarily from not optimizing spacecraft and components for individual missions. Standardized, modular spacecraft, several speakers noted, would be larger and more massive, since there would not be the opportunity to more tightly integrate components. They may also end up being more capable than needed to perform a specific mission, and thus could end up being more expensive than a spacecraft optimized for that mission. Victor Matricardi of the Aerospace Corporation pointed out that for standardization to succeed, the components need to be used multiple times to offset the up-front costs of developing the component, while at the same time advances in technology threaten to render the component obsolete. While the PC industry has to grapple with the same problem, it also produces orders of magnitude more components: what works for PCs may not work for spacecraft.

The dangers of premature standards

Another problem with standardization is figuring out how they will be used in the future. Changes in technology, changes in other spacecraft subsystems, and changes in smallsat uses all pose challenges to developers. “It’s difficult to design good interfaces,” said Matricardi. “What will be needed in the future?”

“Create standards as you would create products,” Caldwell said. “Let natural selection decide what works and what doesn’t.”

Some in the smallsat field used the conference to sound the alarm against adopting standards too soon. Doug Caldwell of Ecliptic Enterprises Corporation warned against the “revolutionary approach” to standards development, where a group defines an unmet need and proposes a solution: “You get design by committee, and that doesn’t work very well.” As an example, he pointed to a standard for computer bus architectures on spacecraft called Futurebus+, or Profile S. The standard, adopted by the IEEE in 1997, seemed to offer everything a spacecraft designer would want, from 256-bit support to redundancy. Yet, the standard was withdrawn in 2003 as spacecraft developers instead adapted what was already available for their needs.

That evolutionary approach, Caldwell said, is a much better way to develop standards. “Create standards as you would create products,” he said. “Let natural selection decide what works and what doesn’t.”

That concern isn’t lost on those working on standardization efforts. “We can make sure it doesn’t get adopted if we don’t do our job well,” said APL’s Lewin.

No longer toys

Those at the conference seemed cautiously optimistic that some form of standardization would be beneficial to smallsat developers in the long run. Despite concerns about the lack of volume needed for standardized designs to succeed, some believed smallsats would benefit even at a low production rate. Stacy Garfield of Lockheed Martin argued that just one smallsat every year would be sufficient to reduce costs and take advantage of standards, while Lt. Colonel Daniel Griffith, director of the Space Test Program of the Air Force’s Space and Missile Systems Center, said that “we can accomplish what we want with a few spacecraft.”

Regardless of the outcome of the standardization debate, the fact that one is taking place is an acknowledgment that smallsats, once consigned to the periphery of space efforts, are now increasingly capable and increasingly important. “Smallsats always used to be treated as toys,” said Alok Das, chief scientist at the Space Vehicles Directorate of AFRL. “We are now trying to make smallsats capable while keeping costs low.”


ISPCS 2015