e-Prints


Blueprints for the Future

Comparing National Security Space Architectures

by

Christian C. Daehnick

INTRODUCTION

In recent years it has become cliché to speak of the growing importance of space systems and their capabilities to US national security in general and to military operations in particular. At the very least, the changing national security environment and our experiences in the Gulf War have caused a more open discussion of what those space-based capabilities are and what they should be. Along with a greater awareness of space has come realization that the systems often seem unresponsive to the needs of some users and that gaps exist in our capabilities. Many see the current US space "architecture" as fragmented or stovepiped, and inflexible. At the same time, decreasing budgets mean that the solution to any problems cannot simply be the purchase of additional capability; the times demand more efficient answers.

Complacency about our space capabilities at this point would be dangerous. Although the United States presently has the best space systems in the world, and military peer competitors or threats to our national survival are beyond the horizon, there is a danger that efforts over the coming years will not adequately address the shortfalls of the current space architecture. Space systems that remain unresponsive, fail to live up to expectations, or fail to evolve toward new capabilities will disillusion national and military policy and strategy makers, who might then either ignore space capabilities entirely or back other, possibly less effective solutions. Ultimately, such a situation will hurt the United States.

Broadly speaking, there are two approaches to making the national security space architecture more effective. The first is incremental, working to eliminate inefficiencies and expand access to space systems/capabilities in a gradual fashion. It would by and large retain the command, control, and tasking arrangements, communications channels, organizational structures, and space system design and operating procedures of the current architecture. A less conservative approach would involve a shift to a fundamentally different architecture based on decentralization and improved responsiveness. Which approach will produce the best capabilities for the United States, given limited resources?

Answering this question begins with a clearer understanding of the alternatives. The current space architecture is primarily "command-oriented": centralized, driven by specific performance requirements and employing a "push" approach to providing services. Numerous initiatives are underway to modify current space systems and make them more responsive, but fundamental changes would be needed to make the architecture "demand-oriented." Demand orientation implies a more decentralized organization, a user-pull approach to providing services, and a focus on responsiveness.

Challenge and Response

The basic question of this study is whether command or demand-oriented architectures can make better use of space for national security purposes, and better respond to a changing security, technological, and budgetary environment. The question is complicated by real tensions between the characteristics of command and demand-oriented systems. They do not perform all functions equally well, and each approach requires some compromises. For example, a command-oriented system requires investment in large, complex systems, and only permits incremental changes in the architecture.

The incremental approach may not be a satisfactory long-term solution, however. Although attractive and to some extent necessary because it makes best use of what the United States has already invested, it begs several questions. Does such an approach attempt to defy fundamental trends in technology, operational requirements, and budgets? Because of the basic philosophy underlying current space systems, will we remain tied to small numbers of large, complex, expensive, and vulnerable systems spread ever more thinly trying to satisfy multiple users? Will these users then grow more dissatisfied with the responsiveness of space systems to their needs, and seek other solutions? Will space systems take so long to design, build, and deploy that they are technologically out of date as soon as they are deployed? If the answers to these questions are "Yes", we may do less, not more in space in the future, to the detriment of our national security.

The radical alternative is to shift to a demand-oriented architecture; one that more directly responds to the needs of today’s primary users and can adapt more readily to changes in requirements or technological opportunity. The primary elements would be smaller, more distributed, and autonomous space systems that could be tasked directly by the users and more closely integrated with other military operations. Such tailored, distributed constellations of space systems would both be enabled by advances in microelectronics, miniaturization, automation, and modularity, and offer a better way to keep our space systems modern and effective. This approach also appears to fit better with a world of global commitments and pop-up crises than our current systems. Unfortunately, such a shift in architectures does not come without cost, nor will it satisfy all requirements. A demand-oriented architecture will require a more responsive space launch capability than we currently have. It will also require a change in satellite design philosophy to emphasize rapid production and deployment, perhaps at the expense of spacecraft lifetime. These trade-offs may reduce performance in some areas, which might be acceptable to some "customers" but unacceptable to others.

Problems will arise if recognized issues of coverage, responsiveness, timeliness, and so forth are not or cannot be addressed by the space architecture. If our space system design and operational philosophy remains closely linked to a Cold War environment our space architecture will likely be inadequate for the world of the next century. Demands on space systems are rising as budgets decrease. Unfortunately, the acquisition, deployment, and to some extent operation of our space systems may remain caught in a vicious cycle of upwardly-spiraling cost, complexity, and time making it difficult to accommodate the changed circumstances. The technical problems will be compounded if institutional inertia and organizational turf battles are allowed to impede constructive change. What is needed is an objective method for deciding if the challenges can be better met by a command- or demand-oriented approach, or if elements of both are required.

Approach

This paper is a foundational effort to develop a methodology for comparing different space architectures. Since an overriding issue is how and why the question of space architecture matters to future national security, the paper begins by describing the capabilities and limitations of space systems. This begs the question, though, of whether those limitations are absolute and intrinsic — unavoidable consequences of some characteristic of the space environment — or actually the result of the design choices made in creating the existing Cold War-based space architecture. Building on these basic issues, the paper will next describe command and demand-oriented space architectures in terms that will allow objective comparison. Next, the paper describes the fundamental factors—requirements, technology, and budgets—that will determine future space architectures, and how these "determinants" affect different types of architectural approaches. The two approaches (command and demand oriented) will be compared against a test case: theater reconnaissance, surveillance, and target acquisition (RSTA). Though not comprehensive, this test case will provide broadly useful insights into future options for national security space doctrine and policy.

DESCRIBING SPACE ARCHITECTURES

Architecture: n. Construction or structure generally; any ordered arrangement of the parts of a system

- Websters Illustrated Contemporary Dictionary

A space system architecture, shaped by the determinants of requirements, technology, and cost at the time of its design, has inherent capabilities and limitations. Comparing architectural alternatives is the best way to highlight strengths and weaknesses of different approaches to developing a "system of systems," but this requires a common framework. This section describes the advantages and limitations of space systems, asserts that not all the drawbacks traditionally associated with space systems are intrinsic, and closes by presenting a way of categorizing and comparing space architectures that will be used in the rest of the paper.

Types of Advantages and Limitations

A proper evaluation of alternative approaches to an issue needs to begin with an objective discussion of the advantages and limitations of each approach. Advantages and limitations of a class of environment-based systems (air, sea, land, space) are either fundamental or derived. The first type (fundamental), which is based on the physics and phenomenology of the environment or medium, could also be called enabling or constraining. In other words, fundamental advantages (or limitations) cannot be altered, only overcome or exploited. The second type (derived) is based on our ability to exploit the environment, which in turn depends on technology, doctrine, and cost. Derived advantages and limitations, though related to fundamental characteristics, are subject to change as military forces (for example) acquire new physical abilities and knowledge. Distinguishing between fundamental and derived advantages or limitations can be difficult, especially when a way of operating has become so entrenched that its genesis and rationale are obscured. Failure to do so, however, may mean that the most effective solutions to a problem are not considered. Thus the ability to compare begins with an understanding of the recognized advantages and limitations of space systems and a realization that these are produced from an interaction of fundamental or environmental qualities with design choices.

The Advantages of Space Systems

Perhaps because the use of space for military operations, and particularly unclassified discussion of it, is a relatively recent phenomenon, and because applications of space "power" continue to evolve, there are nearly as many lists of the advantages of space systems as there are authors. For example, Joint Pub 3-14, Joint Doctrine; Tactics, Training, and Procedures (TTP) for Space Operations refers to the various missions space systems can perform (communications, navigation, surveillance, etc.) as space system capabilities. More to the point, it describes space "characteristics" (extent, vantage, gravity, composition, radiation, temperature, and propagation) and operational considerations (difficult access, placement, long-duration flight, maneuver, global coverage, decisive orbits, weapons range, and organization). While recognizing in the text both that the environment affects the characteristics of the systems, and that this environment offers both opportunities and constraints, the JCS pub does not explain the concept completely. For example, it does not make clear what the net effect of the "characteristics" of extent and composition with weapons range and platform speed (an unmentioned feature) might be. It also, probably necessarily, oversimplifies such concepts as orbit predictability. Except for some rather optimistic and unsupported statements ("Global coverage ensures timely space support is available..."), time and timeliness are hardly dealt with at all as factors in space operations. Finally, the operational considerations are clearly based on existing systems; a valid approach, but one that may inhibit thinking about alternatives.

Evolving doctrinal discussions at US Air Force Space Command focus on the unique "attributes" of space systems: concentration, timeliness, continuity, and perspective. This list appears to be a step in the right direction, but it still contains some troublesome embedded assumptions about the architecture. For example, the "attribute" of continuity "relates to the long operational duration of spacecraft" implying "there is no need to generate forces during a period of increased tension or readiness." This of course assumes we have (and can afford) all the capability we will ever need on orbit at all times, and also that we won’t lose some of that capability (to mishap or hostile action) at unfortunate times.

The SPACECAST 2020 study conducted at Air University cited two "paramount advantages of space—unparalleled perspective and very rapid access to [distant points on] the Earth’s surface." These seem close to being fundamental. Perhaps significantly, they advantages were not asserted a priori, but culled from the ideas presented in the study.

Each of the authors or organizations impose particular biases on the use of space in describing space attributes and doctrine. These biases affect their interpretation of the advantages (and limitations) of space, so each list is somewhat incomplete. A reasonable synthesis of the fundamental advantages of space would be:

Space Advantage

Reason

Non-territorial operations

No worries about overflight rights or provocations in pre-hostility phases of

a crisis.

Vantage point

The ultimate "high ground", providing the following three features

- Viewing angle

- Ability to avoid any obstructions as necessary

- Wide area perspective

- Ability to see an entire area of interest at once; potential for synoptic

coverage

- High energy states

- High speed, useful for rapid transit or potentially to enhance weapons

effects

Global access

Ability to get to any region on earth, support operations in separated

regions

Table 1: Advantages of Space Systems

These advantages are based on two characteristics of space. The first is that space operating restrictions are determined by the function of the spacecraft, not its location (unlike national airspace or territorial waters). The second is that the physics of space systems place them higher than other systems and give them access to large areas of the earth in a relatively short period of time. These two features, manifested in the list of advantages above, seem both generic enough to allow further refinement and broad enough to capture the truly distinctive characteristics of space. The list is undoubtedly open to debate, but at this point only one difference from other lists will be highlighted: longevity (or continuity) is deliberately excluded from Table 1. This is a design choice based on orbit selection and spacecraft characteristics, not an inherent quality of all space systems. Also, this "advantage" does not come without costs, as discussed later.

Of course, none of the advantages are unqualified, nor are they necessarily unique to space. Combinations of features (global access and non-territoriality, for example) do point out the unique contribution space can make, and provide the rational for pursuing space solutions, even in the face of significant disadvantages and limitations.

The Limitations of Space Systems

Few authors, particularly in the space community, discuss the disadvantages or limitations of space systems in any detail. Such points are usually left to the advocates of alternate approaches (e.g. airborne or surface-based) as they compete for funding. As a result, several features of space systems that are more closely tied to design choices or even specific system concepts than to the environment itself have become accepted as generic disadvantages of space.

Clearly, though, space systems have perceived shortcomings in their ability to conduct routine, sustained, and effective military operations. These include:

Perceived Disadvantage

Meaning

Distance

Space systems must operate remotely

Predictability

Enemy knows when satellites will be overhead

Poor continuity

Lack of dwell time and gaps in revisit time.

