Integrated simulation combining process-driven and event-driven models

Abstract

A simulation framework that integrates process-driven and event-driven approaches offers a powerful combination of tools to the modeller. In process-driven simulation models, the system can be represented by block diagrams or system networks through which entities flow to mimic real-life system objects. In event-driven models, the system can be represented by event graphs, which focus on the abstraction of the event rather than on observable physical entities. In this research, a simulation environment is proposed that integrates both the approaches, that is, process and event. One of the main outcomes of working in such an environment is that modellers can manage the complexity of large models based on real-world systems through process orientation, while retaining the control over the attributes, variables and the logic through event orientation. Discrete event simulation is often taught to students at either the event level or the process level. A simulation tool that effectively preserves both levels would be helpful in more effectively educating future simulation modellers.

1. Introduction and background

Simulation used as a tool to analyse as well as to experiment with various strategies makes it a very important component of the decision-making process. The applications of simulation can be found in various fields of study from health-care systems to military applications, manufacturing to computational systems biology. A simulation model is a representation of a system of interest, used to gain insights about existing systems and investigate systems under new operating conditions. A discrete event simulation model is discrete, dynamic and stochastic in nature. Discrete event models represent a system in which the state of the system changes only at a discrete set of points in time. Unlike analytical models, discrete event simulation models are ‘run’ rather than solved (Banks et al, 2005). The artificial history generated by the models is similar to that of the real-life system and is analysed to estimate measures of effectiveness.

Modellers opt for a world view while developing a simulation model, the most popular being event scheduling, process interaction, and activity scanning. The event scheduling or event-driven framework concentrates on events and their effect on the state of the system. The process interaction or process-driven world view focuses on the processes, entities and their lifecycle in the system. Activity scanning concentrates on the activities in the system and the conditions that allow them to begin and continue.

Event graph models (eg Sigma) were introduced by Schruben (1983) and are based on the detail-level, event-driven dynamics of simulation. In event-driven simulation, events are the fundamental actions that change the values of the variables that describe the system state and drive the scheduling of future events. System dynamics are modelled by events that change the state of the system and the logical and temporal relationships among these events (Savage et al, 2005). In an event graph model, the effect of events on the variables is described in vertices (nodes) and the relationship between events both logically and in time is represented by directed edges (arcs).

Figure 1 shows an event graph model with an arrival process (with interarrival times t _a), a service process (with service times t _s), initial queue Q as empty, and resource S with a capacity of k units. Event graphs are not flow charts, and thus are quite different from process models, but are a representation of the system structure. The directed edges or arcs indicate the influence of one event on the occurrence of other events. Edges can represent event-scheduling as well as event-cancelling dynamics. Event-driven models are simulated using objects such as a simulation clock and a list of future events. The simulation engine controls the relationships between the model, the clock and the events list as simulated time passes.

Figure 1

Event graph for simple queuing system.

Activity scanning concentrates on the activities in a model, and the conditions that allow the activities to begin (Banks et al, 2005). At each time step, the conditions of each activity are checked and the activities that return a true value are executed. A disadvantage of activity scanning is that it requires repeated scanning of the conditions on all of the activities. This tends to slow the speed of the simulation. Activity scanning requires that the model builder have a detailed understanding of how all the processes in a system interact. It can be difficult to implement models of systems with highly decentralized processes using the activity scanning approach. This is because the real system is very much decentralized, whereas the model may require very centralized activity scanning logic. Because of this, the activity scanning approach can be very difficult for model builders to master.

The process-driven modelling paradigm represents a higher level of abstraction than the event graph approach. The simple queuing system discussed above can be represented in a process-driven model as shown in Figure 2. Schriber and Brunner (1995, 2005) discuss generic discrete event systems. The implementation of a process model is similar, but software-specific, in simulation tools like SIMAN, Arena (Pegden et al, 1995), ProModel (ProModel Corporation, 1995), GPSS/H (Crain and Smith, 1993), AutoMod (Phillips, 1997), SLX (Henriksen, 2000), and Extend (Krahl and Lamperti, 1997). The models that Schriber describes are process-driven, in which the basic unit is the entity, which flows through a network of resources, time delays and routing logic. The two different possible types of entities are external and internal, where external entities explicitly exist in the simulation environment and internal entities are implicit, for example, machine failures. While a model is being simulated, entities may be in one of a number of possible states Active, Ready, Time-Delayed, Condition-Delayed, and Dormant. In Schriber's generic simulation model, the data structures used to organize the entities in different states are the Active Entity list, Current Event list, Future Event list, Delay list, and User-Managed list. The simulation of the model takes place in two phases, namely the Entity Movement Phase (EMP) and the Clock Update Phase (CUP). The simulation time is updated in the CUP.

