Engineering Elegant Systems Engineering at the System Level Consortium Team UAH George Washington University Iowa State Texas AampM University of Colorado at Colorado Springs UCCS Missouri University of SampT ID: 787356
Download The PPT/PDF document "22 June 2017 Michael D. Watson, Ph.D." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
22 June 2017Michael D. Watson, Ph.D.
Engineering Elegant Systems: Engineering at theSystem Level
Consortium Team
UAH
George Washington University
Iowa State
Texas
A&M
University of Colorado at Colorado Springs (UCCS)
Missouri University of S&T
University of Michigan
Doty Consulting Services
AFRL
Wright
Patterson
Slide2OutlineUnderstanding Systems EngineeringDiscipline integration ModelingSystem State Variables and Goal function treeState Analysis modelSystem Value ModelProducts
Engineering Elegant Systems: Theory of Systems EngineeringEngineering Elegant Systems: The Practice of Systems EngineeringSummary
2
Slide3Understanding Systems Engineering
Slide4MotivationSystem Engineering of Complex Systems is not well understoodSystem Engineering of Complex Systems is ChallengingSystem Engineering can produce elegant solutions in some instancesSystem Engineering can produce embarrassing failures in some instancesWithin NASA, System Engineering does is frequently unable to maintain complex system designs within budget, schedule, and performance constraints
“How do we Fix System Engineering?”Michael D. Griffin, 61st International Astronautical Congress, Prague, Czech Republic, September 27-October 1, 2010Successful practice in System Engineering is frequently based on the ability of the lead system engineer, rather than on the approach of system engineering in general
The rules and properties that govern complex systems are not well defined in order to define system elegance
4 characteristics of system elegance proposed as:
System Effectiveness
System Efficiency
System Robustness
Minimizing Unintended Consequences
4
Slide5ConsortiumResearch Process Multi-disciplinary research group that spans systems engineering areas Selected researchers who are product rather than process focusedList of Consortium MembersMichael D. Griffin, Ph.D.Air Force Research Laboratory – Wright Patterson, Multidisciplinary Science and Technology Center: Jose A. Camberos, Ph.D., Kirk L. Yerkes, Ph.D.
George Washington University: Zoe Szajnfarber, Ph.D. Iowa State University: Christina L. Bloebaum, Ph.D., Michael C. Dorneich, Ph.D.Missouri University of Science & Technology: David Riggins, Ph.D.NASA Langley Research Center: Peter A. Parker, Ph.D.Texas A&M University: Richard Malak, Ph.D.
Tri-Vector Corporation: Joey Shelton, Ph.D., Robert S. Ryan
The University of Alabama in Huntsville: Phillip A. Farrington, Ph.D., Dawn R. Utley, Ph.D., Laird Burns, Ph.D., Paul Collopy, Ph.D., Bryan Mesmer, Ph.D., P. J. Benfield, Ph.D., Wes Colley, Ph.D.
The University of Colorado – Colorado Springs: Stephen B. Johnson, Ph.D.
Doty Consulting Services: John Doty, Ph.D.
The University of Michigan: Panos Y. Papalambros, Ph.D.
Previous Consortium Members
Stevens Institute of Technology – Dinesh
Verma
Spaceworks
– John Olds (Cost Modeling Statistics)
Alabama A&M – Emeka Dunu (Supply Chain Management)George Mason – John Gero (Agent Based Modeling)Oregon State – Irem Tumer (Electrical Power Grid Robustness)Arkansas – David Jensen (Failure Categorization)Massachusetts Institute of Technology: Maria C. Yang, Ph.D.The University of Texas, Arlington: Paul Componation, Ph.D.
35 graduate students and 5 undergraduate students supported to date
5
Slide6Understanding Systems EngineeringDefinition – System Engineering is the engineering discipline which integrates the system functions, system environment, and the engineering disciplines necessary to produce and/or operate an elegant system.Elegant System - A system that is robust in application, fully meeting specified and adumbrated intent, is well structured, and is graceful in operation.
6
Primary Focus
System Design and Integration
Identify system couplings and interactions
Identify system uncertainties and sensitivities
Identify emergent properties
Manage the effectiveness of the system
Engineering Discipline Integration
Manage flow of information for system development and/or operations
Maintain system activities within budget and schedule
Supporting Activities
Process application and execution
Slide7Systems Engineering PostulatesPostulate 1: Systems engineering is product specific.Postulate 2: The Systems Engineering domain consists of subsystems, their interactions among themselves, and their interactions with the system environmentPostulate 3: The function of Systems Engineering is to integrate engineering disciplines in an elegant mannerPostulate 4: Systems engineering influences and is influenced by organizational structure and culture
Postulate 5: Systems engineering influences and is influenced by budget, schedule, policy, and lawPostulate 6: Systems engineering spans the entire system life-cyclePostulate 7: Understanding of the system evolves as the system development or operation progresses
7
Slide8System Engineering HypothesesHypothesis 1: If a solution exists for a specific context, then there exists at least one ideal Systems Engineering solution for that specific contextHypothesis 2: System complexity is greater than or equal to the ideal system complexity necessary to fulfill all system outputsHypothesis 3: Key Stakeholders preferences can be accurately represented mathematically
8
Slide9Systems Engineering PrinciplesPrinciple 1: Systems engineering integrates the system and the disciplines considering the budget and schedule constraintsPrinciple 2: Complex Systems build Complex SystemsPrinciple 3: The focus of systems engineering during the development phase is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the systemSub-Principle 3(a): Requirements are specific, agreed to preferences by the developing organizationSub-Principle 3(b): Requirements and design are progressively defined as the development progresses
Sub-Principle 3(c): Hierarchical structures are not sufficient to fully model system interactions and couplingsSub-Principle 3(d): A Product Breakdown Structure (PBS) provides a structure to integrate cost and schedule with system functionsPrinciple 4: Systems engineering spans the entire system life-cycleSub-Principle 4(a): Systems engineering obtains an understanding of the systemSub-Principle 4(b): Systems engineering models the system
Sub-Principle 4(c): Systems engineering designs and analyzes the system
Sub-Principle 4(d): Systems engineering tests the system
Sub-Principle 4(e): Systems engineering has an essential role in the assembly and manufacturing of the system
Sub-Principle 4(f): Systems engineering has an essential role during operations and decommissioning
9
Slide10Systems Engineering PrinciplesPrinciple 5: Systems engineering is based on a middle range set of theoriesSub-Principle 5(a): Systems engineering has a mathematical basisSystems Theory BasisDecision & Value Theory Basis (Decision Theory and Value Modeling Theory)Model BasisState Basis (System State Variables)Goal BasisControl Basis (Control Theory)
Knowledge Basis (Information Theory)Predictive Basis (Statistics and Probability)Sub-Principle 5(b): Systems engineering has a physical/logical basisSub-Principle 5(c): Systems engineering has a sociological basisPrinciple 6: Systems engineering maps and manages the discipline interactions within the organization
Principle 7: Decision quality depends on the system knowledge represented in the decision-making process
Principle 8: Both Policy and Law must be properly understood to not overly constrain or under constrain the system implementation
Principle 9: Systems engineering decisions are made under uncertainty accounting for risk
10
Slide11Systems Engineering PrinciplesPrinciple 10: Verification is a demonstrated understanding of all the system functions and interactions in the operational environmentIdeally requirements are level and balanced in their representation of system functions and interactionsIn practice requirements are not balanced in their representation of system functions and interactionsPrinciple 11: Validation is a demonstrated understanding of the system’s value to the system stakeholdersPrinciple
12: Systems engineering solutions are constrained based on the decision timeframe for the system need11
Slide12Sociological Concepts in Systems EngineeringSpecification of Ignorance is important in the advancement of the understanding of the systemConsistent use of Terminology is important for Communication within the OrganizationOpportunity StructuresProvide opportunity to mature ideasTask teams, working groups, communities of practice, etc.Socially Expected Durations will exist about the project
Both Manifest and Latent Social Functions exist in the organizationSocial Role SetsIndividuals have a set of roles for their positionCultural Subsets will formi.e., disciplines can be a subset within the organization
Insider and Outsider attitudes can form
Be Aware of the Self-Fulfilling Prophecy, Social Polarization
Reconsiderations Process (i.e.,
Reclama
Process)
Provides ability to manage social ambivalence
Must be able to recognize social beliefs that may be contributing to the disagreement
Helps to avoid putting people in to social dysfunction or complete social anomie
Conformity
Innovation
RitualismRetreatismRebellion12
Slide13Information FlowInformation Flow through a program/project/activity is defined by Information TheoryOrganizational communication pathsBoard StructureDecision Making follows the First PostulateDecision Process is specific to the decision being madeTracked 3 SLS CRs, with 3 separate task team processes, all had equally rated effectiveness
13
Margin is maintained by the Organization, not in the margin management tables
Biased Information Sharing
Margin Management is focused on Managing the Disciplines (informed by the System Integrating Physics)
SLS Organizational Structure was defined by the LSE as a recommendation to the Chief Engineer and the Program Manager
Slide14Discipline Integration Models
Goal Function Tree (GFT)
Organizational
Structure &
Mapping
System Functions
MagicDraw
Enterprise (
SysML
)
Matlab
Matlab
StateFlow
JAVA
Anylogic
Extend
Allow systems engineers to:
Understand information flow through the development and/or operations organization
Integrate discipline information into a system level design
Analyze information flow, gaps, and blind spots at the System level
Agent Based Model (ABM)
System Dynamics Model
Goals
Value Model
Value
Attributes
Discrete Event Simulation
Organizational
Values
Slide15What is System Dynamics?
A methodology that has been used extensively in business and engineering environments to
develop better understanding of the interactions that define the operation and behavior of complex systems
Based on the concept that
complex systems can be sub-divided into simpler, more manageable components
The
high-level operation of an overall system can be defined by examining and defining the behavior and interactions of the individual components.
“While it is often difficult for scientists to intuitively understand the overall operations of complex systems there is often a great deal of in-depth knowledge on the operations of the structural components that constitute the system.”
Slide16Tools and Methodologies
Tools and techniques have been developed using the System Dynamics methodology that make it possible to efficiently decompose complex systems and to quickly set-up and test models of system operation.
Tools promote understanding through visual diagramming and modeling.
Slide17Roles of System Dynamics
Creates a
Structured View
of the Problem Space.
Allows
Visualization and Testing
of Assumptions and Postulated Relationships.
Dynamically Traces
Potential Results of Modifications.
Communicates
Operational Understanding to Others.
Slide18System Dynamics is frequently used to support long-term strategic decision-making
Modeling of strategic decision space often requires at least some tactical level modeling
Art is in decomposing model to a level that captures driving relationships but is not too complex to accurately or efficiently model
Stochasticity is often an important driver in system behavior
Typical strategic models are run probabilistically, with major drivers represented as prob. distributions
Strategic Analysis
Slide19Methodology has been applied across many disciplines which involve complex systems with limited high-level operational understanding:
- Business and monetary systems
- Power generation and distribution
- Information technology networks
- Aircraft /spacecraft design and operation
- Nuclear reactor operation
- Military
operations
- NASA STS/ISS Transportation/Operations Analysis
Develop
a methodology to evaluate strategic level options for the re-supply and operation of the ISS-STS
system
Evaluate various potential transportation
systems
Analyze
impact (financial and performance) on Exploration System
Applications
Slide20STS-ISS Transportation / Operation Analysis
Slide21ISS-STS Transportation / Operations Analysis
Slide22Methods of System IntegrationGoal: Techniques to Enable Integrated System Design and Assessments by the Systems Engineer
Slide23System Models Contain an Understanding of the System
Goal FunctionTree (GFT)
Goals
Value Model
System State Transition
Model
System Functions &
State Variables
System Integrated
Physics Model
(System Exergy)
Discipline Physics
Models
System Functions &
State Variables
Engineering
Statistics
State
Variables
Multidisciplinary Design
Optimization (MDO)
MagicDraw
Enterprise (
SysML
)
Matlab
Matlab
StateFlow
Microsoft
Excell
Allow systems engineers to:
Define system functions based on the system state variables
Understand stakeholders expectations on system value (i.e., capabilities)
Integrate discipline engineering models into a system level physics based model (e.g., system exergy)
Design and Analyze system responses and behaviors at the System level
Slide24System Design and Integration
Slide25System Physics and System Integrating PhysicsGoal: Utilize the key system physics to produce an elegant system design
Slide26System Integrating PhysicsConsortium is researching the significance of identifying and using the System Integrating Physics for Systems EngineeringFirst Postulate: Systems Engineering is Product Specific.States that the Systems are different, and therefore, the Integrating Physics for the various Systems is differentLaunch VehiclesThermodynamic System
SpacecraftIntegrated through the bus which is a thermodynamic systemEach Instrument may have a different integrating physics but integrates with the bus thermodynamicallyOther Thermodynamic SystemsCrew ModulesFluid Systems
Electrical Systems
Power Plants
Automobiles
Aircraft
Ships
Not all systems are integrated by their Thermodynamics
Optical Systems
Logical Systems
Data Systems
Communication Systems
Biological SystemsSystem Integrating Physics provides the engineering basis for the System Model
Slide27Spacecraft Integration Model
27
Slide28System State VariablesGoal: Utilize system state variables to understand the interactions of the system in relation to system goals and system execution
Slide29System State ModelsSystem Stage Models represent the system as a whole in terms of the hardware and software states that the system transitions through during operationGoal Function Tree (GFT) Model“Middle Out” model of the system based on the system State VariablesShows relationship between system state functions (hardware and software) and system goalsDoes not contain system physical or logical relationships and is not executableSystem State Machine Model
Models the integrated State Transitions of the system as a whole (i.e., hardware states and software states)Confirms system functions as expectedChecks for system hazardous, system anomalies, inconsistent state progression, missing states, improper state paths (e.g., short circuits in hardware and/or software design)Confirms that the system states progress as stated in the system design
Executable model of system
29
Slide30What is the “Discipline of Systems Engineering” (DSE)?A new kind of system modeled on classical engineering disciplinesSee 2 papers on DSE listed in backupThe bases (systems, model, state/function, goal, control, value, knowledge, statistical) provide theoretical background for the introduction of a suite of models as the means by which
systems engineering defines and analyzes systemsThe model suite implement the theoretical ideas inherent in the basesThe model suite should at a minimum replicate, eventually at higher fidelity and lower cost, what systems engineering currently can achieve
Lower cost depends on development of tools and automation
DSE
will
be able to do more than what
traditional systems engineering
currently can achieve
30
Slide31Loop-Spiral of DSE Representations31
Physical Simulation Models
Value-Decision
Model
Concept of
Operations
Model
State Machine Model
Pattern Recognition and Anomaly Detection
Goal-Function
Tree
Fault Tree
Design Model
Failure Propagation Model
Physical Containment Model
Organization Hierarchy Model
Anomaly Investigation
Performance Models
Rounded boxes
are functions,
not models.
Tests
Models of Preference
Models of Intention
Models of Design
Models of Agency
Models of Failure
Models of Behavior
Cost & Schedule Models
Design
Optimization
Slide32What is a Goal-Function Tree?A top-down hierarchical decomposition of system goals and functions --- hierarchies are models of “intention”Arranged by major system phase/configuration, Defines the functions the system must perform and goals the system must achieve for the system to successfully perform its mission/objectivesRelationship between goals and functions defined through rigorous use of state variablesThe GFT extends the classical
systems engineering function decomposition through the use of state variables, which makes the GFT causally, physically correct
Slide33State Variable MethodologyState variables are defined as inputs and outputs to functions: y(t)=f(x,t)x = inputs to the functions ff transforms the inputs into the outputs yGoals = Requirements = define intended
range of the output state variables yFailure = state (value) of output state variable y is out of intended rangeState variables enforce strong connection of the functional decomposition to the system’s physical laws and causationThe state variables
exist
in both
functional
and design
representations, and enable formal connection between the two
33
Function f
≤
≤
G
Nominal and Off-Nominal GoalsFor every nominal goal there is the possibility of an off-nominal goal, which is activated if the nominal goal is not achievedValue (state) of state vector y goes out of intended rangeIf a new off-nominal goal is identified, this is an operational Fault Management goal, with associated off-nominal functions to detect or predict failure, and respond
NominalFunction f
≤
≤
G
≥
, or
≥
Off-Nominal
Function
OR failure occurs
Slide35Why Does NASA Space Launch System Build & Use a Goal Tree?Used for Fault Management / System Health ManagementThe “Dark Side” of Systems EngineeringDoes SLS detect failures properly in all SLS-caused failure scenarios that threaten the crew?i.e. failure detection coverage and failure scenario definition
What is the relationship of crew-threatening behaviors to each other, to system goals, and to potential detections?What is the optimal distribution of Fault Management (FM) detections and responses?Generally, the smallest number of detections that cover the widest set of threats to goals
Early
in a program, detailed design and related FMEAs
(failure modes and effects analyses) do
not exist, but need to start FM early in design phase
This must be a top-down analysis based on goals and intended functions, not just on design (SLS is only partly heritage
)
For
a complex system, it is impossible to determine all possible ways the system can go wrong, but we can and should be able to specify completely what must go “right”!
Need to base SHM/FM design in part on protecting the functions needed to succeed, regardless of how they might
fail
Slide36Ascent/Abort GFT Example
Slide37GFT-based FM Analysis #137Every unique path up the GFT from bottom to top can be associated with a failure scenario
This does not generate all possible failure scenariosGFT paths are only nominal paths, but failures can create new off-nominal paths, such as structure breakage or electrical short-circuitsScenario definition also requires a fault tree, not just a success tree, but this fault tree must be based on the same state variable methodology as the
GFT
Failure detection coverage is determined by identifying all paths that have at least one failure detection along the path, and conversely for any non-covered paths
Nuance: when the same state variable exists in more than one
GFT
location,
it often
indicates a different requirement / range constraint levied on the same state variable: example---acceleration constrained by need to protect the crew, the crew capsule structure, and the launch vehicle structure
When this occurs, it is possible that the threshold values set for the failure detection associated with the state variable can be set to the wrong value; it needs to be set to the tightest requirement
Slide38GFT-based FM Analysis #238Optimization of failure detection & response based on the distribution and relationship of failure detections along GFT pathsAt least one failure detection should exist along every GFT pathWhen more than one failure detection exists along a GFT path, then there is redundant detection for a given
scenario.These could indicate excess redundancy, and this should be assessed. It could be that the detections are needed to cover other scenarios.Failure response effectiveness is based on the race condition of the FM response speed compared to the failure effect propagation rate.The latter are related to the types of physics indicated by the state variables along the GFT paths (note not all failure paths exist in the GFT, see previous page).
Examples
: electrical state variables indicate electron flows with characteristic speeds; these differ from pressure and temperature state variables and their characteristic times for fluid flows.
Some paths have failure probabilities higher than other paths. For these it is appropriate to have detections “lower down” in the GFT to make more response time available before compromise of high-level goals.
Slide39Using the GFT within DSEGFT to Fault TreesLogical complement of GFT, then add new failure branchesFault trees have more branches than success trees, because failures create new “off-nominal paths” in the systemMore generally, failure space models are the “more complete” system models than success space modelsGFT-Functions & Requirements to Organizations and Organization InterfacesState variables keyGFT
Design Model Physical Containment Model (Configuration Items) Organization ModelNominal and Failure Scenarios for Requirement VerificationPaths from bottom to top of GFTs and Fault Trees, when implemented with state variablesTest procedures and observables extracted from trees
39
Slide40Traceability from Functions to Organizations; GFT to Fault Trees40
Slide41ConclusionGFT is a central representation of systems engineeringA key representation early in the design process to define intention in a physically accurate wayPhysical, causal accuracy enables its use for many more purposes than is possible for a classical functional decompositionGFT being successfully used today on NASA SLS to support the design of Fault Management (System Health Management, FDIR (Failure Detection, Isolation, and Response)
GFT can be and will be used for many more purposes in the futureRequirements traces, generation of fault trees, generation of ICDs/IRDs41
Slide42Booster – CS Ascent GFT
System Works
Slide43State Analysis Foundations
Ares-OrionCommunication
During Aborts
NESC Toyota
Investigation
LADEE FM
Software
Development
LADEE FM
Operations
SLS
M&FM
Analysis
ORION
ARES
Model Answers What if Scenario
After Orion Requests Auto-Safe Authority, Communication between Orion and Ares is Lost and Ares Exceeds Auto-Safe Threshold:
Ares:
Abort condition exceeds the auto-safing threshold. Because Orion has the auto-safe authority, Ares sends an “auto-safe authority pass-back request” and waits for Orion to send receipt. (Same as in “nominal” scenario)
Orion:
Because communication is severed between Ares and Orion, Orion is not aware of the auto-safe authority request and remains in prior states.
Ares:
Ares can NOT perform safing actions.
Slide44System State Machine ModelThe state analysis model is split into two main components:Manager software modelSystem PlantModeled using MATLAB StateflowAllows the software model to look like the SysML Activity DiagramsAllows the
SystembPlant to be modeled as State MachinesAllows those two models to interact with each other within the MATLAB environmentFacilitates the ability to generate custom analysis toolsReads in command sequence to execute model
44
Slide45State Analysis Model for SLS M&FM
Commands
From Launch
Countdown Doc
Control
(
SysML
to Stateflow)
Plant
(State Machines)
Commands
Sensor
Values
Faults
Physics Values
14% of R12 modeled
Over 7,200 Transitions in the Vehicle and Software
Over 3,500 States in the Vehicle
Slide46What Comes from a State Analysis Model?
Open-Loop Commands fromLaunch Countdown Doc
Control
(
SysML
to Stateflow)
Plant
(State Machines)
Commands
Sensor Values
Slide47State Analysis GUIs
Slide48State Analysis Results
Slide49System ValueGoal: Utilize system state variables to understand the interactions of the system in relation to system goals and system execution
Slide50System Value ModelA System Value Model is a mathematical representation of Stakeholders Preferences (Expectations) for the systemThe basic structure is straight forwardThe sociology/psychology of representing the Preferences can be a challengeThe System Value Model is the Basis of System Validation!!!The Requirements and Design Models form the basis of System VerificationThe System Value Model forms the basis of System Validation
Constructing an SLS Value Model to compare to System Validation resultsCan expand to Integrated Stack with input from MPCV and GSDOSystem Value model also provides basis for a measure of System RobustnessHow many mission types are supported by the system?
50
Slide51Integration with the Capability ModelCongressional Model
SLS AttributesMission 1
Mission 2
Mission 3
Capability Value
Development Cost
Slide52𝑌𝑇 = 𝐴𝑅∗[𝛿∗𝐾
𝑇(𝜎−1)/𝜎+(1−𝛿)∗𝐿
𝑇
(𝜎−1)/𝜎
]
𝜎/(𝜎−1)
+Other Preferences
𝑌
𝑇
= Total output (Best Value from substituting
𝐾
𝑇
and 𝐿
𝑇)𝜎 = Elasticity of Substitution𝛿 = Distribution Parameter
Value between 0 and 1
𝐴
𝑅
= Productivity Factor
𝐾
𝑇
= Value of capital/services from Program 1 (SLS)
Societal Benefits, Resource Value, and New Information from program 1
𝐿
𝑇
= Value of capital/services from Program 2 (Other)
Societal Benefits, Resource Value, and New Information from program 2
Production Function
Slide53Fundamental ObjectivesValue model must quantitatively answer the question: “How does the SLS contribute to NASA’s top-level objectives?”Concrete contributions of the SLS are shown below as “sub-goals”. Note that SLS contributes to the four positive objectives indirectly (for the most part) by enabling missions – the missions themselves are the actual engines of value generation.Prior work on launch vehicle value models is in the context of specific missions – these value models, while useful, are really value models for the missions, not the launch vehicle itself.
A value model for the SLS should value the mission-enabling capability of the vehicle in the generic sense.
Slide -
53
Enable Missions
Increase Military Capability
Support Economic Growth
Further Scientific
Knowledge
Create Jobs & Support Industry
Minimize Negative Impacts
Minimize Environmental Damage
Minimize Loss of Life
Generate National Prestige
Impress other Nations
Impress Public
Sub-Goals
Top-Level Objs.
Impress other Nations
Impress the Public
Create Jobs & Support Industry
Minimize Environmental Damage
Minimize Loss of Life
Enable Missions
Slide54Constructing the Value ModelSlide - 54A generic value model maps a design, described by an envelope of top-level attributes, to a scalar value.This model can (and should) be capable of accepting uncertain attributes and propagating them through to output an uncertain value.This uncertain value can then be adjusted for risk attitude if desired, or (if decision-maker is risk-neutral) the expected value can be used as the final “score” for the design.
A proposed valuation paradigm for the mission enabling capability of SLS should have two distinct components:Capability model (from system behavioral models – “what can it do?”)Value model (from preference elicitation – “how does this benefit us?”)
Capability Model
(physics, software, etc.)
Top-level Attributes
Value Model
(preferences)
Design variables, environmental variables, operational variables
(includes uncertainties)
System Value
Lower
-level Attributes
Slide55Capability Model
(physics, software, etc.)
Top-level Attributes
Value Model
(preferences)
Design variables, environmental variables, operational variables
(includes uncertainties)
System Value
Lower
-level Attributes
Constructing the Value Model
Modifications to basic value model framework for SLS:
Because the SLS does not create value directly (instead enabling missions that create value), the basic value model framework must be modified.
Instead of mapping capability directly to value, instead capture all relevant capabilities of the vehicle and interface them with a portfolio of individual mission value models.
Slide -
55
Slide56The Capability EnvelopeThe first step in constructing the value model is to determine the appropriate abstractions for capturing the capabilities of any given launch vehicle.What are the “top-level attributes” for a launch vehicle?A top-level attribute is defined as any system attribute that directly impacts value delivery – or to put it another way, any system attribute that a potential “customer” of SLS might care about.It is important to identify which system attributes are top-level attributes.Top-level attributes (such as cost, payload mass to orbit, and weather envelope) are derived from other attributes (such as materials used, engine specific impulse, and controllability) via various behavioral models.Any given system design is represented by an N-dimensional envelope in top-level attribute space.
This envelope is here called the “capability envelope”.It is then mapped to value by interfacing with mission value models.Slide -
56
Slide57The Capability EnvelopeThe capability envelope is the fundamental abstraction that allows for valuation of any given launch vehicle design.Why an envelope specifically?Systems are commonly represented with vectors in attribute space.“Envelope” implies instead a bounded region of attribute space.For many top-level attributes, a vector is sufficient to represent capability.However, certain relationships should be expressed as continuous relationships or envelopes in order to accurately model value.Definition of “capability envelope”:
Slide -
57
The
Capability Envelope
is the combination of all top-level
attribute
values
and all
relationships
between top-level attributes that fully define any
individual
design concept.
Slide58The Capability EnvelopeOne of the most important parts of the capability envelope is the answer to the question “how much can it carry, and how far?”This is expressed as an envelope bounded by the curve representing the relationship between max payload mass and total energy imparted.Can be expressed as “C3 vs payload mass” or “
DV vs payload mass”.Converting between the “C3 vs payload mass” and “DV vs payload mass” curves is trivial as long as the required DV to some reference orbit can be assumed or estimated from aerodynamic and trajectory models.
Slide -
58
OR
Slide59The Capability EnvelopeOther top-level attributes included in the capability envelope:Cost (including production, integration, launch, etc.)Reliability (probability of mission success for any given launch)Payload services provided (power, thermal conditioning, etc.)Load factors imparted to payload (max Q and during dynamic events)Shock loads imparted to payload (max Q and during dynamic events)Controllability envelope (wind speeds vs fairing dims vs CoG offset)Allowable payload volumes (related to fairing dimensions)
Time between launches (including assembly time, pad time, etc.)Injection accuracy (altitude and inclination)Ability to operate in loss of communication (autonomy)Important to capture relationships that may restrict variables, even if the variables may affect different aspects of value.Example: controllability envelope relates wind speeds (affects value by determining how often vehicle can launch) to fairing dimensions (affects value by determining which payloads can be carried).
Slide -
59
Slide60The Capability EnvelopeNote that the capability envelope is quite specifically the inherent capabilities of any given single design (see slide 15). The capability envelope is not a design trade-space envelope.The former is an abstraction of a single design in the space of all possible designs, while the latter is a representation of all designs that are possible.Example: the relationship “max wind speed vs fairing diameter” is part of the capability envelope (assuming multiple fairings exist for a single design), while the relationship “cost vs reliability” is not (unless you’ve designed an SLS that literally allows for trading those off on any given launch).The capability envelope is not a mission trade-space envelope.
The former is the inherent capabilities of the vehicle, while the latter is related to specific mission planning.Example: the relationship “max payload mass vs max transfer energy” is part of the capability envelope, while the relationship “flight duration vs transfer energy” (as shown on a porkchop plot) is not.
Slide -
60
Slide61Mapping Capability to ValueThis is only the basic framework for the valuation model.Implementation may vary, but these core elements should remain.There is not necessarily a “correct” specific implementation of this framework – the implementation is limited in detail only by the designer’s knowledge of their preferences and/or ability to codify them.The “mission portfolio” valuation paradigm is beneficial because it allows for the consideration of the entire gamut of launch vehicle applications throughout its lifetime.The following slide presents a general illustration of how the mission portfolio maps the capability envelope to value.
Mission A
20,000 m/s
dV
required
Value = $50000 * m
Demand = 25% of total
Mission B
15,000 m/s
dV
required
Value = $30000 * m
Demand = 60% of total
Mission C
32,000 m/s
dV
required
Value = $80000 * m
Demand = 15% of total
Slide62Mapping System Capability to Value
“Will it work?”
(Reliability)
“What can it carry?”
Load Factors
Shock Loads
Payload Volume
Payload Services
Injection Accuracy
“How expensive is it?”
Production cost
Launch cost
e
tc.
Missions Attempted
Missions Succeeded
Total Value Delivered by Launch Vehicle
&
62
Slide63Mapping Capability to ValuePossible variations on this valuation framework:Mission Classifications:While location is used in the example as the sole classifier for missions, it is far from being the only potentially useful classifier. Missions could also be broken up by purpose (science/military/commercial), manned/unmanned, etc. – it is up to the designer to decide what is most useful.The important thing is that each unique mission archetype has a characteristic C3/D
V requirement, valuation function, and demand.Value Curve:Instead of having a required C3/DV for each mission and value being a function of mass, value for each mission could simply be a function of C3/D
V and mass.
This is a more complicated formulation that would be much more cumbersome to construct, but it would allow for more realistic representations of certain situations (such as scientific mission to a specific location that can accomplish more with a smaller payload and greater
D
V than with a larger payload and smaller
D
V).
Again, it is up to the designer to decide which formulation will best serve the project – in essence trading model fidelity for model effort.
Slide -
63
Slide64Mapping Capability to ValueSlide - 64Possible variations on this valuation framework:Mission Demand:Various restrictions could potentially be placed on any given mission’s demand to more accurately reflect real-world limitations – “no more than X launches of Y mission type every Z years”, etc.
These would allow for more realistic modeling of the change in value delivery granted by having a vehicle that can launch more frequently.Example: It could be the case that no matter how often the launch vehicle can launch, you do not want to (or cannot) launch more than 2 Jupiter missions every 10 years, but would instead do many more LEO and Luna missions).General:Various restrictions could potentially be placed on
individual missions
– “this mission requires at least X kg of payload to be attempted”, that sort of
thing.
Any small tweaks which increase the fidelity of the model are welcome, however designers must remain conscious of the increased effort that will result.
It is recommended to start with a low-fidelity model (similar to that which is shown in the example formulation) and refine as needed instead of attempting to construct a highly detailed model from the start.
Slide65SummaryDiscussed approach to Engineering an Elegant SystemDiscussed Systems Engineering Framework and PrinciplesSystem IntegrationEngineering Discipline IntegrationDiscussed several methods and tools for conducting integrated system design and analysisSystem IntegrationSystem Integrating Physics
System Design and OptimizationEngineering StatisticsState Variable AnalysisSystem ValueDiscipline IntegrationSociological Principles and Cognitive ScienceDecision Making
Policy and Law Application
Processes Application
Systems Engineering Approach defined in two documents
“Engineering Elegant Systems: Theory of Systems Engineering”
“
Engineering Elegant Systems: The Practice of Systems Engineering”
65
Slide66Backup66
Slide67System Exergy Efficiency67
S-1C Center Engine Cut-Off
S-1C Stage Separation
S-II Center Engine Cut-Off
S-II Stage Separation
S-II Engine Mixture Ratio Shift
S-IVB Burn
1
Cut-Off
LEO Insertion
S-IVB Burn 2 Cut-Off
S-!VB Separation
Max Q
S-IVB Burn 2 Engine
Mixture Ratio Shift
Slide68Crew Module Exergy Balance: ISS ECLSS
68
Calculate Efficiency
Relevant GFT PublicationsDSE Part 1: Stephen B. Johnson and John C. Day, “Theoretical Foundations of the Discipline of Systems Engineering”, AIAA SciTech/Infotech Conference, San Diego, California, 4 January 2016Covers Motivation, Approach, Bases, and PrinciplesDSE Part 2: Stephen B. Johnson, “The Representations and Practices of the Discipline of Systems Engineering,” Conference on Systems Engineering Research, Huntsville, Alabama, 23 March 2016Covers Purposes, Strategies, Representations, and Practices
GFT: Stephen B. Johnson, Goal-Function Tree Modeling for Systems Engineering and Fault Management. AIAA Infotech@Aerospace (I@A) Conference, 2013, Boston, MA. August 19-22, 2013. AIAA Paper 2013-4576.
69
Slide70System Engineering Supporting ActivitiesProcess Application and Execution for the Specific System
Slide71ProcessesWell defined in NASA/SP-2007-6105 Rev1, NASA Systems Engineering HandbookSEMP is essential to capture appropriate application of processes to the specific systemProcess application is specific to the system being developedTailoring is not a special exception, it is the norm