Poor responsiveness

Ability to respond to crises they weren’t designed for (strategic) and to theater requirements (operational).

Inflexibility

Long planning lead times; difficulty of making changes.

Unsatisfactory timeliness

Inability to distribute information to end users quickly.

Vulnerability

To attack or natural disaster

Environment

Harsh radiation, temperature, debris, etc.

Cost

Both space systems and access to space are expensive.

Table 2: Perceived Disadvantages of Space

Efforts to overcome these limitations can take several forms: upgrades, mission diversion, or architectural change. The first, focusing on process and procedures, does not seek to address any fundamental limitations, but to improve space system performance at the margins, or in kinder terms, to take full advantage of existing capabilities. The second, mission diversion, involves replacing, augmenting or avoiding the use of space-based systems through the use of alternative means such as airborne platforms for surveillance and reconnaissance, and terrestrial fiber-optic links for communications. The architectural change response is the most radical and has arguably not been tried in the national security arena. To explain how deliberate architectural choices affect space system characteristics, the study now needs a framework for comparison.

Developing a Framework

The first element of the framework is a series of definitions. These are presented below in Table 3, to provide common terms for discussion.

Architecture

The overall, grand design for the hardware, infrastructure procedures and measures of performance of a "system of systems." A strategic theory for exploiting space and a doctrine for employing space assets are implicit in an architecture, though these things may not be well articulated.

National Security

Space Architecture

The architecture associated with military, intelligence, and other functions commonly referred to as the "national security" sector.

Segments

Parts of an architecture grouped by their role and environment. The space segment is what remains on orbit for the duration of its mission. The ground segment is employed by space "operators" and "customers" to make the space segment useful to terrestrial operations. The launch segment is concerned with deploying the space segment, though certain kinds of "launch" vehicles may perform other missions.

Elements

The component pieces of the segments; for example, the ground segment would include command, control, communications, processing and distribution, logistics, and supporting infrastructure elements.

Operator

An organization that controls the activity of a space system.

Customer

An organization or individual with a need for a space product or service.

Attributes

The desired/required, implied or predetermined characteristics of the elements. For example, survivability (robustness?) is a general attribute, which is determined by a system’s size, "hardness", maneuverability, stealthiness and other properties (subattributes). Some measure of survivability may be required by military necessity and expected threat; the way in which this is specified will determine parts of other attributes, such as cost or logistics.

Functional Area

Force enhancement, force application, space control, space support.

Mission Area

A subset the functional areas, such as navigation under force enhancement.

Determinants

Operational requirements, technology, cost.

Table 3: Space System Terms and Definitions

To construct a generic framework for a space architecture the space, ground, and launch segments—fleshed out with their elements, as defined above—make up one axis of a matrix. The second axis will be the attributes (again as defined above).

The result will form the basis for describing the specific features of an architecture, and thus allow comparison of different architectures. The real-world determinants of requirements, technology, and cost as will be described later provide additional detail and refinement.

Elements of a Space Architecture

The challenge with this list is to make it a useful breakout yet inclusive of different type of systems and not overly specific. One way to do this is to use general types of elements as described below, rather than listing every possible element of each segment.

The space segment consists of the mission payload, the spacecraft, and the constellation. The mission payload includes the sensors, transceivers or other equipment that produce a satellite’s capability (ies) of interest. Depending on design, this could be either a fairly modular and easily identified element, or it could (in a highly integrated system) merge with the spacecraft element. Normally though, the spacecraft element is what provides support to the payload: power, navigation, control, and maneuvering capability, communications, and structure. The "constellation" means the number of satellites and their orbit(s). Together, the elements of the space segment determine much of the performance, lifetime, degree of ground support required and other qualities of a space system.

The ground segment is composed of elements that support the satellites in orbit and exploit the information they provide, and can be broken down into telemetry, tracking, and control (TT&C), facilities and infrastructure, and user equipment. TT&C is primarily related to those functions needed to maintain the satellites in orbit and ensure they perform properly. Facilities and infrastructure is of course buildings, antennas, and other support equipment, but also any intermediate communications or processing capabilities needed to deliver and make the product of the satellites useful to their ultimate customers. This also includes common use equipment, such as the space surveillance network which keeps track of orbiting objects. User equipment could range from things like global positioning system (GPS) receivers and special satellite communications (SATCOM) equipment to field-deployable ground stations and tactical dissemination capabilities. The features of the ground and space elements interact strongly and provide many potential areas for trade-offs.

The launch segment includes equipment, facilities, and procedures needed to deploy the space segment. These can be divided into the command and control functions and the sites required to physically prepare and launch a vehicle. Of course the vehicle itself makes up the third category of launch segment elements. Although it is called "launch," this segment would also include other functions, such as orbit transfer, recovery, and de-orbit, or even suborbital missions. It may be worth calling this the "transport" segment as (if and when) the United States moves toward a more comprehensive and sophisticated space capability. This segment, though traditionally seen as completely subordinate to the requirements of the spacecraft designers, may in fact hold the key to flexibility in the other segments.

Summarizing the discussion above, the basic elements of a space architecture can be listed as follows:

Segment

Element

Space

Mission payload

 

Spacecraft

 

Constellation

Ground

Telemetry Tracking & Control (TT&C)

 

Facilities/infrastructure

 

User equipment

Launch/transport

Command and control

 

Launch sites/ranges

 

Vehicle

Table 4: Space Architecture Elements

By themselves, the elements described above offer only a physical description of a space architecture. Functional characteristics, like data transmission, information processing, and data fusion are in fact incorporated in the physical elements, as will be seen in later architectural description. To make value judgments about an architecture and especially to compare alternatives, some qualitative description is needed. For this purpose, the following attributes will help complete the picture.

Attributes of Space Systems

As defined below, the attributes describe the characteristics of each element. These attributes should anticipate design requirements and possibilities, but not predetermine the actual design. Among the most influential are:

Attribute

Definition

Performance

Ability to provide a service with necessary detail, precision, and accuracy.

Responsiveness

Ability to deliver the required performance as needed and on time.

Flexibility

Ability to shift functional or geographic focus.

Robustness

The system should not fail catastrophically or become unable to perform its mission satisfactorily in the face of attack or mishap.

Logistics requirements

Quantity and type of support needed.

Reliability/availability

The chance of the system being fully or sufficiently operational day-to-day.

Ease of operations

Degree of specialized training required.

Environmental impact

Amount of debris, waste or other pollution; need to construct new facilities.

Cost

Life cycle: research, development, acquisition, operation, and disposal.

Table 5: Space Architecture Attributes

These attributes reflect the key considerations involved in designing space systems. As with the elements of a space architecture, it is useful to group the attributes into categories rather than deal with specific items separately. The reason for this is that overspecifying the attributes can unintentionally foreclose design choices. For example, the generic attribute of robustness could be achieved in several ways involving the following interrelated (to themselves and to other attributes) qualities:

• Survivability, through

hardening of spacecraft

location (altitude), proliferation/distribution of assets

stealth/deception/decoys

defense (either organic or with dedicated platforms)

maneuver (this and defense depend on threat detection and assessment)

• Ability to augment/reconstitute capabilities

through on-orbit spares or rapid launch

• Graceful degradation

of individual systems and/or the constellation

• Reduced vulnerability to attacks on links and ground sites

autonomous satellites

antijam/low probability of intercept/encryption

hardening, mobility and/or proliferation of ground equipment

The attributes are presented without priority or weighting at this point. Adding that level of detail—deciding on the relative importance of the attributes —requires making strategic choices about the nature of the space architecture. Fully describing the elements and making design choices (such as the one on robustness mentioned above) requires both that prioritization and application of real-world determinants as will be described shortly. The framework is already of some use in describing generic types of architectures, however. Specifically, it can help illuminate the differences between command- and demand-oriented approaches.

Command and Demand Orientation

The distinction between command and demand orientation is significant because the two types are optimized differently and have different priorities. In this sense, there is a similarity to the debate over centralized versus distributed control of air power. The two types of architecture also imply significant differences beyond command, control, and organization, namely in the capabilities, design, and deployment of space systems.

A command-oriented architecture is above all a centralized approach, relying on the central direction and control for efficiency and economy of force. In theory, as with the centralized control of air power, this command oriented system ensures that the best use is made of scarce yet flexible assets. Because of the nature of space systems (worldwide access), and the potential significance of the functions they perform, this kind of architecture responds first to national and strategic needs, leaving needs at the operational and tactical levels to be satisfied as lower priorities or as byproducts of higher-level requests.

Command orientation emphasizes above all else the attribute of performance in specific tasks, which has several consequences. It leads to small numbers of large, complex, high performance, and long-lived satellites with highly specialized mission support infrastructure, and attempts to make long-range forecasts of future space system requirements. To deal with future contingencies, the system must anticipate unknowable demands, which often leads to the inclusion of performance "pads" in the design. The number of launches needed to maintain this architecture is small, though often using heavy-lift vehicles; the attributes emphasized here — as with the satellites — are performance and reliability.

Organizationally, a command-oriented architecture (in theory) has a single executive agent for the mission. In practice, however, the value of space systems for various missions and the security/secrecy requirements for "exotic" capabilities can lead to vertically integrated organizations to design, develop, and operate systems specialized along functional lines. Operations within each of these "stovepipes" are centralized, and then an additional element of centralization is added through coordinating or oversight committees. This phenomenon tends to improve the responsiveness of a system to its functional "community," but at the expense of making access from outside that community even more difficult.

To help visualize the nature of a command-oriented architecture, a matrix combining the elements and attributes of a space architecture can be used to reflect the priorities described above. Of necessity, this will be a rough portrait; it cannot readily incorporate qualitative features (such as the degree to which a spacecraft might need to operate autonomously) without the framework becoming much more detailed. Nor is it easy to portray the relative importance of the different elements in terms of resource allocation without creating confusion. As a first cut at describing an architecture type, as a possible basis for an operations analysis approach, and in preparation for applying the real-world determinants of the next section, however, this approach has some utility. Using this framework, a command-oriented architecture would look like Table 6:

 

Space Segment

Ground Segment

Launch Segment

 

Payload

Constel.

Craft

TT&C

Facilities

User

C2

Sites

Vehicle

Performance

l

l

l

l

l

w

l

l

l

Responsiveness

w

w

w

l

w

l

w

m

m

Flexibility

w

w

m

m

w

m

m

w

m

Robustness

l

l

l

w

m

m

w

w

m

Logistics requirements

m

m

m

m

m

m

m

m

m

Reliability

l

l

l

l

l

w

l

l

l

Ease of operations

m

m

m

w

w

w

w

m

m

Environmental impact

m

m

m

m

m

m

m

w

m

Cost

m

m

w

m

m

w

m

m

w

Table 6: Command-Oriented Architecture Priorities

For simplicity, the table uses only three levels of priority, with darker symbols indicating greater relative weight/emphasis of each attribute-element pair in design considerations (l = high, w = medium, m = low). This does not mean that a low emphasis is unimportant, only that it would fare poorly in a trade-off with a higher priority item. Finally, this is an attempt to describe a hypothetical command-oriented architecture, not one that exists in the real world.

In contrast, a demand-oriented architecture is organized around the attributes of responsiveness and flexibility. Again in theory, this type of system would accommodate the needs of any potential user, with the priorities determined by a given situation. To support these goals, a demand oriented architecture would consist of relatively (to command-orientation) larger numbers of smaller, more autonomous, specialized, and short-lived satellites deployed in constellations that could be tailored to specific situations. Because of the larger number and more rapid launches that would be required, launch systems would be driven by two primary attributes—responsiveness and cost—and would operate much more like current air transport. Specialized infrastructure—from launch through end user equipment—would be minimized, either by a reduction in infrastructure requirements or through sharing of infrastructure with other systems.

