Object-oriented event-graph modeling formalism to simulate manufacturing systems in the Industry 4.0 era

Journal Pre-proof

Object-Oriented Event-Graph modeling formalism to simulate manufacturing systems in the Industry 4.0 era Lorenzo Tiacci PII: DOI: Reference:

S1569-190X(19)30158-3 https://doi.org/10.1016/j.simpat.2019.102027 SIMPAT 102027

To appear in:

Simulation Modelling Practice and Theory

Received date: Revised date: Accepted date:

17 July 2019 8 November 2019 18 November 2019

Please cite this article as: Lorenzo Tiacci , Object-Oriented Event-Graph modeling formalism to simulate manufacturing systems in the Industry 4.0 era, Simulation Modelling Practice and Theory (2019), doi: https://doi.org/10.1016/j.simpat.2019.102027

This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2019 Published by Elsevier B.V.

Object-Oriented Event-Graph modeling formalism to simulate manufacturing systems in the Industry 4.0 era Lorenzo Tiacci* Università degli Studi di Perugia - Dipartimento di Ingegneria , Via Duranti, 93 – 06125 – Perugia, Italy

Abstract In the event-based modeling formalism a system is modeled by defining the changes that occur at event times and the system dynamics can be described using an „Event Graph‟. An event graph model is a network of event nodes describing the events that take place in the system and the relationships among these events. In the paper we extend the Event Graph framework by proposing an event-graph modeling formalism suitable to represent discrete event simulation models developed through the object-oriented approach, named Object-Oriented Event Graph (OOEG). The importance of Object–Oriented simulation is recently growing under the Industry 4.0 paradigm, in which optimization via simulation, real-time simulation, automatic decisions systems based on simulation, on line scenario analysis play a relevant role. The OOEG representation provides the same compactness of the EG representation. The advantage of the OOEG representation is that allows supporting a modelling methodology where systems are described by linking components analogously as the system components are linked, and the dynamic of the systems can be visualized in terms of interactions between objects, which have their physical correspondence in the real world. Keywords: discrete event simulation; manufacturing systems; object-oriented simulation; Industry 4.0.

1

Introduction

This paper presents an event-graph modeling formalism suitable to represent discrete events simulation models developed through object-oriented approaches, named Object-Oriented Event Graph (OOEG). A systematic methodology of building the Object-Oriented Event-Graph starting from a reference model of a system is also presented and exemplified. The motivation of the paper is to provide a simple and effective modeling formalism for object-oriented simulation, whose importance is now growing under the Industry 4.0 paradigm. The OOEG modeling formalism presented in the paper is an extension of the Event-Based modeling Formalism. In the Event-Based modeling Formalism, a system is modeled by defining the changes that occur at event times and the system dynamics is described using an Event Graph (EG). Event Graphs are a way of representing the Future Event List logic for a discrete-event model, providing a complete description of a discrete event system in a concise and clear manner [1]. Event Graph models are capable of describing any system that can be implemented on a modern computer. This was demonstrated by [2] by presenting an event graphs model able to simulate a Turing machine. In fact, A Turing machine is a simple mathematical model of a computer, predating the modern computer, which is capable of modeling any computable system, e.g., anything that can be accomplished with digital computers.

*

Corresponding Author: Tel.: +39-075-5853741; fax +39-075-5853743. E-mail address: [email protected] (L.Tiacci). -1-

The aim of this work is to extend the Event Graph modeling formalism in order to represent discrete event systems modeled through an Object-Oriented approach. The Object-Oriented modelling approach allows supporting a modelling methodology where systems are described by linking components analogously as the system components are linked. This modelling language introduces a new modularization of physical knowledge, making a clear separation between the physical behavior reprsentation (declarative knowledge) and the computational aspects of model simulation (procedural knowledge). To model complex systems through Object-Oriented approach allows describing the dynamic of the systems in terms of interactions between objects, which have their physical correspondence in the real world. These characteristics match with the requirements of the new paradigm introduced by Industry 4.0. With the development and dissemination of technologies for universal connectivity, Industry 4.0 is the driving force behind the 4th Industrial revolution. Breakthrough innovations as the global communication network, e.g. Internet, and interconnected intelligent sensors are enabling technologies for production systems [3]. In the “factory of the future”, a central computer coordinates the intelligent networking of all subsystems into a cyber-physical system (CPS), able to work with increasing independence. The term CPS describes the networking of individual embedded software systems that collect and pass on specific data. The close interaction between the physical and virtual worlds here represents a fundamentally new aspect of the production process. When this is related to production, we talk of Cyber-Physical Production Systems (CPPS). The advent of the Industry 4.0 paradigm has consequently brought changes to the simulation modelling paradigm. The Industry 4.0 paradigm requires modelling of manufacturing and other systems via the virtual factory concept and the use of advanced artificial intelligence for process control, which includes autonomous adjustment to the operation systems (self-organization). The new simulation modelling paradigm is best surmised by the concept of “Digital Twin”. The concept of Digital Twin extends the use of simulation modelling to all phases of the product life cycle, where the products are first developed and tested in full detail in a virtual environment, and the subsequent phases use the information generated and gathered by the previous product life cycle phases. Combining the real life data with the simulation models from design enables for example accurate productivity and maintenance predictions based on the realistic data [4]. Following this new paradigm, many engineers rely heavily on model-based design and control of complex cyber-physical systems. Of paramount importance is the ability to capture all central aspects of such systems in the models, including the physical behavior of the system components and the architecture description of its software and hardware. There is a recognized necessity of modelling tools supporting libraries of noncausal models which could be coupled in the same way as physical units are assembled in a system. For this reasons, the importance of Object-Oriented simulation is growing under the Industry 4.0 paradigm. Although well-known in the simulation community, the Event Graphs formalism is not suitable for objectoriented and component-based simulation, where the system state is partitioned in components, which implement their own behavior and interact with each other [5]. Event Graphs describe the changes of state variables when events take place. The utilization of state variables however, when complex systems are modeled, bring to a representation that is not easy to read. The use of an Object-Oriented approach allows to link state variables to objects, making the model more understandable. The contribution of the present work is to propose a graphical representation, derived from the Event Graph modeling formalism, suitable to represent discrete events simulation models developed through objectoriented approaches, named Object-Oriented Event Graph (OOEG). By using the proposed OOEG modeling formalism it is possible to describe in a more readably way the interactions between objects that have their correspondence with physical objects in the real system. The paper is organized as follows. In Section 2 a literary review on related works is presented. In Section 3 basic elements of the Event Graph formalism are resumed. Section 4 is devoted to present the ObjectOriented Event Graph formalism, and to propose a methodology to build a model starting from a reference -2-

model. In Section 5 this methodology is applied to model a manufacturing system (an n-stage tandem line). The OOEG representation is also compared with the analogous EG representation formalism related to the same manufacturing system.

2

Related research

The basic idea of Event Graphs (EGs) was proposed in 1983 by Schruben [6]. In Event Graph models, nodes represent events. These specify the actions (changes in the system state) that are executed when the event occurs. Events are related through transitions, which represent the scheduling of the target event when the source event occurs. Transitions may specify an amount of time and a condition for the target event to be scheduled. There is a simple and well-developed mathematics connected with the syntax and semantics of the formalism [7]. Event Graphs are completely general in their simplest form. As already mentioned, they can model any system that can be simulated with a computer without further extension. For this reason, any model that can be developed with other popular modeling paradigm can also be developed with Event Graphs, as demonstrated by the comparison with process flow diagrams [8], activity-cycle diagrams [9], and Petri nets [10]. Healy [11] advocated the use of the EGs modeling formalism as a vehicle for conveying the underlying structure of discrete event dynamic systems models and their implementation. Buss [12] published a survey on modeling methods of EGs, and discussed three enhancements of the basic Event Graph paradigm: passing attributes to events on scheduling edges, event-canceling edges, and the use of data structures (instead of just simple data types). These enhancements do not increase the formal power of Event Graphs, only their readability, ease of construction, and in some cases the quality of the model itself. Ceylan and Gunal [13] utilized Event Graphs in a two stage methodology for fast development of Discrete Event Simulation (DES) models. In the first stage the modeler builds a Conceptual Model represented as an Event Graph (EG). In the second stage the Conceputal Model is translated to an Event Based DES model. To fulfill this task they developed a DES library, SharpSim, using C# (CSharp) programming language. Event Graphs have been used to model manufacturing systems, such as flat panel display (FPD) production lines [14, 15], applications on Internet, such as World Wide Web (WWW) and File Transfer Protocol (FTP)[16], and to model the business processes of a credit card application [17]. Other EGs templates and examples related to various manufacturing systems can be found in Choi and Kang [1]. Osais [18] presented a framework for assisting in detecting modeling and semantic errors in event graphs. The author outlines the importance of a formalism like event graphs, both for educational and for industrial scopes. In fact, students are being blinded by the commercial simulation tools, and no longer can write a simulation program from scratch in a general-purpose programming language like C, C++, Java, or Python. This skill is becoming nowadays very important in the industrial world, due to the slow speed and unoptimized behavior of commercial simulation tools. One of the main limits of the EGs formalism is that is not suited to object-oriented simulation. The importance of Object-oriented simulation is recently growing under the Industry 4.0 paradigm, in which optimization via simulation plays a relevant role. In fact, coupling of simulation and optimization is actually not always sufficiently ensured to take full advantage of near real-time models, and this represents a great difficulty in the course of the realization of the Digital Twin as an essential precondition of a cyber-physical production systems (CPPS) [19]. If optimization is considered in the setting of simulation, one of the main criticality raises from the need to evaluate a large number of configurations when a solution needs to be identified. Hence, calling the simulator has to be fast. In particular, the set–up times due to the interaction of the simulation with the optimization have to be reduced to the minimum [20]. Adopting an object–oriented paradigm can largely -3-