Figure 2

Process model for simple queuing system.

The corresponding terminology for the Current Events list in SIMAN (Schriber and Brunner, 1995) is the Current Events Chain (CEC). The Ready State entities in the CEC are removed and made active in the EMP. When an active entity leaves the Active State and there are no Ready State entities, then the EMP checks for ‘wait conditions’, and ‘condition delayed entities’, in order to move them to the CEC. That is followed by the CUP. The EMP and CUP continue in alternate order until the simulation end time or condition.

In event-driven simulation models, a modeller has the ability to influence the state of everything at any time and flexibility with regard to attributes, variables, and logic flow (Kelton et al, 2004). Alternatively, the ease of modelling a real system with a commonly understood flow chart approach using process blocks has allowed process-driven models to be more accepted among the practice-oriented simulation user community. A major reason for the popularity of process-driven models is the direct mapping of simulation logic to the model animation. The commercial effort to make simulation modelling methodology more accessible to non-programmers has created a separation between technically oriented and non-technically oriented simulation users (Healy and Kilgore, 1997). The separation discussed here is the inaccessibility of the state variables of the simulation model and the simulation engine to the simulation user.

The overwhelming majority of discrete event simulation tools in use, as reported in a software survey in 2005 (Swain, 2005), are based on process-driven models. The process-driven modelling framework's main strength is drawn from the process analysis approach (Seppanen et al, 2005), which when applied in an orderly manner helps in analysing the multiplicity of factors affecting a process. Simulation environments based on this approach are very effective in translating the analysts’ understanding of system structure into a model. Application-specific tools like Lay OPT (Grajo, 1996) and general-purpose simulation packages like Extend (Krahl and Lamperti, 1997) use the process-driven approach. One of the advantages of the process-driven approach is its ‘natural’ mapping to physical flow in actual systems (Schriber and Brunner, 2005) which makes the approach easy for new modellers to accept. However, the ease of modelling of simple systems may misdirect the modellers about the appropriateness of process-driven models for large, complex and congested systems. Experienced simulation modellers have often experienced the shortcomings of process-driven models in modelling more difficult problems like failure queuing, resource deadlock, congestion constipation, jockeying, time-bound sequences, state-dependent service rates, and multiple failure modes and responses.

Buss (2001) supports event-oriented simulation models over other world views such as process/resource. Even though the event-orientation makes simple models slightly more complex, it provides more flexibility and modelling power than a pure process-oriented world view. Every model that can be represented in the process world view can also be represented in an event-oriented model, but the reverse is not true. In order to combine the advantages of both world views, Buss attempts to give the appearance of process-oriented model to event-oriented models. It is accomplished by aggregating some sections of an event graph model into process-oriented components. The resulting simulation environment (Simkit) uses the ‘listener pattern’ from software engineering to implement the interoperability of simulation components. This software implementation using the listener pattern is analogous to the ‘activity scanning’ perspective on models.

Schruben and Roeder (2003) offer a small set of examples of how access to event-driven modelling offers more control for complex model building situations, and higher execution speeds with respect to both job and resource-driven approaches. Because of these advantages, sophisticated, detail-oriented simulation modellers often favour access to the event-driven modelling approach. In the case of event graphs, this is through a graphical user interface. In the case of many languages, this is through access to the underlying objects and methods through a programming interface. Popular simulation packages like SIMAN (ie Arena and related technologies like Simio) fall into this category, which provide ‘event’ blocks for the modellers to access the programming layer. This access is more for programming-oriented users rather than modelling-oriented users, for which an event graph would be more effective. On the other hand, non-technically oriented simulation users will typically opt for ease in model building, using templates of application-specific, process-driven components.

Many technical developments have taken place to make environments based on the process-driven models more appealing. There have not been simulation tools that readily give users the advantages of both approaches, that is, process-driven and event-driven. In particular, users often have to resort to pure ‘programming’ logic to access the event layer, if it is available. A simulation tool that elegantly and efficiently integrates the two approaches in its simulation engine is a requirement for providing the process- and event-modelling functionality to all classes of users. This paper describes the design and implementation of a simulation engine that integrates the two approaches.

