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

8/11/2019 Bray - A Simulation-Based Approach to Job Shop Scheduling - 2007

1/52

A Simulation-Based Approach

to Job Shop Scheduling

Shawn Bray

A thesis submitted in partial fulfillmentof the requirements for the degree of

BACHELOR OF APPLIED SCIENCE

Supervisor: D. Frances

Department of Mechanical and Industrial Engineering

University of Toronto

March 2007


2/52

A Simulation-Based Approach to Job Shop Scheduling Shawn Bray

Abstract

The job shop scheduling problem (JSSP) is a complex optimization problem that isencountered in a variety of manufacturing environments. Many heuristic solution

techniques have been developed for abstract instances of the JSSP, but practitionersoften 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 arelatively 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: thesimulation-based approach to job shop scheduling.


3/52

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.


4/52

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


5/52

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


6/52

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.


7/52

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>0resources raavailable, represented by the set R={r1,r2,r3,,rm}.

C2. There are n>0jobs jato perform, represented by the set J={j1,j2,j3,,jn}.

C3. Each job ja consists of a set of pa > 0 operations oa,b, represented by the set

Oa={oa,1,oa,2,oa,3,,oa,pa}.


8/52

3


C4. Each operation oa,bhas an unknown start time sa,b > 0, an unknown end time

fa,b > 0, and a known duration ta,b > 0.

C5. Each operation is performed by a resource. A tuple (oa,b , rc) is defined for

each operation, denoting that operation oa,bis performed by resource rc.

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: fa,b =sa,b + ta,b.

C8. Operation oa,b+1 cannot be started until operation oa,bis completed: sa,b fa,b+1.

C9. No 2 operations of a single job are performed by the same resource:

(oa,b, rc) (oa,e,rf) (be) (cf).

Based on this definition, the objective of the JSSP is to determine the start time sa,bof