simplify the development of a simulation model and enable the interaction and integration with the optimization component, by creating objects that the simulation can expose to the optimization in order to be modified [21]. In recent years this approach has been successfully utilized to obtain relevant advances in solving complex industrial problems. For example, the development of an object-oriented simulator [22], coupled to evolutionary algorithm approaches, allowed to find very efficient configurations of asynchronous mixed model lines in the following cases: straight lines with parallel workstations without buffers [23]; straight lines with parallel workstations and buffers between work centers [24]; U-shaped lines [25]; straight lines with parallel workstations and ergonomic constraints [26]. There is only one paper in the literature that addresses the problem of extending the EGs formalism towards the specification of component-based models, and it is the one by De Lara [5]. In that paper, an extension to event graphs is proposed in order to consider the communication of processes via events sent through ports. The author called the new formalism Distributed Event Graphs (DEGs). In this work meta-modelling is used for the definition of DEGs, whereas the operational semantics are given by means of graph transformation. The architecture of DEGs needs the definition of process networks. These have two levels. In the first one (specification level), classes of processes are described. In this level, the author includes port types (input or output) and specifies the allowed connectivity between these ports and the kind of events they can produce and receive. The behaviors for process classes are defined by means of DEGs. In the second level (instance level), processes (instances of some process classes), their pins (instances of ports) and their connectivity are specified. In the present paper we adopt a different approach named OOEG that, avoiding using multi-level process networks and communications via ports, provides a very simple and intuitive representation, maintaining the original characteristics of simplicity and effectiveness. Communication between objects is not performed via ports, but following the classical paradigm of object-oriented languages: objects use messages to communicate with each other and the act of sending a message to an object involves calling one of the object's methods. The difference between DEGs and OOEG formalisms is basically that DEGS is more concerned with component-based simulation, while OOEG is more concerned with object-oriented simulation. While in object-oriented approaches inheritance and overloading are the primary mechanisms for implementing polymorphism, component-based design prefers to utilize an approach based on establishing common interfaces between components [27]. Component-based design can be convenient when very complex and heterogeneous systems have to be modeled and replaceability of components is strictly needed. Its disadvantage consists in requiring a much more complicated architecture and, in turn, a much more complicated graphical representation of the simulation model. In this view, the advantage of the objectoriented approach adopted by the OOEG formalism is the ability to represent simulation models that are easily readable and understandable, providing at the same time the sufficient degree of abstraction required to model even complex manufacturing systems.

3 3.1

Event Graphs Models Basics of Event Graphs Models

We assume the reader is familiar with the basic concepts of discrete event simulation. A discrete event system is a system whose state is characterized by a number of state variables that change instantaneously at discrete points in time. The state of the system is representable by a vector variable s. The state changes depend entirely on the occurrence of discrete events over time. Each time an event occurs, a corresponding event routine is executed. An event routine fE(s) is a set of actions invoked by the occurrence of the originating event E, which cause the state change s = fE(s). -4-

The fundamental event-graph construct is depicted in Figure 1: the occurrence of Event A causes the state of the system to change accordingly to the event routine fA, and then causes Event B to be scheduled after a time delay of t, providing condition (i) is true. Thus, the basic Event Graph paradigm contains only two elements: event node and scheduling edge with two options on the edges (time delay and edge condition).

(i) A

B

t

{s = fA(s)}

{s = fB(s)}

Figure 1: Event graph with a scheduling edge. There is another type of edge, namely the canceling edge (Figure 2). The event graph depicted in the figure indicates that whenever the originating event C occurs, the state s changes to fC(s). Then, if the edge condition j is true, the scheduled event D is canceled immediately.

C

D

{s = fC(s)}

{s = fD(s)}

Figure 2: Event graph with a cancelling edge.

3.1.1 Event transition table and Event Routines Each originating event is specified using five data fields: state change, edge condition, action type (schedule or cancel), time delay, and destination event. Thus, an event graph model can be systematically specified by using an event transition table, in which these five fields are specified for each event node. Figure 4 shows the event transition table related to the event graph depicted in Figure 3.

C

(cond2) t2 (cond1)

A

B

t1

{s = fA(s)} -5-

Figure 3: An Event graph with two scheduling edges. Originating Event State Change Edge Condition A

s = f(s )

Action

Delay

Des tination Event

1

cond1

s chuedule

t1

B

2

cond2

s chuedule

t2

C

Figure 4: The Event transition table representing the Event Graph of Figure 3Figure 1. An event routing is a subprogram describing the changes in state variables and how the next events are scheduled or cancelled for an originating event in the event transition table. One event routine is required for each event in an event graph. The event routine for the A event in example can be expressed through pseudocode as follows:

Event A routine { s=fA(s); // state change If (cond1) schedule-event (B, now+t1); If (cond2) schedule-event (C, now+t2);}

Figure 5: The event routine associated to the Event Graph of Figure 3Figure 1.

3.2

Parametrized Event Graph Modeling

A breakthrough improvement of the ordinary event graph framework is the parameterization of event vertices in which similar events are represented by a single vertex with different parameter values, and in which an event node has the capability to pass attributes on an event scheduling edge to the scheduled event. Figure 6 shows the basic construction of a parametrized event graph: when event A occurs, the state of the system changes accordingly to the event routine associated to event A, and expression (k) and condition (i) are evaluated. If condition (i) is true, then event B is scheduled to occur after a delay of t time units with parameter j set equal to the computed value of k. Note that k could be a parameter list.

(i) A

B(j)

k t

Figure 6: Parameterized event graph. The parameterized event graph allows, by introducing the indexing variable j, to build models by repeating pattern of event vertices, and by introducing the indexing variable k, to pass attribute values of each entity along event vertices.

4

Object-Oriented Event Graph Modeling

In object-oriented simulation a system is considered to consist of objects (e.g. an entity or a server) that interact with each other as the simulation evolves. Objects contain data and have methods; data describe the state of an object at a particular point in time, while methods describe the actions that the object is capable of performing. The Object-Oriented Event Graph (OOEG) modeling paradigm is based on three components: 1. The UML Physical Class Diagram (PCD) -6-

2. The UML Event Class Diagram (ECD) 3. The Object-oriented Event Graph (OOEG)

4.1

The UML Physical Class Diagram (PCD)

The object oriented paradigm allows a better understanding of the system, in terms of entities and resources that compose the system. An OO system is designed and implemented as a simulation of the real world using software artifacts. This premise is as powerful as it is simple. UML models make good abstractions of the physical world. The UML Physical Class Diagram shows the parallel between the simulation model and the underlying physical/enterprise system. The system‟s software objects should parallel the enterprises‟s business object (actual, tangible things that the software objects represent). The advantage of such a representation is that all these objects are useful, can be recognized, have structure, and have behavior. Of course, additional software objects may be necessary parts of the design and implementation of an objectoriented software system, even though they have not a physical parallel in the business system. These are the constructions elements of the object-oriented software world. For example, queues or records may be modeled through objects, although they may have not a physical parallel in the system. Although they can be intangible, they too have identity, structure, and behavior, and are included in the Physical Class Diagram, because they belong to the enterprise/business level. Depending on the complexity of the system, the phase consisting in building the UML PCD can be divided in building one top level diagram, with up to 15 key classes. If necessary, it is possible to build second-level diagrams with one of the key classes in the center of the diagram, surrounded by 5 to 10 supporting classes and their association with the key class. If even second-level diagrams are too complex with more than 10 supporting classes, a third level of class diagram can be created, and so on. For reading convenience basics of UML Class diagrams are provided in Appendix A.

4.2

The UML Event Class Diagram (ECD)

In the proposed object-oriented event graph paradigm, an event is an object itself, and is an instance of a class implemented from the abstract class Event. The class Event provides the facilities for creating and scheduling events in the simulation. Each type of event must be defined by extending the class Event. Thus, each type of event has to be defined as a subclass of the class Event, and has to provide an implementation of the method actions() (the equivalent of the event routine) which is executed when an event of that type occurs. The instances of these subclasses are the actual events. This architecture can be visualized through the UML Event Class Diagram (ECD). Figure 7 shows the ECD related to two events, EventA and EventB. The two classes are associated to some of the classes describing the physical system. In the example depicted in the Figure 7, EventA is associated to Class X, while EventB is associated to Class Y. Classes X and Y are two classes introduced in the Physical Class Diagram (PCD), i.e. they represent parallel concepts at the business/enterprises level. In fact, the instances of a Class, related to the physical system, may be involved, during their life cycle, in a certain type of event (i.e. the instance triggers the event, or the event routine makes changes in the state of the instance). It is convenient to consider the corresponding event as an attribute of the corresponding Class, so that the same event can be rescheduled without the need to create a new event. In this way one can avoid creating a new instance of an Event Class every time the event has to be scheduled. Furthermore, when the event routine is executed, a reference to the object associated to the event is directly available.

-7-

Figure 7: UML Event Class Diagram (ECD) associated to the event graph depicted in Figure 8.

4.3

The Object-oriented Event Graph (OOEG)

The PCD and ECD provide only static relations among classes. In order to describe the dynamic of the system, that is, how the system evolves, we introduce the Object Oriented Event Graph, which is a version of the Event Graph formalism particularly suited for object-oriented simulation. The Object Oriented Event Graph, depicted in Figure 8, consists of the same basic elements of the Event Graph formalism: event nodes, scheduling edges and options on the edges (time delay and edge condition). The difference is that, in OOEG, EventA and EventB are two different event types related to two different subclasses of the Event class, as illustrated in the corresponding Event Class Diagram (Figure 7). Associated to each one of the two Event Classes there are two Classes (Class X and Class Y), related to the business/enterprises level, and introduced in the PCD. When EventA occurs, the state of the system changes accordingly to the event routine described in the actions() method of EventA. If condition (i) is true, then EventB related to an instance k of Class Y is scheduled to occur after a delay of t time units.

(i) EventA

EventB

Instance k

(Class X)

(Class Y)

t Figure 8: Object-oriented Event Graph (OOEG) In this way, the „expression k‟ and the „parameter j‟, that have been utilized in the parametrized event graph modeling (see Section 3.2) to provide the capability of represent similar events by a single vertex, are respectively substituted by „an instance k‟ of the „Class Y‟. In this way the OOEG formalism provides the same parametrization ability of the parametrized event graph formalism, but extended to object-oriented simulation models: similar events involves objects of similar type, and thus can be represented by a single node.

5

Modeling a n-stage tandem line

In this section we describe how to model an n-stage tandem line using Object Oriented Event Graph modeling. Figure 9.a shows the reference model of such a system, taken from [1]. The line is composed by a series of n ordered stations. We refer with the term job to the physical entities that go through the line: a job -8-

is generated by an unlimited source, following an interarrival time (ta). The job has to visit each station of the line in the given order. In each station, a machine performs a task on the job, with an associated completion time. Between each station of the line there is a buffer of limited capacity. Thus, a finished job may not be unloaded from the machine when the buffer is full. This situation is referred to as blocking. Figure 9.b and Figure 9.c show respectively the event graph model and the parametrized event graph model of the n-stage tandem line. The events used to describe the dynamic of the systems are: Arrive, that occurs when a new job is created; Enter, occurring when a job enters the buffer of a station; Load, occurring when a job is loaded on a machine and starts to be processed; Finish, occurring when the machine finish its processing on the job; Unload, occurring when a job is unloaded and frees the machine where it has been processed. The state variables used are: Q[k], the number of jobs in the buffer of station k; M[k] the state variable of the machine in station k, busy = 0, idle = 1; B[k] a „blocking‟ variable introduced to control the blocking of the machine in station k, unblocked = 0, blocked = 1. The main advantage of such a representation is its extreme compactness. There may be cases, when the complexity of the system increases, where state change functions, which are usually reported between brackets underneath each event node, could be composed by many instructions. In these cases it is convenient to report them separately using event transition tables and/or event routines (see Section 3.1.1). Another advantage is that the description of the dynamic of the system, which is described by specifying the events that causes state changes and how and when these events are scheduled and rescheduled, is very effective. The main limit of such a representation is the lack of correspondence between the model depicted through the event graph and the real system. Entities and resources of the system are not visible, and any information about the physical architecture of the real system is missing. Furthermore, the state variables introduced are not self-explaining. This lack of correspondence between the event graph representation and the real system makes this representation difficult to read, and not very flexible. For example, being the relations among entities and resources not visible, it is difficult to insert new entities/resources that interact with each-other. In the following we show how by applying Object-Oriented Event Graph Modeling for the n-stage tandem line it is possible to overcome the above mentioned limit while maintaining the advantages of the event graph representation (compactness and effectiveness in describing the dynamic of the system). With respect to the reference model above described, we add a new feature: a station may be composed of parallel machines working in parallel, i.e., each station is composed by either one machine, for the case of non-paralleling, or multiple parallel machines.

-9-

a. Reference model.

b. Event graph model.

c. Parameterized event graph model.

Figure 9: Models of the n-stage tandem line [1].

5.1

Building the model

The main steps of the procedure are the followings: 1. Identify classes that describe the physical system and report their static relations in an UML class diagram (the Physical Class Diagram, PCD). 2. Identify Event Classes describing the dynamic of the physical system, and show inheritance hierarchy on a separate UML diagram (the Event Class Diagram, ECD) 3. Associate classes describing the physical systems to Event Classes in the ECD. 4. Define the Object Oriented Event Graph (OOEG). 5. Update the UML class diagram related to physical classes 6. Define the event routines of each event. 7. Define attributes and methods of the remaining Classes. 5.1.1 Identify Classes that describe the physical system and their static relations. The physical system can be described in a hierarchical way. The whole system can be described as a line, which is composed by a series of stations. Each station can be formed by one or more machines. Another physical element of the system is the job, i.e. the item processed throughout the stations. Thus, the physical system can be described through 4 classes: Line, Station, Machine, Job. The static relations among these classes that describe the physical system are individuated, and are represented through an UML class diagram, that we will indicate with the term Physical Class Diagram (PCD) (see Figure 10). As the composition indicates, a line is composed by 1 or more stations, which in turns are composed by 1 or more machines. We also indicate a generic association between Machine and Load, indicating that a machine processes an indefinite number of loads. - 10 -

Figure 10: The top-level diagram that describes the physical system (PCD, Physical Class Diagram). 5.1.2

Identify Event Classes describing the dynamic of the physical system, and show inheritance hierarchy on a separate UML diagram In this phase the events that characterize the dynamic behavior of the system are individuated, and for each event a Class that extends the abstract Class Event is created. The inheritance hierarchy between the abstract class Event and the event classes that have been created is reported on a separate UML class diagram. We will refer to this UML diagram as „Event Class Diagram‟ (ECD) (see Figure 11). Four events, describing the dynamics of the systems, are individuated:  Passing Event, it happens when a job moves from a station to the successive one  StartProcessing Event, it happens every time a station starts processing a job in one of its machine  FinishProcessing Event, it happens when a job has completed to be processed in a station;  CreateJob Event, it happens when a new job enter the line; Note that, with respect to the parametrized event graph model depicted in Figure 9.c, the following equivalence can be observed: Passing = Unload + Enter; CreateJob = Arrive; StartProcessing = Load; FinishProcessing = Finish. 5.1.3 Associate classes describing the physical systems to Event Classes. In the Event Class Diagram, the Event Classes that have been created are associated to some of the classes describing the physical system. An instance of a Class, related to the physical system, may be involved, during its life cycle, in a certain type of event (i.e. the instance triggers the event, or the event routine makes changes in the state of the instance). The association of event classes to classes describing the physical system is outlined in the Event Class Diagram. In Figure 11, the StartProcessing Event is associated to the Class Station, with cardinality 1 to 1. This means that for each Station object there is an associated StartProcessingEvent object. A Station object contains a reference to its StartProcessingEvent in the form of an attribute, and symmetrically a StartProcessingEvent object contains a reference to its Station object. Figure 11 also shows that the Passing Event and FinishProcessing Event Classes are associated to the Job Class, and that the CreateJobEvent Class is associated to the Line Class.

- 11 -

Figure 11: The Event Class Diagram (ECD) 5.1.4

Draw the Object Oriented Event Graph.

When we draw the object oriented event graph (OOEG) of our simulation model, we graphically define that part of each event routines related to scheduling other events. Passing event The Passing event takes place when a job passes from a station to the next one. Considering the case in which each station has a buffer, when the passing event takes place the job enters the buffer of the generic station i, leaving station i-1. We will refer to the station the job is entering as the current station, and to the station the job is leaving as the previous station (see Figure 12). Previous Station

Current Station

Station i-1

Buffer i-1

Next Station

Station i

Buffer i

Station i+1

Buffer i+1

Figure 12: Three consecutive stations.

- 12 -

When the Passing event takes place, it potentially triggers the startProcessing event both of the previous and of the current station (see Figure 13). Let see why. The station the job is entering (the current station) could be waiting for a job. Thus, by entering the buffer of the current station, the startProcessing event of the current station has to be scheduled, provided that the current station is ready to start processing the job. There can be many conditions that determine if a station is ready to work. In this case for example, the station may be not ready because all its machines are busy, as they are still finishing processing other jobs. For the moment, we introduce a method in the Class Station, named readyToStart(), which returns a boolean value indicating if the station can or cannot start processing the job. At the same time, when the job leaves the previous station, one machine is released. Because a machine in the previous station is now idle, if the previous station is ready to start processing another job, the startProcessing event related to the previousStation has to be scheduled. In this case the previous station may not be ready because there is not any job that has claimed to be processed. In general, two are the conditions for a station to start processing a job: - at least one of its machines is idle; - there is at least a job that has claimed to be processed, i.e. the waitingToBeProcessed List is not empty. In the object oriented event graph (OOEG) model, this dynamic can be represent trough two oriented arc from the passing event to the startProcessing event, one associated to the prevStation instance of the class Station, and the other associated to the currStation instance of the class Station. These events are scheduled under the condition that the method readyToStart() returns true.

passing (Job)

currStation

prevStation

readyToStart()

readyToStart()

start Processing (Station)

Figure 13: Drawing the OOEG by inserting the event triggered by the passing event. In order to schedule the StartProcessing event related to the previous and the current Station, we have to provide the Class Job with a reference to the objects representing the previous and the current station. We do this by adding two attributes of type Station, named respectively prevStation and currStation, to the Job Class. In summary: - a new attribute, named prevStation of type Station, is added to the Class Job; - a new attribute, named currStation of type Station, is added to the Class Job; - a new method, named readyToStart() of type boolean, is added to the Class Station; The Physical Class Diagram is consequently updated (see Figure 10). Start Processing event The StartProcessing event related to an instance of the Class Station happens each time the station starts processing a job in one of its machines. When the startProcessing event takes place, the finishProcessing event related to the job that is starting to be processed has to be scheduled to occur after a delay equal to the processing time of the job (see Figure 14). Thus, we need a reference to the job that is starting to be - 13 -

processed; at this aim we introduce a new attribute named startWorkingJob, of type Job, at the Class Station. This reference has to be updated each time the startProcessing event takes place. The processing time of the job may depend in general from many factors such as the model type, or other operational conditions related to the station or the machine that is working on the job. To generalize this concept, we introduce a method in the Class Job named calcProcessingTime(), of type double, which returns the processing time for the job that is being processed. Thus, the finishProcessing event related to startWorkingJob Job, is scheduled to occur after a delay of the value returned by the method calcProcessingTime(). In summary: - a new attribute, named startWorkingJob of type Job, is added to the Class Station; - a new method, named calcProcessingTime() of type double, is added to the Class Job; The Physical Class Diagram is consequently updated (see Figure 10).

passing (Job)

currStation

prevStation

readyToStart()

readyToStart()

finish Processing (Job)

start Processing (Station)

calcProcessingTime()

startWorkingJob

Figure 14: Drawing the OOEG by inserting the event triggered by the startProcessing event. Finish Processing event When the finishProcessing event takes place, the job has finished to be processed in the current station. If the next station has the place to receive the job (in the buffer or directly in one of its machines), the job passes to the next station. To verify that the next station has place to receive the job, we can use a method of the class Station named hasPlace(), of type Boolean, that returns true if condition is met. Furthermore, we have to provide the Class Job with a reference to the object representing the next station, so an attribute named nextStation, of type Station, is added to the class Job. Each time the passing event takes place, this reference has to be updated. Thus, the passing event, associated to job that has been processed, has to be scheduled to occur at the current time, provided that method hasPlace() of the instance nextStation returns true (see Figure 15). In summary: - a new attribute, named nextStation of type Station, is added to the Class Job; - a new method, named hasSpace() of type boolean, is added to the Class Station. The Physical Class Diagram is consequently updated (see Figure 10).

- 14 -

nextStation.hasSpace()

passing (Job)

currStation

prevStation

finish Processing (Job)

readyToStart()

readyToStart()

start Processing (Station)

calcProcessingTime()

startWorkingJob

Figure 15: Drawing the OOEG by inserting the event triggered by the finishProcessing event. Jobs creation The Create job Event is associated to the Line Class with multiplicity 1..1. Let be myLine the instance of the Class Line. The instance myLine has as attribute an instance of CreateJobEvent, named CreateJob. This event is scheduled each time a new object of the Job Class has to be created. In our system, jobs arrive following an interarrival time, that can be considered a characteristic of the line. We thus introduce an attribute in the class Line named interarrivalTime (type double). Each time a new job is created, the createJob event schedules again the createJob event itself to occur after a delay of myLine.interarrivalTime time units (see Figure 16). To link the createJob event to the ECD depicted in Figure 15, we can introduce a virtual station, named dummyStation, which is a virtual station that precedes the first station in the line. When a job is created, the job is in the dummy station. By simply scheduling the passing event associated to the new job (see Figure 16), the new job will pass from the dummy station to the first station of the line. myLine nextStation.hasSpace() myLine.interArrivalTime

createJob (Line)

passing

newJob

(Job)

currStation

prevStation

readyToStart()

readyToStart()

finish Processing (Job)

start Processing (Station)

calcProcessingTime()

startWorkingJob

Figure 16: The object oriented event graph model of the n-stage tandem line. - 15 -

The diagram depicted helps to complete the definition of the classes that have been introduced in terms of attributes and methods. In summary: - a new attribute, named newJob, of type Job, has to be added to the Class Line; - a new attribute, named interarrivalTime of type double, has to be added to the Class Line; - a new attribute, named dummyStation, of type Station, has to be added to the Class Line. It is thus possible to update the Physical Class Diagram in the following way:

Figure 17: The updated Physical Class Diagram. 5.1.5 Define the event routines of each event. The updated Physical Class Diagram (PCD) (Figure 17) and the Event Class Diagram (ECD) (Figure 11) provide the necessary information to read and understand the object oriented event graph model (OOEG) depicted in Figure 16. At this stage, the top level architecture (PCD+ECD+OOEG) of the simulation model has been built. However, in order to describe in detail the event routines of each Event, and in general the operations of the classes, the utilization of a specific language or, alternatively, of pseudocode is needed. In the following, we describe the implementation of the model using a specific language, Java. This allows providing an executable model. We also utilized a package for discrete event simulation in Java, named SSJ, which stands for Stochastic Simulation in Java [28, 29]. SSJ is not the only Java-based simulation framework. Others frameworks are for instance Silk [30, 31] and Simkit [27]. Every object-oriented framework that provides the event-based view could be used to implement an executable model from an OOEG model. SSJ is an organized set of software tools offering general-purpose facilities for stochastic simulation programming in Java. It supports the event view, process view, continuous simulation, and arbitrary mixtures of these. SSJ provides two basic classes: the abstract class Event, and a static class named Sim that contains the executive of a discrete-event simulation The class Event provides the facilities for creating and scheduling events in the simulation. Each type of event must be defined by extending the class Event, as described in Section 4.2. This abstract class provides event scheduling tools. Each type of event, which is defined as a subclass of the class Event, should provide - 16 -

an implementation of the method actions() which is executed when an event of this type occurs. The instances of these subclasses are the actual events. When an event is constructed, it is not scheduled. It must be scheduled separately by calling one of the scheduling methods schedule(), scheduleNext(), scheduleBefore(). The static class Sim maintains the simulation clock and starts executing the events in the appropriate order. Its methods permit one to start, stop, and (re)initialize the simulation, and read the simulation clock. For reading convenience the methods of these two classes are summarized in the following. public abstract class Event Constructor Summary 

Public Event() Constructs a new event instance, which can be placed afterwards into the event list.

Method Summary    



  

 

abstract void actions() This is the method that is executed when this event occurs. boolean cancel() Cancels this event before it occurs. static boolean cancel(String type) Finds the first occurence of an event of class ``type'' in the event list, and cancels it. void reschedule(double delay) Cancels this event and reschedules it to happen in delay time units. void schedule(double delay) Schedules this event to happen in delay time units, i.e., at time Sim.time() + delay, by inserting it in the event list. void scheduleAfter(Event other) Schedules this event to happen just after, and at the same time, as the event other. void scheduleBefore(Event other) Schedules this event to happen just before, and at the same time, as the event other. void scheduleNext() Schedules this event as the first event in the event list, to be executed at the current time (as the next event). double setTime(double time) Sets the (planned) time of occurence of this event to time. double time() Returns the (planned) time of occurence of this event.

public final class Sim Method Summary  

 



static EventList getEventList() Gets the currently used event list. static void init() Reinitializes the simulation executive by clearing up the event list, and resetting the simulation clock to zero. static void init(EventList evlist) Same as init, but also chooses evlist as the event list to be used. static Event removeFirstEvent() This method is used by the package simprocs; it should not be used directly by a simulation program. static void start() Starts the simulation executive.



static void stop() Tells the simulation executive to stop as soon as it takes control, and to return control to the program that called start.



static double time() Returns the current value of the simulation clock.

- 17 -

Passing The code related to the actions() method of the PassingEvent Class is reported in Figure 18. When the job leaves a station, one machine of that station is released. To model machine releasing, we add a new attribute, named idle, of type boolean, to the Class Machine. We also introduce a method in the Class Job, named releaseMachine(), of type void, and an attribute of type LinkedList, named idleMachines, to the Class Station. The method releaseMachine() adds a machine to the list of idle machines (idleMachines) of the current station. Thus, the first instruction of the action method of the PassingEvent Class, it is a call to the releaseMachine() method of the job: myJob.releaseMachine(). Then the reference to the previous, current and next stations of the job have to be updated. To this aim, we introduce a method in the class Job, named updateStationReference(). The next instruction is: myJob.updateStationReference(). The job, by entering the buffer of the current station, claims to be processed by one of its machine. We realize this by introducing a queue, that can be implemented through a LinkedList, named waitingToBeProcessed, which is an attribute of the Class Station. The next instruction adds the job to the waitingToBeProcessed list of the current station: myJob.currStation.waitingToBeProcessed.add(myJob). Then the two scheduling actions of the startProcessing event, represented through the two directed arcs in Figure 13, are implemented: if the previous station is ready to work (if (myJob.prevStation.readyToStart())), its startProcessing event is scheduled to occur at current time (myJob.prevStation.startProcessing.scheduleNext()). If the current station is ready to work (if (myJob.currStation.readyToStart())), its startProcessing event is scheduled to occur at current time (myJob.currStation.startProcessing.scheduleNext()). The method readyToStart() returns true if both the list of idle machines and the list of loads waiting to be processed of the station are not empty. public class PassingEvent extends Event{ Job myJob; @Override public void actions() { myJob.releaseMachine(); myJob.updateStationReference(); myJob.currStation.waitingToBeProcessed.add(myJob); if (myJob.prevStation.readyToStart()){ myJob.prevStation.startProcessing.scheduleNext(); } if (myJob.currStation.readyToStart()){ myJob.currStation.startProcessing.scheduleNext(); } } //constructor// public PassingEvent(Job myJob) { this.myJob = myJob; } }

Figure 18: The code related to the PassingEvent Class. The attributes and methods introduced in this step are summarized in the following: - a new method, named releaseMachine(), of type void, is added to the Class Job; - a new method, named updateStationReference(), of type void, is added to the Class Job; - a new attribute, named waitingToBeProcessed, of type List, is added to the Class Station. - a new attribute, named idleMachines, of type List, is added to the Class Station; The Physical Class Diagram is consequently updated (see Figure 22). - 18 -

StartProcessing The code related to the actions() method of the StartProcessingEvent Class is reported in Figure 19. When the startProcessing event related to a station takes place, a job is removed from the queue of the jobs that is waiting to be processed in the station. The instruction: myStation.startWorkingJob = (Job)myStation.waitingToBeProcessed.remove(0)

removes the first job (whose index is 0) from the waitingToBeProcessed List, and returns a reference to the job that is starting to be processed. We add an attribute named startWorkingJob, of type Job, to the Station Class, to which this reference is assigned. At the same time, the job seizes one of the machines in the station. This is performed by a new method, named seizeMachine(), of type void, added to the Class Job. This method removes a machine from the list of idle machines of the current station. Then, the processing time is calculated: double procTime = myStation.startWorkingJob.calcProcessingTime();

and the finishProcessing event related to startWorkingJob is scheduled to occur after a delay equal to the processing time: myStation.startWorkingJob.finishProcessing.schedule(procTime); public class StartProcessingEvent extends Event{ Station myStation; @Override public void actions() { myStation.startWorkingJob = (Job)myStation.waitingToBeProcessed.remove(0); myStation.startWorkingJob.seizeMachine(); double procTime = myStation.startWorkingJob.calcProcessingTime(); myStation.startWorkingJob.finishProcessing.schedule(procTime); } //constructor// public StartProcessingEvent(Station myStation) { this.myStation = myStation; } }

Figure 19: The code related to the StartProcessingEvent Class. The attributes and methods introduced in this step are summarized in the following: - a new method, named sizeMachine(), of type void, is added to the Class Job; The Physical Class Diagram is consequently updated (see Figure 22). FinishProcessing The code related to the actions() method of the FinishProcessingEvent Class is reported in Figure 20. It just consists in scheduling the passing event of the job to occur at current time, if the next station has space (in the buffer of directly in one of its machine): if (myJob.nextStation.hasSpace()) myJob.passing.scheduleNext();

- 19 -

The method hasSpace() returns true if there is at least one machine in the idleMachines List of the Station, or if the number of jobs in the waitingToBeProcessed List of the station is lower than the buffer size of the station. The attributes and methods introduced in this step are summarized in the following: - a new attribute, named bufferSize, of type int, is added to the Class Station; The Physical Class Diagram is consequently updated (see Figure 22). class FinishProcessingEvent extends Event { Job myJob; @Override public void actions() { if (myJob.nextStation.hasSpace()) { myJob.passing.scheduleNext(); } } //constructor public FinishProcessingEvent(Job myJob) { this.myJob = myJob; } }

Figure 20: The code related to the FinishProcessingEvent Class. CreateJob This event is scheduled each time a new object of the Job Class has to be created. In our system, jobs arrive following an interarrival time. Each time a new job is created, it is passed from the dummyStation to the first station of the line by scheduling its passing event (newJob.passing.scheduleNext()). The createJob event schedules again the createJob event itself to occur after a delay of myLine.interarrivalTime time units. public class CreateJobEvent extends Event{ Line myLine; @Override public void actions() { myLine.createJob.schedule(myLine.interarrivalTime); myLine.createJob.schedule(myLine.interarrivalTime); } //constructor// public CreateJobEvent(Line myLine) { this.myLine = myLine; } }

Figure 21: The code related to the CreateJobEvent Class

- 20 -

Figure 22: The complete Physical Class Diagram.

5.1.6 Define attributes and methods of the remaining Classes. Appendix B shows the complete code related to the remaining Classes, i.e. Classes defined in the Physical Class Diagram. Constructors of each Class allow the initialization of the system and the creation of objects composing the physical system. The code related to methods introduced in the preceeding steps are completed. In details: methods updateStationReference(), releaseMachine(), seizeMachine() of the Class Job, and methods readyToStart() and hasSpace() of the Class Station.

6

Simulation

This section shows how to implement and execute a simulation model related to the two examples described in Section 5: an n-stage tandem line with limited buffers modelled through the EG formalism (Figure 9) and a n-stage tandem line with limited buffers and parallel machines modelled through the OOEG formalism (Figure 16).

6.1

Implementing and executing an EG through SIGMA

The reference model of this example is a 4 stage tandem line, with interarrival time equal to 10 seconds, and processing times equal to 20, 11, 9 and 31 seconds respectively for machines 1, 2, 3 and 4. There are buffers

- 21 -

with limited capacity between machines (no buffer is needed before the first machine), with capacity equal to 3, 1 and 1 respectively for buffers before machines 2, 3 and 4 (see Figure 23).

Machine

Machine

Machine

Machine

1

2

3

4

3

1

1

Buffer size

Figure 23: The reference model of a 4 stage tandem line with limited buffers. In this section we show how to implement and execute a simulation model developed through the EG modeling formalism using SIGMA. SIGMA is an event based simulation language developed and widely used for modeling various types of DES[33]. An event graph simulator can also be developed, starting from the primitive functions for handling events and managing queues, through general-purpose programming languages. An example on how to implement such a simulator can be found in [1]. SIGMA, which stands for Simulation Graphical Modeling and Analysis system, is based on the Event Graph approach to simulation. It provides a visual approach to build a simulation model starting from an EG representation of the model. The general procedure for building and executing a SIGMA program for simulation is as follows. 1. Create a SIGMA-generated Event Graph 2. Declare all variables 3. Define the Run vertex 4. Define the Event vertices 5. Define the Edges 6. Specify Run Options 7. Execute the model In the next steps, we limit our description of the necessary features of SIGMA needed to implement and execute our model. A complete tutorial and on-line manual of SIGMA is available at [32]. Step.1 Create a SIGMA-generated event graph The default mode for the mouse in SIGMA is the Create Process mode. This mode allows creating a connected chain of events simply by moving the mouse and clicking in various locations within the simulation graph window. Figure 24 shows the SIGMA-generated Event Graph, composed by 6 nodes and 9 edges, built starting from the EG depicted in Figure 9. With respect to the standard Event Graph, the SIGMA-generated Event Graph has one more edge, named Run, that serves to initialize state variables and defining running options for the simulation (see Step3 and Step6). The Run vertex is connected through an edge to the first event (Arrive) of the corresponding EG.

- 22 -

Figure 24: The Sigma-generated event graph of an n-stage tandem line Step2. Declare all variables The Variables menu is used to define and edit the state variables of the simulation (see Figure 25). These variables can be used in any expression, anywhere in the SIGMA model. All state variables in a SIGMA simulation must be defined before a SIGMA model will run. Variables whose size is higher than 1 corresponds to arrays. In our model, variable Q[] is represented through an array of size 6. Q[1], Q[2], Q[3], Q[4] correspond to the queue length before the corresponding machine. Q[0] and Q[5] are virtual queues that allow not incurring in „out of index‟ errors when the parametrized model is executed. Similarly, the variable C is an array of size 6, where C[1], C[2], C[3], C[4] correspond to the buffer capacity before the corresponding machine, while C[0] and C[5] have the same function of Q[0] and Q[5]. Variable M[] is also an array, of size 5. M[1], M[2], M[3], M[4] represent the machine status of machines 14 (busy = 0, idle = 1;), while M[0] is a variable not utilized in the model for simplicity, in order to use the same parameter value of the corresponding variables Q and C.

Figure 25: The state variable editor. Step 3. Define the Run vertex A Run event is defined to initialize the state variables. By clicking the first vertex of the SIGMA event graph (named Run), the dialog box Edit Vertex 1 is created (see Figure 26). Here the variables Q[], M[] and B[], are initialized, while variables containing constant values are entered in the parameters field of the Run vertex dialog box (T[] ,C[], K, N, TARR, Q[N+1], C[N+1]). The values of these variable will be later specified in the Run Options dialog box (see Step 6). In our example, we initialize the model assuming that queues are empty (Q[1]= Q[2]= Q[3]= Q[4]= 0), machines are all idle (M[1]= M[2]= M[3]= M[4]= 1) and not blocked (B[1]= B[2]= B[3]= B[4]= 0).

- 23 -

Figure 26: Editing the Run vertex. Step 4. Define the Event vertexes Changes in the values of state variables occur only when a vertex is executed. Formulas for the state changes associated with a particular vertex are entered using an Edit Vertex dialog box, which is displayed when the mouse is double-clicked on a particular vertex. Figure 27 shows the Edit Vertex dialog box related to the Enter Event. The state change Q[K]=Q[K]+1 is entered in State Change field of the dialog box, while the variable K is entered in the Parameter field. The other Event vertexes are defined analogously.

Figure 27: Editing the vertex related to the Enter event. Step 5. Define the Edges Edges connect pairs of vertices in a simulation graph and define how one event may cause (or prevent) the occurrence of another event. There can be multiple edges between any pair of vertices in the model. Information concerning an edge can be found in its dialog box. Figure 28 shows the Edit Edge dialog box related to the edge going from the Finish to the Unload event. The variable K, utilized in the parameterized event graph, is entered in the Attributes field of dialog box. In this example, every time the Finish event takes place, the Unload event is scheduled to happen at current time (i.e. with a delay equal to 0), provided that condition Q[K+1] < C[K+1] is true. The other Edges are defined analogously. - 24 -

Figure 28: Editing the edge connecting the Finish and Unload events. Step.6 Specify Run Options In the Run Options dialog box (Figure 29) it is possible to define:  the stop condition of the simulation run  which variables have to be traced during the simulation run  initial values of variables defined in the Parameters field of the Run vertex (Step 3). In our example, we define an end-of-simulation time equal 160 time units as stop condition. Trace variables are Q[], M[] and K, while the initial values for the variables initialized in the Parameters field of the Run vertex are the following:  T[1] = 20 seconds, processing time of machine 1  T[2] = 11 seconds, processing time of machine 2  T[3] = 9 seconds, processing time of machine 3  T[4] = 31 seconds, processing time of machine 4  C[1] = 0, size of the buffer before machine 1 (not necessary)  C[2] = 3, size of the buffer before machine 2  C[3] = 1, size of the buffer before machine 3  C[4] = 1, size of the buffer before machine 4  K = 1, variable utilized as parameter  N = 4, number of stages of the line  TARR = 10 seconds, interarrival time  Q[N+1] = 0, dummy variable  C[N+1]=1000, dummy variable Note that dummy variables Q[N+1] and C[N+1] are needed when the condition of the edge going from the Finish to the Unload event (Q[K+1] < C[K+1]) has to be evaluated for K=4. This happens when a job is exiting the last station in the line. Dummy variables allow not incurring in an „Out of Index‟ error when evaluating the condition. When K=4, the job is leaving the fourth station, but the Unload event of station 3 has still to be scheduled. For this reason the condition Q[5]
Figure 29: The Run Options dialog box. Step.7 Execute the model Once the Run Options have been defined, by clicking the Ok & Run button the simulation can be executed. Figure 30 shows the default output provided by SIGMA, in which the model experimental conditions and a list of all the traced variable values at each event time are reported.

- 26 -

Figure 30: The output provided by SIGMA

6.2

Implementing and executing an OOEG through JAVA

The reference model of this example is slightly different from the one described in the preceding section, as it is possible to have multiple parallel machines in each station. In our example case we have 4 station with 2, 1, 1, and 3 machines respectively in stations 1-4 (Figure 31). Interarrival time is still equal to 10 seconds, and processing times are still equal to 20, 11, 9 and 31 seconds respectively for stations 1, 2, 3 and 4. There are buffers with limited capacity between machines (no buffer is needed before the first machine), with capacity equal to 3, 1 and 1 respectively for buffers before stations 2, 3 and 4.

- 27 -

Station Machine Station

Station

Station

Station

1

2

3

4

3

1

1

Buffer size

Figure 31: The line created through the code reported in Figure 32. The implementation through Java of a simulation model for the above described reference model following the OOEG paradigm has been substantially described in Section 5.1. In order to make the simulation model executable, little additions must be made. These ones can be found in Appendix B, where executable versions of the CreateJob, FinishProcessing, StartingProcessing, and Passing classes are shown. In particular, the FinishProcessing Class has been updated with the code necessary to allow a job exiting the line after the last station, and to stop the simulation after the completion of 9 Jobs. The other changes concerns a few lines of code needed to generate an output-log. The code reported in Figure 32 is an example of main method, in which input data required to define the physical system are defined, the simulation model is build and the simulation execution in started. public static void main(String[] args) { // TODO code application logic here Line theLine; int [] lineConfiguration = {2,1,1,3}; int [] bufferSize = {0,3,1,1}; double [] processingTime = {20,11,9,31}; double interarrivalTime = 10.0; theLine = new Line(lineConfiguration, bufferSize, processingTime, interarrivalTime); theLine.createJob.scheduleNext(); Sim.start(); }

Figure 32: An example of simulation Input data are: 

  

= an array of N integers, with N equal to the number of Stations in the line. Each element i corresponds to the number of Machines in the i-th Station. int [] bufferSize = an array of N integers. Each element i corresponds to the size of the buffer preceding the i-th Station. double [] processingTime = an array of N doubles, each element i corresponds to the processing time of machines in the i-th Station. double interarrivalTime = represents the interarrival time of loads entering the line. int [] lineConfiguration

Input data serve to create a new object Line. When the Main class is run, the line is created, the first job is created and the simulation starts. Appendix C shows the output-log generated by the execution of simulation model.

- 28 -

7

Comparing OOEG with EG modeling formalism

In the following some key points about the comparison of the proposed formalism and the EG modeling formalism are discussed (see Table 1 for a point to point comparison summary). - The OOEG modeling formalism allows representing discrete event systems when the model is developed using an object-oriented approach. The compactness and simplicity of an Object Oriented Event Graph is comparable to the ones of an Event Graph. However, the OOEG modeling paradigm is based on other two components (see Section 4): two UML Class diagrams, one related to the physical system (the Physical Class Diagram, PCD) and the other related to events (the Event Diagram, ED). The need of UML Class diagrams is implicit when adopting an object-oriented paradigm. - Contrarily to the EG model, in the OOEG model the dynamic of the system is visualized through interaction between objects. For example, from Figure 16 it is possible to see that when the finishProcessing event associated to a job takes place, the job itself schedules its passing event to happen at current time, if there is space in the next Station. Then, when the Passing event of the job takes place, the job schedules the startProcessing event of the previous Station and of the current Station to happen, if they are ready to start. Then, when a startProcessing event of a station takes place, the station schedules the finishProcessing event of the startWorkingJob to occur after a time equal to the processing time. In this way it is possible to see which object triggers the event corresponding to another object, making evident the interactions among objects. - The OOEG modeling paradigm solves the lack of correspondence between the event graph representation and the real system, typical of the EG paradigm. The Physical Class Diagram allows making evident the physical architecture of the real system, in terms of objects composing the system. The Object Oriented Event Graph, by visualizing the interaction between the same objects, allows defining the dynamic of the system. - The OOEG modeling paradigm, thanks to the object-oriented approach, allows linking state variables to objects, which is not possible using the EG paradigm. For example, the state variables Q[k], M[k] and B[k] used in the EG depicted in Figure 9c, are not linked to objects composing the real system. On the contrary by using the OOEG paradigm this link is made evident by the Physical Class Diagram (Figure 22), where state variables appear as attributes of Classes related to objects composing the physical system. For example, the number of jobs waiting to be processed in a station, which corresponds to Q[k] in the EG, corresponds to the number of items in the List waitingToBeProcessed, which is an attribute of the class Station. This makes evident the meaning of the variable in the logic of the real system, and helps envisioning a queue of jobs waiting to be processed by a station.

- 29 -

Modeling formalism EG

OOEG

Object-oriented approach

Not possible

Possible

Dynamic of the system

Described graphically in terms of state variables changes triggered by events

Described graphically in terms of interactions among components of the system triggered by events

Architecture of the real system

Not visible

Visible through the UML Physical Class Diagram

State variables

Not linked to components of the real system

Linked to components of the real system (as attributes of Classes)

 SIGMA General purpose simulation languages

General purpose object-oriented simulation languages

Implementation languages

Graphical representation



Very compact

Very compact if limited to the Object Oriented Event Graph, but requiring two additional UML Class diagrams

Table 1. Summary of pros and cons EG and OOEG modelling formalism.

8

Conclusions

In the paper an Object-Oriented Event Graph (OOEG) modeling formalism has been presented. The formalism aims to extend the capability of the well-known Event Graph (EG) formalism in order to represent in a more readable and easy way a simulation model developed under the object-oriented paradigm. A methodology for systematically developing an Object-Oriented Event Graph from a reference model has been presented. The methodology has been applied to obtain the OOEG of an n-stage tandem line with parallel machines within stations. By comparing the OOEG with the classical EG for an analogous n-stage tandem line, some considerations can be drawn. The OOEG representation provides the same compactness of the EG representation, and the same basic architecture, with nodes representing events, and arcs representing scheduling of target events. The advantage of the OOEG representation is that variables and conditions become respectively attributes and methods of objects related to the physical world, and this make the structure and the dynamic of the system much more understandable. The price is the need, which is implicit when adopting the object-oriented paradigm, to combine the OOEG representation with two UML Classes diagrams, one related to the physical system, and the other related to events. However, UML diagrams are already a standard for Object-Oriented models representation. From this point of view, OOEG can be viewed as a completion of the UML diagrams set in the view of allowing the representation of object-oriented discrete event simulation models. - 30 -

The importance of providing an effective representation of events scheduling in object-oriented simulation models is nowadays growing under the Industry 4.0 paradigm. The OOEG representation put together the ability of representing complex and component based systems, typical of the Object-Oriented approach, and the effectiveness of a visual representation of the events scheduling logic typical of Event Graphs.

Acknowledgments The author wishes to thank the University of Perugia which supported this research through its program for Basic Research 2018 and its financing through the project RICBA18LT.

- 31 -

Appendix A - Basics of UML Class Diagrams A Class diagram describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. In the diagram, classes are represented with boxes that contain three compartments: the top compartment contains the name of the class. The middle compartment contains the attributes of the class. The bottom compartment contains the operations the class can execute. Class diagrams offers a number of benefits: illustrate data models for information systems, no matter how simple or complex; better understand the general overview of the schematics of an application; create detailed charts that highlight any specific code needed to be programmed and implemented to the described structure; provide an implementation-independent description of types used in a system that are later passed between its components.

Figure 33: Representation of a class in a Class Diagram. In the modeling of a system, a number of classes are identified and grouped together in a class diagram that helps to determine the static relations between them. Static relationships in a UML class diagram can be showed through associations. When two classes are associated it means that instances of these classes „communicate‟ with each other.

Figure 34: Association between two Classes.

Figure 35: Example of association between two Classes. An important type of association is aggregation, that embodies the “whole-or-part of” relationship among classes. Aggregations are a special kind of associations because they associate a whole with its parts. This implies that all aggregations are implicitly named “part of”.

- 32 -

Figure 36: Composition. The case in which a part instance of some whole instance belongs to one and only one whole, is a special case of aggregation, named composition. With composition, parts can‟t be shared with other objects, and the life of the part is completely within the life span of the whole.

- 33 -

Appendix B public class Line { Station[] station; Station dummyStation; CreateJobEvent createJob; double interarrivalTime; //constructor public Line (int[] lineConfiguration, int[] bufferSize, double[] processingTime, double interarrivalTime) { int numberOfStations = lineConfiguration.length; station = new Station[numberOfStations]; for (int k = 0; k < numberOfStations; k++) { int id = k; station[k] = new Station(id, lineConfiguration[k], bufferSize[k], processingTime[k]); } this.interarrivalTime = interarrivalTime; createJob = new CreateJobEvent(this); } }

- 34 -

public class Job { static int counter =1; int id; Line myLine; Station prevStation; Station currStation; Station nextStation; FinishProcessingEvent finishProcessing; PassingEvent passing; Machine currMachine; public void updateStationReference() { int currStationIndex = currStation.id; //if the current station is the dummy one, i.e. the job is entering the line if (currStation == myLine.dummyStation) { prevStation = myLine.dummyStation; currStation = myLine.station[0]; nextStation = myLine.station[1]; } //if the current station is the one before the last one in the line (the job is entering //the last station of the line) there will be no reference for the nextStation else if (currStation.id == (myLine.station.length - 2)) { prevStation = myLine.station[currStationIndex]; currStation = myLine.station[currStationIndex + 1]; nextStation = null; } //if the current station is the last one in the line (the job is entering //the last station of the line) there will be no reference for the current and next Station else if (currStation.id == (myLine.station.length - 1)) { prevStation = myLine.station[currStationIndex]; currStation = null; nextStation = null; } //else if the current station is among other two stations within the line else { prevStation = myLine.station[currStationIndex]; currStation = myLine.station[currStationIndex+1]; nextStation = myLine.station[currStationIndex+2]; } } public void releaseMachine() { //the machine is released only if the job is not in the dummyStation if (currStation != myLine.dummyStation) { currStation.idleMachines.add(currMachine); } } public void seizeMachine() { //the machine is seized by removing it from the List of idle machines of the Station currMachine = (Machine) currStation.idleMachines.remove(0); } public double calcProcessingTime() { double processingTime = currMachine.procTime; return processingTime; } //constructor public Job(Line myLine) { id = counter; Job.counter++; this.myLine = myLine; finishProcessing = new FinishProcessingEvent(this); passing = new PassingEvent(this); currStation = myLine.dummyStation; } }

- 35 -

public class Station { int id; List idleMachines; StartProcessingEvent startProcessing; Job startWorkingJob; List waitingToBeProcessed; int bufferSize; public boolean readyToStart() { boolean isReady = false; if (this.id==-1) return false; //the dummy station (id = -1) does not process any job //the station is ready to start if there is at least one idle machine and a job that is //waiting to be processed if (!idleMachines.isEmpty() && !waitingToBeProcessed.isEmpty()) { isReady = true; } return isReady; } public boolean hasSpace() { boolean hasSpace = false; //if there is at least one idle machine, or there is space in the buffer, //the method returns true if (!idleMachines.isEmpty() || waitingToBeProcessed.size() < bufferSize) { hasSpace = true; } return hasSpace; } //constructor public Station(int id, int numberOfMachines, int bufferSize, double processingTime) { this.id = id; idleMachines = new LinkedList(); for (int k = 0; k < numberOfMachines; k++) { idleMachines.add(new Machine(processingTime)); } waitingToBeProcessed = new LinkedList(); startProcessing = new StartProcessingEvent(this); this.bufferSize = bufferSize;

} //constructor for the dummyStation public Station() { //the id of the dummy station is equal to -1 id=-1; } }

public class Machine { double procTime; //constructor public Machine(double processingTime) { this.procTime=processingTime; } }

- 36 -

public class CreateJobEvent extends Event { Line myLine; @Override public void actions() { Job newJob = new Job(myLine); System.out.println("" + Sim.time() + "\tJob "+newJob.id+" is created"); newJob.passing.scheduleNext(); myLine.createJob.schedule(myLine.interarrivalTime); } //constructor// public CreateJobEvent(Line myLine) { this.myLine = myLine; } }

public class FinishProcessingEvent extends Event { Job myJob; @Override public void actions() { System.out.println(Sim.time() + "\tJob " + myJob.id + " finished to be processed in Station " + myJob.currStation.id); //if the job is in the last station of the line if (myJob.nextStation == null) { System.out.println(Sim.time() + "\tJob " + myJob.id + " exits the line"); if (myJob.id==9) Sim.stop(); //this is the ending condition myJob.releaseMachine(); if (myJob.currStation.readyToStart()) { myJob.currStation.startProcessing.scheduleNext(); } } else if (myJob.nextStation.hasSpace()) { myJob.passing.scheduleNext(); } } //constructor public FinishProcessingEvent(Job myJob) { this.myJob = myJob; } }

- 37 -

public class PassingEvent extends Event { Job myJob; public void actions() { myJob.releaseMachine(); myJob.updateStationReference(); myJob.currStation.waitingToBeProcessed.add(myJob); System.out.println(Sim.time()+"\tJob "+myJob.id+" passes in Station "+myJob.currStation.id); // if (myJob.prevStation.readyToStart()) { myJob.prevStation.startProcessing.scheduleNext(); } if (myJob.currStation.readyToStart()) { myJob.currStation.startProcessing.scheduleNext(); } } //constructor public PassingEvent(Job myJob) { this.myJob = myJob; } }

public class StartProcessingEvent extends Event { Station myStation; @Override public void actions() { myStation.startWorkingJob = (Job)myStation.waitingToBeProcessed.remove(0); myStation.startWorkingJob.seizeMachine(); double procTime = myStation.startWorkingJob.calcProcessingTime(); myStation.startWorkingJob.finishProcessing.schedule(procTime); System.out.println(""+Sim.time()+"\tJob "+myStation.startWorkingJob.id+" processed in Station "+myStation.id); } //constructor// public StartProcessingEvent(Station myStation) { this.myStation = myStation; } }

- 38 -

starts

to

be

Appendix C 0.0 0.0 0.0 10.0 10.0 10.0 20.0 20.0 20.0 20.0 20.0 20.0 30.0 30.0 30.0 30.0 30.0 31.0 31.0 31.0 31.0 40.0 40.0 40.0 40.0 40.0 40.0 40.0 40.0 42.0 42.0 42.0 42.0 50.0 50.0 50.0 50.0 50.0 51.0 51.0 51.0 53.0 53.0 53.0 53.0 60.0 60.0 60.0 60.0 60.0 62.0 62.0 62.0 64.0 64.0 64.0 64.0 70.0 70.0 70.0 70.0 70.0 71.0 71.0 73.0 73.0 73.0 75.0 75.0 75.0 75.0 80.0 80.0 80.0 80.0 80.0 82.0 82.0 84.0 84.0 84.0 86.0 86.0 86.0 86.0 90.0 90.0 90.0

Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job

1 is created 1 passes in Station 0 1 starts to be processed in Station 0 2 is created 2 passes in Station 0 2 starts to be processed in Station 0 1 finished to be processed in Station 1 passes in Station 1 1 starts to be processed in Station 1 3 is created 3 passes in Station 0 3 starts to be processed in Station 0 2 finished to be processed in Station 2 passes in Station 1 4 is created 4 passes in Station 0 4 starts to be processed in Station 0 1 finished to be processed in Station 1 passes in Station 2 1 starts to be processed in Station 2 2 starts to be processed in Station 1 3 finished to be processed in Station 3 passes in Station 1 5 is created 5 passes in Station 0 5 starts to be processed in Station 0 1 finished to be processed in Station 1 passes in Station 3 1 starts to be processed in Station 3 2 finished to be processed in Station 2 passes in Station 2 2 starts to be processed in Station 2 3 starts to be processed in Station 1 4 finished to be processed in Station 4 passes in Station 1 6 is created 6 passes in Station 0 6 starts to be processed in Station 0 2 finished to be processed in Station 2 passes in Station 3 2 starts to be processed in Station 3 3 finished to be processed in Station 3 passes in Station 2 3 starts to be processed in Station 2 4 starts to be processed in Station 1 5 finished to be processed in Station 5 passes in Station 1 7 is created 7 passes in Station 0 7 starts to be processed in Station 0 3 finished to be processed in Station 3 passes in Station 3 3 starts to be processed in Station 3 4 finished to be processed in Station 4 passes in Station 2 4 starts to be processed in Station 2 5 starts to be processed in Station 1 6 finished to be processed in Station 6 passes in Station 1 8 is created 8 passes in Station 0 8 starts to be processed in Station 0 1 finished to be processed in Station 1 exits the line 4 finished to be processed in Station 4 passes in Station 3 4 starts to be processed in Station 3 5 finished to be processed in Station 5 passes in Station 2 5 starts to be processed in Station 2 6 starts to be processed in Station 1 7 finished to be processed in Station 7 passes in Station 1 9 is created 9 passes in Station 0 9 starts to be processed in Station 0 2 finished to be processed in Station 2 exits the line 5 finished to be processed in Station 5 passes in Station 3 5 starts to be processed in Station 3 6 finished to be processed in Station 6 passes in Station 2 6 starts to be processed in Station 2 7 starts to be processed in Station 1 8 finished to be processed in Station 8 passes in Station 1 10 is created

90.0 90.0 93.0 93.0 95.0 95.0 95.0 97.0 97.0 97.0 97.0 100.0 100.0 100.0 100.0 100.0 104.0 104.0 106.0 106.0 106.0 108.0 108.0 108.0 108.0 110.0 110.0 110.0 110.0 110.0 115.0 115.0 117.0 117.0 117.0 119.0 119.0 119.0 119.0 120.0 120.0 120.0 120.0 120.0 126.0 126.0 128.0 128.0 128.0 130.0 130.0 130.0 130.0 130.0 130.0 130.0 130.0 130.0 137.0 137.0 139.0 139.0 139.0 140.0 140.0 140.0 140.0 140.0 141.0 141.0 141.0 141.0 148.0 148.0 150.0 150.0 150.0 150.0 150.0 150.0 150.0 150.0 152.0 152.0 152.0 152.0 159.0 159.0

0

0

1

0

2

1

0

2

1

0

2

1

0

3 2

1

0

3 2

1

0

- 39 -

Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job Job

10 passes in Station 0 10 starts to be processed in Station 0 3 finished to be processed in Station 3 3 exits the line 6 finished to be processed in Station 2 6 passes in Station 3 6 starts to be processed in Station 3 7 finished to be processed in Station 1 7 passes in Station 2 7 starts to be processed in Station 2 8 starts to be processed in Station 1 9 finished to be processed in Station 0 9 passes in Station 1 11 is created 11 passes in Station 0 11 starts to be processed in Station 0 4 finished to be processed in Station 3 4 exits the line 7 finished to be processed in Station 2 7 passes in Station 3 7 starts to be processed in Station 3 8 finished to be processed in Station 1 8 passes in Station 2 8 starts to be processed in Station 2 9 starts to be processed in Station 1 10 finished to be processed in Station 0 10 passes in Station 1 12 is created 12 passes in Station 0 12 starts to be processed in Station 0 5 finished to be processed in Station 3 5 exits the line 8 finished to be processed in Station 2 8 passes in Station 3 8 starts to be processed in Station 3 9 finished to be processed in Station 1 9 passes in Station 2 9 starts to be processed in Station 2 10 starts to be processed in Station 1 11 finished to be processed in Station 0 11 passes in Station 1 13 is created 13 passes in Station 0 13 starts to be processed in Station 0 6 finished to be processed in Station 3 6 exits the line 9 finished to be processed in Station 2 9 passes in Station 3 9 starts to be processed in Station 3 12 finished to be processed in Station 0 12 passes in Station 1 10 finished to be processed in Station 1 10 passes in Station 2 10 starts to be processed in Station 2 11 starts to be processed in Station 1 14 is created 14 passes in Station 0 14 starts to be processed in Station 0 7 finished to be processed in Station 3 7 exits the line 10 finished to be processed in Station 2 10 passes in Station 3 10 starts to be processed in Station 3 13 finished to be processed in Station 0 13 passes in Station 1 15 is created 15 passes in Station 0 15 starts to be processed in Station 0 11 finished to be processed in Station 1 11 passes in Station 2 11 starts to be processed in Station 2 12 starts to be processed in Station 1 8 finished to be processed in Station 3 8 exits the line 14 finished to be processed in Station 0 14 passes in Station 1 16 is created 16 passes in Station 0 16 starts to be processed in Station 0 11 finished to be processed in Station 2 11 passes in Station 3 11 starts to be processed in Station 3 12 finished to be processed in Station 1 12 passes in Station 2 12 starts to be processed in Station 2 13 starts to be processed in Station 1 9 finished to be processed in Station 3 9 exits the line

9

References

[1] B.K. Choi, D. Kang, Modeling and Simulation of Discrete Event Systems, (Wiley, Hoboken, New Jersey, 2013). [2] E.L. Savage, L.W. Schruben, E. Yucesan, On the generality of event-graph models, Informs J Comput, 17 (2005) 3-9. [3] M. Bortolini, E. Ferrari, M. Gamberi, F. Pilati, M. Faccio, Assembly system design in the Industry 4.0 era: a general framework, IFAC-PapersOnLine, 50 (2017) 5700-5705. [4] B. Rodič, Industry 4.0 and the New Simulation Modelling Paradigm, Organizacija, 50 (2017) 193-207. [5] J. De Lara, Distributed event graphs: Formalizing component-based modelling and simulation Electronic Notes in Theoretical Computer Science, Proceedings of the Workshop on Visual Languages and Formal Methods (VLFM 2004), 127 (2005) 145-162. [6] L. Schruben, Simulation Modeling with Event Graphs, Commun Acm, 26 (1983) 957-963. [7] L.W. Schruben, E. Yucesan, Simulation graphs, in: Winter Simulation Conference Proceedings. San Diego, CA, USA, 1988), 504-508. [8] L. Schruben, Graphical Simulation Modeling and Analysis: Using Sigma for Windows, (Boyd & Fraser Pub Co, 1995). [9] L. Schruben, E. Yucesan, Simulation graph duality: A world view transformation for simple queueing models - Winter Simulation Conference Proceedings, 1989 Winter Simulation Conference Proceedings WSC '89, (1989) 738-745. [10] L. Schruben, E. Yucesan, Transforming petri nets into event graph models, in: Proceedings of the 1994 Winter Simulation Conference. Buena Vista, FL, USA, 1994), 560-565. [11] K.J. Healy, The use of event graphs in simulation modeling instruction, 25th Conference on Winter Simulation, WSC 1993, Part F129590 (1993) 1131-1134. [12] A.H. Buss, Modeling with event graphs, in: 1996 Winter Simulation Conference Proceedings. 1996), 153-160. [13] A. Ceylan, M.M. Gunal, A methodology for developing des models: Event graphs and sharpsim, 23rd European Modeling and Simulation Symposium, EMSS 2011, (2011) 278-282. [14] E. Song, B.K. Choi, B. Park, Event graph modeling of a homogeneous job shop with bi-inline cells, Simulation Modelling Practice and Theory, 20 (2012) 1-11. [15] D. Kang, H. Kim, B.K. Choi, B.H. Kim, Event Graph Modeling of a Heterogeneous Job Shop with Inline Cells, Proceedings of the 2014 Winter Simulation Conference (Wsc), (2014) 2156-2167. [16] Y. Pan, Y. Zhou, L. Wang, Modeling internet applications with event graphs, in: 6th International Conference on Fuzzy Systems and Knowledge Discovery, FSKD 2009. Tianjin, 2009), 124-128. [17] Y. Liu, H. Zhang, C. Li, R.J. Jiao, Workflow simulation for operational decision support using event graph through process mining, Decis Support Syst, 52 (2012) 685-697.

- 40 -

[18] Y.E. Osais, Towards a framework to detect modeling and semantic errors in event graphs - Simulation Series, 21st International Symposium on Performance Evaluation of Computer and Telecommunication Systems, SPECTS 2018, Part of the 2018 Summer Simulation Multi-Conference, SummerSim 2018, 50 (2018) 13-22. [19] T.H.J. Uhlemann, C. Lehmann, R. Steinhilper, The Digital Twin: Realizing the Cyber-Physical Production System for Industry 4.0, Procedia CIRP, 61 (2017) 335-340. [20] M.C. Fu, G. Bayraksan, S.G. Henderson, B.L. Nelson, W.B. Powell, I.O. Ryzhov, B. Thengvall, Simulation optimization: A panel on the state of the art in research and practice, in., 2015), 3696-3706. [21] H. Li, Y. Zhu, Y. Chen, G. Pedrielli, N.A. Pujowidianto, The Object-Oriented discrete event simulation modeling: A case study on aircraft spare part management, in: Proceedings - Winter Simulation Conference. 2016), 3514-3525. [22] L. Tiacci, Event and object oriented simulation to fast evaluate operational objectives of mixed model assembly lines problems, Simulation Modelling Practice and Theory, 24 (2012) 35-48. [23] L. Tiacci, Coupling a genetic algorithm approach and a discrete event simulator to design mixed-model un-paced assembly lines with parallel workstations and stochastic task times, International Journal of Production Economics, 159 (2015) 319-333. [24] L. Tiacci, Simultaneous balancing and buffer allocation decisions for the design of mixed-model assembly lines with parallel workstations and stochastic task times, International Journal of Production Economics, 162 (2015) 201-215. [25] L. Tiacci, Mixed-model U-shaped assembly lines: Balancing and comparing with straight lines with buffers and parallel workstations, J Manuf Syst, (2017). [26] L. Tiacci, M. Mimmi, Integrating ergonomic risks evaluation through OCRA index and balancing/sequencing decisions for mixed model stochastic asynchronous assembly lines, Omega (United Kingdom), 78 (2018) 112-138. [27] A. Buss, Component based simulation modeling with Simkit, Proceedings of the 2002 Winter Simulation Conference, 1 (2002) 243-249. [28] P. L'Ecuyer, L. Meliani, J. Vaucher, SSJ: A framework for stochastic simulation in Java, Proceedings of the 2002 Winter Simulation Conference, 1 (2002) 234-242. [29] P. L'Ecuyer, E. Buist, Simulation in Java with SSJ, 2005 Winter Simulation Conference, 2005 (2005) 611-620. [30] K.J. Healy, R.A. Kilgore, SilkTM: A Java-based process simulation language, Proceedings of the 1997 Winter Simulation Conference, (1997) 475-482. [31] R.A. Kilgore, Object-oriented simulation with SML and silk in .Net and Java - Winter Simulation Conference Proceedings, Proceedings of the 2003 Winter Simulation Conference: Driving Innovation, 1 (2003) 218-224. [32] SigmaWiki, Sigma - Event graph simulation modeling. (http://www.sigmawiki.com). [33] L.W. Schruben, Simulation graphical modeling and analysis (SIGMA) tutorial, in: Winter Simulation Conference Proceedings. 1990), 158-161.

- 41 -