Property 1. If i precedes j in “father” and “mother” individuals, then i precedes j in children created by the crossover
6.1. Introduction
6.2.5. Operation placement procedure
As we have often mentioned, schedule quality obtained with the previous procedure largely depends on the sequence in which the jobs are placed. As much as this procedure can be justified in the case of flow shops, it can become penalizing in
job shops or open shops. In fact, it runs the risk of very quickly deteriorating schedule quality for jobs which are not first in the classification.
A more generic operation placement procedure consists of no longer placing all operations corresponding to a given job before placing the operations of the following job. This procedure consists of placing operations in a certain sequence one at a time. In order to do this:
– we classify all operations corresponding to jobs to be executed in a certain order. This order or sequence takes into account certain characteristics of these operations (place in the production route criticality of the machine involved, duration, margin, etc.);
– we take the first operation in the list;
– we place the corresponding operation on the machine on which it must be executed by taking production route constraints into consideration. This placement is definitive and will not be questioned any longer in the rest of the scheduling process;
– we then place the next operation in the list and so on until it is finished.
This procedure can be considered as representing a group of progressive resolution methods for scheduling problems. In fact, as its previous description indicates, it does not explain how operations are classified: is this classification carried out once for all operations at the beginning of the resolution (and in this case, how is it done?) or is it questioned after each operation placement?
This method belongs to the class of so-called “greedy” methods within which we never challenge decisions made at any of the previous steps in the resolution. There is no backtracking in the arborescent resolution. Heuristics must then be chosen to make the best possible local decisions without being sure that they will lead to the optimal solution.
The simulation approach presented in the third part belongs to this class of methods and will implicitly use a systematic operation classification procedure taking increasing achievement dates into consideration.
6.3. Simulation approach 6.3.1. Discrete event models Introduction
First, we will quickly present the modeling context and method of execution for discrete event simulations (for a more detailed presentation, see [CER 88] or [LAW 06]), and in the next section we will show how it can be used to solve the scheduling problem.
In this section, we are attempting to model the dynamic behavior of a production system, or more specifically, job flow circulation in this system. To illustrate the concepts and formalisms used, we will use the very simple example of a machine M with stock Swaiting for execution. This machine receives jobs i on which it must execute operations (each job has only one operation on machine M) lasting a certain amount of time. Once the operation is completed, the job leaves the system.
Objects and attributes
In this type of model, we consider that the model is made up of objects (real or fictitious). In the previous example, objects are: machine M, stock S and jobs i. Each object is characterized by a set of attributes (small database connected to each object). Some of the attributes of these objects are fixed. These represent the characteristics of the object involved or relations with other objects. In this example, the fixed object attributes are:
– machine: name;
– stock: name, possibly stock capacity;
– job: name,execution time on machine M.
Other attributes are variable and evolve over time. In our example, variable attributes are:
– machine: state of occupation valued at 0 if the machine is idle and 1 if the machine is busy;
– stock: list of pending jobs;
– job: position in the system (“out of the system”, “in stock S”, “on machine M”).
States and events
The state of an object at a given moment is characterized by the value of all its attributes (fixed and variable). The state of the system is characterized by the state of all objects that it contains. This model is based on the notion of state. The characteristic of discrete event models comes from the fact that we are placed at such a modeling granularity that:
– the state of each component can only take discrete values. That is the case here because:
- the state of occupation of machines can only take value 0 (idle machine) or 1 (busy machine),
- the state of stock corresponds to different compositions of the list of present jobs,
- the position of jobs can only have three values (“out of the system”, “in stock”, or “on machine”);
– in correlation, state changes can only happen at specific moments in time that we call “events”.
In the example, there are three types of events:
–arrival of a job in the system. This is the moment when the job arrives from outside;
–start of operation for a job on the machine. This is the moment where the job arrives on the machine for execution;
–end of operation for a job on the machine. This is the moment when the job leaves the machine (operation completed) and exits the system.
These events correspond to the start and end of job operations on machines.
State change logic
To describe the dynamic behavior of the system, “state change logic” must be explained. State change logic describes the way in which state changes are made for the different objects involved in the occurrence of a given type of event. There is no imposed formalism to describe this state change logic. It can be described by any organization chart for representing what must be carried out during the event’s occurrence.
In this state change logic, we describe:
– the different state changes which happen during the occurrence of the event;
– projected event dates for which the future occurrence is triggered by the present event’s occurrence (generation of events). For example, during a “start of operation” event, we can forecast the “end of operation” event date taking into account the execution time value.
Modeling helps us consider the fact that the way in which state changes and event generation happen can depend on the state of the system during the occurrence of the event. We can then describe more complex state change logic. In the simple example used as presentation support, we can describe state changes associated with the three types of events:
1. Arrival of job i event
The change of state depends on the state of the machine at the moment where this event arrives:
– if the machine is free then:
- there is projection of the occurrence of a start of operation event at the current date (if the job’s transfer time is negligible);
– if the machine is busy then:
- job position becomes: “in stock”;
- the list of jobs in stock is incremented.
2. Start of operation of job i event Jobposition is “on machine”.
The machine goes into “busy” state.
There is projection of the occurrence of an end of operation event for job i at a date equal to the current date increased by execution time pi of job i.
3. End of operation of job i event
Jobi exits the system: job position is “out of the system”.
If stock is empty then machine goes into “idle” state.
Otherwise, if the job listin stock is not empty then:
– the next job to be executed must be chosen in the job list;
– the name of this job must be taken out of the job list;
– the position of this job becomes: “on machine”;
– there is projection of the occurrence of a start of operation event for the job at the current date (if the job’s transfer time on the machine is negligible).
Priority rules
Choosing the next job in stock is a decision which will define the sequence in which the different jobs in stock will be processed. This decision must be made each time the machine becomes available and consists of only making a choice from jobs present in stock at that moment.
To make this decision, we can use a priority rule by allocating what we call a
“priority index” to each job. The higher the index value, the higher the priority for this job and the quicker it will be processed. The fourth part of this chapter presents a classification of the most common priority rules.