A Genetic Algorithm to Generate a Pro-Active Scheduler for

Transcription

1 A Genetic Algorithm to Generate a Pro-Active Scheduler for a Printed Circuit Board Assembly V. Tcheprasov, E. Goodman, W. Punch, G. Ragatz Michigan State University,Computer Science Department I. orenkov Moscow State (Bauman) Technical University, CAD/CAM systems Department Abstract The term "pro-active scheduler" will denote a set of scheduling rules which are optimized OT only for a given set of jobs, but also to minimize the adverse impact of server failures or job additions or deletions during the period for which the scheduler was optimized. This paper presents a genetic-algorithm-based method to produce such schedulers for a real-time Job Shop Scheduling Problem in a changing environment. The empirical results show that this approach can produce schedulers capable of constructing schedules in polynomial time, and that those schedulers can react well to the random failures/changes presented to them. The goal of the genetic algorithm is to choose optimal, time-varying weighting factors for a fixed set of heuristic rules which determine the assignment of each job to any of multiple, distinct servers at each of multiple server stages, in order to minimize the total production costs (including setup, operation, penalty for needing express shipping, and penalty for delayed delivery). 1. Introduction In general, scheduling problems are P-hard, consequently there are no known algorithms guaranteeing an optimal solution and running in polynomial time. It is hardly necessary to say that scheduling is an immensely important practical problem. This has led researchers to explore many approaches to optimal scheduling. Among the many techniques applied to this problem are heuristic methods, mathematical programming methods, neural nets, stochastic optimization methods (simulated annealing and genetic algorithms), and various combinations of them. Unfortunately, many classical algorithms for seeking near-optimal solutions to job shop and related scheduling problems have exhibited severe limitations as to conditions of applicability (highly specific and restricted problems) and/or the quality of solutions provided (rapid decline in solution quality with increasing problem size, etc.). Therefore stochastic, heuristic approaches for which no error bounds are known are also now widely applied in solving real-world scheduling problems, such as the multi-stage, heterogeneous server problem described here. 2. Problem Description The basic static scheduling problem, without additions or deletions of jobs and without server failures, can readily be formulated as an integer programming problem, as follows. There is a set of jobs waiting to be processed through each of several processing stages, in order. At each stage, there are multiple processors, any or all of

2 which might be able to process each job. All of the processing for a given job at a given stage will be completed by a single machine, without interruption. A machine may work on only one job at a time. Between jobs, a known changeover (setup) time is required to prepare the machine to process the next job. The changeover time is zero for similar jobs (those in the same family ) but may be large for dissimilar jobs (those in different families). If there is slack in the schedule, a machine at a later stage may be changed over in anticipation of the arrival of a job from an earlier stage (i.e., a changeover may be done before a job arrives from the previous processing stage). Each job has a known processing (run) time requirement at each stage. The run time required may depend on the machine chosen to process the job. Some machines may be unable to process certain types of jobs. Each job also has associated with it a target due date, which is the latest date the job can be completed and still be shipped by normal freight mode. If a job is completed after its target due date, it may be shipped, at extra cost, by premium freight. In any event, every job must be completed by its 'late date,' which is the latest date that the job can be shipped by premium freight and still reach the customer on time. Each machine has associated with it a run time cost rate and a changeover time cost rate. The formulation below is for three processing stages, with four machines at Stage 1, four machines at Stage 2, and three machines (lines) at Stage otation Indices: i k m index of job numbers, i=1.. (i=1 is a 'dummy' job, representing the initial state of each machine) index of stage (operation) numbers, k=1..3 index of machine numbers, m=1..11 Parameters: C m D i F i H L i P ikm R m S ii'km changeover (setup) cost rate for machine m target due date for job i (last date for normal freight shipment of job) freight premium paid to ship job i after its normal due date a large constant 'late date' for job i (last date job can be shipped by premium freight and reach the customer on time) processing time of job i at stage k on machine m run (processing) cost rate for machine m setup (changeover) time on machine m at stage k, when job i' follows job i Variables: T i = 1 if job i is completed after its target due date 0 otherwise

