From Sigma

Revision as of 22:27, 20 July 2008 by Davida (Talk | contribs)
Jump to: navigation, search



SIGMA is based on the simple and intuitive Event Relationship Graph (sometimes called an ERG or Event Graph) approach to simulation modeling. The SIGMA project began as an effort to implement the notion of Event Relationship Graphs on personal computers and has evolved into a powerful and practical method for simulation modeling. SIGMA, the Simulation Graphical Modeling and Analysis system, is an integrated, interactive approach to building, testing, animating, and experimenting with discrete event simulations, while they are running. SIGMA is specifically designed to make the fundamentals of simulation modeling and analysis easy. SIGMA is able to translate a simulation model automatically into fast C source code that can be compiled and linked to the sigmalib.lib library to run from a spreadsheet or web interface. SIGMA can also write a description of a simulation model in English. SIGMA was developed without external or University funding.

File Name Extensions

The specific function of SIGMA files are identified by the extensions to their filenames as in following table. .

File Name Extentions
Extension File Type Indicated
.BAK Backup copy of the last saved model
.BAT Batch files
.BMP Bitmaps used for animations
.C Source code in C
.DAT Data files for SIGMA models
.EXE Executable programs
.EXP Experiment file for batched runs (chpt. 11)
.H Source code in C
.LIB SIGMA C Function Library
.MOD Sample SIGMA models
.OUT SIGMA output files (if any)

The SIGMA Modeling Environment

SIGMA is a unique and powerful simulation environment. Developed primarily for discrete event simulations, SIGMA has been proven able to represent any computer program, with modeling power referred to in computer science as Turing Complete.

SIGMA is based on the concept of an Event (Relationship) Graph. Event Graphs graphically capture the events taking place within a system and the relationships among these events. While Event Graphs may look similar to flow graphs, they are very different: Event Graphs are relationship graphs. Thus, a simple model can represent a very large and complex system.

SIGMA’s most striking feature is that simulation models can be created, enriched, and edited while they are running. Events can be added, altered, or even deleted during a simulation run. Logic can be changed and errors corrected without stopping a run to change code and recompile. You can even pause and "replay" interesting events. Using SIGMA, a simulation model can be developed and verified in a fraction of the time it would take using conventional simulation languages.

Animation support is fundamentally different in SIGMA than in other simulation modeling environments. Animations are not created from simulation models using conventional add-on software; in SIGMA, the animation and the simulation model are identical.

In addition to graphical modeling, analysis, and animation, SIGMA also includes state-of-the-art graphical data tracking tools and allows pictures, graphs, plots, and data to be pasted into spreadsheets and word processors.

For speed and portability, SIGMA models can be automatically translated (with a mouse click) into a fast C code. Not only does this code allow models to run thousands of times faster, models can then be run from a spreadsheet and multiple experimental runs can be batched together. A SIGMA model can even write a description of itself in English.

Multiple SIGMA sessions can be run concurrently. You can copy and paste objects from one modeling session to another. In fact, models can be developed in one SIGMA session and then graphically integrated into another simulation model while that model is executing.

SIGMA supports the full simulation model life cycle: from model building and testing to output analysis, animation, documentation, and report writing. Discrete event simulation model building has never been easier, and the results from simulations have never before been so easy to observe and understand.

Discrete Event System Modeling

"A process cannot be understood by stopping it. Understanding must move with the flow of the process, 
must join it and flow with it"
                                                                  -First Law of Mentant

This chapter contains an introduction to the key concepts and terminology of discrete event simulation. The event graph, a method of concisely organizing the elements of a discrete event simulation, is introduced. Using a simple waiting line as an example, an elementary event graph is developed and explained. The future events list, which is the master scheduler of events in a discrete event simulation, is examined in detail. A verbal description of an event graph is introduced as a first step in developing a formal event graph.

Background and Terminology for Systems Modeling

Here we will use computer simulation to study the dynamic behavior of systems –i.e., how systems change over time. Our focus will be on those systems where the status of a system changes at a particular instant of time; such systems are called discrete event systems. Discrete event systems can be found in areas as diverse as manufacturing, transportation, computing, communications, finance, medicine, and agriculture. Engineers, scientists, managers, and planners use simulation methodologies to design and test new systems and to evaluate existing ones, thus avoiding the expense and risks of physical prototypes and pilot studies.


It will be sufficient for our purposes to define a system as:

     a collection of entities that interact with a common purpose according to sets of 
     laws and policies.

The system may already exist, or it may be proposed. Using simulation, even theoretical systems can be studied. We intentionally do not define a system by the specific entities in it. Rather, we define a system by its purpose. Thus, we speak of a communications system, a health care system, a production system, etc. Using a functional definition of a system helps us avoid thinking of a system as having a fixed structure. Consequently, we view a system in terms of how it ought to function rather than how it has traditionally worked in the past. To design a new system it is necessary to free our thinking from the status quo.

The entities making up the system may be either physical or mathematical. A physical entity might be a patient in a hospital or a part in a factory; a mathematical entity might be a variable in an equation.

When developing simulation models of systems, it is useful to classify entities as being either resident entities or transient entities. Resident entities remain part of the system for long intervals of time, whereas transient entities enter into and depart from the system with relative frequency. In a factory, a resident entity might be a machine; a transient entity might be a part. Depending on the level of detail desired, a factory worker might be regarded as a transient entity in one model and a resident entity in another.

In describing a particular aspect of the dynamic behavior of a system, it is often useful to focus on the cycles of the resident entities. For example, we might describe the busy-idle cycles of machines or workers. Alternatively, we might focus on the paths along which transient entities flow as they pass through the system (e.g., parts moving through a factory). Transient entity system descriptions tend to be more detailed (and more informative) than resident entity descriptions. Each type of modeling has advantages: modeling resident entity cycles tends to be easy and efficient, while modeling the details of transient entity flow gives more information. Typically, a mixture of both viewpoints is used, but one or the other predominates.

In systems where there are relatively few resident entities and a great many transient entities, it is usually most efficient to study the cycles of the resident entities. Examples include semiconductor factories with thousands of wafers, communication systems with millions of messages, and transportation systems with tens of thousands of vehicles. In simulating such systems, the cycles of resident entities might be described by the values of only a few variables, while the flow of transient entities might require a great many variables to describe. On the other hand, systems where there are only a few transient entities and many resident entities (a power line inspection system or an airline maintenance facility) may be efficiently studied by examining the flow of transient entities.

It will often be the case that an initial model consisting only of resident entities is appropriate. Thus, first-cut system experiments can be done with a simple and efficient model. After a design has been roughed out and more details are desired, the model can be enriched into a transient entity flow model. Enriching the model to explicitly include transient entities generally makes the model larger, more complex, more prone to errors, and slower to execute. It may be wiser to use detailed transient entity models only for final refinements of a design. A well-designed simulation may have some sections that model only resident entity cycles and other sections that model the detailed flow of transient entities.

Entities are described by their characteristics (referred to as attributes). Attributes can be quantitative or qualitative. Moreover, they can be static and never change (the speed of a machine), or they can be dynamic and change over time (the length of a waiting line). Dynamic attributes can further be classified as deterministic or stochastic depending on whether or not the changes in their values can be predicted with certainty. It is sometimes useful to think of entities as belonging in sets owned by other entities. For example, in a factory a set of parts might be waiting in a line (queue) for a particular machine. Also, a set of machines (routing) might be required to process each part. Thus, each machine owns a set of parts, and each part owns a set of machines.

The Entity/Attribute Hierarchy for a Health Care System


Event Relationship Graphs

Back to Main Page

Personal tools