Bray - A Simulation-Based Approach To Job Shop Scheduling - 2007

A Simulation-Based Approach
to Job Shop Scheduling

Shawn Bray

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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 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

11. Figures and Tables

Figure 1. Assembly Line with Sample Production Planning Calculation

Figure 2. Job Shop with Sample Production Planning Calculation

37

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

progressed-by
progresses controlled-by
controls
populates
populated-by
queries queried-by
Simulation-Based Scheduling (SBS) System
Static Structure Diagram
subsystem
SchedulingModel
subsystem
Simulator
subsystem
ProductionModel
subsystem
Interface
activates
activated-by
"Scheduling Loop"

Figure 4. Simulation-Based Scheduling System (SBS) Static Structure Diagram

39

Figure 5. ProductionModel Static Structure Diagram
40

Figure 6. SchedulingModel Static Structure Diagram
41

Figure 7. Resource Statechart Diagram
42

Figure 8. assignJobs() Sequence Diagram
43

Figure 9. selectNextBatch() Sequence Diagram
44

Figure 10. Screenshot of SIMUL8-Planner Software Implementation

Process

Supervisor

Source

Queue

Resource

Exit

Figure 11. Production Model Components

45

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

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

[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.

Bray - A Simulation-Based Approach To Job Shop Scheduling - 2007

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bray - A Simulation-Based Approach To Job Shop Scheduling - 2007

Hochgeladen von

Copyright:

Verfügbare Formate

A Simulation-Based Approach

to Job Shop Scheduling

Das könnte Ihnen auch gefallen