3 V ikm = 1 if job i is processed on machine m at stage k 0 otherwise W ik = continuous variables used to prevent subtours at stage k X ikm = completion time of job i on machine m at stage k Y ii'km = 1 if job i immediately precedes job i' on machine m at stage k 0 otherwise 2.2 Mathematical Formulation min Z = F i T i + i= R m PikmV ikm + i=1k=1m= C m S i i km Yi i km i=1i =1k=1m=1 Such that: Constraint Set 1 X i1m Pi1m V for i = 1.., m = 1..4 i1m Constraint Set 2 X i2m - X i1 m + H(1- V i2m) P i2m for i = 1..; m = 5..8; m = 1..4 X i3m - X i2 m + H(1- V i3m) P i3m for i = 1..; m = 9..11; m = 5-8 Constraint Set 3 4 W i1 - W i 1 + Y i i 1m -1 for all i i; i i m=1 W i2 - W i Y i i 2m -1 for all i i; i i m=5 11 W i3 - W i 3 + Y i i 3m -1 for all i i; i i m=9 Constraint Set 4 Y i i1m - i=1 Y i i2m - i=1 Y i i3m - i=1 Y i i1m = 0 for m=1..4 i =1 Y i i2m = 0 for m=5..8 i =1 Y i i3m = 0 for m=9..11 i =1 Constraint Set 5

4 Y i'11m 1 for m=1..4 i =2 Y i'12m 1 for m=5..8 i =2 Y i'13m 1 for m=9..11 i =2 Constraint Set 6 11 X i3m - HT i m=9 D i for all i Constraint Set 7 11 X i3m L i m= 9 for all i Constraint Set 8 X i 1m - X i1m + H(1 - Y i i1m) S i i1m + P i 1m for all i i; i i ; m=1..4 X i 2m - X i2m + H(1 - Y i i2m) S i i2m + P i 2m for all i i; i i ; m=5..8 X i 3m - X i3m + H(1 - Y i i3m) S i i 3m + P i 3m for all i i; i i ; m=9..11 Constraint Set 9 X i1m i1m X i2m i2m HV for all i; m=1..4 HV for all i; m=5..9 X i3m HV i3m for all i; m = Constraint Set V ikm = 1 for all i,k m=1 2.3 Explanation of Formulation The objective function minimizes the total cost of premium freight shipments (shipment after target due date), machine run time costs, and machine changeover time costs, plus a large penalty if any jobs are not completed by their late dates. Constraint Set 1 ensures that the Stage 1 completion time for every job is greater than or equal to its processing time on the Stage 1 machine to which it is assigned. Constraint Set 2 ensures that the stage-to-stage precedence relationships are maintained for each job. That is, a job cannot begin processing at one stage until it has completed processing at the prior stage (however, as the formulation is currently stated, the changeover at the latter stage could be completed before processing is completed at the prior stage).

5 Constraint Set 3 ensures that no two operations are processed on any machine simultaneously. The W variables will force the jobs assigned to a particular machine to be arranged in a valid permutation sequence. Constraint Set 4 requires that if a machine gets setup for a particular job, it must also experience a setup from that job to another (the last job in the schedule for each machine will be the dummy job, 1). Constraint Set 5 requires that each machine starts setup for the dummy job, 1. Constraint Set 6 forces the tardiness indicator variable, T i, to take on the value 1 if the last stage of job i is scheduled to be completed after its target due date (express ship or minor penalty date). Constraint Set 7 requires the last stage of every job to be completed by the job's late date, L i (major penalty date). Constraint Set 8 forces the completion time for each job to reflect both processing time required for the job and the setup time required after the completion of the preceding job. Constraint Set 9 requires every operation of every job to be assigned to one and only one machine. Constraint Set 10 requires the completion time variables for all job-machine assignments that are not made to be zero. 2.4 Extension to Above Formulation It should be clear that such a JSSP can be formulated similarly with additional machines at each stage, additional stages, etc. For the scheduling runs performed below, it was extended to model an existing facility with four stages, with four machines at each stage but the last, which had three, for a total of 15 machines. An additional sophistication which was added after the initial explorations were conducted was to allow jobs comprised of multiple batches to begin processing a batch on stage (i + 1) as soon as it completed at stage i. This paper distinguishes between a static and dynamic JSSP. The important difference between those classes is that that in a dynamic JSSP, the preliminary list of tasks and servers presented for scheduling may be altered by events such as failures of servers or additions or cancellations of jobs, which are not considered in the static JSSP. Thus, while a SCHEDULE is a suitable solution to a static JSSP, a dynamic JSSP requires instead a SCHEDULER as its solution. Such a scheduler is typically called a reactive scheduler, because it is capable of generating a new schedule in reaction to a change in the server or job lists during the production period. The solution sought here is a further step -- a "pro-active" scheduler -- in which the set of rules which comprise the scheduler is specifically optimized not for the initial server and task lists, but for scenarios resulting from random changes to lists. 3. Background A detailed theoretical analysis of the scheduling problem can be found in the classical work by Garey and Johnson[4]. Examples of traditional aproaches are described in Balas[1], Lenstra[5], and Carlier and Pinson[2]. Several heuristics were taken for present work from Tanaev et.al.[6]. One of the first articles dedicated to solving the JSSP with a GA was an article by Syswerda appearing in Davis[3]. After that, many articles about

