1. Modeling and Simulation: Exploring Dynamic System Behaviour
Chapter 2
The Modelling and Simulation Process

2. Topics of discussion Some reflections on models
Exploring the foundations
The observation interval
Entities and interaction
Constants and parameters
Variables, input and output
The modelling and simulation process
The dynamic modelling landscape

3. Some Reflections on Models
“A model is a representation of an object, system or idea in some form other than itself”, Shannon (1975)
E.g. physical models (outside scope of this course)
Static models versus dynamic models
We are concerned exclusively with dynamic models
Simplifying assumptions
Used to manage the complexity of the model
Need to be explicitly stated
Challenge is to balance the complexity and credibility
A model has a range of credibility that should always be respected.

4. The observation interval
Io: Interval of time over which the behaviour of the SUI is of interest.
Starting point usually explicit
Ending point can be explicit or implicit
Data collection interval does not always start at the start of the observation interval

5. System Structure - Entities
Components that populate space encompassed by SUI
Must recognize that model exists within a larger universe
Exogenous entities: components from the environment that influence the SUI
Arrival of ships in port
Roadway surface when evaluating car suspension
Endogenous entities: interacting components internal to the SUI, fall into roles:
Consumer: customers, messages, orders, vehicles, manufactured widgets, shipments, predators, bacteria, pollutants, forces
Resources: servers (in banks, gas stations, restaurants, call-centres), transport services (cranes, trucks, tugboats) or health services (ambulances, operating rooms, doctors/nurses)
Queues: line of consumer entities waiting for a resource entity
Groups: group of consumer entities engaged in the same activity, e.g. interacting with a group of resources

6. System Under Investigation (SUI)
Examples of Entities
System Under Investigation (SUI)
Consumer Entities
Resource Entities
Queue Entities
Widget Manufacturing
Parts
Broken Machines
Machines
Repair technicians
List of component parts
List of broken machines
Restaurant
Customers
Tables
Servers
Kitchen/cooks
Customers waiting for tables
Customers at tables waiting for service

7. Examples of Entities (continued)
System Under Investigation (SUI)
Consumer Entities
Resource Entities
Queue Entities
Gas Station
Cars, trucks
Pumps, Attendants
Queue of cars at each pump
Hospital Emergency Room
Patients
Ambulances
Doctors
Nurses
Examination rooms
Waiting room queue
Critical patient queue
Patients in examination rooms
Ecological System
Predator population
Prey population

8. Entity Interactions = System Behaviour
Interaction between entities that populate the model
Nature of interactions unrestricted
Thus modelling and simulation allows solving problems with complex behaviour that cannot be solve otherwise
Environment can also interact with the model
But the model does not influence the environment

9. Data Requirements Data requirements Data Models
Some entities give rise to data requirements.
This data energizes the model specification (needed for behaviour generation)
Many forms: customer arrival rate, equipment failure rate, coefficient of friction in a pipe in a chemical process
Associated to both endogenous and exogenous entities
Localised and often secondary to structural specification
Data Models
Detailed specification of a data requirement
Can be elaborated separately from the main model development
Such development is challenging, particularly with DEDS (discrete event dynamic system) models

10. Revisiting the Gas Station
Entities:
Attendants
Queue in front of each pump
Cars and vans that enter the station
An input entity stream refers to the set of entities such that have a transient existence in the model (e.g. vehicles)
Data models:
Arrival rates of the cars and vans
Service times for each of three phases of service

11. Modelling a step towards a computer model
Must have some rigorous specification
A number of approaches exist
Fundamental to all approaches are variables, constants and parameters

12. Constants and Parameters
Constants and parameters associate names to constant values that do not change during a simulation run.
Examples: g – force of gravity; NCkOut – number of check out counters in a supermarket
Constants
Can represent the constraint of the environment – for example friction coefficient of a tire rolling on a road
Parameters
May be varied from one experiment to another to achieve the goal. i.e. explore the model’s behaviour with different parameter values
Eg – number of berths in a port, number lanes on a road, number of tellers at a bank

13. Time Dealing with dynamic systems Need to capture the passage of time
The variable t represents this passage
Note that we are dealing with simulated time (not real time)
Start time is always t = 0
Time units vary from model to model
“Primitive” variable as it is independent of all other variables
Other variables are dependent on time

14. Time Variables
Vary with time and provide means for developing behaviour
Denoted as a function of time, e.g. V(t)
Regarded as representing “time trajectories”
Domain of V(t), Đ[V], refers to values of t over which V is defined (e.g. the observation interval)
The computation process restricts the domain set Đ[V] to a finite set
Implies that a time variable V(t) can be associated to a finite set of ordered pairs, the trajectory set:
Ŧ[V] = {(ti,vi): ti Đ[V]}, where vi = V(ti)

15. Variables Input variables State variables Output variables
Represents the impact of the environment on the model
State variables
Use to represent the state of the model
Time variables:
Output variables
For gathering information about the behaviour of the model to ultimately meet the goal of the project

