Introduction To Simulation

  • تصفية - فلترة
  • الوقت
  • عرض
إلغاء تحديد الكل
مشاركات جديدة

    Introduction To Simulation


    1. Definition of Simulation Technique

    Simulation is one of the most powerful tools available to decision-makers responsible for the design and operation of complex processes and systems. It makes possible the study, analysis and evaluation of situations that would not be otherwise possible. In an increasingly competitive world, simulation became an indispensable problem solving methodology for engineers [1], designers and managers.
    Simulation is the imitation of the operation of a real-world process or system over time. Simulation involves the generation of an artificial history of a system, and the observation of that artificial history to draw inferences concerning the operating characteristics of the real system that is represented. Simulation is an indispensable problem-solving methodology for the solution of many real-world problems. Simulation is used to describe and analyze the behavior of a system, ask "what if" questions about the real system, and to aid in the design of real systems. Both existing and conceptual systems can be modeled with simulation.
    2. Modeling Concepts
    There are several concepts underlying simulation. These include system and model, events, system state variables, entities and attributes, list processing, activities and delays, and finally the definition of discrete-event simulation. Additional information on these topics is available from Banks, Carson and Nelson [3] and Law and Kelton [2]. The discussion in this section follows that of Carson [4].
    2.1 System, Model and Events
    A model is a representation of an actual system. Immediately, there is a Concern about the limits or boundaries of the model that supposedly represent the system. The model should be complex enough to answer the questions raised, but not too complex. Consider an event as an occurrence that changes the state of the system.
    12.2 System State Variables
    The system state variables are the collection of all information needed to define what is happening within the system to a sufficient level (i.e., to attain the desired output) at a given point in time. The determination of system state variables is a function of the purposes of the investigation, so what may be the system state variables in one case may not be the same in another case even though the physical system is the same. Determining the system state variables is as much an art as a science. However, during the modeling process, any omissions will readily come to light. (And, on the other hand, unnecessary state variables may be eliminated.) Having defined system state variables, a contrast can be made between discrete-event models and continuous models ****d on the variables needed to track the system state. The system state variables in a discrete-event model remain constant over intervals of time and change value only at certain well-defined points called event times. Continuous models have system state variables defined by Differential or difference equations giving rise to variables that may change continuously over time. Some models are mixed discrete-event and continuous. There are also continuous models that are treated as discrete-event models after some reinterpretation of system state Variables, and vice versa.
    2.3 Entities and Attributes
    An entity represents an ****** that requires explicit definition. An entity can be dynamic in that it "moves" through the system, or it can be static in that it serves other entities. An entity may have attributes that pertain to that entity alone. Thus, attributes should be considered as local values.
    2.4 Resources
    A resource is an entity that provides service to dynamic entities. The resource can serve one or more than one dynamic entity at the same time, i.e., operates as a parallel server. A dynamic entity can request one or more units of a resource. If denied, the requesting entity joins a queue, or takes some other action (i.e., diverted to another resource, ejected from the system). (Other terms for queues include files, chains, buffers, and waiting lines.) If permitted to capture the resource, the entity remains for a time, and then releases the resource. There are many possible states of the resource. Minimally, these states are idle and busy. But other possibilities exist including failed, blocked, or starved.
    2.5 List Processing
    Entities are managed by allocating them to resources that provide service, by attaching them to event notices thereby suspending their activity into the future, or by placing them into an ordered list. Lists are used to represent queues. Lists are often processed according to FIFO (first-in first-out), but there are many other possibilities. For example, the list could be processed by LIFO (last-in-first out), According to the value of an attribute, or randomly, to mention a few.
    2.6 Activities and Delays
    An activity is duration of time whose duration is known prior to commencement of the activity. Thus, when the duration begins, its end can be scheduled. The duration can be a constant, a random value from a statistical distribution, the result of an equation, input from a file, or computed ****d on the event state.
    2.7 Discrete-Event Simulation Model
    Sufficient modeling concepts have been defined so that a discrete event simulation model can be defined as one in which the state variables change only at those discrete points in time at which events occur. Events occur as a consequence of activity times and delays. Entities may compete for system resources, possibly joining queues while waiting for an available resource. Activity and delay times may "hold" entities for durations of time. A discrete-event simulation model is conducted over time ("run") by a mechanism that moves simulated time forward. The system state is updated at each event along with capturing and freeing of resources that may occur at that time.

    3. Advan***es and Disadvan***es of Simulation
    Simulation has a number of advan***es over analytical or mathematical models for analyzing systems. First of all, the basic concept of simulation is easy to comprehend and hence often easier to justify to management or customers than some of the analytical models. In addition, a simulation model may be more credible, because its behavior has been compared to that of the real system or because it requires fewer simplifying assumptions and hence captures more of the true characteristics of the system under study. Additional advan***es include [1], [3].
    1. We can test new designs, layouts, etc. without committing resources to their implementation.
    2. It can be used to explore new staffing policies, operating procedures, decision rules, organizational structures, information flows, etc. without disrupting the ongoing operations.
    3. Simulation allows us to identify bottlenecks in information, material and product flows and test options for increasing the flow rates.
    4. It allows us to test hypothesis about how or why certain phenomena occur in the system.
    5. Simulation allows us to control time. Thus we can operate the system for several months or years of experience in a matter of seconds allowing us to quickly look at long time horizons or we can slow down phenomena for study.
    6. It allows us to gain insights into how a modeled system actually works and understanding of which variables are most important to performance.
    7. Simulation's great strength is its ability to let us experiment with new and unfamiliar situations and to answer "what if" questions.
    Even though simulation has many strengths and advan***es, it is not without drawbacks. Among these are:
    1. Simulation modeling is an art that requires specialized training and therefore skill levels of practitioners vary widely. The utility of the study depends upon the quality of the model and the skill of the modeler.
    2. Gathering highly reliable input data can be time consuming and the resulting data is sometimes highly questionable. Simulation cannot compensate for inadequate data or poor management decisions.
    3. Simulation models are input-output models, i.e. they yield the probable output of a system for a given input. They are therefore "run" rather than solved. They do not yield an optimal solution; rather they serve as a tool for analysis of the behavior of a system under conditions specified by the experimenter.
    4. Steps in a Simulation Study
    Figure (1) shows a set of steps to guide a model builder in a thorough and sound simulation study. Similar figures discussion can be found in other sources such as Pegden, Shannon, and Sadowski [1] and Law and Kelton [2]. This presentation is built on that of Banks, Carson and Nelson [3].

    1. Problem formulation Every simulation study should begins with a statement of the Problem. If the statement is provided by the policy makers or those that have the problem client, the simulation analyst must take extreme care to ensure that the problem is clearly understood. If a problem statement is prepared by the simulation analyst, it is important that the client understand and agree with the formulation. It is suggested that a set of assumptions be prepared by the simulation analyst and agreed to by the client. Even with all of these precautions, it is possible that the problem will need to be reformulated as the simulation study progresses.
    2. Setting of ******ives and overall project plan. Another way to state this step is "prepare a proposal." This step should be accomplished regardless of ******** of the analyst and client, viz., as an external or internal Consultant. The ******ives indicate the questions that are to be answered by the simulation study. The project plan should include a statement of the various scenarios that will be investigated. The plans for the study should be indicated in terms of time that will be required, personnel that will be used, and hardware and software requirements if the client wants to run the model and conduct the analysis, s***es in the investigation, output at each s***e, cost of the study and billing procedures.
    3. Model conceptualization. The real-world system under investigation is abstracted by a conceptual model, a series of mathematical and logical relationships concerning the components and the structure of the system. It is recommended that modeling begin simply and that the model grow until a model of appropriate complexity has been developed. For example, consider the model of a manufacturing and material handling system. The basic model with the arrivals, queues and servers is constructed. Then, add the failures and shift schedules. Next, add the material-handling capabilities. Finally, add the special features. Constructing an unduly complex model will add to the cost of the study and the time for its completion without increasing the quality of the output. Maintaining client involvement will enhance the quality of the resulting model and increase the client's confidence in its use.
    4. Data collection. Shortly after the proposal is "accepted" a schedule of data requirements should be submitted to the client. In the best of circumstances, the client has been collecting the kind of data needed in the format required, and can submit these data to the simulation analyst in electronic format. Oftentimes, the client indicates that the required data are indeed available. However, when the data are delivered they are found to be quite different than anticipated. For example, in the simulation of an airline-reservation system, the simulation analyst was told "we have every bit of data that you want over the last five years." When the study commenced, the data delivered were the average "talk time" of the preservationist for each of the years. Individual values were needed, not summary measures. This is to indicate that the simulation analyst can readily construct the model while the data collection is progressing.
    5. Model translation. The conceptual model constructed in Step 3 is coded into a computer recognizable form, an operational model.
    6. Verification. Verification concerns the operational model. Is it performing properly? Even with small ****book sized models, it is quite possible that they have verification difficulties. These models are orders of magnitude smaller than real models (say 50 lines of computer code versus 2,000 lines of computer code). It is highly advisable that verification take place as a continuing process. It is ill advised for the simulation analyst to wait until the entire model is complete to begin the verification process. Also, use of an interactive run controller, or debugger, is highly encouraged as an aid to the verification process.
    7. Validation. Validation is the determination that the model is an accurate representation of the real system. Can the model be substituted for the real system for the purposes of experimentation? If there is an existing system, call it the **** system, then an ideal way to validate the model is to compare its output to that of the **** system. Unfortunately, there is not always a **** system. There are many methods for performing validation. Appendix “A” shows Validation Process and Techniques.
    8. Experimental design. For each scenario that is to be simulated, decisions need to be made concerning the length of the simulation run, the number of runs (also called replications), and the manner of initialization.

    Figure (1) –Steps in a simulation study

    9. Production runs and analysis. Production runs, and their subsequent analysis, are used to estimate measures of performance for the scenarios that are being simulated.
    10. More runs. ****d on the analysis of runs that have been completed, the simulation analyst determines if additional runs are needed and, if any additional scenery need to be simulated.
    11. ********ation and reporting. ********ation is necessary for numerous reasons. If the simulation model is going to be used again by the same or different analysts, it may be necessary to understand how the program model operates. This will enable confidence in the simulation model so that model users can make decisions ****d on the analysis. Also, if the model is to be modified, this can be greatly facilitated by adequate ********ation. The result of all the analysis should be reported clearly and concisely. This will enable the client to review the final formulation, the alternatives that were addressed, the criterion by which the alternative systems were compared, the results of the experiments, and analyst recommendations.
    12. Implementation. The simulation analyst acts as a reporter rather than an advocate. The report prepared in step 11 stands on its merits, and is just additional information that the client uses to make a decision. If the client has been involved throughout the study period, and the simulation analyst has followed all of the steps rigorously, then the likelihood of a successful implementation is increased.
    5. Model Translation and Simulation and Simulation ********s
    Finally ready to describe or program the model in a ******** acceptable to the computer to be used. Well over a hundred different simulation ********s are commercially available. In addition there are literally hundreds of other locally developed ********s in use in Companies and Universities. We have three generic choices, namely [1]:-
    • Build the model in a general-purpose ********.
    • Build the model in a general-purpose simulation ********.
    • Use a special purpose simulation packages. Although general purpose programming ********s such as FORTRAN, C++, Visual Basic, or Pascal can be used they very seldom are anymore. Using one of the general or special purpose simulation packages has distinct advan***es in terms of ease, efficiency and effectiveness of use. Some of the advan***es of using a simulation package are:
    1. Reduction of the programming task.
    2. Provision of conceptual guidance.
    3. Increased flexibility when changing the model.
    4. Fewer programming errors.
    5. Automated gathering of statistics.

    The goal of any simulation package is to close the gap between the user's conceptualization of the model and an executable form. Simulation packages divide themselves more or less into two categories, namely (a) general purpose simulation ********s and (b) special purpose simulators. In the first category are those which can solve almost any discrete simulation problem. Among these are such systems as ARENA, AweSim, GPSS/H, Sim****** II.5, and Extend etc. Some systems are used for the simulation of manufacturing and material handling problems. Packages
    Such as SimFactory, ProModel, AutoMod™, Taylor II, and Witness fall into this category. Others are designed for conducting Business Process Reengineering studies. These include BPSimulator™, Process Model™, SIMPROCESS, and Extend+BPR. Still others are for healthcare delivery (Med Model), or communications networks (COMNET II.5).
    6. Paths to Success
    Just as we can learn from studying projects that fail, we can also learn from those that succeed [13]. Obviously the first thing we want to do is to avoid the errors of those who fail. Thus we want to:
    1. Have clearly defined and achievable goals.
    2. Be sure we have adequate resources available to successfully complete the project on time.
    3. Have management's support and have it known to those who must cooperate with us in supplying information and data.
    4. Assure that we have all the necessary skills required available for the duration of the project.
    5. Be sure that there are adequate communication channels to the sponsor and end users.
    6. Have a clear understanding with the sponsor and end users as to the scope and goals of the project as well as schedules.
    7. Have good ********ation of all planning and modeling efforts.


    [1].Robert E.Shannon, "Introduction to the art and science of simulation", proceeding of the 1998 winter simulation conference.
    [2] . - Law, A.M. and W.D. Kelton, 1991." Simulation Modeling and Analysis", 2nd Ed., New York: McGraw-Hill.
    [3]. Banks, J. and V. Norman, November, 1995. "Justifying Simulation in Today's Manufacturing Environment," IIE Solutions
    [4]. Carson, J.S., 1993. "Modeling and Simulation World Views," in Proceedings of the 1993 Winter Simulation Conference.
    [5]. Banks. Jerry "INTRODUCTION TO SIMULATION" in Proceedings of the 1999 Winter Simulation Conference P. A. Farrington, H. B. Nembhard, D. T. Sturrock, and G. W. Evans, eds.

المواضيع ذات الصلة


المواضيع إحصائيات آخر مشاركة
أنشئ بواسطة HaMooooDi, 05-31-2020, 10:13 PM
ردود 0
7 مشاهدات
0 معجبون
آخر مشاركة HaMooooDi
بواسطة HaMooooDi
أنشئ بواسطة HaMooooDi, 05-31-2020, 10:06 PM
ردود 0
9 مشاهدات
0 معجبون
آخر مشاركة HaMooooDi
بواسطة HaMooooDi
أنشئ بواسطة HaMooooDi, 05-31-2020, 04:30 PM
ردود 0
16 مشاهدات
0 معجبون
آخر مشاركة HaMooooDi
بواسطة HaMooooDi
أنشئ بواسطة HaMooooDi, 05-31-2020, 04:21 PM
ردود 0
18 مشاهدات
0 معجبون
آخر مشاركة HaMooooDi
بواسطة HaMooooDi
أنشئ بواسطة HaMooooDi, 05-30-2020, 02:33 PM
ردود 0
11 مشاهدات
0 معجبون
آخر مشاركة HaMooooDi
بواسطة HaMooooDi