each operation oa,bsuch 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(fa,b) min(sa,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.


9/52

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

(oa,b , rc) 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, da > 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

Za a=1 ____ ,

where Za = fa,pa da if fa,pa> da

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


10/52

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


11/52

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.


12/52


13/52

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


14/52

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


15/52

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 ra available, represented by the set

R = {r1, r2, r3, , rm}.

M2. (C2) There are n > 0 jobs ja to perform, represented by the set

J = {j1, j2, j3, , jn}.

M3. (C3) Each job jaconsists of a set of pa > 0 root operations oa,b, represented by

the set Oa={oa,1, oa,2, oa,3, , oa,pa}.

M4. Each job rahas a corresponding quantity qa> 0.

M5. There are u > 0 material units xa available, represented by the set

X = {x1, x2, x3, , xu}.

M6. Each material unit xahas a corresponding size za> 0.


16/52


17/52

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 Ib,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:

za qba

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 sa,b,cof each operation oa,b,csuch that

the makespan, max(fa,b,c) min(sa,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.


18/52

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 jais assigned its own due date da.

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


19/52


20/52

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


21/52

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.


22/52

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


23/52

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.


24/52

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 UpdateModelandScheduleare no doubt obvious to the

reader. Monitorrepresents the process of comparing the progress and performance

of the generated schedule to the actual state of affairs in the facility. Whenever a

{schedulediscrepancy}is encountered for example, an unexpected machine

breakdown occurs, or production is simply not proceeding as quickly as anticipated

a new Scheduleactivity 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

DefineObjectiveuse 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


25/52

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 Interfacesubsystem is a special case; since each use case represents an

interaction between the user and the system, the Interfaceis involved in

essentially all use cases to some extent. However, it is particularly important for

the UpdateModel, BuildModel, EvaluateSchedule, and Monitoruse cases,

since the success of these tasks is highly dependant on the user interface design.

The ProductionModelsubsystem 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 ProductionModelis

primarily responsible are UpdateModeland BuildModel.

The SchedulingModelsubsystem stores the intelligence for all scheduling

heuristics applied to the JSSP. This consists of the algorithms for the assignment

problem and sequencing problemas well as the data used to prioritize the orders

and material units considered by these algorithms. An alternative perspective is

that the ProductionModelis the primary repository of problem constraint data,

and the SchedulingModelis the primary repository of data related to the

scheduling objectives. Use cases addressed by the SchedulingModelinclude

DefineObjective,PrioritizeOrder,LimitWip,and CreateSchedule.

The Simulatorsubsystem represents the discrete-event simulation engine that is

the foundation for SBS. It facilitates an incremental approach to the completion of

theCreateScheduleuse case by incorporating the notion of time into the main


26/52

21


sequencing algorithm. This is achieved by way of a scheduling loop, as

indicated on the static structure diagram. When the CreateScheduleuse case is

initiated by the user, a scheduling loop begins in which the Simulatorupdates

the state of the ProductionModelbased on its internal event list (i.e. the

Simulatorsimulates 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 ProductionModeland resumes the simulation of operations until

another decision point is reached or the simulation reaches the end of the

scheduling period.

The ProductionModel andSchedulingModel 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 Interfaceand Simulatorsubsystems 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.


27/52


28/52


29/52


30/52


31/52


32/52

27


6.5 Resource Statechart Diagram

The Resourceclass 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 Resourceand the conditions

for state transition.

The initial state of a resource is defined by the initial conditions defined for the

Downtimeand MaterialUnit objects. A Resourcecan therefore start the simulation

in the Down state (i.e. performing Downtime) or in the Loading, Working or

Unloading states (if the currentLocation attributeof at least 1 MaterialUnit

references the Resource). If none of these initial conditions apply, the Resourcewill

call selectNextBatch()from theSequencerclassof the SchedulingModelin 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.


33/52

28


A Resource enters the Down state whenever the earliestStartof its next

Downtime is reached while the Resourceif Idle, or when the Resourcecompletes

work and/or unloading within the starting interval (i.e. earliestStartto

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 Resourceto 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 functionassignJobs()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

eachJobis 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 Assignerstarts by

determining priority scores for all Jobobjects (as determined by calls to the


34/52

29


PriorityCalculation object). Then the Assigneriterates through all Jobobjects

in descending order of priority, and creates as many Assignmentobjects as necessary

to fulfill the quantityof each Job. If no existing MaterialUnitcan satisfy an

Assignment, RequiredMaterialobjects are created (as well as a Routeobject based

on the ProductRouteassociated 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 Resourcecompletes an Operationor

receives a new MaterialUnitwhile idle. Once the Sequenceris 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 minLoadand 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 theResource


35/52

30


is considered. If no PotentialBatchcan 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 PriorityCalculationobject, and the highest ranking PotentialBatch is

marked for processing; this involves instantiating the PotentialBatch as aBatch

and committing the sequencing decision by creating a SequencedEvent to be

reported to the user as part of the generated schedule.

Since all MaterialUnitobjects 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 MaterialUnitthat has not yet completed an earlier

Operation). This would require the Sequencerto evaluate the tradeoff between

immediately processing a low-priority group of MaterialUnitobjects and delaying

processing for a short period in order to expedite processing of an upcoming, higher-

priority group of MaterialUnitobjects.

7. Design Validation

To verify the completeness of the system designpresented in section 6, Table 1 on

page 45 presents a complete mapping between the objects of the 2 SBS subsystems of

interest (i.e. ProductionModeland 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


36/52

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 ProductionModeland

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


37/52


38/52


39/52


40/52

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.


41/52

36


11. Figures and Tables

Figure 1. Assembly Line with Sample Production Planning Calculation

Figure 2. Job Shop with Sample Production Planning Calculation


42/52

37


SBS

User

BuildModelUpdateModel

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


43/52

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


44/52

39


Figure 5. ProductionModel Static Structure Diagram


45/52

40


Figure 6. SchedulingModel Static Structure Diagram


46/52

41


Figure 7. Resource Statechart Diagram


47/52


48/52


49/52

44


Figure 10. Screenshot of SIMUL8-Planner Software Implementation

Process Supervisor Source

Queue Resource Exit

Figure 11. Production Model Components


50/52

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. OperationRootOperation, 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 PreemptionScheduler.idleResource(Resource),

Sequencer.selectnextBatch(Resource)

M13. Operation PrecedenceOperation.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-AllocationAssignment.quantity,

MaterialUnit.updateStatus(Job)

O3. Resource ChangeoverChangeover, 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 FenceSequencer.timeFence,

Sequencer.getStatus(timeFence)

O8. Initial Job Shop ConditionsExistingMaterial,

MaterialUnit.currentLocation


51/52

46


References

[1] Artigues, C., Billaut, J. and Esswein, C., Maximization of solution flexibilityfor 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 EvolutionaryComputation (CEC 2005), vol. 3, pp. 2848 2855, Sept. 2nd 5th, 2005.

[9] Holthaus, O. and Rajendran, C., Efficient rules for dispatching in a jobshop, 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 flowtimes 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.


52/52

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

Documents

Transcript of Bray - A Simulation-Based Approach to Job Shop Scheduling - 2007