Organizationally, command and control would be decentralized to some extent, for example with fielded units at some level able to directly task as well as receive information from space systems, though overall spacecraft "health and welfare" functions might be performed centrally. The danger that a demand-oriented system presents, if poorly coordinated, is the same as that of decentralized air power: potentially inefficient, poorly coordinated, and misdirected effort.

Using the framework as the basis for description gives Table 7.

 

 

Space Segment

Ground Segment

Launch Segment

 

Payload

Constel.

Craft

TT&C

Facilities

User

C2

Sites

Vehicle

Performance

w

l

w

w

w

l

l

l

w

Responsiveness

w

l

w

w

l

l

l

l

l

Flexibility

m

l

l

l

w

w

l

l

l

Robustness

w

l

w

w

m

l

l

l

l

Logistics requirements

m

w

w

m

m

l

m

l

l

Reliability

w

l

w

w

w

l

l

m

w

Ease of operations

l

w

l

l

w

l

w

w

l

Environmental impact

m

m

m

m

m

m

m

w

w

Cost

l

w

l

w

w

w

l

l

l

Table 7 Demand-Oriented Architecture Priorities

In comparison to the command-oriented architecture, this illustration shows differences in the attributes that are important for particular elements, as well as differences in the priorities of attributes across the architecture. This is particularly noticeable in comparing the priorities for the launch vehicle, and in comparing the emphasis placed on the flexibility and reliability of different elements in the two architectures. It also shows that there are more high priorities in the demand-oriented architecture; perhaps an indication of why creating one may be difficult. Although not fully representative of the differences between the architectural types, the chart illustrates the value building an analytical framework.

To better explain the priorities and why some of the features described as part of one architecture are not available to the other is the task of the section which follows the next. For several reasons, however, pure architecture types cannot exist in the real world. Some of those reasons, which will help to introduce the real-world determinants can be illustrated by a brief look at our current architecture.

The Current Architecture

A thorough description of our current national security space architecture is not possible in an unclassified paper, but even the broad outlines of the functions the architecture performs and how it does so show that it is primarily command-oriented. The four JCS space functional areas are force application, space control, force enhancement, and space support. Except for ballistic missiles, which still have only a strategic nuclear mission, we have no force application capability from or through space. Likewise, we have no space control capability except for the monitoring function of the space surveillance network. The force enhancement mission areas that are currently supported are navigation, communications, missile warning, environmental sensing, and reconnaissance, surveillance, and target acquisition (RSTA). Space support consists of launch, satellite control, and logistics.

With few exceptions, the architecture reflects the characteristics of command orientation. Overall, there are a relatively small number of spacecraft considering the number of missions performed and potential customers. Satellite constellations tend to reflect the coverage needs of the Cold War. We also have a small number of operating sites—the primary ones are at Falcon AFB, CO and Sunnyvale, CA—and only two launch sites. Our launch vehicles and operating procedures are not able to respond rapidly to a crisis. Finally, those who can task, communicate with or even receive information from a space system directly is relatively small.

Some functions of the current architecture, such as communications, certain intelligence indicators, and missile warning, are now provided relatively transparently to the ultimate users through existing channels such as TIBS/TRAP (Tactical Information Broadcast System/TRE and Related APplications). These are excellent examples of a "push" sort of approach, since by the very transparency of information delivery, users are often unaware of the contributions of space systems, of the potential to get additional information, or of the procedures to do so.

In practice, the architecture was designed to respond to the needs of the national command authority, national intelligence centers, and to support strategic nuclear missions, and it still has these as its top customers and priorities. The architecture has evolved somewhat over the past few years, but it has done so by exploiting built-in but underused capability, not by changing its basic orientation.

Of course, there are exceptions. The GPS system is one obvious example with widespread applications. Also, there have been numerous TENCAP (Tactical Exploitation of National Capabilities) initiatives by the services, especially since the Gulf War, to make national systems more useful to theater CINCs and warfighters. The creation of the Space Warfare Center and Space Support Teams promise to bring in some elements of demand-orientation, but these measures do not change the basic characteristics of the architecture: access, allocation, and priorities are decided centrally and there are only a few assets to satisfy many needs.

The reasons for this focus are many and interrelated. Security has played a major part, since the need to limit knowledge of our most sophisticated capabilities has of necessity limited access; this will continue to be a source of tension given a limited number of assets, since any knowledge of their operating procedures could compromise their effectiveness. A lack of well documented requirements for expanded capabilities, and in some cases an inability to articulate requirements, from the side of the warfighter remains a factor. Bureaucratic politics has also played a part, with those organizations that in the past successfully pressed a claim to some control over a capability now reluctant to give up any of it. Technology has certainly been a factor, since for many years our space systems were on the cutting edge and therefore limited by what was deemed possible. Cost, which certainly relates to technology, is often a deciding factor in whether we can do a certain mission and how it will be done. Finally, national politics, whether of the visionary or the pork barrel sort, has affected everything from the direction of space R&D to the nature of our spacelift and space access.

Perhaps the bottom line is that our current space architecture was not built as part of a grand design, but rather evolved gradually under the pressure of many influences. Policy makers are now struggling with technical, physical, and bureaucratic inertia, and the various demands of a changed national security environment, shrinking budgets, and an exploding technology base to determine the future of our space architecture. The question for the next section and beyond is whether there is a rational way to evaluate these many influences, and what messages this process might hold for the future direction of space systems.

APPLYING RAEL WORLD DETERMINANTS

Even if "ideal" command or demand architectures do not exist in the real world, it is still useful to ask when a bias toward one approach or the other is appropriate. No general discussion can anticipate all the factors that might affect the choice of a system or architecture. In keeping with the theme of a framework for comparison, however, we proceed with a method for applying real-world determinants in the areas of operational requirements, technology, and budget to the framework of space architecture elements and attributes. The first step is to identify the determinants, if necessary describe how these challenge assumptions that have been made in the past, and describe how the determinants interact. Finally, the determinants are applied to the generic framework of command or demand architectures to show how the inherent assumptions and restrictions of each produce differing implications.

Real-World Determinants: Requirements

In the real world, requirements are debated endlessly and often have different meaning to different people. Requirements also tend to be focused on specific missions or mission areas, at least when formalized as official documents. Though developing detailed requirements in itself implies some analysis, there are a few generic requirements for future space systems that would seem to apply across the board.

The first is that in the uncertain international environment of the post-Cold War world, we cannot optimize our coverage of any particular region for an indefinite length of time. Our interests are global, and our potential enemies are both less obvious than the Soviet Union was, and more likely to be changing (this year’s friend could be next year’s revolutionary trouble spot). Compounding this problem is the fact that that fewer US forces will be forward based, so that much if not all of the ground support equipment we need to exploit space in response to a crisis will have to be deployed from the continental United States.

The second requirement is for our capabilities to be available at the earliest possible stages of any crisis. History suggests that a prompt and appropriate response to a developing situation can often obviate the need for a more drastic response later. To make this possible, the United States must have forces, including space systems, that can be both "on the scene," tailored to the situation, and fully operational in limited time. The question is just how short the reaction time must be; shorter is likely to be better, but at what cost?

The third requirement is that our systems be able to function with little strategic warning, and perhaps in the case of space systems that they provide any strategic warning we get. In other words, systems must not only have short operational and tactical reaction times (the issue above) but will have to be adaptable to vastly different types of situations. Crises of the future will tend to pop up unpredictably or else suddenly flare up after a long period of dormancy to grab the headlines and demand attention from policy-makers; Somalia, the previously repressed nationalist and ethnic conflicts in Eastern Europe and the former Soviet Union, and North Korea’s nuclear weapons are all recent examples. The dilemma posed by this and the preceding requirement is that the kind of coverage needed for global situational awareness is so massive that it will tax our ability to deploy and operate the systems and assess the information.

The fourth requirement is that our capabilities be flexible enough to respond to many different types of crises, from large-scale armored attacks to humanitarian relief operations. Also, the demand for the services of our space architecture is likely to expand suddenly and massively. For, example, the desire to limit collateral damage in wartime and the possibilities of precision weapons have opened the door to potentially huge requirements for extremely detailed data on short notice. World-wide deployments in response to crises could mean great surges in demand for remote, high bandwidth communications capabilities. The dilemma here is whether to build capabilities that will be insufficient and then prioritize tasks, build in so much excess capability that unanticipated tasks can be accommodated, or try to augment and update capabilities as required.

The final general requirement is that our systems perform their functions with little or no delay for processing, analysis, and transmission of information. This has been expressed in many ways—real time, near-real time, "in time"—and implies not just the delivery of a product, but its delivery to exactly the right customers in an immediately useful form. In a future world where transit through space is used for rapid delivery of cargo, people, and weapons, these concerns will apply to the physical as well as the ethereal.

In summary, the future national security space architecture will have to be able to function globally, bring its full capability to bear on an uncertain enemy and situation rapidly and provide enough of the right kind of service in near real time. Many aspects of this situation favor space systems of any kind, but not without reservation, especially when we must operate in a constrained budget environment as will be discussed below.

Real-World Determinants: Technology

This study will not explicitly evaluate all technologies that could contribute to space systems. As in the area of requirements, however, there are some trends and general issues that merit consideration. The first is the general trend away from the Department of Defense (DOD) leading developments in high technology sectors of the economy to DOD’s "product cycles" trailing far behind those of the commercial world. Arguably, this is just a reversal of an historically atypical post WWII trend, but the implications for development of future systems are profound. As our equipment takes longer and longer to produce, increasingly it includes out-of-date components, design practices, and materials. This is true in many militarily significant areas such as microelectronics, though not in certain niche areas such as armor plating and nuclear submarine construction. The question we face is whether space systems are one of those niche areas or not.

A related issue is the current trend favoring dual-use spending for Government research and development money. How well do space systems take advantage of this trend? Will a dual-use focus allow the Government to continue investing as much as it believes necessary in all the military niches? If not, what are the priorities in technology development, and do they support space system requirements?

In specific technology areas, advances over the past few years have been dramatic. This is particularly true of microelectronics and microprocessors. Not only is their capability today much greater than anything that could be planned for when our current space systems were designed, but progress in the near future looks to be even more rapid. Are our military systems in general, and space systems in particular poised to take advantage of this?

Both military and commercial R&D has made possible advances in command, control, and communications. Higher bandwidth links, especially using lasers, new methods of compressing information to fit into less bandwidth, more efficient ways of managing communications channels, the development of more "autonomous" machine capabilities, and the development of expert systems to reduce human workloads are all example. Has the sapce system design kept up?

Several technologies funded by the Strategic Defense Initiative Organization (SDIO) during the 1980’s appear close to fruition now. This includes miniaturization of sensors, many spacecraft components, and the ability to design and build "smart" structures that provide strength, rigidity or precise alignment, and vibration control at a fraction of the weight of current designs. Materials technologies, advanced by many different research and development efforts, also offer a chance to reduce weight or increase performance of structures and surfaces.

Both the commercial and to a lesser extent the military sectors of industry have made progress in the related fields of standardization, modularity, and flexible manufacturing. Together, these capabilities allow products that are ever-more tailored to a specific customer’s desires to be produced quickly without requiring extensive, costly redesign, testing, and fabrication by hand. How well do space systems take advantage of these capabilities and trends?

