Model and Simulation

Multidisciplinary System Design Optimization (MSDO)
Lecture 3: Modeling and Simulation
Prof. Olivier de Weck

1 Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox
MSDO Framework
today
Design Vector Simulation Model Discipline A Discipline B Objective Vector
x1 x2 xn
Coupling
J1 J2 Jz
Discipline C Multiobjective Optimization Optimization Algorithms
Approximation Methods Sensitivity Analysis

Coupling
Tradespace Exploration (DOE)

2
Numerical Techniques (direct and penalty methods) Heuristic Techniques (SA,GA)
Isoperformance Special Techniques
Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox
Todays Topics
Definitions of Modeling and Simulation - physics-based modeling - empirical modeling Model/Simulation Development Process - module identification - module ordering: DSMs and N2 diagrams - module coding: fidelity and benchmarking - model execution = simulation Computational Issues - coupling disparate CAE/CAD tools
3
Definitions
Definitions
Definition: Model
(as used in this class)
A model is a mathematical object that has the ability to predict the behavior of a real system under a set of defined operating conditions and simplifying assumptions.
Definition: Simulation (as used in this class)

Simulation is the process of exercising a model for a particular instantiation of the system and specific set of inputs in order to predict the system response.
From the Reference

System
Experiment with Actual System Experiment with Model of System
Physical Model
Mathematical Model
Analytical Solution
Simulation
Law & Kelton (2000), Simulation Modeling and Analysis 3rd ed., McGraw-Hill, Inc.
Additional Detail Next Chart

The following chart includes additional detail to emphasize the factors that differentiate a model and a simulation Simulation/Model Factors: Real World Variability Reaction to Events
These relate back to the purpose of the sim/model
Models should not include all the details for all purposes
They quickly become unwieldy & expensive
Analysis Methods
Purpose:
System
Experiment with Actual System Experiment with Model of System
Analysis/Design Prediction Training Testing Entertainment Experiencing Visualizing Analyzing
Physical Model
Mathematical Model
Analytical Solution Static vs Dynamic
Numerical (Simulation) Deterministic vs Stochastic Continuous vs Discrete
Law & Kelton (2000), Simulation Modeling and Analysis 3rd ed., McGraw-Hill, Inc.
8
Modified by M.J. Steele with added detail
Visualization Sensory Immersion
Model and Simulation Development Process
Model Development Process

Start Process Define Master Table DSM Diagram
Objectives Constraints Design Variables
N2 Governing Equations Define Modules
Iterate to Improve Fidelity
Code Modules
Integrate Modules
Benchmark Sanity Check
Test Code Ready For Use
10
Objectives, Constraints, Design Variables

This is how we want system to behave Define Objectives J Define Design Variables x Things about system we can change Define Constraints and Bounds g, h Must satisfy this Determine important fixed parameters p Fixed, outside our
control yet important
Influence Matrix
x1 Ji
gj
11
+
o
xn o
+
+
+
+ influence
o no influence
model relationships
Physics Based Modeling

Start with governing equations Continuum Mechanics for physical systems Introduce Boundary Conditions Introduce Initial Conditions External forcing functions Discretize system
12
Governing Equations
Continuum (Structural) Mechanics
x xy y zy xz yz y
yx zx
stress tensor
F3
F1
F2
u x
strain
Fi
x
-Equilibrium Equations -Constitutive equations -Compatibility equations

13
0 E x
dx' dx dx
Example: Finite Element Model
Mx Cx Kx
Geometry Connectivity Material Properties Boundary Conditions Loads
F
Mass and Inertia Matrix
Z X Y
Deflections, Stress, Strain

Natural Frequencies Mode Shapes
Time as Variable: Static

14
Assumptions Discretization Steady State
Transient
Empirical Modeling
Derive a model, not from physics and first principles, but from observation, i.e. data Usually leads to low order models Only valid under similar operating conditions Many cost models are of this nature
15
Example: Empirical Modeling

