MIT Industry Systems Study

MIT Industry Systems Study

Communications Satellite Constellations

Engineering Systems Learning Center (ESLC)

Massachusetts Institute of Technology

Unit 2

“Architectural Design Space Exploration”

Version 1.1, October 20, 2003

Abstract

When designing complex systems, like satellite constellations, particular attention must be paid to the chosen architecture. Unit 1 discussed the architecture of Iridium and Globalstar, the two “big” low Earth orbit (LEO) constellations, which were actually deployed in 1997-2000. Each of these systems represents only one of thousands of potential architectures that could have been chosen by the original designers at Motorola and Loral, respectively. Therefore, this unit introduces the notion of design space exploration, which allows understanding the position of a particular architecture in the larger technical and economic context. A computer simulation captures the important elements of the satellite constellation design problem. In this process, high level design decisions such as the orbital altitude of the constellation or the transmitter power aboard the satellites are mapped to system performance, lifecycle cost and capacity. Iridium and Globalstar are used to benchmark the simulation. The focus is on trading off lifecycle cost (LCC) versus system capacity, while holding the communications performance per channel constant. Those architectures that are non-dominated and approximate the Pareto frontier are of particular interest. Sensitivity analysis is used to identify which design variables are major system drivers. The associated problem set exercises the system simulation and asks you to critically interpret the results.

Learning Objectives

After completing this unit you should be able to:

1. Explain why it is important to thoroughly explore the design space of a complex Engineering System, before committing to a particular architecture.
2. Exercise the simulation for LEO satellite constellations by changing design variables, underlying assumptions and executing the software. This includes benchmarking against known systems, as well as exploring a large, combinatorial design space.
3. Setup a framework for similar Engineering Systems by decomposing the design problem into computational modules and reintegrating them into an overall system simulation.
4. Carefully interpret the simulation results in the context of Iridium, Globalstar and the material presented in unit 1.
5. Extract the set of non-dominated architectures, which approximate the Pareto front.

Disclaimer Statement: The material in this industry systems study was created for educational purposes only. In no way do the statements made in this study express official positions of the Massachusetts Institute of Technology. The material may not be used for any purpose other than classroom or distance learning instruction. Copyright © 2003 M.I.T.- Engineering Systems Learning Center.

Author Information: Prof. Olivier de Weck (), Room 33-410, Darren Chang () , Massachusetts Institute of Technology, 77 Massachusetts Ave, Cambridge, MA 02139, USA

Materials

Unit Material

-  Unit 2: Lecture slides (unit2_lecture.ppt)

-  Unit 2: “Architectural Design Space Exploration” (unit2_summary.htm)

-  Unit 2: Matlab simulation code (cs2.zip)

-  Unit 2: PC executable simulation code (cs2.exe)

-  Unit 2: Overview of variables used in simulation (cs2.xls)

Reference Material

-  de Weck, O. L. and Chang D., ”Architecture Trade Methodology for LEO Personal Communication Systems “, 20th International Communications Satellite Systems Conference, Paper No. AIAA-2002-1866, Montréal, Québec, Canada, May 12-15, 2002

-  Chang D. and de Weck O., ”Basic Capacity Calculation Methods and Benchmarking for MF-TDMA and MF-CDMA Communication Satellites”, Paper AIAA-2003-2277, 21st International Communications Satellite Systems Conference, Yokohama, Japan, 15-19 April, 2003

-  A list of additional references (some with URL links) is contained in the back of this document.

Time required: Approximately 3 hours preparation, 1.5 hours in class, 3 hours homework.

Table of Contents

Abstract 1

Learning Objectives 1

Materials 2

Table of Contents 2

Historical Background 3

Concept of LEO Satellite Constellations (The Technical Case) 4

Communications Satellite Economics 101 (The Business Case) 8

Iridium System 14

Globalstar System 19

Successes and Failures 22

Summary 26

References and Endnotes 26

Introduction

The purpose of this unit is to present a comprehensive methodology for conducting system architecture trades for LEO communication satellite constellations using quantitative metrics. The design space of such systems is explored using a computer simulation over a range of options, including orbital altitude, constellation type, satellite transmitter power and system design lifetime, among others. These quantities all represent important design decisions that must be made during conceptual design, i.e. during the “architecting” phase of a complex development project. Each combination of decisions determines system capacity (total data flow throughout system lifetime and simultaneous users supported by the system), net present lifecycle cost (development, manufacture, test, launch and operations) for a fixed voice channel communications quality. This unit shows that both Iridium and Globalstar are point designs and merely represent discrete choices that were made within the design space. From this trade space you will identify and analyze the Pareto-optimal subset with respect to system capacity and lifecycle cost.

