A Flexible Satellite Command and Control Framework

Thomas Sullivan, Donald Sather, and Ronald Nishinaga

A standard communications infrastructure and shared services allow for rapid receiving and publishing of mission information using common message and data standards, thus enabling situational awareness along with reduced operation and maintenance costs.

The Air Force Space and Missile Systems Center (SMC) Satellite Control and Network Systems Group has been exploring concepts for future satellite command and control implementations. The studies have examined how to apply advances in information technology to improve interoperability, responsiveness, and economy. From these studies, a vision has emerged for an extensible or "compatible" framework that is beginning to shape the future direction of satellite command and control procurement and concepts of operation within SMC.

A framework is the common hardware and software system architecture that an enterprise is built upon. A framework selectively constrains system design for specific missions, and can be created as a service-oriented architecture, netcentric, bus-based, object-oriented, or any combination of these or any other architecture. Here, mission-specific frameworks and enterprise command and control frameworks are grouped with various programs, common services, and common tools.

A framework can be defined as a common system (hardware and software) architecture that a given enterprise is built upon. It selectively constrains the design of the enterprise overall and the individual elements or missions within it. A framework can be created as a service-oriented, netcentric, bus-based, or object-oriented architecture, or any combination of these. One advantage of the framework approach for command and control is that it accommodates a flexible ground infrastructure to support rapid deployment of space assets for tactical space missions. Not surprisingly, the DOD Operationally Responsive Space (ORS) Office has been investigating how such an approach could be used to meet responsive space requirements.

The Aerospace Corporation's Ground Systems Laboratory in Chantilly, Virginia, has been working closely with SMC's Satellite Control and Network Systems Group and the ORS Office on these projects. Aerospace has concluded from initial studies that the concept of a compatible command and control framework is technically viable for Air Force satellite tracking, telemetry, and commanding operations.

History of Air Force Satellite Command and Control

The Air Force Satellite Control Network (AFSCN) is a network of ground remote tracking stations and control nodes that support the launch, command, and control of various national security space assets. The two operational control nodes, located at Schriever Air Force Base in Colorado Springs and Onizuka Air Force Station in Sunnyvale, California, provide the communication relays and resource management that enable the satellite operations centers to interact with remote tracking stations around the globe. The operational control nodes at Schriever and Onizuka started as dedicated ground systems for processing mission data and state-of-health data; they were based on IBM mainframe technologies developed in the 1970s. In the 1980s, AFSCN started using a common system architecture for satellite telemetry, tracking, and command. This architecture, originally known as the Data Systems Modernization, eventually became known as the Command and Control Segment. The Air Force achieved early successes with this architecture, which eventually spread to multiple satellite programs. However, each program still had to employ mission-unique functions on the common architecture, and these became difficult and expensive to maintain or upgrade as more advanced satellites came online.

A typical satellite operations information cycle. One portion of the information cycle for satellite operations includes the continuous stream of tracking data from daily satellite contacts that is needed by orbit management personnel to determine future satellite position information. In turn, this position information is used to determine AFSCN tracking station service opportunities in the future that mission planning personnel use to schedule satellite contacts that accomplish specific satellite mission and maintenance functions. The cycle repeats as each planned satellite contact is executed by satellite operators performing telemetry analysis and commanding functions that, in turn, generate new tracking information.

In the 1990s, the Air Force attempted to replace the Command and Control Segment with the Standardized Satellite Control System, but ended the effort because the business case did not support its development and its schedule became extended so that it could not support the needs of the individual programs. Instead, each individual satellite program was directed to begin procuring its own telemetry, tracking, and commanding solutions. As a result, "stovepipe" systems were developed for each mission area, which still exist today (e.g., Milsatcom, navigation). This approach duplicated common ground system functions and created unique user interfaces, which made training less standard. Stovepipe systems do have an advantage in that they effectively meet the specific needs and timelines of each satellite program; however, they are not interoperable, and they have become expensive to maintain over time.

Flexible Command and Control Framework