Engi ne Si z e v s . HP 400 350 300 250 200 150 100 50 0 0. 0 2. 0 4. 0 6. 0
In-line engine image removed due to copyright restrictions. Animation can be found at HowStuffWorks.com.
Hor s epower
could do physicsBased modeling of this in-line 4 engine, but instead do

Engi ne Si z e ( Li t er s )
Linear Regression
HP = 51.48*ED + 23.12
16
HP
ED
How to decompose a system

What to do when system is new - no experience ? First define black boxes or modules based on: disciplinary tradition, degree of coupling of governing equations or availability of analysis software Crisply define inputs and outputs of each module
Ref: Rogers, J.L.: A Knowledge-Based Tool for Multilevel Decomposition of a Complex Design Problem, NASA TP2903, 1989
Partitioning of Equations
E1 E2
x1 x2 2 x3 2 0 x2 3x5 9 0 x1 x4 x5 x2 x5
X1 X2 1 1 1 1 1 1 1 1
-5 variables -5 independent equations -no degrees of freedom

1. Solve x2,x5 from E2 and E4 2. Solve x4 from E5 3. Solve x1 and x3 from E3 and E1
E3
E4 E5
x3 10 0 x2 9 0
X4 X5
9 x5 3 x2 7 0 x2 x4
X3 1 1 1 1 1
X2 E2 E4 E5 E3 E1 1 1 1 1
X5 1 1 1 1
X4
X1
X3
E1 E2 E3 E4 E5
Module 1 1 1 Module 2 1 1 1 1 Module 3
Occurrence matrix for system of equations 18

Image by MIT OpenCourseWare.
Occurrence matrix showing the system of equations partitioned into three subsets
Module Definition
What is a module in MSDO ?
A module in multidisciplinary system design optimization is a finite group of tightly coupled mathematical relationships who are under the responsibility of a particular individual or organization, and where some variables represent independent inputs while others are dependent outputs. The module frequently appears as a black box to other individuals or organizations .
x1 ... xn
19
Module A
y1 ... ym
Modules for Simulation

A module within a simulation architecture may be defined as a piece of computer code which:
Performs a compact set of calculations. Contains a single entry point and exit point. May be tested in isolation.
Attributes of a good modular unit within a simulation architecture include:

High internal coupling within the module
All sub-functions within the module contribute to form a single primary function.
Low coupling between modules

Minimize the number of variables that flow between modules.
Minimization of feedback loops

Data flow is processed sequentially from input to output.
20
Module Inputs and Outputs

Info fed to upstream (feedback) Info coming from upstream (feed-forward)
Input Output
Module i
Input
Output
Info fed from downstream (feedback)

21
Info fed to downstream (feed-forward)
Module Example
sensors actuators (e.g. CMGs) pointing requirement vehicle inertia matrix disturbance torques
I
d
Output
Attitude Control
Output
Input
Example: Spacecraft Design
22
power required propellant amount
The N2 Diagram
An NxN matrix used to develop and organize interface information. Similar to a Design Structure Matrix (DSM) Each module within the simulation architecture is placed along the diagonal. Provides a visual representation of the flow of information through the simulation architecture. Helps to identify critical modules that have many inputs and outputs. The fidelity of critical modules should be thoroughly tested and verified. Explicitly defines all inputs and outputs for macro-modules and modules. Allows for plug and play
Independent testing Alternative modules easily analyzed Can increase overall model fidelity incrementally
23
Initial random sequencing

feedforward
Execution sequence goes from upper left corner to lower right corner
Problem: Each instance of feedback requires an iteration
feedback
24
Initial, random arrangement of modules on the N-square matrix diagonal.

Ordered sequence
The Need
Identify coupling between discipline or subsystems in a complex system.
The Solution
Automatic identification of subsystems based on interdependence of design variable and constraints.
Actuators Sensors Structures and materials
Dynamics Controls e.g. = output = mode shapes
Modules in the N-square matrix resequenced to reduce feedback.
25
Systematic permutation groups and reduces number of feedback loops
TPF Example : Overview N2 Diagram

