10.1.1.10.624

download 10.1.1.10.624

of 6

Transcript of 10.1.1.10.624

  • 7/27/2019 10.1.1.10.624

    1/6

    Applying Genetic Algorithms to the Optimization of ProductionPlanning in a Real-World Manufacturing Environment

    Roland Braune, Stefan Wagner, Michael Affenzeller

    Institute of Systems Theory and Simulation

    Johannes Kepler University

    Altenbergerstrasse 69

    A-4040 Linz, Austria

    email: [email protected], {sw,ma}@cast.uni-linz.ac.at

    Abstract

    In this paper we present an optimizationapproach to a real-world production plan-ning problem. Based on raw data that havebeen extracted from the Production, Plan-ning and Control System of a company whichproduces special purpose vehicles and equip-ment, we have developed an architecture ofan optimization system for production plan-ning and scheduling in the manufacturingline of this company. The paper itself is di-vided into two major parts. The first part

    mainly deals with the theoretical backgroundof production planning problems. In the sec-ond part of the paper we give an overview ofthe concrete scenario which is the subject ofour research. Based on these fundamentals,we describe our approach to the problem, themodelling process and the architecture of theoptimization system we plan to implement.

    1 Introduction

    Many modern industrial production environments stillrely on pure expert knowledge for production planningand scheduling purposes. Optimization in an algo-rithmic sense is rare and mostly not performed at all.This may seem amazing at first glance since automa-tization and electronic data processing have pervadedmodern companies in almost any area of their dailybusiness. For manufacturing lines in particular, thereexist so called Production, Planning and Control Sys-tems that serve for data storage and as a support toolfor production related management activities. Suchsystems are designed in a highly generic and versatileway in order to be applied in many different companiesno matter what products they actually manufacture.The systems try to distill the most common and es-sential aspects of production data. Customization isof course possible but it mostly requires deep insightand an immense effort.

    Therefore, the concept of Production, Planning andControl Systems is, at present, not applicable for theoptimization of production planning and scheduling inmost of the cases. On the one hand a possible opti-mization approach will have to consider especially the

    domain dependent characteristics, specific propertiesand constraints that distinguish production systemsfrom each other. On the other hand, the objectivesof optimization may vary from company to company,they can be of various different kinds (makespan mini-mization, maximizing machine occupation, etc.), indi-vidually or combined, equally weighted or associatedwith priorities. All these facts make it very difficultto develop a generic optimization tool that meets themanifold requirements of the production industry.

    The problem of (optimal) production planning andscheduling is not new, however. Due to its increasing

    relevance, this issue early attracted the attention ofacademic research. Yet in 1960, Giffler and Thomp-son described the solution of production schedulingproblems from an algorithmic point of view [Gifflerand Thompson, 1960]. Considerable theoretical ad-vances have been made since that time, leading tothe research area of Job Shop Scheduling Problems(JSSP) [French, 1982] which provides the fundamentaltheory and mathematical methodology for productionplanning and scheduling problems in general. TheJSSP and similar scheduling problems are combina-torial optimization problems and commonly classifedas NP-hard ordering problems [Garey and Johnson,1979]. Due to the NP-hardness it is almost impossi-

    ble to solve these problems exactly, even for relativelysmall problem instances. Exact methods exist, likethe branch and bound approach by Carlier and Pinson[Carlier and Pinson, 1989], but they are only of theo-retical relevance due to their exponential runtime com-plexity. In real-world production environments, prov-able optimality is not the criteria a solution must sat-isfy. Instead it suffices to compute results close to theoptimum but in a reasonable amount of time. Exactlythe latter is achieved by heuristic methods that aredominating in the field of JSSP. The most importantand popular ones are Local Search approaches likeTabu Search [Barnes and Chambers, 1995] and Evo-lutionary Algorithms, especially Genetic Algorithms

    (GA) [Yamada and Nakano, 1997].One may think that based on well-established the-

    ory and a multitude of existing solution techniques,the development of a production planning optimiza-tion tool for a specific industrial application will pro-ceed smoothly and in a straight-forward manner. This

  • 7/27/2019 10.1.1.10.624

    2/6

    , , .like the one at hand usually tend to differ tremen-dously from artifcial and designed JSSP benchmarkproblems. The standard Job Shop Scheduling Prob-lem in general is based on the formal description of ahighly simplifed and abstract production system (cf.Section 2). Hence some difficulties may arise whentrying to describe an existing, concrete productionsystem in a way that is precise enough for the prob-lem to be analyzed and processed furtherly by existingand possibly customized methods. In the case of ourproject these difficulties were one of the main chal-lenges especially in the initial phase of our work (cf.Section 3).

    Besides the problem analysis, our solution approachitself will be the second important aspect covered inthe paper (cf. Section 4). We will describe the mod-elling and the architecture of the target system, op-timization specific details such as the chosen methodand problem encoding issues. Furthermore, we willoutline the planned implementation phase in a shortmanner (cf. Section 5).

    2 The Standard Job Shop Scheduling

    Problem

    In order to provide a common basis for the followingsections, we describe the most elementary concepts

    and formalisms with respect to the standard Job ShopScheduling Problem (JSSP).

    The classic n m minimum-makespan Job ShopScheduling Probem is given by a finite set J ofn jobs {Ji}1in and a set M of m machines{Mi}1im [Jain and Meeran, 1999]. Each job Jihas to be processed on every machine. For this pur-pose, a job is subdivided into a set of mi operations{oij}1in,1jmi which have to be scheduled in astrictly sequential way according to a given techno-logical order, also referred to as the precedence con-straint. Thus oik denotes the operation of job Ji thathas to be processed on machine Mk for a certain unin-terrupted processing time ik where each machine can

    process only one job at a time (capacity constraint).The time span needed to complete all operations ofall jobs is known as the makespan Cmax. Given thestarting times tik 0 for each operation the defini-tion of the minimum makespan Cmax with respect toall feasible schedules can be informally written as

    Cmax = min(Cmax) =

    = minfeasible

    schedules

    max(tik + ik) : Ji J,Mk M

    .

    In order to illustrate the formal specification we willpresent now an example of a 33 JSSP (3 jobs, 3 ma-chines). The technological order of operations (ma-chine sequence) is shown in Table 1. The first numberin each column represents the machine Mi on whichthe operation has to be processed whereas the numberwithin the parentheses denotes the required process-ing time tik. Figure 1 depicts one out of many fea-sible schedules for this problem instance. This kind

    Table 1: A 3 3 JSSP instance

    Job Machine Sequence

    1 1 (3) 2 (3) 3 (3)

    2 1 (2) 3 (3) 2 (4)

    3 2 (3) 1 (2) 3 (1)

    time

    J1

    J3

    J2

    J1

    J1

    J3

    J3

    J2

    J2

    M1

    M3

    M2

    0 2 4 6 8 10 12

    Figure 1: A schedule for a 3 3 JSSP instance

    of graphical representation is referred to as the GanttChart of a schedule.

    3 Description of the Actual Problem

    3.1 The Main Entities of the ProductionSystem

    Customer Orders:Customer orders are the most important elementsin the production system and the company as awhole. They determine what has to be producedand when it has to be delivered. In our case, wedistinguish two main types of customer orders:(1) vehicle orders and (2) component (equipment)orders.

    Production Jobs:A production job is the top level entity in theproduction system. The purpose of production

    jobs is the manufacturing of parts. Hence theydefine the final product, the amount to be pro-duced and a due date. There is a clear anal-ogy between production jobs and customer ordersand we will also regard customer orders as jobs.However, the main difference is that the scope ofproduction jobs is restricted to the internal pro-duction management. A production job never di-rectly corresponds to a customer order nor doesit necessarily have to be related to a particularone. Production jobs just produce parts, eitherto satisfy needs that arise from customer orderssuch as (sub-)components or they simply serve forstocking purposes.

    Production Processes:For the stepwise accomplishment of a productiontarget, both customer orders and production jobsinvolve production processes which have to beperformed one by one according to a given se-quence. Each process is to be performed on one

  • 7/27/2019 10.1.1.10.624

    3/6

    us omer r er

    Production Process 1

    Part 1.1

    Production Job 1.2.1

    Production Process 1.2.1.1

    Production Process 1.2.1.2

    Part 1.2.1.2.1

    Part 1.2

    Part Order 1.1.1

    Part Order 1.1.2

    Figure 2: Tree-like view on the production system

    single workplace by a specified number of workers.It has a definite duration (workload) and may re-quire a setup time. Usually, a production processis also associated with a list of parts which haveto be available before the process can start.

    Parts:As already mentioned above, the availability ofparts can be a prerequisite for the execution ofproduction processes. Hence parts and their welltimed availability are issues that are of centralimportance in the production system. There ex-ist two different types of parts: Production parts

    on the one hand are manufactured in the com-pany itself. Typically, one production part canbe associated with one or more production jobs,possibly with different due dates. Purchase partson the other hand are ordered from suppliers. Alist of one or more orders may exist for one pur-chase part determining amount and date of eachcorresponding delivery. Of course there is a stockfor both kinds of parts and usually most of theparts are in stock up to a certain amount.

    Certain complex products such as vehicles are man-ufactured not only using ready-made parts but alsocomposite parts which have to be assembled them-

    selves from other parts. These parts can again besimple parts or composite parts. The level of nestingcan be arbitrarily deep, depending on the complexityof the final product. This fact suggests a tree-like viewonto the production system as shown in Figure 2.

    3.2 Workplaces and Allocation Scheme

    Workplaces are characterized by a definite per-day ca-pacity in hours which is the sum of the capacities ofall workers assigned to this workplace. A single work-place might be able to perform more than one pro-duction process at the same time if its capacity andthe number of available workers is sufficient.

    3.3 Optimization ObjectivesThe main task of our optimization tool for the givenmanufacturing system is to find an optimal scheduleor, in other words, an optimal sequence of productionprocesses for each workplace. The optimization ob-

    jectives can be formulated as follows: (a) Minimizing

    termined delivery dates, thus the mean earliness andtardiness and (b) maximizing the workplace utiliza-tion.

    4 Solution Approach

    In this section, we will present our solution approachto the problem described above. As our optimiza-tion system is meant to be purely software-based, wediscuss the modelling and architectural aspects in asomewhat software-oriented manner.

    4.1 Data Representation and

    AbstractionsIn Section 3.1, we have already identified the mainentities of the production system as well as its struc-ture. For software based processing, it is necessary torepresent these data in an adequate way. Due to thefact that we have chosen an object oriented program-ming language for our optimization tool, we modelthe main entities as classes. This offers several advan-tages: Firstly, we reduce complexity and save memoryby including only the relevant attributes of a customerorder, production job, part or part order. Secondly,by mapping each customer order, production job, partand part order in the production system to an ob-

    ject (instance) of the corresponding class, we can eas-

    ily represent the tree-like structure of the productionsystem by linking objects appropriately. Finally, bytransforming the raw data from the companys pro-duction planning and control system into a structureof objects, we have created the data basis for our soft-ware system. As we will describe in the following,this data basis serves as the starting point for furtherabstractions in our architecture.

    It is evident that our input data differs significantlyfrom the data layout the standard JSSP is based on.On the one hand, the standard JSSP only knows Jobsand Operations and on the other hand, jobs are au-tonomous in the sense that there are no sequentialdependencies between two or more of them. Exist-ing approaches to job shop scheduling problems likethe ones we will use (in a modified form) rely on thisstandard data scheme. The problem was to modify thestructure of our input data in order to conform at leastbasically to the standard scheme. As already statedin Section 3.1, there is a close relationship betweencustomer orders and production jobs, both incorpo-rate production processes and both have a productiontarget. Therefore we make an abstraction here andintroduce a class Job representing either a customerorder or a production job. The associated produc-tion processes are also described by a correspondingclass, namely Operation. However, for better under-standing, we will still use the terms customer order,production job and production process where ap-propriate.

    One of the most important issues that remain, isthe correct reproduction of the tree-like structure ofthe production system, thus the dependencies between

    jobs that emerge from the possible demand for (com-

  • 7/27/2019 10.1.1.10.624

    4/6

    .a real tree of objects as the corresponding representa-tion, hence a nested structure of Job-instances, wouldagain violate the restrictions imposed by the standardJSSP data model. The idea is to resolve the dependen-cies in question through mere temporal relationshipsor, to be more precise, by providing each productionprocess with a starting time. This starting time maybe affected by several factors (assuming that the pro-duction process requires at least one part for beingstarted): If all required parts are in stock, the pro-duction process can start immediately. In the con-trary case, as far as purchase parts are concerned, weare confined to the fixed delivery dates of the existing

    part orders, so we rely on absolute time information.Concerning production parts that are not in stock andthus launch a seperate production job, the situationis more complicated. The new job has to be finishedin order for the part to become available, but the fin-ish time of the job cannot be determined in advance.This is a characteristic of the schedule building algo-rithm (see Section 4.2), which is executed in a step-wise way and only sees the operations that are cur-rently schedulable at a certain time. If we launch anew production job, it will take the schedule build-ing algorithm a particular number of steps until alloperations of the new production job are scheduled.Now the part is available, and the production process

    that has been waiting for the part can possibly start(become schedulable), of course only if all other partrequirements are supplied as well.

    It is a matter of fact that production processes be-longing to customer orders have to be scheduled pri-marily and the ones associated with production jobs(usually) will not become schedulable until they pro-duce a part needed by another production process al-ready considered by the schedule building algorithm.Therefore we categorize jobs by their scheduling prior-ity. Customer orders are regarded as primary jobs, theset of secondary jobs consists of all jobs that producea part required by another jobs production process.The tertiary jobs at last, are formed by the remain-

    ing jobs that either still have no other job to producea part for or just serve for stocking purposes. Thedistinction between primary and secondary jobs is amatter of convenience. It simplifies the test for thequality of a solution which is mainly influenced by thefinish dates of the customer orders as already stated inSection 3.3. The exact way how the schedule buildingalgorithm proceeds with these three categories of jobswill be the subject of the following section.

    4.2 Schedule Building

    In 1960, when Giffler and Thompson published theirarticle on algorithms for solving production schedulingproblems [Giffler and Thompson, 1960], optimizationwas not yet of such a great importance as it is nowa-days. The primary objective was to find a correctschedule for operations of given jobs in considerationof precedence and capacity constraints (in the sense ofthe standard JSSP for example). Of course, the result-ing schedules are of practical quality though they are

    1. Put the first sche ula le operation ofeach job into the set C.

    2. Choose an operation o from C withthe earliest possible starting time.

    3. Determine the machine M on whicho

    has to be processed and build theset G consisting of all operations in Cexecuting on M.The set G is called the conflict set formachine M.

    4. Remove operations which start laterthan o from the set G.

    5. Select one operation from the conflict

    setG

    , place it into the schedule andremove it from the set C.

    6. Insert the successor of operation o

    into the set C (if available).

    7. IfC = goto step 2.

    Figure 3: The non-delay scheduling algorithm

    in no way optimal with respect to a particular objec-tive. The classic Giffler and Thompson algorithm, alsocalled the GT algorithm, produces schedules in whichno operation can be scheduled earlier without delay-ing some other operation. Schedules of this kind arecalled active schedules. The constraints active sched-ules have to satisfy can even be furtherly reinforced.The so called non-delay schedules are active sched-ules in which operations are arranged such that themachine idle time is minimized, meaning that no ma-chine (or workplace) is ever left idle if one or more op-erations are schedulable on that very machine. For theminimum-makespan JSSP described in Section 2, theoptimal solution is known to be among the set of activeschedules. In the case of our optimization objectives(see Section 3.3), we claim that the optimal solutionwill be found in the set of non-delay schedules. The

    non-delay scheduling algorithm is structurally similarto the GT algorithm and its mode of operation is out-lined in Figure 3.

    In the architecture of our optimization system theschedule builder is modelled as a separate class. Asan input, the schedule builder takes jobs of the dif-ferent categories described in the preceeding section(see Section 4.1) and the output schedule represents aby-the-day allocation plan for each workplace in themanufacturing line. Operations of primary jobs andsecondary jobs are tried to be scheduled wheneverpossible whereas operations of tertiary jobs becomescheduling candidates only if there is no other opera-tion schedulable and thus free capacities are available.Of course it is also the task of the schedule builderto check the availability of parts for each operation(production process) and to determine whether a newproduction job is required for a part and thus has to bemigrated from the group of tertiary jobs to the groupof secondary jobs.

  • 7/27/2019 10.1.1.10.624

    5/6

    .

    The most essential aspect of non-delay (and also ac-tive) schedule building is the resolution of the conflictbetween one or more jobs on a machine [Vazquez andWhitley, 2000]. The standard mechanisms for con-flict set resolution are of a heuristic nature and caneither be random in the simplest case or involve fixedscheduling rules (priority rules) [Panwalkar and Iskan-der, 1977; Morton and Pentico, 1993] for choosing one

    job from the conflict set. These techniques are, how-ever, generally insufficient for finding an optimal ornear-optimal solution since searching for it would sim-ply mean trying out different random seeds or schedul-

    ing rules in a completely undirected and in no waytarget-oriented fashion. What simple mechanisms arenot able to perform, can be achieved by classic opti-mization methods as they were already mentioned inSection 1 in the context of the JSSP. They provide adirected search and a stepwise improvement of solu-tions in a systematic way.

    As far as our solution approach is concerned, wehave chosen Genetic Algorithms (GA) [Holland, 1975]as the underlying heuristic optimization concept. In-tensive research related to GA approaches to job shopscheduling problems has been done in the last decadeand therefore we can build upon well developed theo-retical fundamentals and practical experiences in this

    area. As the quality of solutions a GA might gener-ate is heavily affected by the problem encoding andthe associated crossover operators, these issue wereone of the most important theoretical constituents ofour work until now. In fact it is the solution of theproblem rather than the problem itself which is en-coded for the genetic algorithm, since - speaking inthe terms of GAs - an individual corresponds to a so-lution. However, in the case of scheduling problemsthe term solution may have two different meanings.Many GA based approaches are designed in a waythat a solution in the sense of the genetic algorithmonly provides a guidance for resolving the conflict seton a given machine such that the resulting schedule

    - the solution of the JSSP itself - becomes preferablyoptimal. Some other encodings are based on the di-rect representation of an (active) schedule by an in-dividual and some variants even rely on completelydifferent scheduling building procedures. Accordingto [Yamada and Nakano, 1997], the existing encodingvariants can be roughly classified into the categoriespresented in Table 2.

    We assessed the existing encoding schemes for suit-ability for our special problem, their practicality andsimplicity (ease of use) and their overall performance.We came to the conclusion that permutation represen-tations like the job sequence matrix and the permuta-tion with repetition were the most promising ones andfit best into the scope of our problem. However, wecannot definitively decide in advance which GA ap-proach will in fact yield the best results afterwards.For this reason the schedule building part of our ar-chitecture has been designed to provide independenceof a certain optimization method in general and of a

    Table 2: Classification of common JSSP representa-tions for GAs

    Category Representatives /Crossovers

    Binary representation Disjunctive graphbased encoding

    Permutation represen-tation

    Job sequence matrix,Permutation with rep-etition

    Heuristic crossover us-ing an active schedule

    builder

    GT based crossover

    Genetic enumeration Priority rule basedGA, Shifting bottle-neck GA

    Genetic local searchand multi-stepcrossover fusion

    Neighbourhood searchcrossover, MSXF

    special encoding in particular. Of course we are re-stricted to optimization methods and encodings thathave been developed to be applied to the classic non-

    delay (or GT) schedule building process.The proposed architecture is framework-like: Theschedule builder itself is able to use different imple-mentations of an interface named ConflictSetResolver.Concrete implementations such as a job sequence ma-trix based one can be easily plugged in by calling theschedule builder with an instance of the correspond-ing class as an argument. The schedule builder gen-erates a schedule guided by the conflict set resolvingmechanism a job sequence matrix provides for exam-ple. The schedule is evaluated by a fitness functionand the computed quality value is the fitness value ofthe associated individual, thus the actual job sequencematrix for instance.

    As far as crossover operators are concerned, we planto implement at least the most popular variants thatalready exist for the respective encoding scheme. Incase of the job sequence matrix, these will be the sub-sequence exchange crossover (SXX) [Kobayashi et al.,1995] and the job based order crossover (JOX) [Ono etal., 1996]. In [Bierwirth, 1995], Bierwirth suggests amodified order crossover (OX) operator, the General-isation of OX (GOX), for his permutation approach.We refer to the literature for further details on thecrossover operators mentioned above.

    5 Further Proceeding

    In Section 4 we have discussed the modelling and ar-chitectural aspects of our optimization system. How-ever, the implementation itself is still in the startingphase and a first running version is meant to be fin-ished within the next few months. Nevertheless wewill give a brief outline of the most important imple-mentational aspects in the following.

  • 7/27/2019 10.1.1.10.624

    6/6

    ,for several reasons. Firstly, C# is object-oriented andprovides features that are essential for the realisa-tion of our architecture. Secondly, C# shows goodperformance, even compared to C++. Finally, us-ing C# enables us to build upon an existing softwareframework for heuristic optimization algorithms. Thisframework, called HeuristicLab, is still under develop-ment and the current version already includes a broadspectrum of ready-to-use genetic algorithm variantsthat can easily be integrated into individual appli-cations. Thereby we have the advantage to be ableto use the most recent advanced GA concepts e.g.SASEGASA [Affenzeller and Wagner, 2003] which

    has been designed to avoid premature convergence bysophisticated selection pressure steering mechanismsand yields excellent results despite its generic andproblem independent nature.

    Due to the huge amount of input data caused bythe production system we intend to optimize, we areclearly aware of the high computational complexity ofthe associated optimization process. Therefore it is along-term target to extend our optimization tool withregard to parallel processing on multiple computationfacilities. The most obvious underlying parallel com-puting concept for this purpose is Grid Computing.In the context of our optimization system it would beconceivable that grid clients run e.g. on the companys

    office computers during the night when they are nor-mally idle. This is a quite realistic scenario and we areoptimistic that the companys organisational policieswill be in our favour in this matter.

    References

    [Affenzeller and Wagner, 2003] M. Affenzeller andS. Wagner. SASEGASA: An evolutionary algo-rithm for retarding premature convergence by self-adaptive selection pressure steering. In Computa-tional Methods in Neural Modeling, Lecture Notesof Computer Science 2686, pages 438445. SpringerVerlag, Berlin, 2003.

    [Barnes and Chambers, 1995] J.W. Barnes and J.B.Chambers. Solving the job shop scheduling prob-lem with tabu search. IIE Transactions, 27:257263, 1995.

    [Bierwirth, 1995] C. Bierwirth. A generalized permu-tation approach to job shop scheduling with geneticalgorithms. OR Spektrum, 17:8792, 1995.

    [Carlier and Pinson, 1989] J. Carlier and E. Pinson.An algorithm for solving the job-shop problem.Management Science, 35(2):164176, 1989.

    [French, 1982] S. French. An Introduction to theMathematics of the Job Shop. Chichester, Horwoodet al., 1982.

    [Garey and Johnson, 1979] M.R. Garey and D.J.Johnson. Computers and Intractability, a Guide tothe Theory of NP-Completeness. W. H. FreemanCompany, San Francisco, CA, 1979.

    [Giffler and Thompson, 1960] B. Giffler and J.L.Thompson. Algorithms for solving production

    . ,503, 1960.

    [Holland, 1975] J.H. Holland. Adaption in Naturaland Artificial Systems. University of MichiganPress, 1975.

    [Jain and Meeran, 1999] A.S. Jain and S. Meeran.Deterministic job-shop scheduling: Past, presentand future. European Journal of Operational Re-search, 113(2), 1999.

    [Kobayashi et al., 1995] S. Kobayashi, I. Ono, andM. Yamamura. An efficient genetic algorithm for

    job shop scheduling problems. In Proceedings of the6th ICGA, pages 506511, 1995.

    [Morton and Pentico, 1993] T.E. Morton and D.W.Pentico. Heuristic Scheduling Systems. John Wi-ley and Sons, 1993.

    [Ono et al., 1996] I. Ono, M. Yamamura, andS. Kobayashi. A genetic algorithm for job-shop scheduling problems using job-based ordercrossover. In Proceedings of 1996 ICEC, pages547552, 1996.

    [Panwalkar and Iskander, 1977] S.S. Panwalkar andW. Iskander. A survey of scheduling rules. Op-erations Research, 25(1):4561, 1977.

    [Vazquez and Whitley, 2000] M. Vazquez and L.D.

    Whitley. A comparison of genetic algorithms forthe dynamic job shop scheduling problem. In Pro-ceedings of GECCO-2000, pages 169178, 2000.

    [Yamada and Nakano, 1997] T. Yamada and RyoheiNakano. Genetic algorithms for job-shop schedul-ing problems. In Proceedings of Modern Heuristic

    for Decision Support, pages 6781, London, March1997. UNICOM seminar.