The remainder of the paper is organized as follows: Section 2 describes how the simulation framework is structured to efficiently handle models at both the process and event level. Section 3 gives some details on how the process and resource layers in the IE ² framework are designed to support the common needs of simulation modellers. Section 4 describes the integration of the event layer in the framework, and specifically introduces the new Entity Enhanced Event Graph. Section 5 gives a brief overview of the design of the simulation engine that handles the mechanics of efficiently simulating the models. Section 6 has some details on how the user interacts with the framework through a prototype user interface. Section 7 demonstrates the implementation of a classic model (the multiple server queue) in the framework. Section 8 describes conclusions, contributions and future work.

2. Simulation framework overview

The integrated simulation framework (Figure 3) has two main components: an IE ² (Integrated Entity/Event) Integrator and an IE ² model. One of the main goals in the design of the framework is to preserve the elegantly simple logic to process events, even when processing of entities is taking place simultaneously.

Figure 3

Integrated simulation framework overview.

2.1. IE ² integrator

The main functions of the IE ² Integrator are (a) effective communication between the process-driven and event-driven model components, and (b) efficient handling of entities and events for better coordination of the hierarchical layers of the model. The IE ² Integrator has access to prioritized entity and event lists UE ² L (Updated E ² Lists), the processor and the simulation clock. The UE ² L consist of lists of active entities and events as they are being populated by the IE ² model as it is simulated. The list is sorted according to the time of the next scheduled action for an entity or event, with smaller times having higher priority. Each simulation step, the IE ² Integrator compares the priorities of the highest priority item on the entity and event lists, removing the one with the highest priority. This entity or event is used to update the simulation clock, and then is sent to the processor. The processor routes the entity or event to the appropriate process block or event node, respectively. After handling the entity or event, the model object makes appropriate entries in the UE ² L lists.

2.2. IE ² model

The IE ² model provides hierarchical modelling capabilities with process-driven and event-driven components as the upper and lower layers, respectively. The IE ² model provides an interface for the user to build process-driven models. Process-driven models created by the user are a collection of appropriate, interconnected process blocks. In order to hierarchically embed event-driven models within a process-driven model, the IE ² model provides an ‘EventGraph’ block (Figure 4). The ‘EventGraph’ block behaves as a regular process block as well as a workspace for containing an event-driven model. The EventGraph block goes beyond standard event graphs by implementing the Entity Enhanced Event Graph (E ² Event Graph).

Figure 4

Entity-event interaction in an IE ² model.

The event-driven model, which is created in the ‘EventGraph’ block, updates the state of the system, schedules events, and also coordinates with the process-driven model for smooth transition of the entities into and out of the block. As shown in Figure 4, an entity that enters the event-driven model or ‘EventGraph’ block makes its attributes available to the events. The entity that enters the event-driven model is not destroyed: it is tagged to any event that it triggers. The entity attributes may be updated by the events that occur within the block. The entity is held by the event-driven model until it exits the block by the triggering of an Exit event. The updated entity then returns to continue processing by the process-driven components of the simulation model. The handling of entities in a systematic way in the event graph block is a novel feature of the E ² Event Graph. Section 4 further elaborates on the E ² Event Graph and its implementation in the EventGraph block.

3. Process components in IE ² framework

The IE ² framework provides a set of basic process blocks for building process-driven models. In addition to that, a sub-model block is also provided for building multiple layer or hierarchical simulation models. These process components are based on the existing simulation framework namely, queues, resources, blocks, etc. Process-driven model components, in an integrated framework, are necessary for modellers to consider components of a system at a fairly abstract level. Event-driven logic is useful for modelling detailed logic. However, an elegant and accurate model can only be realized by the modellers’ acumen in using the event- and process-driven models appropriately. Figure 5 shows process components like, Create, Seize, Delay, Release, Dispose, and EventGraph. The IE ² model provides an ‘EventGraph’ block to hierarchically embed event-driven models within a process-driven model. Typical options available in each of these blocks are also incorporated in these process-driven components.

Figure 5

Block inheritance.

The process components are defined as a generic class ‘Block’. As shown in Figure 5, all the other process components are defined as sub-classes of the generic ‘Block’ class. This is helpful in dynamically binding the common methods in the sub-classes. Therefore the blocks with special functionalities are simply inherited or defined as sub-classes.

3.1. Simulation model components: resource and queue

An important feature of the IE ² model is that it explicitly models the entity flow taking place at the event level. This feature augments the capabilities of a simulation modeller by making some aspects of process logic available in the event layer and vice versa. However, the two layers are different when they interact with resident entities like resources, queues, etc. This section discusses the intermediate layer that handles queues and resources for the process- and event-driven models. This flexibility provided by the intermediate layer reduces the level of modelling abstraction at the event graph level, and leads to a more seamless IE ² model that spans the two levels. For example, in standard event graphs, resources and queues are left to the modeller to instantiate as appropriate variables.