TMAS N-Squared Diagram
Design Const. Env. Apert. Vector Vector Module Conf. Module Spacecraft Payload and Bus Module Dynamics, Control, & Stability Module Deployment & Operations Module GINA Systems Analysis Module
Design Vector 1 2,3,4 2,4 1,2,3 2,3,4 2,3 1 2,3,4 2,3,4 1,2,3,4 3 1 1,2,3 1,2 2 2,3,4 1,2,3,4 Architecture Constants Vector 11 2 2,3 3 1,2 4 13,14 14,31 15,16 11,32-40 3 5 to 11 2,12 all Environment 1 1,2,3 Aperture Configuration 1 1 1 1 Payload 3,4 1,2 1,2 Power 1,6 6,7 6,7 2,3 2,3,5,6 Thermal 1,4 4 Propulsion 3 6 Communications 1 to 5 8,10 6 Structure 6,10 3,4,5 6,9 6 Sub-Modules Truss Design 1,2 1 Design Vector State-Space Plant Model 1 1,2 Architecture Constants Vector Attitude Determination and Control Environment Model Integration 3 Aperture Configuration Performance Assesment 1 Payload Orbit Transit1,2,3 4 Power Launch 2 Thermal Operations 2 1 Propulsion Capability 7,8,9 Communications Performance 4 Structure Cost 6 Truss Design Cost Per Function 1 State-Space Plant Model Adaptability Attitude Determination and Control Model Integration Performance Assesment Orbit Transit Launch Operations Capability Performance Cost Cost Per Function Adaptability
Inputs
Outputs
m-file
Outputs
Inputs
26
Coding - Benchmarking
Coding of modules can be done in parallel, once the I/O structure has been decided Use dummy input data to exercise modules in isolation Integrate modules step-by-step starting from upper left corner in N2-Diagram Do end-to-end simulation test before release Benchmark (validate) simulation against known cases (experimental data)
Recap
Start Process Define Master Table DSM Diagram
Objectives Constraints Design Variables
N2 Governing Equations Define Modules
Iterate to Improve Fidelity
Code Modules
Integrate Modules
Benchmark Sanity Check
Test Code Ready For Use
28
Example
de Weck, O. L. and Chang D., Architecture Trade Methodology for LEO Personal Communication Systems , 20th International Communications Satellite Systems Conference, Paper No. AIAA-2002-1866, Montral, Qubec, Canada, May 12-15, 2002
29
Example: Communications Satellites

Design (Input) Vector
Simulator
Performance Capacity Cost
Can we quantify the conceptual system design problem using modeling and simulation?
Design (Input) Vector X

The design variables are:
Astrodynamics Satellite Design Network Constellation Type: C Orbital Altitude: h Minimum Elevation Angle: Satellite Transmit Power: Pt Antenna Size: Da Multiple Access Scheme MA:
min
Design Space
Polar, Walker 500,1000,1500,2000 2.5,7.5,12.5 1.0,2.0,3.0 MF-TDMA, MF-CDMA [km] [deg] [m] [-]
200,400,800,1600,2400 [W]
Network Architecture: ISL

C: h: emin: Pt: DA: MA: ISL: 'walker' 2000 12.5000 2400 3 'MFCD' 0
yes, no
[-]
X1440=
This results in a 1440 full factorial, combinatorial conceptual design space
31
Objective Vector (Output) J

Performance (fixed)
Data Rate per Channel: R=4.8 [kbps] J1440= Bit-Error Rate: pb=10-3 Link Fading Margin: 16 [dB]
Consider
Cs: Clife: LCC: CPF: 1.4885e+005 1.0170e+011 6.7548e+009 6.6416e-002
Capacity
Cs: Number of simultaneous duplex channels Clife: Total throughput over life time [min]
Cost
Lifecycle cost of the system (LCC [$]), includes:
Research, Development, Test and Evaluation (RDT&E) Satellite Construction and Test Launch and Orbital Insertion Operations and Replenishment
Cost per Function, CPF [$/min]

