This document provides an overview of different modeling concepts and principles. It begins with an introduction to modeling in different domains like the human body, military operations, and economics. It then discusses general modeling approaches like physical, logical, and mathematical modeling. Different categories of events for simulation are outlined. Common modeling architectures, principles, and cycles from fields like military simulation, surgery, and physics are summarized. The document concludes with advice for early career modelers around designing their own models, generalizing principles, reading widely, questioning others, and drawing from multiple disciplines.
1. Models of Modeling
Roger Smith, PhD, DM, MS, MBA
Chief Technology Officer
Florida Hospital
Nicholson Center for Surgical Advancement
roger.smith@flhosp.org
Approved for Public Release.
4. Challenges in Modeling Different Worlds
Human Body
Hard Objects living Energy Signals
tanks, helos, ships tissue rf, eo, ir
4
5. 90 Mental Models … for Investing
You've got to have models in your head. And you've got to
array your experience ‑ both vicarious and direct ‑ on this
latticework of models. …
What are the models? Well, the first rule is that you've got to
have multiple models ‑ because if you just have one or two that
you're using, the nature of human psychology is such that
you'll torture reality so that it fits your models, or at least you'll
think it does. …
It's like the old saying, "To the man with only a hammer, every
problem looks like a nail." But that's a perfectly disastrous way
to think and a perfectly disastrous way to operate in the
world. …
And the models have to come from multiple disciplines ‑
because all the wisdom of the world is not to be found in one
little academic department. …
You may say, "My God, this is already getting way too Charlie Munger
tough." But, fortunately, it isn't that tough ‑ because 80 or 90 Berkshire Hathaway
important models will carry about 90% of the freight in making (Warren Buffett’s Partner)
you a worldly ‑ wise person. And, of those, only a mere
handful really carry very heavy freight. 5
6. Mental Models and Tools for Modeling
• Mathematics • Finite State Machine
• Statistics • Markov Chain
• Physics • Continuous vs. Discrete
• Logic • Sim Languages & Tools
• Queuing • Notations (ER, UML)
• Human Behavior
• Economics
• Social Relationships
• CFD
• Finite Element
6
9. Pritsker’s Modeling Principles
• Conceptualizing a model • In modeling combined systems,
requires system knowledge, the continuous aspects of the
engineering judgment, and problem should be considered
model-building tools. first. The discrete aspects of the
• The secret to being a good model should then be
modeler is the ability to remodel. developed.
• The modeling process is • A model should be evaluated
evolutionary because the act of according to its usefulness.
modeling reveals important From an absolute perspective, a
information piecemeal. model is neither good or bad,
• nor is it neutral.
The problem or problem
statement is the primary • The purpose of simulation
controlling element in model- modeling is knowledge and
based problem solving. understanding, not models.
Source: Pritsker, A. (2000). Papers, Experiences, Perspectives. Systems Publishing Corp.
10. DES Program Structure
Start
Main
Initialization Timing
1. Invoke Initialization
1. Set clock 2. Invoke Timing 1. Select next event
2. Set state variables 3. Invoke Event Handler 2. Advance sim clock
3. Load event list
Event Handlers
Mathematics
1. Update state variables
2. Increment counters 1. Statistical Distributions
3. Generate future events 2. Mathematical
Operations
NO
Finished?
YES
Reports
1. Compute interest data
2. Write reports
Stop
Source: Law, A & Kelton, W. (1991). Simulation Modeling and Analysis. McGraw Hill.
11. DEVS Model Structure
MODEL Model
5 Internal Transition
•State Data Change 7 Output Events
3 Input Events •State Structure Specific •Event Type
•Event Type •Time Stamped
•Time Stamped •Object Identifier
•Object Identifier •(other attributes)
•(other attributes) 1
State Set 6 Output Event
•Object Instance Generator
4 •Current Attributes •Trigger Condition
External Transition
•Mathematic Algorithm •Event Formatting
•Event+State Data •New State Data
•State Structure Independent •New Event
2 Time Advance
•Monotonically Increasing
•Distributed Synchronization
Source: Zeigler, Praehofer, Kim. (2000). Theory of Modeling and Simulation. Academic Press.
12. Kiviat Modeling Approach
Purpose of the modeling project.
Problem
Statement Static state of objects.
Physical Model Relationships between objects.
Logical Model Possible actions.
Dynamic Model Criteria for taking action.
Decision Process
Model Limiting effects.
Control System
Model
Source: Kiviat, P. (1998). Interview with Ernie Page for ACM SIGSIM Distinguished Lectureship. http://www.acm.org/sigsim.
13. The Big Picture: Knowledge Trumps Algorithms
Knowledge
& Skills
Training
Event
Training
System
Simulated
Environment
Simulation
System
Model
Algorithm
14. Interactive Simulation Architecture
Synthetic User
Models Translators
Environment Interfaces
Simulation Management
Time Management
Data Management
Event Management Object Management
Operating System Distribution Management
Hardware Network
Source: Smith, R. (2006). Military Simulation Techniques and Technology, DiSTI Course Workbook.
15. General Modeling Approaches
• None – Omit Feature and Behavior from the Simulation
• Geometry – Size and placement of organ
• Stochastic – Probability of Injury, Mean Time Between Failure
• Logical – Tissue Properties, Body System
• Physics – Force, Mass, Friction, Vector Tracing
• Artificial Intelligence – Human Decision & Perception
Source: Smith, R. (2007). “Military Modeling”, Handbook of Dynamic Systems Modeling, CRC Press.
16. General Categories for Events
Planned Reactive Management Environment
Movement Path Evade Enemy Start Crater Terrain
Search Pattern Fire Weapons Pause Destroy Bridge
Battle Planning Detect Enemy Checkpoint Burn Forest
Intel Analysis Apply Attrition Rate Change Collapse Building
S Bridge
TARGET
SAM
Bld
SAM
CITY
CITY P
C Trees
Source: Smith, R. (2006). Military Simulation Techniques and Technology, DiSTI Course Workbook..
17. Physical Modeling Cycle
Move
Sense
Start Cycle Here
Communicate
Engage
Source: Smith, R. (2002). Military Simulation Techniques & Technology. DiSTI Course Manual.
19. Battlespace Abstract Model 2
Move
Dynamic
Perceive Environment Reason
Engage
Exchange
Source: Smith, R. (2007). “Military Modeling”, Handbook of Dynamic Systems Modeling, CRC Press.
20. Surgical Simulation: No Architectural Concepts
Model
Clinical Generation Vascular
Expertise Structures
Bleeding Tissue
Simulation Parameters
Tissue Cutting Organ Texturing
Tissue
Haptic Interface
Deformation
Collision
Immersive OR
Detection
Fluid Simulation
Source: Harders, M. (2008). Surgical Scene Generation for Virtual Reality Based Training in Medicine. Springer Verlag. 20
21. Possible Surgical Simulation Architecture
Synthetic User
Models Translators
Environment Interfaces
-Tissue Dynamics -Surgeon
-Body -Instruments
-Fluid Flow -Team
-Fluids -Video
-Body Response -Anesthetist
- Pharma - Monitors
Simulation Management
Time Management
Data Management
Event Management Object Management
Operating System Distribution Management
Hardware Network
22. Read all the code you can find
AWSIM
for(i=1 ; i <= NUMS ; ++i)
{
x1 = myPoints[ mySprings[i].i ].x; y1 =
myPoints[ mySprings[i].i ].y;
x2 = myPoints[ mySprings[i].j ].x;
myPoints[ mySprings[i].j ].y;
y2 = TACSIM
while(x<getmaxx()){
r12d = sqrt ( (x1 - x2) *(x1 - x2) + (y1 - y2) * (y1 - y2)
setfillstyle(SOLID_FILL,0);
); // square
bar(x,y,x+bmp.width,y+bmp.height);
// root of the distance
if(r12d != 0)
x++;
draw_bitmap(&bmp,x,y);
Quake
{
} for (i=0; i<NUM_ITER; i++)
vx12 = myPoints[ mySprings[i].i ].vx -
myPoints[ mySprings[i].j ].vx; {
vy12 = myPoints[ mySprings[i].i ].vy - // Transfer the block N times and simulate
myPoints[ mySprings[i].j ].vy; corruption
f = (r12d - mySprings[i].length) * KS + (vx12 * (x1 - lostBlockCount = 0;
x2) + vy12 * (y1 - y2)) * KD / r12d; for (j=0; j<N; j++)
if (rand_val() <= PR_BAD)
lostBlockCount++;
// Are all blocks lost or did some make it through?
if (lostBlockCount == N)
lostDataCount++;
else
goodDataCount++;
}
22
24. Advice for the Next Generation
• Just do it
… Design, build, run your own models
• Generalize
… Look for general principles
• Read books and code
… Learn beyond your own experience
• Question other people
… There are geniuses in our field
• Branch out
… psychology, system dynamics, medicine, economics …
24
Sim – OR mathematics, Numerical Analysis Soldier – AF F-16 v SAM, Chem War, CONUS AD, WPC Sims, ALBAM, NRO National Intel Spy – Army Elec Intel, NSA Elec, DIA Resource Mgmt, Navy ***, Info War, TechInt Introp Soldier – Serious Games, HPC Sim, Sim as Service, Medical Sim Surgeon – Robotic Surgeon, Physiology
Mathematics to Modeling AF COVAS: take over from 2 year programmer AF AWSIM: Games and reading code Joint ALBAM: From scratch. Team division. Optimization (Tiger Labs) Army TACSIM: Reading code. Code in the field. Reforger. UFL printouts. NSA TRG. New customer, old models. Back to UFL. Importance of use, not algorithms. NSA JSIG. DIA DOMINO. Army FCS. Abstraction. Joint COSCOMO.
Soldier Dynamic Combat Interactions Hard Physics Visualization Interrupt Spy Data collection & analysis Energy & Signature Reveal what is hidden Do not interact Surgeon 1-on-1 connection Active Intervention Reactive to Body Soft Physics, Tissue, Fluids Validation
http://www.paladinvest.com/pifiles/MungersWorldlyWisdom.htm http://robdkelly.com/blog/models-frameworks/munger-mental-models/ You've got to have models in your head. And you've got to array your experience ‑ both vicarious and direct ‑ on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and in life. You've got to hang experience on a latticework of models in your head. What are the models? Well, the first rule is that you've got to have multiple models ‑ because if you just have one or two that you're using, the nature of human psychology is such that you'll torture reality so that it fits your models, or at least you'll think it does. It's like the old saying, &quot;To the man with only a hammer, every problem looks like a nail.&quot; But that's a perfectly disastrous way to think and a perfectly disastrous way to operate in the world. So you've got to have multiple models. And the models have to come from multiple disciplines ‑ because all the wisdom of the world is not to be found in one little academic department. That's why poetry professors, by and large, are so unwise in a worldly sense. They don't have enough models in their heads. So you've got to have models across a fair array of disciplines. You may say, &quot;My God, this is already getting way too tough.&quot; But, fortunately, it isn't that tough ‑ because 80 or 90 important models will carry about 90% of the freight in making you a worldly ‑ wise person. And, of those, only a mere handful really carry very heavy freight.
These seven principles of modeling are derived by Alan B. Pritsker of Pritsker Corporation. He is one of the early developers of simulation specific languages and commercial simulation products. Specifically, I want you to notice the last item. Pritsker makes the excellent point that we create and use simulations in an attempt to increase our understanding of a system or situations. Models are not constructed as exercises in clever thinking, they are intended for some practical and valuable end. A more detailed description of each of these can be found in the Handbook of Simulation , edited by Jerry Banks for John Wiley & Sons, 1998.
Traditional process flow simulations often share a familiar structure. The flow of the program is controlled by a “main” routine that is started by the user and calls the other routines that are the model and its infrastructure. The first step is to call an initialization routine that knows the format of the input file and is able to deliver the contents of that file to the “main” for processing by the rest of the simulation. The input file will contain information that sets the beginning time of the simulation and prepared events that are to execute at specific times. The Timing routine responds to the event times and sets the clock according to the events. Event routines process each event and modify state variables. These routines are the real model within the software. These are supported by the use of packaged and perhaps commercial Library routines that perform specific scheduling, mathematic, and statistical operations. Traditionally, these libraries have allowed non-mathematicians to use advanced mathematics without being required to program every algorithm. The execution of event usually occurs in a loop that finishes when all planned and caused events are processed. When the loop exits it turns control to a Report routine that uses information gathered during simulation execution to generate tabular summaries that address the problem to be solved.
The basic Model begins by defining the boundary of what is internal and what is external. The core of the model is the State Set, the attributes which define the existence and capabilities of the objects. From an outside source, like a GUI or event script, External Input Events are delivered. These bring events which have some form of impact on the internal State Set of this model. The events are handled by External Transition Functions which understand their content and calculate its meaning or mapping to the internal State Set. Internal Transition functions apply the effects of the mapped events to specific state values. Output Event Generators are triggered when a state value is changed or an event is created that must be propagated to another model. These generators marshal the necessary information into Output Events which leave this model and are delivered to other models. Formally this definition is known as a 7-tuple. This means that it is described by a set of seven different variables or characteristics. The mathematical form of this concept comes from Theory of Modelling and Simulation, by Bernard Zeigler.
In a 1998 interview, Phil Kiviat, one of the early founders of discrete event simulation, described five characteristics of the real world that needed to be captured in a model. Together these represent what is most important about the objects under study. 1) Physical. The model must capture details about what the object is. This is often done in a descriptive way, capturing the static state of the object. 2) Logical (Relationships). The model must represent the relationships between the objects in the simulation. There is a tie between objects that is not physical, but is logical. 3) Dynamics. The model must capture the dynamic behavior of an object - how does it move or react when it bumps into another object. 4) Decision Processes. How does the object make decisions? What criteria are used to decide what to do under a given circumstance? 5) Control Systems. What controls or limits the activities of the model?
The components within a simulation system support increasing complexity and allow the system to grow and spread over many computers. This diagram illustrates the most dominant functionality found in many major simulation products. A specific product will include additional layers or components to meet its specific needs, but the components shown here are found in some form in almost all large simulation products. 1) Hardware and Networks. 2) Operating System and Distribution Management. 3) Data Management. 4) Event and Object Management. 5) Time Management. 6) Synthetic Environment. 7) Models. 8) User Interfaces. 9) Translators.
There is not a universal list of event types that are useful for all simulations. However, military simulations tend to focus on events that fall into three broad categories. Planned Events are scheduled for the future with the intention of achieving some objective. In the past these usually came from a human user. However, with the increase in Artificial Intelligence in simulations these may also be created by the Modeling Engine. These include long-term battle planning, intelligence analysis, flight plans, and search patterns. Reactive Events are those executed immediately in response to other events occurring to or around them. These are often generated by the objects themselves without waiting for inputs from the user. These may include firing upon an enemy that has been detected, evading an enemy vehicle that is attacking that object, detecting other vehicles as an ongoing part of a mission, and calculating and posting attrition in response to engagements. Exercise Management Events are used to control the flow of the exercise, maintain synchronization, and respond to the needs of the human operators. Environmental Events are used to propagate changes made to terrain, vegetation, buildings, etc. in one simulation that need to be replicated in another.
Typical military simulation have focused on the actions of movement, sensor detection, and engagement/attrition. Additional models were viewed as supporting features for “the big three”. As simulations became more object oriented each object gained a level of independence that required significant communication with other objects to operate. These communications could be included as part of the infrastructure, or they could be modeled according to the phenomena that allow the operations in the real world. Object specialization also means that the “engagement” actions may no longer be the universal activity. Instead, the operation phase will execute the primary operation for which each specific object exists in the simulation. This change in perspective still considers objects as vehicles or creatures that dynamically interact with the environment. However, buildings and similar cultural features may also be treated as independent objects. These features are currently treated as part of the environment.
The components within a simulation system support increasing complexity and allow the system to grow and spread over many computers. This diagram illustrates the most dominant functionality found in many major simulation products. A specific product will include additional layers or components to meet its specific needs, but the components shown here are found in some form in almost all large simulation products. 1) Hardware and Networks. 2) Operating System and Distribution Management. 3) Data Management. 4) Event and Object Management. 5) Time Management. 6) Synthetic Environment. 7) Models. 8) User Interfaces. 9) Translators.