Mathematical and Computational Modeling and Simulation

e ch nis

me ste Sy

Inf

orm

ati

k

Tec h Leitung: Prof. Dr.-Ing. D.P.F. Möller

Mathematical and Computational Modeling and Simulation Prof. Dr.-Ing. D.P.F.Möller VAK 18.211 Sommersemester 2005

Content 1. Modeling Continuous-Time and Discrete-Time Systems 2. Mathematical Description of Continuous-Time Systems 3. Mathematical Description of Discrete-Time Systems 4. Simulation Languages of Continuous-Time and Discrete-Time Systems 5. Parameter Estimation of Dynamic Systems 6. Soft Computing in Simulation 7. Distributed Simulation 8. Virtual Reality in Simulation Modeling and Simulation

D.P.F Möller

3. Mathematical Description of Discrete Time Dynamic Systems

Modeling and Simulation

D.P.F Möller

Content 3. Mathematical Description of Time Discrete Dynamic Systems 3.1 Introduction 3.2 Discrete Event Systems (DEVS) Formalism 3.3 DEVS Queue Description 3.4 More about Queueing Systems 3.5 More about Discrete Event Systems 3.6 Principles of Discrete Event Systems Simulation 3.7 Discrete Event Systems Programming Languages 3.8 Queueing Models 3.9 Statistical Models in Simulation 3.10 Manufacturing Systems in Simulation 3.11 Petri-Nets 3.12 Economic Systems 3.13 Medical Systems 3.14 Concepts of Power System Modeling and Simulation Modeling and Simulation

D.P.F Möller

3.1 Introduction The formalisms describing discrete event systems are as flexible as a common purpose programming language, and are not accessible for any analytical methods to calculate the trajectories for the model quantities in its original form. However, for some restrictions in modeling such calculations can be done up to a certain grade. To succeed on this analytical way some assumptions of system behavior and some restrictions in model design are necessary: • Restrictions in modeling will lead to restrictions in the significance of the results of a simulation study. • Restricting set of facilities for model description enables the developer of simulation software to give more support during the modeling process by ready-made components with blocks of model code.


D.P.F Möller

3.2 DEVS Formalism Formalism for discrete event systems (DEVS) A discrete event system specification is a structure M = < X, S, δ, ta > where X is a set, the names of external event types S is a set, the sequential states δ is a function, the transition specification ta is a function, the time advance function with the following constraints: • ta is a mapping from S to the non-negative reals with infinity: ta:S→R+0,∞ ta(s) is interpreted as the time the system is allowed to stay in state s if no external events occur Modeling and Simulation

D.P.F Möller

3.2 DEVS Formalism • The total state set of the system specified by M is Q = {(s, e)s ∈ S, 0 ≤ e ≤ ta(s)} both the sequential state s and the elapsed time e spent in this state are significant state variables • The transition specification δ consists of two parts: 1. The internal transition function δΦ: S→S if no external events arrive, the system will transition from sequential state s to δΦ (s) after ta(s) time units. Simultaneously the elapsed time component e is reset to zero 2. The external transition function δΦ: Q×S→S if an event x ∈ X arrives, and the system has been in state s for an elapsed time e, it transitions immediately to δex(s, e, x). Simultaneously, the elapsed time component is reset to zero Modeling and Simulation

D.P.F Möller

3.2 DEVS Formalism Chronologically of events is represented in system theoretic formalism by the concept of time segment, a mapping from a time interval to some descriptor set. In order to distinguish between event occurrence and nonoccurrence we introduce the artifact of a non-event symbols. The nonevent closure Xφ of a set X is obtained as follows: If X does not contain a non-event symbol then Φ is adjoined to it for this purpose; otherwise Xφ = X and Φ is identified with the existing non-event symbol A DEVS segment over X is a mapping ω: < ti, tf > → Xφ where < ti, tf > denotes a time interval in the reals and ω satisfies the condition ω(tj ) ≅ Φ for at most a finite subset { tf } (possibly empty) of < ti, tf >. The instants { tf } are the event times in the observation interval < ti, tf > Modeling and Simulation

D.P.F Möller

3.2 DEVS Formalism

If X is a set of external event names for a DEVS M then the segments over X represent possible input segments to which it responds. Example: Let X represent a set ob job identifiers and M a processor. An input segment then denotes a chronological sequence of job arrivals to M With DEVS M we wish to associate a system SM which represents its response to inputs segments. However, in order to be able to do so, the DEVS must posses from getting the property called legitimacy. Roughly legitimacy prevents a DEVS from getting into an infinite sequence of states in which the time clock of its simulator would not advance beyond a certain point.


D.P.F Möller

3.2 DEVS Formalism Let a system SM with a legitimate DEVS M be as follows SM = < R, XΦ, Ω, Q, Y, δ, λ > which indicates that the time base R is continuous and the input set is the non-event closure of the external set X. The input set Ω is the set of discrete event segments over XΦ and the state set Q is a set of total state pairs { (s, e)| s ∈ S, 0 ≤ ta(s) }. The transition function δ is defined as follows: Let ω: < ti, tf > → Xφ with event time τ1 ,…, τn, where we shall set τ1 = τf if the event set is empty. Computing the state has to be done such a way that SM will be in a time τ1 given that it started in state state q = (s, e) at time τin and received input segment ω. Let τ1 ,…, τm be the sequence of instants in the interval < tin, t1> and s1,…,sn be the corresponding sequence of sequential states that the model traverses in this interval. Modeling and Simulation

D.P.F Möller

3.2 DEVS Formalism No external events occur in the interval, we may generate the sequences of event times and sequential states from an instant t0 preceding tin which represents the point at which the system entered state s. Thus we have: t0 = tin -e ti+1 = ti + ta(si) s0 = s si+1 = δΦ (si) and m is the smallest i for which ti+1 ≥ τ1 The sequence t1,…,tm is the set of internal event times at which internally scheduled events occur before the incidence of the first external event. The sequence s1,…,sm is the corresponding sequence of sequential states that the system moves through during this time. The total state that the system is in at time τ1 is q´= (sm, τ1 - tm) The total state pertaining just after the external event x1 arrives at τ1 is q1 = ( δex (q´,x1),0 ) Modeling and Simulation

D.P.F Möller

3.2 DEVS Formalism A state s ∈ S for which ta(s) = ∞ is said to be passive. A system will stay in such a state indefinitely, only possibly changing state under the influence of an external event. The internal transition function δΦ need not be defined for a passive state. A state which is not passive is said to be active; in particular, a state s for which ta(s) = 0 is said to be transitory. Sequences of transitory states provide the means to express intermediate model computations which do not consume model time – the clock of a simulator is not advanced in the execution of such states. Let x ∈ X be an external event and (s, s´) be a pair of sequential states such that δ(s, e, x) = s´ for some elapsed time e ∈ [0, ta(s)]. If s is passive and s´ active than x is said to activate the model; in particular if s´ is transitory, then x is said to activate the model immediately. Conversely, if s is active and s´ is passive then x is said to passivate the model.


D.P.F Möller

3.2 DEVS Formalism The same terminology applies to transactions caused by internal events. A model passivates itself by entering into a passive state form an active state. However, by definition it is not possible for a model to activate itself in the sense of going from a passive state to an active state without the intervention of an external event. Activation and passivation are important roles that external events can play. However, more subtle is the case where the states pertaining before and after the incidence of the event are both active. To discuss this case, we must explicitly represent the time left component of the model state.


D.P.F Möller

