Systems Engineering Set-Based Design (SBD) and Optimization Can - - PowerPoint PPT Presentation

Systems Engineering

8/14/2018

1

Set-Based Design (SBD) and Optimization … Can they Live Together and Make Program Trade Space Decisions Better?

Author(s):

• Dr. Stephen Rapp, Senior Research Scientist, US Army TARDEC <Presenter>
• Dr. Ratna Babu Chinnam, Professor Systems Engineering, Wayne State University (WSU)
• Dr. Norbert Doerry, Technical Director, Naval Sea Systems Command Technology Office
• Dr. Leslie Monplaisir, Chairman/Professor Systems Engineering, WSU
• Dr. Alper Murat, Associate Professor, WSU
• Dr. Gary Witus, Associate Research Professor, WSU

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Outline

• “Three Minute Thesis”
• Importance & Relevance
• Research Problem

– Scope – Goals and Objectives

• Research Methodology

– PD Set Solution Logic – Quantitative Framework

• Analysis & Results
• Contributions
• Conclusion

2

Core funding: DoD STEM ASEE Doctoral Fellowship through the SMART Scholarship Program Command Sponsorship: U.S. Army RDECOM TARDEC Additional Support: NAVSEASYSCOM and MARCORSYSCOM Partial funding: Systems Engineering Research Center, OSD OUSD R&E (US), Contract Number - HQ0034-13-D-0004

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

“Three Minute Thesis”

• Problem: How do we solve a

trajectory of sequential decisions in Product Development (PD)?

– Every decision is not optimal for a point in time – Data is uncertain and fog around it

• nly yields over time, while you

are designing and developing

• Insight: Decisions need optimal

actions for design trajectory and not immediately for design itself

• Solution: We created a

Quantitative Framework that values the trajectory actions resiliently through time for PD

3

Am I even

• n the right

mountain? Starting out … “I’m going to build the best sports car ever …. My Shangri-La!” Where’s a sports car in Shangri-La?

Systems Engineering

Importance & Relevance

Philosophical to Qualitative

• Pascal’s Wager in 1664 …. “Heaven vs. Fun and ….

maybe Hell”

– One cannot judge performance by results, but by alternative costs. – Decision quality can’t be judged solely by its outcome. However, this is typically voiced by the people who fail (Taleb 2009). – Those who succeed tie it to their own smart decisions – Extending this to Product Development (PD)

• Is risk of high cost development failure worth product

breakthrough?

• Toyota … “kaizen” gradual vs. “kaikaku” breakthrough

– Set-Based Design (SBD) is an integral part of Toyota Product Development System (Liker 1999) – Toyota is more kaizen, but recognizes the need to deal with kaikaku uncertainty during development – SBD allows a gradual “necking down” of options during PD

4

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Importance & Relevance

Adding Quantitative to Qualitative

• Defense Programs are more “kaikaku” by necessity

– Uncertainty impacting programs (over budget/schedule delay) is driving SBD acceptance – Current SBD programs are expanding and there is need for quantification – SBD critical to add design flexibility & resilience

• Specific industry efforts documented SBD to deal with design uncertainty
• Design “Trade Space” exploration methods tied to SBD are being considered

– Focus: expand design trade space

• Design “Process Resilience” is well documented, both with and without SBD

– Resilience in PD ties to expanding design trade space

• Mathematical methods to model uncertainty are developed but less applied to SBD

– Current efforts are focused on domain applications or are specific techniques

• The need to model risk and uncertainty in PD is significant

– Deterministic estimation misses the mark

• Set solutions postulated to reduce uncertainty under changing requirements
• Data quality and maturity are crucial factors impacting design quality

5

Bottom line: Need a quantitative framework to utilize SBD for PD!

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem

Research Scope - Framework

6

Quantitative SBD Framework

Research and Design the Mathematics for the Framework Solution Structure: Markov Decision Process Solution Approach: Stochastic Dynamic Programming Solution Derivation and Analysis

EpochA EpochB EpochΓ EpochΩ

Core Design Data: Performance Burdens

• Size, Weight,

Power, etc.

• Costs