6 applying the GA to various kinds of JSSP appeared in several GA conference proceedings[7]. Most of them describe methods for constructing a schedule for a given problem rather than strategies for creating schedules for general problems. The present work is somewhat similar to (although not derived from) work by Shing and Parker[8]. These authors explored an unknown space using a physical agent, in which the GA was to find bias factors for given heuristics to produce a search strategy. The agent does not use global information to determine the next move in the space, so it applies only local information about the surrounding environment to make a decision. Their method outperforms previous search strategies for most landscape types investigated. The authors suggested that this method is also applicable to a multitude of real-time search/optimization problems. 3.1 Difficulty of Problem The size of the solution space can be roughly estimated as follows: Sp>R *S * (( M )!) Mt where R - number of alternative servers in a stage for one job; - number of given jobs to be scheduled; S - number of stages; M - number of machine in one stage; thus, (/M) is the approximate number of jobs on one server and (/M)! is number of their possible permutations; Mt - total number of servers. For a task presented beneath we have R = 2, = 105, S = 4, M = 4, Mt = 15 and, therefore, Sp > 10**501. The goal for a static SCHEDULER is to find the least expensive schedule, given a fixed set of jobs to schedule, and without any server failures. This is a very large Phard scheduling problem. 4. An Approach to Solving Dynamic JSS Problems To try to reduce search time, the genetic algorithm was used together with a number of heuristics, in order to reduce the number of unreasonable" solutions the GA must evaluate. Each heuristic by itself was designed to make scheduling decisions which are appropriate under some circumstance, according to its criteria. Thus, exploring the solution space is similar to exploring combinations of a set of decision rules, each of which is good in some sense. The attack on the static problem was done using a chromosome encoding the order, at each server, in which a set of heuristics was to be applied to make a scheduling decision. Experiments showed that this approach achieved solutions differing from those found by an exhaustive local search method by no more than 1%. This approach was tried on the dynamic JSSP, but it was clear that an ordering of heuristics found to solve the static problem well is not necessarily well suited to solving the dynamic JSSP. This method performed poorly in the dynamic environment. A new representation was created to use all heuristics simultaneously to assign points to each task/server assignment at each decision point in the scheduling process, and to