On the negative side, there has been relatively little progress in recent years in improving our spacelift capability. With minor exceptions such as the Pegasus small launch vehicle, our systems and operating concepts remain closely tied to the ICBM-derived launchers we have used since the beginning of the space age. Concepts that could radically cut costs and improve access to space would seem to merit high priority, but the efforts and results to date have been paltry. Is this because of technological hurdles or because of a lack of institutional agreement on what is needed? Can space architecture comparisons shed any light on this issue?

In general, reviewing technology and technology trends raises the issue of what the best choices or combinations for a future space architecture are. Does the nature of an architecture affect its ability to apply new capabilities? Do technologies make possible some things thought unworkable in the past?

Real-World Determinants: Budget

No discussion of real world determinants would be complete without the bottom line. It has already been raised as an issue in terms of how much capability we can afford, and what sort of research and development we will be able to pursue, so what are the general outlines of the budgetary determinants?

First, absent a new perceived threat to our national survival, defense budgets likely will continue to decline absolutely and in purchasing power in the near term. In an effort to prevent the current military becoming a "hollow force," the research and procurement accounts of the budget will probably be sacrificed to maintain current readiness. Space systems are no exception: the prospect for new system starts in the near term is poor and getting worse, and our acquisition community seems unable to produce any new answers. Even the development programs in the "black" world, traditionally thought to have almost unlimited budgets in order to get their job done, seem to be feeling the pinch.

As research, development, and acquisition budgets shrink, there is increasing emphasis on reducing the life cycle costs of systems, to include operations, maintenance, and disposal along with procurement. The catch-22 is that building systems with lower life cycle costs requires more up-front investment in improved designs. In a worst case, this could mean we have no options but incremental upgrades to system designs. Again this raises the question, do space architecture alternatives offer any way out of this dilemma?

Finally, the budgetary environment raises the question of whether we can do anything in the national security space business to take advantage of the market forces of the commercial sector. Although this has mostly been discussed in terms of the commercial sector providing services, such as launch, communications, and even some remote sensing, we should ask if there are space architectural options that might be more adaptable to a world in which market forces, not government priorities, drive most investment decisions.

How do the determinants interact?

In discussing the determinants, many of their interactions have already become apparent. Requirements drive a system toward greater capability while budgets place limits on what can be done, whether in terms of numbers, quality or the amount of research and development. Technology, however, can cut both ways. It can force costs higher while enhancing performance, or it can make a mission possible with fewer resources than were possible before. Sometimes technology can even create new missions or capabilities, which are very difficult to quantify.

Generally, the interaction of the determinants produces questions that must be answered by engineering trade studies. Can we keep enough assets on orbit to cover all situations? Conversely, can we deploy any augmentation fast enough to matter? Can we deploy all the ground support equipment needed to make use of our space assets? What can we afford? Is there a way to get more capability for the same or less money? What are the priorities? Do we/can we sacrifice missions and reduce manning?

Recognizing the way the determinants interact is crucial, because doing so exposes what must be done to solve a problem. By way of illustration, consider the process of designing a satellite. If the design process begins with requirements that specify a certain satellite lifetime, those requirements will drive several design features such as the quality of parts, redundancy in the system, and the amount of fuel for orbit maintenance. These features, combined with the mission of the satellite, determine its weight and orbit, hence the launch vehicle required. If access to space is expensive, and the number of satellites being launched small, requirements and fiscal pressure will drive the designers to add additional capability to each satellite, thus increasing its complexity and weight. In extreme cases, this could force the satellite to be launched from a more capable (and expensive) launch vehicle. At this point, recognizing the amount of money being invested in this single system and the number of requirements it is intended to fulfill, designers will feel pressure to make it even more reliable and longer-lived. This means even higher quality, more redundancy, and so forth. Concurrently, recognizing that the system will be on orbit for many years, designers will need to build in additional performance margin. All of these activities lengthen the time needed to build, test, and deploy the satellite, and increase costs dramatically. The result is a stagnating development system, a dearth of successful new program starts, and a reliance on modifications to proven but often dated designs to keep costs under control. Unfortunately, this is very much the situation that the space research and development community finds itself in today. Figure 1 is a simplified illustration of how the interaction of real world determinants, through three linked cycles of design, performance, and lifetime raise costs, and how this in turn creates demands for more costly features.

 

Figure 1: Space System Cycles

 

The key to breaking the vicious cycles of space system acquisition and getting more capable satellites on orbit rapidly and affordably lies in understanding the nature and causes of this interaction. Because different types of space system architectures address requirements and take advantage of technology differently, evaluating those architectural approaches may produce some useful insights.

How do the determinants affect architectures?

Summarizing the determinants in a compact form produces Table 8 below.

Requirements

Technology

Budget

Global coverage

DOD ability to drive technology

In decline, especially for research, development, and acquisition

Early access

Increased emphasis on dual use

Need to reduce life cycle costs.

Pop-up crises

Microprocessor revolution

Can market forces be tapped?

Flexible, expandable capabilities

Command, control, and communications improvements

 

Rapid throughput

Miniaturization, structures, materials

 
 

Standardization and modularity, flexible manufacturing

 

Table 8: Space Architecture Determinants

If it were possible to represent these determinants and the elements and attributes of a space architecture mathematically, the matrix in Table 6 or 7 could be cross multiplied with the table above to produce a complete description of an architecture. Such precision is unlikely to be useful, though, in dealing with qualities that are difficult to estimate and often involve value judgments. A more subjective and qualitative approach is more likely to be useful.

Two questions need to be answered: what affect do the determinants have on specific elements of the architecture, and how does one apply the determinants to the attribute-element pairs of Table 6 or 7? To illustrate the process, two elements of a space architecture will be evaluated: the constellation and the launch vehicle. As should be clear from this and the following section, those elements provide a good representation of the differences between command and demand systems, though a complete picture is only possible if the other elements are incorporated.

Applying the Determinants

The first step is to take a simplified version of the matrix used for Tables 6 and 7 (reflecting only one element) and add columns for each of the determinants. Money figures both as an attribute (cost) and a determinant (budget). This is because it is both a characteristic of design choices (better parts cost more) and a sometimes (seemingly) arbitrary restriction imposed for non-technical reasons. The matrix is used to record qualitative implications (derived from observation) of each of the determinants in Table 8 for the each attribute of the selected element. A priority column reflects what was assigned in the previous section, and gives an idea of how to weight the implications when assembling an overall conclusion. At this level of course, without discussing a particular mission area, specific requirements can not be formulated (this is to be accomplished shortly). For now, the differences between command and demand-orientation can be illustrated relatively; i.e. the implications will relate to how the other approach would look rather than specific numbers.

Implications for a Command-Oriented Architecture

Keeping in mind the general principles of a command-oriented system—that efficiency or economy of force and therefore centralization are most important— the implications or features of the architecture for each element can be surmised. These are presented below for the satellite constellation and the launch vehicle. It’s important to remember that (as described above) the effects of various determinants are highly interactive throughout the architecture; where an implication is partly dependent on another element this analysis is explicit.

 

 

 

Priority

Implications – Constellation

 

Constel.

Requirements

Technology

Budget

Performance

l

Fewer, larger, more capable satellites

Mission-specialized, over-

designed, long lead times

Government the sole customer

Responsiveness

w

Adapt/exploit existing capability

Design to customer spec, leads to "stovepipes"

Add as many satellites as budget allows

Flexibility

w

Add multiple functions

Improve C3, distribution

More satellites?

Robustness

l

Emphasis on individual satellite survival

High mean time between failure, redundancy, best available at tech freeze

Hardening, counter-ASAT (anti-satellite) accidents?

Logistics

m

Pre-planned launch of spares/replacements

Each satellite unique

Limited incentive to improve

Reliability

l

Likely to need all satellites at all times

Redundancy on each satellite, high reliability parts

Plan for large ground C2 network

Ease of operations

m

Specialized operators needed

Focus on ground segment upgrades

Limited incentive to try new methods

Environmental

m

Boost higher or deorbit

Extra fuel

No money for nuclear

Cost

m

Emphasis on capability, regardless of price

Investment leading to better mission performance

Space segment a large portion of life cycle cost

Table 9: Constellation Implications, Command-Oriented Architecture

 

Priority

Implications – Launch Vehicle

 

Vehicle

Requirements

Technology

Budget

Performance

l

Driven by large satellite, orbit

Proven designs, upgrades to increase payload

Dual-use fine but government requirements primary

Responsiveness

m

Months of notice

Build on launch pad okay

Minimize infrastructure investment

Flexibility

m

Vehicle tailored to satellite

Limited use of standardization

Whatever is needed to get the job done

Robustness

m

None built-in, need to manage risk

Careful procedures, reduce risk

Better to accept delay cost than have one fail

Logistics

m

Whatever is needed

Proven techniques

Limited incentive to reduce

Reliability

l

Single loss catastrophic

Prefer proven systems

Unlikely to invest in new concepts

Ease of operations

m

Large numbers, contractors needed

Use specialized equipment to meet performance goal

Little incentive to invest in improvements

Environmental

m

Performance still key

Expendables, solid boosters acceptable

Only highly toxic additives insupportable

Cost

w

Need to buy small numbers of expensive vehicles

Refinements such as payload increases, but no radical change

Focus on reducing research, development, and acquisition cost

Table 10: Launch Vehicle Implications, Command-Oriented Architecture

A few points about the command-oriented architecture stand out. First, the architecture responds to real-world determinants by building relatively small numbers of highly capable and expensive systems. The space assets are replaced infrequently, and these factors lead to small numbers of launches of relatively high-performance vehicles. In the case of each element shown here, the need for reliability is ensured by building more capability and redundancy into the hardware and the procedures, a practice which achieves the goal but at significant cost. In turn, the cost of keeping the system working strongly affects the ability to invest in radical changes to hardware or operating procedures; these simply don’t have the priority to get funded. The result is a relatively slow evolution of capability, limited ability to exploit commercial developments, and ever-increasing operating costs.

Implications for a Demand-Oriented Architecture

As with the command-oriented architecture, demand orientation has overriding goals or principles: responsiveness and flexibility. To this end, the performance of any individual piece of the architecture is less important than overall capability, with implications as seen below.

 

Priority

Implications – Constellation

 

Constel.

Requirements

Technology

Budget

Performance

l

Emphasis on systemic versus satellite measures

Distributed architecture, use most recent technology

Because of the requirement for incorporation of

Responsiveness

l

Right product available quickly to all users

Tailored systems, rapid build and launch

multiple new technologies, need more RD&A money; this

Flexibility

l

Adapt to changing situation

Standardization, modularity, C3, on-board processing

is somewhat offset since many of the technologies are

Robustness

l

Proliferate, degrade gracefully

Autonomy, distribution, C3, on-board processing

being pursued commercially

Logistics

w

Augment and replenish

Standardization, modularity

 

Reliability

l

Backup/swing capability vice individual system

Redundancy, self-healing constellations

 

Ease of operations

w

More systems => need for standardized operations

Autonomy, C3, processing, expert systems

 

Environmental

m

Boost or deorbit

Extra fuel, short-life orbits

No money for nuclear

Cost

w

Trade off some capability for affordability

Technology investment requirements heavy, but dual-use a possibility

Table 11: Constellation Implications, Demand-Oriented Architecture