Risk/Uncertainty

Set Solution Data – Continuous Update/Decisions Anchored to Epochs but Flexible

Data Quality and Maturity

• ut of

Scope

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem

Research Scope – Coverage of the Product Lifecycle

7

Product Development Multiple stakeholders iteratively restricting and relaxing constraints

Production, Deployment, Operation & Sustainment (including modernization, adaptation, extension)

Acceptance Region

Set of potential future trajectories as needs change, technologies mature and funding constraints change

Initial Production

Growth Region

SBD for Continuous Modernization:

• Views “Solution” as a Specific Design and its Set of Potential Future Options
• Constraints and evaluation apply to and address not just cost-vs-capability of initial

design, but also cost-vs-capabilities of set of potential future options

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem

Goals and Objectives

8

I don’t care how your iPhone works just give it to me or else. DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

• Goals:

– Extend SBD to improve resilience of PD process with respect to changes in requirements and to uncertainties – Develop a conceptual framework to integrate quantitative analysis with SBD – Combine SBD and analytics into a new hybrid approach supporting resilient design process – Develop a current case or example as a Proof of Concept to validate the framework

• Objectives:

– Give a rigorous formulation to principle of SBD – Give an analytical approach for set adjustment decisions – Give an analytical formulation for set adjustment decisions

Systems Engineering

Research Methodology

PD Set Solution Logic

• Single design consists of individual option selections, one/subsystem
• f system to be developed
• Set Solution is a combination of any possible Point Solutions or

specific designs for PD

• Visual representation of SBD for considering which designs to develop

– Colored arcs represent designs not developed in the previous epoch – In most programs, these are possible but unlikely

• For example, SS1 in B going to SS2 in Γ requires catching up all work for D2 missed before B

9

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework - Overview

• Framework has control dimensions for time (milestones and development phases)
• High-level framework uses a stochastic process to define value, termed

Contribution-to-Design

– Contribution-to-Design is a weighted and normalized combination of metrics: performance, cost (production) and weight (physical)

• Is forward looking and calculated for all subsystem technology option choices and then “rolled up” for

higher subsystem and set solution

• Metrics have targets, termed: Design Readiness Levels
• Solution Approach: Recursive (backward) Dynamic Programming

– Bellman’s Equation with no discount to determine optimal investment actions at each milestone/epoch

• Contribution-to-Design Values modified to a Markov Decision Process Network:

– Action space: Whether or not an option should be invested in – Transition matrix: Probabilities associated with possible state to state movements

10

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Control Dimensions

• Epochs aka Milestones (E) – Discrete Time points from 𝐵 to 𝛻 where:

– 𝛻 = total number of epochs and 𝑢 is the epoch index – Design Data is updated, reviewed and then used to make forward programmatic decisions from 𝐵, 𝐶, 𝛥… 𝑢 + 1, … 𝛻

• System Designs (𝛦) – the allowable individual system designs possible from the

system trade space from 1 to 𝐸 where:

– 𝐸 = total number of allowable system designs and 𝑒 is design index – A design must include exactly one option for every subsystem or technology – Each System Design, 𝛦

𝑒 is a unique combination of technology options of exactly one per

subsystem and is both a point solution and a singleton set solution – Other set solutions are the combinations of multiple system designs

• Subsystems or Technology types (SS) – The discrete technology subsets that are

required to frame a complete system choice where:

– 𝐽 = total number of technology subsets or subsystems and 𝑗 is the technology subset or subsystem index

• Options (O) – For technologies and subsystems:

– 𝐾𝑗 = total number of options per 𝑗th subsystem and 𝑘 is 𝑗th subsystem option sub-index – 𝐿 = total number of options in the trade space – 𝑙 is the iterative vector transformation index taken from of the (𝑗,𝑘) option pairings

11

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Development Costs

• Framework calculates Development Costs for every option epoch to epoch
• Recovery Costs are calculated for options not developed in prior phases
• Finally, System Integration costs are calculated for all phases
• Framework considers following:

– Options may share certain costs with other options – Reduce or Increase System Integration costs dependent on shared development – Recovery Costs are calculated for all options where timeline permits option recovery – There are no recovery costs if new Set Solution is same as old – Recovery costs are lower if new Set Solution shares development with old – Recovery costs are higher if development needs to be made up

12

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Cost Control Equations

• For real-world application:

– Epochs design reviews determine next phase option investments – Development costs will shift from early option development to later system integration of those options

• Need to apply budget logic and cost controls to determine what

set solutions are possible to develop during next phase

13

Epochs Key Dimensions Value Calculations Development Costs (DC) A Options Set Solution CTD Options Dev (A to B) B to (Ω - 1) Options Set Solution CTD Options Dev + Recovery Costs (B to B+1) Ω - 1 Options Set Solution CTD Options Dev + SI Costs (Ω-1 to Ω) *** Final Design Set Ω Designs Point Design Value Options SI Costs (Ω to TP) for the Optimal Design (∆*) Test/Production (TP) Final Design NA NA Phases Cost Control Equations for Phase (Et to Et+1) EA to EB EB ... to … EΩ-1 EΩ-1 to EΩ EΩ to ETP Final Design SI Costs <= Pre-Test Development Budget 𝐸 𝑙 <= Phase Development Budget 𝐸 𝑙 <= Phase Development Budget 𝐸 𝑙 + 𝑒 𝐽

𝑒

<= Phase Development Budget

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Option Contribution-to-Design

• Contribution-to-Design for an option includes:

– performance/burden to target difference – variance of the option’s development

• Our framework formulation measures confidence of the option to meet Design

Readiness Levels (DRL)

– DRL is a generalization of the Department of Defense’s Technical and Material Readiness Levels – DRL reflects maturity of design relative to program targets – Without loss of generality, our illustrative example has three levels : 1-Least Ready; 2- Somewhat Ready; and 3-Fully Ready – While confidence is based on estimates, the framework allows for continuous updating as uncertainty lessens over time – By including variance, uncertainty can be properly modeled – Additionally, approach permits meta-heuristic optimization techniques for computational efficiency

• We normalize Contribution-to-Design!

14

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Option Contribution-to-Design Example

• Option CTD Example: Performance & Burdens

– Mean and Variance/Standard Deviation (SD) – Targets and Probability to Exceed Targets

15

Epoch A Option 1 Performance Weight Burden AUPC Burden CTD Weight 0.3 0.3 0.4 Current Mean 350 350 47000 Current SD 50 100 10000 DRL 1 Target 250 400 45000 DRL 2 Target 300 390 44000 P (X > DRL 1 Tgt) 0.9772 0.6915 0.4208 0.6689 P (X > DRL 2 Tgt) 0.8414 0.6554 0.3821 0.6019

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Option to Set Solution Contribution-to-Design (CTD)

• Option CTD is Base

Calculation!

• Need to value all Option

CTD (s) in a Subsystem to Create Subsystem CTD

• Repeat for Set Solution

CTD

16

Set Solution CTD Option CTD Option CTD Option CTD Subsystem CTD

See Backup Slides 31 to 33 for Math Detail

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Setup the Markov Decision Process (MDP)

• Dynamic Programming (DP) backsolve

– Initialized by calculating modified Contribution-to-Design (CTD) values – Seeds the MDP Network/reward function 𝑆 – Start from last epoch and solve to the first

• Calculate CTDV at each state, a “black box” value from which we

determine value change, reward 𝑆, from state to state

– We strip the probabilities of the set CTD to become the transition probabilities for set solution to change state(s) – The CTDV is the value at each of the MDP states (nodes)

• Creates a set of stochastic automata with utilities for DP solving

– CTD(s) for options, subsystems and set solutions were all created utilizing forward logic – Recursive DP solve requires backwards logic and a modification of CTD(s) to execute a solve to determine optimal investment set actions

17

Seriously dude? Backwards first to Shangri-La?

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Setup MDP

18

See Backup Slides 34 to 36 for Math Detail

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – State Space

• State Space is set of all possible states for problem, which is

every possible combination (Nodes in Network)

• Individual state’s dimensions are carried in a vector of size:

𝑳 = 𝑸𝒔𝒑𝒆𝒗𝒅𝒖 𝒑𝒈 𝒃𝒎𝒎 “𝑷𝒒𝒖𝒋𝒑𝒐 − 𝑵𝒇𝒖𝒔𝒋𝒅” 𝑸𝒃𝒋𝒔 𝑴𝒇𝒘𝒇𝒎𝒕 𝒚 𝑭𝒒𝒑𝒅𝒊𝒕

• Non-epoch cells hold DRLs that can vary

– Example has exactly 3 levels per option/metric combination

19

Options Metrics P W C P W C P W C P W C StateA 1 1 1 1 1 1 1 1 1 1 1 1 Options Metrics P W C P W C P W C P W C StateΩ 3 3 3 3 3 3 3 3 3 3 3 3 A1 A2 B1 B2 A1 A2 B1 B2

For example, a completely dense network would = 312 * 4 = 2,125,764 state space positions

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Action Space

• Action Space is a matrix of options

(columns) and all possible combinations

• f option sets (rows)
• An option is invested in (1) or not

invested in (0) for next phase’s development

• Additionally, Action Space can be

expanded to cover skipped investments – A skipped investment would be marked by a (2) – Rather rare occurrence in real world but needs to be considered

20

Actions A1 A2 B1 B2 a1 a2 1 a3 1 a4 1 1 a5 1 a6 1 1 a7 1 1 a8 1 1 1 a9 1 a10 1 1 a11 1 1 a12 1 1 1 a13 1 1 a14 1 1 1 a15 1 1 1 a16 1 1 1 1

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Reward or Value Function

• Take the state of the option and the best target state,

then calculate:

𝑷𝒒𝒖𝒋𝒑𝒐 𝑫𝒑𝒐𝒖𝒔𝒋𝒄𝒗𝒖𝒋𝒑𝒐 − 𝒖𝒑 − 𝑬𝒇𝒕𝒋𝒉𝒐 𝑾𝒃𝒎𝒗𝒇 𝑫𝑼𝑬𝑾 = 𝟐– (( 𝟒 − 𝑸𝑾 𝟒𝑸𝑿𝒖) + ( 𝟒 − 𝑿𝑾 𝟒𝑿𝑿𝒖) + ( 𝟒 − 𝑫𝑾 𝟒𝑫𝑿𝒖))/𝟗 – Performance, Weight and Cost Values (𝑄𝑊, 𝑋𝑊 and 𝑊) are DRL (s) for states: 1, 2, or 3

• We apply the same logic to value Subsystem CTDV and

Set Solution CTDV

• Metric and subsystem weights are the same weights

from the CTD

21

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Transitions

• Transitions are possible state to state changes (Arcs)
• Transition probabilities are probabilities from CTD, CTDP
• CTD to CTDV acts as black box calculation for MDP Network
• Investment actions change MDP Transitions

22

Epoch A B Γ Ω 1 2 9 4 5 3 8 7 6 10

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – DP Solve

• Backsolve using Bellman’s Equations (see Backup Slides)
• Find Expected Value for all Actions to a State Node
• Store Best Action and Expected Value for each State Node
• Repeat process backwards; instead of calculating Expected Value, take

best Expected Value from previous Backsolve

23

Γ Ω 9 4 5 8 7 6 10

What’s the best action and its Expected Value for each state from all earlier states?

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Conclusions /Contributions

• Developed a framework to support more resilient PD

– Expanded qualitative structures of Set-Based Design into a quantitative framework – Introduced stochastic processes to cover uncertainty and risk – Utilizing Markov Decision Process allows network view of set solutions and their values as they change over time

• Solution structure does not fall into the process brittleness of point solution structures

– Adding stochasticity allows to directly model variance – Model set value quantitatively for first time – Optimization is toward budget actions and not zeroing in on specific solutions

• Framework structure is modular and accessible for changes

– Dependency can be modeled and added with little change to solution structure of MDP with recursive Dynamic Programming – Framework data structures are either same or compatible with mainstream PD

24

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Limitations & Future Research

• Assumed independence for design options