An entity can change its state depending upon the layer in which it resides. In an IE ² simulation model, entities can be in one of the three fundamental states namely, Transient, Passive, and Tagged. These three states of the entities and the resource layer form the basis for the communication between the process- and event-driven layers in an IE ² model (Figure 6).

Figure 6

States of entities in different layers of IE ² model.

3.2. Resource layer

The resource layer in the IE ² simulation framework manages the resident entities like resource, queues, etc. The resource layer has been designed to be a separate layer from the process- and event-driven layers. The main aim of the resource layer is to hold the components (in this case, queues and resources) that are common to both the layers and establish a communication between the process- and event layers. The functions of the resource layer are summarized as follows:

• control access to the resident entities, that is, resource, queue, and

• effective management of the global and local resident entities in large simulation models.

For effective data management, a simulation model often requires defining resources that are either global or local to different parts of the model. In order to have a structured way of accessing resources, the ‘Resource’ and ‘Queue’ objects are instantiated and stored in the ‘Model’ class. The purpose of associating them with the ‘Model’ class is to centralize the control of the resident entity objects. The resident entities, that is, resources and queues, are instantiated within the constructor and stored in the corresponding vectors. The ‘Model’ class is the main class that interfaces with the modellers while building a simulation model. The modellers use these vectors of the resident entities through the user interface to associate them with appropriate parts of the model. For example, the method which instantiates a Seize block in the simulation model uses the reference of ‘Resource’ and ‘Queue’. This serves the purpose of controlled access to the resident entities. While the actual objects of the resource and queue are in the Model class, the process blocks which need the resident entities are given the access through pass by reference.

4. Enhanced modelling using entities

First introduced by Schruben (1983), an event graph (eg, the Sigma environment) uses event procedures as the building block to update the state of the system, and schedule other events. An important feature of standard event graphs is parameterization of the event vertices, thus combining similar model sub-graphs as a generic graph distinguished by parameter values (Schruben, 1983). The IE ² framework based on an integrated entity/event approach has been further enhanced to explicitly represent entities at the event-driven level. This addition to the integrated simulation framework helps to diminish the abstraction involved in parameter passing. The solution lies in explicitly passing the entities through the event-driven model. Event parameters are replaced by entity attributes. The usage of entities in the event-driven layer serves two purposes: (a) reduce the abstraction by manipulating entity objects instead of working with parameters as in a programming language, and (b) gives the intuitive feel of process-driven models to modellers at the event level, which enhances the appeal of the event-driven models.

4.1. Event parameters and edge attributes

Event parameter passing is a parameterization of the event vertices in standard event graphs. It is an important feature of the implementation of event graphs in a modelling environment (Schruben, 1983). An event graph, as shown in Figure 7, is the representation of an event-driven model. Figure 7 represents event A and event B through nodes or vertices and scheduling of event B by event A is represented by an arc or edge. For the scheduling of an event, a Boolean condition can be evaluated and this is represented by the curved line on the scheduling arc. The event graph as designed by Schruben (1983) uses a feature called ‘event parameters’ or ‘parameter passing’. The concept of event parameters is to represent similar events in a simulation model by a single vertex with different parameter values.

Figure 7

Standard event graph segment with condition (i), delay time t, and parameter passing.

The event parameter concept is demonstrated with the example in Figure 7. When event A occurs then, if the condition i is true, event B is scheduled after a delay of t time units, with the current value of j stored in the act of scheduling B. At a later simulated time, when this instance of event B occurs, its parameter variable k is set to the stored value of j. Parameter passing allows a standard event graph to represent large systems in a compact model, by parameterization of similar events.

The following summarizes the modelling roles filled by event parameters or parameter passing:

• event parameters represent similar events in a simulation model by a single vertex or node with different parameters, and

• it allows a standard event graph to represent large systems in a compact model.

Even though parameter passing is a powerful feature of event graphs, it falls short or needs improvement in the following aspects:

• event parameters are based on a programming style approach and its model representation, as shown in Figure 7, is not intuitive to modelling-oriented simulation practitioners, and

• though it represents large systems in a compact model, from the usability perspective, modellers need to put in extra effort to comprehend the simulation model in terms of real systems.

4.2. The Entity Enhanced (E ² ) Event Graph

