e-PrintsComparing 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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