Control Channel Toolkit: A Software Product Line Case Study
2 Contextual Background
We begin with an overview sketch of CCT. CCT is a software asset base commissioned by one organization (the NRO) and built under contract by another (the Raytheon Company). This acquirer/contractor arrangement adds a bit of a twist to some of the software product line practice areas and also introduces some interesting economic motivations. Raytheon hopes to use the CCT experience to secure future spacecraft command and control system business. The NRO hopes to persuade other government spacecraft ground system projects to subscribe to the product line effort that it commissioned, thus defraying some of the CCT development and sustainment costs.
CCT is neither a complete software system nor a complete software product
line; it is a software product line asset base. The asset base consists of
generalized requirements, domain specifications, a software architecture, a
set of reusable software components, test procedures, a development
environment definition, and a guide for reusing the architecture and
components. CCT users build products. CCT users are individual government
contractors commissioned by a government office to build spacecraft command
and control systems using the CCT software assets. CCT is currently being used
to field several government systems. Those systems constitute the actual
product line. The NRO is currently funding Raytheon to maintain the CCT for
current and future users. Figure 1 annotates our software product line signature
diagram [Clements 01] to illustrate.
You can see from this illustration that in this case the product
development and the core asset development are split among potentially
different contractor organizations, and Raytheon, the NRO, and CCT users share
the management responsibilities. If we are to understand how this all works
smoothly, we need to know something about the two key organizations¾ the NRO and Raytheon.
The NRO designs, builds, and operates defense reconnaissance satellites. NRO intelligence products, provided to an expanding list of customers such as the U.S. Central Intelligence Agency (CIA) and the U.S. Department of Defense (DoD), can warn of potential trouble spots around the world, help plan military operations, and monitor the environment. As part of the 13-member Intelligence Community, the NRO plays a primary role in achieving information superiority for the U.S. Government and Armed Forces. The NRO is staffed by both DoD and CIA personnel. It is funded through the National Reconnaissance Program, part of the National Foreign Intelligence Program. The U.S. Assistant Secretary of the Air Force for Space also serves as the Director of the NRO.
In the past, the very existence of the NRO, let alone its software projects, was classified information. In recent years, the NRO has implemented a series of actions declassifying some of its operations. The organization’s existence was formally declassified in September 1992, followed by the location of its headquarters in Chantilly, VA, in 1994. In February 1995, CORONA, a photoreconnaissance program in operation from 1960 to 1972, was declassified, and 800,000 CORONA images were transferred to the National Archives and Records Administration. The declassification of the satellite generation following CORONA is currently planned. In December 1996, the NRO announced for the first time, in advance, the launch of a reconnaissance satellite. This new policy of openness is, among other things, intended to increase the NRO’s customer and contractor base.1
Shrinking budgets have brought all this about. As the NRO director recently remarked,
This new atmosphere at the NRO¾shrinking budgets, openly
looking for customers of NRO products, exploring
partnerships with industry¾laid the groundwork for
turning to software product lines as a cost-saving
system acquisition strategy.
The NRO selected Hughes Electronics Corporation as prime contractor for the CCT development. The development team at Hughes had broad experience in satellite ground control systems. This experience was to serve them well when it came time to craft common requirements that were generic enough to serve the first three different satellite projects, yet specific enough to be useful to each of them. They were already knowledgeable in areas such as orbit dynamics, coordinate system transformations, vehicle configuration variability, and other technical aspects that would need to be mastered before they could build any single satellite ground control system, let alone an asset base for an entire family of systems. Furthermore, the Hughes team was accustomed to following defined processes for both software project management and software development. The process discipline required for software product line efforts was not a stretch for them.
Hughes Electronics subsequently merged with the Raytheon Company. The consolidation of Hughes into Raytheon also brought together related operations formerly called Raytheon E-Systems, Raytheon Electronic Systems, and the Texas Instruments divisions earlier acquired by Raytheon. Overall, the Raytheon Company operates in both the defense and commercial sectors in the areas of electronics, aircraft systems, and engineering and construction. Raytheon is one of the largest American defense contractors, with $20 billion in sales and more than 92,000 people. Their products include missiles, radar systems, sensors and electro-optics, reconnaissance, surveillance, air traffic control, and aircraft integration systems.3
When Hughes was merged with Raytheon, CCT became a Raytheon project, although the development team remained unchanged. There were 20 to 25 employees on the Raytheon development team that took CCT from domain analysis through its architecture creation and implementation. The team peaked at 45 people during component engineering. With the exception of a very small number of subcontractors, all technical work was done at the contractor’s site in Denver, Colorado.
The Control Channel Toolkit project actually emerged from earlier efforts to produce common software for satellite command and control. In 1993, an Air Force program office began the acquisition of a replacement command and control system for a classified satellite program. The contract for the Distributed Command and Control System (DCCS) began in 1994. The DCCS was designed to fly a specific type of space vehicle. Its design was for the most part object-oriented with some wrapped legacy code that provides highly specialized numerical algorithms.
In 1996, the Air Force Space and Missile Center (SMC) began an effort for a Standard Spacecraft Control Segment (SSCS) that brokered several other satellite program office requirements into a single specification. The SSCS goal was to exploit DCCS to produce a common core capability for use by these other program offices, thus offering development and maintenance savings for SMC. The SSCS technical approach was to modify the DCCS design and code artifacts to meet new (common) requirements. Shortly after development began, it was recognized that the approach was faulty: DCCS had not been designed to address the new requirements. In short, DCCS had not been designed for reuse. All major SSCS schedule milestones were missed. The effort was redirected to work on common human machine interfaces as a way of standardizing business processes.
At this point, the Air Force and the NRO met to determine a common development path for SSCS and DCCS that would offer reduced cost and effort in both development and maintenance phases. There was yet another government project, which we will call the Spacecraft C2 System, that had also planned on modifying the DCCS artifacts to meet their requirements. This project was early in its requirements phase. The Air Force requested a revised program plan for all three systems to determine how they could realistically take advantage of the commonalities found in all three and potentially others.
A two-month feasibility study was approved and commenced in May 1997. Six working groups were formed to explore architecture definition, process definition, operations and maintenance definition, cost analysis, schedule assessment, and risk assessment. Learning from the flawed reuse approach of DCCS/SSCS, the NRO initiated the Control Channel Toolkit (CCT) project to reengineer DCCS from an architecture perspective. The Spacecraft C2 Program became the first user of CCT. The Software Engineering Institute (SEI) became involved with the CCT effort at the request of the NRO in October 1997 and continued the collaboration until CCT completion.
CCT was originally conceived to be a "toolkit" that would consist of:
The toolkit concept evolved into something much more sophisticated and much more usable¾
namely, a software product line asset base. While a product line asset base certainly includes components and tools, we have seen (and so did the CCT team) that much more is required to achieve strategic, predictable, and measurably beneficial reuse.
Command and control software is employed throughout the life cycle of a space vehicle project. Typically, each satellite project develops and maintains a separate software system for the purpose of commanding and controlling the spacecraft vehicle. As the complexity of satellite systems has increased over the years, so have the requirements of the ground systems necessary to command and control them. Typical command and control systems exceed 500,000 lines of code.
The CCT supports a product line of ground-based spacecraft command and control systems (also referred to as "control channels"). Satellite control channels provide ground processing support to spacecraft, allowing operations staff to monitor spacecraft functions, configure spacecraft service and payload systems, manage spacecraft orbits and attitudes, and perform mission planning. Control channels receive clear (unencrypted) telemetry data from the front-end processing equipment and release spacecraft and ground system commands. Within a control channel, telemetry data are used to assess spacecraft health and perform payload functions. The telemetry may be provided to external clients as well; these clients may in turn provide command data to the control channel. Control channels also exercise control of the ground antenna system, uplink transmitter operations, and downlink receiver control. These monitoring and command capabilities combine to allow real-time control of the spacecraft and its payload.
The execution of these real-time functions requires connectivity between the control channel software functions and the spacecraft. The period of time and system configuration used to achieve connectivity describe a contact. Contacts normally include a preplanned set of tasks, such as assessing state of health, commanding the spacecraft into a new configuration, or executing an orbit or attitude maneuver. Since contacts require line-of-sight visibility from a ground antenna to the spacecraft and use ground resources as well, they are scheduled events determined by the scheduling activities of a spacecraft mission. Unplanned contacts may also be required to perform anomaly resolution for the spacecraft.
Control channels perform orbit and attitude maintenance through processing of tracking and telemetry data and generation of orbit estimates and maneuver data. These data are used to determine the need for future contacts and command parameters as well as the times required to execute the maneuvers. Special consideration is given to launch and early-orbit operations, which often place the spacecraft into unique configurations or impose unique requirements.
Some control channel processing is real-time or near-real-time and is called execution processing. The remainder is batch or off-line and is called planning. During a contact, the control channel primarily executes capabilities associated with the receipt of telemetry and the release of command data to the ground equipment and spacecraft. The control channel receives raw telemetry from the spacecraft and the antenna ground system through its front-end processing equipment and converts it into client-usable form. The control channel distributes the telemetry to client processes, often with graphical user interfaces (GUIs) provided for operators to make real-time assessments of the spacecraft’s health. Client processes may also initiate command requests that cause formatting and transmission of command data to destination services such as the spacecraft or to ground equipment such as the antenna. In many systems, traditional operator functions are automated through the use of special client processes that use rule-based processing.
Control channels archive telemetry and command data as well as other systems data such as operator actions and tracking data. These data form key inputs to the planning functions and provide a historical log for analysis and bookkeeping. Historical data are available for trend analysis and anomaly resolution.
Modern spacecraft use on-board processors to control both platform bus and mission payload functions. Control channels model the on-board processor instruction and data loading and its execution in order to anticipate spacecraft state and behavior.
In off-line processing, the control channel performs planning functions to estimate and propagate the spacecraft orbit and attitude, calculate maneuvers to change orbit or attitude, and schedule future contacts and resource needs. These functions include both launch and early-orbit support for the spacecraft as well as on-orbit operations.
Figure 1: The Three Essential Activities and CCT
Figures in this file are displayed in a separate browser
window. This window will remain open to display figures in this file,
although it might be hidden behind other browser windows.
I look back at former NRO Directors, having had tons of money and very little
oversight, and they achieved great results. I look at them with great envy
because now I have an awful lot of oversight and not nearly as much money. .
.Today, virtually all of the imagery that is collected by the National
Reconnaissance Office is collected [as] non-sensitive
information. It’s delivered to military forces around the
world. . . [T]he large majority of NRO information can be
handled at lower classification levels, opening up the
opportunities for partnership. Finally, we continue to find
ways of strengthening our partnerships with industry. As the
commercial satellite industry matures, we’re looking at
industrial practices and trying to bring them into our major
acquisitions.
1
Source: http://www.nro.gov
2
From remarks by Keith Hall, Director of the National
Reconnaissance Office, to the National Space
Symposium, Colorado Springs, Colorado, 9 April 1998.
3
Source: 1999 Raytheon annual report, http://www.raytheon.com/finance/1999/ray_annual.pdf.
[Title Page]
[Abstract]
[Figures]