ARENA模拟：构建与分析复杂系统的关键工具

需积分: 12 177 浏览量更新于2024-07-23 收藏 19.54MB PDF 举报

"《ARENA仿真建模与分析》是一本深入探讨蒙特卡洛模拟方法在复杂系统建模与分析中的应用的专业书籍。该书强调了在现实生活中，由于实际问题的复杂性以及难以找到解析解或数值计算解决方案，许多系统的研究几乎不可能通过传统的分析模型来完成。相反，通过模拟模型，我们可以构建出几乎适用于所有领域的系统历史，如制造业（半导体、制药等）、供应链管理（生产库存系统、分销网络）、交通运输（高速公路、机场、铁路和港口）以及计算机信息系统（客户端/服务器系统、电信网络）等，来获取关于系统运行和性能指标的有用统计信息。仿真技术不仅有助于分析师理解在特定条件或参数设置下系统的性能表现，而且在优化研究中发挥着关键作用。它常被用于解决离线设计问题中的最佳参数选择，通过迭代过程寻找最理想或可接受的参数值。如今，仿真技术的应用范围已经非常广泛，几乎涵盖所有涉及系统动态行为分析和决策优化的场景。 ARENA是一款强大的仿真软件，它提供了一套完整的工具集，使得用户能够创建各种类型模型，包括随机事件驱动、流程图、网络模型等，以模拟系统的交互行为。它支持数据导入、参数调整、性能度量和结果可视化，使得模拟结果更具可信度和实际指导意义。此外，本书还可能包含如何设置边界条件、定义变量、设定随机事件的概率分布，以及如何解读和解释模拟结果等内容。《Simulation Modeling and Analysis with ARENA》不仅介绍了理论基础，还提供了实操指南，帮助读者掌握如何利用ARENA进行有效的系统建模和性能评估，从而在工程设计、运营管理、战略决策等领域做出更精确和有依据的决策。"

Chapter 2

Discrete Event Simulation

The majority of modern computer simulation tools (simulators) implement a para-

digm, called discrete-event simulation (DES). This paradigm is so general and powerful

that it provides an implementation framework for most simulation languages, regardless

of the user worldview supported by them. Because this paradigm is so pervasive, we

will review and explain in this chapter its working in some detail.

2.1 ELEMENTS OF DISCRETE EVENT SIMULATION

In the DES paradigm, the simulation model possesses a state S (possibly vector-

valued) at any point in time. A system state is a set of data that captures the salient

variables of the system and allows us to describe system evolution over time. In a

computer simulation program, the state is stored in one or more program variables that

represent various data structures (e.g., the number of customers in a queue, or their exact

sequence in the queue). Thus, the state can be defined in various ways, depending on

particular modeling needs, and the requisite level of detail is incorporated into the

model. As an example, consider a machine, fed by a raw-material storage of jobs.

A “coarse” state of the system is the number jobs in the storage; note, however, that this

state definition does not permit the computation of waiting times, because the identity of

individual jobs is not maintained. On the other hand, the more “refined” state consisting

of customer identities in a queue and associated data (such as customer arrival times)

does permit the computation of waiting times. In practice, the state definition of a

system should be determined based on its modeling needs, particularly the statistics to

be computed.

The state trajectory over time, S(t), is abstracted as a step function, whose jumps

(discontinuities) are triggered by discrete events, which induce state transactions (changes

in the system state) at particular points in time. Although computer implementation of

events varies among DES simulators, they are all conceptually similar: An event is a data

structure that always has a field containing its time of occurrence, and any number of other

fields. Furthermore, the “occurrence” of an event in a DES simulator is implemented as the

execution of a corresponding procedure (computer code) at the scheduled event occur-

rence time. When that procedure is run, we say that the event is processed or executed.

Simulation Modeling and Analysis with Arena

The evolution of any DES model is gove rned by a clock and a chronologically

ordered event list. That is, events are linked in the event list according to their scheduled

order of occurrence (Figure 2.1). The event at the head of the list is called the most

imminent event for obvious reasons. Scheduling an event means that the event is linked

chronologically into the event list. The occurrence of an event means that the event is

unlinked from the event list and executed. The execution of an event can change state

variables and possibly schedule other events in the event list.

An essential feature of the DES paradigm is that “nothi ng” changes the state unless

an event occurs, at which point the model typically undergoes a state transition. More

precisely, every event execution can change the state (although on rare occasions the

state remains intact), but every state change is effected by some event. Between events,

the state of the DES is considered constant, even though the system is engaged in some

