I.2.1 Systems and System Environment

To model a system, it is necessary to understand the concept of a system and the system constraints. We define a system as a group of objects that are joined together in some interaction or interdependence toward the accomplishment of some purpose. An example is a production system manufacturing automobiles. The machines, component parts, and workers operate jointly along an assembly line to produce a high-quality    vehicle.
A system is often affected by changes occurring outside the system. Such changes are said to occur in the system environment. In modelling systems, it is necessary to decide on the boundary between the system and its environment. This decision may depend on the purpose of the study.

I.2.2 Components of a System

In order to understand and analyse a system, we need to define a number of terms.
i) entity:  This is an object of interest  in the system. An          attribute  is a property of an entity.
ii) activity:  Represents  a time period of specified length. If a bank is being studied, customers might be one of the entities, the balance in their checking accounts might be an attribute, and making deposits might be an activity.
iii) state of a system: A collection of variables necessary to describe a system at a particular time, relative to the objectives of a study. In a study of a bank, examples of possible state variables are the number of busy tellers, the number of customers in the bank, and the time of arrival of each customer in the bank.
We categorise systems to be one of two types, discrete and continuous.

iv) Discrete system: The state variables change instantaneously at separated points in time. A bank is an example of a discrete system, since state variables, e.g. the number of customers in the bank, change only when a customer arrives or when a customer finishes being served and departs.
v)  Continuous system: The state variables change continuously with respect to time. An aeroplane moving through the air is an example of a continuous system, since state variables such as position and velocity can change continuously with respect to time.

Few systems in practice are completely discrete or completely continuous, but since one type of change predominates for most systems, it will usually be possible to classify a system as being either discrete or continuous.
With  respect to discrete systems, we define an event as an instantaneous occurrence that may change the state of the system. The term endogenous is used to describe activities and events occurring within a system, and the term exogenous is used to describe activities and events in the environment that  affect the system.

I.2.3 Model  of a System

A model is defined as a representation of a system for the purpose of studying the system. In practice, what is meant by "the system" depends on the objectives of a particular study. For most studies, it is not necessary to consider all the details of a system; thus, a model is not only a substitute for a system, it is also a simplification of the system. However, there should be sufficient detail in the  model to permit valid conclusions to be drawn about the real system.
Different  models of the same system may be required as the purpose of investigation  can change. For example,  one may want to study a bank to determine the number of tellers needed to provide adequate service for customers who want just to cash a check or make a savings deposit. The model can be defined to be that portion of the bank consisting of the tellers and the customers waiting in line or being served. If the loan officer and the safety deposit boxes are to be included, the definition of the model must be expanded in an obvious way.
Just as the components of a system were entities, attributes, and activities, models are represented similarly. However, the model contains only those components that are considered to be relevant to the study.

System    A collection of entities that interact  together over time to accomplish one or more goals
Model        An abstract  representation of a system, usually containing logical and/or mathematical
        relationships which describe a system in terms of state, entities, and their attributes, sets,
         events, activities, and delays
System state    A collection of variables that contain all the information necessary to describe the system
         at any time
Entity        Any component in the system which requires explicit representation in the model and that
         can change the state of  the system
Item        Any component in the system which requires explicit representation in the model and that
         cannot change the  state of the system
Attributes    The properties of a given entity or item
Event        An instantaneous occurrence that changes the state of a system
Activity    A duration of time of specified length, which length is known when it begins (although it
         may be defined in terms of  a statistical distribution)
Action        An action is a series of changes to the state; every individual change is called an action
Transform    An action that changes the attributes, but not the number of components (entities or
        items)
Split/Join    An action that splits a number of new components, or a number of components are joined
        together to one new component.
Process    A series of state changes within a component during a particular time-span
Process    The system is modelled as a combination of processes and interactions (relations)
interaction

Table 1.1: Overview of simulation concepts.

I.2.4 Experimentation and Simulation

At  some point in the lives of most  systems, there is a need to study them to try to gain some insight into the relationship  among various components, or to predict performance under some new conditions being considered. Figure 1.1 maps out different  ways in which a system might be studied.

Figure 1.1: Ways to study a system.

I.2.4.1 Experiment with the Actual System  vs. Experiment with a Model of the System

If it is possible (and cost-effective)  to alter the system physically and then let it operate under the new conditions, it is probably desirable to do so. In this case there is no question about whether what we study is relevant.  However, it is rarely  feasible to do this, because such an experiment would often be too costly or too disruptive to the system. For example, a bank may be contemplating  reducing the number of tellers  to decrease costs, but actually trying this could lead to long customer delays and queues. In more abstract terms this "system" might not even exist, but we nevertheless want to study it in its various proposed alternative  configurations to see how it should be built in the first place. Examples of this situation might be modern flexible manufacturing facilities, or strategic nuclear weapons systems. For these reasons, it is usually necessary to build a model as a representation  of the system and study it as a surrogate for the actual system. When using a model, there is always the question of whether it accurately reflects the system for the purposes of the decisions to be made.

I.2.4.2 Physical  Model vs. Mathematical  Model

