Space Systems Architecture
Lecture 3
Introduction to
Tradespace Exploration
Hugh McManus
Metis Design
Space Systems, Policy, and Architecture Research Consortium
A joint venture of MIT, Stanford, Caltech & the Naval War College
for the NRO
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
1
Tradespace Exploration
• A process for understanding complex solutions to
complex problems
• Allows informed “upfront” decisions and planning
Most relevant to processes
in these phases
Concept
Development
System-Level
Design
Phases of Product Development
Space Systems, Policy, and Architecture Research Consortium
Detail
Design
Testing and
Refinement
Production
Ramp-Up
From Ulrich & Eppinger, Product Design and
Development, 1995
©2002 Massachusetts Institute of Technology
2
1
Architecture Trade Space Exploration
A process for understanding complex solutions to complex problems
• Model-based high-level assessment of system capability
• Ideally, many architectures assessed
• Avoids optimized point solutions that will not support
evolution in environment or user needs
• Provides a basis to explore technical and policy uncertainties
• Provides a way to assess the value of potential capabilities
Allows informed “upfront” decisions and planning
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
3
Integrated Concurrent Engineering
A process creating preliminary designs very fast
• State-of-the-art rapid preliminary design method
• Design tools linked both electronically and by co-located
humans
• Design sessions iterate/converge designs in hours
• Requires ready tools, well poised requirements
Allows rapid reality check on chosen architectures
Aids transition to detailed design
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
4
2
Emerging Capability
• Linked method for progressing from vague user needs to
conceptual/preliminary design very quickly
• MANY architectures, several/many designs considered
• Understanding the trades allows selection of robust and
adaptable concepts, consideration of policy, risk.
MATE
Architecture
Evaluation
User
Needs
ICE
Conceptual
Design
Robust
Adaptable
Concepts
Months, not Years
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
5
What is an Architecture Trade Space?
X-TOS
• Small low-altitude
science mission
Km
km
DESIGN VARIABLES: The architectural
trade parameters
•
Orbital Parameters
–
–
–
•
Apogee altitude (km)
Perigee altitude (km)
Orbit inclination
Each point is
a specific
architecture
150-1100
150-1100
0, 30, 60, 90
Physical Spacecraft Parameters
–
–
–
–
–
Antenna gain
communication architecture
propulsion type
power type
delta_v
Total Lifecycle Cost
($M2002)
Assessment of the utility and cost of a large
Number
ofofArchitectures
Explored:
50488
Number
Architectures
Explored:
50488
space
of possible
system
architectures
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
6
3
Developing A Trade Space
Attributes
Mission
Concept
•
•
•
•
•
•
Define Design
Vector
Understand the
Mission
Create a list of
“Attributes”
Interview the
Customer
Create Utility Curves
Develop the design
vector and system
model
Evaluate the potential
Architectures
Develop System
Model
Calculate
Utility
Estimate
Cost
Architecture
Trade Space
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
7
XTOS Tradespace Development
Concept
• Small low-altitude science
mission
• Known instruments
Attributes
•
•
•
•
•
Data Life Span
Data Collection Altitude(s)
Diversity of Latitude(s)
Time Spent at Equator
Data Latency
Design Vector
1
• Number of Vehicles and
Mission Design
• Apogee Altitude
• Perigee Altitude
• Orbit Inclination
• Antenna Gain
• Communications Architecture
• Propulsion Type
• Power Type
• Manuever Delta-V Capability
Define Utility
0.9
0.8
Utility
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
150
350
550
750
950
Data Collection Altitude (km)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
8
4
Continued
•
•
•
System Model
Orbit Calculations (STK)
Spacecraft Estimations (SMAD)
Launch Module
Calculate Utility
•
Estimate Cost
Multi-Attribute Utility Theory
•
SMAD/NASA mode
50488 Architectures Explored
Pareto front of “best”
architectures
Each point is a
specific architecture
Total Lifecycle Cost
($M2002)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
9
Understanding What Systems Do
•
•
•
•
Transmit Information
Collect Information
Move Mass (inc. People)
Others (Space Station…)
[Beichman et al, 1999]
Space Systems, Policy, and Architecture Research Consortium
Martin 2000
© 2002 Massachusetts Institute of Technology
10
5
Understanding who cares Stakeholders
• Many interested parties in a complex system
• Each “customer” has a set of needs
• They are different, and can be contradictory
Customer
Acquirers
End Users Consumers
Partners
Shareholders
Enterprise
Employees
Suppliers
Corporation
Society
Unions
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
11
Concept Selection: Bounding
ATOS:
Multi-vehicle
Ionosphere
Explorer
In Situ
Topside Sounding
Direct Scintillation Sensing
GPS
GPS Occultation
Space Systems, Policy, and Architecture Research Consortium
UV Sensing
©2002 Massachusetts Institute of Technology
12
6
Scoping
Spacecraft
Instrument
A-TOS
scope
Ionosphere
Raw, commutated, uncalibrated data
Control
Center
Decommutated, calibrated instrument data
Hanscom Model
“Scientist”
User Set
Physics Model
Instrument -> Local Ionosphere
Ionospheric characteristics
Database
Global Ionospheric Model
Current State
Other
Data Sources
(Various assets)
“Space Weather”
User Set
Global Ionospheric Model
Predict Future State
User-Specific
System Integration
“Knowledgeable”
User Set
Go/No-Go “green light”
“Warfighter”
User Set
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
13
Attributes
• “what the decision makers need to
consider”
• ( and/or what the user truly cares about)
• Examples: Billable minutes =
GINA metrics
• TPF Pictures =
camera performance metrics
• Rescue/move satellites =
mass moving, grappling capability,
timeliness
[Beichman et al, 1999]
– Could have sub-cartoons for above
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
14
7
XTOS Attributes
(1)
1) Data Life Span
2) Data Altitude
3) Maximum Latitude
4) Time Spent at Equator
5) Data Latency
(3)
(2)
DATA
2004
km
2005
(4)
Km
(5)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
15
Utilities
• “What the attributes are WORTH to the decision
makers”
• Single Attribute utility maps attribute to utility
• Multi-attribute utility maps an architecture (as
expressed by its attributes) to utility
0
1
Single Attribute
Utility function
Attribute
Space Systems, Policy, and Architecture Research Consortium
Good ->
Good ->
1
0
Multi-Attribute
Utility analysis
Expense
©2002 Massachusetts Institute of Technology
16
8
Single Attribute Utilities
1
0.9
0.8
Utility
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
150
350
550
750
950
Data Collection Altitude (km)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
17
Multi-Attribute Utility
Single Attribute Utility Curve for Data
Point Altitude
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
150
350
550
Altitude (km)
750
950
N
Weight Factors of each Attribute
(k values)
KU ( X ) + 1 = ’ (KkiU ( X i ) + 1)
i =1
0.45
0.4
0.35
0.3
Utility
0.25
0.2
0.15
0.1
0.05
0
Lifespan
Latitude
Latency
Equator
Time
Altitude
Total Lifecycle Cost ($M 2002)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
18
9
XTOS Design Vector
• “Parameters of the Trade Space”
Variable:
Orbital Parameters:
•Apogee altitude (200 to 2000 km)
•Perigee altitude (150 to 350 km)
•Orbit inclination (0 to 90 degrees)
Physical Spacecraft Parameters:
•Antenna gain (low/high)
•Comm Architechture (TDRSS/AFSCN)
•Propulsion type (Hall / Chemical)
•Power type (fuel / solar)
•Total DV capability (200 to 1000 m/s)
Space Systems, Policy, and Architecture Research Consortium
First Order Effect:
Lifetime, Altitude
Lifetime, Altitude
Lifetime, Altitude
Latitude Range
Time at Equator
Latency
Latency
Lifetime
Lifetime
Lifetime
©2002 Massachusetts Institute of Technology
19
ATOS design Vector
• Geometry of the Multi-vehicle Swarm
Swarm Orbit Parameters
Number of spacecraft in swarm
Geometry of swarm
Mothership/ no
mothership
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
20
10
Attributes
Data Lifespan
Sample Altitude
Diversity of Latitudes
Time at Equator
Latency
Total
Cost
Total w/Cost
9
9
9
6
0
0
0
6
9
9
9
0
0
0
0
0
0
9
0
0
0
0
9
0
0
0
9
0
6
0
0
9
0
0
0
9
3
3
0
0
3
9
9
6
3
21 27
9
6 21
9
9 12 39
9
9
3
6
6
3
6
6
9
30 36 12 12 27 12 15 18 48
Total Impact
Power system
Mission Scenario
Ant. Gain
Inclination
Comm System
Propulsion
Apogee
Delta-V
Perigee
Design Vars
Scoping-QFDs
Identify key
interactions
for modeling
48
27
18
24
36
Sums identify attributes and Design Variables
that are likely to be (or not be) distinguishers
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
21
Scoping-Iteration/evolution
TABLE II. EVOLUTION OF DESIGN VECTOR
First Cut
10/20/00
Swarm type
# sats/swarm
# swarms
Swarm orbit
Intra-swarm orbit
Instrument type
# instruments/sat
TT&C scheme
Ground station
Mission lifetime
Processing scheme
Position control scheme
Latitude of interest
Space Systems, Policy, and Architecture Research Consortium
After GINA exercise
10/31/00
Concept type
# sats/swarm
# swarms per plane
# orbital planes
Swarm altitude
Swarm orientation
Swarm geometry
Separation within swarm
Mothership (yes/no)
After utility
characterization and
module progress
1/15/01
Swarm perigee altitude
Swarm apogee altitude
# sats/swarm
# subplanes/swarm
# suborbits/subplane
Yaw angle of subplanes
Max sat separation
Mothership (yes/no)
Schedule Crunch
1/21/01
Swarm perigee altitude
Swarm apogee altitude
# sats/swarm
# subplanes/swarm
# suborbits/subplane
Yaw angle of subplanes
Max sat separation
©2002 Massachusetts Institute of Technology
22
11
Mapping Design Vector to Attributes
and Utilities - Simulation Models
XTOS Simulation Software Flow Chart
Orbits
All variations
on design
vector
Spacecraft
Mission
Scenario
Satellite
database
Launch
Cost (lifecycle)
Output
Mission scenarios with
acceptable satellites
Utility
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
23
Techsat Models
Inputs (Design Vector)
# S/C per Cluster
MATLAB Models
….
Constellation
Radar
# Clusters
Key Outputs
….
Constellation Altitude
S/C Bus
Payload
Launch &
Operations
System
Analysis
Aperture Diameter
Lifecycle Cost
Availability
Probability of
Detection
Revisit Rate
Resolution & MDV
….
Antenna Power
100
90
80
70
60
50
40
30
20
10
0
1
2
3
4
5
6
7
8
9
10
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
24
12
Exploring the Tradespace
Cadillac
Many good architectures
at c. $0.5M/Image
Each point is an
evaluated architecture
$2M/Image
2200
$0.55M/Image
1350
2000
1800
$0.5M/Image
1300
1600
$0.5M/Image
1400
1200
True Optimal
Solution
1250
$0.45M/Image
1200
1000
800
0
Zoom in of the TPF System Trade Space
1400
$1M/Image
Lifecycle Cost ($millions)
Lifecycle Cost ($millions)
TPF System Trade Space
2400
$0.25M/Image
500 1000 1500 2000 2500 3000 3500 4000
Performance (total # of images)
Taguchi
Solution
1150
2300
2400
$0.4M/Image
2500 2600 2700 2800 2900
Performance (total # of images)
3000
TPF: a science
imaging system
Chevy
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
25
The Pareto Front
• Set of “best” solutions
• “Dominated” solutions are more expensive or less
capable
)
M
$
( 2200
Utility (images)
t
s 2000
o
C
1800
TPF System Trade Space Pareto-Optimal Front
Dominated Solutions
Non-Dominated Solutions
$1M/Image
$2M/Image
e
l 1600
c
y
c 1400
e
f
i 1200
L
$0.5M/Image
1000
$0.25M/Image
800
0
500
1000
1500
2000
2500
3000
3500
4000
Performance (total # of images)
Cost ($M)
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
26
13
Optimization
• Can look for the Pareto front using advanced
optimization techniques
)
s
n
o
i
l
l
i
m 1600
$
(
1500
t
s 1400
o
C 1300
Pareto Front
Multi-Objective SA Exploration of the TPF Trade Space
Current Solution Path
Pareto-Optimal Set
$1M/Image
$2M/Image
e
l 1200
c
y 1100
c
e 1000
f
i
L 900
$0.5M/Image
800
$0.25M/Image
700
0
500
1000
1500
2000
Performance (total # images
2500
3000
Space Systems, Policy, and Architecture Research Consortium
©2002 Massachusetts Institute of Technology
27
Using the Trade Space to Evaluate
Point Designs
TPF
• Terrestrial Planet
Finder - a large
astronomy system
• Design space:
Apertures
separated or
connected, 2-D/3D, sizes, orbits
• Images vs. cost
Designs from traditional process
From Jilla, 2002
Space Systems, Policy, and Architecture Research Consortium
[Beichman et al, 1999]
©2002 Massachusetts Institute of Technology
28
14