– This is a seminal start to develop an initial framework – Dependency of design elements need to be researched to determine impact on trade space

• Problem Size

– Size of trade space for design grows geometrically – Use of current optimization and simulation techniques can mitigate this, but needs to be developed

• Other Systems Engineering processes that support PD need to be considered to be

integrated with the framework:

– Design Structure Matrices (DSM) – Trade Space Simulations – Systems Modeling Language (SysML)

• Integration With Core Mathematical Optimization Processes and Software

– Implementation at TARDEC for Army, Marine and Joint Armored Combat Vehicle Development – Support Sharing of Research to NAVSEASYSCOM and MARCORSYSCOM and potential Air Force partners

25

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Publication Pursuits

• Three Journal Article Set
• Article #1 – Approved by the INCOSE SE Journal

– Documents the Framework and Results – Submitted in May 2017 – Approved for Publication for 3Q/2018

• Article #2 – Under Revision for the INCOSE SE Journal

– Design Structure Matrix (DSM) Implementation – Reviewed, Revisions are Required – Target Publication 3Q/2019

• Article #3 – Will Document TARDEC’s Further Development of its Whole

System Design Space Optimization with this SBD Framework – MOR Journal (Target Journal) – SBIR Effort In Process

• Dissertation URL:

– https://digitalcommons.wayne.edu/oa_dissertations/1861/

26

MOR Journal

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Backup Slides

• Fuller Literature Review: Research Problem
• More on the Research Methodology
• MDP Policy Equation and Graphic
• Dynamic Programming: Bellman’s Equations

27

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem

Adding Quantitative to Qualitative

• Defense Programs are more kaikaku by necessity

– Uncertainty impacting programs is driving SBD acceptance (Singer 2009) – Current SBD programs are expanding and there is need for quantification (Mebane 2011 and Martin 2012)

• Half of all programs are overrun or not moved to production!

– SBD critical for design flexibility & resilience (Doerry 2012)

• US Navy Design Manual implies that SBD adds resilience to design process
• Specific industry efforts documented SBD formulations to deal

with design uncertainty (Madhavan 2008, Gray 2012)

– Examples are highly focused and not applicable across entire PD process

28

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem

Adding Quantitative to Qualitative

• Design “Trade Space” exploration methods tied to SBD and their need are

being considered (Gries 2004, Thangaraj 2010, McKenney 2012) – Focus is on need to expand design trade space – Use of SBD to help is viewed as promising

• Design “Process Resilience” is a well documented need, both with and

without SBD (Fiksel 2003, Azizian 2009, Batini 2009, Daskiliwicz 2012, Dremont 2013, Holland 2013, Spero 2014) – Resilience in PD ties to expanding design trade space

• Mathematical methods to model uncertainty are developed but are not

applied to SBD (Bertsimas 2004, Goel 2006, Fortunato 2010, Azadian 2011) – Current efforts are focused on domain applications or are specific techniques

29

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Problem …

Adding Quantitative to Qualitative

• The need to model risk and uncertainty in PD is significant

(Ratiu 2004, Bassler 2011)

– Deterministic estimation misses the mark – Understanding historical data yields better estimates both deterministically and stochastically

• Use of “set solutions” to reduce uncertainty under changing

requirements is postulated (Oehman 2012)

• Data quality and maturity are crucial factors impacting design

quality (Wang 1995, Zhou 2011)

– Data maturity directly impacts PD programs since design datum to datum vary in quality

30

Bottom line: Need a quantitative framework to utilize SBD for PD!

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Option Contribution-to-Design (CTD)

31

This is the Contribution-to-Design formulation for an option at a specific Epoch looking forward: CTD = 𝜕𝑗 ∙ 𝑄[𝑎𝑗]

𝑜 1

(1) where 𝑄 is the probability lookup of the 𝑎𝑗 value (defined below), 𝜕𝑗 is the weight of the externality (performance or burden parameter), and 𝑗 is the index for all 𝑜 externalities. 𝜕𝑗

𝑜 1

