Upload
others
View
10
Download
0
Embed Size (px)
Citation preview
Responsive Systems Comparison Method: Dynamic Insights into Designing a Satellite
Radar System
Adam M. Ross, Hugh L. McManus, Donna H. Rhodes, Daniel E. Hastings, and Andrew Long
September 16, 2009
Track 43 MIL-4: Systems of Systems Analysis for NSS: Answer the Why question
AIAA Space 2009
seari.mit.edu © 2009 Massachusetts Institute of Technology 2
Outline
• Motivation• Review of Responsive Systems
Comparison Method (RSC)• Design Tradespace Evaluation• Multi-Epoch Analysis• Discussion
seari.mit.edu © 2009 Massachusetts Institute of Technology 3
Motivation
• System designers and architects often face changes in…– User needs– Available technologies– Political and technical contexts
• Classical “scenario analysis” can be too opportunistic, qualitative, or sparse
• Lack of value-centric approaches results in point designs with questionable value delivery to stakeholders
• Structured method needed to characterize, analyze, and represent a wide variety of possible futures to identify “value robust” designs
Note: This paper is a “part 2” of last year’s AIAA Space paper*This paper presents the application of Responsive Systems Comparison (RSC) Method through “Multi-Epoch Analysis”
*Ross, A.M., McManus, H.L., Long, A., Richards, M.G., Rhodes, D.H., and Hastings, D.E., "Responsive Systems Comparison Method: Case Study in Assessing Future Designs in the Presence of Change," AIAA Space 2008, San Diego, CA, September 2008.
seari.mit.edu © 2009 Massachusetts Institute of Technology 4
The RSC Method
RSC consists of seven processes:1. Value-Driving Context Definition2. Value-Driven Design Formulation3. Epoch Characterization4. Design Tradespace Evaluation5. Multi-Epoch Analysis6. Era Construction7. Lifecycle Path Analysis
• Processes consist of discrete set of activities
• Some feedback between processes is possible
• Some processes can occur in parallel to save time
Using Multi-Attribute Tradespace Exploration, Epoch-Era Analysis, and other approaches, a coherent set of processes were developed into the RSC method
Focus of talk
seari.mit.edu © 2009 Massachusetts Institute of Technology 5
Case Application: Satellite Radar System (SRS)
Critical issue in national security space– Unique all-weather surveillance capability– Opportunity for impact given ongoing studies– Rich multi-dimensional tradespace
Unit-of-analysis: SR architecture– Radar payload– Constellation of satellites– Communications network
To assess potential satellite radar system architectures for providing the United States Military a global, all-weather, on-demand capability to image
static, and track moving, ground targets; supporting tactical military operations; and maximizing cost-effectiveness across many possible futures
Case Application Goal: (CBO 2007)
24 hour, all weather on-demand “Visibility and Tracking”over things that can be observed
In order to develop RSC, a test case was selected with requisite complexity…
Satellite Radar System (SRS) Value Proposition:
seari.mit.edu © 2009 Massachusetts Institute of Technology 6
Satellite Radar SystemProgram Manager
comptroller
Nation
SI&E
SRS Enterprise Boundary
Capital(non‐fungible assets)
Capital(non‐fungible assets)
National Security Strategy/PolicyNational Security Strategy/Policy
Resources(fungible assets)
Resources(fungible assets)
RadarProductRadarProduct
DNI
NGAJ2
Military
USD(I)
ExtendedSRS
Enterprise
SRS Context
OMBCongress
Which SRS Architecture?
R&DR&D Comm/GrndComm/Grnd
Infra‐
Struct.
Process 1: Value-Driving Context Definition
Evaluation Perspective: Given distributions of future uncertainties, how does Satellite Radar Program Manager select the “best” architecture?
DoD/IC stakeholderschanging tasking priorities
Dynamic threat environment
Funding instability
Uncertain technology availabilityUncertain ground/relay infrastructure
How does one account for exogenous uncertainties?
– Policy– Funding– Infrastructure– Environment
Enterprise boundary helps to define “context”
A “Satellite Radar Program Manager” is chosen as a “supra-decision maker” who
must represent all interests in order to have
a successful program
seari.mit.edu © 2009 Massachusetts Institute of Technology 7
None, long-lead, sparesConstellation OptionYes, NoTugable1x, 2x, 4x base fuelManeuver CapabilityYes, NoTactical Communication AbleRelay, Direct downlinkCommunication Downlink8 Walker IDsConstellation Configuration800, 1200, 1500 [km]AltitudeMechanical, AESAAntenna Type10, 40, 100, 200 [m2]Physical Antenna Area0.5, 1, 2 [GHz]Radar Bandwidth1.5, 10, 20 [kW]Peak Transmit Power
Definition RangeVariable Name
None, long-lead, sparesConstellation OptionYes, NoTugable1x, 2x, 4x base fuelManeuver CapabilityYes, NoTactical Communication AbleRelay, Direct downlinkCommunication Downlink8 Walker IDsConstellation Configuration800, 1200, 1500 [km]AltitudeMechanical, AESAAntenna Type10, 40, 100, 200 [m2]Physical Antenna Area0.5, 1, 2 [GHz]Radar Bandwidth1.5, 10, 20 [kW]Peak Transmit Power
Definition RangeVariable Name
DES
IGN
VAR
IAB
LES
Process 2: Value-Driven Design Formulation
Design-Value Mapping (DVM) ensures design decisions drive value delivery
Design-space:Designer-controlled parameters
that define a system concept
Value-space: Concept-neutral evaluation criteria specified
by decision makers
Design-Value Mapping (DVM): Ensures alignment between
Value-space and Design-space
Peak Transmit Power 1.5 10 20 [KW] 9 9 9 3 1 1 9 9 9 0 1 9 9 9 9 96Radar Bandwidth .5 1 2 [GHz] 9 9 3 3 1 1 9 9 9 0 1 3 3 3 3 66Physical Antenna Area 10 40 100 200 [m^2] 9 9 9 3 1 1 9 9 9 1 1 9 9 9 9 97Antenna Type Mechanical vs. AESA 9 9 9 3 3 1 9 9 9 1 1 9 9 9 9 99Satellite Altitude 800 1200 1500 [km] 9 9 3 9 9 3 9 9 9 9 3 1 1 1 1 85Constellation Type 8 Walker IDs 0 0 1 9 9 3 0 0 3 9 3 9 9 9 9 73Comm. Downlink Relay vs. Downlink 0 0 0 0 0 9 0 0 0 0 9 9 9 3 9 48Tactical Downlink Yes vs. No 0 0 0 0 3 9 0 0 0 0 9 9 9 3 9 51Maneuver Package 1x, 2x, 4x 1 1 1 1 1 0 1 1 1 1 0 9 3 3 3 27Constellation Option none, long-lead, spare 0 0 0 0 0 0 0 0 0 0 0 9 9 9 9 36
Bas
elin
e Sch
edule
Act
ual
Sch
edule
(Era
)
To
tal
Imp
act
Tracking Imaging
Min
. D
isce
rnab
le V
eloci
ty
Num
ber
of
Tar
get
Box
es
Tar
get
ID
Tim
e
Tar
get
Tra
ck L
ife
Tra
ckin
g L
aten
cy
Mission
ATTRIBUTES
ScheduleProgrammaticsCost
Definition RangeVariable Name Min
imum
Tar
get
RC
S
DE
SIG
N V
AR
IAB
LE
S
Bas
elin
e Cost
Act
ual
Cost
s (E
ra)
Imag
ing L
aten
cy
Res
olution (
Pro
xy)
Tar
get
s per
Pas
s
Fiel
d o
f R
egar
d
Rev
isit F
requen
cy
Attribute Name units range (U=0 to U=1)Minimum Target RCS m^2 1000 --> 0Min. Discernable Velocity m/s 50 --> 5Number of Target Boxes # 1 --> 10Target Acquisition Time min 120 --> 10Target Track Life min 0 --> 60Tracking Latency min 240 --> 0Resolution m 5 --> 0.01Targets per Pass # 1 --> 10^5Field of Regard km^2 1000 --> 10^6Revisit interval min 300 --> 10Imaging Latency min 720 --> 60Geo-Location Accuracy m 500 --> 50
Baseline Cost $BDeviation from Cost %Baseline Schedule yearsDeviation from Schedule years
Tra
ckin
gPr
ogra
mIm
agin
g
ATT
RIB
UTE
S
seari.mit.edu © 2009 Massachusetts Institute of Technology 8
None, long-lead, sparesConstellation OptionYes, NoTugable1x, 2x, 4x base fuelManeuver CapabilityYes, NoTactical Communication AbleRelay, Direct downlinkCommunication Downlink8 Walker IDsConstellation Configuration800, 1200, 1500 [km]AltitudeMechanical, AESAAntenna Type10, 40, 100, 200 [m2]Physical Antenna Area0.5, 1, 2 [GHz]Radar Bandwidth1.5, 10, 20 [kW]Peak Transmit Power
Definition RangeVariable Name
None, long-lead, sparesConstellation OptionYes, NoTugable1x, 2x, 4x base fuelManeuver CapabilityYes, NoTactical Communication AbleRelay, Direct downlinkCommunication Downlink8 Walker IDsConstellation Configuration800, 1200, 1500 [km]AltitudeMechanical, AESAAntenna Type10, 40, 100, 200 [m2]Physical Antenna Area0.5, 1, 2 [GHz]Radar Bandwidth1.5, 10, 20 [kW]Peak Transmit Power
Definition RangeVariable Name
DES
IGN
VAR
IAB
LES
Process 2: Value-Driven Design Formulation
Design-Value Mapping (DVM) ensures design decisions drive value delivery
Design-space:Designer-controlled parameters
that define a system concept
Value-space: Concept-neutral evaluation criteria specified
by decision makers
Design-Value Mapping (DVM): Ensures alignment between
Value-space and Design-space
Peak Transmit Power 1.5 10 20 [KW] 9 9 9 3 1 1 9 9 9 0 1 9 9 9 9 96Radar Bandwidth .5 1 2 [GHz] 9 9 3 3 1 1 9 9 9 0 1 3 3 3 3 66Physical Antenna Area 10 40 100 200 [m^2] 9 9 9 3 1 1 9 9 9 1 1 9 9 9 9 97Antenna Type Mechanical vs. AESA 9 9 9 3 3 1 9 9 9 1 1 9 9 9 9 99Satellite Altitude 800 1200 1500 [km] 9 9 3 9 9 3 9 9 9 9 3 1 1 1 1 85Constellation Type 8 Walker IDs 0 0 1 9 9 3 0 0 3 9 3 9 9 9 9 73Comm. Downlink Relay vs. Downlink 0 0 0 0 0 9 0 0 0 0 9 9 9 3 9 48Tactical Downlink Yes vs. No 0 0 0 0 3 9 0 0 0 0 9 9 9 3 9 51Maneuver Package 1x, 2x, 4x 1 1 1 1 1 0 1 1 1 1 0 9 3 3 3 27Constellation Option none, long-lead, spare 0 0 0 0 0 0 0 0 0 0 0 9 9 9 9 36
Bas
elin
e Sch
edule
Act
ual
Sch
edule
(Era
)
To
tal
Imp
act
Tracking Imaging
Min
. D
isce
rnab
le V
eloci
ty
Num
ber
of
Tar
get
Box
es
Tar
get
ID
Tim
e
Tar
get
Tra
ck L
ife
Tra
ckin
g L
aten
cy
Mission
ATTRIBUTES
ScheduleProgrammaticsCost
Definition RangeVariable Name Min
imum
Tar
get
RC
S
DE
SIG
N V
AR
IAB
LE
S
Bas
elin
e Cost
Act
ual
Cost
s (E
ra)
Imag
ing L
aten
cy
Res
olution (
Pro
xy)
Tar
get
s per
Pas
s
Fiel
d o
f R
egar
d
Rev
isit F
requen
cy
Attribute Name units range (U=0 to U=1)Minimum Target RCS m^2 1000 --> 0Min. Discernable Velocity m/s 50 --> 5Number of Target Boxes # 1 --> 10Target Acquisition Time min 120 --> 10Target Track Life min 0 --> 60Tracking Latency min 240 --> 0Resolution m 5 --> 0.01Targets per Pass # 1 --> 10^5Field of Regard km^2 1000 --> 10^6Revisit interval min 300 --> 10Imaging Latency min 720 --> 60Geo-Location Accuracy m 500 --> 50
Baseline Cost $BDeviation from Cost %Baseline Schedule yearsDeviation from Schedule years
Tra
ckin
gPr
ogra
mIm
agin
g
ATT
RIB
UTE
S
Peak Transmit Power 1.5 10 20 [KW] 9 9 9 3 1 1 9 9 9 0 1 9 9 9 9 96Radar Bandwidth .5 1 2 [GHz] 9 9 3 3 1 1 9 9 9 0 1 3 3 3 3 66Physical Antenna Area 10 40 100 200 [m^2] 9 9 9 3 1 1 9 9 9 1 1 9 9 9 9 97Antenna Type Mechanical vs. AESA 9 9 9 3 3 1 9 9 9 1 1 9 9 9 9 99Satellite Altitude 800 1200 1500 [km] 9 9 3 9 9 3 9 9 9 9 3 1 1 1 1 85Constellation Type 8 Walker IDs 0 0 1 9 9 3 0 0 3 9 3 9 9 9 9 73Comm. Downlink Relay vs. Downlink 0 0 0 0 0 9 0 0 0 0 9 9 9 3 9 48Tactical Downlink Yes vs. No 0 0 0 0 3 9 0 0 0 0 9 9 9 3 9 51Maneuver Package 1x, 2x, 4x 1 1 1 1 1 0 1 1 1 1 0 9 3 3 3 27Constellation Option none, long-lead, spare 0 0 0 0 0 0 0 0 0 0 0 9 9 9 9 36
Bas
elin
e Sch
edule
Act
ual
Sch
edule
(Era
)
To
tal
Imp
act
Tracking Imaging
Min
. D
isce
rnab
le V
eloci
ty
Num
ber
of
Tar
get
Box
es
Tar
get
ID
Tim
e
Tar
get
Tra
ck L
ife
Tra
ckin
g L
aten
cy
Mission
ATTRIBUTES
ScheduleProgrammaticsCost
Definition RangeVariable Name Min
imum
Tar
get
RC
S
DE
SIG
N V
AR
IAB
LE
S
Base
line
Cos
t
Act
ual
Cost
s (E
ra)
Imag
ing L
aten
cy
Res
olu
tion (
Pro
xy)
Tar
get
s per
Pas
s
Fiel
d o
f R
egar
d
Rev
isit F
requen
cy
1-3-9 scoring is intended to capture first order strength
of interaction in order to quickly focus on important
trades for analysis
seari.mit.edu © 2009 Massachusetts Institute of Technology 9
Process 3: Epoch Characterization
Epoch variables allow for parameterization of some “context” drivers for system value
Level 1 – SAR < GMTILevel 2 – SAR = GMTILevel 3 – SAR > GMTI
3Imaging vs. Tracking Mission PrioritiesNational Security Strategy/Policy
Use tradespace to vary “costs”naBudget ConstraintsResources
Level 1 – AvailableLevel 2 – Not available
2Collaborative AISR Assets
Radar Product
Capital
Exogenous Uncertainty Category
Epoch Variable Number of Steps
Units/Notes
Epoch Vector
Radar Technology Level
3 Level 1 (Mature), TRL = 9 Level 2 (Medium), TRL = 6 Level 3 (Advanced), TRL = 4
Communication Infrastructure
2 Level 1 – No Backbone + AFSCN Ground Sites
Level 2 – WGS + AFSCN Ground Sites
Operations Plans 9 Lookup table of geographic region & target op. plans
Environment 2 Level 1 – No jammingLevel 2 – Hostile jamming
Epochs defined by specifying needs and context through Epoch Variables
– Enumerate hundreds of contexts – Analogous to design variables
648Future
Contexts
648Future
Contexts
Satellite Radar SystemProgram Manager
comptroller
Nation
SI&E
SRS Enterprise Boundary
Capital(non‐fungible assets)
Capital(non‐fungible assets)
National Security Strategy/PolicyNational Security Strategy/Policy
Resources(fungible assets)
Resources(fungible assets)
RadarProductRadarProduct
DNI
NGAJ2
Military
USD(I)
ExtendedSRS
Enterprise
SRS Context
OMBCongress
Which SRS Architecture?
R&DR&D Comm/GrndComm/Grnd
Infra‐
Struct.
Epoch: A time period with a fixed context and set of needs; characterized by static constraints,
design concepts, available technologies, and articulated attributes (Ross 2006)
seari.mit.edu © 2009 Massachusetts Institute of Technology 10
Process 3: Epoch Characterization
Epoch variables allow for parameterization of some “context” drivers for system value
Level 1 – SAR < GMTILevel 2 – SAR = GMTILevel 3 – SAR > GMTI
3Imaging vs. Tracking Mission PrioritiesNational Security Strategy/Policy
Use tradespace to vary “costs”naBudget ConstraintsResources
Level 1 – AvailableLevel 2 – Not available
2Collaborative AISR Assets
Radar Product
Capital
Exogenous Uncertainty Category
Epoch Variable Number of Steps
Units/Notes
Epoch Vector
Radar Technology Level
3 Level 1 (Mature), TRL = 9 Level 2 (Medium), TRL = 6 Level 3 (Advanced), TRL = 4
Communication Infrastructure
2 Level 1 – No Backbone + AFSCN Ground Sites
Level 2 – WGS + AFSCN Ground Sites
Operations Plans 9 Lookup table of geographic region & target op. plans
Environment 2 Level 1 – No jammingLevel 2 – Hostile jamming
Epochs defined by specifying needs and context through Epoch Variables
– Enumerate hundreds of contexts – Analogous to design variables
648Future
Contexts
648Future
Contexts
Satellite Radar SystemProgram Manager
comptroller
Nation
SI&E
SRS Enterprise Boundary
Capital(non‐fungible assets)
Capital(non‐fungible assets)
National Security Strategy/PolicyNational Security Strategy/Policy
Resources(fungible assets)
Resources(fungible assets)
RadarProductRadarProduct
DNI
NGAJ2
Military
USD(I)
ExtendedSRS
Enterprise
SRS Context
OMBCongress
Which SRS Architecture?
R&DR&D Comm/GrndComm/Grnd
Infra‐
Struct.
Epoch: A time period with a fixed context and set of needs
seari.mit.edu © 2009 Massachusetts Institute of Technology 11
Process 3: Epoch Characterization
Epoch variables allow for parameterization of some “context” drivers for system value
Level 1 – SAR < GMTILevel 2 – SAR = GMTILevel 3 – SAR > GMTI
3Imaging vs. Tracking Mission PrioritiesNational Security Strategy/Policy
Use tradespace to vary “costs”naBudget ConstraintsResources
Level 1 – AvailableLevel 2 – Not available
2Collaborative AISR Assets
Radar Product
Capital
Exogenous Uncertainty Category
Epoch Variable Number of Steps
Units/Notes
Epoch Vector
Radar Technology Level
3 Level 1 (Mature), TRL = 9 Level 2 (Medium), TRL = 6 Level 3 (Advanced), TRL = 4
Communication Infrastructure
2 Level 1 – No Backbone + AFSCN Ground Sites
Level 2 – WGS + AFSCN Ground Sites
Operations Plans 9 Lookup table of geographic region & target op. plans
Environment 2 Level 1 – No jammingLevel 2 – Hostile jamming
Epochs defined by specifying needs and context through Epoch Variables
– Enumerate hundreds of contexts – Analogous to design variables
Enterprise scoping exercise informed the types of “epoch variables” encountered by program
648Future
Contexts
648Future
Contexts
Satellite Radar SystemProgram Manager
comptroller
Nation
SI&E
SRS Enterprise Boundary
Capital(non‐fungible assets)
Capital(non‐fungible assets)
National Security Strategy/PolicyNational Security Strategy/Policy
Resources(fungible assets)
Resources(fungible assets)
RadarProductRadarProduct
DNI
NGAJ2
Military
USD(I)
ExtendedSRS
Enterprise
SRS Context
OMBCongress
Which SRS Architecture?
R&DR&D Comm/GrndComm/Grnd
Infra‐
Struct.
Epoch: A time period with a fixed context and set of needs
seari.mit.edu © 2009 Massachusetts Institute of Technology 12
Process 4: Design Tradespace Evaluation
Compares system designs on a common, quantitative basis– Uses computer-based models to compare thousands of designs– Avoids limits of local point solutions– Maps structure of stakeholder value onto design space– Simulation can be used to account for design uncertainties
(i.e., cost, schedule, performance uncertainty bubbles)
Design tradespaces provide high-level insights into system-level trade-offs. Detailed system-level design would follow-on preferred system concept decisions
Each point represents a feasible solution
Epoch Variables
Design Variables Attributes
Model(s)
seari.mit.edu © 2009 Massachusetts Institute of Technology 13
Typical Tradespace: Utility vs. Cost
EPOCH 171
Each point is anevaluated design
Some good value solutions?
• Color shows additional information; in this case, antenna area
• Larger area (100 m2) gives better utility at higher cost
• Medium size (40 m2) works, cheaper
• Smallest area in DV (10 m2) does not appear -small antennas do not satisfy minimum user needs in this case
Visualizations used to get quick insights into key trades, which may be context dependent
Epoch 171No AISR avail, WGS availNo jamming, TRL 9 techTARGETS: Mid East, AsiaImaging mission (primary)
seari.mit.edu © 2009 Massachusetts Institute of Technology 14
Process 5: Multi-Epoch Analysis
• Cross-epoch analysis
• Within-epoch analysis
• Identifying Passive Value Robust designs
• Identifying changeable designs
seari.mit.edu © 2009 Massachusetts Institute of Technology 15
Cross-Epoch Analysis: Tradespace Yield
0 100 200 300 400 500 600 700 800 900 10000
5
10
15
20
25
30
35
40Tradespace Yield by Percent for Evaluated Epochs
Epoch Number
Per
cent
Yie
ld (
%)
0 5 10 15 20 25 30 35 400
5
10
15
20
25Tradespace Yield Distribution by Frequency
Percent Yield (%)
Fre
quen
cy
Yield = feasible designs / total designs per tradespace* (in %)
*For the SRS case study, total designs per tradespace = 23,328
Epochs with demanding target sets
Epochs with collaborative AISR assets
Observations• No epoch with more than 36% yield
• Most epochs with 18-20% yield
Possible low yield causes: poor design enumeration, demanding constraints, difficult attribute range expectations
seari.mit.edu © 2009 Massachusetts Institute of Technology 16
Within-Epoch Analysis:Tradespace Yield
Tracking mission attributes
Low attribute importance
Many designs disqualified!
“Easy”attribute
Distribution of designs across attribute ranges shows the impact of “easy” and “hard” expectations
Relaxing attribute range constraints may make many otherwise
attractive designs feasible
Especially for low attribute importance
One third of tradespace
disqualified!
Also low attribute
importance
seari.mit.edu © 2009 Massachusetts Institute of Technology 17
Calculating Pareto Trace to Identify Passive Value Robust Designs
1 2 3 4 5 6 7 8
x 107
0.65
0.7
0.75
0.8
0.85Epoch 171 Only Valid Designs
Lifecycle Cost
Imag
e U
tility
Find non-dominated solutions within a given epoch (Pareto Set)
Higher Pareto Trace designs are more passively value robust
0 1 2 3
x 104
0
20
40
60
80
100
Par
eto
Tra
ce
D es ign ID
im age v. c os t
3350 3400 34500
20
40
60
80
100
120
Par
eto
Tra
ce
D es ign ID
im age v. c os t
P T
Identify designs with high Pareto Trace for further investigation
e.g. “design 3435” is in 67% of Pareto Sets
Pareto Trace Number# Pareto Sets containing design
(measure of passive robustness)
Num
of d
esig
ns
Pareto Trace Number
Util
ity
EpochCos
t
Pareto Trace Number# Pareto Sets containing design
(measure of passive robustness)
Num
of d
esig
ns
Pareto Trace Number
Num
of d
esig
ns
Pareto Trace Number
Util
ity
EpochCos
t
Util
ity
EpochCos
t
Across many epochs, track number of times solution appears in Pareto Set
seari.mit.edu © 2009 Massachusetts Institute of Technology 18
Finding “Compromises” Across Missions and Stakeholders
Discover “best” alternatives for individual missions, as well as “efficient” compromises
1 2 3 4 5 6 7 8
x 107
0.65
0.7
0.75
0.8
0.85Epoch 171 Only Valid Designs
Lifecycle Cost
Imag
e U
tility
1 2 3 4 5 6 7 8
x 107
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9Epoch 171 Only Valid Designs
Lifecycle Cost
Tra
ck U
tility
34356027
21701
21697
13929
13925
13921
6038
3758
3446
21701
21697
13929
13925
13921
6038
3758
3446
6153
6149
6145
1285
6153
6149
6145
1285
6003
5967
3887
3883
3877
3519
3483
3411
3375
6003
5967
3887
3883
3877
3519
3483
3411
3375
1287 3433 3434 3436 3445 3757 6025 6026 6028 6037 3363 3399 3447 3555 3559 3879 5955 5991
6029 3769 6147 6469 6741
Imaging Tracking
Joint
Compromise
Pareto Efficient Sets Imaging Mission
Tracking Mission
Method provides quantitative approach for discovering “best”mission-specific designs, as well as “efficient” (benefit at cost) compromises across missions and stakeholders
“Best” for mission
“Best” for mission
“Efficient”compromise
seari.mit.edu © 2009 Massachusetts Institute of Technology 19
Diving Deeper onto Select Designs
Colored by increasing peak power*
* Similar effect due to increased antenna aperture
Colored by increasing radar bandwidth
• Utility can be decomposed into individual stakeholder values
• Decomposition provides insights into key system design tradeoffs across missions
Focused tradespace of ~9,000 designs around single design
Design 3435
Tracking Mission
Imaging Mission
seari.mit.edu © 2009 Massachusetts Institute of Technology 20
Defined 8 System Transition Paths (Rules)1. Redesign (Design Phase)2. Redesign (Build Phase)3. Redesign (Test Phase)4. Add satellites to constellation (Ops Phase)5. Alter altitude with on-orbit fuel (Ops Phase)6. Alter altitude through tug (Ops Phase)7. Alter inclination with on-orbit fuel (Ops Phase)8. Alter inclination through tug (Ops Phase)
Calculating Filtered Outdegree to Identify Changeable Designs
One can identify “changeable” designs and design choices (real options) by determining the filtered outdegree at a given acceptable transition “cost” threshold
Filtered Outdegree# outgoing arcs from design at acceptable “cost”
(measure of changeability)
102
104
106
108
0
0.5
1
1.5
2
2.5x 10
4
Delta Cost
Ou
tdeg
ree
Design 3435, All Epochs, All Rules
Ep63Ep171Ep193Ep202Ep219Ep258Ep279Ep282Ep352Ep387Ep494Ep495Ep519Ep525Ep711Ep773Ep819Ep843Ep849Ep877Ep879
In some cases…“changeability” goes to zero
Variation in design “changeability”in response to context change
seari.mit.edu © 2009 Massachusetts Institute of Technology 21
Defined 8 System Transition Paths (Rules)1. Redesign (Design Phase)2. Redesign (Build Phase)3. Redesign (Test Phase)4. Add satellites to constellation (Ops Phase)5. Alter altitude with on-orbit fuel (Ops Phase)6. Alter altitude through tug (Ops Phase)7. Alter inclination with on-orbit fuel (Ops Phase)8. Alter inclination through tug (Ops Phase)
Calculating Filtered Outdegree to Identify Changeable Designs
One can identify “changeable” designs and design choices (real options) by determining the filtered outdegree at a given acceptable transition “cost” threshold
Filtered Outdegree# outgoing arcs from design at acceptable “cost”
(measure of changeability)
102
104
106
108
0
0.5
1
1.5
2
2.5x 10
4
Delta Cost
Ou
tdeg
ree
Design 3435, All Epochs, All Rules
Ep63Ep171Ep193Ep202Ep219Ep258Ep279Ep282Ep352Ep387Ep494Ep495Ep519Ep525Ep711Ep773Ep819Ep843Ep849Ep877Ep879
In some cases…“changeability” goes to zero
Variation in design “changeability”in response to context change
Quantification and specification of “ilities” can be made explicit using RSC (e.g. flexibility, adaptability, scalability,
survivability, etc.)
seari.mit.edu © 2009 Massachusetts Institute of Technology 22
Changeability Across the Lifecycle
0 0.5 1 1.5 2 2.5
x 104
0
1000
2000
3000
4000
5000
6000
7000
Design Num
Filt
ered
Out
degr
ee
Filtered Outdegree, Epoch 171, Design Phase
0 0.5 1 1.5 2 2.5
x 104
0
500
1000
1500
2000
2500
Design Num
Filt
ered
Out
degr
ee
Filtered Outdegree, Epoch 171, Build Phase
0 0.5 1 1.5 2 2.5
x 104
0
500
1000
1500
Design Num
Filt
ered
Out
degr
ee
Filtered Outdegree, Epoch 171, Test Phase
0 0.5 1 1.5 2 2.5
x 104
0
5
10
15
20
25
30
35
Design Num
Filt
ered
Out
degr
ee
Filtered Outdegree, Epoch 171, Operate Phase
Notional system lifecycle
Design Build Integrate & Test Operate
Path E
nablersD
esign Variables
3
5
1
0
0
20
1
0
100
10
4
800
16805
133Constellation Option (1=nothing, 3=spares built)
466Maneuver package (4=baseline, 5=x2, 6=x4)
111Tugable (1=yes)
000Tactical Comm (0=yes)
100Comm Arch (0=backbone, 1=ground)
102020Peak Power (kW)
211Radar Bandwidth (GHz)
000Ant Type (0=AESA)
4010040Ant Area (m^2)
101010Tx Freq (GHz)
344Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
1500800800Orbit Alt (km)
34351680916701
Path E
nablersD
esign Variables
3
5
1
0
0
20
1
0
100
10
4
800
16805
133Constellation Option (1=nothing, 3=spares built)
466Maneuver package (4=baseline, 5=x2, 6=x4)
111Tugable (1=yes)
000Tactical Comm (0=yes)
100Comm Arch (0=backbone, 1=ground)
102020Peak Power (kW)
211Radar Bandwidth (GHz)
000Ant Type (0=AESA)
4010040Ant Area (m^2)
101010Tx Freq (GHz)
344Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
1500800800Orbit Alt (km)
34351680916701
0.525.538.2100Best across171
0.423.638.210016805171
0.525.527.010016701171
0.20.30.041003435171
OperateTestBuildDesignDesign #Epoch
Phase
Changeability decreases as design moves through lifecycle
Highly changeable designs per phase can be identified and features investigated
Time
seari.mit.edu © 2009 Massachusetts Institute of Technology 23
Identifying “Interesting” Designs
Path E
nablersD
esign Variables
3
5
1
0
0
20
1
0
100
10
4
800
16805
133Constellation Option (1=nothing, 3=spares built)
466Maneuver package (4=baseline, 5=x2, 6=x4)
111Tugable (1=yes)
000Tactical Comm (0=yes)
100Comm Arch (0=backbone, 1=ground)
102020Peak Power (kW)
211Radar Bandwidth (GHz)
000Ant Type (0=AESA)
4010040Ant Area (m^2)
101010Tx Freq (GHz)
344Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
1500800800Orbit Alt (km)
34351680916701
Path E
nablersD
esign Variables
3
5
1
0
0
20
1
0
100
10
4
800
16805
133Constellation Option (1=nothing, 3=spares built)
466Maneuver package (4=baseline, 5=x2, 6=x4)
111Tugable (1=yes)
000Tactical Comm (0=yes)
100Comm Arch (0=backbone, 1=ground)
102020Peak Power (kW)
211Radar Bandwidth (GHz)
000Ant Type (0=AESA)
4010040Ant Area (m^2)
101010Tx Freq (GHz)
344Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
1500800800Orbit Alt (km)
34351680916701
16701 16805
16809
3435
Most passive value robust (3435)Most changeable (16701) Both passive value robust and changeable
designs can be identified in any epoch
seari.mit.edu © 2009 Massachusetts Institute of Technology 24
Discussion
Insight 1: Quantitative investigation of “requirement” effect– Ease or difficulty in achieving “acceptable” levels– Identification of overly constraining expectations
Insight 2: Quantify “value robust” and correlate to design features– Pareto Trace metric to identify value robust designs (across
enumerated epochs)– Filtered Outdegree metric to identify changeable designs (for
unknown epochs or for evolving systems)– Identify useful design features for real options
Insight 3: Quantify key system tradeoffs– Illustrate tensions between missions– Identify good “compromise” design alternatives
Caution: Specific insights into SRS more illustrative than prescriptive(very low fidelity model used)
seari.mit.edu © 2009 Massachusetts Institute of Technology 25
Next Steps
• RSC method refinement on-going
• Application of Process 6 (Era Construction) and Process 7 (Lifecycle Path Analysis) in current research (aim to publish next year)
• Advanced metrics and approaches for incorporating survivability, SoS design, and valuing destinations for changeability
Thank you.Questions?
Stay tuned for follow-up publications with results…
seari.mit.edu © 2009 Massachusetts Institute of Technology 27
Tradespace NetworkTradespace NetworkTradespace Network
DV Transition RulesDV Transition Rules
Context(Epoch Vector)
Context(Epoch Vector)
Epoch VariablesEpoch Variables
EPOCH CHARACTERIZATION
MULTI‐EPOCH ANALYSIS
Sample
Epoch Transition RulesEpoch Transition Rules
ErasEras
Path CalculatorPath Calculator
Cost-Utility TrajectoriesCostCost--Utility TrajectoriesUtility Trajectories
Path SelectionRules
Path SelectionRules
ERA CONSTRUCTION
LIFECYCLE PATH ANALYSIS
Overall Model Architecture
ModelModel
Design VectorDesign Vector
AttributesAttributes
MissionMission
VALUE‐DRIVEN DESIGNFORUMULATION
UtilityUtility
CostCost
TradespaceTradespaceTradespace
Sample
Value RobustnessValue RobustnessValue RobustnessSurvivabilitySurvivabilitySurvivability FlexibilityFlexibilityFlexibility
Epoch DataEpoch DataEpoch Data
2
3
5
6
7DESIGN TRADESPACE
EVALUATION
4
VALUE‐DRIVING CONTEXTDEFINITION
1