3.2 DEVS Formalism A DEVS is in explicit form if the sequential state takes the form of a pair (s, δ) such that ta (s, δ) = δ. Thus the time left component δ is explicitly represented. Let x ∈ X arrive when the model has been in sequential state (s, δ) for elapsed time e and cause the transition to (s´, δ´) where (s´, δ´) = δ ((s, δ), e, x) The event x is said to be ignored if s´ = s and δ´= δ`- e, I.e. the only result has been to update the time left component to account for the passing of elapsed time e; the model remains scheduled to undergo a transition from the same state at the same time that it was before. An event which is not ignored is said to cause an interrupt. Such an event causes a non-trivial state change and/or a rescheduling of the model´s next internal transition.


D.P.F Möller

3.3 DEVS Queue Description A generalized queue: Single server queueing systems form a quite flexible class to develop DEVS models that includes •first come – first served disciplines •job scheduling algorithms such as prioritized preemption and round robin Defining a Job Description Structure (JDS) enable us to stipulate what must be known about the jobs to be processed. Then we define a queueing structure which stipulates the functions required to insert jobs in the queue and to select a job to be processed Finally, we employ these structures to specify a class of DEVS which embodies the dynamics they set up.


D.P.F Möller

3.3 DEVS Queue Description Job Description Structure (JDS) is an object J = < X, id, tl, update > where X is a set, the set of job descriptors Id is a V-function or Value-function, the identifier of a job tl is a V-function, the job´s processing time left update is an O-function or Operation-function, for updating job status subject to the constraints id: X→I+ tl: X→R+0 update: X× R+0 →X such that if update (x, t) = x´then id(x´) = id(x) and tl(x´) = tl(x) – t update (x, t) reduces the processing time left of job x by the elapsed time t; the updating affects only the time left component of the job description Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description A V-function, or Value-function returns a value when applied to an object but does not change its state An O-function, or Operation-function provides a means of performing such a change in state. Finally, a predicate to indicate whether a job is finished its processing is defined as follows done(x) = [ tl(x) = 0 ]


D.P.F Möller

3.3 DEVS Queue Description Queue based on a Job Description Structure J is a structure QU(J) = < S, first, insert, ts > where S is a set, the set of line configurations first is a V-function, selecting the first in line insert is an O-function, for inserting a job ts is a V- function, for determining the time slice subject to the constraints S consists of the set of all finite subsets of X satisfying: the empty set Φ ∈ S if s ∈ S, and x, x´ ∈ s, then x ≅ x´implies id(x) ≅ id(x´)


D.P.F Möller

3.3 DEVS Queue Description A line cannot contain two job descriptions with the same id first: S→X such that first(s) ∈ s for s ≅ Φ Insert: X× S→S such that if insert (s, s´) = s´ then x is_in s´ and y is_in s`/x, if, and only if, y is_in s where

x is_in s ≡[there is an x´ ∈s with id(x´)=id(x) and tl(x´)=tl)x)]