The assertion that a demand-oriented architecture will trade off some capability to save money may make some people uncomfortable; it sounds like the claims of the "military reformers" of the early 1980’s that our systems were too complex and expensive to work well. In fact, demand-oriented systems do not try to push the state of the art in technologies, but to take advantage of the most recent available technology and to get it operational faster. This still results in capable systems using advanced technology, but does not require deployment of a system to wait for programmed innovation.

 

Priority

Implications – Launch Vehicle

 

Vehicle

Requirements

Technology

Budget

Performance

w

Less payload needed

Aid rapid access to space

Need for investment in operability of launch systems;

Responsiveness

l

Launch on demand hours/days

Aircraft-like operations

requires a shift to a new kind of vehicle while keeping existing

Flexibility

l

Surge capability

Standard interfaces, reusable vehicles

capabilities working through a transition

Robustness

l

Multiple vehicles/launch sites

Ability to operate from multiple sites

 

Logistics

l

Minimize

Reduce special handling equipment

Reduce expenditures

Reliability

w

A figure of merit, not a hard and fast requirement

Only what is consistent with safety

Gradual approach; improve with practice

Ease of operations

l

No need for contractor support

Ability to operate with reduced support

Build on aircraft experience?

Environmental

w

More launches imply need to reduce impact

Reduce noise, toxins, waste

Avoid cleanup, legal restrictions

Cost

l

Bring down cost per pound to orbit drastically

Reusable vehicles, smaller payloads

Focus on reducing operations costs

Table 12: Launch Vehicle Implications, Demand-Oriented Architecture

As with the constellation, the need for new investment in launch vehicles appears to be a problem given the real-world budget determinants. One could argue, however, that the type of investments needed more closely parallel what is needed for the commercial space launch market and for emerging markets such as rapid surface-to-surface cargo delivery. In general, the demand-oriented system is better positioned to exploit technological advances as they occur and regardless of who has sponsored them.

It’s also interesting to note that the type of changes called for—improved operability, reduced cost per pound to orbit, more rapid response—would benefit any architecture, only the demand-oriented architecture requires them. In other words, in the command-oriented approach there is little or no incentive to invest in the new kinds of capabilities mentioned above. The type and number of space systems being deployed, the way in which the architecture responds to new requirements or unexpected events, and the underlying philosophy of what is important all determine the kind of support infrastructure, including launch.

One other point bears mentioning: that smaller payloads may be compatible with reduced cost per pound to orbit. This goes against conventional wisdom, since in any aerospace vehicle the greater the payload, the more the costs can be spread out. However, just as airlines don’t operate 747’s on every passenger route, there is a limit to economies of scale through size. First, the vehicle must be purchased, and large systems will cost more. This is compounded by the need to spread larger development costs over a (generally) smaller production run. In operations, if the airline can’t fill the large vehicle, it won’t get all of the benefit of that vehicle’s lower operating costs per pound of payload. Finally, in the case of space lift systems, "range" (which tends to favor large air vehicles) is not a factor; almost all of a launch vehicle’s energy is used to raise its speed. The benefits of large structures (like wings) are reduced because there is no "cruise" regime, and the penalties are increased (all the mass minus fuel must be accelerated to the final velocity). Although the trade-offs are complicated, the implication is that designing to a specific payload size is a poor way to build a space lift system. Maximizing operability and minimizing life cycle cost is the better way to go. If access is cheap enough, payloads will be redesigned to fit.

Narrowing the focus

The above examples are somewhat general and certainly not as rigorous as possible; to improve them requires additional detail. It may be possible to compare the performance of space architectures in detail across all mission areas at once, but that is beyond the scope of this study. Comparing the advantages and disadvantages of command versus demand systems for a single mission area, however, should both illustrate the process and provide some additional insights for the big picture.

 

ARCHITECTURAL COMPARISON FOR THE THEATER RECONNAISSANCE, SURVEILLANCE AND TARGET ACQUISITION MISSION

As presented to this point, the framework for architectural comparison does not say much about when command- or demand-oriented architectures are preferable. Adding a specific mission focus is the next step. This section will describe the general outlines of theater reconnaissance, surveilance and target acquisition (RSTA) requirements, show how these affect (or are affected by) the other determinants of technology and budget, and apply them to the elements and attributes of the competing space architectures. This will illustrate the method and produce some useful insights about architectural choices.

Why Examine Theater RSTA?

RSTA is an expansion of the traditional reconnaissance and surveillance missions. Theater RSTA is an essential part of space "support to the warfighter," that is support to the theater CINC or his forces. Although the emphasis on theater-level operations may change in the future, for now it serves as the basis for most force planning and strategy discussions. Theater RSTA is a good example, despite limitations on unclassified discussion, because it provides the full range of design responses—upgrades, diversions to different platforms, or architectural change—to shortcomings identified from operational experience. Further, it combines the significant issues relating to space architectures with a mission important enough to highlight the consequences of making poor space choices.

RSTA Mission Description

The theater RSTA mission involves providing the United States and the theater CINC(s) the awareness, flexibility, and information needed to respond to actual or potential crises. This ability must be available throughout all phases of an evolving situation, from pre-crisis indications and warning through hostilities, if unavoidable, to post-conflict monitoring. Theater RSTA includes a wide variety of specific tasks as determined by the forces involved and the information they require, and these tasks are not solely military (especially in those phases of the situation that do not involve armed conflict). Table 13 summarizes these issues conceptually as a prerequisite to determining mission requirements.

Phase

Function

Meaning/Tasks

Pre-crisis

Monitoring

Global basic awareness (framework system)

Emerging

crisis

Access

Quick reaction augmentation for theater of interest

- improved synoptic coverage

- gather additional detail; intelligence preparation of the battlefield -

limited warfighting capability if needed

War

Exploit the "high

ground"

Theater-level situational awareness

Timely location of enemy forces, description of their activity

Reduce effectiveness of camouflage, concealment, and deception

Detect and characterize "indicators," aid in identifying centers of

gravity

Find specific targets; report information to "shooters" "in time"

Augmentation as appropriate

Replenishment and/or reconstitution as needed

Post-crisis

Drawdown,

redeploy, but

maintain

awareness

Monitoring as necessary

- unobtrusive; non-invasive if appropriate

Deactivation/redeployment when no longer needed

- or replenishment and augmentation for continuing mission

 

Table 13: Theater RSTA Description

This table focuses on the specific contributions RSTA can make to the theater mission: to provide information, and to do so in a way that accommodates each phase of the crisis and can adapt to potential enemy action—hence the presence of such tasks as augmentation and reconstitution. It does not extend to derived capabilities such as deterrence based on the enemy’s knowing that their adversary is watching and can react. Nor should the table imply that only space forces can do the theater RSTA mission. A space system that does perform or support this mission, however, will have all the elements of the architecture already presented, though many of those elements will support other missions as well.

Questions for Architectural Comparison

Each part of the RSTA mission raises questions about the type of architecture needed. In the past, the desire of the United States to monitor and anticipate crises in "important" parts of the world, coupled with fiscal constraints has meant that some theaters were much better covered than others. Keeping in mind the generic requirements of the previous section, space planners must ask if the national security environment of the future will permit the United States to maintain the disparity between theaters, or if something like global situational awareness or "global presence" is needed. If the United States needs expanded capability, how can our RSTA forces achieve it, and what can we afford? Likewise, should the United States continue to place most space RSTA investment in systems that provide highly detailed coverage of relatively small areas of interest? At the same time, as precision weapons delivery capabilities improve, and the national leadership’s and American public’s desire for economy of force and lack of collateral damage demands ever more accurate target information, do RSTA systems not also need to provide more highly detailed information of more types than ever before? The goal of architectural comparison is to illustrate the trade-offs involved and suggest answers to these questions.

RSTA Mission Requirements

Examining Table 13 shows a need for a time-phased mix of presence, persistence, and access to respond to an emerging geopolitical crisis. By their nature, space systems will usually be the first ones "on the scene" and will provide the initial RSTA functions. Depending on the situation, US objectives, and the means available, we will then deploy additional capabilities to augment the RSTA architecture in the theater of interest.

A natural example of a RSTA mission is the detection, location, tracking, and targeting of theater ballistic missile launchers. Briefly, RSTA assets must be able to aid intelligence preparation of the battlefield by gathering information on bases, operating areas, order of battle, and so forth prior to any hostilities, keep this information updated as the crisis evolves, and determine the location of as many launchers as possible at all times and provide sufficient information for targeting. Once hostilities have begun, RSTA systems will need to locate as many missiles (and launchers) as possible before they can do any damage to friendly forces, keep track of their movements, and provide timely targeting updates to weapons platforms.

Qualitatively, a RSTA architecture will have to include the features listed in Table 14.

Quality

Requirements

Access

All parts of the theater, unrestricted by enemy defenses

Coverage

Wide area synoptic plus ability to focus on specific areas

Revisit time

Allowable gaps in coverage will depend on target; days for fixed sites with little

activity, hours or minutes for mobile forces

Spectra

Sufficient to penetrate weather, camouflage, and foliage, and to aid in target

discrimination and identification

Resolution

Consistent with requirements for target identification and status determination

Geolocation

Sufficient to cue other sensors, provide adequate target data to weapons

Information

dissemination

Ability to enough information of the right kind to all customers in a timely manner as

often as necessary

 

Table 14: Theater RSTA Qualitative Requirements

These requirements present three challenges to a theater RSTA architecture. The first concerns sensors. Some of the requirements are impossible for a single sensor to satisfy simultaneously: for example, the need for both wide area coverage and high resolution information. It is also impractical to put sensors that cover all the relevant spectra—spanning at least radar to infrared wavelengths—on a single platform. It may be impractical, depending on cost and employment constraints, to deploy some of the sensor types we ideally use in a given situation.

The second challenge is that the type, quantity, and timeliness of RSTA information needs vary considerably among customers. Aircrews planning missions will need the most current threat information for ingress, egress, and the target area, details on aimpoints, and sufficient information to acquire the target with on-board sensors and place a weapon "in the basket." Campaign planners will need detailed information on particular targets: hardness, extent, dispersal, and other physical characteristics, the targets’ use and interaction with other aspects of the enemy "system"; in general, any information which will help determine the importance of a target to the enemy’s war effort—and to achieving our campaign objectives—and its vulnerability to attack. Assembling enough information and performing this kind of analysis will take time, however, so planners can usually live with somewhat less reporting timeliness. In assessing effects, however, timing, timeliness, and detail are all important. Senior military leadership will want a broad overview of events in the theater so that they can try to judge if events are unfolding according to plan. Although to some extent this can be synthesized from the gathering of detailed information, that approach risks missing the forest for the trees. Policy-makers may want to use RSTA to look for indicators or "signals" of enemy intentions, thus they may need to examine in detail areas of little use to other RSTA customers. Finally, events may force a diversion of RSTA to address a task because of its political or strategic (as opposed to operational-military) import. All of these demands for information will have to be accommodated by a RSTA system.

The third challenge is an outgrowth of the first two: given the competing and sometimes conflicting demands for information, how does the architecture respond? Has the architecture been set up to accommodate all users? How can capabilities be augmented? Can national level capabilities be dedicated to a theater, and under what circumstances might they be recalled? Who "owns" theater RSTA assets? How can they be used most efficiently and effectively? Although the theater warfighter is intended to be the focus of theater RSTA, can the involvement of national-level agencies be avoided? These questions all come down to the issue of who sets priorities for use of limited assets, and on what they base those decisions. In establishing an architecture, how many requirements can be anticipated, and who is best at determining these: a central operator or the eventual customer?