An important feature of the IE ² model is that it explicitly models the entity flow taking place at the event level. The Entity Enhanced (E ²) Event Graph augments the capabilities of a simulation modeller in the event layer by including some of the structure usually associated with process logic. One of the prominent features of building simulation models with standard event graphs (Schruben, 1983) is the use of event parameters. In our framework, the role of event parameters in the event graph is replaced by entities in the E ² Event Graph. This additional structure reduces the level of modelling abstraction due to parameter passing at the event-driven level, and leads to a more seamless, IE ² model that spans the two levels.

An E ² Event Graph segment in an IE ² model is shown in Figure 8. The important elements (including the three elements usually defined in an event graph) in an IE ² model are the state variables, events that update the state variables, scheduling relationships between the events, and entities that are associated with the events. As in a standard event graph, events are represented by nodes (vertices) and the scheduling relationships between events are represented by arcs (edges). In addition, in an E ² Event Graph, entities associated with arcs and nodes are represented by a black dot as shown in Figure 8. The presence or absence of the dot at the end of the scheduling arc indicates the association of an entity with the node and arc.

Figure 8

E ² Event Graph model segment with two events.

In Figure 8, the nodes A and B represent events. The arc connecting nodes A and B represents the scheduling relationship between the events and it has the following functionalities:

• Schedules event B when the condition {bool} is true, and

• Associates an entity with event B

The presence of a dot at the end of a scheduling arc indicates an association of an entity with the scheduling relationship. The absence of a dot in a scheduling arc indicates that no entity association is taking place in the scheduling of that event.

The following are the advantages of the E ² Event Graph segment with the event-entity arc over the typical event graphs as proposed by Schruben (1983):

• The E ² Event Graph uses entities to carry entity-specific information instead of using event parameters. Hence, entities are explicitly represented in the event model, as shown in Figure 8. This reduces the abstraction associated with the implementation of variables or parameters.

• Another advantage of explicitly representing the entities at the event level is that the modeller gets the intuitiveness of a typical process-driven model. The flow chart or process-driven approach of entity movement in the event-driven model makes it easier to comprehend large systems.

5. Simulation engine

A simulation engine that supports process-driven models was developed during the inception phase of the research. The choice of programming language, C++, was based on its imperative, object-oriented and generic paradigms. The algorithm used to simulate a discrete event model should be captured in a software architecture that is elegant in representing the IE ² structure and efficient as a simulation engine. At this stage, different software design patterns from the theory of software architecture (Kuchana, 2004) were considered, as they provide a more tested and proven development paradigm that can speed up the process of software development. The mediator pattern was the most appropriate software pattern which expresses the required functionality.

A simulation framework consists of a number of objects (blocks/classes). Logic and computation is distributed among different objects (blocks/classes). As the simulation model increases in size and complexity, communication and interaction between different objects increases. This can lead to a complex maze of references between the objects (blocks). As mentioned by Kuchana (2004) a high degree of referencing affects the maintainability of the application and highly coupled objects greatly reduces the scope for reuse.

The mediator pattern eliminates the complexity arising from objects referring to each other. It forms the basis for the controlled, coordinated communication model for the group of objects. As shown in Figure 9, all the object (blocks) interaction details are abstracted into a separate Simulation (Mediator) class. Every block is still responsible for the intended functionality, but they do not interact with each other directly. The interaction between any two different blocks (such as, Process block sending an entity to Dispose block) is routed through the Simulation (Mediator) class. All the blocks or nodes send their entities or events (respectively) to the Simulation (Mediator) class. The Simulation (Mediator) class then assigns the appropriate entity or event to the corresponding block or node respectively, as per the simulation model requirement.

Figure 9

Mediator pattern applied to the simulation framework.

The resulting software design has the following advantages:

• As all block interactions are managed by the Simulation (Mediator) class, it will be easier to alter the behaviour of the block interrelationships.

• Centralizing the inter block dependencies to the Simulation class results in enhanced object reusability.

• As blocks are less coupled with other blocks, their behaviour/functionality can be easily modified and tested.

5.1. Implementation

Figure 10 shows the message flows among the Simulation, Model, Block, Node, EntityList and EventList classes. The read( ) method of the Model object that is associated with the Simulation class is invoked to read the model from the user. The Model class instantiates the Block and Node classes. The instantiated classes are used to create the process-driven and event-driven models. The process-driven and event-driven models populate the EntityList and EventList through the InsertlnList method. After reading the model, the ManageSimulation( ) method of the Simulation class executes a loop, to process the entities and events, until the end of simulation. In this method, the GetEntity( ) and GetEvent( ) methods read an entity and an event (respectively) from the appropriate list.

Figure 10

Simulation framework: message flow.