activity. For example, consider a machine on the factory floor that packages beer cans

into six-packs, such that the next six-pack is loaded for processing only when the

previous one has been completely processed. Suppose that the state tracks the number

of six-packs waiting to be processed at any given time. Then during the proces sing time

of a six-pack, the DES state remains unchanged, even though the machine may, in fact,

be processing six beer cans individually. The DES state will only be updated when the

entire six-pack is processed; this state change will be triggered by a “six-pack comple-

tion” event. Note again that the definition of the state is up to the modeler, and that

models can be refined by adding new types of events that introduce additional types of

state transitions.

At the highest level of generalization, a DES simulator executes the following

algorithm:

1. Set the simulation clock to an initial time (usually 0), and then generate one or

more initial events and schedule them.

2. If the event list is empty, terminate the simulation run. Otherwise, find the most

imminent event and unlink it from the event list.

3. Advance the simulation clock to the time of the most imminent event, and execute

it (the event may stop the simulation).

4. Loop back to Step 2.

This beguilingly simple algorithm (essentially an infinite loop) is extremely general.

Its complexity is hidden in the routines that implement event execution and the data

structures used by them. The power and versatility of the DES simulation algorithm

Event 1

Time: 7.25

Event 2

Time: 11.2

Event 3

Time: 22.13

Event 4

Time: 22.11

Other fields

Event List Head

Event List Tail

Figure 2.1 Structure of a DES event list.

12 Discrete Event Simulation

stem from the fact that the DES paradigm naturally scales to collections of interacting

subsystems: one can build hierarchies of increasingly complex systems from subsys tem

components. In addition, the processing of any event can be as intricate as desired. Thus,

both large systems as well as complex ones can be represented in the DES paradigm.

(For more details, see Fishman 1973, Banks et al. 1999, and Law and Kelton 2000.)

2.2 EXAMPLES OF DES MODELS

In this section the power and generality of DES models are illustrated through

several examples of elementary syst ems. The examples illustrate how progressively

complex DES models can be constructed from simpler ones, either by introducing new

modeling wrinkles that increase component complexity, or by adding components to

create larger DES models.

2.2.1 SINGLE MACHINE

Consider a failure-proof single machine on the shop floor, fed by a buffer. Arriving

jobs that find the machine busy (processing another job) must await their turn in the

buffer, and eventually are processed in their order of arrival. Such a service discipline is

called FIFO (first in first out) or FCFS (first come first served), and the resulting system

is called a queue or queueing system. (The word “queue” is derived from French and

ultimately from a Latin word that means “tail,” which explains its technical meaning as

a “waiting line.” Its quaint spelling renders it one of the most vowel-redundant words

in the English language.) Suppose that job interarrival times and processing times are

given (possibly random). A schematic description of the system is depicted in Figure 2.2.

To represent this system as a DES, defin e the state S(t) to be the number of jobs in

the system at time t. Thus, S(t) ¼ 5 means that at time t, the machine is busy processing

the first job and 4 more jobs are waiting in the buffer. There are two types of events:

arrivals and process completions. Suppose that an arrival took place at time t, when

there were S(t) ¼ n jobs in the system. Then the value of S jumps at time t from n to

n þ 1, and this transition is denoted by n ! n þ 1. Similarly, a process completion

is described by the transition n ! n  1. Both transitions are implemented in the

simulation program as part of the corresponding event processing.

2.2.2 SINGLE MACHINE WITH FAILURES

Consider the previous single machi ne on the shop floor, now subject to failures.

In addition to arrival and service processes, we now also need to describe times to

Job

Departures

Job

Arrivals

Machine

FIFO

Buffer

Figure 2.2 A single FIFO machine.

Discrete Event Simulation 13

failure as well as repair times. We assume that the machine fails only while processing

a job, and that on repair completion, the job has to be reprocessed from scratch.

A schem atic descri ption of the system is depicted in Figure 2.3.

The state S(t) is a pair of variables, S(t) ¼ (N(t), V (t) ), where N( t) is the number of

jobs in the buffer, and V(t) is the process status (idle, busy, or down), all at time t.Ina

simulation program, V(t) is coded, say by integers, as follows: 0 ¼idle, 1 ¼busy, and 2 ¼

down. Note that one job must reside at the machine, whenever its status is busy or down.

The events are arrivals, process completions, machine failures, and machine repairs.

The corresponding state transitions follow:



Job arrival: (n, v) ! (n þ 1, v)



Service process completion: (n,1)!

(0, 0), if n=1

