Time-Constrained Project Scheduling T.A. Guldemond ORTEC bv, PO Box 490, 2800 AL Gouda, The Netherlands
J.L. Hurink, J.J. Paulus, and J.M.J. Schutten University of Twente, PO Box 217, 7500 AE Enschede, The Netherlands,
[email protected]
We study the Time-Constrained Project Scheduling Problem (TCPSP), in which the scheduling of activities is subject to strict deadlines. To be able to meet these deadlines, it is possible to work in overtime or hire additional capacity in regular time or overtime. For this problem, we develop a two stage heuristic. The key of our approach lies in the first stage in which we construct partial schedules with a randomized sampling technique. In these partial schedules, jobs may be scheduled for a shorter duration than required. The second stage uses an ILP formulation of the problem to turn a partial schedule into a feasible schedule, and to perform a neighbourhood search. The developed heuristic is quite flexible and, therefore, suitable for practice. We present experimental results on modified RCPSP benchmark instances. The two stage heuristic solves many instances to optimality, and if we substantially decrease the deadline, the rise in cost is only small.
1. Introduction The problem addressed is a project scheduling problem with strict deadlines on the activities, which we call the Time-Constrained Project Scheduling Problem (TCPSP). In many project scheduling problems from practice, deadlines occur and in order to meet these deadlines, different ways to speed up the project are given, e.g., by working in overtime, hiring extra resource capacity, or even outsourcing (parts of) the project. All these options are costly but often not avoidable. Thus, the question arises how much, when, and what kind of extra capacity should be used to meet the deadlines against minimum cost. The TCPSP is a variant of the well studied RCPSP (Resource-Constrained Project Scheduling Problem). For an overview of the literature on the RCPSP see, e.g., Herroelen et al. (1998), Kolisch and Hartmann (1999), and Kolisch and Padman (2001). However, there are fundamental differences between the time-constrained and the resource-constrained variant. In the first, the deadlines cannot be exceeded and resource profiles may be changed, whereas in the second, the resource availability cannot be exceeded. Moreover, in the TCPSP, a non-regular objective function is considered. Therefore, most existing solution techniques of the RCPSP are not suitable for the TCPSP. Although the TCPSP occurs often in practice, it has been considered only rarely in the literature. Deckro and Herbert (1989) give an ILP formulation for the TCPSP and discuss the concept of project crashing. In project crashing, it is possible to decrease the processing time of an activity by using more resources, see also Kis (2005) and Li and Willis (1993). In practice, however, there are only limited possibilities to crash an activity and these possibilities can therefore be captured in the concept of multi-mode scheduling. Kolisch (1995) discusses a heuristic procedure for the TCPSP with limited hiring. None of the literature on TCPSP considers the concept of overtime. The TCPSP has, besides to the RCPSP, some relation to the time driven rough-cut capacity planning problem, see Gademann and Schutten (2005). The rough-cut capacity planning problem is about finding the appropriate capacity level on a tactical decision level, while the TCPSP is on an operational decision level. In this paper, we fill a gap in the literature on the TCPSP. To the best of our knowledge, for 1
Guldemond et al.: Time-Constrained Project Scheduling
2
the first time the concept of overtime and multiple forms of irregular capacity is included in the modelling of the TCPSP. The outline of the paper is as follows. Section 2 gives a detailed problem description and presents two ILP’s to model the TCPSP. The first model takes into account only hiring in regular time. The second model also deals with working and hiring in overtime. To solve the TCPSP, we develop in Section 3 a two stage heuristic. The first stage of the heuristic constructs a partial schedule. The key of the approach lies in this first stage, where jobs may be scheduled for a shorter duration than required. The second stage turns the partial schedule into a feasible schedule. The goal of this two stage approach is to spread the usage of irregular capacity evenly over the planning horizon. Section 4 concerns the computational results. The test instances used are RCPSP benchmark instances from the PSPlib, see Kolisch and Sprecher (1997b), that are modified into TCPSP instances. Section 5 concludes this paper.
2. Problem description and ILP formulations In this section, we describe the Time-Constrained Project Scheduling Problem (TCPSP) and formulate it as an integer linear program (ILP). First, we consider the TCPSP with hiring in regular time only, to get a thorough understanding of the problem. Second, we consider the TCPSP with working in overtime, and hiring in regular time and in overtime. Due to the complexity of the problem, we cannot expect to solve the TCPSP via this ILP-model. However, we present the ILP’s since the heuristic presented in Section 3 makes use of the ILP formulation to get a feasible solution and to perform a neighbourhood search. 2.1. TCPSP with hiring in regular time For the TCPSP, a set of n jobs, {J1 , ..., Jn }, each job Jj with a release date rj and a deadline dj , has to be scheduled without preemption on a time horizon [0, T ]. This time horizon is divided into T time buckets, t = 0, ..., T − 1, where time bucket t represents the time interval [t, t + 1]. (In the following, we will use T to refer to both the set of time buckets and the horizon [0, T ].) The release date rj gives the first time bucket in which job Jj is allowed to be processed and its processing has to be finished before dj , i.e., dj − 1 is the last time bucket where it is allowed to work on job Jj . For processing the jobs, a set of K resources, {R1 , ..., RK }, is available, where resource Rk has a capacity Qkt in time bucket t. To hire one extra unit of resource Rk in time bucket t, an amount cH kt has to be paid. The processing of the jobs is restricted by precedence relations, which are given by sets of jobs Pj , denoting all direct predecessors of job Jj . These precedence relations have non-negative time lags lij , indicating that the start of job Jj is at least lij time buckets later than the completion of job Ji . For each job Jj , a set Mj of different execution modes is given. Each mode m ∈ Mj has a specified processing time pjm and during the processing of job Jj in mode m it requires qjmk units of resource Rk . To model this variant of the TCPSP, we employ one type of binary decision variables xjmt that are equal to 1 if job Jj is being processed in time bucket t in mode m. To formulate the problem as an ILP, we use three types of variables that can be deduced from the variables xjmt . First, we use binary variables µjm that are equal to 1 if job Jj is processed in mode m. Second, we use binary variables sjmt that are equal to 1 if time bucket t is the first time bucket where job Jj is being processed and mode m is used to perform it. Finally, the nonnegative variables Hkt represent the amount of capacity hired of resource Rk in time bucket t. Now the TCPSP with hiring in regular time can be modelled by the following ILP: minimize:
−1 K T X X k=1 t=0
cH kt Hkt
(1)
Guldemond et al.: Time-Constrained Project Scheduling
3
subject to: X
µjm = 1
∀j
(2)
X
xjmt = pjm µjm
∀j, m ∈ Mj
(3)
∀k, t
(4)
∀j
(5)
∀j, m ∈ Mj ∀j, m ∈ Mj , t > 0
(6) (7)
∀j, Ji ∈ Pj
(8)
m∈Mj dj −1
t=rj n X X
qjmk xjmt ≤ Qkt + Hkt
j=1 m∈Mj dj −pjm
X
m∈Mj
X
sjmt = 1
t=rj
xj,m,0 = sj,m,0 xjmt ≤ xj,m,t−1 + sjmt di −pim X X X X pim µim + lij ≤ t · simt +
m∈Mi
t=ri
m∈Mi
sjmt = 0 xjmt = 0 µjm ∈ {0, 1} xjmt ∈ {0, 1} sjmt ∈ {0, 1} Hkt ≥ 0
m∈Mj
dj −pjm
X
t · sjmt
t=rj
t∈ / {rj , ..., dj − pjm } t∈ / {rj , ..., dj − 1} ∀j, m ∈ Mj ∀j, m ∈ Mj , t ∀j, m ∈ Mj , t ∀k, t
(9) (10) (11) (12) (13) (14)
The objective function (1) minimizes the total hiring costs. Due to constraint (2), exactly one mode is selected for each job. Constraint (3) ensures that each job is processed for the required duration between the release date and the deadline, and that the variables µjm and xjmt are consistent. Constraint (4) ensures that the amount of required resource does not exceed the amount of available resource, using regular capacity and hiring. Constraints (5), (6), and (7) guarantee the non-preemption requirement, and that the variables sjmt and xjmt are consistent. Each job Jj starts exactly once in one of its modes, and the processing of job Jj in time bucket t is only allowed if job Jj is being processed in time bucket t − 1 or it starts in time bucket t. The precedence relations with time lags are managed in constraint (8); the start time of job Ji plus its processing time and the time lag lij is less than or equal to the start time of job Jj , whenever job Ji is a predecessor of job Jj . Constraints (9) and (10) put all non-relevant sjmt and xjmt variables to zero. Finally, constraints (11) to (14) define the domain of the variables. 2.2. TCPSP with working in overtime, and hiring in regular time and in overtime In this section, we extend the model of the previous section, such that it can handle the TCPSP with working in overtime, and hiring in regular time and in overtime. This extension requires extra effort, due to the different usage of time buckets. A time bucket in overtime has different properties than a regular time bucket during a work day. Furthermore, we have to handle the following two requirements. As before, preemption is not allowed during regular time. However, it is allowed to work (without gaps) in some of the time buckets in overtime, then stop and continue the work in the next regular time bucket or in a subsequent block of overtime, if no regular time is in between these two blocks of overtime. The second requirement is on working in overtime. If personnel work in one time bucket in overtime, they have to work from the beginning of that overtime block until that time bucket. To cope with the modified non-preemption requirement, we take a different view on the time buckets. We define one chain of regular time buckets T 0 = {t01 , ..., t0N0 }, and L chains of time buckets that
Guldemond et al.: Time-Constrained Project Scheduling
4
are available for working in overtime T l = {tl1 , ..., tlNl }, l = 1, ..., L. For each chain of overtime time buckets T l , there is an index τ l ∈ {1, .., N0 } that indicates the last regular time bucket (t0τ l ∈ T 0 ) before the start of the chain T l . Furthermore, we assume that the chains do not overlap in time and that the overtime chain T l+1 is later in time than the overtime chain T l . If the first time bucket is not regular time but overtime, we P introduce an artificial regular time bucket to start L with. This way we have the time horizon [0, l=0 Nl ], and the corresponding set of time buckets l L T is the union of all chains, i.e., T = ∪l=0 T . As a consequence, each time bucket t ∈ T belongs to one unique chain T l , l ∈ {0, ..., L}. Due to the above mentioned constraints, the set of time buckets itself is also a chain, so we can compare each pair of time buckets, no matter whether these time buckets are in regular time or overtime. The modified non-preemption requirement can now be stated as follows. If a job is processed on two time buckets of a chain T l , it is also processed in all time buckets in between these two time buckets, and if a job is processed in two different overtime chains T k and T l , 1 ≤ k < l ≤ L, than this job has to be processed in all regular time buckets {t0τ k +1 , t0τ k +2 , ..., t0τ l } ⊂ T 0 . Note that it is possible that certain regular time buckets are followed by more than one chain of overtime time buckets. Consider the following example. For processing, we have 8 regular hours available on Friday and Monday, and 4 overtime hours on Friday evening, 8 on Saturday and again 4 on Monday evening. This means that T 0 = {F r1 , ..., F r8 , M o1 , ..., M o8 }, T 1 = {F r9 , ..., F r12 }, T 2 = {Sa1 , ..., Sa8 } and T 3 = {M o9 , ..., M o12 }. Furthermore, t0τ 1 = t0τ 2 = F r8 and t0τ 3 = M o8 . Figure 1 illustrates this example.
T 0 : F r1
F r8 M o1
M o8
T 1 : F r9 T 2 : Sa1
T 3 : M o9
F r12
M o12 Sa8
T : F r1 Figure 1
F r8 F r9
F r12 Sa1
Sa8 M o1
M o8 M o9
M o12
Chains of time buckets.
Within this new concept of time chains, using general time lags for the precedence relations leads to problems. They are not properly defined anymore, since it is not clear if the time lags only refer to regular time buckets or also to overtime time buckets. Consider the following example. If the time lag is a consequence of a lab test that has to be done between two processes, the opening hours of the lab determine to which time buckets the time lag applies. To overcome this problem, it is possible to introduce a dummy job and a dummy resource for each time lag. With the proper resource requirements for each dummy job, time lags can have any desired property with respect to regular and overtime time buckets. Therefore, for the problem considered in this subsection, we restrict ourselves to standard precedence relations, indicating that a job Jj can only start after the completion of job Ji , i.e., we assume that the corresponding lij values are all 0. We are now ready to model the problem with working in overtime, and hiring in regular time and in overtime. In addition to the parameters already used in the previous model, we have costs cO kt for one extra unit of resource Rk in time bucket t as working in overtime and hiring in and cHO kt
Guldemond et al.: Time-Constrained Project Scheduling
5
overtime, respectively. To model the different types of capacities, we introduce variables Okt and HOkt representing the amount of capacity made available through working in overtime and hiring in overtime respectively, for resource Rk in time bucket t. For ease of notation, we define pmax := maxm∈Mj pjm . j The TCPSP with working in overtime, and hiring in regular time and overtime can be modelled by the following ILP: K hX X
minimize:
k=1
cH kt Hkt +
t∈T 0
X
HO (cO kt Okt + ckt HOkt )
i
(15)
t∈T \T 0
subject to: X
µjm = 1
∀j
(16)
X
xjmt = pjm µjm
∀j, m ∈ Mj
(17)
qjmk xjmt ≤ Qkt + Hkt
∀k, t ∈ T 0
(18)
qjmk xjmt ≤ Okt + HOkt
∀k, t ∈ T \ T 0
(19)
Ok,tl ≤ Qk,t0
∀l ≥ 1, k
(20)
Ok,tl ≤ Ok,tl
∀l ≥ 1, h > 1, k
(21)
∀j
(22)
∀j, m ∈ Mj
(23)
∀j, m ∈ Mj , h ≥ 1
(24)
∀l ≥ 1, j, m ∈ Mj
(25)
∀h > 1, l ≥ 1, j, m ∈ Mj
(26)
∀t ∈ T, Jj , Ji ∈ Pj
(27)
∀t ∈ / {rj , ..., dj − pjm } ∀t ∈ / {rj , ..., dj − 1} ∀j, m ∈ Mj ∀j, m ∈ Mj , t ∈ T ∀j, m ∈ Mj , t ∈ T ∀k, t ∈ T 0 ∀k, t ∈ T \ T 0 ∀k, t ∈ T \ T 0
(28) (29) (30) (31) (32) (33) (34) (35)
m∈Mj dj −1
t=rj n X X
j=1 m∈Mj n X X
j=1 m∈Mj τl
1
h
h−1
dj −pjm
X
X
m∈Mj
xj,m,t0 ≤ xj,m,t0 h
sjmt = 1
t=rj
h−1
xj,m,t01 = sj,m,t01 X + sj,m,t0 + t∈∪{l|τ l =h−1}
pmax i
τl
1−
X
m∈Mj
Tl
X
xj,m,tl ≤ xj,m,t0 + sj,m,tl + 1
sj,m,t
h
1
sj,m,t
t∈{t|t