The ‘time’ associated with an entity and an event is compared and the element with the earliest time is removed from the corresponding list. The entity or event that is removed from the list is passed as a reference to an appropriate method, that is, process_entity( ) or process_event( ). These methods will transfer control of the entity or event to the process-driven (Block) or event-driven (Node) component where it is handled accordingly.

6. IE ² Simulation framework: user manipulated objects

The contributions of the IE ² simulation framework can only be realized through an effective interface. Past literature on the user interface of discrete event simulation software packages, namely, Kuljis (1996) and Buss and Sanchez (2002), has been considered in this research for their relevancy. Kuljis (1996) discusses essential elements of a user interface in a simulation package. These elements served as guidelines for constructing a prototype user interface for the IE ² simulation framework. Buss and Sanchez (2002) is important background in this regard for its attempt to integrate process-driven and event-driven approaches on the user interface level. Also, this section presents a prototype user interface of the IE ² framework and discusses the importance of the graphical elements.

Kuljis (1996) discusses the features of simulation packages in the context of human-computer interaction. The most relevant features for any simulation environment are model logic representation, model elements, and model validation. The model logic representation is the first step towards making the simulation engine accessible to non-specialists. Secondly, the model elements provide a highly abstracted interface to the simulation engine for the non-expert users. Finally, the model validation aspect of the simulation environment is equally important in debugging and validating the model. The following section focuses on these issues while describing the development of a prototype simulation environment for the Integrated Entity/Event (IE ²) models.

6.1. Model logic representation: Integrated Entity/Event (IE ²) model

As also argued by Odhabi et al (1998), a key motivation of this project is to develop a simulation environment that is accessible and usable by people from outside the core simulation modelling field. As pointed by Schneiderman (1983, 1988), a variety of front-ends to computer systems generally, and simulation modelling environments specifically exist: from command-line interfaces which rely on purely textual interaction through to graphical user interfaces which allow the user to graphically drive, or directly ‘manipulate’ the interaction. Model logic representation serves the objective by providing cognizable simulation objects in the graphical user interface and supporting the novice users through a natural and intuitive process.

Figure 11 shows the set of process blocks, nodes, process connectors, event arc, and event-entity arc that form the model logic elements for the IE ² model. Most of the model logic elements are known to typical simulation modellers, as the graphical representation of the process blocks is similar to many process-driven simulation software packages and event nodes and arcs are similar to the SIGMA environment. Apart from the process blocks and event nodes that are well-known, the main model logic elements that are introduced in the IE ² framework are the EventGraph block and event-entity arc. The EventGraph block provides the event graph workspace, while event-entity arc enables the representation of entities in the event layer.

Figure 11

Process blocks, event node, and connectors supported by the integrated entity/event (IE ²) environment.

6.2. Model logic representation: EventGraph block

Buss and Sanchez (2002) built on the usability of event graphs by giving them the look and feel of a process-driven model through introduction of LEGOs (Listener Event Graph Objects). LEGOs are fundamentally event graphs except that they are encapsulated as atomic components and these components communicate with each other through the listener pattern, a software design pattern (Kuchana, 2004). As shown in Figure 12, the arrival of new entities is modelled using an event graph and this event graph is encapsulated as an independent atomic component. This particular component is named Arrival Process. Another event graph which models a multi-server queue is also encapsulated as an atomic component and it is called Multi-Server Queue. In order for these two components to be coupled to each other, to form a complete queuing model, the listener pattern software architecture is used. A listener pattern loosely connects two objects with one object listening to any changes of the state of the other object. In this case, the Multi-Server Queue listens to any change in the value of the state variable in the Arrival Process object.

Figure 12

Arrival process, multi-server queue, and queue model LEGOS (Buss and Sanchez, 2002.).

The LEGO approach, by Buss et al, enhanced the appeal of event graphs by incorporating the outlook of process-driven models to the event-driven models. However, the LEGO approach has the following disadvantages:

• it only provides the appearance of process-driven models to the event graphs;

• it does not directly support a flow chart or process flow approach or any other approach that represents real-life systems and hence, it not as intuitive as a process-driven model;

• it does not eliminate the necessity of programming style Parameter Passing, while modelling complex logic;

• it requires the use of the listener construct: a concept that has no direct mapping to the real world and requires the modeller to have an abstracted understanding of the simulation environment.