Purpose and Approach

Purpose of the computer simulation

A LEO communications satellite constellation is a complex Engineering System whose background knowledge resides in multiple fields including spacecraft and launch vehicle design, communications theory, cost analysis, etc. Where should we start to understand this complex system?

Putting ourselves in the shoes of the original system designers, there is a vector of design variables x that we can determine at the early stage of design as well as a vector of constants, c. The values of x can be changed within certain bounds, while the entries of c are assumed to be fixed. There are also vectors of policy constraints, p, imposed by regulatory bodies like the FCC, and a vector of design requirements, r, imposed by the customers of the service. For a complex system, how can designers predict how well the design will achieve certain objectives, J, based on known system metrics? Such a performance prediction capability is especially important to researchers who need to study a large number of different designs collectively. Every possible system cannot be designed in detail, but one may want to be able to predict the objective vector J, at least approximately, from the design vector x, the constant vector c, the policy vector p, and the requirements vector r. To achieve such prediction capability, a computer-based simulation that re-produces the behavior of real-world designs in a computer environment must be developed first. Thus, the simulation performs a mapping from decision space to objective space:

(1)

Can one believe the results produced by such a simulation? To benchmark the fidelity of the simulation, a vector of (mainly intermediate) benchmarking variables, B, is also generated for comparison with real systems. This comparison will give an idea of how well the simulation reproduces reality.

System Architecture Evaluation Framework

With a simulation framework in place, the problem of architectural design space exploration becomes relatively straightforward. The following six steps have been proposed by de Weck and Chang in solving the problem.

1.  Choose the elements and bounds of the architectural design vector x, constant vector c, policy vector p, requirement vector r, objective vector J, and benchmarking vector B.

2.  Build the mapping matrix, subdivide the problem into modules and define the interfaces.

3.  Model technological-physical, economic and policy relationships, implement the individual modules and test them in isolation from each other. Then integrate the modules into an overall simulation.

4.  Benchmark the simulation against reference systems. Tune and refine the simulation as necessary (Loop A).

5.  Conduct a systematic trade space exploration using design-of-experiments (DOE) or optimization search algorithms.

6.  Post-processing of the Pareto optimal set including sensitivity and uncertainty analysis. Extract a subset of Pareto optimal architectures that are non-dominated for further study. If no acceptable architecture is found, the design space needs to be modified (Loop B).

Figure 1 shows a block diagram of the proposed architectural design space exploration methodology. Other researchers such as Jilla and Miller[1] or Ross and Hastings[2] have suggested similar architecture exploration frameworks, whereby the main differences are to be found in how multiple objectives in J are combined together, or what role is ascribed to system optimization.

Figure 1. Architectural design space exploration methodology

Computer Simulation

While the proposed framework is applicable to many classes of complex systems, we now turn our attention to LEO communication satellite constellations. In this section we go through the first four steps of the methodology. This begins by clearly defining the input and output vectors of the simulation, and ends with benchmarking the simulation against the two actual LEO systems of unit 1: Iridium and Globalstar.

Input (design, constant, policy, and requirement) vectors and output (objective and benchmarking) vector definition (step 1)

Figure 2 shows the vector of design variables x, constants c, policy constraints p, performance requirements r, objectives J, and the benchmarking vector B.

Figure 2. Input-output mapping of LEO communication satellite constellation simulation

For any Engineering System one may ask the following question early during conceptual design: “What are the most important, high-level technical decisions that need to be made?” The answers to this question are good candidates for inclusion in the design vector, x. The design vector x for our satellite constellation design problem embodies the architectural design decisions and is subject to the bounds or discrete choices shown in Table 1.

Symbol / Variable / xLB / xUB / Unit
c / constellation type / Polar / Walker / [-]
h / altitude / 500 / 1500 / [km]
εmin / min elevation / 5 / 35 / [deg]
div / diversity / 1 / 4 / [-]
Pt / sat transmit pwr / 200 / 2000 / [W]
Gt dB / sat antenna edge cell spot beam gain / 5 / 30 / [dBi]
ISL / inter sat links / 1 / 0 / [-]
MAS / multiple access scheme / MF-TDMA / MF-CDMA / [-]
Tsat / sat lifetime / 5 / 15 / [years]

Table 1. Design variable definition, x

