Chapter 1 Introduction to Modelling and
Simulation
[First Draft CBPrice September 22 2011]
[Revised Oct 3]
[Revised Dec 11]
The Nature of Modelling and Simulation
The Purpose of Modelling and Simulation
We view modelling and simulation as a tool to solve problems, e.g.,(i) how to hit a badminton shuttle-cock
to just clip over the net, or (ii) how to design a wind turbine farm to most optimally extract energy from the
wind and convert it into electricity, (iii) how to design a car suspension system to provide the best ride. You
will experience all of these problems in this module. We also view the problem as relating to a system, a
number of components whose individual behaviour can be described in some way, but also where the
interactions between the individual components can be described. Think of a car as a system. You may
conclude that its components are the engine, the gearbox, the suspension, the wheels the interior. That’s not
a bad choice, and we shall return to this example later.
You may have noticed some common elements in the examples given above. There was first the statement
of the problem context (“car suspension”) but an associated problem goal (“to provide the best ride”). That’s
what modelling and simulation is about. First you have to identify the problem context and then you have to
identify the problem goal. The goal may be something like striving for the “best” or “optimal” solution, or it
may be a “what-if” question, such as to find out what happens if the car hits a sleeping policeman at high
speed. If you were working in a company, then more than likely, the context and the goal will be given to
you. This is the approach we shall take in this Workbook, where we shall consider some models in the fields
of (i) Physics, (ii) Engineering, (iii) Biology and (iv) Sociology. These fields are all highly significant in our
contemporary world; they are the focus of much academic and industrial/commercial research, and your
study of these fields will enhance your own employability!
Today, modelling and simulation is based on the use of the computer. A correctly crafted computer
simulation of a problem will provide a deep understanding of the problem and therefore an advantage to a
commercial company. For example, a deep understanding of car suspension systems (obtained through
modelling and simulation) will give a motorcar manufacturer a competitive advantage in the design of their
suspension systems. Yes, this is also true of “Formula 1”.
Indeed, the existence of the computer has allowed us to simulate (and therefore understand) systems of a
high degree of complexity (that means having a large number of components) such as weather prediction,
climate change, nuclear power station controls and even social interactions (marriage, divorce, panic, riot
behaviour).
The whole point of a simulation of a system is to provide some data showing how that system behaves,
without having to engage with or experiment with the real system in the real world. This data will help us
understand the real system. A modelling and simulation of a potential riot situation would not replicate the
actual riot, by conducting experimental riots (which would involve harm or even loss-of-life). It would be
through the riot model, and its simulation that an understanding of this situation could be obtained, and
therefore used to plan how best manage the real riot situation. So the results of modelling and simulation
have a real use.
A correct simulation of a wind-turbine farm could accurately predict the power output of a particular windturbine design. The simulation would be able to investigate the effects of changing the mechanical design
details of the rotor blades, the power conversion system structure and of expected wind conditions. This
would not be possible in the real physical world, since it is not economically viable to construct real physical
wind turbines to investigate all design possibilities.
Not convinced? You may ask “what is the point of simulating a system when the system exists in the real
world”? That system exists and can be investigated and analysed. Continuing our example of a car
suspension system, well cars exist and so do their suspension systems in the real world, so why simulate?
Think about it. How much time and effort is required to produce 100 variants of a real suspension system,
involving all the associated processes of mechanical engineering? How much time is needed to investigate
these systems and analyse their properties? This will typically involve years and many engineers working on
the project. This is where modelling and simulation realises its power. The investigation of these 100
variants may take one week using the modelling and simulation approach.
Application of Modelling and Simulation
As hinted above, a model and its simulation provide a surrogate for a system in the real world, which means
that it replaces the real-world system in some sense. You may ask again what is the point of working with
this surrogate when the real-world system exists and can be observed? Well, remember that simulation
involves experimentation, finding out what happens when some aspect of the system changes, e.g., when a
wind-turbine is subject to very high speed winds. Performing real-world experiments may not be appropriate
because of the following reasons:
(i)
(ii)
(iii)
(iv)
(v)
It is impossible to perform the real-world experiments, e.g., we can’t control the wind speed near
a wind-turbine. Yet within a simulation we can!
An experiment may have irreversible consequences, e.g., allowing student doctors to perform
treatments may be harmful to real patients. Simulated treatments (such as laparoscopy) within a
simulation can be reversed through a click on the “reset” button.
The problem context may render real-world experimentation too dangerous. Think about
investigating the limits of a nuclear reactor control system, or subjecting a 747 to a real partial
loss of hydraulic pressure. “Simulations are safe”
A real-world problem exists and there may only be one attempt to solve it; there is no room for
experimentation. Think about the Apollo 13 mission where an internal explosion in the fuel tanks
destroyed much of the Command Module functionality. Here there was no opportunity to test out
various ideas. Thanks to a ground-based series of planned simulation experiments, the correct
power-up sequence was obtained, uploaded and executed with the successful return of the Apollo
13 astronauts.
The context may make real-world experimentation too costly, e.g., changing the number of
“express checkout counters” in all supermarkets of a particular chain, to investigate the possible
gains in customer throughput.
(vi)
There may be moral or ethical implications. Is it ethical to try to control the population of one
species in an ecological environment by the introduction of a predator?
This list of justifications for the need for modelling and simulation (which you are invited to extend) leads in
to possible areas of application of modelling and simulation. Here’s some possible examples:
(i)
(ii)
(iii)
(iv)
(v)
(vi)
Education and Training. There is currently research into the use of computer game technology in
the training of doctors (e.g., laparoscopy) and of “triage” within a disaster scenario. Other
approaches used simulated bodies. My own research group is developing physics and
engineering simulations to be used in secondary school and undergraduate courses. Training of
pilots using simulations is important since this avoids the cost of training in real-world planes
and the safety issues involved.
Forecasting. Super-computers are used in weather forecasting with the results we know. It is
impossible to experiment with the weather, so forecasting relies on simulations.
Engineering design. Simulations are used in many engineering disciplines, including the design
of bridges, aircraft, cars as well as medical devices. These simulations avoid the problem of
development costs.
Safety and Risk assessment. Good examples are the evacuation of buildings when there is a
spreading fire, or a terrorist attack; the control of nuclear power stations.
Prototyping. The design and development of a new system usually will involve a cycle of
producing and evaluating prototypes. This may be costly for the development of a new product
which starts out at the “concept” stage, which means it is not based on a previous product. For
example, a manufacturer of solar panels wishes to move into the wind-turbine market. Their
development team suggests that they have a novel product with unique features, but they cannot
construct a real-world prototype, since they do not have the manufacturing skills. Modelling and
simulation would help them to evaluate their concept, to produce a prototype and refine this and
so decide on a new business plan, which leads onto
Making decisions. Continuing the above example, the manufacturer can make a business
decision, whether or not they should extend their product range, into the wind-turbine market.
What is a Model?
You may already have experience of commercial computational models, for example trying out Flight
Simulators, or playing computer games where you control the behaviour of cars. You may have felt that the
underlying simulation was perfect (in the sense that it totally reproduced reality) where you experienced a
high-fidelity graphical display and responsive interaction. Those of you who really drive cars or fly planes
(or even *board) will realise that this is nonsense, in reality the simulations you experienced were far from
perfect.
A model and its computational simulation is not intended to reproduce reality in all of the details of the real
physical world. This is impossible, since the real physical world works on the level of atoms and whereas
the simulation of an atom in computer code is possible (and has been done), this requires a computer
programme, which in itself requires many, many atoms when compiled and stored in memory. So a
computer simulation of reality which reproduces reality requires more atoms that exist in reality. This
implies an increase in complexity, or dimensionality which cannot help us in understanding real-world
scenarios since ultimately it would create a world larger than the world we live in. That is nonsense, and
therefore is the subject of a philosophical reflection. What we need in our modelling and simulation
enterprise is a reduction in the complexity or the dimensionality of the system.
Let’s consider this from the point of view of an automobile manufacturer who wishes to develop a new
suspension system [goal ???] which will enable its cars to negotiate bends at an increased speed. This is a
realistic goal and has been attempted before in the rail industry, where the first attempts at the Advanced
Passenger Train (did they simulate?) failed, but the Virgin “Pendulino” system worked (did they simulate?).
To return to our example, the question is, at what level of detail does the automobile manufacturer need to
model? The suspension system comprises at least, springs and shock absorbers. But springs are made of
geometrical structures (helices) and metals which are also systems. Shock absorbers comprise pistons and
cylinders and gases; clearly they are systems. You get the idea, each system is composed from a number of
(sub-) systems. And moving down the levels of (sub-) systems we experience an increase in complexity.
So what the automobile manufacturer needs to know is which level of complexity, ie which system
description is appropriate to solve the problem goals. This defines the model and its associated simulation. It
is therefore important to understand the problem goals before stepping down to create a model and a
programmed simulation.
Historical Overview
The original computer technology used in modelling and simulation was the analogue computer. Such
computers implemented the required models through various electrical circuits which were connected with
wires. Let’s consider how we would write a computer programme to calculate the change in speed of a
projectile (ball, shuttle-cock or missile) as a function of time. We would code the equivalent of the physics
acceleration = rate of change in speed as 𝑎 =
𝑑𝑣
𝑑𝑡
and so compute the change of speed as ∆𝑣 = 𝑎∆𝑡 and so
write the code speed += acceleration*dT. Of course the acceleration will be defined by the model.
But the important aspect of our computation is that we compute the speed change in a particular interval of
time dT. The analogue computer works differently , it establishes a direct electronic model of the physical
situation, and through tis electronic circuits could simulate the model in real-time (which means that time is
continuous, without the need for a time increment dT. So these simulations were exact in the sense that they
solved exactly the underlying mathematics of the particular model. So why do we not use analogue
computers today in the general realm of modelling and simulation? Whereas the analogue computer was an
expert at solving models based on differential equations (such as describing projectile motion, hydro-electric
power stations or wind turbines), they could not be used to model and simulate other interesting scenarios
such as the spreading of disease, or of fire in space, the behaviour of queues in shopping markets, petrol
filling stations etc.
While analogue computers became commercially viable in the 1950’s, the speed of digital computers and
their software support had a major impact on the simulation industry in the 1960’s. Digital computer
approaches reached a level where they could replicate the results of analogue computers, and moreover,
digital approaches showed they could implement models and provide solutions not possible for analogue
computers. In the 1970s and 1980s software support for digital computer solutions was established, with
many ‘software libraries’ created for scientific and engineering solutions.
Recent years have shown the emergence of a number of professional associations and organisations that are
committed to research and deployment of modelling and simulation, and especially their implementation in
code. Noteworthy are safety-critical systems, especially in the automotive and aerospace industries. For
example the ‘MISRA’, the Motor Industry Software Reliability Association provides guidelines on how to
write C (and C++) code in a safety critical context, within the motor vehicle industry.
[devel here].
The Process of Modelling and Simulation
You can see an outline of the process of modelling and simulation in the figure below.
Project
Description
Conceptual
Model
Simulation
Model
Simulation
Program
Project Description
A M&S project begins with a project description document. This includes the project goals and the required
results of the M&S to achieve the project goals. This document will usually be laden with jargon associated
with the project, which has to be unravelled and interpreted at later stages in the project. Nevertheless, this
document would normally form the basis of further discussions which will lead in to the actual M&S
realisation.
Conceptual Model
This is the starting place for the M&S project. There are various ways to build such a model. For continuous
time simulations we would normally use a model based on differential equations. This would be appropriate
for modelling economics scenarios, rocket flight or car suspension. We could also use Petri Nets which may
be appropriate for modelling the flow of components in a manufacturing process, the flow of information in
an organisation, or the behaviour of shoppers in a check-out queue.
Simulation Model
The simulation model is in effect computer code which captures the details of the conceptual model. There
are many platforms available for the construction of this code, such as Vensim, Modelica, Labview though in
an academic research context the code may be developed in C/C++, Fortran or using Matlab. In terms of our
Computation Visualisation Interaction approach to simulation code, this model is clearly associated with
the computation code. This code captures the details of the conceptual model, but does not include the
algorithms which actually solve the model. For example, a simulation model of interacting predator-prey
populations (such as Lynx and Hares) may establish code which correctly calculates the interactions
between the animals, but does not actually solve the interactions.
Simulation Program
While the simulation model code is intended to correctly “compute” the conceptual model, this code must be
supplemented with additional support code. This falls into two categories: (i) For the case of a continuous
time M&S (such as the Lynx and Hares system), we need additional code to solve the interactions. There are
various approaches to doing this, such as Euler, Runge-Kutta, and this code needs to be incorporated into
our software which clearly is additional computation code. (ii) Additional features need to be provided to
the investigator to provide visualisation of the simulation experiments and interaction with the software to
easily observe key parameters and variables and to change these.
Verification and Validation
Before a simulated model can be used in an experimental investigation it has to be verified and validated.
Here is a way of remembering these and the difference between them
Verification: Are we building the model and simulation right?
Validation: Are we building the right model?
Let’s start with an example. Consider a wind turbine MS. Working from principles of aerodynamics (for the
blades), mechanics (for the gearbox) and electrics (for the generator) we may construct a conceptual model
using differential equations. The task of writing these down correctly and transforming them into correct
computer code falls into the realm of verification, (this is “building the M&S right) Confirming that the
actual behaviour of the equations and code accurately reproduce the behaviour of a real wind-turbine falls
into the realm of validation, (this is building the right Model).
So how would we verify and validate our M&S? Validation can be straightforward. We can compare the
results of our Simulation code with the behaviour of a real wind-turbine for a small set of experiments where
we vary say one parameter such as wind speed. If there is a clear difference between the real data and the
simulated data then the validation fails and we must revisit the whole M&S process.
[insert falling raindrop discussion here]
Verification may also be straightforward, e.g., our model may be cast as a set of differential equations, and
these will be converted into computer code and then solved using some algorithm (procedure). Verification
means checking that this algorithm and computer code implementation actually works. We’re not thinking
about buggy code here, we’re assuming that the code is OK. Rather we are asking the question, does this
code accurately work in solving the differential equations? There are various algorithms we can choose from
to do this. Have we made the right choice and have we implemented this correctly?
Verification can be approached by using the code to solve a simpler problem before moving on to our real
problem. For example, the code written to model and simulate the full control system of a wind turbine
could be tested on a baby problem, such as the thermostatic control of our domestic boiler. If our code fails
this baby problem, then there is no point in applying it to the wind-turbine.
In solving our differential equations which represent our model we need to use a “numerical integration”
algorithm. These algorithms provide only an approximation to the analytical mathematical solution, there is
always an error involved, since we are computing changes at discrete time intervals, whereas real-life time
flows continuously. Often we can control how large this error is, in general to reduce the error we need more
CPU cycles, so there is a trade-off between accuracy of the simulation and how quickly it can be computed.
In this context, verification involves making sure we have an acceptable level of error in our simulation.
So let’s attempt to summarise this.
Verification is done to ensure that (i) the correct algorithm is used to programme the model, (ii) the
programme has been written correctly, (iii) the errors in the simulation are acceptable.
Validation is done to ensure that (i) the Model correctly reproduces the behaviour of the real-world situation
being modelled, (ii) the Model meets its intended requirements. (iii) In some simple cases, the M&S can be
validated against an exact mathematical solution. The process of validation aims to invalidate a model by
pushing the model to its extreme limits. This will provide information about the model’s capabilities and
limitations, and will allow the investigator to know the ‘zone of reliability’ of the model.
Now let’s pull down some of this thinking into one of the tasks on this module, a M&S of the flight of a
badminton shuttlecock. The task involves development of a conceptual model for the flight of a shuttlecock
starting with a consideration of forces on the shuttlecock. Unlike the case of a tennis-ball, the shuttlecock
experiences a large amount of drag due to air resistance. This means that a “mathematical analytical”
solution does not exist. We cannot validate the M&S against a mathematical solution, unlike the case of a
tennis ball where air resistance may be neglected in the model and where an exact “mathematical analytical”
solution does exist.
So how do we proceed when we have created the model and implemented it in code? Verification would
start by testing the simulation on a simpler situation, where there is no air resistance and where a
“mathematical analytical” solution is available. If the simulated data do not agree with the predictions of the
“mathematical analytical” solution, then we have a problem with the model (differential equations) or our
transformation of this into computer code. Verification could be attempted by considering a highlysimplified scenario such as the vertical behaviour of a shuttlecock, where we choose to examine the
“terminal velocity” of the shuttlecock. There is a “mathematical analytical” solution for this velocity which
we could test. Verification should also consider the level of error in this simplified scenario where.
Validation of our M&S can be achieved in various ways: A “scientific” validation can only be achieved by
comparing our simulated shuttlecock trajectories with actual experimental trajectories recorded e.g. through
actual video recording of a badminton game using a motion capture facility such as available at the
Worcester “Motion and Performance Centre”. If our verified simulation code cannot be validated, then there
is something wrong with our initial model, perhaps we have incorrectly modelled air resistance.
A “face validation” could be obtained from the experience of players playing badminton, by comparing the
observed shuttlecock behaviour with the simulated results. The players would evaluate the simulation
against their real-world experience. As mentioned above, this “face validation” is a useful first step in a
validation process.
The Process of Modelling and Simulation – Application to Wind Turbines
Let’s discuss this using the example of modelling and simulating a Wind Turbine, focussing on the control
systems.
Project Description
A wind turbine has a complex control system which ensures that the turbine blades rotate with a variable
speed in order to extract the maximum power from that available in the wind at any speed. However this
rotational speed must be limited when the wind speed becomes too high, otherwise the turbine could
experience excessive stresses and fail. This project should work from the theoretical understanding of
aerodynamics and mechanics
Conceptual Model
The control systems of a wind turbine are designed (and therefore described) using differential equations.
This is because all of the details of the wind turbine behaviour and its excitation (the wind) vary
continuously with time. The model of the wind turbine may include several components such as (i) the
aerodynamics of the turbine blades, (ii) the mechanics of the shafts and gearboxes, (iii) the electrical
generator and, (iv) the overarching control system.
Here we shall focus on the control system which is designed with two goals in mind: (i) to extract the
maximum possible power from the wind (which is subjected to gusts of a variable speed and occurrence),
(ii) to limit the turbine behaviour in conditions of extreme wind speed, ie those speeds which may occur
above the design specification of the turbine. The control model will be specified as a number of differential
equations specifying the behaviour of the turbine elements, such as the torques on the drive-train and the
pitch of the rotor blades.
Simulation Model
The simulation model will be constructed according to the components of the conceptual model described
above which will normally be cast as a number of differential equations describing the dynamics of the
turbine sub-systems such as the rotor/generator speed and the rotor blade pitch-angle.
Simulation Programme
Since this system is complex, involving many components, the choice of the computational algorithm is
important. The simple Euler algorithm will surely fail. More appropriate is the time-adaptive Runge-KuttaFehlberg (RKF) algorithm, which copes well with most simulations (except “stiff” problems). We feel that
coding this algorithm within Unreal Script is infeasible due to the mechanics of the UDK programming
interface available. Therefore we choose to use standard RKF algorithm, implemented in C/C++ and bound
to the UDK engine
Verification and Validation
The verification of the wind-turbine code is no different from other situations. Primary verification involves
running the code and looking for a reasonable and stable result. This means that given an initial wind
velocity, the turbine should rotate with a constant velocity. If the velocity increases or decreases with time
and does not settle down then there is a problem with the code.
Validation is also quite straightforward. The wind-turbine model provides a theoretical graph of power
output versus wind speed, deduced from the mathematical analysis, using several key parameters. The
results of the simulation investigations using the parameters of a real wind turbine (footnote CART3) must
agree with this to validate the model.
Design of Investigations
Types of Dynamic Model
Most dynamic models consider two conceptual dimensions, time and space (or place). These dimensions
may be continuous or discrete. So we have a number of options which we summarise here according to the
syntax TiSj. Here “T” represents time and “S” represents space. The values of “i” and “j” may be “c”
(continuous) or “d” (discrete)
(1) TcSc: Continuous time and continuous space. For example projectiles, wind turbines. The motion of both
of these examples changes continuously.
(2) TcSd: Cellular automata of spreading fires. Here the simulation uses continuous time but discrete space,
where the area is divided into a number of discrete cells. The burning operates in continuous time.
(3) TdSc
(4) TdSd: Supermarket Queues. People arrive at queues at definite intervals in time. As the customers get
served, they move forward at definite intervals. Space is also discrete since the people move up the queue
which consists of a line of customers at discrete places in the queue.
Glossary








Model
Simulation
Complexity
Dimensionality
Real-World
Computer Code
Dynamic
Validation

Verification