= 1 (2) 𝑎𝑗 = (𝜈𝑗 − 𝑀𝑗)/𝜏𝑗 where: (3) 𝑀 = Performance or Burden Requirement Target Value {𝜈, 𝛽} = System or Sub-system externality probability distribution In the table we show an example of Option 1’s individual Contribution-to-Design calculations for meeting Readiness Levels 1 and 2. In this example we “weight” the three metrics (performance, physical weight burden and AUPC burden). The Contribution-to-Design is then a weighted value of the three probability measures.

Epoch A Option 1 Performance Weight Burden AUPC Burden CTD Weight 0.3 0.3 0.4 Current Mean 350 350 47000 Current SD 50 100 10000 DRL 1 Target 250 400 45000 DRL 2 Target 300 390 44000 P (X > DRL 1 Tgt) 0.9772 0.6915 0.4208 0.6689 P (X > DRL 2 Tgt) 0.8414 0.6554 0.3821 0.6019

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – Subsystem CTD

32

For Set Solutions with more than one option per subsystem, it is expected that the multiple

• ptions reduce total design uncertainty should a single option fail to meet targets.

This is the cornerstone of SBD and has been effectively utilized for over twenty years, even if not quantitatively proven. For the framework, we assume that the multiple option designs are independent since we only calculate the probabilities of exceeding targets of the readiness levels. Given independence, the Contribution-to-Design formulation for multiple

• ptions in a subsystem is:

𝑈𝐸𝑗,𝑆𝑀𝑢→𝑆𝑀𝑢+1 = 1 − 1 − 1 𝑦𝑗,𝑘,𝑢,𝑆𝑀 𝑢 𝑄𝑠

𝑗,𝑘 𝑆𝑀𝑢 → 𝑆𝑀𝑢+1 𝑈𝐸𝑗,𝑘 ,𝑆𝑀𝑢→𝑆𝑀𝑢+1 3 𝑆𝑀𝑢=1 𝑛𝑗 𝑘 =1

1 𝑦𝑗,𝑘,𝛻 ,𝑆𝑀 𝑢 : 1 if option 𝑘 of subsystem 𝑗 is selected and its current state in 𝛻 is 𝑆𝑀𝑢, 0

• therwise.

where 𝑈𝐸𝑗 is the subsystem CTD for the 𝑗th subsystem. 𝑘 is the index for the option members, from 1 to 𝑛, where 𝑛 is the total number of options in the same subsystem that are in the set solution. For example, let’s assume we have a subsystem with two options in Epoch 𝐶, both moving forward to Design Readiness Level of 3. Assuming their likelihood to move up is respectively 0.7 and 0.1 the following calculation applies: CTD (Subsystem 3, Epoch 𝐶 to Epoch 𝛥, DRL 3) = {1 − ((1 − 0.7) ∙ (1 − 0.1))} = {0.73}.

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Research Methodology

Quantitative Framework – System CTD

• The total CTD for the set solution must then consider the individual

subsystem CTD’s at the epochs.

– Depending on program situation, it may be important to weight the subsystem CTD’s differently.

• For example, an automotive program may value its engine subsystem higher than its

entertainment system for its sports car while it reverses that weight value for its minivan.

• The CTD for the entire set solution at an Epoch moving to given Design

Readiness Level during the next phase is:

33

For this example, we assume the set includes: Options 2 through 6. Note: Subsystems B and C calculations include both options, i.e. 0.73 Instead of 0.7 or 0.1.

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

MDP - Policy (π) Mapping from S to A

34

Following a policy π :

• 1. Determine the current state S
• 2. Execute action π(S)
• 3. Go to step 1.

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Dynamic Programming (DP) Bellman Equations

35

Bellman equations relate the value function to itself via the problem dynamics. For the discounted objective function, V

s = R(ss) + T sss

V

s sS

V

*s =

  MAX R(sa) + T sas

V

*s a A sS

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.

Systems Engineering

Dynamic Programming (DP) Bellman Equations

36

Finite-horizon Bellman Equations

Finite-horizon values at adjacent horizons are related by the action dynamics V

0s = R(ss)

DISTRIBUTION STATEMENT A. Approved for public release; distribution unlimited.