A Distributed Search and Simulation Method for Job Flow Scheduling S. R. Jernigan, S. Ramaswamy, and K. S. Barber The Laboratory for Intelligent Processes and Systems Electrical and Computer Engineering The University of Texas at Austin Austin, TX 78712 http://www-lips.ece.utexas.edu
[email protected] phone: (512) 471-6152 fax: (512) 471-3652
Abstract Simulation serves as an effective decision support tool in flexible manufacturing systems for understanding and analyzing the effect of changes to the system environment. Due to the variety of situations that have to be evaluated, a generative scheduler for such a system must be more flexible than its realistic equal while still producing detailed and accurate schedules. This research presents a possible solution to this problem and is intended for use in a distributed, reactive, virtual environment. The solution exploits the advantages gained by using multiple processes in a distributed environment to create, simulate, and evaluate possible schedules. The system is designed on the premise that a distributed parallel search and simulation of competing schedules with accompanying heuristics and subgoaling will greatly reduce the search space and control the state space explosion. The architecture implemented in this research exhibits a paradigm shift by focusing on scheduling over a distributed network of computing resources, each of which is ultimately responsible for their individual capabilities. Moreover, the need for cycle and deadlock detection is eliminated, thereby decreasing the overall complexity and computational requirements.
Accepted to SIMULATION Volume 68: Number 6 June 1997 pgs. 377-401
Contact Person: Professor Charles M. Shub Technical Editor, SIMULATION Computer Science Department University of Colorado at Colorado Springs Box 7150 Colorado Springs, CO 80933-7150
July 1995
1
A Distributed Search and Simulation Method for Job Flow Scheduling * S.R. Jernigan, S. Ramaswamy ** , K.S. Barber The Laboratory for Intelligent Processes and Systems The Department of Electrical and Computer Engineering The University of Texas at Austin, Austin, TX 78712-1084
Abstract Simulation serves as an effective decision support tool in flexible manufacturing systems for understanding and analyzing the effect of changes to the system environment. Due to the variety of situations that have to be evaluated, a generative scheduler for such a system must be more flexible than its realistic equal while still producing detailed and accurate schedules. This research presents a possible solution to this problem and is intended for use in a distributed, reactive, virtual environment. The solution exploits the advantages gained by using multiple processes in a distributed environment to create, simulate, and evaluate possible schedules.
The system is designed on the premise that a
distributed parallel search and simulation of competing schedules with accompanying heuristics and subgoaling will greatly reduce the search space and control the state space explosion. The architecture implemented in this research exhibits a paradigm shift by focusing on scheduling over a distributed network of computing resources, each of which is ultimately responsible for their individual capabilities. Moreover, the need for cycle and deadlock detection is eliminated, thereby decreasing the overall complexity and computational requirements.
Keywords: reactive simulation, heuristic, manufacturing, scheduling
* This research was supported in part by the Texas Higher Education Coordinating Board under Grant ATP-115 and the National Science
Foundation under NFS DMI-9500266. ** Dr. S. Ramaswamy is currently with the School of Computer and Applied Sciences, Georgia Southwestern College, Americus, GA 31709.
1. Introduction Increasing economic pressure has steadily driven manufactures toward partial or complete automation of their production facilities. While the costs associated with automation have decreased, the demand for low cost, high quality goods have increased enormously. Besides the efficient use of raw materials by producing less scrape and waste, automation also reduces Work In Progress (WIP) by introducing less variability and thus allowing for more efficient scheduling. The operation of a factory floor requires the existence of a schedule. The schedule specifies the order of operations for each part and the resources with which to perform those operations. For a flexible manufacturing system (FMS), the scheduler, the entity that constructs schedules, must be flexible enough to efficiently handle changes in products and processes. A scheduler in the simulation of a FMS must allow for extreme changes in the products, processes, and even capabilities. Due to the variety of possible situations simulated, the schedule must be more flexible than its realistic counterpart. On the other hand, the produced schedule must still be accurate, realistic, and efficient so that it can reliably evaluate possible changes to the physical factory floor or the parts produced. Traditionally, scheduling has been addressed by two diverse approaches. These include: (i) Numerical methods, and, (ii) Simulation. Numerical methods attempt to solve a problem using analytical techniques but often fail to catch the appropriate level of detail. For instance, relaxation techniques, as in [ChLi94], have limited practical application because they assume that processing times, down times, success rates, etc., are deterministically known. Queuing theory methods can model the steady-state operation, but cannot model transients due to the assumptions made to improve computational efficiency. The inability in developing an accurate set of constraints, makes the numerical approach complex and expensive for use in large systems. These approaches often result in a static schedule. Special run-time conditions are poorly handled or not handled by many numerical approaches (see Section 4.2). Simulation can thus prove to be a simple alternative; it has the advantages of being useful in the study of both steady state and transient (dynamic) system behavior. However, a simulation might result in the exponential growth of possible schedules and this makes it highly complex and computationally intensive. With the use of effective search algorithms for selecting candidate schedules, simulation becomes a powerful tool in evaluating system schedules. The objective in using simulation techniques in scheduling is to generate a maximally constrained schedule. A maximally constrained schedule is one that contains all the necessary details to instruct every machine so that the schedule can be executed. Many scheduling techniques do not hold at this level of detail as a result of their simplifying initial assumptions. Evaluation of a maximally constrained schedule demands that the true dynamic nature of the system be modeled. Several generic simulation systems are available. The interfaces of these packages vary from a programming language interpreter to a complete graphical user interface. These packages include AutoMod II [Bank90], WITNESS [Holl86], SIMFACTORY [LaKe91] [Bank90], GPSS [WiSS90] [Bank90] [Chis89] [LaKe91], SIMAN/Cinema/Arena [LaKe91][PuPu89] [Bank90], and SLAM [LaKe91][MoEv94] [Bank90]. Comparison reviews of simulators for evaluation in manufacturing environments can be found in [LaHa89] and [Bank90]. Unfortunately, all of these packages are designed to perform simulation as an analysis tool. That is, the system to be studied is modeled, perturbed in some interesting fashion, and simulated to predict what changes that perturbation would cause in the real system. Simulation studies performed in this fashion are widely prevalent in the literature and have had
3
positive results in many areas including floor layout, dispatch rule evaluation, batch sizing, and line balancing. In this research, simulation is used as an generative method for reactive scheduling. Given this use, these packages are not well suited and inefficient. Furthermore, they do not exhibit the level of modularity required for this research and severely limit the implementation of any modules that are allowed. None of the above simulation packages are distributed across several processes and their interfaces would make the rest of the scheduler's implementation difficult. No packages exist, to the authors knowledge, that are well suited for use in this research. For these reasons, a new discrete event simulation, DES, was implemented as discussed in Section 3.2. This work addresses the problem of using simulation for generative scheduling of a FMS while avoiding the computational difficulties of an exponentially large set of possible schedules as well as the inaccuracies associated with numerical or static methods. The growing availability of computing power lowers the cost for this approach to scheduling and the approach is gaining in popularity. For instance, [LeFi94] describe a "simulation-based planning" system for military war games. In this paper, the scheduling process is viewed as the selection of a solution from a large number of possible solutions. Given this perspective, classical AI search methods are used to find the best solution or schedule, while a new distributed, discrete event simulation (DES) method is developed and used to generate competing schedules within the search process. The system proposed in [LeFi94] attempts to limit the computational difficulties of the problem by reducing the level of detail for planning. Since this detail is vital for schedule accuracy and completeness, this system reduces the computational complexity through two primary methods.
First, the architecture separates planning from the on-line
scheduling component as suggested by [FoKe85]. Second, the system limits the search space through the use of both domain dependent and domain independent heuristics. The scheduling system uses the following techniques: (i) Reactive(dynamic) scheduling techniques to take advantage of run-time information, (ii) Modified DES to accurately generate the possible schedules and to allow for points of non-determinism, (iii) Object oriented, modular design of the factory floor so that modules are easy to design, maintain, adapt, and update, (iv) Distributed computing to increase the computational speed of the scheduler, and, (v) Heuristics and subgoaling to limit the state space, the theoretical space containing all the solutions. The advantages of the distributed search and simulation approach described in this paper are: (i)
The implementation of the distributed simulation
environment reflects the requirements foreseen in future schedulers (e.g. scheduling for various machines requires different reasoning capabilities and the scheduler may profit from the use of radically different methods for that reasoning), (ii) The simulation approach handles the level of detail needed for use in a reactive scheduling system by producing a maximally constrained schedule, (iii) The layout of the factory and specification of parts is easily modified and the schedules immediately reflect changes so that the simulation system can be used in an interactive decision support role, and, (iv) The exploratory research in this paper expands on-line scheduling to encompass several machines or workcells through the use of the proposed distributed search and simulation method. This paper is organized as follows: Section two describes the proposed system architecture and discusses some of the basic issues for the implementation. Section three presents the implementation of the new scheduler. In section four, three examples of the scheduler are presented. The first example details the application of the scheduler to a simple assembly line. The other examples illustrate the capabilities of the scheduler to address two classes of problems: (i) systems with
4
flexible, redundant machine capabilities, and (ii) systems with multiple products on a single line. Section five concludes the paper.
2. System Architecture Flexibility and automatic reconfigurability are two important issues for any scheduler [StJo93, Bell93]. Any scheduling algorithm must be able to rapidly incorporate changes. Moreover, the constraints and capabilities of a machine may be dynamic (e.g. processing rates are affected by tool wear) and need to be accounted for in the schedule. The ability of the scheduler to respond to machine failures and performance consistently under modified situations enhances its ability to develop robust and more realistic schedules. In a simulation, the above issues will be paramount to determining the scheduler's success or failure. The search space of possible schedules is dependent on the current resource capabilities.
Therefore, the
scheduler's must have some knowledge of the resource capabilities. However, the individual system components (i.e., individual system component models) are the ultimate authority on their capabilities. Instead of collecting this resource information in a single model for consideration by a central process, the proposed architecture distributes both the scheduling process and the model to the individual system components. The distribution of the scheduling task allows each component to, in essence, schedule itself according to its capabilities and availability; thus achieving the appropriate level of accuracy and detail. It is, therefore, the assumption of this work that factory floor resources, or a simulation of them, are uniquely coupled with a software scheduling resource. This is a paradigm change from a central controlling computer scheme popular in most current manufacturing environments to a scheme involving a distributed network of computing resources. This assumption foresees future vendors supplying a software reasoning element with new hardware resources. Recently, due to the efforts of the automotive industry, the "Realistic Robot Simulation" initiative has already resulted in vendor supplied simulation packages for robotic manipulators [BeSW94]. Advantages of such a distributed architecture include: modularity, loose coupling, heterogeneous reasoning, speed, and flexibility. The proposed scheduling system is broken down into components; each component is composed of software modules directly associated with a physical resource on the factory floor. The only exception to this rule is a central sequencer which acts mainly as a time keeper for the whole system. Figure 1 illustrates the components and modules for a sample portion of an assembly line. Each factory floor hardware resource has at least two software modules directly associated with it. These are: (i) Operation Module: This module directs and monitors the current execution of the hardware resource, and, (ii)
Scheduling Module: This module closely communicates with its associated operation module to
determine the current state of the resource and to set the current schedule. The scheduling module, combined with the sequencer, forms the scheduler (shaded box in Figure 1). Each component maintains information about its state, capacities, capabilities, past records of performance, and connections to other components. Therefore, components can be updated and expanded independently. Moreover, each component has a method for communicating with its neighbors, but no global picture of the connectivity of the system is immediately available. With the exception of the central sequencer, the systems' communication and interconnection structure is strongly tied to the geometric layout of the factory floor. Much like a fire brigade where buckets of water are passed from person to person, each component only needs to communicate with its neighbors for the system to operate properly. The simplicity of this scheme is attractive because the system is easy
5
to implement and it simplifies
Sequencer
Scheduler Module
Scheduler Module
Scheduler Module
Scheduler Module
Scheduler Module
the
requirements
on
the
communications environment as well as
Operations Monitor
Operation Module
Operation Module
Operation Module
Operation Module
Operation Module
the components. In the sequel,
the
various
steps involved in the scheduling process of
Planner
the
architecture
are
further explained. The existence of Floor Component
Floor Resources
many
components
system (e.g.,
a
planner) is assumed to allow the definition of Figure 1: Proposed External Architecture
the
scheduler’s
interface.
In a virtual
manufacturing environment, the factory hardware resources are simulated by software. However, since it is convenient to think of the factory resources as real hardware resources, the rest of this paper will make no delineation between simulated factory floor hardware resources and real hardware components. Although this paper does not discuss a knowledge representation method, the capability to reason with a set of knowledge elements is closely linked with the method used for knowledge representation. Therefore, some capabilities of the knowledge representation method and the reasoning to be used are defined to effectively design and implement this architecture. The advantage of leaving out the detailed specification of the knowledge representation method is that it is open for modifications and hence the scheduler is applicable in various domains. The information to be used by the scheduler is classified into three distinct bodies of information: (i) Floor configuration: The floor configuration, implicit in the floor layout, limits or defines the possible paths parts can take when transitioning between floor resources, (ii) Resource information: This defines the state of the individual resources on the factory floor. It includes the type of machines, the machine capabilities and tolerances, machine maintenance schedules, and any other constraints introduced by the facility. Since this representation is only shared between the scheduler module and its associated operations module, the representation could vary widely and may be vendor specific, and, (iii) Part representation: Contrary to the resource representation, the part representation may transition through all the scheduling modules and must be standardized to allow for reasoning in each module. The part information contains the partial orders that define how to manufacture the part, its final configuration, any goal and sub-goals that may help with inspection and scheduling, and its history of previous manufacturing processes.
6
The representation of the part and process information can be separated from the design of the system if the following minimum capabilities are assumed: (i) The resource knowledge representation must allow each scheduling module to independently reason about the processes that its associated factory resources can perform, (ii) The part representation must allow an individual scheduling module to determine if the part requires any of the processes from its associated factory resource. Therefore, the representation for a part must contain a plan at the beginning of the scheduling process. These representations do not include the global part mix or any relations to other parts beyond subassemblies, (iii) The part representation must preserve enough information at the end of the scheduling stage to form a maximally constrained schedule, and, (iv) The part representation must be able to indicate what the expected state of the physical part should be at various points of the schedules' execution so that it can be checked by an operation modules. A modified AND/OR tree is used for part representation and resource representation in the implementation of this research. These modifications allow the tree to explicitly represent XOR representations, thereby improving the expressiveness of the representation in capturing some manufacturing concepts.
2.1. Nondeterminism Points of determinism (and nondeterminism) can be classified as: (i) time-based, or, (ii) event-based. Most traditional DESs exhibit time-based nondeterminism due to the use of random number generators. On the contrary, a traffic signal, for example, is deterministic with respect to events. That is, the chain of events is deterministically defined. However, many domains are not so strictly defined. Given some state, it is possible that several next states are possible (i.e. more than one event could be chosen as the next event). In the assembly domain, the plan may allow a machine to choose which process it is going to perform when a part reaches its station. In this case, the simulation is nondeterministic with respect to events. Due to the unavoidable variances in processing time, determinism with respect to time will always exist. Therefore, the discussion of determinism is restricted to determinism with respect to events. Ideally two distinct points of nondeterminism can be distinguished: (i) Nondeterminism based on floor resources: For each machine a part reaches, a machine may have the choice of performing one or more processes or passing the part through unchanged. This type of nondeterminism is due to flexibility in the plan and multiple capabilities of a floor resource, and, (ii) Nondeterminism based on material handling systems : Active materials handling modules may have a choice between two or more sources from which to draw the next part or two or more sinks to which the current part could be transported.
Each of the choices for the point of nondeterminism represents an alternative schedule that must be
considered. The generation of schedules in the manner is similar to a branch and bound search discussed below.
2.2. Branch and Bound Simulation The primary modification made to basic sequential simulators in this research is the ability to handle points of nondeterminism. When a point of non-determinism occurs, the simulation is divided into multiple simulations. Each new simulation represents the selection of one of the possible choices. If the simulations process mutually events with respect to communications between machines, then these simulations may proceed in parallel. However, the sequencer can control the progression of the simulations1 . Since the events are simulated in distributed processes, the simulation of more than 1 Hereafter, the term universe will be used to denote a single simulation, while the term simulation will be used to denote the simulation as
a whole.
7
one universe can proceed at any given time. Thus, parallelism is introduced without the complexity of parallel simulation methods and the implementation of heuristics is straightforward. The parallel search for a schedule is controlled with heuristics to control state space expansion. Such a heuristic is a maximum bound on the cost function; while universes that exceed this bound are terminated, universes that successfully complete beneath this bound are used to define new upper bounds.
The bound automatically terminates deadlocked or cyclic solutions without special watchdog procedures
monitoring the progress in each universe. The elimination of these extra procedures reduces the computation time.
2.3. Search Space Reduction The scheduler has to limit the number of schedules it can consider on-line to enable it to make decisions within certain time periods. In this system, the application of heuristic rules limits the number of considered schedules. Most heuristics that are specific to manufacturing are not admissible. The use of non-admissible heuristics jeopardizes the optimality of the search. However, the most optimal solution is not always required and a stronger, non-admissible heuristics can be used to quickly find suitable solutions. These solutions are often very close to the optimal solution. Therefore, the gain in computation speed is worth a slight loss in optimality [RaTR89]. In the examples discussed in later sections, we used heuristics that bound the maximum schedule time, prevent needless cycling when the factory has reentrant loops, impose restrictions on the portion of the schedule that has already been formed, and impose restrictions on the remaining steps in the plan. In the implementation, these heuristics are represent by special keywords in the extended AND/OR tree used to initialize the modules. Using only bound limiting heuristics, the initial number of simulations will be large until the simulation times begin to near the bound. In practice, the initial choice of the bound could be artificially specified to eliminate the complete generation of all sub-optimal solutions. Often, the initial bound is set to a maximum which can be trivially calculated. The bound can be reduced as each candidate schedule completes. Identifying sub-optimal universes early and terminating them will save processing time. Subgoals are a method of reducing the search space by forcing the solution to include an intermediate state. While no global subgoals are identified for universes in general, subgoals for individual parts are easily recognized. The most common and easily implemented subgoal is a subassembly. For instance, universes that contain parts where the subassemblies are not complete by the time they are in final assembly should be terminated. Furthermore, it is often well know that certain subassemblies must be completed long before the final assembly area. Artificial subgoals can be introduced to force the final schedule to use a certain machine for a specific process. Many termination heuristics are domain specific and are implemented within the scheduling components closely associated with domain workstations. For instance, in a machining environment, a termination heuristic within a milling scheduling component might specify that universes be terminated if they require a milling operation where a portion of the slot to be milled has already been drilled with an irregular shaped bit. While termination heuristics control the number of universes by removing unattractive ones, branching heuristics control the number of universes by not creating all the possible choices at a point of nondeterminism. As stated earlier, branching is the result of a nondeterminism and nondeterminism arises either due to the availability of multiple processes or multiple paths. In this work, dispatch rules for FIFO and shortest job first rules have been implemented to convert nondeterministic points into deterministic points, or at least reduce the degree of the non-determinism(i.e., the number of alternative choices).
8
3. Implementation In this section, the current implementation of the system will be discussed in the context of a simple example. A more complete discussion of the implementation can be found in [Jern96]. As discussed in the previous section, a scheduling module exists for every resource of the (simulated) factory floor. Figure 2 is a sample layout for an assembly line with multiple machines, an inspection station, and a reentrant pathway. Figure 3 shows the scheduling modules and connections that correspond to the example factory floor in Figure 2. The arcs show the possible routes and directions parts may travel. The communications between modules are limited to modules with connecting arcs. All communications are bi-directional to allow for handshaking communications. In addition to the connections shown, each agent has an additional link to the sequencer. The two additional modules in Figure 3 represent the beginning and ending of the line (denoted by S and E respectively).
They perform almost no role in scheduling
except to simplify the design of the other modules. Since the modules have no knowledge of their position within the factory floor, the extra modules are a necessity.
Q
Using a
Graphical User Interface2 (GUI), the floor layout is setup as
M Q
shown in Figure 4. Currently, the output of the GUI is used by
modules
processes.
Normally,
however, the scheduling
M
Q
M
I MH
Q
Figure 2: Layout of sample factory floor
the sequencer to start the scheduling
MH
Q
S
Q
MH
Q
Mach
Mach
Q
I
processes are started by the associated operations module at the beginning of the execution and they
MH Q
Mach
E
remain active until the termination. In this case,
Figure 3: Logical layout of sample factory
the user reconfigures the factory floor through the GUI which automatically reconfigures the operations modules, the planner, and the scheduler.
2
The screen captures in this section show a graphical user interface developed for the scheduler by Gabriel Brostow. implementation of the user interface is not discussed in this paper.
9
The
Figure 4: Factory floor setup GUI There are three major groups of permanent factory floor entities: materials handling resources, process resources, and inspection resources. Material handling resources can be further subdivided into either deterministic (e.g., conveyor belts) or nondeterministic resources (e.g., robots).
Nondeterministic material handling resources exhibit points of
nondeterminism (Section 2) that must be accounted for in the schedule; whereas, deterministic material handling resources can largely be controlled by the status of the downstream module. Each module is representative of a subclass of resources in one of the four major resource categories. These include: (i) Queues: Queues are a form deterministic material handling resource. They are one of the simplest forms of floor entities; for instance, a conveyor belt can be modeled as a queue because it cannot change the state or ordering of the parts it contains, (ii) Inspection stations: Inspection stations in the factory detect differences between the state of the physical world and the predicted state in the world model. Since the presence of the inspection station affects the floor, they must be modeled in the simulation. However, currently errors are not scheduled and therefore the inspection station will detect no errors. However, they may introduce delays and exhibit buffering, (iii) Material handling robots: Material handling robots are nondeterministic material handling resources. For instance, a robotic manipulator may pick a part from a conveyor and deliver the part to one of many machines, (iv) Processing machines: Processing machines are floor resources that can cause a change in the state of the current part. Processing machines are the most complicated scheduling modules in this implementation. These machines must match their own capabilities with the needs of the current part. This matching involves solving the partial ordering problem on a part's plan.
3.1. Overview The current implementation is in C++. The implementation is currently split into several different executables (ie., heavy weight threads) including the sequencer and the modules. At any time, the sequencer and several modules can be executing. As stated earlier, each factory floor module only communicates with its physical neighbors and the central process. Each of these links is implemented with the socket-based InterAgent™ distributed communications toolkit [InAg93]. The communications toolkit requires at least one message-passing process to be running. As the modules only communicate through InterAgent (ie., no shared memory), they can be located on a single processor or multiple processors as allowed by the InterAgent toolkit. All system actions are assumed to be the result of event occurrences. Events received before the completion of the process initiated by a previous event are queued and processed in order of their arrival. The
10
processing of events is not preemptive. The scheduler assumes the communication to be completely reliable. Four static size message types have been described at compile time. The message types and their usage are as follows: (i) Meet Messages: "Meet" messages are used to initially obtain the address of another process with which a process wishes to communicate, (ii) Sequencer messages: Sequencer messages are commands directed to scheduling modules. The majority are specific to a single universe; these include commands to create, duplicate, process an event in, and terminate a universe, (iii) Module-to-Sequencer Messages: Modules to the sequencer messages are usually in response to sequencer messages. The majority of these messages are to register the next event time for a specific universe. However, these messages can also request that the universe be terminated or duplicated. If the message is a register message, it can specify other modules it disturbed in the processing of an event, (iv) Module-to-Module messages: These messages are between two modules. They are used to implement the handshaking that occurs when a part transitions from one module to the next. In addition to handshaking messages, these messages allow one module to query another for its private data or status.
3.2. Sequencer The implemented sequencer is a branch and bound, distributed, discrete-event simulator. The sequencer has four main responsibilities: (i) the control of the overall scheduling process, (ii) the advancement of the event clock for each universe, (iii) the creation of new universes as requested by scheduling modules, and, (iv) the application of heuristics to guide the search. The primary responsibility of the sequencer is the global control of the scheduling process. This involves starting and stopping the scheduling activity. In this function, the sequencer can be seen as a multi-tasking DES engine which allows the running simulation to branch.
In the current implementation, the sequencer has the additional
responsibility of starting all executions of the scheduling modules. Once all the scheduling modules are started and their "Meet" messages are received, the sequencer sends a start message to each module. Following the start message, the distributed modules and the sequencer construct the schedule. When the final schedule has been chosen, the sequencer sends a stop command to each scheduling module, outputs any gathered information, and quits.
Between the start and
stop commands, the sequencer is sending and receiving messages from the scheduling modules. These messages serve to keep the clock in each universe consistent3 and direct the processing for each universe to the appropriate scheduling module. The sequencer algorithm for this process is illustrated in Figure 5. Lines 1-4 discuss the event queue setup for each universe and the clock that is maintained for each universe. In lines 8 and 9, the sequencer initializes the first universe to the current state, sets the clock to zero, and establishes the maximum bound for any universe. Lines 10-35 are a series of five steps that the sequencer cycles through for the duration of the scheduling process.
3 The clock can only be advanced by the sequencer. The sequencer notifies the distributed scheduling modules of the clock’s value when
necessary. This is commonly called a global clock to differentiate from schemes where each module can independently advance a local clock. No shared memory is necessary to implement this scheme and no clock slew is possible. For a complete description of this type of distributed discrete-event simulation, the interested reader is referred to [Misr86].
11
1 T = T1, T2, ... Tx where x is the number of universes and Tw is the clock of universe w. 2 The clock can be defined as: Tw = MIN (ti) for 1