The constant vector, c, contains technical parameters that are assumed constant throughout the design space exploration process. They are assumed constant either because they are determined by existing technologies, or because their variation will not affect the relative “goodness” of one design vis-à-vis another. But nevertheless, these parameters are needed to complete some calculations during the simulation. The values of the constants, c, are listed in Table 2.

Symbol / Constant / Value / Unit
AKM / apogee kick motor type / 2 (3-axis-stablized) / [-]
AKMIsp / apogee kick motor specific impulse / 290 / [s]
StationIsp / station keeping specific impulse / 230 / [s]
MS / modulation scheme / QPSK / [-]
ROF / Nyquist filter rolloff factor / 0.26 / [-]
CS / cluster size / 12 / [-]
NUIF / neighboring user interference factor / 1.36 / [-]
Rc / convolutional coding code rate / ¾ / [-]
K / convolutional coding constraint length / 6 / [-]
RISL / intersatellite link data rate / 12.5 / [MB/s]
Ge dB / gain of user terminal antenna / 0 / [dBi]
Pe / user terminal power / 0.57 / [W]
D / discount rate / 15 / [%]
IDT / initial development time / 5 / [years]

Table 2. Constants definition, c

The policy vector, p, contains only the bounds of the frequency bands assigned by FCC. Their values for Iridium and Globalstar are listed in Table 3 and 4, respectively.[3] This is where other policy decisions, such as restrictions on the placement of gateways or the use of foreign launch vehicles could be included.

Symbol / Policy constraints / pLB / pUB / Unit
FBup / Uplink frequency bandwidth / 1621.35 / 1626.50 / MHz
FBdown / Downlink frequency bandwidth / 1621.35 / 1626.5 / MHz

Table 3. Iridium (and full-factorial runs) policy constraints definition

Symbol / Policy constraints / pLB / pUB / Unit
FBup / Uplink frequency bandwidth / 1610.00 / 1626.50 / MHz
FBdown / Downlink frequency bandwidth / 2483.50 / 2500.00 / MHz

Table 4. Globalstar policy constraints definition

The technical requirement for LEO communication satellite constellations is defined as providing satisfactory voice communications quality for all individual channels of the system. Although the services provided by Iridium and Globalstar include telephony, facsimile, modem, and paging, voice telephony is the major service and has proven to be the one that is most difficult to satisfy. So, providing a reasonable voice communications quality is the dominant requirement. As shown by the Iridium and Globalstar case, in order to provide the minimum acceptable voice quality, the requirements vector, r, includes the bit error rate (BER), data rate per user channel (Ruser), and link margin (Margin). These are dependent upon the choice of the design variables: multiple access scheme (MAS) and diversity (div) as shown in Table 5.

Design variables / Requirements
Multiple access scheme / Diversity / Bit error rate (BER) [-] / Data rate per user channel (Ruser) [kbps] / Link margin (Margin) [dB]
MF-TDMA / 1 → 2 / 1e-3 / 4.6 / 16
2 → 3 / 1e-3 / 4.6 / 10
3 → 4 / 1e-3 / 4.6 / 4
MF-CDMA / 1 → 2 / 1e-2 / 2.4 / 12
2 → 3 / 1e-2 / 2.4 / 6
3 → 4 / 1e-2 / 2.4 / 3

Table 5. Requirements vector definition, r

The objective vector J captures all the metrics by which the “goodness” of a particular architecture can be evaluated. The objective vector contains the total lifetime data flow that represents the total communication traffic (throughput) throughout the lifetime of the system, the number of simultaneous users the system can support, the life-cycle cost that we have already discussed in unit 1, the number of expected subscribers per year, the total air time, and the cost per function (CPF). Cost per function here is defined as the life-cycle cost divided by the total lifetime data flow. All the objectives are defined in Table 6.

Symbol / Objectives / Unit
Rlifetime / total lifetime data flow (integrated) / [GB]
Nusers / number of simultaneous users / [-]
LCC / life-cycle cost / [B$]
Nyear / number of subscribers per year / [-]
Ttotal / total airtime / [min]
CPF / cost per function / [$/MB]

Table 6. Objectives definition, J

The benchmarking vector contains technical specifications that emerge from the design process. If the simulation uses the same design vector, x, as a real system, then comparing the benchmarking vector of the simulation with the real system will show how well the simulation reproduces the system. The closer the simulation is to the real system, the higher the fidelity of the simulation is. Table 7 shows the technical specifications contained in the benchmarking vector, B. Some of these variables are also in the objective vector, J.