The Role and Limitations of Modeling and Simulation in Systems Design
description
Transcript of The Role and Limitations of Modeling and Simulation in Systems Design
Systems Realization Laboratory
The Role and Limitations of Modeling and Simulation in Systems Design
Jason Aughenbaugh & Chris ParedisThe Systems Realization Laboratory
The George W. Woodruff School of Mechanical Engineering
The Georgia Institute of Technology
November 19, 2004, Anaheim, CAIMECE2004-5981
Systems Realization Laboratory
Uncertainty: The Challenge of Design, Modeling, and Simulation
Evaluate Alternatives
GenerateAlternatives
Select Alternative
KnowledgeInformation
GenericDecisionProcess
Predictions of Consequences of DecisionsAre Always Uncertain
Analyze the results
Model the alternatives
Systems Realization Laboratory
Uncertainty: The Challenge of Design, Modeling, and Simulation
Evaluate Alternatives
GenerateAlternatives
Select Alternative
KnowledgeInformation
GenericDecisionProcess
Designers currently lack appropriate methods for representing and computing with
the various types of uncertainty faced in designespecially lack of knowledge
Systems Realization Laboratory
Motivation: Complexity Increasing
Increasingly complex
Increasingly multidisciplinary
Need more knowledge
Need more collaboration
HumanCommunication
HumanCommunication
Product SystemInteractions
Product SystemInteractions
Systems Realization Laboratory
Systems Engineering: A Decomposition Approach
Understand User Requirements, Develop
System Concept and Validation Plan
Develop System Performance Specification and System Validation Plan
Expand Performance Specifications into CI
“Design-to” Specs and CI Verification Plan
Fab, Assemble and Code to “Build-to” Documentation
Evolve “Design-tp” Specifications into “Build-
to” Documentation and Inspection Plan
Inspect to “Build-to”
Documentation
Assemble CIs and Perform CI Verification
to CI “Design-to” Specifications
Integrate System and Perform System Verification to
Performance Specifications
Demonstrate and Validate System to
User Validation Plan
Integ
ratio
n an
d
Qualif
icatio
nDecom
position
and Definition
Time
Systems Engineers
Discipline Engineers
Understand User Requirements, Develop
System Concept and Validation Plan
Develop System Performance Specification and System Validation Plan
Expand Performance Specifications into CI
“Design-to” Specs and CI Verification Plan
Fab, Assemble and Code to “Build-to” Documentation
Evolve “Design-tp” Specifications into “Build-
to” Documentation and Inspection Plan
Inspect to “Build-to”
Documentation
Assemble CIs and Perform CI Verification
to CI “Design-to” Specifications
Integrate System and Perform System Verification to
Performance Specifications
Demonstrate and Validate System to
User Validation Plan
Integ
ratio
n an
d
Qualif
icatio
n
Integ
ratio
n an
d
Qualif
icatio
nDecom
position
and Definition
Decomposition
and Definition
TimeTime
Systems Engineers
Discipline Engineers
Systems Engineers
Discipline Engineers
Forsberg, K., and Mooz, H., 1992, "The Relationship of Systems Engineering to the Project Cycle," Engineering Management Journal, 4(3), pp. 36-43.Forsberg, K., Mooz, H., and Cotterman, H., 2000, Visualizing Project Management: A Model for Business and Technical
The Vee Model
Systems Realization Laboratory
System Decomposition:Relating Requirements and Attributes
Requirements AttributesRequirements Attributessubsystems
system
Systems Realization Laboratory
Relating Requirements and AttributesEngineers Decide on
Engineers Design and Build
Requirements AttributesRequirements Attributessubsystems
system
Have resultant
Must match customer
requirements
Systems Realization Laboratory
Making “good” decisionsEngineering Decisions
Engineers Build
Requirements Attributessubsystems
system
Have resultant
Must match customer
requirements
???
Systems Realization Laboratory
The Role of Modeling and SimulationEngineers Decide on
Engineers Build
Requirements Attributessubsystems
system
Have resultant
Must match Customer
requirementsModeling and Simulation:estimates
Systems Realization Laboratory
Decomposition is Hierarchical
Requirements AttributesAttributessubsystems
system
A
Requirements AttributesAttributessubsystems
systemA
Systems Realization Laboratory
Decomposition is Hierarchical
Requirements AttributesAttributessubsystems
system
A
Requirements AttributesAttributessubsystems
systemAHow do subsystem decisions affect the system attributes?
Systems Realization Laboratory
Aggregation of Subsystem Attributes
Depending on system compositione.g. mass
Depending on system structuree.g. cost
Depending on system operatione.g. reliability
Resulting from complex emergent behaviore.g. queue wait times
Increasingly complex
Increasing value of simulation
Product SystemInteractions
Product SystemInteractions
HumanCommunication
HumanCommunication
Systems Realization Laboratory
Specific Uses of Modeling and Simulation
Requirements AttributesAttributessubsystems
system
HumanCommunication
HumanCommunicationProduct System
InteractionsProduct System
Interactions
Models improve communication
Simulations reveal emergent behaviors
Ref. AND
1
Start System
LP
2
Run A to B LP
LP
3
Run B to A LP
AND Ref.
SystemReady at A
InPeopleA
OutPeopleB
SystemReady a...
InPeopleB
OutPeopleA
Date:Saturday, July 12, 2003
Author:Trial User
Number:0
Name:(Trial) OperateTransportation System
Models clarify requirements
I didn’t think it would do that! I wanted it to behave
more like…
Now I understand!
Models help explore robustness
Systems Realization Laboratory
Limitations of Modeling and Simulation
Requirements AttributesAttributessubsystems
system
Representation and propagation of uncertainty
Limitations of knowledge: uncertainty Integration of multiple models
PID withRedundancy
SatelliteStructurePayload Reaction
Wheels
AttitudeEstimator
Signal
Mechanical
PID withRedundancy
SatelliteStructurePayload Reaction
Wheels
AttitudeEstimator
Signal
Mechanical
x1
x2
q1
q2
u1
u2
u3
u4
PDF/PMF
value[ ]u5
This is what I know:
Expressing model validity
So how accurate are these numbers?
Is he even using the right model?
Systems Realization Laboratory
How do we deal with uncertainty?
We need formalisms for• Representing uncertainty accurately• Computing with such formalisms• Making decisions based on these formalisms
We need to accurately express what is known• Capture as much of what is known as necessary• Not imply information that we don’t have
Reflect different types of uncertainty
Systems Realization Laboratory
Different Types of Uncertainty Aleatory uncertainty
• Inherently random – irreducible• Best represented as probability
distribution• Examples:
• Manufacturing variability
Epistemic uncertainty• Due to a lack of knowledge• Not accurately represented as • probability distributions• Examples:
• Error due to model approximation• Future design decisions
x1
x2
q1
q2
u1
u2
u3
u4
PDF/PMF
value[ ]u5
Systems Realization Laboratory
Possible Handling Mixed Aleatory and Epistemic Uncertainty:Probability Bounds Analysis
A p-box expresses the range of all possible CDFs that are still deemed possible based on existing knowledge.
• Example: An enveloping of all possible CDFs for normal distributions with variance of 1 and means in the interval [0,1]
• It represents aleatory uncertainty (variability) via the normal distributions
• It represents epistemic uncertainty (incertitude) via the interval on the parameters -3 -2 -1 0 1 2 3 4
0
0.5
1
g3
g4
g5
g6 g1
A “P-box”
N(0,1)
N(1,1)
Systems Realization Laboratory
P-boxes: two dimensions of uncertainty Ignorance (Epistemic) Precise
Variability (Aleatory)
-3 -2 -1 0 1 2 3 40
0.5
1
pbox
(a)
Ignorance about the variability
-3 -2 -1 0 1 2 30
0.5
1 cdf
(b)
Precise knowledge of the variability
Deterministic
-1 0 1 20
0.5
1
interval
(c)
Ignorance about the true deterministic value
0.4 0.5 0.60
0.5
1
deterministic_value
(d)
Precise knowledge of the deterministic value
Variable
Deterministic
Epistemic Precise
Systems Realization Laboratory
Summary: we need more appropriate representations of uncertainty
Evaluate Alternatives
GenerateAlternatives
Select Alternative
KnowledgeInformation
GenericDecisionProcess
Predictions of Consequences of DecisionsAre Always Uncertain
Analyze the results
Model the alternatives
Systems Realization Laboratory
Summary: we need more appropriate representations of uncertainty
Evaluate Alternatives
GenerateAlternatives
Select Alternative
KnowledgeInformation
GenericDecisionProcess
Predictions of Consequences of DecisionsAre Always Uncertain
Analyze the results
Model the alternatives
Better Representations
Better Selection
Better Design
Systems Realization Laboratory
Acknowledgements
Thank you for attending! This material is based upon work supported under a National
Science Foundation Graduate Research Fellowship. • Any opinions, findings, conclusions or recommendations expressed in this
presentation are those of the authors and do not necessarily reflect the views of the National Science Foundation.
Additional support is provided by the G.W. Woodruff School of Mechanical Engineering at Georgia Tech.
Systems Realization Laboratory
Questions?