On The Generalization Of Continuous-Time Stochastic Processes

On The Generalization Of Continuous-Time Stochastic Processes Simulation For Industrial Production Modeling Fabio Bursi, Andrea Ferrara, Andrea Grassi, Chiara Ronzoni Dipartimento di Scienze e Metodi dell’Ingegneria, Universit`a degli Studi di Modena e Reggio Emilia Via Amendola 2, 42122 Reggio Emilia, Italy. Logistics & Automation Consulting srl, Via G.V. Catullo 22, 42124 Reggio Emilia, Italy. [email protected], [email protected], [email protected], [email protected] Keywords: discrete event simulation, continuous time, production flow, manufacturing system, DEVS.

Abstract The paper presents a new generalized framework for carrying out simulations of continuous-time stochastic processes by exploiting a discrete event approach. The application scope of this work mainly refers to industrial production processes executed on a continuous flow of material (e.g., food and beverage industry) as well as production processes working on discrete units but characterized by a high production rate (e.g., automated packaging lines). The proposed model extends a previous work of the same Authors by introducing the capability to manage logical signals between couples of simulation units. In this way, control policies can be modeled and triggered by variations on parameters under monitoring during the simulation. A generalized model for a generic simulation unit is then presented and described adopting the DEVS formalism.

1. INTRODUCTION Simulation is an effective tool that can be adopted in industry to support production plant design and management. Specifically, Discrete Event Simulation (DES) has been widely adopted in the industrial context thanks to the advantages deriving from the discretization of event occurrence, that is, the possibility to move on the time line jumping from event to event, thus speeding up the simulation model. DES perfectly applies to the modeling of discrete manufacturing systems, given their implicit event driven behavior. However, when production assumes the characteristics of a continuous flow, DES tends to show limits in both accuracy and speed. We find this situation in food industry, but also in discrete manufacturing systems characterized by high production rate (e.g., packaging and bottling). Even if discrete event simulation has been widely used to solve design and management problems in the manufacturing field [Jahangirian et al. 2010], the combination of continuous-time and discrete event simulation is still a challenging area of research. In this field, contributions mainly refer to the modeling of the so-called hybrid sys-

tems [Melamed et al. 2001; Pritchett et al. 2001; Nutaro et al. 2012]. Despite that, the common approach adopted in practice to suitably simulate a continuous flow system by adopting discrete event simulation is to discretize the flow [Yan and Gong 1999; Stephen Kuo et al. 2001]. This approach, even if simple to implement, does not guarantee accuracy. Thus, new development and proposal in the field of the efficient simulation of continuous time systems by means of discrete event approach are of great interest, both for academics and practitioners. The aim of this paper is to present a new modeling framework for the simulation of flow manufacturing processes following an approach that aims to reproduce the behavior of a continuous-time stochastic process by means of a discrete event approach. The work extends a previous one proposed in [Bursi et al. 2013] by introducing the capability to generate and catch logical signals connecting couples of arbitrary units. This allows to generate control signals, modeled as discrete events, to modifiy the behavior of a unit based on the values of parameters measured on another unit. The Discrete EVent system Specification (DEVS) formalism, firstly introduced by Zeigler [Zeigler 1976, 1984; Zeigler et al. 2000], is used in this paper to define the base unit model. DEVS allows the development of robust model representation based on the concept of atomic models and on the concept of higher-level models coupling. Several applications of DEVS for the definition of models for simulating manufacturing systems have been presented in literature. Among them, interesting contributions are [Giambiasi and Carmona 2006] and [Pujo et al. 2006]. The remaining of the paper is organized as follows. Section 2. defines the problem statement, while Section 3. develops the model for the base unit. Finally, Section 4. provides concluding remarks.

2. PROBLEM STATEMENT The aim of this paper is to present a generalized modeling fremwork for simulating manufacturing processes. In particular, the production is modeled as a continuous flow, hence the whole system acts like a continuous-time stochastic process. The added value of the proposed framework is that it

makes it possible the simulation of a continuous-time system by means of Discrete Event Simulation (DES), thus guaranteeing at the same time the accuracy of the continuous-time simulation and the speed of the DES. The scope of application of the present work is of course the process industry, in which the production flow is actually formed by continuous material (e.g., food and beverage industry), but it can also be extended to discrete manufacturing, expecially when production rates are high (e.g., automated lines for packaging and bottling). In both of the aforementioned cases, the proposed approach can provide benefits. The simulation of continuous production flow is typically carried out by discretizing the flow (e.g., by defining a discrete physical unit in terms of volume or some other measures) and addressing the simulation by means of a discrete event approach [Stephen Kuo et al. 2001]. If, in one hand, this provides a simple escape to reduce the complexity of the problem, on the other hand it introduces a loss of accuracy. Large dimension of the discrete unit involves a worsening of accuracy, but allows speeding up the simulation model. Conversely, when we deal with simulation of discrete manufacturing, the descrete event approach allows to obtain the best accuracy, but producing an increase of the computational effort as the production rate of the system increases. For both of the aforementioned situations, i.e., continuous flow production and high speed discrete manufacturing, the possibility to deploy a discrete event simulation in which the flow is assumed to be continuous and the events refer to state changes of the machines, both due to internal changes and to interactions with external machines, can provide benefits in terms of accuracy and computational speed. That concept is similar to what has been done in years by scientists addressing the analytical modeling of continuoustime stochastic processes applied to the design of manufacturing systems. If we consider the continuous-time mixed-state markov process based modeling of the so-called two-machine one-buffer building block [Zimmern 1956; Gershwin and Schick 1980; Yeralan and Tan 1997], we can notice that the production flow is assumed to be continuous, while the model is structured so as to represent the different states with the related transtion rates. As the behaviour of the system increases its complexity, the dimension of the state space rises [Tan and Gershwin 2009, 2011; Gebennini et al. 2013; Gebennini and Gershwin 2013]. Similarly, also stochastic Petri Nets can be used to address the same class of problems [Ajmone Marsan et al. 1991; Donatelli 1994]. Based on that concept, the aim here is to propose a framework for a base unit, to be used in a simulation model, able to represent any mandatory behavior a production unit has to posses to be effectively used to characterize the performance of the production system. A first proposal of a base unit hav-

ing that capability was presented by [Bursi et al. 2013]. In this paper, we extend Bursi et al. (2013)’s model to introduce the capability to variate the base unit behavior by means of control signals whose occurrence is triggered by the variation of parameters under monitoring during the simulation. Bursi et al. (2013)’s model was conceived so as to be able to represent three basic classes of objects, by means of those almost all of the manufacturing processes can be modeled: • workcenters continously operating on the flow, chracterized by a specific maximum production speed, zero accumulation and zero throughput time; • buffers, characterized by a maximum speed, an accumulation greater than zero, and a throughput time depending on the buffering strategy (FIFO, LIFO, mixing, etc.); • conveying units (i.e. conveyors, belts, pipes, etc.), characterized by a specified speed, no accumulation capability (the material in the system is simply moved), and a throughput time depending on the length and the speed. Every of those three objects can be obtained by the same base unit by a simple configuration of the characteristic parameters, that refer to the following three families: 1. failures and repairs; 2. working speed and accumulation; 3. throughput time. Moreover, custom parameters (e.g. temperature, concentration of polluttants, etc.) are kept under monitoring and their variation is computed considering the time as a continuous variable, but triggered by event propagation. The base unit generates state change events in function of its internal state and receives events from the units connected both in the upstream and in the downstream channels. Hence, the propagation of the events is related to the physical propagation of the production flow along the production system. In this paper, the possibility to send and receive logical signals is added to the original model of [Bursi et al. 2013]. Practically, the user can define links between couples of units by means of which events are sent. The advantage is that those links can allow to send signals that do not pass along the production flow and, for this reason, they are considered logical signals. In the proposed model, those logical signals are triggered by the variation of parameters. In particular, for each link, a threshold of a specific parameter is set and the unit sends the event as soon as the threshold is reached. The time needed to reach the threshold is a priori computed, so the system behaves following a classical discrete event scheme.

Figure 2. The dependency matrix.

Figure 1. The base unit model.

3. THE BASE UNIT MODEL 3.1. Base unit object 3.1.1. Informal description The base unit model is composed by three atomic models representing the behaviors (i) failures and repairs, (ii) working speed and accumulation, (iii) throughput time, plus one interface, a logic control object and n additional parameter models. The purpose of this section is to illustrate the interaction between them. Figure 1 shows the interactions between physical external signals, coming from the upstream and the downstream flows, and internal signals. Logical external signals coming from other base units are also considered. The base unit is composed by standard objects and one interface whose task is to generate output signals. Considering a simple flow system, the base unit is equipped with one input and two output ports for external physical signals, in order to send system variations both to upstream and downstream flows. The base unit receives logical signals through one input port and broadcasts these signals by one output port. Forward signals processed among internal objects follows a static scheme represented by a matrix of dependencies (see Figure 2) composed by: 1. the base matrix managing signals among standard objects; 2. the external signals; 3. the set of rows and columns managing additional parameters signals. The vector S∗ represents the internal set of data that are used for local storing purposes. The signal generated by the failures and repairs object (FR) is related to a state change due to the occurrence of a TTF or of a TTR, that is, a change of the operative conditions of the unit. A signal (updateFR) is then sent to the working speed and accumulation object (WSA) for updating purposes. The opposite signalling direction (updateWSA) is also introduced,

since a change in the speed of the unit can imply a variation in the way the TTF consumption is accounted (i.e. if the failures are operation dependent or not). Updates in WSA conditions are also sent to the additional parameter objects (ADDk ) to allow the update of their values and functions. For what concerns logical signals, updateLC is sent to the WSA object in order to verify if working speed and accumulation changes are occurred. UpdateLC is also sent to the additional parameter objects in order to re-compute related functions. As a result of the update, the updateLPk signal is sent to the throughput time object (T), where threshold values are updated. The throughput time object acts as a sort of final gateway by which every signal has to pass before being sent to the external units. The reason is that the object T is devoted to the computation of the delay with which external units realize that something has changed in the considered unit. Finally, the interface object (I) takes care of the signals broadcasting. Physical signals are sent to the upstream and the downstream flow, while logical signals are dispatched to all base units that are logically connected with the considered parameter. 3.1.2. Formal description ‘base unit’ = h Xbu ,Ybu , Tbu , δext , δint , λ,t i Input event variable Xbu = (inputS, inputL) where: • ‘inputS’ = S where S = { f , s, param1 , . . . , paramk , . . . , paramn } − f = {d, u} is the flow parameter, where ? f = ‘d’ represents a message coming from a downstream unit while ? f = ‘u’ represents a message from an upstream unit; − s is the working speed; − paramk , for k = 1, . . . , n, is the function describing the variation of the additional parameter k over time. • ‘inputL’ = L where L = {m, method, param,t, w} − m represents the base unit from which the input logical signal has been sent; − method is the events flow that need to be executed

when an input logical signal is received ; − param is the involved parameter; − t is the threshold achieved by the sending base unit; − w = {up, down} represents the direction with which the threshold is reached. Output event variables Ybu = (downstreamS, upstreamS, out putL) where: • ‘downstreamS’ = {‘u’, s∗ , param∗1 , . . . , param∗k , . . . , param∗n} − ‘u’ indicates the unit in the downstream that the signal is coming from an unit in its upstream; − s∗ is the value of the actual working speed; Figure 3. The logic control object. − param∗k , for k = 1, . . . , n, is the function describing the actual law of variation of the additional parameter k over time. − method is the events flow that need to be executed when an input logical signal is received ; • ‘upstreamS’ = {‘d’, s∗ , param∗1 , . . . , param∗k , . . . , param∗n } − ‘d’ indicates the unit in the upstream that the signal − param is the involved parameter; is coming from an unit in its downstreamstream; − t is the threshold achieved by the sending base unit; − s∗ is the value of the actual working speed; − w = {up, down} represents the direction with − param∗k , for k = 1, . . . , n, is the function describing which the threshold is reached. the actual law of variation of the additional paramState variables: TLC = (phase,t, σ) where: eter k over time. • ‘phase’ = {init, wait, method} is a name representing • ‘outputL’ = L where L = {m, method, param,t, w} the situation in the real world; − m represents the base unit from which the input • ‘t’ = {f∗m } represents the time needed to execute the logical signal has been sent; proper method. − method is the events flow that need to be executed • σ ∈ R+ 0 ∪ ∞ is the life time of the current state. when an input logical signal is received ; Output event variable: YLC = (updateT ) where: − param is the involved parameter; • ‘updateT’ = {yes} indicates the need to recompute ad− t is the threshold achieved by the sending base unit; ditional parameter functions and the base unit physical − w = {up, down} represents the direction with parameters. which the threshold is reached.

3.2. Logic Control object

3.3. Failures and repairs object model

3.2.1. Informal description Looking at Figure 3, the ‘init’ state represents the initialization phase. After this phase, the system turns in the ‘wait’ state where it stays till external ?inputL = ‘L’ signal is received. At this moment, the system switches to the ‘method’ state and computes the time (t) needed to execute the method read into the L vector, time representing the lifetime of this state. Once the t time has passed, the system generates an internal !updateLC = ‘yes’ ouput signal and comes back to the ‘wait’ state.

This model has the same description as reported in [Bursi et al. 2013].

3.2.2. Formal description ‘logic control object’ = h XLC ,YLC , TLC , δext , δint , λ,t i Input event variable: XLC = (inputL) where: • ‘inputL’ = L where L = {m, method, param,t, w} − m represents the base unit from which the input logical signal has been sent;

3.4. Working speed and accumulation object model 3.4.1. Informal description The purpose of this object (see Figure 4) is to model the operative conditions of the base unit system. Considering the ‘init’ state as initialization of the object variables, all parameters are set to ‘0’ and, by means of an internal transition, the system jumps in the ‘wait’ state. Thus, the working speed and accumulation object receives an !updateFR = ‘1’ and the system switches to the ‘update’ state: s∗i , s∗o , s∗ , andAcc∗ variables are updated to the new calculated values obtained by reading previously stored values of s∗i , s∗o , s∗ , andAcc∗. In this case, the base unit restarts calculating parameters using the stored ones.

Figure 4. The working speed and accumulation object. After the update have been done, the system switches to the ‘wait’ state creating an output signal !updateWSA = ‘yes’ in order to notice the changes made. The same path is followed also when: • there is an external signal ?inputS = ‘S’ entering the unit where information about speed changes, both upstream and downstream, are stored and then used to update the unit operative condition; • there is a ?updateLC = ‘{yes}’ signal coming from the logic control object in order to update all parameters. As a transitional state, the system switches to the ‘wait’ state and remains in this state for a time that is the minimum value between infinite and tb , the time when the base unit will be at one accumulation boundary. Boundaries are possible only when the base unit is configured as a buffer, so that boundaries are the empty level of the buffer and a level of the buffer equal to its capacity. At the boundary state, the actual level of the buffer is computed (emtpy or full). The ‘boundary’ state is transitional, so that the system sets its parameters, creates an internal output signal to notice the changes and then switches into the ‘wait’ state in order to wait that a change signal occurs. After receiving an !updateFR = ‘0’ the system switches from the ‘wait’ state to the ‘down’ state and sets all its parameters to ‘0’. As a transitional state, the system switches to the ‘wait’ state after the creation of an internal output in order to notice an operative change. 3.4.2. Formal description ‘working speed and accumulation object’ = h XW SA ,YW SA , TW SA , δext , δint , λ,t i Input event variable: XW SA = (inputS, updateFR, updateLC) where:

• ‘inputS’ = S where S = { f , s, param1 , . . . , paramk , . . . , paramn } − f = {d, u} is the flow parameter, where ? f = ‘d’ represents a message coming from a downstream unit while ? f = ‘u’ represents a message from an upstream unit; − s is the working speed; − paramk , for k = 1, . . . , n, is the function describing the variation of the additional parameter k over time. • ‘updateFR’ = {0, 1} is the internal signal that is generated as output by the failures and repairs object, where ?updateFR = ‘0’ indicates that the state of the base unit is down and ?updateFR = ‘1’ indicates that the state of the base unit is up. • ‘updateLC’ = {yes} is generated by the logic control object. This signal indicates that speeds and accumulation level can be updated if the base unit receives a logical signal. State variables: TW SA = (phase, s∗ , s∗i , s∗o , acc∗ , σ) where: • ‘phase’ = {init, down, wait, update, boundary} is a name representing the situation in the real world; • ‘s∗ ’ = fs () represents a function which calculates the base unit working speed considering the upstream and downstream base units working speed, the maximum working speed of the base unit, and the accumulation level. • ‘s∗i ’ = fsi () represents a function which determines the upstream base unit working speed. • ‘s∗o ’ = fso () represents a function which determines the downstream base unit working speed. • ‘acc∗ ’ = facc () represents a function which determines the accumulation level considering s∗i , s∗o , s∗ , and the previous accumulation level. • σ ∈ R+ 0 ∪ ∞ is the life time of the current state. Output event variable: YW SA = (updateWSA) where: • ‘updateWSA’ = {yes} indicates a working speed and accumulation variation.

3.5. Throughput time object model 3.5.1. Informal description By referring to Figure 5, all parameters are computed in the initial ‘update’ state. Here, the thresholds vector (V) is set for the first time. Its values are calculated by using a specific function for each threshold and they represent the time needed for achieving the threshold. By identifying the minimum value in the thresholds vector as l, the system switches to the ‘wait’ state. In case an external input signal occurs when the system is in the ‘wait’ state, the system comes back to the ‘update’ state and recomputes its V vector and the new

• ‘phase’ = {wait, update, setV} is a name representing the situation in the real world; • ‘V ’ is a finite-dimensional vector where all parameter thresholds are stored. In case that n base unit are logically connected as output, V will be composed by n × k logical values, and by m physical values. • ‘l’ = min(l) is the vector V minimum value. It represents the minimun distance in time to the next threshold achieving. • σ ∈ R+ 0 ∪ ∞ is the life time of the current state. Output event variable: Ytr = (updateT, updateTL) where: • ‘updateT’ = {yes} indicates a physical signal to be sent to the Interface object. • ‘updateTL’ = {yes} indicates a logical signal to be sent to the Interface object. Figure 5. The throughput time object.

3.6. Interface object model l value. The possible external input signals are: • ?updateParamk = ‘yes’ coming from the additional paramater object; • ?updateLPk = ‘yes’ coming from the additional paramater object; • ?updateWSA = ‘yes’ coming from the working speed and accumulation object. Being the ‘update’ state a transient state, the system jumps immediately to the ‘wait’ state. In case that l time has elapsed without any incoming external input signal, the first threshold related to the additional k-th parameter is achieved and the system switches to the ‘setV’ state. Hence, the system recomputes only the V vector thresholdes related to the considered additional paramenter. Furthermore, the new l value is calculated and the system immediately generates the proper internal output signal. Whenever a logical threshold is achieved, the system produces a logical ?updateT L = ‘yes’, otherwise, if a physical threshold is reached, a physical ?updateT = ‘yes’ signal is generated. 3.5.2. Formal description ‘throughput time object’ = h Xtr ,Ytr , Ttr , δext , δint , λ,t i Input event variable: Xtr = (updateParamk, updateWSA, updateLPk ) where: • ‘updateParamk’ = {yes} indicates a variation in the k-th additional parameter function; • ‘updateWSA’ = {yes} indicates a work speed and accumulation variation. • ‘updateLPk’ = {yes} indicates a variation of the k parameter. State variables: Ttr = (phase,V, l, σ) where:

3.6.1. Informal description By referring to Figure 6, in the initial state ‘init’, both the physical output signal (S) and the logical output signal (L) are initialized empty. When the interface receives a physical signal from the throughput time object, S is updated. For each physical input signal received, two different signals are generated: one is sent to upstream and the other one to the downstream. The first signal is S = {‘d’, s∗ , param∗ }, while the latter is S = {‘u’, s∗ , param∗ }. It means that the Interface object sends: • ‘flow’ = {‘d’, ‘u’}, that is, the information to the upstream and the downstream with the position reference of the considered base unit; • the speed of considered base unit; • the additional parameter functions of the considered base unit. When the interface receives a logical input singal from the throughput time object, L is generated and the system switches to the ‘set3’ state. Here, L is composed as follow: • m represents the base unit from which the input logical signal has been sent; • method is the events flow that need to be executed when an input logical signal is received ; • param is the involved parameter; • t is the threshold achieved by the sending base unit; • w = {up, down} represents the direction with which the threshold is reached. Immediately the system sends the logical ‘out putL’ signal and comes back to the ‘wait’ state.

init tparam = f*tparam σ=0

?updateWSA = 'yes' update1 tparam = f*tparam σ=0 wait tparam σ = infinite

!updateParamk = 'yes'

?updateLC = 'yes'

updateParamk yes

Additional parameter k

!updateLPk = 'yes'

update2 tparam = f*tparam σ=0

updateLPk yes

Figure 7. The generic additional parameter object. Figure 6. The interface object. 3.6.2. Formal description ‘interface object’ = h Xint ,Yint , Tint , δext , δint , λ,t i Input event variable: Xint = (updateT, updateTL) where: • ‘updateT’ = {yes} indicates the reception of a physical signal from the throughput time object. • ‘updateTL’ = {yes} indicates the reception of a logical signal from the throughput time object. State variables: Tint = (phase, S, L, σ) where: • ‘phase’ = {init, wait, set1, set2, set3} is a name representing the situation in the real world; • S = { f low, s∗ , param∗} is the physical output signal and it consists of: − ‘flow’ = {‘u’, ‘d’}, ‘u’ indicates that the considered base unit is the upstream of the destination base unit, while ‘d ′ indicates that the considered base unit is the downstream of the destination base unit; − s∗ , the speed of the considered unit; − param∗, the additional parameter functions of the considered base unit. • L = {paramk } represents the logical output signal. It is composed by: − m represents the base unit from which the input logical signal has been sent; − method is the events flow that need to be executed when an input logical signal is received ; − param is the involved parameter; − t is the threshold achieved by the sending base unit; − w = {up, down} represents the direction with which the threshold is reached. • σ ∈ R+ 0 ∪ ∞ is the life time of the current state. Output event variable: Yint = (upstreamS, downstreamS, out putL) where: • ‘upstreamS’ = {S} indicates a physical signal to be sent to the upstream base unit;

• ‘downstreamS’ = {S} indicates a physical signal to be sent to the downstream base unit; • ‘outputL’ = {L} indicates a logical physical to be sent to the logically connected base units.

3.7. Additional paramter object 3.7.1. Informal description Looking at Figure 7, in the initial state ‘init’, the parameter of the additional function t param is set for the first time. This function depends on the base unit speed, accumulation, the base unit state and on the additional parameter itself. Later, the object waits for an input signal in order to update its function. This function can be updated when: • the object receives a physical ‘updateWSA’ = yes signal by the working speed and accumulation object; • the object receives a logical ‘updateLC’ = yes signal by the logic control object. In both cases, since the updating states are transitory, the system immediately comes back to the ‘wait’ state generating an internal output signal. This signal can be a physical one if the received signal was ‘updateWSA’ = yes, or a logical one if the the received signal was ‘updateLC’ = yes. In the latter case, the internal output signal is generated only in order to update the V thresholds vector located in the throughput time object without broadcasting purposes. 3.7.2. Formal description ‘additional parameter object’ = h X param ,Yparam , Tparam , δext , δint , λ,t i Input event variable: X param = (updateWSA, updateLC) where: • ‘updateWSA’ = {yes} indicates a work speed and accumulation variation. • ‘updateLC’ = {yes} allows the updating of the function of the considered parameter.

State variables: Tparam = (phase,t param , σ) where: • ‘phase’ = {init, wait, update1, update2} is a name representing the situation in the real world; • ‘t param ’ = {f∗tparam } represents the function associated to the additional parameter object. • σ ∈ R+ 0 ∪ ∞ is the life time of the current state. Output event variable: Yparam = (updateParamk, updateLPk ) where: • ‘updateParamk’ = {0, 1} indicates a variation in the additional parameter k function. • ‘updateLPk’ = {yes} indicates that the thresholds of the additional parameter k must be recomputed.

4. CONCLUSIONS The paper presents an extension of the work done by [Bursi et al. 2013]. A base unit framework is proposed to allow the modeling of a continuous-time production flow by means of a discrete event approach, without loss of accuracy. Here, the possibility to manage logical control signals between couples of units has been added to make it possible the control of the production flow based on the values of parameters under monitoring. In this way, the framework proposed allows the anlyst to model both the physical flow and control mechanism to be deployed in the production system.

REFERENCES Ajmone Marsan, M., G. Balbo, G. Chiola, G. Conte, S. Donatelli, and G. Franceschinis. 1991. “An introduction to generalized stochastic Petri Nets”. Microelectronics Reliability 31 (4): 699–725. Bursi, F., A. Ferrara, A. Grassi, and C. Ronzoni. 2013. “Simulating continuous time production flows in food industry by means of discrete event simulation”. In Proceedings of the 12 th International Conference on Modeling and Applied Simulation, 95–102. Athens, Greece. Donatelli, S. 1994. “Superposed generalized stochastic Petri Nets: Definition and efficient solution”. Lecture Notes in Computer Science 815:258–277. Gebennini, E., and S. B. Gershwin. 2013. “Modeling waste production into two-machine one-buffer transfer lines”. IIE Transactions 45 (6): 591–604. Gebennini, E., A. Grassi, C. Fantuzzi, S. B. Gershwin, and I. C. Schick. 2013. “Discrete time model for two-machine one-buffer transfer lines with restart policy”. Annals of Operations Research 209 (1): 41–65. Gershwin, S. B., and I. C. Schick. 1980. “Continuous Model of an Unreliable Two-Stage Material Flow System with a Finite Interstage Buffer”. Technical Report LIDS-R1039, OSP No. 87049, Laboratory for Information and Decision Systems, Massachusetts Institute of Technology, Cambridge, Massachusetts 02139, USA.

Giambiasi, N., and J. Carmona. 2006. “Generalized discrete event abstraction of continuous systems: GDEVS formalism”. Simulation Modelling Practice and Theory 14 (1): 47–70. Jahangirian, M., T. Eldabi, A. Naseer, L. Stergioulas, and T. Young. 2010. “Simulation in manufacturing and business: A review”. European Journal of Operational Research 203 (1): 1–13. Melamed, B., S. Pan, and Y. Wardi. 2001. “Hybrid discretecontinuous fluid-flow simulation”. In Proceedings of SPIE - The International Society for Optical Engineering, Volume 4526, 263–270. Nutaro, J., P. T. Kuruganti, V. Protopopescu, and M. Shankar. 2012. “The split system approach to managing time in simulations of hybrid systems having continuous and discrete event components”. Simulation 88 (3): 281–298. Pritchett, A. R., S. M. Lee, and D. Goldsman. 2001. “Hybridsystem simulation for national airspace system safety analysis”. Journal of Aircraft 38 (5): 835–840. Pujo, P., M. Pedetti, and N. Giambiasi. 2006. “Formal DEVS modelling and simulation of a flow-shop relocation method without interrupting the production”. Simulation Modelling Practice and Theory 14 (7): 817–842. Stephen Kuo, S., E. Jack Chen, P. L. Selikson, and Y. M. Lee. 2001. “Modeling continuous flow with discrete-event simulation”. In Proceedings of the 2001 Winter Simulation Conference, 1099–1103. Arlington, VA, USA. Tan, B., and S. B. Gershwin. 2009. “Analysis of a general Markovian two-stage continuous-flow production system with a finite buffer”. International Journal of Production Economics 120 (2): 327–339. Tan, B., and S. B. Gershwin. 2011. “Modelling and analysis of Markovian continuous flow systems with a finite buffer”. Annals of Operations Research 182 (1): 5–30. Yan, A., and W. B. Gong. 1999. “Time-driven fluid simulation for high-speed networks”. IEEE Transactions on Information Theory 45 (5): 1588–1599. Yeralan, S., and B. Tan. 1997. “Analysis of multistation production systems with limited buffer capacity. Part I: The subsystem model”. Mathematical and Computer Modelling 25 (7): 109–122. Zeigler, B. 1976. Theory of modelling and simulation. New York: John Wiley. Zeigler, B. 1984. Multifacetted Modelling and Discrete Event Simulation. London: Academic Press. Zeigler, B., H. Praehofer, and T. Kim. 2000. Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems. Second ed. New York, NY: Academic Press. ´ Zimmern, B. 1956. “Etudes de la propagation des arrˆets al´eatoires dans les chaˆınes de production”. Rev. Statist. Appl. 4:85–104.