The IE ² model overcomes these issues for widespread adaptation of event graphs in simulation models. It provides hierarchical modelling capabilities with process-driven and event-driven components as the upper and lower layers, respectively. The IE ² model provides an interface for the user to explicitly build process-driven models without translation. Process-driven models created by the user are a collection of appropriate, interconnected process blocks. To hierarchically embed event-driven models within a process-driven model, the IE ² model provides an ‘EventGraph’ block. The ‘EventGraph’ block behaves as a regular process block as well as a workspace for containing an event-driven model. As shown in Figure 4, the IE ² model approach is different from the LEGO approach by explicitly defining the role of process- and event-driven models in the integrated IE ² simulation framework.

The EventGraph block clearly defines the transition of entities into and out of the event-driven model. The entry and exit of an entity in the EventGraph block is managed by the Enter and Exit events as indicated in Figure 4. The model logic representation of the IE ² model is a significant change over the Buss and Sanchez (2002) LEGO approach in actually representing as well as developing a formal relationship between process- and event-driven models. When compared with the LEGO model representation (Figure 12), the IE ² model representation (Figures 13 and 14) is more intuitive. IE ² supports a direct process flow chart approach in modelling as well as represents the flow of entities through different processes and events.

Figure 13

IE ² model representation of multiple server queue.

Figure 14

IE ² model built in the IE ² software.

The following are the advantages of the IE ² simulation environment over the Buss and Sanchez (2002) LEGOs:

• The IE ² environment integrates the process- and event-driven models, rather than just aggregating sections of an event graph.

• The IE ² environment supports the flow chart approach in model representation. This allows modellers to build models that not only represent the model logic but also have model animation that directly maps to the real systems.

• The IE ² environment eliminates the necessity of parameter passing and detailed programming while modelling complex logic.

• IE ² environment is simple in implementation and elegant in design.

7. An example model in the IE ² framework

One of the prominent features of simulation modelling in event graphs is event parameters. In our framework, the role of event parameters in the event graph is replaced by entities in the E ² Event Graph. This change reduces the level of modelling abstraction due to parameter passing at the event graph level, and leads to a more seamless, IE ² model that spans the two levels. This section compares a specific example in traditional event graphs vis-á-vis the same problem in an IE ² model, and explores the level of modelling detail obtained while reducing the level of abstraction.

7.1. The multi-server queue

This model is the IE ² version of the process model shown in Figure 2 and event graph model shown in Figure 1. The IE ²model is shown in Figure 14.

System description: Customers arrive for processing by one of the multiple servers (eg bank tellers) and wait in a first-in-first-out queue. A server is selected at random from the available servers. After processing, the customers leave the bank. The purpose of the model is to track waiting time statistics for individual customers. The simulation clock time is given the name Time. The service time required for a server to process a customer is t _s.

The state variables describing the system are given below,

S::

number of servers available and

Q::

number of customers that are waiting for processing.

Boolean conditions on the scheduling arcs either return true or false:

{bool} ₁::

S>0, Entity Transfer: No

{bool} ₂::

Q>0, Entity Transfer: No

Attributes of the entity (customer) are as follows:

Queue Enter Time::

Time at which customer/entity enters the queue

TimelnQueue::

Waiting time in queue of the customer/entity

Using the symbol (dot) for an entity in the E ² Event Graph, Figure 14 shows an IE ² model of a simple queuing system with multiple servers. The process model primarily consists of three blocks, that is, Create, Delay, EventGraph, and Dispose. The following is a brief description of the functionalities of each block.

Create::

Customer (Entity) creation with inter-arrival time t _a

Delay::

Customer (Entity) is delayed for time t _d

EventGraph::

By default, EventGraph blocks include an Enter event and an Exit event to allow entry and departure of entities. The remainder of the EventGraph block provides a work space for building the event-driven portion of the model

Dispose::

Finished customers/entities exit the model

The event nodes in the EventGraph block are defined as follows:

Enter::

Enter event acts as the gateway for an entity into the event graph model in the EventGraph block. The attributes of the entering entity are available to the event for state changes and for scheduling other events.

Arrive::

Arrive events are always scheduled with an attached entity. The entity object is stored in the queue (Q=Q+1). A Start Event is scheduled when a server is free, QueueEnterTime=Time.

Start::

No entity is attached to a Start event.

An entity (Customer) is retrieved from the queue (Q=Q−1).

One unit of the resource (machine) is made busy and the entity begins the processing (S=S−1).

TimelnQueue=Time − QueueEnterTime.

Finish::

End of the processing for an entity and a unit of resource is freed.

Exit::

Acts as a gateway back into the process model for an entity.