Space systems will make a contribution to meeting the theater RSTA requirements. How they do this, what kind of capabilities they will have, and what other issues they raise will depend on the choice of architecture.

The Command-Oriented Approach to RSTA

The premise of a command-oriented space architecture is that the national level capabilities will provide the first reliable indications of a crisis. These capabilities will then be apportioned to some extent to support the theater, but the need to monitor other situations around the world will force compromises. Whatever support can be made available will be allocated by a central authority from a fixed pool of assets; as a rule, there would be no augmentation of space capabilities that hadn’t long since been planned.

If one were to design a space architecture to support theater RSTA requirements using this approach, the general outlines would appear as shown in Table 15.

 

Implications of RSTA Requirements

 

Space Segment

Ground Segment

Launch Segment

Performance

Emphasis on strategic needs,

tactical met as collateral function

High throughput; centralized tasking

Ensure that standing capabilities

are kept on orbit;

Responsiveness

Change orbits

Provide central direction to shift

assets

replenishments launched on

schedules determined years in

advance

Flexibility

A byproduct of built-in

overcapacity

Ability to produce multiple products

centrally; deploy some functions

forward

 

Robustness

Defend, harden

Defend, distribute

Keep CONUS sites operational

Logistics

Prepare to augment for a long

conflict

Deploy comm links, specialized

ground stations

Prepare to augment for a long

conflict

Reliability

Essential

Have skilled technicians to fix on-

orbit problems

Near 100% necessary

Ease of operations

Secondary to reliability

Deploy specialists

Secondary to reliability

 

Table 15: Command-Oriented Architecture for RSTA Requirements

The table above is divided by segment (see Table 4) for simplicity and to give an overall view of the architecture. Also, the last two attributes (environmental impact and cost) have been dropped for this illustration because they change little among mission areas. In general, the effects of applying the requirements of a specific mission are apparent at this level, though to see the effect on specific design choices would require a further breakout.

Technology and budget determinants, as illustrated previously, are to a large extent already included in the above table. Some of their key impacts on the command-oriented theater RSTA space architecture are: reliance on a relatively small number of large satellites, emphasis on ground-based versus on-board processing of information, and the channeling of information through central locations.

The command oriented architecture tends toward centralization for doctrinal and physical reasons. Small numbers of satellites mean there is little or no slack in the system to respond to a surge in demand, so a central clearinghouse for tasking is established. This central authority is distant from the theater, both physically and in terms of organizational hurdles, since it spends most of its time responding to national level requests for information.

Centralization also results from the hardware design. Development and production of a large and complex satellite takes years, and designers often cannot anticipate changes in technology with any certainty that it will be ready and reliable when their spacecraft is produced. Coupled with a lack of standard interfaces and operating systems on satellites, this makes it extremely difficult to insert the latest capabilities. The result is that the processing electronics on a spacecraft will be several generations behind what can be put in a ground station; consequently, designers tend to put minimal processing capability into the satellite. This results in high data rate downlink requirements, and in turn means that a ground station equipped to receive and process the signals must have significant hardware capability (often peculiar to the system) and highly trained personnel; neither of these is conducive to easy and rapid deployment to the theater.

The type of information disseminated is also affected by both doctrinal and budget concerns. Because the satellite provides data in only one form, the ground station must convert it into something useful. Again because of the high level of skill required to do this (and potentially because the product is subject to interpretation) the command-oriented system favors centralizing production, and working to assemble the kind of product each user says he or she needs. The disadvantage is that this takes some time, especially when data is coming in quickly and there are many requests for products. Further, it requires the end users to understand the system’s capabilities and limitations well in order to ask for the right product; this often means adapting the theater’s operating methods to fit the needs of what is supposed to be a supporting function.

Observations on the Command-Oriented Approach to RSTA

Command-oriented space RSTA systems will be best suited for detecting and responding to the concerns of their primary customers—national level authorities. They are capable of producing highly detailed and customized products, and centralized control should ensure that the space systems on orbit are used most efficiently but not overtasked. A command-oriented architecture, because it is intended to have virtually its full capability on orbit at all times, may provide the maximum available global coverage and situational awareness.

A command-oriented architecture, unless it is unconstrained by funding, will respond poorly to surges in demand, especially if those surges occur in parts of the world that do not have optimum coverage or call for sensors that are not deployed. In other words, the effectiveness of a command-oriented system depends on its designers’ ability to anticipate specific requirements. Command oriented systems will suffer from untimely information distribution, again especially at times of increased demand, and probably will use standardized products and request formats. These characteristics will result in a lack of flexibility and produce frustration among the ultimate customers.

Because the same systems serve all users, because the capabilities of the systems are determined by the most pressing national needs, and because the assets available are few, the products of a command-oriented space RSTA architecture will have to be carefully protected. Security is necessary to ensure that enemies, including those not engaged with us at the moment, do not learn so much about our capabilities that they can develop effective countermeasures. Unfortunately, these security requirements will restrict access to the information; allies and even many of our own troops may not have sufficient "need to know" to get access to the best information available.

Finally, a command-oriented architecture gives the theater CINC little if any control over space assets. This does reduce the decision-making burden on the CINC’s staff, but it also leaves open to the possibility that support from the space systems will not be provided when it is needed most.

Two further observations are necessary. The characteristics of a command-oriented theater RSTA space architecture as described above are nearly identical to the characteristics of our current space RSTA systems. One example of this is in the area of flexibility. The Defense Support Program (DSP) early warning satellite, although not intended to support theater warfighting, took advantage of certain built-in capabilities in excess of what was needed for its strategic warning mission to cue other sensors and weapons in a limited way during the Gulf War. It’s also apparent that the disadvantages of a command-oriented space architecture are very close to the commonly perceived disadvantages of space systems in general, as discussed previously. A comparison with a demand-oriented approach should help answer the question if these are in fact generic to space systems.

Responses to the Command-Oriented Approach to RSTA Shortfalls

As discussed, there are three ways of responding to a shortfall in capability: by improving or upgrading existing assets, by diverting missions allocated to one type of system to another one, or by using the same types of systems but in a different architectural framework. All three have merits, and the first two are being vigorously pursued to enhance our theater RSTA capabilities. Architectural change, which has received less attention, may offer the greatest long term payoff in providing better space RSTA.

Upgrades or improvements to the current United States RSTA architecture involve speeding up processing times, making more information on system capabilities and limitations available to users in the field, pushing more information to the field, to include changing rules on classification, producing better data fusion, working to eliminate system-specific equipment and provide common terminals and ground stations, and reducing the number of barriers between theater users and those who actually control the systems. Fundamentally, though, the architecture remains the same. Assets are still centrally controlled, and the improvements are a matter of degree, not qualitative differences.

For example, the Custom Product Network allows users at forward locations to create custom imagery "products," for example mosaics of pictures. This does provide additional flexibility to the users, who can enhance their intelligence preparation of the battlefield, but it is still limited to material that has been archived or is being sent forward. It also raises the question of whether a mosaic picture of the battlefield in which each piece might have been taken at a different time or by different sensors is sufficiently accurate; for some applications it may be, for others not. In other words, while a step forward, this sort of solution is only a partial answer.

Another category of solutions is diversion. In the case of theater RSTA, this means using airborne sensors to cover the gaps that perhaps are too difficult for space sensors to fill. Airborne sensors also offer many advantages, such as the ability to loiter over a particular area for hours or even longer. By employing unmanned vehicles, reducing payload (and hence vehicle) sizes, and employing low observable features, such platforms can even provide coverage over otherwise denied areas, thus incorporating some of the advantages of space systems.

Aerial vehicles also have drawbacks, however. They require fairly regular launch and recovery operations, and because they are limited to atmospheric speeds they will have to be based in theater or fairly close to avoid lengthy transits and the sacrifice of loiter time. These considerations mean aerial vehicles will have a considerable logistics tail, much of which will have to be deployed into theater. Not only does this add to the number of things that are high priority for immediate delivery, but it could complicate the basing and scheduling of other aircraft. Finally, aerial vehicles must still deal with the overflight issue; even though the probability of detection may be low, it will require a political decision to take the risk of overflying sensitive territory during a crisis.

Aerial vehicles do offer tremendous possibilities, however. In some cases, they may be the only way to get close enough to a target to obtain precisely the right kind and quality of information. The best solution to the theater RSTA problem will undoubtedly incorporate aerial vehicles, but should they necessarily address all the disadvantages of a command-oriented system?

Before discussing the demand-oriented architectural approach to theater RSTA, there is one other avenue to improve today’s capabilities deserving mention. This might be called a hybrid of diversion and architectural change, since it involves using systems that are not under our direct control to augment our capabilities. For example, the French SPOT imaging satellite, and the LANDSAT multispectral sensing satellite, provide useful products which we have incorporated into our databases in the past. One might argue that in the future, as the market for earth observation products grows, the theater CINC could have a variety of commercial sources from which to obtain information. This idea also has merit, but with several caveats. First, depending on the political situation, the availability of those products to us, our allies, and our adversary are questionable. Second, the timeliness of the information is far from ideal. Third, the data may arrive in a format incompatible with the rest of the theater RSTA architecture, requiring additional processing and further delays. All of these concerns indicate that although commercial augmentation may be a valuable addition to RSTA capabilities, it may not be one to rely on in a time of crisis.

The Demand-Oriented Approach to RSTA

The main premise of this architecture is that those responsible for the theater, aided by national capabilities, will have the first indications of a crisis and be able to identify additional RSTA needs. A truly demand-oriented system will then respond by surging and augmenting capability, to include deploying additional space assets tailored to the situation in terms of orbit and mission payload.

Summarizing as for the command-oriented architecture:

 

Implications of RSTA Requirements

 

Space Segment

Ground Segment

Launch Segment

Performance

Emphasis on operational-level

needs,

Information on demand to any user

Ability to surge number of

launches

Responsiveness

Additional capability available

in days

Tasking at low operational level

Orbit satellites within hours of

need

Flexibility

Add new satellite types;

autonomous platforms

Interoperable with all RSTA assets

Deploy different satellites to

different orbits

Robustness

Proliferation; replace and

reconstitute as needed

Proliferation of equipment

Operate from multiple sites

Logistics

Reduce number of unique parts

Minimize unique equipment

Reusable (or cheap expendable)

vehicles

Reliability

High for functions; lower for

individual satellites

On par with other

computers/electronics

High for function, not individual

vehicle

Ease of operations

Access and control easy for

users

Standardized equip and procedures

Rapid turn times

Table 16: Demand-Oriented Architecture for RSTA Requirements

In an extreme form, a demand-oriented architecture would have a minimum essential capability in place for worldwide strategic monitoring. On identification of a crisis in a region, the theater CINC would activate a plan to augment space RSTA capabilities in terms of coverage type and amount as appropriate. These augmenting assets would be tailored to the theater’s needs and would be tasked directly by theater forces. Because these RSTA capabilities would not be at the national level, the security requirements would be less stringent and the information distribution correspondingly broader. The space systems themselves would primarily be small, relatively short-lived systems so it would neither be a major commitment of resources to deploy them nor a significant setback if one failed to work. This in turn implies an extremely responsive space lift capability, one that can surge to place potentially dozens of satellites in orbit over a few days, and then sustain a launch rate to augment or replace satellites as needed. For crises of indefinite duration or for a world in which the need to augment capabilities occurs on a regular basis, a reusable launch system offers clear advantages over expendable ones—if it provides access often and inexpensively enough.