Unlike the stovepipe approach, the envisioned command and control framework is a standard, open communications infrastructure based on commercial networking technologies. It provides common physical interfaces for communications protocols within and among satellite operations centers and shared antenna resources provided by AFSCN. It is built upon a core set of specific standards for messaging and for formatting the data transported by those messages, which represent satellite operational information (e.g., telemetry, commands, orbits, mission activities).

This framework enables multiple operations centers to share a common set of tools and services that are added to the infrastructure over time as appropriate. Each mission area can also build mission-specific components on top of the shared enterprise framework. At a minimum, legacy systems can interface to the common infrastructure to provide access to their satellite command and control information, and can begin migrating to those common tools and services that provide the best return on investment. New satellite programs would be designed to use the shared infrastructure, and only those command and control elements that are unique to each mission would have to be built, thereby reducing overall system cost.

A compatible satellite command and control framework enables multiple operations centers to share a common set of tools and services that are added to the infrastructure over time as appropriate. Each mission can also build mission-specific components on top of the shared enterprise framework. Legacy systems can interface with the common infrastructure too.

Concepts of Operation Flexibility

The envisioned command and control framework accommodates multiple concepts of operation without changing its fundamental standards. For example, when implemented for a single satellite mission, it provides a predeveloped infrastructure and set of core services that require additional development of only the mission-unique portion of the ground-control software. It does not constrain satellite missions to specific services; rather, it enables a program to tailor its uses of the framework to best meet its specific requirements. To fit into the framework, a satellite mission must adhere to the standards for messaging and data between the command and control functions it creates. Doing so avoids the rigid, one-size-fits-all approach that made the Data Systems Modernization architecture inflexible and costly to change.

Another possibility is to use the framework within a multimission operations center, where each individual satellite mission shares a common infrastructure. Each mission has its own unique piece, but all missions can use the shared services provided in the framework for common command and control functions. Extending the framework across multiple satellite operations centers creates a true enterprise for satellite operations, where multiple centers can share a common infrastructure and services. Because of the standard way satellite information is both represented and transported, space and ground situational awareness is enabled across all centers and missions in the enterprise.

Some of the principles and definitions necessary of responsive space and their link to actions. Utility, interoperability, flexibility, adaptability, and agility are just some of the factors that must be considered.

Common Command and Control Services

A look at a typical satellite operations cycle in the satellite operations center at Schriever Air Force Base illustrates the potential advantages of a command and control framework with a standard communications infrastructure and services. The satellite operations centers generate requests for AFSCN antenna services to mission planning personnel at Schriever Air Force Base generally two weeks before the required satellite contacts. The mission planning personnel perform the orbit management and mission scheduling function. To support this process, a cycle of information is needed to feed the orbit management, mission scheduling, and real-time satellite contact execution process. One portion of this information cycle is illustrated in the following steps:

1. Each day during satellite contacts, AFSCN tracking stations produce tracking data that is delivered to the satellite operations center. The telemetry and commanding software systems in the operations center receive the data and pass them to the orbit management systems in each operations center.
2. Operations personnel responsible for orbit management periodically determine satellite ephemeris from tracking data collected over several satellite contacts to predict when the tracking stations will be able to view the satellites two weeks into the future. From this prediction, calculated antenna look angles are also created for future AFSCN service opportunities.
3. Operations personnel responsible for mission scheduling employ satellite visibility information as well as other resource information to assign specific satellite supports to remote tracking stations in the future. The results are reviewed by the satellite operators and reconciled against an established priority scheme to generate an overall schedule for satellite supports. The resulting schedule is sent to the satellite operation centers and the assigned remote tracking stations. Specific contact support plans and operational crew assignments are developed.

In a compatible command and control framework, the same satellite tracking information going from the AFSCN to the satellite operation center's standard communications infrastructure would be published by the infrastructure using a standard message format. The information would be subscribed to by an orbit management service that also publishes its information to the bus. A mission scheduling service could subscribe to that information to create its candidate resource requests and coordinate the schedule with the AFSCN planning and scheduling organization, which is also connected to the satellite operations center communications infrastructure to adjudicate contention of resources. Once the AFSCN allocates resources, the mission scheduling service publishes the contact schedules and associated instructions to be passed to the operational crews that will execute the satellite contacts on shift. As shared orbit management and mission scheduling services become more efficient and automated, the number of operations personnel can be reduced.

