- Email: [email protected]
A distributed time-driven simulation method for enabling real-time manufacturing shop floor control
Computers & Industrial Engineering 49 (2005) 572–590 www.elsevier.com/locate/dsw
A distributed time-driven simulation method for enabling real-time manufacturing shop floor control* Sohyung Cho * Department of Industrial Engineering, University of Miami, 281, McArthur Building, Coral Gables, FL 33146, USA Received 19 November 2003; revised 11 April 2004; accepted 20 August 2005 Available online 24 October 2005
Abstract This paper proposes a distributed simulation approach for scheduling discrete-events in manufacturing shop floors. The proposed approach employs a time-driven method to simulate occurrence of discrete-events using distributed entities that replicate physical entities in the manufacturing shop floor. In specific, the proposed approach iteratively controls the timing of discrete-events occurrence using a control theoretic model. In this approach, changing the speed of the simulation clock, termed time-scaling factor, can accelerate or decelerate the simulation speed resulting in simpler synchronizations of discrete-events and faster simulation than standard distributed discrete-event simulations according to the capability of the communication networks. Computational experiments are conducted to test the performance of the proposed system with different values of the time-scaling factor, and the relationship between the system performance and the time-scaling factor is investigated through analysis of the system model. Results obtained from the computational experiments show significant successes in speeding up discrete-event simulations in such a way that the proposed approach can be used for the control of manufacturing shop floors, providing real-time decision supports. q 2005 Elsevier Ltd. All rights reserved. Keywords: Discrete-events; Simulation; Time-scaling factor; Arrival time controller
1. Introduction Simulation has been widely used as a decision support for modeling, analysis, and design of systems to characterize the impact of changing parameters on system performance. Thus, simulation provides the means for observing the behavior of a system over time when direct measurement of the system parameters is inconvenient, or when it is desirable to view the system at increased or decreased rate of time passage. Simulations can be used for continuous or discrete systems depending upon the way that the state of the system changes from one state to another. While continuous systems include state variable that can take on real value in a certain interval, discrete systems include state variable that can take on a large but finite set of alternatives. In this paper, we focus our attention on discrete systems because discrete models for part flow would be satisfactory in manufacturing systems, which deal with discrete products. The state of discrete manufacturing systems transits over a set of discrete-events including ‘moving a part from a machine to another’, ‘arrival of a part at a machine’, and ‘completion of a part processing at a machine.’ Simulation methods for such systems broadly fall into two categories as shown in Fig. 1: event-driven and time-driven methods. *
This manuscript was processed by Area Editor Gary L. Hogg. * Corresponding author. Tel.: C1 305 284 2370, fax: C1 305 284 4040. E-mail address: [email protected].
0360-8352/$ - see front matter q 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.cie.2005.08.003
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
573
Simulation method
Event–driven
Centralized/Sequential
Disctret–event
Time-driven
Parallel/Distributed
Conservative
Optimistic
Centralized
Parallel/Distributed
DTS
Fig. 1. Classification of simulation methods (DTS: distributed time-scaled simulation).
Fig. 1 shows the classification of various simulation methods including centralized and distributed discrete-event simulation, and distributed time-scaled simulation (DTS). Time-driven simulation refers to the case where every decision regarding which event to schedule next is made as needed as time advances in the physical system. On the other hand, in event-driven simulation events in the physical systems are simulated at discrete points in time and the simulation clock discontinuously advances after simulation of an event to the time of the next event. The operations of manufacturing shop floors can be viewed by either method. In the event-driven method, part-processing flow through shop floor is viewed as a chain of events with simulation of each event leading to the generation of a following event simulation until finishing required manufacturing operations. Using the time-driven approach, the shop floor is observed at different intervals of time. At each observation, the status of all components in the simulation model (e.g. parts and machines) is modified to reflect the activities and changes that occurred during the preceding time interval in the shop floor. As one of many event-driven methods, discrete-event simulation has been extensively used to predict the capacity or analyze the performance of discrete systems (Misra, 1986; Kim & Kim, 1994). In general, discrete-event simulation is conducted in a sequential manner using a variable of clock and data structure, called event list. Event list usually maintains a set of messages including time-stamp for occurrence time and description of the events. One of the major drawbacks of discrete-event simulation is that the simulations of large systems are limited by their inherent sequential structure (Misra, 1986). As an alternative, distributed discrete-event simulation has been studied to exploit the cost benefits of micro-computers and high bandwidth of communication networks by decomposing large simulation problems and executing entities on multiple processors. In distributed simulations, avoiding causality error to ensure ordering of events is a critical issue. Causality error is typically used to describe a situation as follows: an event Ex containing a larger time-stamp is processed earlier than the smallest time-stamped event Emin (Fujimoto, 1990). This situation is clearly unacceptable because the future affects the past. Such distributed discrete-event simulation can be classified into two categories: conservative and optimistic. Conservative methods strictly avoid this causality error. In these methods, any entity cannot process an event until it can determine that no other event(s) containing a smaller time-stamp will later be received. A common approach used by conservative methods is to have entities ‘look ahead’ into the simulated future to predict what events they may later schedule. Good performance has been reported for a range of problems, including simulations of queuing networks and road traffic (Fujimoto, 1989; Merrifield, Richardson, & Roberts, 1990). However, the drawback of conservative methods is that they require the application specific knowledge in order to avoid causality error leading to lower flexibility. On the other hand, optimistic methods employ a detection and recovery process to avoid causality errors. In the optimistic methods, entities are allowed to continue a simulation even though a larger time-stamped event is processed earlier. When the causality errors are detected, each entity saves its state up to current simulation time. This detection requires an entity to resimulate a previous part of the simulation. The resimulation is conducted using a method of rolling back the state of the entity currently being simulated and undoing its effects on other entities. All optimistic approaches must have some mechanisms for detecting and recovering from the causality errors. Time warp is a well-known scheme, which belongs to this category. Optimistic methods provide application independent synchronization for discrete-event simulations. Since optimistic methods do not rely on application specific knowledge, they can be used as a general synchronization mechanism, just as the event list provides a general
574
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Table 1 Comparison of simulation methods Simulation method
Advantage
Disadvantage
DTS
Extremely simple synchronization mechanism to ensure ordering of events in the simulation Minimal development and implementation effort Faster simulations can be expected and simulations can be limited by the computing or communication resources
Time-scaling can lead to errors in measurements
Distributed discrete-event
Complex synchronization mechanisms required Possibility of deadlock caused by the complexity in synchronization Considerable development and implementation effort
and application independent synchronization mechanism for sequential simulation. However, the drawback of the optimistic approach is that it incurs costs associated with state-saving overhead (Fujimoto, 1990). In time-driven simulation methods, simulation clock value increases at a constant rate. As the simulation clock advances, events with corresponding time-stamps are processed. Due to this increasing sequence of the simulation clock values, avoiding causality errors to ensure ordering of events can be relatively simple in the time-driven simulation methods. Furthermore, simple synchronization of events in these methods results in minimal development and implementation effort. Distributed time-driven simulation using communication networks can be easily achieved because of the minimized global information of synchronization. However, the shortcoming of the distributed timedriven method is that CPU time and network bandwidth may not be fully utilized because there may be no events to be simulated for long periods of time. The time-scaling approach has been introduced to overcome this shortcoming (Peacock, Wong, & Manning, 1979). The software complexity of the time-scaling approach has been compared to that of the time-warp simulation method with an order of less complexity (Duffie & Prabhu, 1994). Choosing discreteevent simulation or distributed time-scaled simulation is a design issue involving tradeoffs between complexity and maximizing utilization of CPU and network bandwidth. The main characteristics of these two techniques can be compared as in Table 1. In this paper, distributed time-driven simulation using time-scaling factors for manufacturing systems is considered, which is called distributed time-scaled simulation (DTS). This paper is organized as follows: in Section 2, the DTS approach is presented in detail. In addition, the performance of the network is evaluated to gain systematic information on the required network capability. Section 3 covers open architecture for DTS, including the communication library. In Section 4, DTS is applied for a continuous feedback control system for manufacturing shop floors, called distributed arrival time control system (DATC). Section 5 provides computational results for the performance of DTS. 2. Distributed time-scaled simulation First, the concept of the simulation clock is introduced and then time-scaled simulation is defined. The simulation clock is the abstraction of a wall clock, that is, real time, in that the state of the physical system at any real time will correspond to a logical state of the simulated system at the corresponding simulated clock. In time-driven simulation, the sequence of simulation clock time values forms an increasing sequence, that is, DtsZc, where ts denotes simulation clock and c is a constant such that cO0. While in event-driven simulation, the simulation clock sequence is still monotonically non-decreasing, but it is not an arithmetic sequence, that is, DtsR0; the sequence values represent times at which the state of the system changes, and such state changes is called events. The relationships between simulation clock and wall clock are considered here. A method is scaled if it has the property that S !tr ts Z int q (1) q where tr is wall clock, q is the quantum step size of simulation time, and S is the scaling factor. Note that since we are interested in digital simulation methods, the values assumed by simulation clock must be discrete. Due to this
Simulation clock
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
575
ts,2 ts,1
∆ts,2 ∆ts,1
ts,0 ∆tr,1
∆tr,2
Wall clock
Fig. 2. Simulation clock vs. wall clock.
property, observation of the dynamics of a system is possible with a constant rate of simulation clock elapses relative to real time. Fig. 2 shows the relationship between simulation clock and wall clock. In the DTS method, logical processes (e.g. autonomous entities) have their own simulation clock possessing the scaling factor in common. Due to the time-scaling factor in Eq. (1), nonlinear components in the physical system can be easily modeled (Peacock et al., 1979). Furthermore, DTS simulation allows the user to observe the dynamic behavior of the system as the simulation progresses in a similar way to simulation using an analog computer. Note that this approach is not limited to the simulation of manufacturing shop floors, but may be applied to any system that can be decomposed into a set of parallel processes such as computer systems and traffic flow studies. The speed of DTS simulation can be accelerated or decelerated by changing the scaling factor that presents the ratio between simulation and wall clock. Adjustment of the scaling factor executes the simulation several orders of magnitude faster than in real time. This scaling factor distinguishes the proposed approach from discrete-event simulations. Major problem of the DTS method is that the simulation may be not accurate, i.e. if the same simulation is run twice, the results may be different. This is due to variations in service time and errors in message communication leading to limitation of time-scaling factor. More specifically, the scaling factor and thus, the simulation speed is limited by the throughput and utilization of the communication network used. If the simulation is executed beyond this limit, the order of messages being return from related entities can be varied for different simulations, which in turn introduce randomness in the system. Therefore, for this approach to be viable in industrial applications, there is a need to characterize the limitation on the possible scaling factor for the DTS method related to the capability of communication networks, and a quantitative measure of this limitation is provided in the following section. 3. Open architecture for DTS Davis and Smith (1983) emphasized the requirement of distributed computing to solve complicated problems as ‘cooperative solution of problems by a decentralized, loosely coupled collection of problem solvers’. Krueger and Chawla (1991) supported the need of distributed computing with a fact that overall computing capacity is idle 91% of the time in an average network computing systems. With recent advances in communication networks personal computers distributed computing functionality becomes intrinsic elements of the system (Li & Otway, 1994). The requirement for distributed computing drives the need for integrated systems with open architecture. Furthermore, dissatisfaction with the high cost and relative inflexibility of proprietary systems results in more interests in open architecture and systems. Open architecture is concerned with the use of commodity technology to build integrating applications that link together existing applications, databases, control systems and users. The advantages the open system architecture offers are: economical, maintainable, open, modular, and scalable. Therefore, an open architecture based DTS is developed and tested in this paper to provide shop floor control systems with aforementioned advantages. Specifically, a flexible and easy-to-use communication library based on the open architecture is developed, which is used for efficient inter-process communication (IPC) between virtual entities. The communication library consists of several functions that can manage creating and terminating sockets, and sending and receiving peer-to-peer,
576
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
multicast, or broadcast messages with object-oriented structure. This communication library is developed based on WinSock standard, NetBIOS address family and NetBEUI datagram protocol for IPC. The main reason for selecting this protocol is that WinSock supports various other protocols including TCP/IP and IPX (Sinha, 1996). Moreover, highly distributed entity name management offered by NetBIOS address family eliminates the need for a central name server, the associated global information and improves fault tolerance of the system. Any entity residing anywhere in the network domain can communicate with other entity or a group of entities using multicast, allowing it to dynamically discover resources in the system. This communication library is essential to develop a simulation system based on DTS method consisting of virtual entities in this paper. In the following section, three main entities, which are used for simulating manufacturing shop floors, are described together with communication control protocol. More detailed description of the communication library is provided in Appendix A.1. 3.1. Part entity Part entities are instances of a generic object-oriented module for virtual entities and can reside in any PC in the network. Without the knowledge about where they are residing, they can be uniquely distinguished by their name because of NetBIOS address family as described. Part entities are created when the system starts, and they open communication sockets for (i) peer-to-peer, (ii) multicasting, (iii) broadcasting communication. Note that all the part entities have the membership of PART group for multicasting message. Communication control protocol between part and machine entity is shown in Fig. 3, where arrival times and completion times are denoted as ai(t) and ci(t), respectively. Part entity starts to seek available machine passing ‘MACH_TYPE_REQ’ message. It receives acknowledgement from available machine entities with the message ‘available’. Then, part entity reserves the available machine passing the message ‘MACH_RESV_REQ’. When it receives a ‘reserved’ message from the machine, part processing is requested with ‘MACH_PROC_REQ’. One round of part processing simulation is completed when the state of the part entity changes from state 1 to 4. The time elapsed from state 1 to 3 is a waiting time for processing start. It is needed to emphasize that there is minimum waiting time in DTS due to the capabilities of the communication network used, such as message latency and bandwidth. The processing time shown in Fig. 3 can be simulated as a time delay associated with time-scaling factor. 3.2. Machine entity Machine entities are created and initialized when the system is started. Machine entities are also instances of a generic object-oriented program module as part entities. These machine entities passively wait for reservation requests from part entities, and they can be in one of the following states at any time: (i) FREE; (ii) BUSY; or (iii) DONE (Fig. 3). Once a part reserves an available machine, the machine entity becomes in the state of BUSY, and it should wait for certain amount of time which corresponds to part processing time in order to shift back to the state of FREE again. In DTS simulation, part-processing time is simulated by a scaled time-delay, offering opportunity to simulate several orders faster than in real-time. After simulating part processing, the machine entity sends back a ‘completed’ message to the part entity. During the BUSY state, the machine entity accumulates reservation requests PART STATE 1 (ai(t )) STATE 2
MACHINE MACH_TYPE_REQ1 available2 MACH_RESV_REQ2 reserved2
STATE 3
FREE
BUSY
MACH_PROC_REQ2 Processing time completed2
STATE 4 (ci(t ))
DONE 1: Multicast Datagram 2: Peer–to–Peer Datagram
Fig. 3. Communication protocol for part and machine entity.
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
577
Initialize global performance
DTS simulation (best performance:Jb)
Jb
No
Yes Update Jg as Jb Fig. 4. Calculation of the global performance during simulation.
in the message queue, and the next reservation requests is served after part processing is completed. The completion of each operation includes machine set-up time, working file downloading time and so on. The processing time for operations can be identical when the identical machines are assumed. Otherwise, it will be different. Machine capacity accounts for controlling the processing time. In fact, dissimilar or identical machines can be distinguished by different machine capacity. 3.3. Evaluator The primary function of the evaluator is to collect local due-date deviations from part entities in every simulation round in order to monitor the global performance. Another function is synchronizing the simulation. After each simulation round is completed, it resets the simulation clock to zero broadcasting a ‘reset timer’ message to all the part entities. During the simulation, the best schedule can be updated and saved periodically by comparison of current best performance and present performance as shown in Fig. 4. Knowledge of the networking performance is important in order to develop DTS successfully because the communication network determines the efficiency of IPC. Latency measures the time for a packet of arbitrary size data to be sent to a remote node across the network. This factor significantly affects design of the communication control protocol between part and machine entity. In the experimental system with 100 Mbps network capability, it has been observed that the latency is, on average, 18.9357 ms for 256 Byte packet of message as shown in Fig. 5. Seven hundred (700) trials have been used to collect statistically reasonable data. Considering the communication capability of the network, a significant overhead in the communication can be observed. Fig. 6 shows the snapshot of part entities and evaluators developed using visual CCC in DTS method. 4. Application of DTS using DATC The time at which the communication protocol is initiated is referred to as arrival time, which is denoted as ai(t) in Fig. 3. In general, arrival times have a significant impact on system performance because they implicitly determine the evolution of events in the system. DTS is used to simulate such evolution of events by controlling arrival times of 250 Frequency
200 150 100 50 0 1
2
3 4 Latency(msec)
5
6
Fig. 5. Distribution of message latency (Avg.Z18.93571 ms).
578
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Fig. 6. Distributed virtual entities in different PCs.
part entities at variable speed to provide the real-time decision support. As various control techniques can be used for the control of arrival times, DTS in this paper employs a distributed arrival time control (DATC) system that continuously controls arrival time using completion time feedback to minimize due-date deviation (Cho & Prabhu, 2002a,b). In DTS using DATC, a closed-loop arrival time controller is constructed for each part entity, and tentative arrival times are iteratively adjusted to improve the control system performance. This iterative process is repeated at a faster rate than real-time according to the scaling factor used for DTS simulation, leading to a multi-variable closed loop feedback control system. Adjustment of arrival times can be expressed as a function of continuous time as follows: ð ai ðtÞ Z ki ðdi Kci ðtÞÞdt C ai ð0Þ (2) where ai(t), ki, di, ci(t) denote the arrival time, the control system gain, the due-date and the completion time of ith part, respectively. Eq. (2) can be rewritten in discrete time as follows: ai ðmTÞ Z ki ðdi Kci ððmK1ÞTÞÞ C ai ððmK1ÞTÞ
(3)
where T is the discrete time step. Fig. 7 illustrates the closed loop control structure of DATC system in discrete time. Fig. 8 illustrates that the arrival times modeled using Eq. (2) exponentially converge to a single steady-state value when the production demand in the manufacturing shop floor exceeds the available resource capacity. It has been shown that the single steady-state value of arrival times can be analytically predicted (Prabhu & Duffie, 1999). After the arrival times converge to the steady-state value, the relative order of arrival times continue to change generating various part processing sequences. DATC system keeps searching various schedules based on part processing sequence change. Thus, DATC system can be viewed as a ‘search heuristic based on feedback control’. Due–date deviation
Due–date
di
Arrival time
Disturbance pi+qi (mT )
+ _
ci (mT)
ki zi ((m–1))T+ai ((m–1)T )
zi ((m-1)T )
ai (mT)
Completion time
Fig. 7. Closed control loop of DATC system in discrete time.
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
579
Fig. 8. Trajectory of the arrival times.
Recent work has focused on developing techniques to design control system parameters such as gains in order to improve scheduling performance and predictability. In contrast to the exponential computing complexity in traditional combinatorial formulation for controlling discrete-events, the arrival time control formulation eliminates combinatorial complexity by transforming the scheduling problem into a continuous variable control problem. DATC system has been found to have exponential convergence rate which makes it attractive for real-time scheduling (Cho & Prabhu, 2002a). Because the controllers are fully distributed the computations for each controller can be executed on a separate processor in parallel, making them inherently suitable for massively parallel/distributed computing. The implementation of the DTS using DATC can be outlined as follows: Step 1: Create virtual entities including parts, machines and evaluator. Step 2: Read input parameters: routing information, initial arrival times, processing times, due dates, control gains, iteration. Step 3: Reset simulation clock. Step 4: Start simulation clock. Step 5: Part reserves machine when the simulation clock becomes equal to arrival time. Step 6: Machine returns ‘available’ message to the part when it becomes idle (queuing time is included here). Step 7: Machine starts processing at the speed set by the scaling factor. Step 8: Part receives ‘part completion’ message with the completion time information. Step 9: Adjust arrival time with the completion time using Eq. (3). Step 10: Send the due date deviation information (di – ci) to the evaluator for performance monitoring. Step 11: Go to Step 3. The communication between parts and machines during DTS is shown in Fig. 9 with underlying NetBEUI protocol. To make this simulation available, two system files should be revised as described in Appendix A.2. Also, CCC code for implementing the above outline in DTS is provided in Appendix A.3. Similar program codes to Appendix A.3 for machine and evaluator can be accessed by contacting the author. 5. Computational experiment As one of key factors for manufacturing productivity, effective scheduling can improve on-time delivery, reduce inventory, cut lead times, and improve the utilization of bottleneck resources. Because of the combinatorial nature of
580
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
NetBEUI
SendTo (Fadal, “request processing”)
ReceiveFrom (PART, szMsg)
ACTION
ReceiveFrom (Fadal, szMsg )
ACTION
PART ENTITY †: Multicasting,
SendTo (PennCube, “processing done”)
MACHINE ENTITY : Peer–to–peer
Fig. 9. Communication between parts and machines in DTS.
scheduling problems, it is often difficult to find optimal schedules, especially within a limited amount of computational time. Furthermore, job shop scheduling problems are known as one of the most complicated problems because of their complexity. Note that in job shop configurations, routing for part processing can be different from that of other part processing. Using DTS simulation can generate production schedules fast because it decomposes these complex problems into distributed computing structure using communication network. DTS is based on the message passing between part and machine entities. As described in Section 2, the message passing is controlled by communication control protocol that regards state changes in both entities. While in centralized simulation, arrival times are updated by queuing times and processing times as expressed in Eq. (2), they are affected in DTS by the communication delays in addition to the queuing and processing times. Suppose several parts request their processing to unique machine at approximately identical time with infinitesimal difference. The order with which part entities request their processing can be different from the order with which they are served by the machine entity because of the communication delays leading to the unexpected waiting time until the machine entity becomes free. If the communication delays play some role in simulation, the scheduling performance of DTS can be different from that of the centralized simulation algorithm. The effect of the communication delays can be referred to as random tie-breaking policy in terms of scheduling theory. Since communication delays are related to the time scaling factor in DTS, characterizing the limitation of the scaling factor is important. This characterization will provide information on the trade-off between simulation speed and scheduling performance. Two job-shop scheduling problems are tested in this section. Required computational time for time-scaled simulation is associated with the scaling factor and minimum bandwidth for the communication is also discussed. The results of DTS are compared to the results of a centralized algorithm. The structure of the centralized simulation algorithm can be outlined as follows: Step 1: For iZ1 – n ai ðmTÞZ ki ðdi Kci ððmK1ÞTÞÞC ai ððmK1ÞTÞ Next i Step 2: Sort ai using FCFS dispatching policy Step 3: For iZ1 – n Compute ci(m) P Next i ðd ðmÞKc ðmÞÞ2 Compute MSD(m), where MSDðmÞZ i i n i Step 4: Go to Step 1
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
581
Table 2 Two parts and two machines job-shop problem Part
Operations
Routing
Due-date
Processing time
Part1 (p1) Part2 (p2)
2 2
Milling (m1), Turning (m2) Turning (m2), Milling (m1)
10 10
1, 2 2, 1
As outlined above, arrival times are adjusted to reduce the deviations between the due dates and the completion times at each iteration in this algorithm, leading to the trajectory of arrival times as shown in Fig. 8. The centralized algorithm also uses an arrival time controller to adjust event timing. It should be emphasized that the computational complexity of the centralized algorithm is described as polynomial because of the sorting function in Step 2. In this computational experiment, Matlab program has been used for the implementation of the centralized simulation algorithm. 5.1. Two parts and two machines case A problem instance for two parts and two machines has been given in Table 2 with due-dates as a common due-date. In this problem instance, two different machines are required to process two operations of each part. Virtual entities are distributed in two personal computers (PCs) connected over 100 Mbps communication network. Denoting the time-scaling factor as S, due-date and processing times for DTS can be rewritten as follows: d Z Sd; p Z Sp Setting the scheduling objective as to minimize the due-date deviations (J), J 0 for scaled due-dates and processing times can be expressed as J0 Z
J S2
Four scaling factors S1Z1.0, S2Z0.1, S3Z0.05 and S4Z0.01 are used to examine the trade-offs between simulation speed and system performance. Approximately, the computational time required to complete DTS with the scaling factor S can be expressed as Te Z SchLPTi I
(4)
where Te, chLPTi, I denote a computational time, completion time of LPT sequence and number of iterations, respectively. Note that the required computational time for the DTS is linear function of iterations, while it is a polynomial of the iterations in case of centralized algorithm. Therefore, DTS with scaling factor S4 is run 100 times faster than with scaling factor S1 for the same problem instance. Fig. 10 shows arrival time trajectories of DTS method with four scaling factors and a centralized algorithm using single PC. Each arrival time trajectory has been obtained using identical initial conditions of the arrival times. It has been observed that arrival time trajectory with scaling factor S2(Z0.1) becomes different from that of the centralized simulation. Note that the average latency of used communication network (100 Mbps) has been tested as 18.94 ms in Section 2. Therefore, the minimum required time to simulate the state transition of part entity from State 1 to State 4 in Fig. 3 is 111.84 ms (Z18.94!6). Scaling factor S2 simulates the smallest processing time, 1 s as 100 ms. Communication protocol cannot control 100 ms because it exceeds the minimum resolution of simulation with a used communication network. Fig. 11 illustrates average deviations in arrival times with different scaling factors from the centralized method. Note that as simulation speed increases, the deviations of arrival times from the centralized method increase. In addition, the best scheduling performances (MSD) have been obtained as 0.25, 0.25, 0.07, 0.18, and 0.00 for centralized, S1, S2, S3, and S4, respectively. In the DTS based on the DATC approach, the second operations of parts start as soon as machine entities become free due to its control structure. Hence, the best performance of the centralized simulation and the DTS with SZ1.0 has been obtained as 0.25, while in the DTS with the scaling factor below 0.1 the best performance can be improved and even can
582
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
7
7
6
6
Arrival Times
(b) 8
Arival Times
(a) 8
5 4 3
5 4 3
2
2
1
1
0
0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Iterations part1(S=1.0)
part2(S=1.0)
part1(MatLab)
Iterations part1(S=0.1)
part2(MatLab)
7
7
6
6
Arrival Times
(d) 8
5 4 3
part2(MatLab)
4 3 2
1
1
0
part1(MatLab)
5
2
0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Iterations part1(S=0.05)
part2(S=0.05)
part1(MatLab)
Iterations part2(MatLab)
part1(S=0.01)
part2(S=0.01)
part1(MatLab)
Fig. 10. Arrival time trajectories in DTS (nZ2, mZ2).
1.4 ABS(Arrival_matlab - Arrival_DTS)
Arrival Times
(c) 8
part2(S=0.1
1.2 1 0.8 0.6 0.4 0.2 0 0.0
–1.0
–1.3
–2.0
log10(S) Fig. 11. Average deviation of arrival times for different scaling factors (nZ2, mZ2).
part2(MatLab)
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
583
Table 3 Problem information for six parts and four machines case Parts
Operation
Routing
Processing time
Due-date
1 2 3 4 5 6
3 4 2 4 4 2
(m1,m3,m2) (m2,m3,m1,m4) (m1,m4) (m2,m3,m1,m4) (m3,m4,m1,m2) (m3,m4)
(1,2,3) (1,2,3,4) (1,2) (1,2,3,4) (1,2,3,4) (1,2)
17 17 17 17 17 17
be zero because of the inserted idle time between two operations that has been caused by communication delays randomly. Specifically, the MSD performance has been improved by introduced randomness in starting times. It should be pointed out that although the performance has been improved, it is not desirable to have randomness in the control system in general. Also, note that when the scheduling objective is set-up to a different measure such as minimization of Work-In-Process (WIP), lower values of scaling factor can degrade the scheduling performance. 5.2. Six parts and four machines case Another example of a job-shop problem, where four machines are required to process six parts, is given as Table 3. Fig. 12 shows arrival time trajectories in this example of DTS with two scaling factors S1Z1.0 and S2Z0.1, and centralized simulation (M). Fig. 13 shows the average deviations of arrival times of DTS from the centralized simulation. It can be observed that while arrival times in centralized and DTS with S1 are comparable, arrival time trajectories in DTS with S2 are not comparable to those of the centralized one due to communication delays, which result in undesirable change of the part processing sequences as described in Section 3. The best scheduling performance has been obtained as 6.821, 6.527, and 5.471 for centralized simulation and DTS simulations with scaling factors S1, S2, respectively. As in two parts and two machines job-shop problem, lower scaling factors have generated better MSD scheduling performance.
part1(M) part2(M)
Arrival Time Trajectory 18
part3(M)
16
part4(M) part6(M)
12
part1(S=1) part2(S=1)
10
part3(S=1)
8
part4(S=1) part5(S=1)
6
part6(S=1) part1(S=0.1)
4
part2(S=0.1)
2
part3(S=0.1)
0 97
89
81
73
65
57
49
41
33
25
17
9
part4(S=0.1) 1
Arrival time
part5(M) 14
Iteration Fig. 12. Arrival time trajectories in DTS (nZ6, mZ4).
part5(S=0.1) part6(S=0.1)
584
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Deviations in arrival time
Deviations from centralized method 2
S=1.0 S=0.1
1.5 1 0.5 0 1
9
17
25
33
41 49 57 Iterations
65
73
81
89
97
Fig. 13. Deviations in arrival time from centralized simulation method (nZ6, mZ4).
5.3. General case Centralized simulation method described in above is based on a sorting function that results in a polynomial computational time. However, this sorting function is replaced by FCFS policy in DTS method for handling receiving message that results in a linearly increasing running time. DTS using DATC has been tested for general problems of shop floors with the number of part entities up to 400 and 4 machine entities. Fig. 14 shows that running times of DTS for two different testing configurations: (1) part entities ranging from 10 to 100 are simulated using a single PC; and (2) same parts are simulated using two PCs over the communication network. Note that in both configurations simulation is executed using DTS method not using the centralized program. It can be observed that distribution of part entities into multiple PCs can reduce communication overheads leading to faster simulation speed. In Fig. 15, up to 400 part entities are distributed over four PCs with four machine entities. Running time of DTS method is shown to be linearly increasing as the number of par entities increase in this figure. In addition to this test, running time of DTS method has also been compared to another centralized simulation method using Arena RT for 50 part entities. It has been observed that running time of DTS is 1/3 of that of Arena based centralized simulation. 6. Conclusion
Time for one iteration (sec)
A highly distributed and time-scaled simulation method for manufacturing shop floors was presented in this paper. It has been shown that the required time to simulate shop floor using a time-scaled simulation approach is a linear function of iterations, while it was polynomial in centralized simulation. The minimum resolution of
50 45 40 35 30 25 20 15 10 5 0
1 PC
10
20
2 PCs
30
40
50 60 No. of parts
70
80
Fig. 14. Running time of the DTS using one and two PCs.
90
100
Time for one iteration (sec)
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
585
90 80 70 60 50 40 30 20 10 0 100
200
300
400
No. of Parts Fig. 15. Running time of the DTS using four PCs (all jobs with 3 operations).
the distributed time-scaled simulation is identified as 111 ms when a communication network with 100 Mbps capability is used. This factor restricts the maximum allowable scaling factor to accelerate the simulation speed. The time-scaling factor distinguishes the proposed approach from optimistic methods such as time-warp simulation. Distributed control structures and time-scaling factors make the proposed approach an attractive alternative to traditional discrete-event simulation approaches. The benchmark with the centralized simulation method shows that the distributed time-scaled simulation can generate better schedules than the centralized methods for the tested job-shop scheduling problems. Although there is some success in speeding up the simulation speed by changing the time-scaling factors, the limitation is strongly related to the capability of the communication network, which can be characterized by message passing latency. Recently, virtual interface (VI) architecture has gained much attention because it can significantly reduce the latency and increase bandwidth bypassing operating systems for the communication. Appendix A A.1. Communication library Four (4) subroutines have been developed using Microsoft Visual CCC and MFC Class. Basically these four functions have been designed for the purpose of peer-to-peer, multicasting and broadcasting communication without client/server paradigm. Refer the following descriptions of these concepts: † Peer-to-peer: communication between any two processes † Mulitcasting: communication between a process and groups † Broadcasting: communication between all the processes
A.1.1. int CPennDiConCom::InitSockets(char *szProcess, char *szGroup); This function initialize Windows sockets with given specific process name and group name which the process belongs to. This function automatically binds a socket to the specific process. Routine
Required header
Compatibility
InitSockets ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value InitSockets function returns the value of 0 if this is called successfully. The return value is 1 for an error during the creation of sockets. Parameters SzProcess Character pointer for the process name SzGroup Character pointer for the group name which the process belongs to
586
Routine
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Required header
Compatibility
Remarks Both length of string szProcess and szGroup are equal or less than 16. This is the regulation of NetBIOS and both process name and group name are case sensitive. This function contains WSAStartup function of WinSock Library. Sockets are created with nonblocking mode.
A.1.2. void CPennDiConCom::CloseAllSockets(void); This function closes all open sockets that have been created by calling of InitSockets function. Routine
Required header
Compatibility
CloseAllSockets ANSI, Win 95, Win NT, Win32s hsockutil.hi Remarks Since CloseAllSockets contains WSACleanup of WinSock library, it should be called before the termination of main program.
A.1.3. int CPennDiConCom::SendTo(char *To, char *szMsg, int len); The SendTo function is used on datagram sockets and is used to write outgoing data on a specific peer-to-peer socket, multicast socket or broadcast socket by the To parameter. Routine
Required header
Compatibility
SendTo ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value SendTo function returns the value of 0 if this is called successfully. The return value is 1 for an error during the outgoing procedure of messages to sockets. Parameters To Character pointer for the target name (process or group name) SzMsg Character pointer for the message Len Integer value of Sizeof(szMsg) Remarks This function contains sendto function of WinSock library with SOCK_DGRAM identifier. Due to this function not function send, accept and listen functions for the Client/Server paradigm are not called for here.
A.1.4. int CPennDiConCom::Receive(char *From, char *szMsg, int len); The Receive function is used to read incoming data on a (possibly connected) socket and capture the address from which the data was sent. Routine
Required header
Compatibility
Receive ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value If Receive function succeeds, it returns the value of 0 and returns the value of 1 for an error during the reading procedure of messages to sockets. Parameters From Character pointer for the target name (process or group name) SzMsg Character pointer for the message Len integer value of Sizeof(szMsg) Remarks This function contains recvfrom function of WinSock library with SOCK_DGRAM identifier. Due to this function not function recv, accept and listen functions for the client/server paradigm are not called for here. Since, the sockets are created with nonblocking mode, it does not wait for coming data.
A.2. Setting up configuration files for DTS Services and protocol files under C:\Windows\System32\Drivers\Etc directory should be modified by the user before running the communication program which is using WinSock based on NetBIOS (NetBEUI). In the DTS,
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
587
a fictitious service name ‘PennDiCon’ is used. Therefore, user must include this service name in the services file with unreserved port number (here, 5001) and protocol name (here, NetBEUI) as shown in the following files.
A.3. CCC code for part entity in DTS
588
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
589
590
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
References Cho, S., & Prabhu, V. V. (2002a). A vector space model for variance reduction in single machine scheduling. IIE Transactions, 34, 933–952. Cho, S., & Prabhu, V. V. (2002b). Sliding mode dynamics in continuous feedback control for distributed discrete-event scheduling. Automatica, 38(9), 1499–1515. Davis, R., & Smith, R. G. (1983). Negotiation as a metaphor for distributed problem solving. Artificial Intelligence, 20(1), 63–109. Duffie, N. A., & Prabhu, V. V. (1994). Real-time distributed scheduling of heterarchical manufacturing systems. Journal of Manufacturing Systems, 13(2), 94–107. Fujimoto, R. M. (1989). Time-warp on a shared memory multiprocessor. Transactions of the Society for Computer Simulation, 6(3), 211–239. Fujimoto, R. M. (1990). Parallel discrete event simulation. Communication of the ACM, 33(10), 31–53. Kim, M. H., & Kim, Y. (1994). Simulation-based real-time scheduling in a flexible manufacturing systems. Journal of Manufacturing Systems, 13(2), 85–93. Krueger, P., & Chawla, R. (1991). The stealth distributed scheduler IIE international conference on distributed computing (pp. 336–343). Li, G., & Otway, D. (1994). An open architecture for real-time processing. ICL Systems Journal, 9(2), 213–221. Merrifield, B. C., Richardson, S. B. & Roberts, J. (1990). Quantitative studies of discrete event simulation modeling of road traffic. Proceedings of SCS Multiconference on Distributed Simulation (pp. 188–193). Misra, J. (1986). Distributed discrete-event simulation. Computing Surveys, 18(1), 39–65. Peacock, J. K., Wong, J. W., & Manning, E. G. (1979). Distributed simulation using network of processors. Computer Networks, 3, 44–56. Prabhu, V. V., & Duffie, N. A. (1999). Nonlinear dynamics in distributed arrival time control of heterarchical manufacturing systems. IEEE Transactions on Control Systems Technology, 1(6), 724–730. Sinha, A. K. (1996). Network programming in Widows NT. New York: Addison-Wesley.
A distributed time-driven simulation method for enabling real-time manufacturing shop floor control* Sohyung Cho * Department of Industrial Engineering, University of Miami, 281, McArthur Building, Coral Gables, FL 33146, USA Received 19 November 2003; revised 11 April 2004; accepted 20 August 2005 Available online 24 October 2005
Abstract This paper proposes a distributed simulation approach for scheduling discrete-events in manufacturing shop floors. The proposed approach employs a time-driven method to simulate occurrence of discrete-events using distributed entities that replicate physical entities in the manufacturing shop floor. In specific, the proposed approach iteratively controls the timing of discrete-events occurrence using a control theoretic model. In this approach, changing the speed of the simulation clock, termed time-scaling factor, can accelerate or decelerate the simulation speed resulting in simpler synchronizations of discrete-events and faster simulation than standard distributed discrete-event simulations according to the capability of the communication networks. Computational experiments are conducted to test the performance of the proposed system with different values of the time-scaling factor, and the relationship between the system performance and the time-scaling factor is investigated through analysis of the system model. Results obtained from the computational experiments show significant successes in speeding up discrete-event simulations in such a way that the proposed approach can be used for the control of manufacturing shop floors, providing real-time decision supports. q 2005 Elsevier Ltd. All rights reserved. Keywords: Discrete-events; Simulation; Time-scaling factor; Arrival time controller
1. Introduction Simulation has been widely used as a decision support for modeling, analysis, and design of systems to characterize the impact of changing parameters on system performance. Thus, simulation provides the means for observing the behavior of a system over time when direct measurement of the system parameters is inconvenient, or when it is desirable to view the system at increased or decreased rate of time passage. Simulations can be used for continuous or discrete systems depending upon the way that the state of the system changes from one state to another. While continuous systems include state variable that can take on real value in a certain interval, discrete systems include state variable that can take on a large but finite set of alternatives. In this paper, we focus our attention on discrete systems because discrete models for part flow would be satisfactory in manufacturing systems, which deal with discrete products. The state of discrete manufacturing systems transits over a set of discrete-events including ‘moving a part from a machine to another’, ‘arrival of a part at a machine’, and ‘completion of a part processing at a machine.’ Simulation methods for such systems broadly fall into two categories as shown in Fig. 1: event-driven and time-driven methods. *
This manuscript was processed by Area Editor Gary L. Hogg. * Corresponding author. Tel.: C1 305 284 2370, fax: C1 305 284 4040. E-mail address: [email protected].
0360-8352/$ - see front matter q 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.cie.2005.08.003
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
573
Simulation method
Event–driven
Centralized/Sequential
Disctret–event
Time-driven
Parallel/Distributed
Conservative
Optimistic
Centralized
Parallel/Distributed
DTS
Fig. 1. Classification of simulation methods (DTS: distributed time-scaled simulation).
Fig. 1 shows the classification of various simulation methods including centralized and distributed discrete-event simulation, and distributed time-scaled simulation (DTS). Time-driven simulation refers to the case where every decision regarding which event to schedule next is made as needed as time advances in the physical system. On the other hand, in event-driven simulation events in the physical systems are simulated at discrete points in time and the simulation clock discontinuously advances after simulation of an event to the time of the next event. The operations of manufacturing shop floors can be viewed by either method. In the event-driven method, part-processing flow through shop floor is viewed as a chain of events with simulation of each event leading to the generation of a following event simulation until finishing required manufacturing operations. Using the time-driven approach, the shop floor is observed at different intervals of time. At each observation, the status of all components in the simulation model (e.g. parts and machines) is modified to reflect the activities and changes that occurred during the preceding time interval in the shop floor. As one of many event-driven methods, discrete-event simulation has been extensively used to predict the capacity or analyze the performance of discrete systems (Misra, 1986; Kim & Kim, 1994). In general, discrete-event simulation is conducted in a sequential manner using a variable of clock and data structure, called event list. Event list usually maintains a set of messages including time-stamp for occurrence time and description of the events. One of the major drawbacks of discrete-event simulation is that the simulations of large systems are limited by their inherent sequential structure (Misra, 1986). As an alternative, distributed discrete-event simulation has been studied to exploit the cost benefits of micro-computers and high bandwidth of communication networks by decomposing large simulation problems and executing entities on multiple processors. In distributed simulations, avoiding causality error to ensure ordering of events is a critical issue. Causality error is typically used to describe a situation as follows: an event Ex containing a larger time-stamp is processed earlier than the smallest time-stamped event Emin (Fujimoto, 1990). This situation is clearly unacceptable because the future affects the past. Such distributed discrete-event simulation can be classified into two categories: conservative and optimistic. Conservative methods strictly avoid this causality error. In these methods, any entity cannot process an event until it can determine that no other event(s) containing a smaller time-stamp will later be received. A common approach used by conservative methods is to have entities ‘look ahead’ into the simulated future to predict what events they may later schedule. Good performance has been reported for a range of problems, including simulations of queuing networks and road traffic (Fujimoto, 1989; Merrifield, Richardson, & Roberts, 1990). However, the drawback of conservative methods is that they require the application specific knowledge in order to avoid causality error leading to lower flexibility. On the other hand, optimistic methods employ a detection and recovery process to avoid causality errors. In the optimistic methods, entities are allowed to continue a simulation even though a larger time-stamped event is processed earlier. When the causality errors are detected, each entity saves its state up to current simulation time. This detection requires an entity to resimulate a previous part of the simulation. The resimulation is conducted using a method of rolling back the state of the entity currently being simulated and undoing its effects on other entities. All optimistic approaches must have some mechanisms for detecting and recovering from the causality errors. Time warp is a well-known scheme, which belongs to this category. Optimistic methods provide application independent synchronization for discrete-event simulations. Since optimistic methods do not rely on application specific knowledge, they can be used as a general synchronization mechanism, just as the event list provides a general
574
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Table 1 Comparison of simulation methods Simulation method
Advantage
Disadvantage
DTS
Extremely simple synchronization mechanism to ensure ordering of events in the simulation Minimal development and implementation effort Faster simulations can be expected and simulations can be limited by the computing or communication resources
Time-scaling can lead to errors in measurements
Distributed discrete-event
Complex synchronization mechanisms required Possibility of deadlock caused by the complexity in synchronization Considerable development and implementation effort
and application independent synchronization mechanism for sequential simulation. However, the drawback of the optimistic approach is that it incurs costs associated with state-saving overhead (Fujimoto, 1990). In time-driven simulation methods, simulation clock value increases at a constant rate. As the simulation clock advances, events with corresponding time-stamps are processed. Due to this increasing sequence of the simulation clock values, avoiding causality errors to ensure ordering of events can be relatively simple in the time-driven simulation methods. Furthermore, simple synchronization of events in these methods results in minimal development and implementation effort. Distributed time-driven simulation using communication networks can be easily achieved because of the minimized global information of synchronization. However, the shortcoming of the distributed timedriven method is that CPU time and network bandwidth may not be fully utilized because there may be no events to be simulated for long periods of time. The time-scaling approach has been introduced to overcome this shortcoming (Peacock, Wong, & Manning, 1979). The software complexity of the time-scaling approach has been compared to that of the time-warp simulation method with an order of less complexity (Duffie & Prabhu, 1994). Choosing discreteevent simulation or distributed time-scaled simulation is a design issue involving tradeoffs between complexity and maximizing utilization of CPU and network bandwidth. The main characteristics of these two techniques can be compared as in Table 1. In this paper, distributed time-driven simulation using time-scaling factors for manufacturing systems is considered, which is called distributed time-scaled simulation (DTS). This paper is organized as follows: in Section 2, the DTS approach is presented in detail. In addition, the performance of the network is evaluated to gain systematic information on the required network capability. Section 3 covers open architecture for DTS, including the communication library. In Section 4, DTS is applied for a continuous feedback control system for manufacturing shop floors, called distributed arrival time control system (DATC). Section 5 provides computational results for the performance of DTS. 2. Distributed time-scaled simulation First, the concept of the simulation clock is introduced and then time-scaled simulation is defined. The simulation clock is the abstraction of a wall clock, that is, real time, in that the state of the physical system at any real time will correspond to a logical state of the simulated system at the corresponding simulated clock. In time-driven simulation, the sequence of simulation clock time values forms an increasing sequence, that is, DtsZc, where ts denotes simulation clock and c is a constant such that cO0. While in event-driven simulation, the simulation clock sequence is still monotonically non-decreasing, but it is not an arithmetic sequence, that is, DtsR0; the sequence values represent times at which the state of the system changes, and such state changes is called events. The relationships between simulation clock and wall clock are considered here. A method is scaled if it has the property that S !tr ts Z int q (1) q where tr is wall clock, q is the quantum step size of simulation time, and S is the scaling factor. Note that since we are interested in digital simulation methods, the values assumed by simulation clock must be discrete. Due to this
Simulation clock
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
575
ts,2 ts,1
∆ts,2 ∆ts,1
ts,0 ∆tr,1
∆tr,2
Wall clock
Fig. 2. Simulation clock vs. wall clock.
property, observation of the dynamics of a system is possible with a constant rate of simulation clock elapses relative to real time. Fig. 2 shows the relationship between simulation clock and wall clock. In the DTS method, logical processes (e.g. autonomous entities) have their own simulation clock possessing the scaling factor in common. Due to the time-scaling factor in Eq. (1), nonlinear components in the physical system can be easily modeled (Peacock et al., 1979). Furthermore, DTS simulation allows the user to observe the dynamic behavior of the system as the simulation progresses in a similar way to simulation using an analog computer. Note that this approach is not limited to the simulation of manufacturing shop floors, but may be applied to any system that can be decomposed into a set of parallel processes such as computer systems and traffic flow studies. The speed of DTS simulation can be accelerated or decelerated by changing the scaling factor that presents the ratio between simulation and wall clock. Adjustment of the scaling factor executes the simulation several orders of magnitude faster than in real time. This scaling factor distinguishes the proposed approach from discrete-event simulations. Major problem of the DTS method is that the simulation may be not accurate, i.e. if the same simulation is run twice, the results may be different. This is due to variations in service time and errors in message communication leading to limitation of time-scaling factor. More specifically, the scaling factor and thus, the simulation speed is limited by the throughput and utilization of the communication network used. If the simulation is executed beyond this limit, the order of messages being return from related entities can be varied for different simulations, which in turn introduce randomness in the system. Therefore, for this approach to be viable in industrial applications, there is a need to characterize the limitation on the possible scaling factor for the DTS method related to the capability of communication networks, and a quantitative measure of this limitation is provided in the following section. 3. Open architecture for DTS Davis and Smith (1983) emphasized the requirement of distributed computing to solve complicated problems as ‘cooperative solution of problems by a decentralized, loosely coupled collection of problem solvers’. Krueger and Chawla (1991) supported the need of distributed computing with a fact that overall computing capacity is idle 91% of the time in an average network computing systems. With recent advances in communication networks personal computers distributed computing functionality becomes intrinsic elements of the system (Li & Otway, 1994). The requirement for distributed computing drives the need for integrated systems with open architecture. Furthermore, dissatisfaction with the high cost and relative inflexibility of proprietary systems results in more interests in open architecture and systems. Open architecture is concerned with the use of commodity technology to build integrating applications that link together existing applications, databases, control systems and users. The advantages the open system architecture offers are: economical, maintainable, open, modular, and scalable. Therefore, an open architecture based DTS is developed and tested in this paper to provide shop floor control systems with aforementioned advantages. Specifically, a flexible and easy-to-use communication library based on the open architecture is developed, which is used for efficient inter-process communication (IPC) between virtual entities. The communication library consists of several functions that can manage creating and terminating sockets, and sending and receiving peer-to-peer,
576
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
multicast, or broadcast messages with object-oriented structure. This communication library is developed based on WinSock standard, NetBIOS address family and NetBEUI datagram protocol for IPC. The main reason for selecting this protocol is that WinSock supports various other protocols including TCP/IP and IPX (Sinha, 1996). Moreover, highly distributed entity name management offered by NetBIOS address family eliminates the need for a central name server, the associated global information and improves fault tolerance of the system. Any entity residing anywhere in the network domain can communicate with other entity or a group of entities using multicast, allowing it to dynamically discover resources in the system. This communication library is essential to develop a simulation system based on DTS method consisting of virtual entities in this paper. In the following section, three main entities, which are used for simulating manufacturing shop floors, are described together with communication control protocol. More detailed description of the communication library is provided in Appendix A.1. 3.1. Part entity Part entities are instances of a generic object-oriented module for virtual entities and can reside in any PC in the network. Without the knowledge about where they are residing, they can be uniquely distinguished by their name because of NetBIOS address family as described. Part entities are created when the system starts, and they open communication sockets for (i) peer-to-peer, (ii) multicasting, (iii) broadcasting communication. Note that all the part entities have the membership of PART group for multicasting message. Communication control protocol between part and machine entity is shown in Fig. 3, where arrival times and completion times are denoted as ai(t) and ci(t), respectively. Part entity starts to seek available machine passing ‘MACH_TYPE_REQ’ message. It receives acknowledgement from available machine entities with the message ‘available’. Then, part entity reserves the available machine passing the message ‘MACH_RESV_REQ’. When it receives a ‘reserved’ message from the machine, part processing is requested with ‘MACH_PROC_REQ’. One round of part processing simulation is completed when the state of the part entity changes from state 1 to 4. The time elapsed from state 1 to 3 is a waiting time for processing start. It is needed to emphasize that there is minimum waiting time in DTS due to the capabilities of the communication network used, such as message latency and bandwidth. The processing time shown in Fig. 3 can be simulated as a time delay associated with time-scaling factor. 3.2. Machine entity Machine entities are created and initialized when the system is started. Machine entities are also instances of a generic object-oriented program module as part entities. These machine entities passively wait for reservation requests from part entities, and they can be in one of the following states at any time: (i) FREE; (ii) BUSY; or (iii) DONE (Fig. 3). Once a part reserves an available machine, the machine entity becomes in the state of BUSY, and it should wait for certain amount of time which corresponds to part processing time in order to shift back to the state of FREE again. In DTS simulation, part-processing time is simulated by a scaled time-delay, offering opportunity to simulate several orders faster than in real-time. After simulating part processing, the machine entity sends back a ‘completed’ message to the part entity. During the BUSY state, the machine entity accumulates reservation requests PART STATE 1 (ai(t )) STATE 2
MACHINE MACH_TYPE_REQ1 available2 MACH_RESV_REQ2 reserved2
STATE 3
FREE
BUSY
MACH_PROC_REQ2 Processing time completed2
STATE 4 (ci(t ))
DONE 1: Multicast Datagram 2: Peer–to–Peer Datagram
Fig. 3. Communication protocol for part and machine entity.
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
577
Initialize global performance
DTS simulation (best performance:Jb)
Jb
No
Yes Update Jg as Jb Fig. 4. Calculation of the global performance during simulation.
in the message queue, and the next reservation requests is served after part processing is completed. The completion of each operation includes machine set-up time, working file downloading time and so on. The processing time for operations can be identical when the identical machines are assumed. Otherwise, it will be different. Machine capacity accounts for controlling the processing time. In fact, dissimilar or identical machines can be distinguished by different machine capacity. 3.3. Evaluator The primary function of the evaluator is to collect local due-date deviations from part entities in every simulation round in order to monitor the global performance. Another function is synchronizing the simulation. After each simulation round is completed, it resets the simulation clock to zero broadcasting a ‘reset timer’ message to all the part entities. During the simulation, the best schedule can be updated and saved periodically by comparison of current best performance and present performance as shown in Fig. 4. Knowledge of the networking performance is important in order to develop DTS successfully because the communication network determines the efficiency of IPC. Latency measures the time for a packet of arbitrary size data to be sent to a remote node across the network. This factor significantly affects design of the communication control protocol between part and machine entity. In the experimental system with 100 Mbps network capability, it has been observed that the latency is, on average, 18.9357 ms for 256 Byte packet of message as shown in Fig. 5. Seven hundred (700) trials have been used to collect statistically reasonable data. Considering the communication capability of the network, a significant overhead in the communication can be observed. Fig. 6 shows the snapshot of part entities and evaluators developed using visual CCC in DTS method. 4. Application of DTS using DATC The time at which the communication protocol is initiated is referred to as arrival time, which is denoted as ai(t) in Fig. 3. In general, arrival times have a significant impact on system performance because they implicitly determine the evolution of events in the system. DTS is used to simulate such evolution of events by controlling arrival times of 250 Frequency
200 150 100 50 0 1
2
3 4 Latency(msec)
5
6
Fig. 5. Distribution of message latency (Avg.Z18.93571 ms).
578
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Fig. 6. Distributed virtual entities in different PCs.
part entities at variable speed to provide the real-time decision support. As various control techniques can be used for the control of arrival times, DTS in this paper employs a distributed arrival time control (DATC) system that continuously controls arrival time using completion time feedback to minimize due-date deviation (Cho & Prabhu, 2002a,b). In DTS using DATC, a closed-loop arrival time controller is constructed for each part entity, and tentative arrival times are iteratively adjusted to improve the control system performance. This iterative process is repeated at a faster rate than real-time according to the scaling factor used for DTS simulation, leading to a multi-variable closed loop feedback control system. Adjustment of arrival times can be expressed as a function of continuous time as follows: ð ai ðtÞ Z ki ðdi Kci ðtÞÞdt C ai ð0Þ (2) where ai(t), ki, di, ci(t) denote the arrival time, the control system gain, the due-date and the completion time of ith part, respectively. Eq. (2) can be rewritten in discrete time as follows: ai ðmTÞ Z ki ðdi Kci ððmK1ÞTÞÞ C ai ððmK1ÞTÞ
(3)
where T is the discrete time step. Fig. 7 illustrates the closed loop control structure of DATC system in discrete time. Fig. 8 illustrates that the arrival times modeled using Eq. (2) exponentially converge to a single steady-state value when the production demand in the manufacturing shop floor exceeds the available resource capacity. It has been shown that the single steady-state value of arrival times can be analytically predicted (Prabhu & Duffie, 1999). After the arrival times converge to the steady-state value, the relative order of arrival times continue to change generating various part processing sequences. DATC system keeps searching various schedules based on part processing sequence change. Thus, DATC system can be viewed as a ‘search heuristic based on feedback control’. Due–date deviation
Due–date
di
Arrival time
Disturbance pi+qi (mT )
+ _
ci (mT)
ki zi ((m–1))T+ai ((m–1)T )
zi ((m-1)T )
ai (mT)
Completion time
Fig. 7. Closed control loop of DATC system in discrete time.
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
579
Fig. 8. Trajectory of the arrival times.
Recent work has focused on developing techniques to design control system parameters such as gains in order to improve scheduling performance and predictability. In contrast to the exponential computing complexity in traditional combinatorial formulation for controlling discrete-events, the arrival time control formulation eliminates combinatorial complexity by transforming the scheduling problem into a continuous variable control problem. DATC system has been found to have exponential convergence rate which makes it attractive for real-time scheduling (Cho & Prabhu, 2002a). Because the controllers are fully distributed the computations for each controller can be executed on a separate processor in parallel, making them inherently suitable for massively parallel/distributed computing. The implementation of the DTS using DATC can be outlined as follows: Step 1: Create virtual entities including parts, machines and evaluator. Step 2: Read input parameters: routing information, initial arrival times, processing times, due dates, control gains, iteration. Step 3: Reset simulation clock. Step 4: Start simulation clock. Step 5: Part reserves machine when the simulation clock becomes equal to arrival time. Step 6: Machine returns ‘available’ message to the part when it becomes idle (queuing time is included here). Step 7: Machine starts processing at the speed set by the scaling factor. Step 8: Part receives ‘part completion’ message with the completion time information. Step 9: Adjust arrival time with the completion time using Eq. (3). Step 10: Send the due date deviation information (di – ci) to the evaluator for performance monitoring. Step 11: Go to Step 3. The communication between parts and machines during DTS is shown in Fig. 9 with underlying NetBEUI protocol. To make this simulation available, two system files should be revised as described in Appendix A.2. Also, CCC code for implementing the above outline in DTS is provided in Appendix A.3. Similar program codes to Appendix A.3 for machine and evaluator can be accessed by contacting the author. 5. Computational experiment As one of key factors for manufacturing productivity, effective scheduling can improve on-time delivery, reduce inventory, cut lead times, and improve the utilization of bottleneck resources. Because of the combinatorial nature of
580
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
NetBEUI
SendTo (Fadal, “request processing”)
ReceiveFrom (PART, szMsg)
ACTION
ReceiveFrom (Fadal, szMsg )
ACTION
PART ENTITY †: Multicasting,
SendTo (PennCube, “processing done”)
MACHINE ENTITY : Peer–to–peer
Fig. 9. Communication between parts and machines in DTS.
scheduling problems, it is often difficult to find optimal schedules, especially within a limited amount of computational time. Furthermore, job shop scheduling problems are known as one of the most complicated problems because of their complexity. Note that in job shop configurations, routing for part processing can be different from that of other part processing. Using DTS simulation can generate production schedules fast because it decomposes these complex problems into distributed computing structure using communication network. DTS is based on the message passing between part and machine entities. As described in Section 2, the message passing is controlled by communication control protocol that regards state changes in both entities. While in centralized simulation, arrival times are updated by queuing times and processing times as expressed in Eq. (2), they are affected in DTS by the communication delays in addition to the queuing and processing times. Suppose several parts request their processing to unique machine at approximately identical time with infinitesimal difference. The order with which part entities request their processing can be different from the order with which they are served by the machine entity because of the communication delays leading to the unexpected waiting time until the machine entity becomes free. If the communication delays play some role in simulation, the scheduling performance of DTS can be different from that of the centralized simulation algorithm. The effect of the communication delays can be referred to as random tie-breaking policy in terms of scheduling theory. Since communication delays are related to the time scaling factor in DTS, characterizing the limitation of the scaling factor is important. This characterization will provide information on the trade-off between simulation speed and scheduling performance. Two job-shop scheduling problems are tested in this section. Required computational time for time-scaled simulation is associated with the scaling factor and minimum bandwidth for the communication is also discussed. The results of DTS are compared to the results of a centralized algorithm. The structure of the centralized simulation algorithm can be outlined as follows: Step 1: For iZ1 – n ai ðmTÞZ ki ðdi Kci ððmK1ÞTÞÞC ai ððmK1ÞTÞ Next i Step 2: Sort ai using FCFS dispatching policy Step 3: For iZ1 – n Compute ci(m) P Next i ðd ðmÞKc ðmÞÞ2 Compute MSD(m), where MSDðmÞZ i i n i Step 4: Go to Step 1
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
581
Table 2 Two parts and two machines job-shop problem Part
Operations
Routing
Due-date
Processing time
Part1 (p1) Part2 (p2)
2 2
Milling (m1), Turning (m2) Turning (m2), Milling (m1)
10 10
1, 2 2, 1
As outlined above, arrival times are adjusted to reduce the deviations between the due dates and the completion times at each iteration in this algorithm, leading to the trajectory of arrival times as shown in Fig. 8. The centralized algorithm also uses an arrival time controller to adjust event timing. It should be emphasized that the computational complexity of the centralized algorithm is described as polynomial because of the sorting function in Step 2. In this computational experiment, Matlab program has been used for the implementation of the centralized simulation algorithm. 5.1. Two parts and two machines case A problem instance for two parts and two machines has been given in Table 2 with due-dates as a common due-date. In this problem instance, two different machines are required to process two operations of each part. Virtual entities are distributed in two personal computers (PCs) connected over 100 Mbps communication network. Denoting the time-scaling factor as S, due-date and processing times for DTS can be rewritten as follows: d Z Sd; p Z Sp Setting the scheduling objective as to minimize the due-date deviations (J), J 0 for scaled due-dates and processing times can be expressed as J0 Z
J S2
Four scaling factors S1Z1.0, S2Z0.1, S3Z0.05 and S4Z0.01 are used to examine the trade-offs between simulation speed and system performance. Approximately, the computational time required to complete DTS with the scaling factor S can be expressed as Te Z SchLPTi I
(4)
where Te, chLPTi, I denote a computational time, completion time of LPT sequence and number of iterations, respectively. Note that the required computational time for the DTS is linear function of iterations, while it is a polynomial of the iterations in case of centralized algorithm. Therefore, DTS with scaling factor S4 is run 100 times faster than with scaling factor S1 for the same problem instance. Fig. 10 shows arrival time trajectories of DTS method with four scaling factors and a centralized algorithm using single PC. Each arrival time trajectory has been obtained using identical initial conditions of the arrival times. It has been observed that arrival time trajectory with scaling factor S2(Z0.1) becomes different from that of the centralized simulation. Note that the average latency of used communication network (100 Mbps) has been tested as 18.94 ms in Section 2. Therefore, the minimum required time to simulate the state transition of part entity from State 1 to State 4 in Fig. 3 is 111.84 ms (Z18.94!6). Scaling factor S2 simulates the smallest processing time, 1 s as 100 ms. Communication protocol cannot control 100 ms because it exceeds the minimum resolution of simulation with a used communication network. Fig. 11 illustrates average deviations in arrival times with different scaling factors from the centralized method. Note that as simulation speed increases, the deviations of arrival times from the centralized method increase. In addition, the best scheduling performances (MSD) have been obtained as 0.25, 0.25, 0.07, 0.18, and 0.00 for centralized, S1, S2, S3, and S4, respectively. In the DTS based on the DATC approach, the second operations of parts start as soon as machine entities become free due to its control structure. Hence, the best performance of the centralized simulation and the DTS with SZ1.0 has been obtained as 0.25, while in the DTS with the scaling factor below 0.1 the best performance can be improved and even can
582
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
7
7
6
6
Arrival Times
(b) 8
Arival Times
(a) 8
5 4 3
5 4 3
2
2
1
1
0
0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Iterations part1(S=1.0)
part2(S=1.0)
part1(MatLab)
Iterations part1(S=0.1)
part2(MatLab)
7
7
6
6
Arrival Times
(d) 8
5 4 3
part2(MatLab)
4 3 2
1
1
0
part1(MatLab)
5
2
0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Iterations part1(S=0.05)
part2(S=0.05)
part1(MatLab)
Iterations part2(MatLab)
part1(S=0.01)
part2(S=0.01)
part1(MatLab)
Fig. 10. Arrival time trajectories in DTS (nZ2, mZ2).
1.4 ABS(Arrival_matlab - Arrival_DTS)
Arrival Times
(c) 8
part2(S=0.1
1.2 1 0.8 0.6 0.4 0.2 0 0.0
–1.0
–1.3
–2.0
log10(S) Fig. 11. Average deviation of arrival times for different scaling factors (nZ2, mZ2).
part2(MatLab)
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
583
Table 3 Problem information for six parts and four machines case Parts
Operation
Routing
Processing time
Due-date
1 2 3 4 5 6
3 4 2 4 4 2
(m1,m3,m2) (m2,m3,m1,m4) (m1,m4) (m2,m3,m1,m4) (m3,m4,m1,m2) (m3,m4)
(1,2,3) (1,2,3,4) (1,2) (1,2,3,4) (1,2,3,4) (1,2)
17 17 17 17 17 17
be zero because of the inserted idle time between two operations that has been caused by communication delays randomly. Specifically, the MSD performance has been improved by introduced randomness in starting times. It should be pointed out that although the performance has been improved, it is not desirable to have randomness in the control system in general. Also, note that when the scheduling objective is set-up to a different measure such as minimization of Work-In-Process (WIP), lower values of scaling factor can degrade the scheduling performance. 5.2. Six parts and four machines case Another example of a job-shop problem, where four machines are required to process six parts, is given as Table 3. Fig. 12 shows arrival time trajectories in this example of DTS with two scaling factors S1Z1.0 and S2Z0.1, and centralized simulation (M). Fig. 13 shows the average deviations of arrival times of DTS from the centralized simulation. It can be observed that while arrival times in centralized and DTS with S1 are comparable, arrival time trajectories in DTS with S2 are not comparable to those of the centralized one due to communication delays, which result in undesirable change of the part processing sequences as described in Section 3. The best scheduling performance has been obtained as 6.821, 6.527, and 5.471 for centralized simulation and DTS simulations with scaling factors S1, S2, respectively. As in two parts and two machines job-shop problem, lower scaling factors have generated better MSD scheduling performance.
part1(M) part2(M)
Arrival Time Trajectory 18
part3(M)
16
part4(M) part6(M)
12
part1(S=1) part2(S=1)
10
part3(S=1)
8
part4(S=1) part5(S=1)
6
part6(S=1) part1(S=0.1)
4
part2(S=0.1)
2
part3(S=0.1)
0 97
89
81
73
65
57
49
41
33
25
17
9
part4(S=0.1) 1
Arrival time
part5(M) 14
Iteration Fig. 12. Arrival time trajectories in DTS (nZ6, mZ4).
part5(S=0.1) part6(S=0.1)
584
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Deviations in arrival time
Deviations from centralized method 2
S=1.0 S=0.1
1.5 1 0.5 0 1
9
17
25
33
41 49 57 Iterations
65
73
81
89
97
Fig. 13. Deviations in arrival time from centralized simulation method (nZ6, mZ4).
5.3. General case Centralized simulation method described in above is based on a sorting function that results in a polynomial computational time. However, this sorting function is replaced by FCFS policy in DTS method for handling receiving message that results in a linearly increasing running time. DTS using DATC has been tested for general problems of shop floors with the number of part entities up to 400 and 4 machine entities. Fig. 14 shows that running times of DTS for two different testing configurations: (1) part entities ranging from 10 to 100 are simulated using a single PC; and (2) same parts are simulated using two PCs over the communication network. Note that in both configurations simulation is executed using DTS method not using the centralized program. It can be observed that distribution of part entities into multiple PCs can reduce communication overheads leading to faster simulation speed. In Fig. 15, up to 400 part entities are distributed over four PCs with four machine entities. Running time of DTS method is shown to be linearly increasing as the number of par entities increase in this figure. In addition to this test, running time of DTS method has also been compared to another centralized simulation method using Arena RT for 50 part entities. It has been observed that running time of DTS is 1/3 of that of Arena based centralized simulation. 6. Conclusion
Time for one iteration (sec)
A highly distributed and time-scaled simulation method for manufacturing shop floors was presented in this paper. It has been shown that the required time to simulate shop floor using a time-scaled simulation approach is a linear function of iterations, while it was polynomial in centralized simulation. The minimum resolution of
50 45 40 35 30 25 20 15 10 5 0
1 PC
10
20
2 PCs
30
40
50 60 No. of parts
70
80
Fig. 14. Running time of the DTS using one and two PCs.
90
100
Time for one iteration (sec)
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
585
90 80 70 60 50 40 30 20 10 0 100
200
300
400
No. of Parts Fig. 15. Running time of the DTS using four PCs (all jobs with 3 operations).
the distributed time-scaled simulation is identified as 111 ms when a communication network with 100 Mbps capability is used. This factor restricts the maximum allowable scaling factor to accelerate the simulation speed. The time-scaling factor distinguishes the proposed approach from optimistic methods such as time-warp simulation. Distributed control structures and time-scaling factors make the proposed approach an attractive alternative to traditional discrete-event simulation approaches. The benchmark with the centralized simulation method shows that the distributed time-scaled simulation can generate better schedules than the centralized methods for the tested job-shop scheduling problems. Although there is some success in speeding up the simulation speed by changing the time-scaling factors, the limitation is strongly related to the capability of the communication network, which can be characterized by message passing latency. Recently, virtual interface (VI) architecture has gained much attention because it can significantly reduce the latency and increase bandwidth bypassing operating systems for the communication. Appendix A A.1. Communication library Four (4) subroutines have been developed using Microsoft Visual CCC and MFC Class. Basically these four functions have been designed for the purpose of peer-to-peer, multicasting and broadcasting communication without client/server paradigm. Refer the following descriptions of these concepts: † Peer-to-peer: communication between any two processes † Mulitcasting: communication between a process and groups † Broadcasting: communication between all the processes
A.1.1. int CPennDiConCom::InitSockets(char *szProcess, char *szGroup); This function initialize Windows sockets with given specific process name and group name which the process belongs to. This function automatically binds a socket to the specific process. Routine
Required header
Compatibility
InitSockets ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value InitSockets function returns the value of 0 if this is called successfully. The return value is 1 for an error during the creation of sockets. Parameters SzProcess Character pointer for the process name SzGroup Character pointer for the group name which the process belongs to
586
Routine
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
Required header
Compatibility
Remarks Both length of string szProcess and szGroup are equal or less than 16. This is the regulation of NetBIOS and both process name and group name are case sensitive. This function contains WSAStartup function of WinSock Library. Sockets are created with nonblocking mode.
A.1.2. void CPennDiConCom::CloseAllSockets(void); This function closes all open sockets that have been created by calling of InitSockets function. Routine
Required header
Compatibility
CloseAllSockets ANSI, Win 95, Win NT, Win32s hsockutil.hi Remarks Since CloseAllSockets contains WSACleanup of WinSock library, it should be called before the termination of main program.
A.1.3. int CPennDiConCom::SendTo(char *To, char *szMsg, int len); The SendTo function is used on datagram sockets and is used to write outgoing data on a specific peer-to-peer socket, multicast socket or broadcast socket by the To parameter. Routine
Required header
Compatibility
SendTo ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value SendTo function returns the value of 0 if this is called successfully. The return value is 1 for an error during the outgoing procedure of messages to sockets. Parameters To Character pointer for the target name (process or group name) SzMsg Character pointer for the message Len Integer value of Sizeof(szMsg) Remarks This function contains sendto function of WinSock library with SOCK_DGRAM identifier. Due to this function not function send, accept and listen functions for the Client/Server paradigm are not called for here.
A.1.4. int CPennDiConCom::Receive(char *From, char *szMsg, int len); The Receive function is used to read incoming data on a (possibly connected) socket and capture the address from which the data was sent. Routine
Required header
Compatibility
Receive ANSI, Win 95, Win NT, Win32s hsockutil.hi Return value If Receive function succeeds, it returns the value of 0 and returns the value of 1 for an error during the reading procedure of messages to sockets. Parameters From Character pointer for the target name (process or group name) SzMsg Character pointer for the message Len integer value of Sizeof(szMsg) Remarks This function contains recvfrom function of WinSock library with SOCK_DGRAM identifier. Due to this function not function recv, accept and listen functions for the client/server paradigm are not called for here. Since, the sockets are created with nonblocking mode, it does not wait for coming data.
A.2. Setting up configuration files for DTS Services and protocol files under C:\Windows\System32\Drivers\Etc directory should be modified by the user before running the communication program which is using WinSock based on NetBIOS (NetBEUI). In the DTS,
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
587
a fictitious service name ‘PennDiCon’ is used. Therefore, user must include this service name in the services file with unreserved port number (here, 5001) and protocol name (here, NetBEUI) as shown in the following files.
A.3. CCC code for part entity in DTS
588
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
589
590
S. Cho / Computers & Industrial Engineering 49 (2005) 572–590
References Cho, S., & Prabhu, V. V. (2002a). A vector space model for variance reduction in single machine scheduling. IIE Transactions, 34, 933–952. Cho, S., & Prabhu, V. V. (2002b). Sliding mode dynamics in continuous feedback control for distributed discrete-event scheduling. Automatica, 38(9), 1499–1515. Davis, R., & Smith, R. G. (1983). Negotiation as a metaphor for distributed problem solving. Artificial Intelligence, 20(1), 63–109. Duffie, N. A., & Prabhu, V. V. (1994). Real-time distributed scheduling of heterarchical manufacturing systems. Journal of Manufacturing Systems, 13(2), 94–107. Fujimoto, R. M. (1989). Time-warp on a shared memory multiprocessor. Transactions of the Society for Computer Simulation, 6(3), 211–239. Fujimoto, R. M. (1990). Parallel discrete event simulation. Communication of the ACM, 33(10), 31–53. Kim, M. H., & Kim, Y. (1994). Simulation-based real-time scheduling in a flexible manufacturing systems. Journal of Manufacturing Systems, 13(2), 85–93. Krueger, P., & Chawla, R. (1991). The stealth distributed scheduler IIE international conference on distributed computing (pp. 336–343). Li, G., & Otway, D. (1994). An open architecture for real-time processing. ICL Systems Journal, 9(2), 213–221. Merrifield, B. C., Richardson, S. B. & Roberts, J. (1990). Quantitative studies of discrete event simulation modeling of road traffic. Proceedings of SCS Multiconference on Distributed Simulation (pp. 188–193). Misra, J. (1986). Distributed discrete-event simulation. Computing Surveys, 18(1), 39–65. Peacock, J. K., Wong, J. W., & Manning, E. G. (1979). Distributed simulation using network of processors. Computer Networks, 3, 44–56. Prabhu, V. V., & Duffie, N. A. (1999). Nonlinear dynamics in distributed arrival time control of heterarchical manufacturing systems. IEEE Transactions on Control Systems Technology, 1(6), 724–730. Sinha, A. K. (1996). Network programming in Widows NT. New York: Addison-Wesley.