7 use the chromosome to store two weighting coefficients for each heuristic. Because the goal was to generate a pro-active scheduler, these coefficients had to be optimized not only for the given jobs at the beginning of the week and perfect server availability, but also for cases in which jobs are added and/or cancelled, and server failures occur. This increased evaluation time, but offered the promise of producing a scheduler which can perform well even in a variable environment. Such a scheduler should avoid allowing rules to dominate whose effectiveness depends in a strong way on the particular individual features of the job mix, which may be negatively impacted by changes in jobs needed or servers available The scheduler is formulated as a set of numerical-valued criteria according to which each task (i.e., one stage's processing for a job) is evaluated at each point when a scheduling decision must be made. These criteria are combined using a set of weights, and the adaptive or learning character of the pro-active scheduler is in learning the weights used to combine these criteria into an overall scheduling decision for each job at each stage, for a particular week's production, using a genetic algorithm. The GA is used "off-line" -- that is, it need be run only once, at the beginning of the week, to find the optimal scheduler, and the scheduler then runs unchanged for the remainder of the week, revising the SCHEDULE only in the face of changes in tasks to be scheduled or the failure of servers. It is important to note that the weight of each heuristic is changed during the course of the week, using linearly varying weights. Thus, a chromosome consists of two values for each criterion -- a slope and an intercept (Fig.1,below). Figure 1. Presentation of chromosome I1 S1 I2 S2 I3 S3... S13 I14 S14 DC = ( I + S * T ) * SCV ; where DC is dynamic_criterion ; I is intercept; S is slope ; T is time ; SCV is the scaled value of the criterion. I.e: dynamic_criterion = ( intercept + time * slope ) * scaled_value_of_criterion; The SCV depends on the set of currently unscheduled tasks. It is normalized using corresponding criteria for all of the tasks currently under consideration. SCV = ( MAX_VC - VC )/( MAX_VC - MI_VC ); where MAX_VC is the maximum value of the corresponding criteria among the current set of tasks being considered ; VC is the current value of the criterion evaluated ;

8 MI_VC is the minimum value. The GA determines a set of weights for combination of the numerical values assigned for each criterion to each task at each stage, and schedules next the task which has the highest aggregate value. Clearly, after the GA is run, the scheduler (using the weights found on the best chromosome from the GA search) may be re-run in "real time" when conditions change, and the schedule produced should be reasonably close to optimal, so long as the nature of the job mix and server outages have not changed radically from the initial set on which the optimization was done. In the operation of the scheduler, decisions are made sequentially about which job to assign next to which server at which stage, based on "points" currently assigned to each task on each machine on which its next operation then could be performed. The due date for each job determines an overall order of consideration for the tasks, and at any time a window of about 10 tasks for each stage is actively under consideration according to the criteria given below (the GA determines the relative importance or weights of each criterion). The sum of the costs of ten simulated weeks (including random failures, additions, and deletions) is used as the antifitness function to be minimized, and because this fitness function is stochastic, each chromosome is reevaluated in each generation. Criteria which are currently used in the scheduler include: 1. Choose the task with the smallest run time on the processing stage. This helps to create a more compact schedule at the begining of processing. 2. Choose the task with the smallest total runtime for all stages. This helps to get all machines working as soon as possible in the work week. First stage xxx(1)xx Second stage i1 xxx(1)xxx Third stage i2 xxxx(1)xxxx Fourth stage i3 xxxx(1)xxx This criterion minimizes idle time (i1+i2+i3) at the beginning of the work week. 3. Choose the task such that run time on subsequent stage minus run time on this stage is maximum (very useful for choosing an order among tasks which are being considered ). Example: Second stage

9 ... aaa(2)aaa_bbbbb(2)bbbbb ^ Third stage... aaaa(3)aaaa bb(3)bb ^ ^End 1 Instead of: Second stage... bbbbb(2)bbbbb_aaa(2)aaa ^ Third stage... bb(3)bb aaaa(3)aaaa ^ ^ End 2 End 1 < End 2 4.This rule is a modification of the previous one. Instead of considering only current and next stage, it considers relations among run times of operations at all stages. Maximize run(i+1)/run(i) +run(i+2)/run(i+1)... i-current stage (does not play any role at last stage). 5.Choose the task minimizing the setup time between different families of tasks. 6.Choose the task that minimizes the idle time of server. This keeps server busy even if it is not the cheapest server for this task. 7.Choose the task according to earliest possible start time. This rule gives priority to the task which can begin to process sooner than any others at the current stage. 8.Choose the task which can be processed fastest. This frees servers soonest for other jobs. Rules 9,10 and 11 correspond to cost characteristics rather than scheduling ones, and are used to work toward the main criterion, which is the cost of completion of the whole schedule. Prefer tasks according to their: 9. setup cost, 10. run cost,

10 11. total cost (setup cost + run cost). 12.Choose the task which has least slack time to its target (soft) due date. 13.Choose the task which has least slack time to its late (hard) date. The genetic algorithm is implemented in GALOPPS, a freeware parallel genetic algorithm package developed by one of the authors, and employs island parallel subpopulations with occasional exchange of individuals. In experiments we have used 8 populations, 150 individuals each. Results shown below achieved in cycles, each of 10 generations, i.e. exchange of individuals occurs after each cycle of 10 generations. Population were structured as a ring with migration in one direction of the best individuals of population. 5. Results Experimental results have been obtained on a realistic prototype problem modeled on a Printed Circuit Board assembly line. There are 105 jobs in the sample week, chosen from 60 types of boards (some must be shipped more than once). Board types are grouped into 20 families (and, by definition, setup time between boards of the same family is 0). The costs are determined by the cost/minute of runtime for each machine, of setup time for each machine, of late shipping (after "PEALTY_TIME" -- the "soft" deadline for truck ship -- shipping by air is required) and a penalty for any job shipped after the second, or "hard", deadline ("LIMIT_TIME") for the job. Both the static and dynamic JSS Problems were tested for data representative of a line with 4 stages, and with each stage having 4 machines except the last, which has 3. Each type of board can be made on at least (and usually exactly) two machines at each stage, but typically with different amounts of time required and different costs per unit time. Each job is comprised of 1 or more "batches" of 50 boards, all of which are processed on the same server at each stage without interruption by other jobs; however, processing of a completed batch at the next stage may be begun before all batches have been processed at a given stage. Setup time is allowed to begin in anticipation of the completion of a batch on the previous stage. While for early runs the penalties for express and late shipment were set at 1000 and 10,000, respectively (indicated by * in column), for later comparison with the dynamic JSSP runs, those chromosomes were also evaluated using penalties 8,000 and 80,000, respectively. For the static JSSP, the approach encoding order of application of heuristics for each server yielded the following results (from 1 thrugh 4 in the table below): Penalty [1000, 10000] Penalty [8000, 80000] o.of soft & hard violations 1. 22,209.50* 22, , ,145.85* 23, , ,114.75* 24, , ,058.70* 22, , 0

11 5. 21,980.00* 23, , 0 Row 5 was achieved using an exhaustive local search heuristic, which works in the following way: the algorithm uses as input the list of tasks ordered according to their worst case slack time (i.e., the minimum time between the due date and the processing time on the slowest machines, assuming worst case setup times). The algorithm then considers all possible assignments of a small (7, in this case) window of tasks, taking them from the beginning of the input list, and makes a decision on some assignments. It then shifts the window to add the number of tasks just assigned from the next tasks on the list, and proceeds in that fashion until all jobs are scheduled. The dynamic JSSP example used the same data about the job stream and servers, but added the following information: 1) EACH MACHIE has a probability of 0.02 of failing at some time during a week. (Thus, the probability that the week has O failures is 0.98**15, or about.7386, since there are 15 machines.) These failures occur at uniform random. Failure duration is negative exponentially distributed, with a mean of 2.0 hours. The task being processed (or setup for) when the failure occurs does OT migrate to another machine -- its processing time on that stage is simply increased by the duration of the failure. (Therefore, this can be implemented by simply adding the calculated failure duration to the time of processing of the task the server was doing when the failure occurred -- since the task does not migrate.) 2) There is a probability of 0.3 that one new job (not in the set of jobs on which the scheduler was optimized) will arrive at some time in the first half of the week. ew jobs will not arrive after that, for delivery that week. When a new job arrives, it is made to be a second copy of one of the jobs originally scheduled for that week, chosen at random. Its "soft" due date is chosen at random in the second half of the week, and its hard due date is later by the difference between hard and soft dates of the job copied. 3) There is a probability of 0.3 that exactly one job will be cancelled. The cancellation will be known at some time between 1440 and 4320 (minutes into the week), and will affect a job which has OT YET been started at the time the cancellation becomes known. The job MUST be ICLUDED in the schedule first generated at time 0, and then later removed (deleted as a job to be done). (Thus, taking into account failures, added jobs, and cancellations, the probability that the week passes with O failures, added jobs, or cancellations is (0.98**15) * (.7) * (.7) ~=.3619.) Results achieved with weighted coefficients of heuristics for static JSSP: Penalty [1000, 10000] Penalty [8000, 80000] o.of soft & hard violation 1. 22, ,319.45* 11, , ,118.95* 10, , ,095.90* 11, 0