Multidisciplinary Simulator Structure

Constants Input p x Vector Vector
msat
Spacecraft
h,
min
Constellation
msat
Launch Module
LV
Cost
T, p
ISL
Pt , Da , MA
nspot
Satellite Network
nGW
Link Budget
LCC
Rs
Capacity
Cs
msat Satellite Mass Number of Satellites T p Number of orbital planes

33
nspot Number of spot beams nGW Number of gateways LV Launch vehicle selection
Output J Vector
Note: Only partial input-output relationships shown

Governing Equations
a) Physics-Based Models Energy per bit over noise ratio:
Eb N0
PG r G t kL space L add.Tsys.R
(Link Budget)
b) Empirical Models
msat
38 0.14 Pt
mprop
0.51
(Spacecraft)
Scaling models derived from FCC database
34
Benchmarking
Benchmarking is the process of validating a model or simulation by comparing the predicted response against reality.
Benchmarking Result 1: Simultaneous channels of the constellation
Number of simultaneous channels of the constellation
Benchmarking Result 2: Lifecycle cost

Lifecycle cost (billion $)
6.00 5.00 4.00 3.00 2.00 1.00 0.00 1 Iridium Iridium and Globalstar 2 Globalstar actual or planned simulated
140,000 120,000 100,000 80,000 60,000 40,000 20,000 0
actual or planned simulated
1 Iridium
2 Globalstar
Iridium and Globalstar
Benchmarking Result 3: Satellite mass

Number of satellites in the constellation
Benchmarking Result 4: Number of satellites in the constellation