To most people, the word "model" evokes images of clay cars in wind tunnels, cockpits disconnected from their aeroplanes to be used in pilot training, or miniature super tankers scurrying about in a swimming pool. These are examples of physical models (also called iconic models), and are not typical of the kinds of models that  are usually of interest in systems analysis and computer simulations. In some circumstances it has been found useful to build physical models to study engineering or management systems; examples include tabletop scale models of material-handling systems, and in at least one case a full-scale physical model of a fast-food restaurant inside a warehouse, complete with full-scale, real (and presumably hungry) humans.

The vast majority of models built for such purposes are mathematical, representing a system in terms of logical and quantitative relationships that are then manipulated and changed to see how the model reacts, and thus how the system would react--if the mathematical model is a valid one.

Perhaps the simplest example of a mathematical model is the familiar  relation  d = vt, where v is the speed of travel, t is the time spent travelling, and d is the distance travelled. This might provide a valid model in one instance (e.g., a space probe to another planet after it has attained its flight velocity) but a very poor model for other purposes (e.g., rush-hour commuting on congested urban freeways).

I.2.4.3 Analytical Solution vs. Simulation

Once we have built a mathematical model, it must then be examined to see how it can be used to answer the questions of interest about the system it is supposed to represent. If the model is simple enough, it may be possible to work with its relationships and quantities to get an exact, analytical solution. In the d = vt example, if we know the distance to be travelled and the velocity, then we can work with the model to get t = d/v as the time that will be required. This is a very simple, closed-form solution obtainable with just paper and pencil, but some analytical solutions can become extraordinarily complex, requiring vast computing resources; inverting a large non sparse matrix is a well-known example of a situation in which there is an analytical formula known in principle, but obtaining it numerically in a given instance is far from trivial. If an analytical solution to a mathematical model is available and is computationally efficient, it is usually desirable to study the model in this way rather than via a simulation. However, many systems are highly complex, so that valid mathematical models of them are themselves complex, precluding any possibility of an analytical solution.  In this case, the model must be studied by means of simulation, i.e., numerically exercising the model for the inputs in question to see how they affect the output measures of performance.
While there may be an element of truth to pejorative old saws such as "method of last resort" sometimes used to describe simulation, the fact is that we are very quickly led to simulation in many situations, due to the sheer complexity of the systems of interest and of the models necessary to represent them in a valid way.
Given, then, that we have a mathematical model to be studied by means of simulation (henceforth referred to as a simulation model), we must then look for particular tools to execute this model (i.e. actual simulation). It is useful for this purpose to classify simulation models along three different  dimensions:

I.2.4.4  Static vs. Dynamic Simulation Models

A static simulation  model is a representation of a system at a particular  time, or one that may be used to represent a system in which time simply plays no role; examples of static simulations are Monte Carlo models (see chapters 2 and 7). On the other hand, a dynamic simulation  model represents a system as it evolves over time, such as a conveyor system in a factory.

I.2.4.5 Deterministic  vs. Stochastic Simulation Models

If a simulation  model does not contain any probabilistic (i.e., random) components, it is called deterministic. A complicated (and analytically intractable) system of differential equations describing a fluid flow is an example of such a model. In deterministic models, the output is "determined" once the set of input quantities and relationships in the model have been specified, even though it might take a lot of computer time to evaluate what it is.
Many systems, however, must be modelled as having at least some random input components, and these give rise to stochastic simulation models. Most queuing and inventory systems are modelled stochastic. Stochastic simulation models produce output that  is itself  random, and must therefore be treated as only an estimate of the true characteristics of the model; this  is one of the main disadvantages of simulation.

I.2.4.6 Continuous vs. Discrete Simulation Models

Loosely speaking, we define discrete and continuous simulation  models analogously to the way discrete and continuous systems were defined above. It should be mentioned that a discrete model is not always used to model a discrete system and vice versa. The decision whether to use a discrete or a continuous model for a particular system depends on the specific objectives of the study. For example, a model of traffic flow on a freeway would be discrete if the characteristics and movement of individual cars are important.    Alternatively, if the cars can be treated "in the aggregate," the flow of traffic can be described by differential equations in a continuous  model.

I.2.5 A Closer Look at System Models

Although many attempts have been made throughout the years to categorise systems and models, no consensus has been arrived at. However, it is convenient to make the following distinction between the different models:

I.2.5.1 Continuous-Time Models

Here the state of a system changes continuously over time. These types of models are usually represented by sets of differential equations. A further subdivision would be:
* Lumped parameter models expressed in ordinary differential equations (ODE's):

dx/dt = f(x,u,t)

* Distributed parameter models expressed in partial differential equations (PDE's):

Figure 1.2: Trajectory of continuous-time model.

I.2.5.2 Discrete-Time Models

With discrete-time models, the time axis is discretised. The system state changes are commonly represented by difference equations. These types of models are typical to engineering systems and computer-controlled systems. They can also arise from discrete versions of continuous-time models.

The time-step used in the discrete-time model is constant.

Figure 1.3: Trajectory of a discrete-time model.

I.2.5.3 Discrete-Event Models

In discrete-event models, the state is discretised and "jumps" in time. Events can happen any time but only every now and then at (stochastic) time intervals. Typical examples come from "event tracing" experiments, queuing models, Ising spin simulations, image restoration, combat simulation, etc.

Figure 1.4: Trajectory of discrete-event model.