12 4. 22, ,072.75* 10, 0 Results for typical weeks with different events (pro-active scheduler, best solution found) Trial 0 cost = Trial 1 cost = Trial 2 cost = Trial 3 cost = Trial 4 cost = Trial 5 cost = Trial 6 cost = Trial 7 cost = Trial 8 cost = Trial 9 cost = The cost of the schedule when no changes in jobs or servers occur is 2,331,945 (e.g.,trial 1). Simulation time of 10 schedules is 3 seconds. 6. Conclusions The success of this approach depends strongly on the quality of the criteria provided to the scheduler, and the degree to which the search can fully explore the space of possible ways of combining those criteria. It is not obvious that a single rule can be constructed from a small set of such criteria which is a relatively optimal robust scheduler. Various methods other than linear combination of linearly time-weighted criteria may be needed to obtain nearly optimal performance. However, preliminary results using this approach have demonstrated that the method can outperform several fixed heuristic methods. Further work will explore more general ways of combining and generating heuristics. References [1] E.Balas. Machine sequencing via disjunctive graphs: an implicit enumeration algorithm. Operations Research, 17: , [2] J.Carlier and E.Pinson. An algorithm for solving the job-shop problem. Management Science, 35(2): , [3] L.Davis. Handbook of Genetic Algorithms. International Thomson Publishing company, 21: , [4] M.Garey and D.Johnson. Computers and Intractability. Bell Telephone Laboratories, 242, [5] J.Lenstra. Sequencing by Enumerative Methods. Technical report, Mathematish Centrum, Amsterdam, 1976.

13 [6] V.Tanaev, U.Sotskov, and V.Strusevich. Theory of scheduling. Multistage system. M.:auka.Gl.red. phis.-math. lit., [7] Proceedings of International Conference on Genetic Algorithms. Morgan Kaufman Publishers, Inc [8] M.Shing and G.Parker. Genetic Algorithm for the Development of Real-Time Multy-Heuristic Search Strategies. Proceedings of the Fifth International Conference on Genetic Algorithms. Morgan Kaufman Publishers, Inc , 1993.