Observations on the Demand-Oriented Approach to RSTA

This sort of architecture offers clear advantages to the theater CINC in terms of responsiveness to tasking and the ability to tailor the coverage to the situation. Because of the proliferation of satellites, it offers the ability to get close to continuous observation of the theater from space. In a future situation in which an enemy could threaten some or all aspects of our space architecture, the demand-oriented approach is clearly more robust than a command-oriented one: it presents the enemy with a proliferated and distributed target set both in space and on earth. Each of the targets is relatively small and insignificant in itself, and there are no critical nodes that will cause the whole system to cease functioning. Because of proliferation, the architecture is also less vulnerable to accident or natural disaster.

On the other hand, the distributed architecture will have a less capable initial configuration than the command-oriented system, and augmenting it will take a finite amount of time. Also, because of the smaller size of the spacecraft, there are missions they will not perform as well as the satellites of a command-oriented architecture. Perhaps most critically, the demand-oriented architecture requires a satellite building and launching capability that the United States does not currently possess, but which is not unattainable.

Assembling a Workable Theater RSTA Architecture

Satisfying theater RSTA requirements takes more capability than any one class of solution can bring to the table. The above discussion explains how our current, command-oriented space architecture cannot meet all the requirements, and that each of the potential enhancements to the current system have drawbacks making them unlikely to solve the problems alone. Because the eventual solution will take the form of a hybrid architecture, there will be many challenges to ensuring the entire network of systems is interoperable in terms of communications, ground stations, databases, geographic coordinate references and so forth. Recognizing our current shortfalls, and with the impetus of the Gulf War, there are numerous initiatives underway to do this and to make the best use of the considerable assets we have.

The class of solution that has received the least attention to date however, is the potential to build a space architecture that both takes advantage of the unique characteristics of space and provides the theater user the control and responsiveness he or she needs—in other words, a demand-oriented architecture. This type of solution offers considerable potential, but will require work in both technological and doctrinal areas. By helping to identify the key issues, a framework for architectural comparison may advance the process.

UTILITY OF A FRAMEWORK FOR COMPARING ARCHITECTURES

Previous sections have built and elaborated on a framework for describing and comparing space architectures. This section will answer some of the questions raised in the process and consolidate observations in four areas. First, the distinguishing characteristics of the command- and demand-oriented approaches are reviewed. Second, these characteristics are used to define which perceived disadvantages of space are inherent and which are a result of design choices. Third, the key efforts needed to overcome those design disadvantages are identified, and finally, the contribution that having a framework makes to this process is discussed.

Distinctions between Command- and Demand-Oriented Architectures

Command and demand oriented architectures can be distinguished by physical, temporal, and philosophical differences. The physical ones are the most obvious: satellite size, satellite numbers, and launch vehicle size and type. Command oriented architectures will tend to have fewer, larger, and more complex space systems. Those systems will individually be more capable than those of a demand-oriented system. Space lift will be an infrequent activity that is scheduled far in advance and optimized to lift the maximum weight into orbit per launch. In demand-oriented systems, satellites might be built to perform a specific mission, and would be more likely to use off the shelf components than custom-designed ones. Although less complex overall, demand-oriented satellites will be "smarter;" more of the navigation, system management, communication and information processing capabilities will be on orbit than in a demand-oriented architecture. Information from a satellite is more likely to be broadcast or directly downlinked to end users than in the command-oriented system.

The temporal differences are of two types. First, systems for the command-oriented architecture will take longer to design, build, and deploy. Technology will be inserted more slowly than in a demand-oriented system, and satellites will be designed to last longer. Demand-oriented satellites could be built on short notice and for relatively short (months instead of years) duration missions. The second type of difference is in the response of the system to new situations. A demand oriented architecture can be reconfigured rapidly and is designed from the beginning to provide the fastest possible response to its users. The command-oriented architecture changes slowly, if at all, in response to changing situations on the ground, and tends to sacrifice timeliness of information for precision.

Underlying the physical and temporal difference are the philosophical or doctrinal ones. In a command-oriented system, efficiency and economy of force are the driving principles, which lead to centralization both of command and control and of information distribution. In a command-oriented architecture, the designers assume that a central authority not only has the greatest ability to control tasking and distribution, but also has the best idea of what the priorities are. In contrast, a demand-oriented architecture is built around the principles of flexibility and responsiveness, under the assumption that the end users of a system’s product are best able to determine priorities and control tasking. Both control and dissemination of information (or execution) are distributed and decentralized, leading to a more robust but somewhat anarchical and inefficient system.

Command-oriented architectures are inherently better suited to missions having long term and reasonably predictable requirements. Demand-oriented architectures in contrast are best suited to those missions that are unpredictable, may involve sudden changes in the capabilities needed, and could conceivably be of short duration. A command-oriented architecture emphasizes efficiency by making best use of assets in place, but this requires excellent long-range planning. A demand-oriented architecture relies on the ability to react and adapt quickly to new situations, even if this means accepting less than optimum use of assets. Paradoxically, for unpredictable situations, the demand-oriented architecture may be the most efficient one: by allowing rapid changes in capability it prevents the architecture from having to be overdesigned in the first place, and by providing a more rapid and tailored response it may preempt the need for a larger or longer term commitment.

The Inherent Disadvantages of Space

Recalling the list of perceived space disadvantages from Table 2:

• Distance

• Predictability of movement (to the enemy)

• Poor continuity, meaning

-- lack of dwell time (a low earth orbiting satellite has a point on the ground in view

for only about 10 minutes out of every orbit)

-- gaps in revisit time (the ability to have a specific mission capability over a specific

point on the earth with sufficient frequency)

• Poor responsiveness

-- (strategic) to crises the systems were not designed for

-- (operational) to theater requirements

• Inflexibility for retasking

• Unsatisfactory timeliness/distribution of information

• Vulnerability to attack or natural disaster

• Need to operate in a harsh environment

• Cost

Are there any lessons from the foregoing architectural comparisons about which of these are inherent and which are design dependent?

Distance is an intrinsic disadvantage. There are some missions for which proximity is needed, and to be in "space" a platform must be in a sustainable orbit, generally accepted as at least 93 miles above the surface of the earth. As a result, these are the closest approaches a space system can make. Other practical concerns may push this minimum higher, but to keep things in perspective, our airborne systems will sometimes have to operate at similar ranges from the target in order to see deep with reasonable security, and have to look through more air in the process. The other aspect of this drawback is that this distance is vertical; combined with the high speeds needed to achieve orbit, a large increase in kinetic and potential energy is needed to enter the environment from earth. As a result we have not yet been able to deploy space systems as routinely and inexpensively as we would like.

Predictability is also inherent in orbital systems, but with significant caveats. First, orbital mechanics is not deterministic; knowing a satellite’s location precisely requires frequent observations. Unless the satellite is in a synchronous orbit of some sort, orbital perturbations will change its path from what has been predicted in a relatively short period of time. This phenomenon is compounded if the satellite has the ability to perform even small maneuvers (especially if out of sight of enemy sensors). With the addition of decoys, a satellite could leave even relatively sophisticated adversaries uncertain as to the actual time that they were being overflown. Maneuvers do cost fuel, which in turn shortens the life of the satellite, but this could be overcome either by deliberately designing the rest of the satellite to last a short time (and thus saving money) or possibly by refueling the satellite on orbit. In other words, although maneuver of an orbiting body is difficult, relatively small maneuvers can have substantial effects. The disadvantages of predictability can largely be overcome.

Continuity is clearly a function of design, and usually becomes an issue because of cost constraints. If we could build enough satellites cheaply, and if launching them and maintaining them in orbit was affordable, there is no physical reason why space systems could not provide continuous coverage over any part or all of the globe. We do this now with GPS (24 satellites), and the Iridium (66 satellites) and Teledesic (approximately 800 satellites) communications constellations will also do it from much lower orbits. The problem is that in lowering the altitude to overcome the distance problem the number of satellites needed rises considerably, which complicates the cost and command and control issues. Use of advanced technologies such as standardization and modularity, flexible manufacturing, and autonomous spacecraft operations make the problems manageable, however, these approaches clearly fit more closely into a demand-oriented architecture.

Responsiveness and flexibility are strongly architecture, dependent. An architecture that can be tailored to an emerging situation on the ground would provide good strategic flexibility, and one that can be rapidly augmented to provide additional capabilities will fulfill the needs of operational users. A command-oriented system by its nature is ill-suited to these kind of adjustments, however, and our lack of a responsive spacelift capability makes the problem worse. Even if we had a launch on demand type system, however, a command-oriented architecture would not be flexible and responsive. This is due to the long lead times for satellite building, the requirement that they last a long time, the cost of each satellite, and our operating procedures that put most of the maintenance and control functions on the ground, and thus require large numbers of "operators."

Less obvious, but equally important, is the fact that the architectural philosophy strongly influences the responsiveness of spacelift systems. Although it is clearly desirable to be able to launch satellites rapidly, a command-oriented architecture may in fact hinder the development of rapidly responsive launch capabilities. Since the command-oriented architecture is ill-suited to take advantage of these capabilities it provides little incentive to justify the development costs of a revolutionary kind of space access which we only have requirements to use a few times a year.

Timeliness also is a function of design. Even a command-oriented system, given sufficient motivation, can push information through its bottlenecks quickly on occasion. By removing the chokepoints of centralized processing and control, a demand-oriented system can get respond rapidly to almost any request.

Vulnerability, whether to enemy action or to mishap, can also be greatly reduced by design. Clearly the more systems there are on orbit, the "smarter" those systems are, the more pathways available for information transmission, the more launch sites, and the more ground sites capable of tasking the satellites the less chance there is that loss of any one component will seriously affect the system. Because this is the case, each component in turn can be designed and tested to less stringent specifications, which will make the cost of proliferating systems more bearable.

The need to operate in a harsh environment is an inherent feature of space systems. But what is the answer to this problem? Long life in our systems is seen as a plus, but this seems to tackle an environmental disadvantage head on. It also adds to the cost and technological backwardness of our spacecraft by increasing their weight and complexity and thus lengthening the time needed to design, build, test, and deploy them. Much cheaper systems could operate perfectly well for more limited periods, so that in the long run responsiveness could be improved at no greater cost. This disadvantage of space shows that alternative architectural approaches can mitigate even inherent limitations of the operating environment.

Cost is a drawback for space systems, but it may not be an insurmountable barrier. Cost is driven by many things, but two stand out: the satellite itself, and the cost of access. Many of our current satellites are indeed extremely expensive, but so are aircraft carriers and B-2 bombers. Just as not all ships and aircraft are as expensive as those premier systems, neither are all satellites. In fact, by taking advantage of new technologies and methods as described throughout this study, individual satellites could be produced relatively inexpensively. As for launch, the combination of demand for responsiveness, robustness, and low operating costs with the potential of improved design and construction capabilities could finally provide the incentive to pay the up front costs of developing a radically improved space lift system. There will always be a price to pay for having an advanced capability, but it need not be exorbitant.

From the discussion above, the intrinsic disadvantages of space systems appear to be distance and harsh environment. The rest are essentially a function of two things: the design choices made in developing the space architecture, and the difficulty (cost and slowness) of access to space—which is also related to architectural design choices. Even the intrinsic disadvantages of space are no worse than the intrinsic disadvantages of air or the ocean in the sense that properly designed systems will always be needed to exploit the environment.

