Sep 16, 2009 - Strategy/Policy. National Security. Strategy/Policy. Resources. (fungible assets). Resources. (fungible assets). Radar. Product. Radar. Product.
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
Outline • Motivation • Review of Responsive Systems Comparison Method (RSC) • Design Tradespace Evaluation • Multi-Epoch Analysis • Discussion
seari.mit.edu
© 2009 Massachusetts Institute of Technology
2
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
3
The RSC Method Using Multi-Attribute Tradespace Exploration, Epoch-Era Analysis, and other approaches, a coherent set of processes were developed into the RSC method • Processes consist of discrete set of activities • Some feedback between processes is possible • Some processes can occur in parallel to save time
Focus of talk
RSC consists of seven processes: 1. Value-Driving Context Definition 2. Value-Driven Design Formulation 3. Epoch Characterization 4. Design Tradespace Evaluation 5. Multi-Epoch Analysis 6. Era Construction 7. Lifecycle Path Analysis seari.mit.edu
© 2009 Massachusetts Institute of Technology
4
Case Application: Satellite Radar System (SRS) In order to develop RSC, a test case was selected with requisite complexity… 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
Satellite Radar System (SRS) Value Proposition:
24 hour, all weather on-demand “Visibility and Tracking” over things that can be observed (CBO 2007)
Case Application Goal:
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 seari.mit.edu
© 2009 Massachusetts Institute of Technology
5
Process 1: Value-Driving Context Definition
Funding instability
How does one account for exogenous uncertainties? – – – –
Policy Funding Infrastructure Environment
Enterprise boundary helps to define “context”
DoD/IC stakeholders changing tasking priorities National Security Strategy/Policy
Which SRS Architecture?
DNI USD(I) SRS Enterprise Boundary
comptroller
Resources (fungible assets)
Congress OMB
SI&E
Satellite Radar System Program Manager Nation R&D
Extended SRS Enterprise
NGA J2
Radar Product
Dynamic threat environment
Military Comm/Grnd Infra‐ Struct.
A “Satellite Radar Program Manager” is chosen as a “supradecision maker” who must represent all interests in order to have a successful program
SRS Context
Capital (non‐fungible assets)
Uncertain technology availability Uncertain ground/relay infrastructure
Evaluation Perspective: Given distributions of future uncertainties, how does Satellite Radar Program Manager select the “best” architecture? seari.mit.edu
© 2009 Massachusetts Institute of Technology
6
Process 2: Value-Driven Design Formulation Design-space:
Value-space:
Designer-controlled parameters that define a system concept
Concept-neutral evaluation criteria specified by decision makers
1.5, 10, 20 [kW] 0.5, 1, 2 [GHz] 10, 40, 100, 200 [m2] Mechanical, AESA 800, 1200, 1500 [km] 8 Walker IDs Relay, Direct downlink Yes, No 1x, 2x, 4x base fuel Yes, No None, long-lead, spares
Imaging Program
Peak Transmit Power Radar Bandwidth Physical Antenna Area Antenna Type Altitude Constellation Configuration Communication Downlink Tactical Communication Able Maneuver Capability Tugable Constellation Option
Tracking
Definition Range
ATTRIBUTES
DESIGN VARIABLES
Variable Name
Attribute Name Minimum Target RCS Min. Discernable Velocity Number of Target Boxes Target Acquisition Time Target Track Life Tracking Latency Resolution Targets per Pass Field of Regard Revisit interval Imaging Latency Geo-Location Accuracy
units m^2 m/s # min min min m # km^2 min min m
Baseline Cost Deviation from Cost Baseline Schedule Deviation from Schedule
$B % years years
range (U=0 to U=1) 1000 --> 0 50 --> 5 1 --> 10 120 --> 10 0 --> 60 240 --> 0 5 --> 0.01 1 --> 10^5 1000 --> 10^6 300 --> 10 720 --> 60 500 --> 50
ATTRIBUTES
Definition Range
Minimum Target RCS
Min. Discernable Velocity
Number of Target Boxes
Target ID Time
Target Track Life
Tracking Latency
Resolution (Proxy)
Targets per Pass
Field of Regard
Revisit Frequency
Imaging Latency
Baseline Cost
Actual Costs (Era)
Baseline Schedule
Actual Schedule (Era)
DESIGN VARIABLES
Variable Name Peak Transmit Power Radar Bandwidth Physical Antenna Area Antenna Type Satellite Altitude Constellation Type Comm. Downlink Tactical Downlink Maneuver Package Constellation Option
Programmatics Cost Schedule
Imaging
1.5 10 20 [KW] .5 1 2 [GHz] 10 40 100 200 [m^2] Mechanical vs. AESA 800 1200 1500 [km] 8 Walker IDs Relay vs. Downlink Yes vs. No 1x, 2x, 4x none, long-lead, spare
9 9 9 9 9 0 0 0 1 0
9 9 9 9 9 0 0 0 1 0
9 3 9 9 3 1 0 0 1 0
3 3 3 3 9 9 0 0 1 0
1 1 1 3 9 9 0 3 1 0
1 1 1 1 3 3 9 9 0 0
9 9 9 9 9 0 0 0 1 0
9 9 9 9 9 0 0 0 1 0
9 9 9 9 9 3 0 0 1 0
0 0 1 1 9 9 0 0 1 0
1 1 1 1 3 3 9 9 0 0
9 3 9 9 1 9 9 9 9 9
9 3 9 9 1 9 9 9 3 9
9 3 9 9 1 9 3 3 3 9
9 3 9 9 1 9 9 9 3 9
Total Impact
Mission Tracking
96 66 97 99 85 73 48 51 27 36
Design-Value Mapping (DVM): Ensures alignment between Value-space and Design-space
Design-Value Mapping (DVM) ensures design decisions drive value delivery seari.mit.edu
© 2009 Massachusetts Institute of Technology
7
Process 2: Value-Driven Design Formulation Design-space:
Value-space:
Designer-controlled parameters that define a system concept
Concept-neutral evaluation criteria specified by decision makers
1 1 1 3 9 9 0 3 1 0
1 1 1 1 3 3 9 9 0 0
9 9 9 9 9 0 0 0 1 0
9 9 9 9 9 3 0 0 1 0
Total Impact
Actual Schedule (Era)
Baseline Schedule
Actual Costs (Era)
Baseline Cost
Imaging Latency
Revisit Frequency
Field of Regard
Targets per Pass
Resolution (Proxy)
Tracking Latency
Target Track Life
Tracking
Imaging Target ID Time Program
ATTRIBUTES
9 9 9 9 9 0 0 0 1 0
0 0 1 1 9 9 0 0 1 0
1 1 1 1 3 3 9 9 0 0
9 3 9 9 1 9 9 9 9 9
9 3 9 9 1 9 9 9 3 9
9 3 9 9 1 9 3 3 3 9
9 3 9 9 1 9 9 9 3 9
Total Impact
3 3 3 3 9 9 0 0 1 0
Actual Schedule (Era)
9 3 9 9 3 1 0 0 1 0
Baseline Schedule
Resolution (Proxy)
9 9 9 9 9 0 0 0 1 0
Actual Costs (Era)
Tracking Latency
9 9 9 9 9 0 0 0 1 0
Programmatics Cost Schedule
Baseline Cost
Target Track Life
1.5 10 20 [KW] .5 1 2 [GHz] 10 40 100 200 [m^2] Mechanical vs. AESA 800 1200 1500 [km] 8 Walker IDs Relay vs. Downlink Yes vs. No 1x, 2x, 4x none, long-lead, spare
9 9 9 9 9 ATTRIBUTES 0 Imaging 0 0 1 0
Imaging Latency
Definition Range
Target ID Time
DESIGN VARIABLES
Variable Name Peak Transmit Power Radar Bandwidth Physical Antenna Area Antenna Type Satellite Altitude Constellation Type Comm. Downlink Tactical Downlink Maneuver Package Constellation Option
9 9 9 9 9 Mission 0 0 0 1 0
Number of Target Boxes
.5 1 2 [GHz] 10 40 100 200 [m^2] Mechanical vs. AESA 800 1200 1500 [km] 8 Walker IDs Tracking Relay vs. Downlink Yes vs. No 1x, 2x, 4x none, long-lead, spare Min. Discernable Velocity
Radar Bandwidth Physical Antenna Area Antenna Type Satellite Altitude Constellation Type Comm. Downlink Tactical Downlink Maneuver Package Constellation Option
Minimum Target RCS
DESIGN VARIABLES
Peak Transmit Power None, long-lead, 1.5 10 20spares [KW] Constellation Option
Revisit Frequency
Minimum Target RCS
Yes, No 1x, 2x, 4x base fuel Yes, No Definition Range
Min. Discernable Velocity
1.5, 10, 20 [kW]
1-3-9 scoring0.5, is 1,intended to 2 [GHz] 10, 40, 100, 200 [m2] capture first order strength Mechanical, AESA of interaction in order to 800, 1200, 1500 [km] quickly focus8 on important Walker IDs Direct downlink trades forRelay, analysis
Field of Regard
Peak Transmit Power Radar Bandwidth Physical Antenna Area Antenna Type Altitude Constellation Configuration Communication Downlink Tactical Communication Able Maneuver Capability Variable Name Tugable
Attribute Name units range (U=0 to U=1) ATTRIBUTES Minimum m^2 1000 --> 0 Mission Target RCS Programmatics Velocity Cost m/s 50 --> 5 TrackingMin. Discernable Imaging Schedule Number of Target Boxes # 1 --> 10 Target Acquisition Time min 120 --> 10 Target Track Life min 0 --> 60 Tracking Latency min 240 --> 0 Resolution m 5 --> 0.01 Targets per Pass # 1 --> 10^5 Field of Regard km^2 1000 --> 10^6 Revisit interval min 300 --> 10 Imaging Latency min 720 --> 60 Geo-Location Accuracy m 500 --> 50 96 9 3 1 1 9 9 9 0 1 9 9 9 9 Baseline Cost $B 66 3 3 1 1 9 9 9 0 1 3 3 3 3 Deviation from Cost % 97 9 3 1 1 9 9 9 1 1 9 9 9 9 Baseline Schedule years 99 9 3 3 1 9 9 9 1 1 9 9 9 9 Deviation from Schedule 1 years 85 3 9 9 3 9 9 9 9 3 1 1 1 73 1 9 9 3 0 0 3 9 3 9 9 9 9 48 0 0 0 9 0 0 0 0 9 9 9 3 9 51 0 0 3 9 0 0 0 0 9 9 9 3 9 27 1 1 1 0 1 1 1 1 0 9 3 3 3 36 0 0 0 0 0 0 0 0 0 9 9 9 9 Number of Target Boxes
Definition Range
Targets per Pass
DESIGN VARIABLES
Variable Name
96 66 97 99 85 73 48 51 27 36
Design-Value Mapping (DVM): Ensures alignment between Value-space and Design-space
Design-Value Mapping (DVM) ensures design decisions drive value delivery seari.mit.edu
© 2009 Massachusetts Institute of Technology
8
Process 3: Epoch Characterization National Security Strategy/Policy
Which SRS Architecture?
comptroller
Resources (fungible assets)
Congress OMB
Epochs defined by specifying needs and context through Epoch Variables
DNI USD(I) SRS Enterprise Boundary
SI&E
Satellite Radar System Program Manager Nation
NGA J2
Radar Product
Military Comm/Grnd Infra‐ Struct.
R&D
Extended SRS Enterprise
SRS Context
Capital (non‐fungible assets)
– Enumerate hundreds of contexts – Analogous to design variables Exogenous Uncertainty Category
Epoch Variable
Number of Steps
National Security Strategy/Policy
Imaging vs. Tracking Mission Priorities
3
Resources
Epoch Vector
648 Future Contexts
Capital
Units/Notes Level 1 – SAR < GMTI Level 2 – SAR = GMTI Level 3 – SAR > GMTI
na Use tradespace to vary “costs” Epoch: 3 Level 1 (Mature), TRL = 9 Radar Technology 2 (Medium), = 6 of Level period with a fixed Level A time context andTRLset Level 3 (Advanced), TRL = 4 needs; characterized by static 2 Level 1 – constraints, No Backbone + AFSCN Communication Ground Sites Infrastructure design concepts, availableLevel technologies, 2 – WGS + AFSCN and Ground Sites articulated attributes (Ross 2006) 2 Level 1 – Available Collaborative AISR Assets
Budget Constraints
Level 2 – Not available
Radar Product
Operations Plans
9
Lookup table of geographic region & target op. plans
Environment
2
Level 1 – No jamming Level 2 – Hostile jamming
Epoch variables allow for parameterization of some “context” drivers for system value seari.mit.edu
© 2009 Massachusetts Institute of Technology
9
Process 3: Epoch Characterization National Security Strategy/Policy
Which SRS Architecture?
comptroller
Resources (fungible assets)
Congress OMB
Epochs defined by specifying needs and context through Epoch Variables
DNI USD(I) SRS Enterprise Boundary
SI&E
Satellite Radar System Program Manager Nation
NGA J2
Radar Product
Military Comm/Grnd Infra‐ Struct.
R&D
Extended SRS Enterprise
SRS Context
Capital (non‐fungible assets)
Epoch Vector
648 Future Contexts
– Enumerate hundreds of contexts – Analogous to design variables Exogenous Uncertainty Category
Epoch Variable
Number of Steps
National Security Strategy/Policy
Imaging vs. Tracking Mission Priorities
3
Level 1 – SAR < GMTI Level 2 – SAR = GMTI Level 3 – SAR > GMTI
Resources
Budget Constraints
na
Use tradespace to vary “costs”
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
Collaborative AISR Assets
2
Level 1 – Available Level 2 – Not available
Operations Plans
9
Lookup table of geographic region & target op. plans
Environment
2
Level 1 – No jamming Level 2 – Hostile jamming
Capital
Radar Product
Units/Notes
Epoch: A time period with a fixed context and set of needs
Epoch variables allow for parameterization of some “context” drivers for system value seari.mit.edu
© 2009 Massachusetts Institute of Technology
10
Process 3: Epoch Characterization National Security Strategy/Policy
Which SRS Architecture?
comptroller
Resources (fungible assets)
Congress OMB
Enterprise scoping exercise informed of Epochs defined by specifying needsthe andtypes context “epochEpoch variables” encountered by program through Variables
DNI USD(I) SRS Enterprise Boundary
SI&E
Satellite Radar System Program Manager Nation
NGA J2
Radar Product
Military Comm/Grnd Infra‐ Struct.
R&D
Extended SRS Enterprise
SRS Context
Capital (non‐fungible assets)
Epoch Vector
648 Future Contexts
– Enumerate hundreds of contexts – Analogous to design variables Exogenous Uncertainty Category
Epoch Variable
Number of Steps
National Security Strategy/Policy
Imaging vs. Tracking Mission Priorities
3
Level 1 – SAR < GMTI Level 2 – SAR = GMTI Level 3 – SAR > GMTI
Resources
Budget Constraints
na
Use tradespace to vary “costs”
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
Collaborative AISR Assets
2
Level 1 – Available Level 2 – Not available
Operations Plans
9
Lookup table of geographic region & target op. plans
Environment
2
Level 1 – No jamming Level 2 – Hostile jamming
Capital
Radar Product
Units/Notes
Epoch: A time period with a fixed context and set of needs
Epoch variables allow for parameterization of some “context” drivers for system value seari.mit.edu
© 2009 Massachusetts Institute of Technology
11
Process 4: Design Tradespace Evaluation Each point represents a feasible solution
Epoch Variables Design Variables
Attributes
Model(s)
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
seari.mit.edu
© 2009 Massachusetts Institute of Technology
12
Typical Tradespace: Utility vs. Cost EPOCH 171
Epoch 171 No AISR avail, WGS avail No jamming, TRL 9 tech TARGETS: Mid East, Asia Imaging mission (primary)
Some good value solutions?
Each point is an evaluated design
• 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 seari.mit.edu
© 2009 Massachusetts Institute of Technology
13
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
14
Cross-Epoch Analysis: Tradespace Yield Yield = feasible designs / total designs per tradespace* (in %) Tradespace Yield by Percent for Evaluated Epochs
Tradespace Yield Distribution by Frequency 25
40 35
20
25 Frequency
Percent Yield (%)
30
20 15 10
15
10
5
5 0
0
100
200
300
400 500 600 Epoch Number
700
800
900
Observations • No epoch with more than 36% yield • Most epochs with 18-20% yield
1000
0
0
5
10
Epochs with demanding target sets
15 20 25 Percent Yield (%)
30
35
40
Epochs with collaborative AISR assets
*For the SRS case study, total designs per tradespace = 23,328
Possible low yield causes: poor design enumeration, demanding constraints, difficult attribute range expectations seari.mit.edu
© 2009 Massachusetts Institute of Technology
15
Within-Epoch Analysis: Tradespace Yield Many designs disqualified!
Tracking mission attributes
Low attribute importance
“Easy” attribute One third of tradespace disqualified!
Relaxing attribute range constraints may make many otherwise attractive designs feasible
Also low attribute importance
Especially for low attribute importance
Distribution of designs across attribute ranges shows the impact of “easy” and “hard” expectations seari.mit.edu
© 2009 Massachusetts Institute of Technology
16
Calculating Pareto Trace to Identify Passive Value Robust Designs Epoch 171 Only Valid Designs 0.85
Pareto Trace Number 0.8
# Pareto Sets containing design
0.65
3
4 5 Lifecycle Cost
6
7
8
Epoch
7
x 10
Find non-dominated solutions within a given epoch (Pareto Set)
Pareto Trace Number
Across many epochs, track number of times solution appears in Pareto Set im a g e v. c o s t
120
80
100 Pareto Trace
Pareto Trace
im a g e v. c o s t 100
60 40 20 0
st Co
Identify designs with high Pareto Trace for further investigation
80 T
2
60 40
P
1
Num of designs
0.7
Utility
Image Utility
(measure of passive robustness) 0.75
20 0
1 2 D e s ig n ID
3 x 10
4
0 3350
3400 D e s ig n ID
3450
e.g. “design 3435” is in 67% of Pareto Sets
Higher Pareto Trace designs are more passively value robust seari.mit.edu
© 2009 Massachusetts Institute of Technology
17
Finding “Compromises” Across Missions and Stakeholders 0.85
“Best” for mission
Compromise
0.8
Imaging
3411
3758
3483 1285
13921
6145
13925
6149
13929
6153
21697 21701
Image Utility
3375 3446
6038
Imaging Mission Epoch 171 Only Valid Designs
Pareto Efficient Sets
“Best” for mission
0.75
0.7
3519 3435 6027
3877
Tracking
0.65
3883
Joint
3887 1
5967
2
6003
3
4 5 Lifecycle Cost
6
7
8 7
x 10
Tracking Mission Epoch 171 Only Valid Designs
0.9
0.7 0.6 Track Utility
“Efficient” compromise
0.8
1287 3433 3434 3436 3445 3757 6025 6026 6028 6037 3363 3399 3447 3555 3559 3879 5955 5991 6029 3769 6147 6469 6741
Method provides quantitative approach for discovering “best” mission-specific designs, as well as “efficient” (benefit at cost) compromises across missions and stakeholders
0.5 0.4 0.3 0.2 0.1
1
2
3
4 5 Lifecycle Cost
6
7
8 7
x 10
Discover “best” alternatives for individual missions, as well as “efficient” compromises seari.mit.edu
© 2009 Massachusetts Institute of Technology
18
Diving Deeper onto Select Designs Tracking Mission • Utility can be decomposed into individual stakeholder values • Decomposition provides insights into key system design tradeoffs across missions Colored by increasing peak power* * Similar effect due to increased antenna aperture
Imaging Mission
Design 3435
Focused tradespace of ~9,000 designs around single design
seari.mit.edu
Colored by increasing radar bandwidth
© 2009 Massachusetts Institute of Technology
19
Calculating Filtered Outdegree to Identify Changeable Designs Filtered Outdegree
Variation in design “changeability” in response to context change
# outgoing arcs from design at acceptable “cost” (measure of changeability)
2.5
x 10
4
Design 3435, All Epochs, All Rules
Ep63 Ep171 Ep193 Ep202 Ep219 Ep258 Ep279 Ep282 Ep352 Ep387 Ep494 Ep495 Ep519 Ep525 Ep711 Ep773 Ep819 Ep843 Ep849 Ep877 Ep879
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)
Outdegree
2
1.5
1
0.5
In some cases… “changeability” goes to zero 0 2 10
10
4
10
6
10
8
Delta Cost
One can identify “changeable” designs and design choices (real options) by determining the filtered outdegree at a given acceptable transition “cost” threshold seari.mit.edu
© 2009 Massachusetts Institute of Technology
20
Calculating Filtered Outdegree to Identify Changeable Designs Filtered Outdegree
Variation in design “changeability” in response to context change
# outgoing arcs from design at acceptable “cost” (measure of changeability)
2.5
x 10
4
Design 3435, All Epochs, All Rules
Ep63 Ep171 Ep193 Ep202 Ep219 Ep258 Ep279 Ep282 Ep352 Ep387 Ep494 Ep495 Ep519 Ep525 Ep711 Ep773 Ep819 Ep843 Ep849 Ep877 Ep879
Defined 8 System Transition Paths (Rules) 1. Redesign (Design Phase) 2.Quantification Redesign (Build Phase) and specification of 3. Redesign (Test Phase) “ilities” can be made explicit using RSC 4. Add satellites to constellation (Ops Phase) (e.g. flexibility, adaptability, scalability, 5. Alter altitude with on-orbit fuel (Ops Phase) survivability, etc.)Phase) 6. Alter altitude through tug (Ops 7. Alter inclination with on-orbit fuel (Ops Phase) 8. Alter inclination through tug (Ops Phase)
Outdegree
2
1.5
1
0.5
In some cases… “changeability” goes to zero 0 2 10
10
4
10
6
10
8
Delta Cost
One can identify “changeable” designs and design choices (real options) by determining the filtered outdegree at a given acceptable transition “cost” threshold seari.mit.edu
© 2009 Massachusetts Institute of Technology
21
Changeability Across the Lifecycle Notional system lifecycle Build 2500 Filtered Outdegree
Filtered Outdegree
6000 5000 4000 3000 2000 1000 0
0
0.5
1 1.5 Design Num
2
2.5
Filtered Outdegree, Epoch 171, Build Phase
2000 1500 1000 500 0
Operate Filtered Outdegree, Epoch 171, Operate Phase 35
Filtered Outdegree, Epoch 171, Test Phase
Filtered Outdegree
Filtered Outdegree, Epoch 171, Design Phase 7000
Integrate & Test
30
1500
Filtered Outdegree
Design
Time
1000
500
25 20 15 10 5
0
0.5
4
x 10
1 1.5 Design Num
2
0
2.5
0
0.5
1 1.5 Design Num
4
x 10
2
2.5
0
0
0.5
1 1.5 Design Num
4
x 10
2
4
Changeability decreases as design moves through lifecycle Phase Design #
171
3435
171
16701
Design
Build
Test
Operate
100
0.04
0.3
0.2
100
27.0
25.5
0.5
171
16805
100
38.2
23.6
0.4
171
Best across
100
38.2
25.5
0.5
seari.mit.edu
Path Enablers
Highly changeable designs per phase can be identified and features investigated
Design Variables
Epoch
16701
16805
16809
3435
800
800
800
1500
Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
4
4
4
3
Tx Freq (GHz)
10
10
10
10 40
Orbit Alt (km)
Ant Area (m^2)
40
100
100
Ant Type (0=AESA)
0
0
0
0
Radar Bandwidth (GHz)
1
1
1
2
Peak Power (kW)
20
20
20
10
Comm Arch (0=backbone, 1=ground)
0
0
0
1
Tactical Comm (0=yes)
0
0
0
0
Tugable (1=yes)
1
1
1
1
Maneuver package (4=baseline, 5=x2, 6=x4)
6
5
6
4
Constellation Option (1=nothing, 3=spares built)
3
3
3
1
© 2009 Massachusetts Institute of Technology
2.5 x 10
22
Identifying “Interesting” Designs 16701
16805
16809
3435
800
800
800
1500
Walker ID (53deg, 4=20 sats, 5 planes; 3=10 sats, 5 planes)
4
4
4
3
Tx Freq (GHz)
10
10
10
10
Ant Area (m^2)
40
100
100
40
Ant Type (0=AESA)
0
0
0
0
Radar Bandwidth (GHz)
1
1
1
2
Peak Power (kW)
20
20
20
10
Comm Arch (0=backbone, 1=ground)
0
0
0
1
Tactical Comm (0=yes)
0
0
0
0
Orbit Alt (km)
16701
16809
Design Variables
3435
16805
Path Enablers
Most changeable (16701) Most passive value robust (3435) seari.mit.edu
Tugable (1=yes)
1
1
1
1
Maneuver package (4=baseline, 5=x2, 6=x4)
6
5
6
4
Constellation Option (1=nothing, 3=spares built)
3
3
3
1
Both passive value robust and changeable designs can be identified in any epoch
© 2009 Massachusetts Institute of Technology
23
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
24
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 seari.mit.edu
© 2009 Massachusetts Institute of Technology
25
Thank you. Questions? Stay tuned for follow-up publications with results…
Overall Model Architecture 3 EPOCH CHARACTERIZATION
1 VALUE‐DRIVING CONTEXT Mission
Epoch Variables
6 ERA CONSTRUCTION
DEFINITION Epoch Transition Rules
Sample
Attributes
VALUE‐DRIVEN DESIGN FORUMULATION Design Vector
Context (Epoch Vector)
2
Sample
Eras
DV Transition Rules
Model
Utility
DESIGN TRADESPACE EVALUATION Cost
4
Flexibility
MULTI‐EPOCH ANALYSIS
5 seari.mit.edu
Path Selection Rules
Tradespace
Tradespace Network
Survivability
LIFECYCLE PATH
7 ANALYSIS
Epoch Data
Value Robustness © 2009 Massachusetts Institute of Technology
Path Calculator
Cost-Utility Trajectories Cost-Utility 27