The power of using a standard communications infrastructure and shared services becomes clearer as other satellite systems are added. The next satellite mission will need only to publish its information—in this case, satellite-tracking information—using the same message and data standards. It does not need to develop its own services.

Enabling Situational Awareness

Another advantage of the command and control framework is that all satellite applications have access to the same information traveling through the infrastructure. This enables situational awareness of operations in real time. Publishing data across all satellite operations centers and satellite programs on the standard communications infrastructure augments development of value-added applications that are not easily created in today's stovepipe environment.

As an example, telemetry made available in a standard form from all satellites can be used to build applications that identify the effects of space weather across the entire space environment. For national security, other applications could provide national leaders with indications of space attacks and assessments of national space mission status in real time during times of conflict. Other value-added capabilities that can emerge from a compatible command and control framework include adding greater opportunities for automation of satellite operations to reduce costs and adding high-level enterprise management to the nation's space ground infrastructure.

SMC Concept Explorations

To explore the technical feasibility and opportunities of moving to a compatible command and control framework, SMC's Satellite Control and Network Systems Group initiated a concept exploration study and testbed development effort using the Aerospace Ground Systems Laboratory, starting in mid 2008. The objective was to look at potential options for a middle-of-the-road approach between the extreme commonality of the Data Systems Modernization and the extreme specificity of stovepipe systems. The laboratory started with the NASA Goddard Space Flight Center's command and control framework, called Goddard Mission Services Evolution Center (GMSEC). The GMSEC implements many of the features of a compatible framework for Goddard satellite missions and proved to be a valuable starting point for SMC's exploration of framework concepts. A key factor in the selection of the Goddard framework was its independence as a government agency from the influence of vendor-proprietary solutions.

The command and control framework testbed, created by the Ground Systems Laboratory, implements the framework structure of a standard communication infrastructure using either the GMSEC bus or a commercial sockets-based bus product (such as the TIBCO Software bus) and the NASA-developed application programming interface. The interface was instrumental in allowing command and control components to rapidly integrate for "plug-and-play."

Aerospace Ground Systems Laboratory Testbed

The testbed created by the Ground Systems Laboratory implements the framework structure of a standard communications infrastructure using either the GMSEC bus or a commercial sockets-based bus product (such as the TIBCO Software bus) and the NASA-developed application programming interface. The programming interface was instrumental in allowing command and control components to rapidly integrate the bus and messaging standard with the framework in a manner resembling a "plug-and-play" capability.

Four satellite telemetry, tracking, and command systems were rapidly integrated using adaptors developed by vendors and the Ground Systems Laboratory. In fact, three of the four applications were successfully integrated within the first two months of building the testbed and demonstrated passing telemetry across the bus.

These systems used simulated data for both NASA and Air Force satellite missions. Satellite command and telemetry data were simulated using a commercial off-the-shelf (COTS) simulator—SAGES (Satellite and Ground Environment Simulation)—used in training Air Force satellite operators for both the Global Positioning System (GPS) and Defense Satellite Communications System (DSCS)-3. The systems included simulated data from AFSCN tracking stations.

For added realism, actual front-end hardware commonly used at the satellite operations centers and AFSCN was also integrated in the testbed, enabling researchers to begin exploring options for the framework to monitor and control network hardware. NASA provided various tools—for example, a system monitor tool called GREAT (GMSEC Reusable Events Analysis Toolkit)—to help manage the framework, monitor traffic on the bus, and display SMC satellite data in messages.

The Ground Systems Laboratory also developed a multimission telemetry display to show the sharing of information across satellite missions that would be needed to support space situational awareness. In addition, sample services were created, including one that used a COTS orbit analysis product to help simulate orbit management. This service subscribed to simulated tracking data for both GPS and DSCS-3 satellites using AFSCN remote tracking stations in Guam and Boston and published predicted satellite ephemeris and real-time visibility information.

Phase One Study Findings