The Key Factors Needed to Overcome Design-Driven Disadvantages

The features of a demand-oriented architecture enable space system designers to make better use of rapidly evolving technology. At the same time, that technology may make some of the features of a demand-oriented architecture possible. For example, by taking advantage of a standardized and modular spacecraft design, to include operating system software, future military space operators could draw from a stock of subsystems and essentially "bolt" together a satellite in a few hours. Since the design and interfaces would be standardized, a minimum amount of testing would be needed before the system was deployed. Using an advanced internal architecture, the basic components could be assembled to support several different missions. Sensor or other mission payload packages could likewise be designed to fit the standard interfaces.

Taking advantage of assembling the satellite shortly before launch and the flexibility of its design, operators could incorporate the latest in processor and storage technology. Not only would this produce better performance on orbit, it would cut down on the stockpiles of parts that would have to be continually maintained. With improved on-orbit performance, satellites can do more for themselves, including autonomously navigating, maneuvering, and monitoring their own health and status. Except for emergency situations, the amount of ground support needed to "fly" the satellite can be reduced to almost zero, making the additional support costs of proliferated constellations small. The additional processing capability would also allow the satellites to provide different kinds of products directly to the users, for example doing on-board target detection processing and cueing other sensors or combat forces with target type and location. At the same time the satellite could pass a full image of an area, already annotated with detected targets, to theater headquarters for correlation with other sources, and unprocessed raw data to a central location for evaluation of the satellite’s performance. This has the potential to make RSTA systems much more decentralized and available to multiple users.

An architectural approach resulting in a proliferation of autonomous and potentially maneuvering satellites on orbit and increasing transits of space is bound to strain our existing ability to monitor activity in space itself. At some point, we will need to deploy an enhanced space surveillance capability than can adapt to this new environment. This will probably include space-based sensors and a new concept of space traffic control.

Technology trends seem to favor the demand-oriented approach. As more and more advanced capabilities become part of the commercial sector, particularly in electronics and software but also in materials, design and manufacturing, our national security space architecture will be challenged to adopt the capabilities ever more rapidly. In many cases, the technological advantage among military forces will go not to the country that can develop the best technologies, but the one that can best exploit new technologies regardless of the source. In a similar vein, technological advantage is becoming more perishable, and we may be ill-advised to lock ourselves into a specific technology for 20 years. The key to exploiting the trends in technology is to change our design philosophy to one that not only accepts early obsolescence but actively plans for it. This will undoubtedly prove uncomfortable to some (as it does to any personal computer buyer who finds a better system on the market for less money a month later), but it is also the key to adapting to a rapidly changing environment and to making swift progress, thus staying ahead of rivals.

Inevitably, the concept of a demand-oriented architecture will depend on the performance and cost-effectiveness of small satellites, sometimes called "lightsats," since only by reducing size, weight, and complexity are space systems likely to be built rapidly and affordably. Lightsats have numerous critics as well as advocates. Because of progress in miniaturizing components and subsystems, there is substantial reason to believe that performance goals can be achieved, especially if those performance goals are realistic; that is, based on what we need from satellites rather than what we’d like to have. A more debatable proposition is whether satellites can ever be cheap enough to be routinely considered for short duration (three to six months) or special purpose missions.

Taking advantage of commercially-available equipment and relatively large production runs, and using smaller, more modular spacecraft, would dramatically reduce the cost of each satellite. This would be of little use, however, if launch costs were not also dramatically decreased. The preceding sections should make it clear that rapid, affordable spacelift is a critical issue, if not the center of gravity, in moving toward the advantages of a demand-oriented space architecture. Advocates of improved space capability for the United States should make the development of greatly improved spacelift an overriding priority.

How Does an Architectural Comparison Framework Help?

The Department of Defense has recognized the need for a coordinated approach to developing future space capabilities and has designated a deputy defense undersecretary for space acquisition and technology programs. Building on this concept, the Air Force has proposed seven strategies to improve the space capabilities of the United States. Both actions imply a recognition that future space capabilities must be considered in a holistic sense. Addressing problems or pursuing opportunities in just one area—satellite size, launch systems, command and control, or operational concepts, for example—at best leads to suboptimization and at worst leads to poor conclusions by assuming away key issues or ignoring interdependencies. To avoid this pitfall, some method of describing what a space architecture is and how its components interact is needed.

The framework for architectural comparison presented in this paper is a foundation for thinking about the real differences between alternative approaches to designing space systems. With considerable expansion, it could serve as the basis for quantitative comparisons between different architectural designs. At this point, however, its main value is in providing some qualitative boundaries to the debate and helping to frame questions about both space system hardware and the underlying operational philosophy or doctrine. By highlighting the nature and extent of the differences between command and demand orientation, their respective advantages and disadvantages, and the relationship of the architectural features to real-world determinants, the framework also opens the way to discussion of what doctrinal or physical changes are desirable in future space systems.

 

SUMMARY AND IMPLICATIONS

This study has explored the possibility of using the concepts of command and demand orientation to describe not only the way information might flow in a space system, but to encompass the nature of the entire space architecture, to include hardware, facilities, and operational procedures. To give this expanded definition of command and demand orientation meaning, the study presented a framework for describing and ultimately comparing space architectures in terms of their physical elements, operational and other attributes, and the real world factors determining how an architecture will look and perform.

This approach appears to have some utility. Although the distinctions that the study draws between command and demand-oriented architectures are largely qualitative, they are real and unambiguous. Command orientation manifests itself in a centralized system with extensive ground control, a relatively small and fixed number of large, highly capable on-orbit assets, and a spacelift capability driven by reliability and the need to launch on schedule. In contrast, a demand-oriented architecture will be decentralized and distributed with more processing and even control functions in orbit, a relatively large number of smaller satellites that can be augmented in a short period of time, and an emphasis on system-wide (constellation) performance as opposed to the performance of an individual satellite. Demand-oriented systems, unlike command-oriented systems, favor satellites that can be built quickly and affordably using the latest off the shelf technology. Demand-oriented architectures will tend to allow more users, and at a lower organizational level, to communicate directly with the satellites, and will delegate authority to task space systems to the operational level. The spacelift capability required by a demand-oriented architecture must be responsive and able to surge to augment on-orbit capabilities.

An architecture with demand-oriented characteristics also appears to be the only viable alternative if in the future an enemy contests our right to use space freely. The demand-oriented approach is inherently more robust, able to absorb damage, and able to respond with augmented or replenishment capability. A command-oriented architecture, because of the centralization and the criticality of each asset, is less robust in the face of attack or mishap. Although the concept of wars extending to space is not yet widely accepted, space superiority has not yet become an issue in a conflict, and at present the threat seems minimal in both a strategic and tactical sense—as did the threat of aircraft to surface ships before World War II—this is an issue that space planners should not ignore.

The contrast between command and demand-oriented architectures reveals that many of the disadvantages traditionally associated with space systems—among them predictability, inability to provide continuous coverage, and poor responsiveness and flexibility—are more a function of architecture design characteristics than the inherent limitations of the environment. With the right approach to space system design we can and should achieve much more in space than we have come to expect. On the other hand, failure to separate fundamental or intrinsic limitations from those imposed by design choices can lead to less overall capability by producing faulty assumptions.

It should come as no surprise that the current US national security space architecture is predominantly command-oriented, with the associated advantages and disadvantages. Since this is the only space architecture that most space planners are familiar with, it is also unsurprising that many think of those advantages and disadvantages as intrinsic to space systems. Furthermore, the United States’ tremendous investment in existing systems and the undeniably superb capabilities of those systems encourage the development of incremental improvements rather than wholesale changes in equipment or concepts of operations.

Although this situation has valid historical and technical roots, changes over the past several years in the geopolitical environment have reshaped basic assumptions about requirements and budgets. Budgetary reality means that the United States cannot respond to additional needs by deploying more of the existing kind of systems; it’s simply not affordable. Emerging requirements clearly point to the need for a more demand-oriented architecture, at least to augment the command-oriented "backbone" in times of crisis, if not to provide the bulk of the space support to regional or theater CINCs. Providing a fundamentally different architecture is the best way to be responsive to the needs of the theater warfighters, to convince those warfighters that space assets will always be there when needed, and to encourage full use of the advantages of space.

Demand-oriented architectures require not only the development of new procedures, but the exploitation of new technology. Technological trends—in computing power, structures, materials, and design techniques such as standardized interfaces and modular construction—enable a break from the vicious cycle of increasing cost and complexity that space systems are now in and allow the deployment more modern systems more rapidly. Harnessing the capabilities in those technologies will make smaller, less expensive, but still highly capable space systems possible. The same trends also make it imperative that we assess our current doctrine and practices, since failure to recognize and adapt to a changing environment could allow an enemy to leap ahead of us in capability.

To take advantage of the potential of demand-oriented systems, some obstacles must be overcome. These obstacles are two-fold. First, planners are saddled with outdated assumptions about what space systems can and should do. The United States lacks a coherent strategy for controlling and exploiting space that could help shape military doctrine and direct system development efforts. Second, the ability to change the nature of our space architecture depends heavily on creating a much more responsive and inexpensive spacelift capability. Unfortunately, the nature of the current national security space architecture does not produce sufficient incentives to develop that new type of spacelift.

The United States needs to move toward more rapid exploitation of technological opportunities vice comprehensive, dedicated leading edge development. We need to make this process routine so that we can adapt more rapidly when hit with surprises or opportunities. Since it’s impossible to anticipate everything, we must build flexibility into our future space assets—but at the architectural level, not by creating heroically capable individual systems. Perhaps the ultimate test of a space architecture is whether it encourages or retards this flexibility.

Recognizing that the United States cannot—and should not—completely abandon the type of space systems that have served it well for over thirty years, there are still some useful steps to be taken. Strategy and doctrine for decentralized space operations keyed to supporting the theater CINCs should be developed from a clean sheet of paper, with no preconceptions as to what is possible. A detailed analysis of the potential for demand-oriented systems to respond to requirements and technological opportunities in several mission areas should be conducted. Development of a spacelift system that provides rapid, reliable, and inexpensive access to space must be given the highest priority, with the payload such a system carries treated as a measure of merit, not specified in a requirement. To demonstrate the possibilities of new types of space systems, DOD should promote a design-to-cost competition for small satellites to perform various missions, and should encourage the development of modular designs and standard interfaces. If such steps are taken in parallel—and it is important to recognize that strategy, doctrine, technology, cost goals, and perhaps above all the ability to get useful payloads into orbit as quickly and as often as the strategy demands, are linked—the next few years could see the emergence of a new space architecture.

Fundamentally, the choice of an architectural approach in developing future space systems matters. We first need to recognize that there are viable alternative approaches. To understand the nature and implications of those alternatives, we need a common basis for discussion and comparison. The framework presented in this study is a first step in that direction.

In the words of General of the Air Force Hap Arnold in 1945:

National safety would be endangered by an Air Force whose doctrines and techniques are tied solely on the equipment and process of the moment. Present equipment is but a step in progress, and any Air Force which does not keep its doctrines ahead of its equipment, and its vision far into the future, can only delude the nation into a false sense of security"

The words are as relevant for space forces as they have been for the Air Force, and as applicable today as ever.

 

 

This work was accomplished in partial fulfillment of the Masters Degree requirements of the School of Advanced Airpower Studies, Air University, Maxwell AFB, AL, 1996.

Advisor: Lt Col Robert Owen, Ph.D.

Reader: Dr James Corum