Introduction: The Department of Defense (DOD) Office of Force Transformation (OFT) approached the Naval Research Laboratory with an opportunity to build and launch a microsatellite that would provide operationally responsive access to, and near-term tactical exploitation of space.1 A key challenge posed to the Laboratory by OFT was to build this operational capability in less than 1 year from the approval to proceed (ATP) to an on-orbit utility. One of the objectives of TacSat-1, as well as the broader initiative, is to make space assets and their capabilities available to operational users. Additionally, OFT intends for the TacSat-1 experiment to generate policies in which concepts and technology co-evolve, ultimately ensuring that space-based assets emerge as an organic part of the Joint Task Force. Bringing this first "tactical satellite" vision together required the development of new partnerships and methods, and the leveraging of existing hardware, software, and facilities. Copperfield-2, an existing sensor system developed for flight on the Global Hawk unmanned aerial vehicle (UAV), became the cornerstone of the TacSat-1 payload infrastructure.

Changing Paradigms: TacSat-1 sought to investigate flawed and limited interactions where failure is a significant data point. As a result, the initiative is exploring and taking advantage of emerging concepts that will broaden the technology base and provide incentives to a new space cadre, all of which seek to mitigate risk averse behavior. In order to execute the initiative successfully, risk was appropriately managed, commensurate with the level of cost and time associated with the development and testing process. "Traditional" satellite programs often manage risk with very stringent requirements for reliability, parts screening, and documentation, resulting in significant increases in cost and time and inflexibility in addressing today’s threats. TacSat-1 has intentionally taken many risks, both in its conceptual application and with its UAV components, all combined to produce high payoff. Commercial parts are being used throughout the spacecraft. Mechanical build processes are being changed and streamlined to meet a significantly truncated schedule. Payload software development is leveraging open-standard protocols and tools wherever possible in order to provide for the highest amount of re-use and adaptation. Finally, the bus infrastructure for TacSat-1 builds on Orbcomm hardware, taking advantage of a proven and paid-for space heritage.

Payload Adaptation and TACSAT-1 Implementation: The core payload component, Copperfield-2, provides two key functions for the satellite. First, it is itself a sensor system that receives signals of interest and provides for machine-to-machine collaboration between air and space assets for geo-location. Secondly, it serves as a general-purpose computer system and provides storage and data handling. A module designed specifically for TacSat, called the high-speed interface (HSI), provides conversion from the TCP/IP payload communication protocol, to the proprietary OX.25-based communications that the Orbcomm bus provides.

FIGURE 9
This three-dimensional CAD rendering shows the payload environmental enclosure, which enables convection-cooled components to operate in a space environment.

TCP/IP-based systems provide tremendous flexibility and standardized communications between various devices. The Copperfield-2 system sponsor is striving to provide TCP/IP-enabled payload elements that allow for the ultimate in flexibility — payloads and ground stations can be placed virtually anywhere routable via TCP/IP packets. Another OFT goal is to eventually provide an entirely TCP/IP-based satellite system so that classical integration challenges can be eliminated and so that speed of development and launch are not held hostage to newly created interfaces.

Copperfield-2 was designed from the ground up to provide a modular payload infrastructure that can be adapted to changing needs and requirements. This capability is used in the TacSat-1 program; the addition of support hardware for the visible camera, via the PCI bus allowed the "frame grabber" card to be used by the general-purpose processor, and the frame grabber card manufacturer’s driver to be used with minimal modifications. This capability reduced the development timeline significantly, and allowed insertion of a new camera and frame-grabber card well into the program.

While hardware allows the physical interconnection of payload components, the most "custom" part of the satellite development is putting together the payload control software. All of the Copperfield payload components with processors run on the Linux operating system. Much of the payload software was implemented through the use of BASH (Bourne again shell) scripts operating on the various processors. This allows the special binary "drivers" (either real operating system drivers or user-space programs), which provide control to the other payload elements, to be small command-line utilities that can be completely tested in their limited functionality.

By utilizing the BASH scripting language and leveraging GNU utilities that come with Linux software distributions, software components that have been well tested and had tremendous peer review are re-used and provide the core functionality. Custom software components that are required to interface with specific hardware or software can be of limited scope. Linux and the GNU utilities provide the glue logic that binds the payload together.

Summary: Few satellite programs have the latitude or the ability to take risks that the TacSat-1 initiative provides. In this context, the TacSat-1 program allows innovative leveraging of both government and commercial off-the-shelf hardware components, as well as novel approaches to creating payload software which provides for maximum flexibility and standards-based operation. The modular nature of the Copperfield-2 allowed rapid hardware integration, proving the concept of a modular payload that scales from UAV applications to a spacecraft application. In the same vein, the very simplistic UAV payload software requirements were significantly expanded for TacSat-1, extending the role of standards-based open-source software such that it provides a modular software infrastructure suitable for flexible command and control of the TacSat-1 payload and for uses other than space.

Acknowledgments: The author acknowledges the contributions to this effort by Stuart Nicholson, Eric Karlin, and Mike Steininger of SGSS, Inc.; Brian Micek of Titan Corp.; Chris Gembaroski, Don Kremer, and the Copperfield-2 team at Aeronix, Inc.; Jeff Angielski for the PTR Group; and the Copperfield-2 UAV payload sponsor, LCDR Michael Carlan, USN.

[Sponsored by OFT]