With the completion in February 2009 of phase one of the study by the Ground Systems Laboratory, the testbed successfully showed features and potential problems of a compatible command and control framework in operation with Air Force mission data. The following list includes some of the specific activities accomplished using this testbed.

• Demonstrated a shared communications infrastructure based on commercial publish and subscribe technologies with standard interfaces supporting telemetry streams and telemetry mnemonic subscriptions from six different satellites.
• Simulated multiple telemetry sources on a common message bus, subscribed to by current telemetry, tracking, and command applications used by the Air Force, such as Milsatcom CCS-C (Command and Control System—Consolidated) and GPS AEP (Architecture Evolution Plan).
• Controlled the operation and configuration of AFSCN front-end hardware using NASA GMSEC standard messaging.
• Demonstrated a rudimentary situational awareness capability by merging telemetry information from both DSCS-3 and GPS satellites in a common display.
• Measured the performance of adding the GMSEC application programming interface and a middleware sockets bus to real-time commanding, which showed minimal impact to real-time operations.
• Executed a simulated DSCS-3 satellite state-of-health and battery reconditioning support using the NASA command and control framework, including message bus and standard messages.
• Demonstrated the feasibility of using shared services for orbit management and mission scheduling between two satellite missions, which now duplicate this functionality in their own stovepipe implementation.
• Proved the plug-and-play capability of framework components and the infrastructure's middleware by replacing the GMSEC bus with a commercial bus.
• Illustrated the need for security features in the GMSEC implementation to meet DOD requirements.

In addition to using the testbed to assess command and control framework concepts, Aerospace also performed detailed analysis of the GMSEC standards and application programming interface implementation to assess overall maturity and identify gaps in capabilities needed by an SMC framework. The maturity analysis had three separate components—an automated code analysis, a detailed code walk-through, and an industry questionnaire. The code analysis provided several useful metrics, including code complexity, code/comment counts and ratios, and object-oriented metrics. The detailed walk-through of the C++ source code focused on industry standard best practices, programming conventions, style, and functionality. The user survey was sent to industry partners with current experience not only with the GMSEC application programming interface, but also with relevant satellite command, control, communications, and telemetry programs.

The application programming interface was found to be flexible and usable with sufficient functionality. Overall, the complexity metrics indicated a relatively low-risk, maintainable framework; however, detailed analysis of the framework revealed several areas needing improvement—specifically in security, logging, and complexity of certain high-use software components.

Aerospace Conclusions

Based on the results of phase one of the study, Aerospace concluded that a compatible command and control framework or architecture is technically viable for Air Force satellite operations centers. A key finding was the lack of adequate data standards for satellite command and control information to complete a comprehensive framework definition. Without this standard, integration of new satellite missions into the framework would be more costly and less rapid.

Aerospace recommended that the government take a lead role in defining these command and control standards. Industry efforts to create a data standard through the Consultative Committee for Space Data Systems—particularly, the XML Telemetric and Command Exchange—are a good source for the government to derive a suitable data standard that could be implemented by vendors economically.

The Aerospace Ground Systems Laboratory is expanding the use of the testbed in phase two of the study to look into specific issues important to the Air Force, such as security and unique AFSCN interfaces. In particular, information assurance features will be defined for the framework and their impacts on performance will be assessed on the testbed.

Acknowledgments

Many individuals, organizations, and companies helped create the testbed and results provided in this article. Col. Philip Simonsen and Maj. Matthew McQuinn of SMC's Satellite Control and Network Systems Group provided funding support. Lamont Williams of Aerospace was instrumental in providing guidance during the study. Dan Smith and his GMSEC team at NASA Goddard provided expertise and software that jump-started the testbed. Integral Systems Inc., L3 Communications, Lockheed Martin, Harris Corporation, TIBCO Software Inc., and a.i. solutions loaned software and hardware and provided free technical support. Finally, thanks goes to members of the Ground Systems Laboratory team that built and analyzed the testbed including Prashant Doshi, Andrew Gilbertson, Cathy Proplisch, Alex Martinello, Eric Nelson, Thomas Eden, and Sky Troyer.

To Summer 2009 Table of Contents