70 60 50 40 30 20 10 0 Iridium 1 Globalstar 2 Orbcomm 3 SkyBridge 4 actual or planned simulated
1,400.0 1,200.0 1,000.0 800.0 600.0 400.0 200.0 0.0
Satellite mass (kg)
actual or planned simulated
Iridium 1
Globalstar 2
Orbcomm 3
SkyBridge 4
Iridium , Globalstar, Orbcom m , and SkyBridge
Iridium , Globalstars, Orbcom m , and SkyBridge
35
Simulation Results
Lifecycle Cost [B$]
10
Iridium actual
Iridium simulated Globalstar actual Globalstar simulated
Pareto Front
10
10
10
10
10
10
Global Capacity Cs [# of duplex channels]

Simple Example (Prep for Homework A1)
37
Example: Communications Satellite

Design of a geosynchronous communications satellite
Satellite
Earth
S
t
Pbus
Ground Station
Main Lobe
D
Antenna Bus Solar Panel
r = 6378 [km]
38
Design problem (Define D.V., objectives, constraints): How should antenna (D) and solar array (A) be sized for a given orbital period (p) such that a data rate requirement (R=Rreq) is met, while minimizing cost (C) ?
Comsat: Governing Equations

Objective: min C , Constraint: R>=Rreq
Communications: Power:
D t Pt 2 16S
avg
4
[bps]
(link budget)
Pt
A AWo cos
p 1.66 10
Pbus
3/ 2
(power budget)
[W]
Orbits: Cost:
S rE
(orbital period)
[min]
2500 D
12000 A 1 +100 Pbus

10 P t [W]
[$]
Bus Engineering:
39
P bus
(cost budget)
Comsat: Master Table

D A p R C Pt Antenna Diameter Solar Panel Area Orbital Period Data Rate Cost Transmitter Power [m] [m2] [min] [bps] [$] [W] design var. design var. design var. constraint objective dependent
40
Pbus Bus Power Sun incidence angle a array/xmit efficiencies a,t, S Orbital altitude constant Wo Solar constant
[W] [deg] [%] [km] [-] [W/m2]
dependent parameter parameter dependent parameter parameter
ComSat Block Diagram

Input Vector x D
A p
BLOCK DIAGRAM
A
Power
Cost
Pt
D
Pbus
Orbits
Bus Comm
Output Vector
C R
p
41
Comsat N2 Diagram
In p Orbits D S Comm Pt Powe r Pbus Pt Bus Pbus Cost C R A D,A
Out
42
iterative block
Computational Implementation
43
Computational Issues
Computer technologies have been changing the environment of engineering design - enabling MDO Hardware: Advances in processor speed, memory and storage Software: Powerful disciplinary analysis and simulation programs (e.g. Nastran, Fluent )
This also creates new difficulties: Most activities involve stand-alone programs and many engineers spend 50-80% of their time organizing data and moving it back-and-forth between applications
Data must be shared between disciplines more easily
Coupling Disparate Tools

Case 1: Within one application on the same computer
Application
in
Case 2: Between different applications on the same computer

in
B B
A C
B E D

out
*
D
* *
E

out
E.g. MATLAB, Excel, C++
* Interface files
Implementation and Ownership (II)

Case 3: In a LAN or WAN environment
Owner A Owner C
A B B
Design Team Site

in
Map out
#
E

46
Owner B
# Server
Owner G
Modeling-Simulation Environments
Integrated Modeling & Simulation ICEMaker
Write functions and integrate via Master script MATLAB, Mathematica are popular environments Developed at Caltech/JPL linked spreadsheets (client server)
DOME (MIT) - CO (Oculus)
FIPER (Simulia Dassault Systems) PHX Model Center
DOME based peer-peer system APIs into numerous Engineering applications

Client-server enterprise system Targeted at the corporate environment Phoenix Integration Flagship Product Desktop Integration Environment
47
Lecture Summary
Follow a logical model & simulation development process, dont forget benchmarking Decomposition is crucial in order to facilitate code integration and coupling N2/DSM Matrix is useful tool to organize data Minimize the number of feedback loops
48
N2 and DSM References

Rogers, James L.: DeMAID/GA User's Guide - Design Manager's Aid for Intelligent Decomposition with a Genetic Algorithm, April 1996, NASA TM 110241. Steward, D.V., 1981, Systems Analysis and Management: Structure, Strategy, and Design, New York: Petrocelli. D.V. Steward. Partitioning and Tearing Systems of Equations, SIAM Journal of Numerical Analysis. Ser.B, vol.2, no.2, 1965, pp.345-365 de Weck, O. L. and Chang D., Architecture Trade Methodology for LEO Personal Communication Systems , 20th International Communications Satellite Systems Conference, Paper No. AIAA-2002-1866, Montral, Qubec, Canada, May 12-15, 2002 Ulrich, K.T., and S.D. Eppinger, 1995, Product Design and Development , McGraw-Hill. The Design Structure Matrix Website, http://www.dsmweb.org/
MIT OpenCourseWare http://ocw.mit.edu
ESD.77 / 16.888 Multidisciplinary System Design Optimization

Spring 2010
For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.

Model and Simulation

Uploaded by

Model and Simulation

Uploaded by

Multidisciplinary System Design Optimization (MSDO)

Lecture 3: Modeling and Simulation

Prof. Olivier de Weck

Discipline C Multiobjective Optimization Optimization Algorithms

Approximation Methods Sensitivity Analysis

Tradespace Exploration (DOE)

Numerical Techniques (direct and penalty methods) Heuristic Techniques (SA,GA)

Isoperformance Special Techniques

Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox

Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox

Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox

Definition: Simulation (as used in this class)

Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox

From the Reference

Additional Detail Next Chart

These relate back to the purpose of the sim/model

Analysis/Design Prediction Training Testing Entertainment Experiencing Visualizing Analyzing

Analytical Solution Static vs Dynamic

Numerical (Simulation) Deterministic vs Stochastic Continuous vs Discrete

Modified by M.J. Steele with added detail

Massachusetts Institute of Technology - Prof. de Weck and Prof. Willcox

Visualization Sensory Immersion