16. Input Variables
Allows modelling of the influence of exogenous entities on the model
Model does not affect input
Consider input variable fa – friction on airplane that is dependent on is altitude
Airplane altitude, hence the model, has influence on the value of fa
But altitude of airplane. i.e. airplane behaviour, cannot affect the physical law, density of air reduces as altitude increases
Input entity stream

17. State Variables State variables have a constructive property
Model’s dynamic behaviour is constructed in terms of state variable together with input variables and parameters.
Exists a minimal set of state variables to represent the state of the model, but not restricted to this set to allow clarity
Set of variables captures the past behaviour of the model
Property Σ – if the model behaviour were interrupted, saving the current values of the state variables is all that is needed to continue the behaviour later.
For continuous time dynamic systems (CTDS), state variables are readily identified
For DEDS, dealing with entities for which attributes are defined and the notion of state variable is much less evident
Variables can be complex data structures such as lists within lists
Relationship to output requirements (observing behaviour)

18. Output Variables
Capture the features of behaviour motivated by project goal, i.e. what we want to know about model behaviour
Can even regard model as an outgrowth of output variables
E.g. number of messages waiting to be processed at a network node
Based on recording values during the behaviour: point-set output variables (PSOVs)
Assumption R: Output is recorded as the experiment progresses (output variables do not have property Σ)
Scalar output variables (SOVs) correspond to a scalar value generated during experimentation
Function of state variables

19. Point-Set Output Variables (PSOVs)
Time Variable:
Recorded as a trajectory set:
Ŧ[Y] = {(ti,yi): ti Đ[Y]}, where yi = Y(ti)
Assumption R means that the ordered pairs (ti,yi) are deposited into Ŧ[Y] as they are generated
Sample Set Variable (for DEDS):
Entity instances in a DEDS model leave a data trail, e.g. the waiting time of customers in queue
Such data values are saved in a “sample set”, e.g. for sample variable D, sample set is defined as
Ψ[D] = {d1, d2, dN}
The sample variable D is in reality a random variable, and it’s sample set, a set of observations on the random variable.

20. Scalar Output Variables (SOVs)
Derived Scalar Output Variables (DSOVs):
For DEDS models, rarely interested in the PSOV
Apply an operator to the sets, e.g. AVG(Ŧ[Y]) or MAX(Ψ[D] )
The application of such operators can be a post-processing step to experimentation
For DEDS models, often referred to as a performance measures
Simple Scalar Output Variables (SSOVs):
SOV whose existence is not founded on a PSOV
For example, the number of customers that balked during the observation interval
Examples of DSOVs:
The amount of time that a teller is busy in a bank
The average size of a queue for components being serviced by a machine
The average wait time a customer experiences in a doctor’s office

21. Modelling with parameters and variables

22. Bouncing ball – Problem Description
Boy is on the edge of an ice pond with a hole in the middle
He has a ball that he wishes to bounce into the hole
He throws the ball upwards and towards the hole
Gravity pulls the ball down while a head wind pushes the ball back towards the boy
Goal: Have the ball bounce at least once and then fall trough the hole in the ice.
Assumptions:
We assume that when the ball is released from the boy’s hand, the velocity vector, V0, lies in a vertical plane that passes through the boy’s position and the location of the hole in the ice (this ensures that the ball is heading, at least initially, in the direction of the hole).
We assume that the horizontal wind velocity is parallel to the plane specified in (a) above (this ensures that the wind will not alter the “correct” direction of the ball’s initial motion; i.e., towards the hole).

23. Bouncing Ball – Conceptual Model
State variables
x1(t) = ball’s horizontal position
x2(t) = ball’s horizontal velocity
y1(t) = ball’s vertical position
y2(t) = ball’s vertical velocity
V0 = Initial velocity
Newton’s law: F = ma
Behaviour rules:

24. When the Ball Bounces Assumptions
Symmetric: angle of incidence is equal to angle of reflection, i.e. velocity vector orientation changes from θC to –θC
Kinetic energy is lost, that is the magnitude of the velocity vector changes from |VC| to α |VC|, where 0 < α < 1
The bounce dynamics are expressed as:
Before leaving this example, it is of some interest to revisit the stated goal of this modelling and simulation project. In particular, consider the fundamental issue of whether or not the underlying problem has a solution. It is important to recognize here that the existence of an initial release angle of the ball (θ0) that will cause the ball to fall through the hole in the ice is not guaranteed. This is not a deficiency in the model but is simply a consequence of the underlying physics. The boy’s throwing action gives the ball kinetic energy which is dependent on the release velocity (V0). This energy may simply be insufficient to accommodate the energy losses encountered by the ball over the course of its trajectory and the ball may not even be able to travel the distance H where the hole is located.

25. Modelling and Simulation Process

26. Modelling and Simulation Process (continued)

27. Project Description Project goal
Description of behavioural features of the SUI
Informal language, colored by SUI related jargon
Informal sketches used to represent structural features
Communications tool to understand the problem