(n  1, 1), if n > 1





Failure arrival: (n,1)! (n,2)



Repair completion: (n,2)! (n,1)

2.2.3 SINGLE MACHINE WITH AN INSPECTION STATION AND

ASSOCIATED INVENTORY

Consider the single machine on a shop floor, without failures. Jobs that finish

processing go to an inspection station with its own buffer, where finished jobs are

checked for defects. Jobs that pass inspection are stored in a finished inventory ware-

house. However, jobs that fail inspection are route d back to the tail end of the machine's

buffer for reprocessing. In addition to interarrival times and processing times, we need

here a description of the inspection time as well as the inspection decision (pass/fail)

mechanism (e.g., jobs fail with some probability, independently of each other).

A schematic description of the system is depicted in Figure 2.4.

The state S(t) is a triplet of variables, S(t) ¼ (N (t), I(t), K(t) ) where N(t) is the

number of items in the machine and its buffer, I(t) is the number of items at the

inspection station, and K(t) is the storage content, all at time t. Events consist of

arrivals, process completions, inspection failure (followed by routing to the tail end

of the machine's buffer), and inspection passing (followed by storage in the warehouse).

The corresponding state transitions follow:



Job arrival: (n, i, k) ! (n þ 1, i, k)



Process completion: (n, i, k) ! ( n  1, i þ 1, k)



Inspection completion: (n, i, k) !

(n þ 1, i  1, k), if job failed inspection

(n, i  1, k þ 1), if job passed inspection



Machine

Failures

Repairs

FIFO

Buffer

Job

Arrivals

Job

Departures

Figure 2.3 A single FIFO machine with failures.

14 Discrete Event Simulation

2.3 MONTE CARLO SAMPLING AND HISTORIES

Monte Carlo simulation models incorporate randomness by sampling random values

from specified distributions. The underlying algorithms and/or their code use random

number generators (RNG) that produce uniformly distributed values (“equally likely”)

between 0 and 1; these values are then transformed to conform to a prescribed dis-

tribution. We add parenthetically that the full term is pseudo RNG to indicate that the

numbers generated are not “truly” random (they can be reproduced algorithmically), but

only random in a statistical sense; however, the prefix “pseudo” is routinely dropped for

brevity. This general sampling procedure is referred to as Monte Carlo sampling. The

name is attributed to von Neumann and Ulam for their work at Los Alamos National

Laboratory (see Hammersly and Handscomb 1964), probably as an allusion to the

famous casino at Monte Carlo and the relation between random number generation

and casino gambling.

In particular, the random values sampled using RNGs are used (among other things)

to schedule events at random times. For the most part, actual event times are determined

by sampling an interevent time (e.g., interarrival times, times to failure, repair times,

etc.) via an RNG, and then adding that value to the current clock time. More details are

presented in Chapter 4.

DES runs use a statistical approach to evaluating system performance; in fact,

simulation-based performance evaluation can be thought of as a statistical experiment.

Accordingly, the requisite performance measures of the model under study are not

computed exactly, but rather, they are estimated from a set of histori es. A standard

statistical procedure unfolds as follows:

1. The modeler performs multiple simulation runs of the model under study, using

independent sequences of random numbers. Each run is called a replication.

2. One or more performance measures are computed from each replication. Examples

include average waiting times in a queue, average WIP (work in process) levels,

and downtime probabilities.

3. The performance values obtained are actually random and mutually independent,

and together form a statistical sample. To obtain a more reliable estimate of the

true value of each performanc e metric, the corresponding values are averaged and

confidence intervals about them are constructed. This is discussed in Chapter 3.

Warehouse

Machine

FIFO

Buffer

Job

Arrivals

Passed Jobs

Inspection

Buffer

Inspector

Failed Jobs

Figure 2.4 A single FIFO machine with inspection and storage.

Discrete Event Simulation 15

剩余434页未读，继续阅读

clarkwym11

粉丝: 0
资源: 2

ARENA模拟：构建与分析复杂系统的关键工具

Simulation modeling and analysis with ARENA

Simulation Modeling and Analysis with ARENA By Tayfur Altiok Benjamin Melamed

Simulation_Modeling_and_Analysis

Arena Advanced

使用Arena进行系统仿真分析

Arena高级模拟：商业学生指南

使用ARENA进行模拟建模与分析

Altio克/Melamed的Arena模拟与分析软件详解

如何在Arena软件中建立一个生产线仿真模型，并进行效率分析和优化？请提供一个详细的流程。

友价免签约支付接口插件最新版

最新资源