In contrast, the Sigma (standard event graph) implementation of the Multi-Server Queue example discussed here can be implemented by defining an array variable Q[i], QueueEnterTime[i], and TimeInQueue[i]. These variables allow queue times to be computed and tracked. Here i represents the index of an entity in the model. Parameter passing is required in the model to keep track of entity indices. This ‘computer programming’ style of variable definitions and parameters increases the abstraction required for the event-driven simulation modellers. This problem is eliminated in the IE ² model by defining appropriate entity attributes.

Discussion of waiting times of individual entities/customers.

In standard event graphs, attributes of entities in a queue must be stored somewhere. The waiting times of entities could be stored in an array variable (similar to the BANK2.MOD example in the Sigma documentation; Schruben, 1992). To store attributes, the customer ID attribute of an entity can be used as a lookup in the array. To implement this in a standard event graph, edge attributes and event parameters are necessary to implicitly model entity ownership of information. In addition, a number of updating statements to counter-type variables must be added to the model.

In the standard (BANK2.MOD) implementation of event graphs, the modeller is not required to explicitly keep track of entity flow through the events while building a simulation model. The IE ² model approach forces a modeller to think in terms of entities and not in programmer-level abstractions such as parameter passing. At the same time the model-builder is not deprived of the event graph capabilities. On comparing the two models of the same problem in two different simulation environments, one can observe that in an IE ² model, a modeller can reach the same goals without resorting to a ‘programming’ type of approach. This demonstrates the attenuation of abstraction in the IE ² model in comparison with a classical event graph.

8. Conclusion and contributions

In this research, we proposed an integrated simulation framework that combines the process- and event-driven models. These two different models, that is, process- and event-driven, are integrated in the simulation framework as hierarchical layers. The simulation framework is designed to handle the processing of entities and events. A formal relationship among process-driven models, event-driven models and resident entities, like resources and queues, has been established. This formalism enables the models in the integrated simulation framework to be more accurate and elegant by using both process- and event-driven components in a logically consistent way. In an effort to build models that accurately represent real-world structure, this ability is critical.

An important feature of the IE ² model is that it explicitly models the entity flow taking place at the event level. This feature of the E ² Event Graph augments the capabilities of a simulation modeller by making some aspects of process logic available in the event layer. However, the two layers are different when they interact with resident entities like resources, queues, etc. The IE ² framework handles queues and resources for the process- and event-driven models through an intermediate layer. This flexibility provided by the intermediate layer reduces the level of modelling abstraction at the event graph level, and leads to a more seamless, IE ² model that spans the two levels.

The IE ² framework provides a set of basic process blocks namely, Create, Seize, Delay, Release, Dispose, Decision, Batch and Separate for building process-driven models. In addition to that, a sub-model block is also provided for building multiple layers or hierarchical simulation models. These process components were built on the existing simulation framework namely, queues, resources, blocks, etc. The purpose of building the process-driven model components, in an integrated framework, is to augment the capabilities of a modeller.

Comparing a standard process-driven model such as found in Arena (and related technologies like Simio) with an IE ² model, the IE ² model embodies the function of event parameterization through the entity attributes. Entity attributes are a natural construct for modellers familiar with process-based logic. The advantage of using the entity attributes in the IE ² model is that similar model sub-graphs can be combined together as a generic sub-graph distinguished by the attribute values of entities flowing through them. At the event level, entities are handled as objects in a way that is analogous to their treatment in the process models. The attributes of an entity are defined by the modeller, enabling the flexibility and explicit handling of entities at the event level. Instead of passing information as event parameters to other nodes as in a programming language, the IE ² model defines them explicitly as attributes of entities that are associated with events as they are scheduled. This entity passing through the events in the event graph gives the intuitive feel of the process-driven model to the modellers. This modelling of entity flow through the E ² Event Graph enhances the appeal of event graphs to modellers with a process perspective, while retaining the power and flexibility of the event logic. At the process level, the modellers’ ability to model complex logic is enhanced without resorting to programming languages in a simulation model. One of the major objectives of the IE ² model is to diminish the gap between real-world processes and their representation in the simulation environment while not limiting itself to the graphical representation as in most commercially available process-driven simulation tools.

To hierarchically embed event-driven models within a process-driven model, the IE ² model provides an ‘EventGraph’ block. The ‘EventGraph’ block behaves as a regular process block as well as a workspace for containing an event-driven model. As discussed in Section 4.2, the design of the EventGraph block embodies the IE ² approach integrating the event-driven and process driven modelling layers.

In educating future simulation practitioners, the IE ² framework provides a unified environment for training modellers. By integrating both process and event logic coherently, and without resorting overly to a computer programming perspective, environments based on the IE ² framework have the capability to more effectively train a set of potential simulation practitioners from a variety of backgrounds.