28. Conceptual Model (CM)
Refinement phase, where project description is reformulated in terms of parameters and variables
The CM provides a basis for the development of the simulation model, i.e. bridge between the project description and simulation model
Number of formalisms available: mathematical equations, symbolic/graphical formalisms, structured pseudo-code, or any combination
Can be a collection of partial models that need not be uniform
Consolidation of structural and behavioural features in concise and precise format
Often information from project description is inadequate – leads to the clarification loop
Verification associated to the transition from the project description to the conceptual model
Mathematical equations (algebraic and differential equations)
Symbolic/graphical formalisms (Petri nets, finite state machines)
Structured pseudo-code
Combinations of these
Can be a collection of partial models that need not be uniform

29. Simulation Model
Representation of the CM in a computer programming language.
Next step to an executable form of the model in order to generate the “behaviour” of the model
Solution to the problem is obtained from the analysis of the data produced by this “behaviour”
Many simulation languages exist for creating simulation models and simulation programs
SIMSCRIPT II.5, MODSIM, GPSS, SIMAN, ACSL, Modelica, Arena, CSIM, and SIMPLE++
Simulation model is a software product -> same development features of any software product
Transformation and verification process (ensure that transformation is correct)

30. Simulation Program
Augments the simulation model to provide auxiliary services – two categories
First: services related to implementation issues
Initialisation
Assignment of observation interval
Management of stochastic features
Solution of equations (differential equations)
Data collection
Simulation languages and environments provide constructs for these services
General purpose languages require that everything be built from scratch

31. Simulation Program (continued)
Second: services related to nature of experiments
Associated with realizing project goal
Data presentation (visualization and animation)
Data analysis
Database support
Etc.
Care should be taken to keep separate the code of the simulation model separate from code required by ancillary services
To ensure that simulation program remains easy to verify, understand and maintain.
Verification
Verify decisions made relating to the execution of the simulation model
Example: a number of methods exist for the solution of differential equations, each with their strengths and weaknesses

32. Operational Phases
So far, have been developing various versions of the model
Evolution of different representations of the SUI
With a simulation program, stage is set for 2 operational phases
Verification/Validation phase
Experimentation phase

33. Verification and Validation
Validation: are we building the right product?
Verification: are we building the product right?

34. Verification
No loss of credibility as model undergoes transformation from problem description to simulation program
Confirmation of the integrity of the software environment
Examples:
Adequacy of numerical software for the solution of differential equations
Adequacy of the generation of random number stream in a DEDS model.

35. Validation
Credible model (adequate emulation of the SUI behaviour) from the perspective of the project goals
Examples
Confirmation of selected thermodynamic principles used in modeling the control systems of a thermoplastics manufacturing plant
Confirmation of the rules of behaviour for the operation used in modeling elevators in a large metropolitan hospital.
“Complete validation” is unattainable
Best to hope for is “failure to invalidate”
Start validation as early as possible, i.e., at the stage of problem definition composed of many facets
Consider model validated for evaluating the business plan of a commercial airline
Above model will not qualify for determining an aircraft’s aerodynamic characteristics (same airline)

36. Validation (continued)
Face validation
Observed behaviour appears correct by means of animation, graphical displays or the values of designated variables
More qualitative than quantitative
Naïve approach but still useful when the judgment of “domain experts” are included
Behaviour validation
Validating using a collection of anticipated known behaviours
E.g.
Engine failure of aircraft leads to decrease in altitude
Doubling arrival rate of tourists in model of urban area should lead to about double occupancy rate of hotels
Replicative validation
Collect input-output behaviour of SUI in a database
Compare input-output behaviour of model to observed SUI behaviour
Validation of Data Modelling

37. Quality Assurance Documentation Program development standards Testing
Experiment Design
Interpretation and Presentation of Results

38. The Dynamic Model Landscape
Deterministic versus stochastic
Stochastic dynamics contain elements of randomness
Discrete versus Continuous
Discrete: changes occur in the system at discrete points in time
Continuous: Changes occur in the system continuously (idealized view, in reality, computational process imposes discrete “jumps” in time)
Class of models combine both discrete and continuous features (beyond scope of this course)
Linear and Nonlinear
Because of numerical computation used in M&S process, simplifications due to linearity of a system has no consequence in the M&S realm
Absence of any need to distinguish between linear and non-linear systems is a noteworthy feature of modelling and simulation.

39. Coffee Shop
The coffee shop contains some 15 tables. It is Saturday morning and the tables are almost full. At the back of the shop is a counter with one cash register. Behind the counter are two women serving customers using two coffee machines. At the counter, there is a long line of customers waiting for service.
Draw schematic, concept graph, notes for the system described
Compare to neighbor group – are they similar, what are differences

40. Barber Shop
The barber shop has 5 chairs around a small table with magazines. There are two barber chairs with customers being serviced by 2 barbers. A counter and cash register is by the door. There is a small coffee machine in a corner where customers can help themselves. The chairs are full. The owner (one of the barbers) noticed that on Saturday mornings, many drop in customers do not enter when they see that the chairs are full. He is wondering how much business he is losing.
Repeat exercise
At end note if it was easier to model, are schematics, concept graphs simpler/more complex
Compare to neighbor gain – are there more or less differences than in previous exercise.