An electronics factory produces an amplifier on an assembly line with four workstations. An amplifier is assembled in twelve operations between which there are certain precedence constraints. The following table indicates the duration of every task (in minutes) and the list of its immediate predecessors (the abbreviation PCB used in this table stands for ‘printed circuit board’).
The production manager would like to distribute the tasks among the four workstations, subject to the precedence constraints, in order to balance the line to obtain the shortest possible cycle time, that is, the total time required for assembling an amplifier. Every task needs to be assigned to a single workstation that has to process it without interruption. Every workstation deals with a single operation at a time. We talk about cycle time because the operations on every workstation will be repeated for every amplifier. When an amplifier is finished, the amplifiers at stations 1 to 3 advance by one station, and the assembly of a new amplifier is started at the first workstation.
Table 7.8:List of tasks and predecessors
Task Description Duration Predecessors
1 Preparing the box 3 –
2 PCB with power module 6 1
3 PCB with pre-amplifier 7 1
4 Filter of the amplifier 6 2
5 Push-pull circuit 4 2
6 Connecting the PCBs 8 2,3
7 Integrated circuit of the pre-amplifier 9 3 8 Adjusting the connections 11 6 9 Heat sink of the push-pull 2 4,5,8
10 Protective grid 13 8,11
11 Electrostatic protection 4 7
12 Putting on the cover 3 9,10
7.6.1
Model formulation
Let TASKS be the set of tasks, DURi the duration of task i, MACH the set of workstations (numbered in the order of the production flow). The precedence relations can be represented as a directed graph
G = (TASKS, ARCS), where ARCS denotes the set of arcs. An arc (i, j) from task i to j symbolizes that i is the
immediate predecessor of j.
To assign the tasks, we define binary variables processim with processim = 1 if and only if task i is as- signed to workstation m. The constraints (7.6.1) are required to assure that every task goes to a single workstation.
∀i ∈ TASKS : X m∈MACH
processim= 1 (7.6.1)
An assignment is valid only if it fulfills the precedence constraints, which means that for every arc (i, j) the workstation processing i must have a number that is smaller or equal to the workstation number for
7 5 3 8 11 11 10 13 9 12 4 6 8 6 1 3 2 6 2 3 4 9 7 4
Figure 7.8:Graph of tasks with durations
j. This relation is established with the constraints (7.6.2). Note how the numbers of the workstations for
i and j are calculated with sums of the assignment variables: due to constraints (7.6.1) only the index m for which processim= 1 will be counted.
∀(i, j) ∈ ARCS : X m∈MACH k · processim≤ X m∈MACH k · processjm (7.6.2)
We now introduce a real variable cycle ≥ 0 that represents the cycle time. The constraints (7.6.3) indicate that this variable is an upper bound on the workload assigned to every workstation.
∀m ∈ MACH : X i∈TASKS
DURi· processim≤ cycle (7.6.3)
We thus obtain the following mathematical model, where all variables with the exception of cycle are binaries. The objective function (7.6.4) consists of minimizing cycle.
minimize cycle (7.6.4) ∀i ∈ TASKS : X m∈MACH processim= 1 (7.6.5) ∀(i, j) ∈ ARCS : X m∈MACH k · processim≤ X m∈MACH k · processjm (7.6.6) ∀m ∈ MACH : X i∈TASKS
DURi· processim≤ cycle (7.6.7)
∀i ∈ TASKS, m ∈ MACH : processim∈ {0, 1} (7.6.8)
cycle ≥ 0 (7.6.9)
In this problem formulation, we assume the the production line already exists with its NM workstations and that we wish to balance the workload. For (re-)designing production lines, it would possible to work with a given market demand (number of amplifiers per day) and a given cycle time to minimize the number of workstations that form the new production line. To be able to generate solutions for this problem, the maximum duration of tasks obviously must not exceed the given cycle time.
To solve this new version of the problem, we may take the preceding model, delete the objective function and replace the variable cycle by a constant (the desired cycle time). We then try to solve the system (7.6.5) to (7.6.9), initializing the number of machines NM with some lower bound, such as the total duration of all tasks divided by the cycle time and rounding the resulting value to the next larger integer. If this system has no solution, we increment the value of NM and restart the solution algorithm. This process converges since a trivial solution exists with one task per workstation.
7.6.2
Implementation
The following Mosel program implements the mathematical model defined by lines (7.6.4) – (7.6.9) in the previous section. It poses a frequently recurring problem, namely the encoding of the graph G. One
possibility consists of defining a binary matrix B (called an adjacency matrix), with Bij = 1 if and only if the arc (i, j) is in G. The second method that is used here lists only the existing arcs and therefore has a lower memory consumption for sparse graphs like G: the graph is represented by a table ARC with a line per arc and two columns. The arc represented by the line a has the source ARCa1and the sink ARCa2. The first data line contains the number 1 and 2 for the arc (1,2), the second 1 and 3 for (1,3) and so on. Since we initialize the arc numbers dynamically with the data read from file (the range of arc numbers RA is not fixed in the program), the index-tuples for the entries of the array ARC need to be given in the data fileb6linebal.dat.
model "B-6 Assembly line balancing" uses "mmxprs"
declarations
MACH=1..4 ! Set of workstations
TASKS=1..12 ! Set of tasks
DUR: array(TASKS) of integer ! Durations of tasks
ARC: array(RA:range, 1..2) of integer ! Precedence relations between tasks process: array(TASKS,MACH) of mpvar ! 1 if task on machine, 0 otherwise cycle: mpvar ! Duration of a production cycle end-declarations
initializations from ’b6linebal.dat’ DUR ARC
end-initializations ! One workstation per task
forall(i in TASKS) sum(m in MACH) process(i,m) = 1 ! Sequence of tasks
forall(a in RA) sum(m in MACH) m*process(ARC(a,1),m) <= sum(m in MACH) m*process(ARC(a,2),m) ! Cycle time
forall(m in MACH) sum(i in TASKS) DUR(i)*process(i,m) <= cycle forall(i in TASKS, m in MACH) process(i,m) is_binary
! Minimize the duration of a production cycle minimize(cycle)
end-model
7.6.3
Results
The mixed integer solver finds a minimum cycle time of 20 minutes. The assignment of tasks to worksta- tions and the resulting workload per workstation are given in the following table. It is easy to verify that the precedence constraints hold.
Table 7.9:Assignment with minimum cycle time
Workstation number 1 2 3 4
Assigned tasks 1,2,4,5 3,7,11 6,8 9,10,12
Workload 19 20 19 18
7.7
References and further material
With the exception of the stadium construction all problems in this chapter are very difficult combinato- rial problems, so-called NP-hard problems (the exact definition of this notion is given in [GJ79]). There is a large variety of scheduling. The works of Carlier and Chretienne [CC88], Lopez and Roubellat [LR99], Błazewicz et al. [BESW93], and French [Fre82] are good entry points for this very active domain.
The stadium construction problem (Section7.1) is a project scheduling problem that is now easily solved and for which a number of software tools are available, such as Project by Microsoft and PSN by Scitor- Le Bihan. To answer question 1, there are simple solution methods based on graphs. The graph of a project may be coded in two different ways. The first consists of representing tasks by arcs and the nodes
correspond to the stages of the project. This graph, called AOA (activities on arcs) is used by the PERT method [Eva64]. In the representation that we have used the nodes correspond to the tasks, this is the AON (activities on nodes) encoding that is used by the Method of Potentials [Pri94a] [GM90].
Historically, the PERT method stems from the USA and the Method of Potentials from France. Besides the encoding of the graph, the two methods are largely equivalent, to the point that certain software provides both methods. Nevertheless, the AOA representation becomes quite impractical outside the context of project scheduling, for instance for workshop planning. In this case, the AON notation is used systematically.
The question 2 concerns the PERT-cost problem, or scheduling with project crashing, in which the ob- jective is to minimize the total cost if the tasks have flexible durations and the costs depend on these durations. Depending on the assumptions, several model formulations are possible: for example, an ad- ditional cost that is proportional to the number of days saved per task, or a cost inversely proportional to the duration of a task. The reader may find other practical cases in Wasil [WA88].
The flow shop problem (Section7.2) is a classical scheduling problem. The mathematical formulation we have used is due to Wagner [Wag59]. Other solution methods are described by French [Fre82], pages 132-135, and Pinedo [Pin95a], pages 99-101. Curiously, these works forget to mention the constraints (7.2.6) – (7.2.7) that are absolutely necessary for obtaining correct results.
The flow-shop problem is NP-hard in the general case, and Mathematical Programming only allows solv- ing problems limited to about thirty operations. For large cases, simple heuristics like NEH (from the name of the authors Nawaz, Enscore and Ham [NEH83]) or metaheuristics like tabu search [WH89] are used. The two-machine case is easy and may be solved by an algorithm by Johnson that is described in the two books just quoted.
The problem in Section7.3is a classical scheduling problem called job shop. This problem is NP-hard in the general case. Modeling as a MIP is often inefficient for large problems. Nevertheless, the generic model formulation given here is used by Applegate and Cook with cutting plane techniques [AC91] where the authors obtain interesting results for difficult instances. But the problem is usually solved by list- based heuristics or with exact methods based on a formulation with disjunctive graphs [CCE+93], [Fre82], [Pin95b]. Note that the generic model formulation is also valid for the general flow shop problem (whilst the model of Section7.2only applies to the permutation flow shop).
Different solution algorithms are available for one-machine problems (Section7.4). The aim of this ex- ercise was to give a common model formulation for the three objectives. Other models using variables relative to the position of jobs may be found in [LQ92] [Sev98].
The paint production problem (Section7.5) is a representative of a family of scheduling problems where the preparation before every task depends on the chosen order (sequence-dependent setup times). We have in fact used one of the models for the famous traveling salesman problem (TSP). In this problem, the jobs (batches) become cities and the cleaning times the cost of traveling from one city to the next. The objective is to find the minimum cost for the journey of a sales representative that starts from his home in city 1, visits every city once, and finally returns to his starting point.
Here we have considered the asymmetric case, that is, the cleaning time between batch i and batch j is in general different from the one between j and i. In Chapter11, we study a symmetric TSP, with distances between cities as the crow flies. It is solved with a different technique, by progressively adding constraints of type (5). Since the TSP is NP-hard, the models presented often take too long to be solved for more than twenty cities. Beyond this limit, specialized tree search methods [HK70] need to be used. Demonstration versions of such methods are available [Ros85] [EM92], and a Pascal code is given by Syslo [SDK83]. For cases with hundreds of cities one needs to give up on optimality and use heuristic techniques, some of which like tabu search (e.g. [GTdW93]) or simulated annealing ([KGV83]) are in practice quite efficient. Such heuristics are explained with some detail in [Pri94a].
The problem of assembly line balancing (Section7.6) is NP-hard for the two given versions (minimizing the cycle time or the number of workstations). Without precedence constraints, the first version is equivalent to a scheduling problem with parallel machines (see the wagon loading problem in Chapter9) whilst the second is reduced to a bin-packing problem (the problem of saving files to disks in Chapter9). Problems of about twenty tasks can be dealt with in Mathematical Programming, beyond this limit heuristics may be used like the one by Dar-El [DE73], described together with another heuristic in the book on production planning by Buffa and Sarin, pages 660-671 [BS87]. Scholl has recently published a book dedicated to assembly line balancing problems [Sch99].
Chapter 8
Planning problems
The term planning is often used with three different meanings in the context of production management: long-term planning that is used for taking strategic decisions, mid-term planning that corresponds to the tactical level, and short-term planning for operational decisions. Long-term planning concerns the direction a company is taking over several years, like the depot location problem in Chapter10. Short- term planning takes detailed production decisions for the shop floor, with a time horizon of a few days. Most importantly it comprises scheduling problems such as those described in Chapter7. The present chapter is dedicated to tactical planning, currently referred to as production planning.
This decision level often covers a time horizon of one or several months, working for instance with time slices of the length of a week. It takes a macroscopic view of the production system: the detailed con- straints for workshops and machines are ignored, the operations are dealt with in an aggregated fashion. The objective is to determine the best quantities to produce in every time period whilst, in a majority of cases, minimizing the cost incurred through production and storage.
Section8.1presents a simple case of single product planning, namely bicycles. The following section (8.2) deals with the production of several products (different types of glasses). In Section8.3we plan the production of toy lorries with all their components. This is a typical case of Material Requirement Planning (MRP). The two following problems have more complex cost functions: the production of electronic components in Section8.4includes costs for changing the level of production, and for the production of fiberglass in Section8.5the cost depends on the time period. The problem of Section8.6stands apart: it concerns the assignment of product batches to machines of different capacities and speeds.
8.1
Planning the production of bicycles
A company produces bicycles for children. The sales forecast in thousand of units for the coming year are given in the following table. The company has a capacity of 30,000 bicycles per month. It is possible to augment the production by up to 50% through overtime working, but this increases the production cost for a bicycle from the usualBC32 to BC40.
Table 8.1:Sales forecasts for the coming year in thousand units Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
30 15 15 25 33 40 45 45 26 14 25 30
Currently there are 2,000 bicycles in stock. The storage costs have been calculated asBC5 per unit held in stock at the end of a month. We assume that the storage capacity at the company is virtually unlimited (in practice this means that the real capacity, that is quite obviously limited, does not impose any limits in our case). We are at the first of January. Which quantities need to be produced and stored in the course of the next twelve months in order to satisfy the forecast demand and minimize the total cost?
8.1.1
Model formulation
The variables that we need to determine are the numbers of bicycles pnormtand povertto be produced respectively in normal working hours and in overtime hours during month t, and the number of bicycles
storet held in stock at the end of the month. Let MONTHS = {1, . . . , 12} be the set of time periods. The objective is to minimize the total cost, that is, the sum of cost of production (in normal and additional hours) and the storage cost. We write CNORM and COVER for the production cost of a bicycle in normal
and overtime hours, and CSTOCK the monthly storage cost per bicycle. With these conventions we obtain the objective function (8.1.1).
minimize X t∈MONTHS
(CNORM · pnormt+ COVER · povert+ CSTOCK · storet) (8.1.1)
In every month t, the available quantity of bicycles is given as the sum of bicycles in stock at the end of month t − 1 and the bicycles produced in normal and overtime hours during this month. This sum must equal the number of bicycles sold in the course of month t, plus the number of bicycles held in stock at the end of month t. This key relation is called the inventory balance equation, and forms an important component of mathematical models for production planning problems.
Let us call the initial stock level ISTOCK and DEMt the forecasted demand for month t. The balance constraint for the first month is then given by relation (8.1.2)
pnorm1+ pover1+ ISTOCK = DEM1+ store1 (8.1.2)
The constraints (8.1.3) establish this relation for all following months.
∀t ∈ MONTHS, t 6= 1 : pnormt+ povert+ storet−1= DEMt+ storet (8.1.3)
The production capacity in normal working hours is limited by the given capacity CAP, and the additional production in overtime hours is limited to 50% of this capacity; hence the constraints (8.1.4) and (8.1.5).
∀t ∈ MONTHS : pnormt ≤ CAP (8.1.4)
∀t ∈ MONTHS : povert ≤0. 5 ∗ CAP (8.1.5)
And finally, we note that all variables are non-negative (constraints (8.1.6)).
∀t ∈ MONTHS : pnormt ≥0, povert≥0, storet≥0 (8.1.6)
8.1.2
Implementation
The mathematical model may be translated into the following Mosel program.
model "C-1 Bicycle production" uses "mmxprs"
declarations
TIMES = 1..12 ! Range of time periods DEM: array(TIMES) of integer ! Demand per months
CNORM,COVER: integer ! Prod. cost in normal / overtime hours CSTOCK: integer ! Storage cost per bicycle
CAP: integer ! Monthly capacity in normal working hours ISTOCK: integer ! Initial stock
pnorm:array(TIMES) of mpvar ! No. of bicycles produced in normal hours pover:array(TIMES) of mpvar ! No. of bicycles produced in overtime hours store:array(TIMES) of mpvar ! No. of bicycles stored per month
end-declarations
initializations from ’c1bike.dat’ DEM CNORM COVER CSTOCK CAP ISTOCK end-initializations
! Objective: minimize production cost
Cost:= sum(t in TIMES) (CNORM*pnorm(t) + COVER*pover(t) + CSTOCK*store(t)) ! Satisfy the demand for every period
forall(t in TIMES)
pnorm(t) + pover(t) + if(t>1, store(t-1), ISTOCK) = DEM(t) + store(t) ! Capacity limits on normal and overtime working hours per month
forall(t in TIMES) do pnorm(t) <= CAP pover(t) <= 0.5*CAP end-do
! Solve the problem minimize(Cost) end-model
In this implementation we use the inlineiffunction to condense the balance constraints for the first and all following periods into a single constraint. For t = 1 the expression evaluates to
pnorm(1) + pover(1) + ISTOCK = DEM(1) + store(1)
while for the rest of the periods we have
pnorm(t) + pover(t) + store(t-1) = DEM(t) + store(t)
8.1.3
Results
The minimum cost for production and storage isBC11,247,000. The following table list the production plan for the coming year (in thousands) — its first line recalls the forecast monthly demand. In January to April and September to December the demands can be satisfied with production in normal hours. In April, 3000 bicycles need to be stored to satisfy the higher demand in May. In June to August overtime work is required to produce the required quantities.
Table 8.2:Quantities to produce and store in thousand units
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Demand 30 15 15 25 33 40 45 45 26 14 25 30
Normal 28 15 15 28 30 30 30 30 26 14 25 30
Additional – – – – – 10 15 15 – – – –
Store – – – 3 – – – – – – – –
Note that in practice one might not like a solution like this: the inventory at the month end is almost always 0, so if there were a surge in demand (e.g. unusually good weather) the company would be in