0 évaluation0% ont trouvé ce document utile (0 vote)
33 vues52 pages
A simulation-based, object-oriented model is proposed as a platform for applying scheduling heuristics to "real world" instances of the JSSP. The efficiency of the design is verified by demonstrating that the model can accommodate a wide variety of different job shop configurations. Plans for future work are established by describing the progress of a software implementation of the model.
Description originale:
Titre original
Bray - A Simulation-Based Approach to Job Shop Scheduling - 2007
A simulation-based, object-oriented model is proposed as a platform for applying scheduling heuristics to "real world" instances of the JSSP. The efficiency of the design is verified by demonstrating that the model can accommodate a wide variety of different job shop configurations. Plans for future work are established by describing the progress of a software implementation of the model.
A simulation-based, object-oriented model is proposed as a platform for applying scheduling heuristics to "real world" instances of the JSSP. The efficiency of the design is verified by demonstrating that the model can accommodate a wide variety of different job shop configurations. Plans for future work are established by describing the progress of a software implementation of the model.
A thesis submitted in partial fulfillment of the requirements for the degree of
BACHELOR OF APPLIED SCIENCE
Supervisor: D. Frances
Department of Mechanical and Industrial Engineering University of Toronto
March 2007
A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Abstract The job shop scheduling problem (JSSP) is a complex optimization problem that is encountered in a variety of manufacturing environments. Many heuristic solution techniques have been developed for abstract instances of the JSSP, but practitioners often lack the means to apply these techniques to their particular scheduling activities. A simulation-based, object-oriented model is proposed as a platform for applying scheduling heuristics to real world instances of the JSSP.
After a discussion of JSSP solution techniques which highlights the barriers to practical implementation, a detailed design of the simulation-based model is presented. The efficiency of the design is verified by demonstrating that the model can accommodate a wide variety of different job shop configurations through a relatively small set of external parameters. Finally, plans for future work are established by describing the progress of a software implementation of the model, and the role of this software implementation in the context of a broader concept: the simulation-based approach to job shop scheduling. i A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Acknowledgements Many thanks are extended to Kieran Concannon and Kim Hindle of Visual8 Corporation, who sponsored this thesis project and provided valuable advice and technical support. ii A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Table of Contents 1. Introduction 1 2. The Job Shop Scheduling Problem 2 3. Heuristic Scheduling Techniques 4 4. Applications of Job Shop Simulation 7 5. System Requirements 9 5.1 Flexibility 9 5.1.1 Mandatory Characteristics of the Application Domain 10 5.1.2 Optional Characteristics of the Application Domain 13 5.1.3 Characteristics Omitted from the Application Domain 15 5.2 Efficiency 17 6. System Design 18 6.1 Use Case Diagram 19 6.2 SBS Static Structure Diagram 19 6.3 ProductionModel Static Structure Diagram 22 6.4 SchedulingModel Static Structure Diagram 24 6.5 Resource Statechart Diagram 27 6.6 assignJobs() Sequence Diagram 28 6.7 selectnextBatch() Sequence Diagram 29 7. Design Validation 30 8. Software Implementation 31 9. Future Work 33 10. Conclusion 34 iii A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
List of Figures 1. Assembly Line with Sample Production Planning Calculation 36 2. Job Shop with Sample Production Planning Calculation 36 3. Simulation-Based Scheduling System (SBS) Use Case Diagram 37 4. Simulation-Based Scheduling System (SBS) Static Structure Diagram 38 5. ProductionModel Static Structure Diagram 39 6. SchedulingModel Static Structure Diagram 40 7. Resource Statechart Diagram 41 8. assignJobs() Sequence Diagram 42 9. selectNextBatch() Sequence Diagram 43 10. Screenshot of SIMUL8-Planner Software Implementation 44 11. Production Model Components 44
List of Tables 1. Mapping of Application Domain Characteristics to Simulation-Based Scheduling System Classes, Attributes and Functions 45 1 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
1. Introduction This report describes the design of a simulation-based, object-oriented model that enables a comprehensive definition of the job shop scheduling problem (JSSP). This model serves as the foundation of a simulation-based approach to job shop scheduling, which is also described in this report. Ultimately, this report aims to demonstrate that simulation-based scheduling (SBS) is both a practical and effective method for managing real world instances of the JSSP.
The JSSP is an optimization problem that is encountered by manufacturers in virtually every industry. Like any scheduling problem, the essence of the JSSP is to determine how to best allocate available resources in this case, the operating time of a set of workstations in order to complete all required work as quickly as possible. In simple manufacturing configurations, such as the single-product assembly line depicted in figure 1 on page 36, scheduling can be as simple as determining the rate at which production must take place at each workstation in order to complete the required number of finished goods. A job shop, however, is a more complex configuration in which the same set of workstations are used to produce multiple product types, each potentially requiring a different sequence of manufacturing steps, as depicted in figure 2 on page 36. This heterogeneous production environment can create highly complex scheduling situations, to the extent that it can prove difficult to even define the scheduling problem, let alone solve it [5]. The success of any solution technique for the JSSP therefore depends on an efficient framework that is capable of managing all constraints and decision variables. 2 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
In addition to its high degree of complexity, job shop scheduling is also a highly time- constrained activity; schedules must be generated on-demand in order to respond to constantly changing conditions, such as the arrival of a new production order or an unexpected machine breakdown. For this reason, the most successful approaches to job shop scheduling in practice are those that apply effective heuristics in order to quickly obtain good (but not necessarily optimal) schedules [14].
To overcome these challenges of the JSSP, a simulation-based scheduling (SBS) method is proposed. Discrete-event simulation is a highly effective tool for modeling complex systems, understanding their behavior over time, and discovering the impact of changes to their configuration. SBS leverages these strengths to provide an efficient framework for JSSP representation, and to support iterative refinement of schedules through rapid schedule generation.
2. The Job Shop Scheduling Problem The classic definition of a job shop, as described by Pinedo [14], can be summarized by 9 characteristics, listed below as C1-C9. Ad hoc notation has been provided where appropriate to help clarify the meaning of each characteristic. C1. There are m>0 resources r a available, represented by the set R={r 1 ,r 2 ,r 3 ,,r m }. C2. There are n>0 jobs j a to perform, represented by the set J={j 1 ,j 2 ,j 3 ,,j n }. C3. Each job j a consists of a set of p a > 0 operations o a,b , represented by the set O a =
{o a,1 ,o a,2 ,o a,3 ,,o a,pa}. 3 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
C4. Each operation o a,b has an unknown start time s a,b > 0, an unknown end time f a,b > 0, and a known duration t a,b > 0. C5. Each operation is performed by a resource. A tuple (o a,b , r c ) is defined for each operation, denoting that operation o a,b is performed by resource r c . C6. A resource can only perform 1 operation at a time. C7. When a resource starts an operation, it must be performed for the full duration without interruption: f a,b =
s a,b + t a,b . C8. Operation o a,b+1 cannot be started until operation o a,b is completed: s a,b f a,b+1 . C9. No 2 operations of a single job are performed by the same resource: (o a,b , r c ) (o a,e ,r f ) (be) (cf).
Based on this definition, the objective of the JSSP is to determine the start time s a,b of each operation o a,b such that the makespan is minimized. The makespan is defined as the total time elapsed from the start of the first job to the end of the last job, max(f a,b ) min(s a,b ) [11]. This basic objective will henceforth be referred to as the sequencing problem.
The 4 most common extensions to the JSSP (E1-E4) include: E1. Preemption, which permits operations to be interrupted by other operations and resumed later. This extension eliminates C7 from the JSSP definition. E2. Recirculation, which permits each job to include operations that require the same resource. This extension eliminates C9 from the JSSP definition. 4 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
E3. The flexible JSSP, in which some or all operations can be performed by any one of several resources (usually representing a job shop with parallel lines) [6]. This extension modifies C5 of the JSSP definition to allow multiple tuples (o a,b , r c ) to exist for each operation. Any feasible solution to the JSSP would have to satisfy exactly 1 of these tuples for each operation. E4. Job-specific due dates, d a > 0. This extension is unique because it entails a change to the objective function as opposed to a change to the constraints. An example of an appropriate scheduling objective under this extension is to minimize the average lateness of jobs [17]: n
Z a
a=1 ____ ,
where Z a = f a,pa d a if f a,pa > d a
n = 0 otherwise.
Many other practical extensions of the JSSP can be conceived. For example, manufacturing processes commonly involve machines that can process batches of jobs simultaneously, such as curing ovens. However, academic research on the subject of job shop scheduling has focused mainly on the abstract cases listed above, since even these relatively simple cases are mathematically intractable [16]. There is therefore both a need and an opportunity to develop efficient solution techniques for more complex (i.e. realistic) manufacturing systems.
3. Heuristic Scheduling Techniques Due to their complexity, most forms of the JSSP are formally classified as NP-hard problems [16]. The major implication of this classification is that there is no known solution technique that is guaranteed to obtain an optimal schedule, other than 5 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
searching through all possibilities. However, an exhaustive search is almost always impractical given the vast number of permutations for even relatively small JSSPs. Consequently, researchers have focused their efforts on developing heuristic techniques that aim to construct the best possible schedule in a limited amount of time.
The heuristic that has received the most attention in academic research is the dispatch method, which involves prioritizing the work to be performed by each machine according to a rule of thumb. Examples of dispatching rules are the shortest- processing-time-first (SPT) rule and earliest-due-date-first (EDD) rule; Blackstone, Phillips, and Hogg [3] provide a thorough survey of other common dispatch rules. The primary strength of the dispatch method is that it is a highly economical approach to scheduling, usually providing an acceptable tradeoff between schedule quality and computational effort. Computational efficiency has proven especially important for scheduling problems in industries with very complex production sequences, such as semiconductor wafer fabrication. Hung and Chen [10] present a study in which dispatching rules were successfully employed to reduce the average completion time of a semiconductor wafer fabrication process. This study also observes that the choice of dispatching rule had a significant impact on the quality of the resulting schedule, and that different dispatching rules were most effective for different scheduling objectives. These observations are not unique to the semiconductor industry; in fact, a great deal of research has been performed in an effort to develop policies for selecting 6 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
the best dispatch rule in different operating conditions or to achieve specific scheduling objectives.
Researchers have made some progress in establishing general guidelines for dispatch rule selection. For example, the consensus is that dispatching rules based on processing times (such as the SPT rule) tend to be the most effective in congested systems, while rules involving due dates (such as the EDD rule) tend to be the most effective in systems with little congestion [9]. However, no single dispatch rule can be expected to perform well for all possible instances of the JSSP. Complex system interdependencies and multiple schedule criteria benefit from more sophisticated implementations of the dispatch heuristic. Perhaps the most obvious extension is to apply different dispatch rules at different workstations. Barman [2] uses this approach on a 3-machine scheduling problem, and achieves better results with certain combinations of rules than with any single dispatch rule. A generalization of the mixed-rule approach is the concept of a composite dispatch rule. Composite rules are simply functions (for example, a weighted sum) of 2 or more individual dispatch rules. The rationale behind composite rules is that they should be able to better balance multiple scheduling criteria by combining the strengths of several simpler dispatching rules. Recent studies by Jayamohan and Rajendran [11] and John and Xiaoming [12] have successfully employed composite dispatching rules to improve job shop scheduling performance compared to standard dispatch methods. In addition, these studies demonstrate that composite rule development is a generalized form of policy development for dispatch rule selection. 7 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
There are a number of approaches to composite rule development in the literature. Many research papers propose and test new composite rules that are based on the researchers intuition, or that are a combination of rules that have consistently performed the best in previous studies. For example, Holthaus and Rajendran [9] have experimented with composite rules that are linear combinations of composite rules they have previously developed. More structured approaches to composite rule creation have also been proposed; Ho and Tay [8] have developed an empirical technique that constructs composite rules by means of a genetic algorithm. While the performance of Ho and Tays evolved composites is found to be superior to the most popular human-made dispatching rules, the genetic algorithm takes over 12 hours to complete and the results are applicable only to a simplified version of the JSSP. Despite their limitations, these studies provide evidence to support the value of empirical approaches to dispatching; all that is required is a more efficient and practical means of implementation.
4. Applications of Job Shop Simulation Discrete-event simulation has been successfully employed to help solve a variety of complex problems in the field of operations research. Simulation is particularly useful when the system of interest contains elements of uncertainty; for example, machines in a job shop environment may be subject to random breakdowns, represented by probability distributions [13]. However, simulation can also be useful to model complex deterministic systems for which an analytical model would be too difficult to construct or use. The JSSP would appear to be a perfect candidate for this approach; 8 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
indeed, all of the studies discussed to so far [2,8,9,10,11,12] employed discrete-event simulation, some with and some without elements of uncertainty, in order to evaluate the performance of their scheduling heuristics.
A simulation-based study typically follows an iterative process in which a model of the system of interest is used to answer a series of what if? questions, which take the form of simulation scenarios. In the aforementioned JSSP studies, the what if? questions have been of the form what if dispatch rule X is used to schedule work in the job shop?. However, other researchers have taken the simulation-based approach one step further, by integrating a simulation component into their solution algorithm. Toncich [20] presents the CHESS algorithm, which uses a series of brief simulation look-aheads to predict the future impact of scheduling a particular operation next. This approach can be viewed as an advanced application of the dispatch heuristic, in which the dispatching rule is to schedule the operation that will cause the fewest future resource conflicts (as predicted by the look-ahead simulations). The experimental results of Toncichs study offer makespan performance improvements of over 20 percent as opposed to fixed heuristic algorithms. Sun, Li, and Xiong [18] present a similar, simulation-based approach to job shop scheduling, but introduce global feedback loops in addition to the local feedback loops used by CHESS. The global feedback loop acts as a high-level supervisory element for the local dispatch mechanisms, by monitoring scheduling performance and dynamically adjusting local dispatch parameters. The researchers note that this approach offers the advantage of avoiding subjectivity in dispatch rule 9 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
selection, since the feedback mechanism is purely performance-driven. This approach is also found to be highly successful, offering clear superior performance to a variety of other heuristics in terms of both work flow and due date conformance. An interesting observation is that both Toncich [20] and Sun et al. [18] explicitly claim to be motivated by the need for more practical scheduling strategies, but neither provides a sufficiently generalized job shop model to support this effort. The logical next step is therefore to adapt the most promising, simulation-based scheduling techniques to a more comprehensive job shop model.
5. System Requirements Based on the analysis presented above, there is an outstanding need for an approach to job shop scheduling that satisfies 2 fundamental requirements: Flexibility: The approach must provide the means to represent and generate feasible solutions for as many variations of the JSSP as possible. Efficiency: The approach must provide the means to generate feasible solutions for all supported variations of the JSSP within a matter of minutes. The next 2 sections of the report (5.1 and 5.2) explain the meaning of and rationale behind these requirements in more detail.
5.1 Flexibility Above all else, SBS seeks to provide maximum modeling flexibility, to ensure maximum applicability to real-world manufacturing environments. The flexibility of any model should be defined in terms of the system of interest, or as it is 10 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
commonly referred to in software engineering, the application domain [4]. A model could be said to have maximum flexibility if it can represent all possible instances of the application domain. For the purposes of this project, the application domain is an extension of the classic JSSP defined in section 2 of this report; its characteristics are outlined in sections 5.1.1-5.1.3 below.
5.1.1 Mandatory Characteristics of the Application Domain There are 15 characteristics, labeled M1-M15, common to all possible instances of the application domain. This set of characteristics is therefore the minimum set required to describe the simplest JSSP scenario of interest. Included in this set are 7 of the characteristics from the classic JSSP definition and its common extensions presented in section 2 of the report; these are included in parenthesis in the description of the corresponding M characteristic. M1. (C1) There are m>0 resources r a available, represented by the set R = {r 1 , r 2 , r 3 , , r m }. M2. (C2) There are n > 0 jobs j a to perform, represented by the set J = {j 1 , j 2 , j 3 , , j n }. M3. (C3) Each job j a consists of a set of p a > 0 root operations o a,b , represented by the set O a =
{o a,1 , o a,2 , o a,3 , , o a,pa}. M4. Each job r a has a corresponding quantity q a > 0. M5. There are u > 0 material units x a available, represented by the set X = {x 1 , x 2 , x 3 , , x u }. M6. Each material unit x a has a corresponding size z a > 0. 11 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
M7. Material units are allocated to jobs. Material units x a that have been allocated to a particular job j b are represented by the set I b,a , and a material unit can only be allocated to 1 job. M8. A material unit x a that is allocated to a job j b inherits the jobs set of root operations O b . A material units operations (henceforth referred to simply as operations) are differentiated from the jobs root operations o b,c by using the notation o b,a,c , and represented by the set O b,a =
{ o b,a,1 , o b,a,2 , o b,a,3 , , o b,a,pb}. M9. (E3) Each operation must be performed by a resource. For each operation, a set of 1 or more tuples (o a,b,c , r d ) is defined to denote that resource r d is a candidate for performing operation o a,b,c. Any feasible solution to the JSSP must satisfy exactly 1 of these tuples for each operation. M10. Each resource r a has a capacity c a > 0 that indicates the maximum number of operations it can perform at any one time. M11. (C4) Each operation o a,b,c has an unknown start time s a,b,c > 0, an unknown end time f a,b,c > 0, and a known duration t a,b,c > 0. M12. (C7) When a resource starts an operation o a,b,c , it must be performed for the full duration without interruption: f a,b,c =
s a,b,c + t a,b,c . M13. (C8) Operation o a,b+1,c cannot be started until operation o a,b,c is completed: s a,b,c f a,b+1,c . M14. Material units incur a fixed delay v a,b 0 to travel from resource r a to resource r b . This means that resource r b cannot perform an operation on the material unit until at least v a,b time has elapsed since the end of the operation that was performed on the material unit by resource r a . 12 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
M15. There is a limit to the number of material units that can be in progress in the job shop at once. This is primarily intended to represent physical space constraints in the job shop, but could also be used to represent more complex constraints such as the availability of material handling equipment (assembly fixtures, containers, etc.).
The scheduling objective for this minimal description of the application domain can be broken down into 2 sub-objectives. The first of these sub-objectives is an assignment problem between jobs and material units; more specifically, the I b,a sets
(as defined by M7) must be constructed to maximize the number of jobs that are fully allocated, where fully allocated is defined by the following inequality: z a q b
a b,a This sub-objective will henceforth be referred to as the assignment problem.
The second sub-objective is functionally equivalent to the sequencing problem defined in section 2: to determine the start time s a,b,c of each operation o a,b,c such that the makespan, max(f a,b,c ) min(s a,b,c ), is minimized.
Besides the expanded set of objectives, there are 4 key differences to note between the application domain presented in this section and the classic JSSP presented in section 2: The concept of a material unit (M5-M8) is introduced as a vehicle for job fulfillment. 13 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Flexible routing (M9) is allowed by default. M10 replaces C6, giving resources the potential to perform multiple operations simultaneously. C9 has been omitted, which implies that recirculation is allowed by default.
5.1.2 Optional Characteristics of the Application Domain The 8 optional characteristics listed below (O1-O8), when combined with the mandatory characteristics presented in section 5.1.1 (M1-M15), define the full range of JSSP configurations to be considered. As in section 5.1.1, equivalent characteristics from section 2 are indicated in parenthesis. Also note that since many of these characteristics are inherently more complex than any of the mandatory characteristics, ad hoc notation has been omitted for some characteristics in favor of more thorough text descriptions. O1. (E4) Each job j a is assigned its own due date d a . O2. A material unit can be assigned to multiple jobs until it has been completely assigned (i.e. the sum of the job quantities assigned to the material unit are equal to its size). All jobs assigned to a particular material unit must have compatible properties and operations, where the definition of compatible varies with the particular scenario. O3. Before starting an operation, resources incur an additional delay referred to as a changeover. The duration of a changeover and the conditions under which it are incurred may be resource-specific (for example, a resource may require 14 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
a changeover after every n th operation) and/or operation-specific (certain operations
may always require a changeover). O4. Resources incur loading and unloading delays at the start and end of operations. A resource that starts or completes multiple operations at the same time incurs only a single load or unload delay for that group of operations. This constraint is used to represent resources that perform batch processing, such as curing ovens. O5. Resources must remain idle for pre-defined intervals of time. This represents activities such as maintenance that is scheduled for a future time or unscheduled repairs that must be completed before the resource is available to perform operations. O6. Operations o a,b,c require a number a,b,c,d of sub-resources d in addition to a single primary resource r e during setup and/or processing. These sub-resources represent secondary resource constraints such as non-dedicated machine operators and setup teams. O7. The number of material units that are available for job allocation is initially fixed. At a pre-defined time in the scheduling period, however, a new set of decision variables is introduced to represent the number of additional raw material units that are required to fulfill all outstanding job quantities. The delay in the introduction of these decision variables is equal to the lead time for new material arrival will henceforth be referred to as the time fence. O8. The initial state of the job shop must be defined, including the initial location of each material unit, all pre-defined material-to-job allocations (if any), the 15 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
operations initially in progress at each resource (if any), and the initial utilization of all sub-resources. Of the 8 optional characteristics presented above, only O1 (job-specific due dates) and O2 (multiple job assignments) affect the form of the scheduling objective presented in section 5.1.1; the other 6 optional characteristics can be interpreted as constraints.
With O1 in effect, the sequencing problem must be expanded to account for job- specific due dates in addition to makespan minimization. This new sub-objective could potentially take several forms, provided it is based on a function of the job due dates. As suggested in section 2, an example of such an objective is to minimize the average lateness of the jobs. Other appropriate approaches include minimizing the lateness of the latest job, minimizing the total number of late jobs, or a weighted combination of these objectives.
With O2 in effect, the sequencing problem must be further modified to account for the possibility of multiple due dates associated with the same material unit, due to the possibility of multiple job assignments. This suggests further application of a weighted combination approach to performance measurement.
5.1.3 Characteristics Omitted from the Application Domain While sections 5.1.1 and 5.1.2 provide a thorough description of the application domain, it is also important to note what JSSP scenarios have not been accounted for 16 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
and why. This section explains the rationale behind the 2 most relevant omissions, and suggests alternative strategies to help manage these scenarios.
The most notable omission is that of preemption, or the ability of a resource to complete operations in a piecemeal fashion. During the design phase, it was decided that the increase in computational complexity required to fully integrate this option was not justified. In addition, Queyranne and Sviridenko have shown that the preemptive scenario can be successfully approximated by dividing operations into multiple, shorter operations [15]. Section 6.3 of the design description will explain how such an approximation can be accommodated.
The other notable omission from the application domain is the concept of a bill of materials (BOM). BOM-driven production planning, in which aggregate material and production requirements are derived from customer orders by tracing backwards through the appropriate BOM hierarchies, is a common practice in industry [19]. Support for hierarchical, BOM-driven scheduling within a single SBS model is an appealing possibility, but as for the preemption scenario, it was determined that the subsequent increase in modeling complexity was not justified. In addition to increased modeling complexity, the presence of subassemblies necessitates additional coordination of assembly operations, which further increases scheduling complexity. To overcome the inherent complexities of BOM management, a more practical divide and conquer approach to BOM-driven scheduling will be suggested in section 9. 17 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
5.2 Efficiency After flexibility, one the most important tenets of SBS is that schedule generation should be very fast in the range of a few minutes. This allows the scheduler to respond quickly to a change in operating conditions, such as an unexpected machine breakdown. Another approach to coping with uncertainty is to maximize schedule robustness, or the ease with which a schedule can be altered in order to account for unexpected events. Schedule robustness can be pursued in a variety of ways, including the 3 listed below. 1. Worst-case scenario scheduling, which at least guarantees a feasible schedule and minimal disruption to the actual production sequence. 2. Probabilistic job shop models, which incorporate measurements such as resource reliability and operating time variability into the scheduling procedure. This approach is based on the philosophy of expected values, and therefore seeks to achieve the optimal long-term tradeoff between schedule performance and the risk of selecting a schedule that is later discovered to be infeasible [7]. 3. Multiple-scenario scheduling, which attempts to provide the decision maker with multiple sequencing options for different points in time. To achieve this, a number of schedules are generated by applying different permutations of operating conditions. Areas of compatibility between schedules are then identified, resulting in a network of schedules that can account for different possibilities. The scheduler can then consult this network to identify different scheduling options whenever new operating conditions are encountered. This can be a highly effective but computationally expensive approach to robustness, since its 18 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
effectiveness is heavily dependent on the number of different schedules that are generated [1].
It is proposed that SBSs emphasis on responsiveness via rapid schedule generation could also facilitate a robustness strategy similar in approach to strategy #3. In fact, the automated iterative schedule refinement extension discussed in section 9 would provide most of the required framework, with only minor additions required to support rapid recall of archived schedules.
6. System Design Having defined the application domain, the next step taken in this thesis project was to document the solution domain (i.e. the SBS approach) using Unified Modeling Language (UML) [21]. UML offers a highly structured approach to systems modeling, and is a recognized standard for software engineering projects. However it is still highly accessible to non-experts due to its intuitive graphical format. Moreover, documenting the SBS approach with UML provides a concrete plan for a practical software implementation (described in section 8 of the report). The design of SBS will now be explained through a description of 7 UML diagrams (figures 3-9 on pages 37 to 43). This explanation will be followed by a validation of the design in section 7 of the report.
19 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
6.1 Use Case Diagram Figure 3 on page 37 presents a UML use case diagram for SBS. Use case diagrams outline the functional requirements of a system from the perspective of the user. 3 primary use cases have been identified for SBS: UpdateModel, Schedule, and Monitor. The intent of UpdateModel and Schedule are no doubt obvious to the reader. Monitor represents the process of comparing the progress and performance of the generated schedule to the actual state of affairs in the facility. Whenever a {schedule discrepancy} is encountered for example, an unexpected machine breakdown occurs, or production is simply not proceeding as quickly as anticipated a new Schedule activity is triggered in order to obtain an updated schedule.
The value of the use case diagram is that it forces the system designer to generalize specific user activities into functional requirements, and subsequently provides clues for the required structure of the systems components. For example, the DefineObjective use case represents the requirement for the user to have certain influences on the scheduling algorithm, such as being able to prioritize individual orders or specifying a maximum allowable work-in-progress level. Section 6.2 below provides a description of the use cases addressed by each subsystem.
6.2 SBS Static Structure Diagram Figure 4 on page 38 presents a static structure diagram for the entire SBS system. Static structure diagrams are used to describe the relationships between the objects (in the sense of object-oriented modeling) that a system is composed of. This static 20 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
structure diagram is the highest-level view of SBS, identifying its 4 primary subsystems. The responsibilities of these 4 subsystems, with reference to the use cases described in section 6.1, are as follows: The Interface subsystem is a special case; since each use case represents an interaction between the user and the system, the Interface is involved in essentially all use cases to some extent. However, it is particularly important for the UpdateModel, BuildModel, EvaluateSchedule, and Monitor use cases, since the success of these tasks is highly dependant on the user interface design. The ProductionModel subsystem is an object-oriented representation of the production model described in section 5.1. It acts as the primary repository for application domain data. The use cases for which the ProductionModel is primarily responsible are UpdateModel and BuildModel. The SchedulingModel subsystem stores the intelligence for all scheduling heuristics applied to the JSSP. This consists of the algorithms for the assignment problem and sequencing problem as well as the data used to prioritize the orders and material units considered by these algorithms. An alternative perspective is that the ProductionModel is the primary repository of problem constraint data, and the SchedulingModel is the primary repository of data related to the scheduling objectives. Use cases addressed by the SchedulingModel include DefineObjective, PrioritizeOrder, LimitWip, and CreateSchedule. The Simulator subsystem represents the discrete-event simulation engine that is the foundation for SBS. It facilitates an incremental approach to the completion of the CreateSchedule use case by incorporating the notion of time into the main 21 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
sequencing algorithm. This is achieved by way of a scheduling loop, as indicated on the static structure diagram. When the CreateSchedule use case is initiated by the user, a scheduling loop begins in which the Simulator updates the state of the ProductionModel based on its internal event list (i.e. the Simulator simulates the sequence of events that take place in the job shop). When a decision point is reached (in particular, the completion of an operation, triggering the selection of the next operation), the SchedulingModel is called to make the decision by running the main sequencing algorithm (described in section 6.7). The decision is then communicated to the Simulator, which applies the decision to the ProductionModel and resumes the simulation of operations until another decision point is reached or the simulation reaches the end of the scheduling period.
The ProductionModel and SchedulingModel subsystems have been designed to be platform-independent, making no assumptions about the simulation package to be employed for the software implementation of this design. As a consequence of this, detailed design descriptions for the Interface and Simulator subsystems are not necessary, since successful design of a generic ProductionModel and SchedulingModel will ensure that any compatible user interface technology and discrete-event simulation engine can be employed. Thus the remainder of the design description (sections 6.3-6.7) will focus exclusively on the ProductionModel and SchedulingModel subsystems.
22 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
6.3 ProductionModel Static Structure Diagram This static structure diagram (figure 5 on page 39) provides a more detailed description of the ProductionModel subsystem. Some of the more notable design features are as follows: Assignment: This class of objects relates Job objects to their assigned MaterialUnit objects. This flexible, 3-part relationship structure also allows multiple MaterialUnit objects to be assigned to the same Job object and vice versa. MaterialUnit: this class is assigned a size for order allocation purposes, and its currentLocation and currentOperation are used both to define starting conditions and for tracking purposes by the main sequencing algorithm. Route: this abstract class groups related sequences of Operation objects. It represents the assignment of a RootRoute (which is an abstraction of a standard, or root sequence of operation objects) to a MaterialUnit as a result of assigning an initial Job to that MaterialUnit. Creating a unique instance of Operation objects for each MaterialUnit, regardless of the source of the Operation objects, allows for total routing flexibility; for example, if a particular MaterialUnit requires a special sequence (perhaps because the MaterialUnit was diverted for rework), this can be accommodated while remaining transparent to other components of the system (such as the sequencing algorithm). Dynamic creation of routes also provides an opportunity to partition each Operation into a larger set of Operation objects in order to approximate pre-emptive processing, since the sequencing logic is re-run after every 23 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Operation (as explained in section 6.7), even if that Operation represents only a portion of a real life operation. Resource: this class will be described in more detail during the discussion of the Resource statechart diagram in section 6.5. Destination: this class, together with the Zone class, is designed to support flexible routing of MaterialUnit objects to Resource objects. A Zone is a logical grouping of Resource objects, in the same way that a Route was defined as a logical grouping of Operation objects. Therefore, by defining both the Resource and Zone classes as sub-classes of the Destination class, the Destination class can represent either a single Resource or any combination of Resource objects. This allows the Operation class totransparently communicate a choice in Resource objects by referencing a Destination instead of a Resource. SequencedEvent: an object of this class is created each time a Resource performs an Operation, Changeover, Load, Unload, or Downtime. This serves as a record of the sequence of events that take place during the simulation (i.e. the schedule requested by the user). Batch: a Batch is a logical grouping of batchContents, which in turn map to individual MaterialUnit objects. Thus the Batch class allows a group of MaterialUnit objects to be referenced at once. This allows the SequencedEvent class to describe an Operation, Load, or Unload conducted by a Resource object that can simultaneously process multiple MaterialUnit objects (i.e. batches of 24 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
work). Note that to achieve total transparency, a Batch must be defined for every Operation, Load, and Unload, even if it involves only a single MaterialUnit. Downtime: this class represents another scheduling consideration besides the sequencing of MaterialUnit objects. An acceptable range of start times for the event are provided by the attributes earliestStart and latestStart. The duration of the event (during which time the affected Resource is not permitted to process a MaterialUnit) is indicated by the duration attribute.
6.4 SchedulingModel Static Structure Diagram This static structure diagram (Figure 6 on page 40) provides a more detailed description of the SchedulingModel subsystem. To clarify the interaction between this subsystem and the ProductionModel, classes from the ProductionModel have also been included in this diagram; these repeated classes are marked by the <<interface>> designation and a light grey color. Some of the more notable design features of the SchedulingModel are as follows: Scheduler: a single instance of this class is responsible for procedural control of the 2 major algorithms executed by this subsystem. These algorithms are described by means of UML sequence diagrams in sections 6.6 and 6.7. Assigner: a single instance of this class executes the algorithm responsible for solving the assignment problem. This algorithm, implemented as the function assignJobs(), is described by means of a UML sequence diagram in section 6.6. 25 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Sequencer: this class executes the algorithm responsible for solving the sequencing problem. This algorithm, implemented as the function selectNextBatch(), is described by means of a UML sequence diagram in section 6.7. In addition, this class is responsible for enforcing the time fence for new material arrival and the work-in-progress limit, 2 constraints that are described in section 5.1.2. PotentialBatch: This class and PotentialBatchContents are temporary analogues to Batch and BatchContents from the ProductionModel. Their purpose is to allow dispatch heuristics to be applied to groups of MaterialUnit objects; this allows selectNextBatch() to be executed for sequencing at both single-unit Resource objects and at Resource objects that perform work in batches. PriorityCalculation: The PriorityCalculation class and Priority subclasses are the heart of the SBS systems implementation of the dispatch heuristic. The structure presented in the diagram implies that every decision made by the SchedulingModel is based on some function of priority ratings controlled by PriorityCalculation. PriorityCalculation determines priority ratings by calling the appropriate subclasses of Priority (for example, JobPriority for a Job priority calculation). These subclasses each return a value that is a function of 3 object attributes: a userPriority (which affords the user some influence on the relative priority of objects), a staticPriority (i.e. those attributes of an object that do not change during the simulation), and a dynamicPriority (i.e. those attributes of an object 26 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
that do change during the simulation). By separating the calculation of priority ratings from their interpretation (by the Sequencer and Assigner), changes to the priority calculations can be made without requiring fundamental changes to the scheduling algorithms. Thus any conceivable dispatch method can be implemented using this framework. JobClassification: This metaclass represents all possible means of grouping jobs, such as the customer for whom the Job (i.e. order) is performed, or the product line that the Product associated with the Job belongs to. The purpose of representing such categorizations in a general manner is to imply that any priority rating associated with the categorization can be accommodated, due to the flexible structure for priority calculations explained in the PriorityCalculation section above. Note that the Product class also fits the description of a JobClassification, but has been explicitly modeled due to its pervasiveness in job shop manufacturing environments. The Product class is also the most likely Job categorization to influence the constraints represented by the ProductionModel, which is why it has been included as a class of the ProductionModel; in contrast, the JobClassification metaclass is modeled as a class of the SchedulingModel subsystem because its primary function is to provide an infrastructure for prioritization (a scheduling concern).
27 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
6.5 Resource Statechart Diagram The Resource class has been designed to accommodate a wide variety of potential configurations. Its capabilities are illustrated by a UML statechart diagram (figure 7 on page 41), which documents the 6 possible states of a Resource and the conditions for state transition.
The initial state of a resource is defined by the initial conditions defined for the Downtime and MaterialUnit objects. A Resource can therefore start the simulation in the Down state (i.e. performing Downtime) or in the Loading, Working or Unloading states (if the currentLocation attribute of at least 1 MaterialUnit references the Resource). If none of these initial conditions apply, the Resource will call selectNextBatch() from the Sequencer class of the SchedulingModel in an attempt to identify a Batch of MaterialUnit objects. Failing this, the Resource begins the simulation in the Idle state.
A Resource remains in the Idle state until a new MaterialUnit becomes available, which triggers a new call to selectNextBatch(). Once the algorithm successfully identifies a feasible Batch, the Resource enters the Changeover state (optional) followed by the Loading (optional), Working, and Unloading (optional) states sequentially. When the Resource completes the Unloading process (or the Working process if no unload is required), selectNextBatch() is called again and the cycle is repeated.
28 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
A Resource enters the Down state whenever the earliestStart of its next Downtime is reached while the Resource if Idle, or when the Resource completes work and/or unloading within the starting interval (i.e. earliestStart to latestStart) of its next Downtime. As suggested in section 6.3, the selectNextBatch() sequencing algorithm must account for the next Downtime event scheduled for each Resource to prevent the possibility of scheduling work that spans the entire start interval of the Downtime (i.e. latestStart earliestStart).
These 6 states, combined with policies for issues such as batch sizes and changeover frequencies defined through the ProductionModel, account for every desired Resource scenario possible in the application domain; a more complete proof of this claim will be provided in section 7 of the report.
6.6 assignJobs() Sequence Diagram The function assignJobs()is the first of 2 scheduling algorithms implemented by the SchedulingModel. Its purpose is to generate Assignment objects, which relate Job objects to compatible MaterialUnit objects, until the quantity attribute of each Job is satisfied. The sequence of logic required to achieve this is outlined by a UML sequence diagram (figure 8 on page 42).
The assignJobs() function is the first major function invoked by the Scheduler when a new schedule() request is received from the user. The Assigner starts by determining priority scores for all Job objects (as determined by calls to the 29 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
PriorityCalculation object). Then the Assigner iterates through all Job objects in descending order of priority, and creates as many Assignment objects as necessary to fulfill the quantity of each Job. If no existing MaterialUnit can satisfy an Assignment, RequiredMaterial objects are created (as well as a Route object based on the ProductRoute associated with the Job) to fulfill the Assignment.
The assignJobs() function is only invoked once for each scheduling request from the user, as all required MaterialUnit objects are instantiated immediately even those that may be delayed from being sequenced due to the timeFence. This provides the selectNextBatch() function with the long-term visibility required to maximize the efficiency of sequencing, as discussed in section 6.7 below.
6.7 selectNextBatch() Sequence Diagram Figure 9 on page 42 presents a sequence diagram for the selectNextBatch() function, which implements an algorithm to address the sequencing problem. As mentioned in section 6.5 during the description of the Resource statechart, selectNextBatch() is invoked every time a Resource completes an Operation or receives a new MaterialUnit while idle. Once the Sequencer is notified of the idle Resource, it determines all permutations of MaterialUnit objects available to the Resource that can feasibly be processed (with respect to the minLoad and maxLoad attributes of the Resource, the value of the timeFence attribute, and any other relevant constraints). Once all of these permutations have been identified and instantiated as PotentialBatch objects, the next Downtime event for the Resource 30 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
is considered. If no PotentialBatch can be completed before the next Downtime event must begin, the algorithm is delayed until the Downtime event has time to complete. Otherwise, the priority ranking of each PotentialBatch is determined via the PriorityCalculation object, and the highest ranking PotentialBatch is marked for processing; this involves instantiating the PotentialBatch as a Batch and committing the sequencing decision by creating a SequencedEvent to be reported to the user as part of the generated schedule.
Since all MaterialUnit objects are instantiated at the beginning of the simulation, there is an opportunity to enhance this algorithm to also consider batches consisting of MaterialUnit objects that are not yet available for processing at a Resource (due either to the time fence or a MaterialUnit that has not yet completed an earlier Operation). This would require the Sequencer to evaluate the tradeoff between immediately processing a low-priority group of MaterialUnit objects and delaying processing for a short period in order to expedite processing of an upcoming, higher- priority group of MaterialUnit objects.
7. Design Validation To verify the completeness of the system design presented in section 6, Table 1 on page 45 presents a complete mapping between the objects of the 2 SBS subsystems of interest (i.e. ProductionModel and SchedulingModel), and the list of mandatory and optional characteristics of the application domain presented in sections 5.1.1 and 5.1.2. Table 1 shows that there is at least 1 object-oriented concept from the SBS 31 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
system design to account for each of the analytical/descriptive characteristics of the application domain. This supports the claim that any JSSP scenario defined with the application domain model can also be defined with the SBS object-oriented model.
Evaluating the other fundamental system requirement efficiency is best conducted by means of empirical testing of a software implementation of the SBS system. The progress in the ongoing development of an SBS software implementation is described in section 8 below.
8. Software Implementation Upon completion of the system design, the most recent project work has focused on developing a practical software implementation of the SBS system. The SIMUL8 software package was selected for this purpose. SIMUL8 was selected over other commercial simulation packages for the following reasons: SIMUL8 offers a self-contained simulation system development environment, with built-in data stores, a fully customizable user interface, and Visual Logic, a high-level proprietary programming language. These conveniences have allowed the implementation effort to remain focused on the ProductionModel and SchedulingModel, as no additional software infrastructure has been required to integrate the 4 major SBS subsystems outlined in section 6.2. SIMUL8 has recently released an extension to its standard program called SIMUL8-Planner. This extension provides additional features to assist developers 32 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
of simulation-based scheduling systems, including an expanded data structure for dates and times, indexed spreadsheets, and a Gantt chart interface. Visual8 Corporation, the primary provider of consulting, training, and support services for SIMUL8 in North America, has agreed to sponsor this development effort by providing licenses of SIMUL8 Professional and SIMUL8-Planner.
The development process is currently estimated to be 80% complete. All classes of the ProductionModel and SchedulingModel have been implemented with the exception of the Sequencer and its selectNextBatch() function. A robust user interface for ProductionModel inputs has also been completed, including a graphical user interface (GUI) for defining the physical structure of a ProductionModel. This GUI is depicted in figure 10 on page 44, which is a screenshot of a sample ProductionModel layout.
The SIMUL8-Planner implementation provides 6 components that allow the user to define the physical layout of a production model, as depicted in figure 11 on page 44. A brief description of these components is provided below. Process: this component is equivalent to the SBS Resource class. Queue: this component is used to organize the MaterialUnits available for processing at each Resource (Process). However, no local queue capacities are enforced as this would introduce the possibility of deadlock situations due to the ProductionModels support of recirculation. A SIMUL8-Planner production model requires exactly 1 Queue per Process. 33 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Supervisor: this component implements the Zone class, which allows Operation objects to transparently reference either a specific Resource (Process) or group of Resource objects. Resource: this component is equivalent to the SBS SubResource class. Source: this component helps to define the system boundary by representing the entry point of all MaterialUnit objects. Exit: this component completes the definition of the system boundary by representing the exit point of all MaterialUnit objects. Once a MaterialUnit has completed every Operation associated with its Route, it is routed to the Exit component to represent Job completion.
Once implementation of the selectNextBatch() function is completed, the performance of the SIMUL8-Planner software implementation can be tested in order to complete the outstanding validation of model efficiency described in section 7 of the report.
9. Future Work Besides completion of the SIMUL8-Planner implementation of the SBS system, there are several opportunities for further refinement of the SBS approach. Two of the most exciting opportunities for long-term expansion are described below. Automated Iterative Schedule Refinement: Due to the rapid schedule- generating capabilities promised by the SBS system structure, there is the potential to extend the scheduling loop concept depicted in figure 4 on page 38 34 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
into a global, performance-driven feedback loop that runs additional scheduling iterations in an effort to improve upon an initially generated schedule. However, the success of such a process would depend heavily on the ability to identify an appropriate mapping between schedule performance and dispatch heuristic values. This mapping would vary based on the configuration and dynamics of the production model, making it challenging to generalize the technique. Hierarchical Scheduling: By formatting the output of one scheduling model into the input requirements for another scheduling model, larger scheduling problems can be effectively broken down into smaller, more manageable problems. This approach has potential applications to solve JSSPs involving BOM-driven production as well as large-scale supply chain scheduling problems. Implementing such as approach would involve the development of a software routine that automates the conversion of the ProductionModels SequencedEvent outputs into Job inputs.
10. Conclusion This thesis project was carried out in order to address the need for a practical representation of the job shop scheduling problem that accounts for many of the complexities encountered in real-life job shop manufacturing environments. This objective was motivated by the tendency for research to focus on abstract models of the problem that lack the detail to be of practical use. A simulation-based approach to job shop scheduling was proposed as an efficient means for both modeling and obtaining feasible solutions to the problem. 35 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
A comprehensive list of modeling requirements was proposed, followed by a detailed design specification that was documented with the industry-standard Unified Modeling Language. The model completeness was validated by mapping each of the modeling requirements to components of the detailed design. The current state of the project is imminent completion of a software implementation of the system using the SIMUL8-Planner simulation software package.
Upon completion of the SIMUL8-Planner software implementation, this ongoing development project will focus on identifying a practical test case to demonstrate the full range of the software's production modeling capabilities. By quickly generating feasible schedules for a complex test case, the simulation-based approach will demonstrate its ability to bridge the gap between industry requirements and academic research into the job shop scheduling problem. 36 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
11. Figures and Tables
Figure 1. Assembly Line with Sample Production Planning Calculation
Figure 2. Job Shop with Sample Production Planning Calculation
37 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
SBS User BuildModel UpdateModel CreateSchedule DefineObjective EvaluateSchedule Schedule uses uses Monitor QueryOrder uses QueryProcess extends uses uses extends {schedule discrepancy} {initial development} LimitWIP PrioritizeOrder {WIP constraint} {urgent order} extends extends Simulation-Based Scheduling (SBS) System Use Case Diagram
Figure 3. Simulation-Based Scheduling System (SBS) Use Case Diagram 38 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 4. Simulation-Based Scheduling System (SBS) Static Structure Diagram
39 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 5. ProductionModel Static Structure Diagram 40 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 6. SchedulingModel Static Structure Diagram 41 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 7. Resource Statechart Diagram 42 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 8. assignJobs() Sequence Diagram 43 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 9. selectNextBatch() Sequence Diagram 44 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Figure 10. Screenshot of SIMUL8-Planner Software Implementation
Process
Supervisor
Source
Queue
Resource
Exit
Figure 11. Production Model Components
45 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
Table 1. Mapping of Application Domain Characteristics to Simulation-Based Scheduling System Classes, Attributes and Functions
Application Domain Simulation-Based Scheduling System M1. Resource Resource M2. Job Job, Product, JobClassification M3. Operation RootOperation, RootRoute, ProductRoute, MaterialRoute M4. Job quantity Job.quantity M5. Material Unit MaterialUnit M6. Material Unit Size MaterialUnit.size M7. Material Unit-to-Job Allocation Assignment, Assigner.assignJobs() M8. Material Unit Operation Inheritance Operation, Route M9. Resource-to-Operation Mapping Destination, Zone M10. Resource Batch Processing Resource.capacity, Batch, BatchContents M11. Operation Scheduling Operation.duration, SequencedEvent M12. No Preemption Scheduler.idleResource(Resource), Sequencer.selectnextBatch(Resource) M13. Operation Precedence Operation.sequence, MaterialUnit.currentOperation M14. Material Unit Travel Time TravelTime M15. Material Unit Work-in-Progress Limit MaterialUnit.currentLocation, Sequencer.materialLimit O1. Job-Specific Due Date Job.dueDate O2. Material-Unit-to-Job Multi-Allocation Assignment.quantity, MaterialUnit.updateStatus(Job) O3. Resource Changeover Changeover, Changeover.duration, Resource.changeover(duration) O4. Resource Batch Loading/Unloading Resource.minLoad, Resource.maxLoad, Resource.minUnload, Resource.maxUnload, Load, Unload O5. Resource Downtime Downtime, Resource.downtime(duration) O6. Sub-Resources SubResource O7. Time Fence Sequencer.timeFence, Sequencer.getStatus(timeFence) O8. Initial Job Shop Conditions ExistingMaterial, MaterialUnit.currentLocation 46 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
References
[1] Artigues, C., Billaut, J. and Esswein, C., Maximization of solution flexibility for robust shop scheduling, European Journal of Operational Research, pp. 314-328, 2005.
[2] Barman, S., "Simple priority rule combinations: An approach to improve both flow time and tardiness," International Journal of Production Research, vol. 35, pp. 2857-2870, 1997.
[3] Blackstone, J. J. H., Phillips, D. T. and Hogg, G. L., A state-of-the-art survey of dispatching rules for manufacturing job shop operations, International Journal of Production Research, vol. 20, pp. 27-45, 1982.
[4] Bruegge, B. and Dutoit, A., Object-oriented software engineering: using UML, patterns, and java (second edition). New Jersey: Prentice Hall, 2004.
[5] Buxey, G. Production scheduling: Practice and theory, European Journal of Operation Research, vol. 39, pp. 1731, 1989.
[6] Chan, F. T. S., Wong, T. C. and Chan, L. Y., Flexible job shop scheduling problem under resource constraints, International Journal of Production Research, vol. 44, pp. 2071-2089, 2006.
[7] W. Herroelen, and R. Leus, Project scheduling under uncertainty, European Journal of Operational Research, pp. 289306, 2005.
[8] Ho, N.B. and Tay, J. C., Evolving Dispatching Rules for solving the Flexible Job-Shop Problem, Proceedings of the IEEE Conference on Evolutionary Computation (CEC 2005), vol. 3, pp. 2848 2855, Sept. 2 nd 5 th , 2005.
[9] Holthaus, O. and Rajendran, C., Efficient rules for dispatching in a job shop, International Journal of Production Economics, vol. 48, pp. 87-105, 1997.
[10] Hung, Y. and Chen, I., A simulation study of dispatch rules for reducing flow times in semiconductor wafer fabrication, Production Planning and Control,vol.9,pp.714-722,1998.
[11] Jayamohan, M. S. and Rajendran, C., "Development and analysis of cost- based dispatching rules for job shop scheduling," European Journal of Operational Research, vol. 157, pp. 307-321, 2004.
[12] John, J.K., and Xiaoming, L., "A weighted modified due date rule for sequencing to minimize weighted tardiness", Journal of Scheduling, vol. 7, pp. 261-276, 2004.
47 A Simulation-Based Approach to Job Shop Scheduling Shawn Bray
[13] Law, A. and Kelton, D., Simulation modeling and analysis (third edition). New York: McGraw-Hill, 2000.
[14] Pinedo, Michael L., Planning and scheduling in manufacturing and services. New York: Springer Science+Business Media, 2005.
[15] Queyranne, M. and Sviridenko, M., Approximation algorithms for shop scheduling problems with minsum objective, Journal of Scheduling, pp. 287- 305, 2002.
[16] Roy, U. and Zhang, X., A heuristic approach to n/m job shop scheduling: Fuzzy dynamic scheduling algorithms, Production Planning and Control, vol.7, pp. 299-311, 1996.
[17] Smith, M.L. and Seidman, A., Due date selection procedures for job-shop simulation. Computers and Industrial Engineering, vol. 7, pp. 199-207, 1983.
[18] Sun, R.L., Li, H.X, and Xiong, Y., Performance-oriented integrated control of production scheduling, IEEE Transactions on Systems, Man, and Cybernetics, vol. 36, pp. 554-562, 2006.
[19] Tompkins, A. et al., Facilities planning (third edition). New York: John Wiley & Sons, 2006.
[20] Toncich, D., CHESS: A methodology for resolving scheduling and dispatch problems in FMSs, International Journal of Flexible Manufacturing Systems, vol. 8, pp. 23-43, 1996.
[21] Unified modeling language specification. http://www.omg.org/technology/documents/formal/uml.htm, visited September 16, 2006.