and s´/x = s`- {x´} where id(x´)=id(x) and tl(x´)=tl(x)


D.P.F Möller

3.3 DEVS Queue Description Allowing the inserting operation to change any aspect of a job description its id and time left components FIFO and line configurations based on priority schemes can therefore be accommodated as follows ts: S → R+0 selects a next time slice based upon the current line configuration, includes the case of constant time slice. We define as follows: empty(s) ≡ [s = Φ] Φ

if empty (s)

rest(s)= s/first(s)


otherwise

D.P.F Möller

3.3 DEVS Queue Description Example: Specification of generalized queue J = < X, id, tl, update > Job Description Structure -Æ JDS QU(J) = < S, first, insert, ts > Queue based on JDS J-Æ MQU(J) = < X, S, δΦ, δex, ta > DEVS


D.P.F Möller

3.3 DEVS Queue Description Specification of the DEVS Class of Queues means translation which takes a Job Description Structure and a Queue based on it and produces the DEVS which portrays how such a queue operates. Such a translation could be programmed so as to produce a simulation program which would implement the queueing system specified by the JDS and the Queue parameters. A Queue structure QU(J) based on JDS J specifies a DEVS MQU(J) = < X, S, δφ, δex, ta > where X is the set of job descriptions given by J S is the set line configurations given by QU(J) δΦ: S → S is given by rest(s) δΦ(s)= insert(update.first(s)),rest(s)) where update.first(s)=update(first(s),ta(s)) Modeling and Simulation

if done(update.first(s)) otherwise D.P.F Möller

3.3 DEVS Queue Description The time slice allocated to the job being processed, namely the one first in line, has just ended; if the job has finished then remove from it from the line, otherwise reduce its time left by the time slice it received, namely ta(s), and replace into the line

δex (s,e,x)=

δΦ: Q × X → S is given by insert(x,s)

if empty(s)

insert(x,insert(update(first(s),e),rest(s))) otherwise If a job arrives to a non-empty line then the job currently being processes has its time left updated and then replaced into th line, after which, the incoming job is inserted into the line, if the insert operation realizes a preemption scheme this may result in its becoming the first in line ta: S → → R+0 is given by ∞ if empty(s) ta(s)= minimum{tl(first(s)),ts(s)} otherwise If the line is not empty then allot a processing time to the first job in line of at most the allowed time slice Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Example: Classical FIFO discipline Let us express a queue in which jobs wait in line in order of arrival, and are given the processing time for completion. Let X be a set of triples (i, α,p) such that id (i, α,p) = i, tl (i, α,p) = α and p is a non-negative integer which will indicate the place of the job in line. Thus (i, α,p) represents a job with identifier i, a processing time left α; initially this is the processing time required for completion, and a position p in the line. Let update((i, α,p) ,t) = (i, α-t,p) For QU(J) let ts = ∞ and if {(i1, α1,p1),…, (in, αn,pn)} then first(s)= (imin, αmin,pmin) where pmin = minimum{pi}, and Insert((i, α,p),s) = s U {i, α,pmax +1} where pmax = maximum{pi}, Thus a new arrival is explicitly placed at the end of the line by changing it a higher number than those of the jobs already in line Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Classes of DEVS Models Special forms of discrete event specification are useful in realizing experimental frames in the simulation of DEVS models. Specifically, the concepts of generator, acceptor, and transducer can be readily generated to the DEVS context from their automata theoretic origins, and can be seen as active and passive DEVS. A DEVS is passive if its time advance function is identically infinite. Such a DEVS is not capable of initiating activity on its own since the time to the next internal transition is always infinity. It can however respond to external events by changing its state and producing an output An active DEVS is one which is not passive. Such a DEVS has at least one active state in which it can initiate activity of its own choosing by means of its self scheduling mechanism. A generator is an active DEVS which is input-free. Such a DEVS is capable of scheduling itself for a state transition, producing an output as a function of this state, and rescheduling itself for the next such iteration. The output function is defined in such a way that an output segment produced by such a generator when started in an initial state satifies the constarints of a DEVS segment. Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Classes of DEVS Models Generators may be used to implement arrival processes (in the way that blocks of the same name function in GPSS) among other classes of input segments to models. Formally, a generator is a DEVS G = where the symbols have the meanings standard in the DEVS context. If the output function is given the special constraint λ(s,e) = Φ except when e=ta(s) then the output events will occur only at the internally generated event times. The set of all output segments generated by G called its generated set is given by ΩG = {OTRAJ q| q ∈ Q} Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Classes of DEVS Models An acceptor is an passive DEVS with state set partitioned into two sets, the accepting and the non-accepting states. In addition the acceptor designates a state in which the system is always initialized. An input segment is accepted by such a system, if it causes the acceptor to reach an accepting state at the end of its application. An acceptor is a DEVS A= where X, S and δex have the usual meanings and q0, the initial state

and

F, the set of accepting states are subject to the constraints and

q0 ∈Q

F is a subset of Q, where Q is the total state set Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Classes of DEVS Models It should be noticed that the time advance function need not be included in the specification since it is identically infinite. The set of segments accepted by A is given by ΩA = {ω|δ(q0,ω) ∈ F} In analogy with automata theory, ΩA may be termed the language accepted by M. Ω is said to be accepted by A if Ω = ΩA A transducer is a passive DEVS object with a designated initial state. When started in such a state, the transducer maps its input segments into output segments. A transducer is called a final value transducer, if all output is suppressed until the end of the input segment interval. Transducers may be employed to gather statistics about model trajectories in a manner similar to the ACCUMULATE mechanism in SIMSCRIPT 11.5 or data types. A transducer is a DEVS T= where q0 is the initial state. Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Classes of DEVS Models The final value function computed by T is the mapping fT: Ω → Y defined by fT(ω) = λ(δ(q0,ω)) where Ω is the set of DEVS segments over X and δ is the transition function of the system specified by T.


D.P.F Möller

3.3 DEVS Queue Description Finite Memory DEVS An important mens of constructing DEVS generators, acceptors, or transducers is to save a finite number of past inputs and outputs for use in computing the next output (state). A finite memory system can be used, hence the sequential state set of such a model takes on a special form: if n past inputs and m past outputs are saved then a state is a pair of vectors, one of size n of values of X and the other of size m of values of Y. A finite memory can be specified as follows F= where X a set, the input set Y a set, the output set n is a non-negative integer, the input order m is a non-negative integer, the output order F is a function, the output function, such that f: Xn × Ym → Y Modeling and Simulation

D.P.F Möller

3.3 DEVS Queue Description Finite Memory DEVS A FM DEVS, F translates into a passive DEVS M = < X, S, Y, δex, λ > where

S = Xn × Ym

and is defined by where

δex: Q × X → S δex((x1,…,xn,y1,…,ym)e,x)=(x, x1,…,xn-1,y, y1,…,ym-1)

and


y=f(x1,…,xn,y1,…,ym,e) λ=f

D.P.F Möller

3.4 More about Queueing Systems One of the most well known application areas in modeling and simulation of discrete-event systems are simulations of queuing systems that represent random-based processes. The key element of a queuing system are the customers and the servers. Hence a queuing system can be described by the following attributes: • The calling population, which represents the population of potential customers • The system capacity, which is the limit on the number of customers the discrete-event system can accommodate at any time • The composition of the arrivals, which can occur at scheduled times or at random times • The queuing discipline, which is the behavior of the queue in reaction to its current state • The service mechanism, which means that the service times may be constant or of some random duration


D.P.F Möller

3.4 More about Queueing Systems The attributes represent the elements of discrete-event systems. Elements are necessary to describe real-world systems and can be classified as: • Permanent elements, which are - Queues - Stations - Servers - etc. • Temporary elements, which are - Jobs - etc. • Times, which are - The inter arrival times between two jobs following each other - The service time needed in the server - etc. Modeling and Simulation

D.P.F Möller

3.4 More about Queueing Systems

Let arrivals and services be defined by the distribution of the time between arrivals and the distribution of the service times, respectively. For any simple single- channel telecommunication queue, such as the one of Example 3.3, the overall effective arrival time has to be less than the total service rate, otherwise the waiting line will grow without bound. If queues grow without bound, they are called explosive or unstable. In cases where the arrival time will be for short terms greater than the service rate, there is a need for queuing networks with routing capabilities.


D.P.F Möller

3.4 More about Queueing Systems These elements can be represented through graphical symbols, such as circles for an indication of the waiting line in a queue, or blocks, which represent the servers, etc. By combining elements complex queuing nets can easily be built up visualizing the way a job moves through a net of service stations. Moreover, the symbols of the elements describe the limits of the queuing models by sources and sinks for jobs, and the possibility to branch and to merge the flow of the jobs. The intention of queuing models is to gain information about characteristic quantities that describe the workload of the servers, or the time the jobs need to pass through the discrete-event system. High workload of stations makes the discrete-event system highly efficient for the operator, but increases the waiting time for jobs. Hence modeling and simulation is necessary for the prediction of these values to be able to parameterize the system in an acceptable manner.


D.P.F Möller

3.4 More about Queueing Systems Example 3.3: Consider a simple single-channel telecommunication system with the following elements: a calling population, a waiting line, and a server. Let the calling population be infinite; that is, if a unit leaves the calling population and joins the waiting line or enters service, there is no change in the arrival rate of other units that may need service. Arrivals for service occur one at a time if we use a randomized schedule; once they join the waiting line, they are eventually served. In this simple single-channel telecommunication model service times are assumed to be of some random length according to a probability distribution that does not change over time. Assume that the system capacity has no limit, meaning that any number of units can wait in line. Furthermore, the units should be served in the order of their arrival by a single server, which results in the first-in, first-out (FIFO) service schedule.


D.P.F Möller


Queuing systems can be represented by terms such as stable, event, simulation clock, etc. Hence, the state of the queuing system is represented by its number of units as well as the status of the server, which can be busy or idle. An event then represents a set of circumstances that cause an instantaneous change in the state of the system. In case study Example 3.3 there are only two possible events that can affect the state of the single-channel telecommunication system, the arrival event, which means the entry of a unit into the system, and the departure event, meaning the completion of service on a unit. Furthermore, a simulation clock is used to track simulated time.


D.P.F Möller

3.4 More about Queueing Systems If a unit enters the discrete-event system, the unit can find the server either busy or idle, which results in two cases: 1. The unit begins service immediately if the server is idle. 2. The unit enters the queue for the server immediately if the unit is busy. It is not possible for the server to be idle and the queue to be not empty, which can be interpreted as a third case. The results of which can be expressed in a matrix form for the potential unit actions upon arrival, as shown in Table 3.1.


D.P.F Möller


Queue status

Server status

Not empty

Empty

Busy

2

2

Idle

3

1

Table 3.1. Cases of unit actions upon arrival


D.P.F Möller

3.4 More about Queueing Systems After the completion of a service, as shown in Table 3.1, the server can become idle or remain busy with the next unit. The relationship of these two outcomes to the status of the queue is shown in Table 3.2. If the queue is not empty, another unit can enter the server keeping him busy, or if the queue is empty, the server will be idle after a service is completed, which is indicated by the disjunctive indication of case 1 or 2. Again, it is impossible for the server to become busy if the queue is empty when a service is completed, which is indicated by case 3.


D.P.F Möller


Queue status

Server status

Not empty

Empty

Busy

1 or 2

3

Idle

3

1 or 2

Table 3.2. Server outcomes of Table 3.1 after service completion


D.P.F Möller

3.4 More about Queueing Systems Simulating queuing systems requires the stipulation of an event list for determining what will be next. This event list tracks the future times at which different types of events occur. Hence the simulation system is able to calculate the respective simulation clock time for arrivals and departures. If events occur at random times, the randomness needed can be realized through random numbers. Random numbers are distributed uniformly and independently on the interval [0,1]. Random numbers are uniformly distributed on the set {0, 1, 2, 3, …, 8, 9}. They can be generated with the respective queuing systems simulation packages.


D.P.F Möller

3.4 More about Queueing Systems Example 3.4: For the simple single-channel telecommunication queuing systems in Example 3.1, the inter-arrival times and service times can be generated from the distribution of random variables. Consider having seven customers with the inter-arrival times 0, 2, 6, 4, 3, 1, 2. Based on the inter-arrival times the arrival times of the seven customers at the queuing systems results in 0, 2, 8, 12, 15, 16, 18. Due to these boundaries the first customer arrives at clock time 0, which sets the simulation clock in operation. The second customer arrives two time units later, at the clock time 2, the third customer arrives six time units later, at the clock time 8, etc. The second time values of interest in Example 3.3 are the service times that are generated at random from a distribution of service times. Let the possible service times be one, two, three, and four time units. Hence we are able to mesh the inter-arrival times and the service times, simulating the simple single-channel telecommunication queuing system, which results in the schedule, shown in Table 3.3. . Modeling and Simulation

D.P.F Möller

3.4 More about Queueing Systems Customer no.

Arrival time

Service begins

Service time

Service ends

1

0

0

4

4

2

2

4

3

7

3

8

8

2

10

4

12

12

4

16

5

15

17

3

20

6

16

20

2

22

7

18

22

4

26

Table 3.3. Simulating the single-channel queuing system Modeling and Simulation

D.P.F Möller

3.4 More about Queueing Systems As shown in Table 3.3, the first customer arrives at clock time 0 and service starts immediately, which requires four time units. The second customer arrived at clock time 2, but service could not begin until clock time 4. This occurred because customer 1 did not finish service until clock time 4. The third customer arrives at clock time 8 and is finished at clock time 10, etc. The strategy that serves customers in Example 3.2 is based – again – on the first-in, first-out (FIFO) basis, which keeps track of the clock time at which each event occurs.


D.P.F Möller

3.4 More about Queueing Systems Furthermore, the chronological ordering of events can be determined from Table 3.3, as records of the clock times of each arrival event and of each departure event, depending on the customer number. The chronological ordering of events is needed as a basis concept for the realization of discrete-event simulation systems. Further interesting parameters for discrete-event simulation systems are the: • Workload, which represents the percentage of the simulation time a resource was working • Throughput, which is the number of jobs per time unit that leave the system • Mean waiting time • Mean time in system • Queue length • Mean number of waiting jobs • etc. Modeling and Simulation

D.P.F Möller

3.4 More about Queueing Systems Moreover, knowledge of the layout of the queuing networks is of importance for the use of discrete-event simulation systems. The layout depends on: • Open-queuing systems, which have sources and sinks. The job-pass through the queuing net and leave it when all demands are satisfied. Typical examples of open-queuing systems are production lines, where the jobs are the raw materials that have to be treated by certain operations and leave the system as ready-made products. • Closed-queuing systems, which are identified by a closed loop in which the jobs move through the queuing net. The number of jobs are fixed for the whole simulation time. A typical example of a closed-queuing system is a multi user system with n terminals and a single central processing unit (CPU). The jobs circle between the terminals and the CPU; their number stays constant all over the simulation time.


D.P.F Möller

3.4 More about Queueing Systems Moreover, it has to be decided whether: • • • •

It is possible to leave the queue without being served at all. The number of jobs in the queue is limited. There are priorities for the jobs (static and/or dynamic). It is possible for a job with high priority to interrupt the service for a lowpriority one and to occupy the service station immediately when entering the queue. • etc.


D.P.F Möller

3.4 More about Queueing Systems The way the jobs are processed through the queues is based on specific concepts that show how to organize queues. The most common concepts are: • • • • • • •

First-in, first-out (FIFO) Last-in, last-out (LILO) Shortest job first Round robin Shortest remaining processing time Multi level feed back Service in random number


D.P.F Möller


· · · · · · ·

Simulating queuing systems generally requires the maintenance specifying the dynamic behavior of the discrete-event system, which can be done using simulation tables, designed for the problem being investigated. Hence, the content of the simulation table depends from the observed system and can give answers such as: The average waiting time of a customer is determined by the total time the customers wait in queue, divided by the total numbers of customers. The average time a customer spends in the queuing system is determined by the total time the customers spend in the queuing system, divided by the total numbers of customers. The average service time is determined by the total service time, divided by the total number of customers. The average time between arrivals is determined by the sum of all times between arrivals, divided by the number of arrivals − 1. The probability a customer has to wait in the queue is determined by the number of customers who wait in queue, divided by the total number of customersThe fraction of idle time of the server is determined by the total idle time of the server, divided by the total run time of the simulation. Modeling and Simulation

D.P.F Möller

3.5 More about Discrete Event Systems Even within these alternatives decisions are necessary to specify the dynamic behavior of the system completely. Hence, it has to be determined whether • • • •

it is possible to leave the queue without being served at all the number of jobs in the queue is limited there are priorities for the jobs (static/dynamic) it is possible for a job with high priority to interrupt the service for a lesspriority one and to occupy the service station immediately when entering the queue


D.P.F Möller

3.5 More about Discrete Event Systems To standardize the description of queuing models, Kendall introduced notation for queuing systems, which includes information about the processes such as job arrivals and the distribution of the time that is needed in the server. This standard notation is based on a five-character code

A/ B/ c / N / k

where A represents the interarrival-time distribution, B is the service-time distribution, c is the number of parallel servers – of a station (c ≥1) –, N represents the system capacity and k is the size of the population. The elements of queues and servers are represented in the term “station”. Hence a station can be described, using Kendalls notation, as:

[

]

A / B / c − < strategy > [ pre − emptive] max imal queue − length The short forms for the mostly used distributions of queuing systems are: • G: general (no limitation concerning the distribution) • D: deterministic • M: exponential distribution • etc. Modeling and Simulation

D.P.F Möller

3.5 More about Discrete Event Systems Example 3.5 Kendalls notation can be used as follows: • M/D/1: which represents the simplest example, the FIFO principle. • M/G/2: which represents a so-called pre-emptive systems example, the LCFS princple. • MM/1/∞/∞: which indicates a single-server system with unlimited queue capacity and infinite calling population. Interarrival times and service times are exponentially distributed.


D.P.F Möller

3.5 More about Discrete Event Systems Performance measures for queuing systems are of importance for the validation of discrete-event simulation models, which are too complex to be modeled analytically. A queuing system typically has two stages of behavior, short-term or transient behavior, followed by long-term or steady-state behavior. If a queuing system is started it must operate for a period of time before reaching steady-state conditions. A discrete-event simulation model must run for a sufficiently long period of time to exceed the transient period before measures of steady-state performance can be determined, which results in a specific queuing notation that contains • • • • • • • •

Steady-state probability of having n customers in system Probability of n customers in system at time t Arrival state Effective arrival state Effective rate of one server Server utilization Interarrival time between customers n-1 and n etc. Modeling and Simulation

D.P.F Möller

3.5 More about Discrete Event Systems Based on this notation for the various classes of queuing system models a performance analysis can be introduced based on: • • • • • •

Steady-state parameters for M/M/1 queues Steady-state parameters for M/G/1 queues Steady-state parameters for M/Ek/1 queues Steady-state parameters for M/D/1 queues Steady-state parameters for M/M/1/N queues Steady-state parameters for M/M/c queues

• For the first three queues the service times are exponentially distributed for M, generally distributed for G and Erlangen distributed for E. For the fourth case, D, the service times are constant. For M/M/1/N queues, the system capacity is limited to N, for M/M/C queues the channels c operate in parallel.


D.P.F Möller

3.5 More about Discrete Event Systems While simulation of queuing systems often is done manually, based on simulation tables, one has to decide, comparing the difference between possible analytical and simulative solutions, which of the two methods should be used. This comparison can be restricted, reflecting limitations and advances. • • • • •

Limitations of the analytical solutions are: Preconditions, concerning the distribution of the inter arrival times and time to be served Substantial problems, to handle queuing strategies Numerical efforts, to solve the state equations Results only for the steady state Only mean values, no predictions about the minimum and the maximum or the history of individual jobs

• An advantage of analytical solutions is: • Results, which are general for use of all possible parameterizations


D.P.F Möller

3.5 More about Discrete Event Systems A limitation of simulation-based solutions is: • A single simulation run only corresponds to a single random sample, all simulation results are singular solutions for the given initial state, they are not general results for the whole modes • • • •

Advantages of simulation-based solutions are: No preconditions concerning the distributions Any strategy can be reproduced Observation of the individual history for jobs and queue lengths possible


D.P.F Möller

3.5 More about Discrete Event Systems Another important class of simulation problems of queuing systems involves inventory systems. An inventory system has a periodic review of length at which time the inventory level is observed, and an order that is made to bring the inventory up to a specified level of amount in inventory. At the end of the review period, an order quantity is placed.


D.P.F Möller

3.5 More about Discrete Event Systems Example 3.6 An inventory problem deals with the purchase and sale of newspapers. The paper sellers may buy the papers for 30 cents each and sell them for 50 cents each. Newspapers not sold at the end of the day are sold as scrap for 5 cents each. The problem to be solved with this inventory system is to determine the optimal number of papers the newspaper seller should purchase, which can be done by simulating the demands for a month and recording the profits from sales each day. The profit P can easily be calculated as follows:

 sales   cos t of  −  P =    revenue   papers


  salvage sale    profit loss  +  −   excess demand   scrap papers      

D.P.F Möller

3.5 More about Discrete Event Systems Based on Example 3.6 the primary measure of the effectiveness of inventory systems, which are total system costs, can be extracted. Contributing to total inventory cost are the following: • • • •

Item cost which represents the actual costs of the Q items acquired Order costs which are the costs of initiating a purchase or production setup Holding costs which are the costs for maintaining items in inventory Shortage costs represent the costs of failing to satisfy demand

In general, inventory problems of the type discussed above are often easier to solve then queuing problems.


D.P.F Möller

3.5 More about Discrete Event Systems Furthermore, discrete-event simulation of queuing models is based on simulation languages, which use programming languages. Assuming a model consists of two events: customer arrival and service completion. The events can be modeled with event subroutines, which are ARRIVE and DEPART, respectively. These subroutines include an INCLUDE statement, and can be described with generalized statements as follows SUBROUTINE ARRIVE INCLUDE ´mm1.dc1´ … Schedule next arrival …. IF (SERVER.EQ.BUSY) THEN ….. END


D.P.F Möller

3.5 More about Discrete Event Systems SUBROUTINE DEPART INCLUDE ´mm1.dc1´ … Check whether the queue is empty or not …. IF (NIQ.EQ.0) THEN ….. SERVER = IDLE …. ELSE Queue is not empty NIQ=NIQ+1 …. END


D.P.F Möller

3.6 Principles of Discrete Event Simulation To establish a general framework for discrete event simulation, the major concepts used are: system: a collection of entities that interact over time to accomplish a set of goals or objectives model: a mathematical-logical representation of the system in terms of its entities and their attributes, sets, e´vents, activities, and delays system state: a collection of variables the values of which define the state of the system at a given point in time • entity: an object, item, or component of the system that requires explicit representation in the model attributes: the properties or characteristics of a given entity set: a collection of associated entities event: an instantaneuos occurrence in time that alters the state of the system activity: a duration of time in which one or more entities are engaged in the performance of some function that is germane to the system under study, the length of which is known at the outset delay: a duration of time of unspecified length, the length of which is not usually known until its ends Modeling and Simulation

D.P.F Möller

3.6 Principles of Discrete Event Simulation Illustrating these concepts: system: outpatient clinic in a hospital entities: patients, physicians, nurses, examining rooms attributes: nature of disorder of a patient, time the patient arrives at the clinic, type of insurance coverage available, …entire patients history set: patients waiting for service, ordered by severity of disorder and FIFO within disorder policy activity: examination of a patient ba y doctor, time required to perform an x-ray procedure delay: time the patient spends waiting to see a doctor event: arrival of another patient into the clinic, completion of examination of a patient by a physician, completion of an x-ray by a laboratory technician Scheduling of events is accomplished by a next event approach


D.P.F Möller

3.6 Principles of Discrete Event Simulation next event approach: time is advanced from the time of a current event ti to the time of the next scheduled event tj+1 The calendar of events consists of a file containing the time and type of each n events arranged in chronological order in the memory of the computer. The simulation program must have a mechanism fetching the nest event scheduled to occur, automatically advancing simulation time to the scheduled time of occurrence of that event, and transferring control to the appropriate event program, as shown in the following figure that illustrate the time-advance procedure in next event simulation


D.P.F Möller

3.6 Principles of Discrete Event Simulation next event approach: The method by which events are placed in the event calendar is extremely important. One or more events must be initialized at the outset of the simulation.


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language The DEVS formalism we have been introduced have reached the complexity where they can readily capture much complex real world behavior/systems. Consider the statements of an multicomponent discrete event specification DN = < D, {Si}, {Ii}, {Ti}, SELECT >

to specify D: Declare components: {list of names} to specify S: Declare phases of i: {list of names} Declare variables of I: {list of name:range pairs} to specify I: Declare influencees of i: {component names} Declare influencers of I: {component names} (not applicable for the next event formalism)

to specify SELECT: Tie breaking order is: {list of component names} (this is a commonly employed special form of SELECT) Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language to specify T: {finite list of statements of the following type} assignment statement: variable name:={expression evaluating to range of variable} if….then…..else statement: if {predicate} then statement [else statement] plus the following (depending on the formalism);

Next Event Formalism (re)schedule {component name/this component} in {non negative real} units

[set component´s δ to {non negative real} ] activate {component name} [set component´s δ to 0] passivate {component name/this component} [set component´s δ to ∞]

Activity Scan Formalism wait until({predicate}) (must be first statement in list; exactly one waituntil may occur) plus all of Next Event statements Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Process Formalism {phase name}.waituntil({predicate}) {phase name}.hold({non-negative real}) units

[set your own δ to {non negative real} ] go to {phase name} (re)schedule {component name} [from {phase name}) in {non-negative real} units [set component´s phase to {phase name} and its δ to {non negative} ] activate {component name} [from {phase}) [set component´s phase to {phase name} and its δ to 0] passivate {component name/this component} [in {phase name}) [set component´s phase to {phase name} and its δ to ∞]


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: In case of an assignment statement we say that the component has write access to the variable on the left hand side; it has read access to any variable used in the expression of the right hand side. In the assignment A: = B the component has write access to A and read access to B Similarly a component must have read access to any variable appearing in a predicate of a if….then.…else…. statement


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Coin Tossing Coin Tossing show a random behavior. Once flipped, a coin may fall on the heads or tails face in a seemingly unpredictable manner. There may seem very little one can model about such a system except to assign a probability of its landing heads pHEAD hence also of tails since pTAIL = 1 – pHEAD For a fair coin these probabilities are equal. Actually, coin tossing is a remarkable complex dynamic system for which some 15 models are known. Coin tossing may be decomposed into two processes: • a spin process in which the coin flips from heads to tails • a translation process in which the coin is traveling through the air while spinning • When the coin lands the side of the coin facing up represents the results of the toss. A new toss is initiated from this state. The coin spends a fraction τ in heads (and 1-τ in tails) during one spin revolution. A fair coin has τ = 0.5 by definition.


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Coin Tossing The coin tossing model is a multicomponent system level specified by:

DEVS at the structured

Declare components: {spin process, translation process, toss} Declare phases of toss: {WAIT} Declare phases of spin process: {HEADS, TAILS} Declare phases of translation process: {START, STOP} Declare influencees of toss: {spin process, translation process} Declare influencees of toss: {translation process} Declare influencees of spin process: none Declare influencees of translation process: {spin process}


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Coin Tossing The transition function of each component, specified in process formalism, is declared as follows: spin process HEADS. hold(τ) TAILS. Hold(1- τ) go to HEADS translation process START. hold(travel_time) passivate spin proces STOP. Passivate toss process WAIT. waituntil(translation process phase=STOP) activate spin process activate translation process go to WAIT Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Subway Train A subway train consists of a lead car (responsible for pulling the train) passenger cars, and a rear car (the last passenger car). Except for the lead car,each car is specified by three processes: •Control •Loading •Unloading Subway train

Lead car Controller Process

Controller Process Modeling and Simulation

Passenger Cars

Rear Car

Passenger Car

Loading Process

Unloading Process D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Subway Train Declare components: D = {0} )lead car), 1,…,n-1 (passenger cars) n (rear car) Declare phases of lead car: {STOPPED, MOVING} Declare variables of lead car: arrived: boolean Declare phases of all other cars: the crossproduct of phase sets:

{STOPPED, MOVING} (control process) {MOVING, WORKING} (unloading process) {MOVING, WORKING} (loading process)


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Subway Train Declare variables of all other cars: arrived, ready: boolean (control process) front_door: range {open, closed} (loading process) back_door:back_door: {open, closed} (unloading process) except the rear car does not use arrived

Declare influencers of lead car: I0 = {1} the influencer of the lead car´s condition is the car behind; it has no influences other than itself

Declare influencers of cars: In = {n-i, n} the influencers of a passenger car are the cars behind and ahead ass well as itself, via unloading and loading process; it has no influencees other than itself


D.P.F Möller

3.7 Discrete Event Simulation Languages User Oriented DEVS Language Example: Subway Train Ti is described in process for as follows lead car control process

STOPPED. , MOVING.

waituntil(car_behind.ready) arrived:=false Hold(travel_time) arrived:=true go to STOPPED

passenger car control process

MOVING.

STOPPED.

waituntil(car_behind.arrived) arrived:=true ready:=false front_door:=back_door:open waituntil(front_door and back_door=closed) ready:=true go to MOVING


D.P.F Möller

3.7 Discrete Event Simulation Languages rear car control process

MOVING. STOPPED.

waituntil(car_ahead.arrived) ready:=false front_door:=back_door:open waituntil(front_door and back_door=closed) ready:=true go to MOVING

unloading process

MOVING. WORKING.

waituntil(back_door=open) hold(unloading_time) back_door:=closed go to MOVING

loading process

MOVING. WORKING.

waituntil(front_door=open) hold(loading_time) frnt_door:=closed go to MOVING


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Discrete-time systems simulation languages can be separated into general-purpose and special or application-purpose simulation languages. Their structure is similar to the continuous ones, but they contain an eventbased control of time that allows classification of discrete-system simulation software as follows: Transaction oriented simulation software; are based on a time-step control, deter-mined through preprogrammed logical conditions related to the respective blocks. Language elements of transaction-oriented simulation systems are transactions, blocks, facilities, queues, pools and storages, logical switches, numerical and logical variables, functions, and ta-bles. Event-oriented simulation software; are based on time-depen-dent and restricted event-handling language elements. Activity-oriented simulation software; are based on activity schedules that are started if specific constraints are fulfilled. Process-oriented simulation software; are based on the activation trigger of the following events as specified language elements. Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages The development of discrete-system simulation software results in several systems, which are the • Universal or special-purpose discrete system simulation languages, such as ARENA, GASP, GPSS, MODSIM, SIM-SCRIPT, SIMAN, SLAM-SYSTEM, based on general-purpose programming languages • Application-oriented discrete-system simulation languages, such as NETWORK, SIMFACTORY, SIMPLE++, SIMULAP, XCELL, etc., based on programming languages for special-application domains The universal or general-purpose discrete system simulation languages are applicable in a wide range of applications, but, for example, the user has to have specific programming experience, such as TESS (the extended SLAM system), and SIMAN (simulation analysis language).


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Application-based simulation languages are primarily more specific due to their application-domain dependent design that results in a better efficiency. But in contrast, their flexibility and their restriction to a specific application domain are less acceptable, from the general-purpose point of view. New software releases show two specific approaches: • Parameterized, application-oriented languiages, that are expanded by a user simulation system, like SIMFACTORY II.5 Rel.6, or an interface for a higher programming language is embedded, as in SIMAN V. Hence, the user can develop and implement his own control strategies, or his specific model components, which may be combined with the standard elements. Object-oriented simulation systems, based on specified basic components, which allow an object-oriented design of the application-specific components, such as the OS/2 metafiles for graphics in SLAMSYSTEM.


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages A typical representative of a special-purpose simulation programming language based on the process interaction-approach and oriented towards queueing systems is GPSS (general purpose simulation system). GPSS is a highly structured simulation software based on standard blocks, which represent events, delays, and other actions that affect the transaction flow. Hence, GPSS can be used to model situations where transactions, such as entities, customers, units of traffic, etc., are flowing through a system, which can be a network of queues, with the queues preceding scare resources. The GPSS block diagram is converted to block statements, and control statements are added, which results in a GPSS model. Furthermore, GPSS contains specific subroutines for coordinating the transactions: • Coordination of transactions within one step • Coordination of transactions within parallel steps • Coordination of time-equal transactions


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Its successor, GPSS/H, provides improvements of the fundamental concepts of an earlier version of GPSS, such as transaction flow view, facilities, queues, and storages. Its latest version includes • Ampervariables that allow arithmetic combinations of values used in the simulation • Animation • Arithmetic expressions as block operands • Built-in files • Built-in mathematical functions • Built-in random variate generators • Expanded control statements • Faster execution • Floating-point clock • Interactive debugging • etc.


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages The animator for GPSS/H is proof animation, which provides a 2D animation, based on a scale drawing that can run in post-processed mode or concurrently. Example 4.17 The kernel of a single-server queue-simulation program in GPSS/H contains the GENERATE statement which represents the arrival event, with the interarrival times given by the statements RVEXPO(1,&IAT). RVEXPO stands for random variable, exponentially distributed, while 1 indicates the random number to use, and &IAT indicates that the mean time for the exponential distribution comes from an ampervariable, indicated by the & character. The next statement is a QUEUE, named SYSTIME. The QUEUE statement works in conjunction with the DEPART statement to collect data on queues – r any other subsystem.


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Another successor to GPSS/H, SLX, replaces many of the features of GPSS/H entirely and represents many of them with simpler, more general constructs, because SLX is a layered modeling system in which GPSS/H comprises only one of the five layers, which are as follows: • Layer 0: C based kernel that supports a number of primitives required for simulation • Layer 1: simulation and statistical primitives, consisting of data structures, subroutines, operators, and macros, written in SLX • Layer 2: general GPSS/H features • Layer 3: application-domain-specific packages • Layer 4: special packages such as highly interactive front ends •


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages SIMSCRIPT, a representative of another universal discrete simulation system that allows users to built models either process-oriented or eventoriented. SIMSCRIPT can be used to produce dynamic and static presentation graphics. Animation of the simulation output is realized using the SIMGRAPHICS software to produce interactive graphic front ends or forms for entering model input data.


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 implementation of the grocery checkout model declares a customer process, a customer generator process, and a server resource. The CUSTOMER.GENERATOR creates new CUSTOMER processes then activates them. The CUSTOMER process requires a server from the SERVER resource object and waits in a queue if the server is busy. The queue and its statistics gathering capability are an integral part of SIMSCRIPT II.5 built-in resources. When a server resource becomes available, the CUSTOMER process waits while being served then leaves the system. There is also is also code to initialize the program and create the participating processes, gather statistics, and report the results


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 output report for single-server queue simulation SIMSCRIPT II.5 checkout model starting… Mean interarrival time 4.50 Mean service time 3.20 Standard deviation of service time 0.60 Number of customers to service 1000.00 Server utilization 0.71 Maximum line length 5.00 Average line length 6.47 minutes Proportion who spent four minutes or more in system 0.68 Simulation run length 4500.48 minutes Number of customers 1000.00


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 programs start with a preamble that describes the components of the model. These are the processes, resources, variables and statistics gathering variables. The preamble serves a double purpose. Declaring all of the components of the program causes the SIMSCRIPT II.5 compiler to check each component mentioned in the preamble for consistent and correct usage in the program code. Even more important is that the preamble lists all of the components of the model for examination by the reader or program maintainer before going through the reminder of the program. By convention, SIMSCRIPT II.5 programs are written with system keywords in lower or mixed case and user declared variables in upper sizes. The preamble include the following code: Preamble Processes include CUSTOMER, CUSTOMER.GENERATOR Every CUSTOMER.GENERATOR has a CUST.MAEAN.IAT Define CUST.MEAN.IAT as a real variable Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: Note that, once the two processes are declared, the preamble adds an attribute CUST.MEAN.IAT, to the CUSTMER.GENERATOR process and defines is as a real variable. Resources are built-in capability in SIMSCRIPT II.5, so it is only necessary to declare them, i.e. resources include SERVER causes the grocery store checkout clerk called server to become part of the model. After the processes and resources are declared in the preamble, the program variables are also declared. Next are the keywords Tally and Accumulate as shown in the following: Define TIME.IN.SYSTEM, FOUR.OR.MORE as real variables Define CUSTOMERS.SERVED as an integer variable Tally MEAN.TIME.IN.SYSTEM as the average of TIME.IN.System


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: The Tally keyword specifies that TIME.IN.SYSTEM will be monitored. Whenever an assignment is made to the variable TIME.IN.SYSTEM, statistics will automatically be gathered. The particular statistic that will be kept in this case is the average of all assignments to this variable. The average will be called MEAN.TIME.IN.SYSTEM. The next declaration uses the Tally keyword to attach another monitor which will keep track of the max number of processes waiting in the SERVER resource´s queue for service. N:Q:SERVER is one of several attributes of the SERVER that is automatically generated and managed by the system to keep track of the SERVER processes in the SERVER resource´s service QUEUE. MAX.QUEUE will contain the highest value reached by N.Q.SERVER and, therefore, the highest number ever waiting in the queue for service. This is followed by an Accumulate statement Accumulate UTILIZATION as the average of N.X.SERVER


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: The Accumulate keyword is the same as the Tally keyword except that it weights its average with respect to the simulation time which has elapsed. In this case we will monitor the N.X.SERVER attribute of the server resource, which specifies the number of processes currently using a resource. N.X.SERVER is another attribute which has been automatically generated by the system to keep track of resource utilization statistics. By weighting this average with respect to time, the utilization rate of the server resource can be determined. The program starts executing in the Main section where program variables are initialized, processes created and activated and the simulation is started as follows: Main Write as ``SIMSCRIPT II.5 checkout model starting …``,/ Let NUMBER.OF.CUSTOMERS = 1000 Let MEAN.INTER.ARRIVAL.TIME = 4.6 Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: After one resource called SERVER is created it is initialized to have one unit of resource. One customer generator process is the created, its mean interarrival attribute is set and it is activated by the following: Create a CUSTOMER.GENERATOR Let CUST.MEAN.IAT(CUSTOMER.GENERATOR)= MEAN.INTER.ASRRIVAL.ME Activate this CUSTOMER.GENERATOR now Then the simulation is started. Once the simulation has run its course and finished, the report generator is called and the program terminates at the END statement.


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: The customer process code below illustrates how readable SIMSCRIPT II.5 code helps the reader to understand the model:

PROCESS CUSTMER Define Arrival.TIME as a real variable Let ARRIVAL.TIME = TIME.V Request 1 SERVER(1) Work normal.f(MEAN.SERVICE.TIME, SERVICE.STD.DEV,2) minutes Relinquish 1 SERVER(1) Let TIME.IN.SYSTEM = TIME.V – ARRIVAL.TIME IF TIME.IN.SYSTEM not less than 4.0 Add 1 to FOUR.OR.MORE Endif First, a local variable called ARRIVAL.TIME is declared and used to note the current simulation time which is taken from the system variable called TIME.V. The customer process then request one unit of SERVER resource. If one unit of resource is not available, the customer process blocks and waits for an indefinite time until the resource becomes available. It then continues to the Work statement where it passes simulation time while using the resource. Once finished with the resource, the customer process relinquishes it, computes statistics and terminates Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: The following customer generator code is very typical for asimcript II.5 model: Process CUSTOMER.GENERATOR While CUSTOMERS.SERVED less that NUMVER.OF.CUSTOMERS Do Wait exponential.f(CUST.MEAN.IAT(CUSTOMER.GENERATOR), 1) minutes Create a CUSTOMER Add 1 to CUSTOMERS.SERVED ACTIVATE this CUSTOMER now Loop End It samples interarrival times from the exponential distribution and waits for that time before generating each customer process and activating it. This yields arrivals which are characterized by a Poisson arrival pattern


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: The report shown below illustrates SIMSCRIPT II.5´s facilities for generating reports: Routine REPORT.RESULTS Print 4 lines with MEAN.INTER.ARRIVAL.TIME, MEAN.SERVICE.TIME, SERVICE.STD.DEV, NUMBER.OF.CUSTOMERS thus Mean interarrival time **.** Mean service time **.** Standard derivation of service time **.** Number of customers to serve ***** Essentially the programmer types a report and allows SIMSCRIPT II.5 to fill the blanks as specified in the Print----with statement


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue Preamble Processes include CUSTOMER, CUSTOMER.GENERATOR Every CUSTOMER.GENERATOR ha a CUST.MEAN.IAT Define CUST.MEAN.IAT as real variable Resources include SERVER D Define NUMVER OF CUSTOMERS, MEAN.INTER.ARRIVAL.TIME, MEAN.SERVICE.TIME, SERVICE.STD.DEV. as real variable Define TIME.IN.SYSTEM, FOUR.OR.HOME as real variabls Define CUSTOMERS.SERVED as an integer variable Tally MEAN.TIME.IN.SYSTEM as the average of TIME.IN.SYSTEM Tally MAX.QUEUE as the max of N.Q.SERVER Accumulate UTILIZATION as the average of N.X.SERVER Define minutes to mean time End Modeling and Simulation

D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue Main Write as SIMSCRIPT II.5 checkout model starting…./ Let NUMBER.OF.CUSTOMERS = 1000 Let MEAN.INTER.ARRIVAL.TINME = 4.5 Let MEAN.SERVICE.TIME = 3.2 Let SERVICE.STD.DEV. = 0.6 Create every SERVER(1) Let U.SERVER(1) = 1 Create a CUSTOMER.GENERATOR Let CUST.MEAN.IST(CUSTOMER.GENERATOR) = MEAN.INTER.ARRIVAL.TIME Activate the CUSTOMER.GENERATOR now Start Simulation Call REPORT.RESULTS End


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue P PROCESS CUSTOMER Define ARRIVAL.TIME as a real variable Let ARRIVAL.TIME = TIME.V Request 1 SERVER(1) Work normal.f(MEAN.SERVICE.TIME, SERVICE.STD,DEV,2) Minutes Relinquish 1 SERVER(1) Let TIME.IN.SÝSTEM = TIME.V – ARRIVAL TIME If TIME.IN.SYSTEM not less than 4.0 Add 1 TO FOUR.OR.MORE End if End


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue P PROCESS CUSTOMER GENERATOR While CUSTOMERS.SERVED less that NUMBER.OF.CUSTOMERS Do WAIT exponential.f(CUST.MEAN.IAT(CUSTOMER.GENERATOR) ,1) minutes Create a CUSTOMER Add 1 to CUSTOMERS.SERVED Activate this CUSTOMER now Loop End


D.P.F Möller

3.7 Discrete Event Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue ROUTINE REPORT RESULTS Print 4 lines with MEAN.INTER.ARRIVAL.TIME, MEAN.SERVICE.TIME, SERVICE.STD.DEV, NUMBER.OF.CUSTOMERS thus Mean interarrival time **.** Mean service time **.** Standard derivation of service time **.** Print 7 lines with UTILIZATION(1), MAX.QUEUE(1), MEAN.TIME,IN.SYSTEM (FOUR.OR.MORE/NUMBER.OF.CUSTOMERS), TIME:V, CUSTOMERS,SERVED) thus Server Utilization **.** Maximum line length ***** Average response time **.** minutes Proportion who spent four minutes or more in system *.** Simulation run length ******.** minutes Number of customers ***** Modeling and Simulation D.P.F Möller End

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages Example: SIMSCRIPT II.5 program for single-server queue P PROCESS CUSTOMER GENERATOR While CUSTOMERS.SERVED less that NUMBER.OF.CUSTOMERS Do WAIT exponential.f(CUST.MEAN.IAT(CUSTOMER.GENERATOR) ,1) minutes Create a CUSTOMER Add 1 to CUSTOMERS.SERVED Activate this CUSTOMER now Loop End


D.P.F Möller

3.7 Discrete Event Simulation Languages General-Purpose Simulation Languages A typical representative of the class of application-oriented discrete simulation software is SIMAN V, which incorporates the ARENA environment that includes • • • •

Menu-driven point- and click procedures for modeling Animation of the model Input processor which assists in fitting distributions to data Output processor, which can be used to obtain confidence intervals, histograms, etc.

•


D.P.F Möller

3.8 Statistical Models in Simulation In simulation the modeler sees a probabilistic world. The time it takes a machine to fail is a random variable, as is the time it takes a maintenance mechanic to repair it. Modeling requires skill in recognizing the random behavior of the various phenomena that must be incorporated into the model, analyzing data to determine the nature of these random processes, and providing appropriate mechanisms in the model to mimic these random processes. Random Variables Let X be a variable that can assume any of several possible values over a range of such possible values. Assuming X is a variable in which the range of possible values is finite or countably infinite, the probability mass function of X is

p ( xi ) = P( X ) = xi p ( xi ) ≥ 0

∑ p( x ) = 1 . 1

i


D.P.F Möller

3.8 Statistical Models in Simulation Continuous Random Variable Assuming X is a variable in which the range of possible values is the set or real numbers, the probability mass function of X is b

P (a ≤ X ≤ b) = ∫ f ( x)dx a

f (x) ≥ 0 for all x in ℜ

∫ f (x) =1 .

ℜx


D.P.F Möller

3.8 Statistical Models in Simulation Expectation Let E(X) be the expected value of the random variable X. The expectation function is given by

E ( X ) = ∑ xi p( xi ) i

if X is discrete, and by

E( X ) =

∞

∫ xf ( x)dx

−∞

X is discrete. The expected value is also called the mean, denoted by µ. Defining the n-th moment of X results in the variance of the random variable X

[

] [

V ( X ) = E ( X − E ( X )) = E ( X − µ )


2

2

] D.P.F Möller

3.8 Statistical Models in Simulation Discrete Distributions Random variables can be based on continuous distributions or discrete distributions that are used to describe random phenomena. For continuous distributions one can use the · · · · · ·

Erlanger distribution Exponential distribution Gamma distribution Normal distribution Uniform distribution Weibull distribution For continuous distributions one can use the

· · · · •

Bernoulli distribution Binomial distribution Geometric distribution Poisson distribution Modeling and Simulation

D.P.F Möller

3.8 Statistical Models in Simulation Discrete Distributions Example 3.1 Assuming the number X of defective assemblies in the sample n of manufactured assemblies is binomially distributed. Let n = 30 and the probability of defective assembly p = 0.02 results in

 30  x 30 − x = P( X ≤ 2) = ∑  (0.02) (0.98) x =0  x  0.5455 + 0.3340 + 0.0988 = 0.9783 2

The mean number of defectives in the sample is

E ( X ) = n ⋅ p = 30 ⋅ 0.02 = 0.6 The variance of defectives in the sample is

V ( X ) = n ⋅ p ⋅ q = 30 ⋅ 0.02 ⋅ 0.98 = 0.588


D.P.F Möller

3.8 Statistical Models in Simulation Discrete Distributions Example 3.2 Assuming a class of vacuum pumps has a time to failure that follows the Weibull distribution, with α = 200 h, β = 0.333, and ν = 0. The mean time to failure yields for the mean Weibull distribution

1  E ( X ) = v + αΓ + 1 = 200Γ(3 + 1) = 200(3!) = 1200 h ß 

and for the variance Weibull distribution

2

   1 2  2 V ( X ) = α Γ + 1 − Γ + 1  ß    ß  The probability that a vacuum pump fails before 200 h can be calculated based on the cumulative distribution function of the Weibull distribution as follows

F ( x) = 1 − e

 x −ν −  α


  

β

= 1− e

 2000  −   200 

0.333

= 1 − e − 2.15 = 0.884 D.P.F Möller

3.8 Statistical Models in Simulation Uniform Distribution A random variable X is uniformly distributed in the interval [a, b] if ist probability density function (PDF) is given by

 1 ;a ≤ x ≤ b f ( x) =  b − a  0; otherwise The cumulative distribution function (CDF) is given by

 0; xb  The mean and the variance of the uniform distribution are E(X)=(a+b)/2 and V(X)=(b-a)²/12 Modeling and Simulation

D.P.F Möller

3.8 Statistical Models in Simulation

PDF Modeling and Simulation

and

CDF D.P.F Möller

3.8 Statistical Models in Simulation Exponential Distribution The random variable X is said to be exponentially distributed with parameter λ > 0 if its probability density function (PDF) is given by •

f(x) = λ⋅e-λ⋅x ; x ≥ 0

The exponential distribution is used to model interarrival times in random processes in which the rate of arrivals is Poisson distributed. In this case λ is the mean rate of arrivals and 1/ λ is the mean time between arrivals. The mean and variance of the exponential distribution are E(X) = 1/λ and

V(X) = 1/ λ2

The cumulative distribution function (CDF) is given by F(X) = 1 - e-λ⋅x ; x ≥ 0 Modeling and Simulation

D.P.F Möller


Exponential PDF


and

CDF

D.P.F Möller

3.8 Statistical Models in Simulation Gamma Distribution A function used in defining the gamma distribution is the gamma function, which is defined for all ß > 0 as

Γ( ß) =

∫

∞

0

x ß −1 ⋅ e − x dx

Integrating by parts we obtain Γ(β) = (β-1)Γ(β-1) If ß is an integer, then Γ(1)=1 and Γ(β) = (β-1)! The random variable X has a gamma distribution with parameters ß and Θ if its probability density function (PDF) is given by

ßΘ ( ßΘx ) ß −1 e− ßΘx ; f ( x) = Γ( ß )

x>0

The parameter ß is called the shape parameter, and Θ is called the scale parameter. Modeling and Simulation

D.P.F Möller


Several gamma distributions for Θ = 1 and various values of ß Modeling and Simulation

D.P.F Möller

3.8 Statistical Models in Simulation Gamma Distribution When ß = 1 the gamma function will have a n exponential distribution. The mean and the variance of the gamma distribution are given by E(X)=1/Θ V(X) =1/(ß Θ²) The cumulative distribution function (CDF) is given by ∞

ßΘ ß −1 − ßΘx ( ßΘx ) e dx F(X ) =1− ∫ Γ( ß ) x


D.P.F Möller

3.8 Statistical Models in Simulation Normal Distribution A random variable X with mean µ and variance σ² has a normal distribution if its probability density function (PDF) is given by

f ( x) =

1 e σ 2π

[( x − µ ) / σ 2 ] − 2

;−∞ < x < ∞

Normal distribution Modeling and Simulation

D.P.F Möller


Normal Distribution The cumulative distribution function (CDF) for the normal distribution N(µ, σ²) is given by [( x − µ ) / σ 2 ] x − 1 F(X ) = ∫ e − ∞ σ 2π

2

The evaluation of this CDF for given values for µ and σ² is extremely difficult, so that the preferred procedure is to employ the transformation z=(x- µ)/σ. The random variable Z has the so-called standard normal distribution N(0,1), with probability density function Φ(z).

Standard normal distribution


D.P.F Möller

3.8 Statistical Models in Simulation Example Consider the case in which project completion time for a construction follows a normal distribution with a mean µ = 50 days and a variance σ² = 9 days². Let us determine the probability that a given project will require longer than 56 days, or P(X > 56). Clearly, P(X > 56) = 1 - P(X ≤ 56). Using the transformation to the standard normal distribution, z = (56 - 50)/3 = 2.0 so that

P(Z ≤ 2.0) = 0.977

Therefore, P(Z > 2.0) = P(X > 56) = 0.23


D.P.F Möller


Transformation to the standard normal distribution Modeling and Simulation

D.P.F Möller

3.8 Statistical Models in Simulation Weibull transformation for v=0 and α=1


D.P.F Möller

3.8 Statistical Models in Simulation Poisson Processes Arrival processes in which the number of occurences of an event per unit time is a Poisson-distributed random variable are Poisson processes if they conform to the following definition. Let a counting function {N(t), t≥0} represent the number of occurrences of an event in [0, t]. Thus N(t) is a discrete random variable with possible values 0, 1, 2, ... The counting process {N(t), t≥0} is said to be a Poisson process with mean rate λt if the following assumptions will met: 1. Arrivals occur one at a time 2. {N(t), t≥0} has stationary increments, which means that the numbe of arrivals between t and t+s depends only on the length of the interval s, not on the starting point t 3.{N(t), t≥0} has independent increments, which means that the number of arrivals in non overlapping intervals are independent random variables If arrivals occcur according to a Poisson process, the probability N(t) = n is given by the expression e − λt (λt ) n P[N (t ) = n] =


n!

; for t ≥ 0

and

n = 0,1,2,...

D.P.F Möller

3.9 Empirical Distributions Empirical Distribution Sometimes it is possible to match a distribution of data to a known distribution. In such instances we resort to fitting an empirical distribution to the sample distribution. Suppose that the lot sizes in production orders followed the distribution shown in the following table Lot size Relative Cumulative relatice per order Frequency frequency frequency ---------------------------------------------------------------------------------------------------------------------------1 30 0.10 0.10 2 110 0.37 0.47 3 45 0.15 0.62 4 71 0.24 0.86 5 12 0.04 0.90 6 13 0.04 0.94 7 7 0.02 0.96 8 12 0.04 1.00 Plotting the histogram of the sample distribution shwoing the relative distribution, usually called the probability mass function when dealing with discrete random variable Modeling and Simulation

D.P.F Möller

3.9 Empirical Distributions

Histogram for a sample distribution showing a relative distribution, usually called the probability mass function when dealing with with discrete random variable Modeling and Simulation

D.P.F Möller

3.9 Empirical Distributions

Empirical cumulative distribution function (CDF) for a sample of 100 observations of the time to repair an overhead trolley conveyor, based on the assumption of continuous random variables Modeling and Simulation

D.P.F Möller

3.10 Queueing Model One of the most important types of random processes involved in simulation studies is the queueing system, which is composed of a calling population of potential customers, a waiting line for customers, and a service process.

Single-channel queueing system Let potential customers b a group of machines in a factory. As a machine fails, it becomes a customer for the repair service. If the repair mechanics is busy servicing another failed machine, the newly failed machine join a queue, After a machine has been repaired, it rejoins the calling population of operating machines Modeling and Simulation

D.P.F Möller

3.10 Queueing Model • • • • • • • • • • • • • •

The key elements of queuing systems are the customers and the servers The term customer can refer to people, parts, machines aircraft computer jobs etc. The term server can refer to bank tellers machine operators maintenance mechanics air traffic controllers computer operators etc. The arrival process describes the manner in which customer seek service The departure process describes the manner in which customers leave the service system Modeling and Simulation

D.P.F Möller

3.10 Queueing Model • The calling population, represents the population of potential customers, it may be finite or countable infinite. The arrival rate into the queueing system depends on the size of the calling population • The system capacity, which is the limit on the number of customers the discrete-event system can accommodate at any time • The arrival process, which means that arrivals may occur at scheduled times or at random times, the latter usually by an assumed probability distribution. The Poisson distribution is the most common • The queuing discipline, which is the behavior of the queue in reaction to its current state ot the manner in which the service facility organizes the queue • The service mechanism, which means that service times may be constant or of some random duration. The exponential, Weibull, gamma, and normal distribution are commonly used in scheduling services. Service can be in single or multiple channels


D.P.F Möller

3.10 Queueing Model • • • • •

A standard notation for queueing systems is one involving a five-charcter code A/B/C/N/k, where A represents the interarrival-time distribution B is the service-time distribution c is the number of parallel servers – of a station (c ≥1) – N represents the system capacity k is the size of the population For example M/M/1/∞/∞ indicates a single-server system with unlimited queue capacity and infinite calling population. Interarrival times and service times are exponentially distributed. This system is typivally abbreviated M/M/1, the absence ot the last two charcters indicating default to values of infinity.


D.P.F Möller

3.10 Queueing Model Performance Measure for Queueing Systems Queueing systems typically exhibits to two stages • short-term or transient behavior • long-term or steady state behavior Long-run measure of queuing system performance Server utilization: fraction of available time that the server is busy Customers in system: steady state time-average number of customers in the system Customers in queue: steady-state time average number of customers in the queue Time in system: average time a customer spends in the system, including time in queue and time in service Time in queue: average time a customer spends in the queue waiting for service Probability of n customers in system: steady-state probability that there are n customers in the system Modeling and Simulation

D.P.F Möller

3.10 Queueing Model Performance Measures for Single-server queueing system M/M/1


D.P.F Möller

3.10 Queueing Model Steady-State parameters for M/M/1 Queues L: Long-run time-average number of customers in queue λ ρ = µ − λ 1− ρ LQ: Long-run time-average number of customers in queue λ2 ρ2 = µ (µ − λ ) 1 − ρ w: Long-run average time spent in system per customer 1 1 = µ − λ µ (1 − ρ )

wQ: Long-run average time spent in queue per customer λ ρ = µ ( µ − λ ) µ (1 − ρ )

Pn: Steady state probability of having n customers in system 2

µ: Service rate of one server λ: Arrival rate ρ: Server utilization Modeling and Simulation

 λ  λ  1 −   = (1 − ρ ) ρ 2  µ  µ 

D.P.F Möller

3.10 Queueing Model Performance Measures for M/M/c Queueing System

Suppose that c channels operate in parallel. The traffic intensity p cannot exceed the number of channels, so that λ

Mathematical Modeling and Simulation - yimg.com

Mathematical and Computational Modeling in Complex Biological ...

A Computational Modeling and Simulation ... - Semantic Scholar

Computational Materials: Modeling and Simulation of ... - CiteSeerX

A Computational Modeling and Simulation ... - Semantic Scholar

simulation and modeling in computational chemistry

Mathematical modeling, simulation and analysis ... - Academic Journals

MATHEMATICAL MODELING AND NUMERICAL SIMULATION OF ...

Mathematical Modeling and Simulation of Drying

COMPUTATIONAL MODELING AND SIMULATION OF LOW ...

Cyber Defense: Mathematical Modeling and Simulation - International ...

Mathematical Modeling, Numerical Simulation and Statistical ...

Mathematical Modeling and Simulation of ... - Semantic Scholar

Cyber Defense: Mathematical Modeling and Simulation - ijapm

mathematical modeling, analysis and simulation of

Mathematical Modeling and Simulation of Anaerobic ... - CyberLeninka

Mathematical Modeling and Computer Simulation of ... - CiteSeerX

Mathematical Modeling and Simulation of Reactive ...

Mathematical Modelling and Simulation

Mathematical and computational modeling in biology at multiple scales

Mathematical and Computational Modelling of

mathematical and computational knowledge to

MATHEMATICAL MODELING AND TEACHERS

computational and microhydrodynamic modeling and

Mathematical and Computational Modeling and Simulation

Mathematical and Computational Modeling and Simulation

Suggest Documents