Expert Systems with Applications 37 (2010) 2963–2973

Contents lists available at ScienceDirect

Expert Systems with Applications

journal homepage: www.elsevier.com/locate/eswa

Scheduling of maintenance work: A constraint-based approach

J. Palma a, F.C. Gómez de León Hijes a, M. Campos Martínez b,*, L. Guillén Cárceles a
a
Information and Communication Engineering Department, University of Murcia, Computer Science Faculty, Espinardo 30100, Murcia, Spain
b
Informatics and Systems Department, University of Murcia, Computer Science Faculty, Espinardo 30100, Murcia, Spain

a r t i c l e i n f o a b s t r a c t

Keywords: The growing demand for IT tools for maintenance management in the workplace has led to the develop-
Intelligent systems ment of a wide range of software, both of a general nature and designed for specific purposes. The need
Planning for such tools becomes more evident as the number of machines and installations grows, since their
Programming maintenance, particularly preventative maintenance, must be planned and scheduled.
Industrial maintenance
Planning a maintenance schedule implies knowing the tasks to be carried out, their periodicity and all
Work order
the details necessary for these tasks to be accomplished. Then, bearing in mind the daily (or weekly) work
orders, it will be necessary to program the exact order in which the various maintenance tasks must be
carried out. This will involve coordinating a large number of temporal constraints, which can only be
described as a ‘‘headache” for maintenance engineers.
Within the framework of Knowledge Engineering, we present an application based on Constraints Sat-
isfaction Problems (CSP) techniques, such as Forward checking, whereby, from a set of initial proposals,
constraints are propagated until increasing better solutions are incrementally found.
In this case, the G2 tool from Gensym was successfully applied to planning the weekly maintenance
tasks of a municipal service charged with distributing and controlling drinking water supplies to a city,
the main characteristic being the wide geographical dispersion of the installations and the limited per-
sonal and operative resources available.
Ó 2009 Elsevier Ltd. All rights reserved.

1. The role of planning in maintenance
Planning maintenance involves organising a set of activities, of
greater or lesser complexity, in an attempt to ensure the maximum
possible operational availability of equipment. That is, to eliminate
(or minimise, at least) unforeseen faults and stoppages and to
make any unavoidable stoppages necessary for the servicing and
repair of machinery as brief as possible, minimising any impact
on production.
This need to plan maintenance tasks and, especially, plant stop-
pages, takes on particular importance when it comes to preventa-
tive strategies, which involve periodic revision of the equipment
and installations or the replacement of worn parts. From the sim-
plest routine inspection to complete plant stoppages must be
planned, that is, all the tasks to be carried out must be included
in a protocol of maintenance that facilitates the work and minimis-
es the time employed. It must not be forgotten that in some pro-
duction processes, such as the case of electricity generation in a
nuclear power station, every day’s outage may represent a loss of
millions of dollars.
* Corresponding author. Tel.: +34 968 398521; fax: +34 968 364151.
E-mail address: manuelcampos@um.es (M. Campos Martínez).
More specifically, planning the maintenance of an industrial
plant must take into consideration the following questions, among
others (Gómez de León & Ruiz Cartagena, 2006): the type of main-
tenance necessary for each part of equipment, the extent of any
intervention, the specific action protocols, a generic calendar for
each activity, staff involved, means and necessary infrastructure,
the management of work orders, procedures for control and evalu-
ation of the maintenance carried out, servicing procedures, altera-
tions to established plan, etc.
Once the specific needs of a plant are known, its will be neces-
sary to establish a work plan that spreads the tasks to be carried
out over a convenient time scale – a given day or week – that is,
the resources available must be assigned to a certain task or set
of tasks, each one of which will comprise a temporal sequence of
activities.
Traditionally, it has been the head of maintenance who has had
to apply all his skills and experience in finding the most suitable
solution to each case, that is, to find the balance between all the
criteria in play, with particular regard to safety, technical and eco-
nomic considerations. However, as the number of variables and
complexity of the task increase, the risk of straying from the most
suitable solution grows and the cost of maintenance rises.
It is because of this that maintenance management programs,
especially those that offer help in planning tasks, have been found

0957-4174/$ - see front matter Ó 2009 Elsevier Ltd. All rights reserved.
doi:10.1016/j.eswa.2009.09.038
2964 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
to be so useful. Such systems should be capable of managing the
information available, the criteria of the company concerned when
distributing resources and the time conditioners set out, offering
consistent multi-objective solutions that are technically viable
and economically sound. We are dealing, then, with a problem of
planning and scheduling in which the conditions are continually
changing, sometimes without warning. For example, operators
usually take their holidays on a weekly or monthly basis, while
on other occasions changes may take place randomly or with only
a few hours’ notice.
The IT tools commercially available for maintenance manage-
ment are very effective for planning a large number of tasks for
many machines according to a pre-established timetable, possibly
with a few straightforward limitations or conditions. However,
they are not so effective when there are many time-related con-
straints or when these occur randomly and continuously.
Applying certain simple rules when tasks are scheduled may in
practice be inefficient. For example, let’s take the obvious case that
‘‘an operator cannot do two tasks simultaneously”, which may be
translated into ‘‘if an operator has been assigned a task, then, as
long as this task is not finished, do not assign him another task”.
This apparently simple rule may give rise to conflictive situations
in real time since the ‘‘as long as this task is not finished” introduces
a temporal uncertainty factor (Cárdenas, Marín, & Navarrete, 2001)
which cannot be resolved a priori.
The normal solution in such cases is to make an estimate based
on mean intervention or repair time, the so-called MTTR (Mean
Time To Repair), if this is known. However since the value of MTTR
is in reality a function of the distribution of probability (Gómez de
León, 1998), foreseen times might be very different from the time
actually taken, throwing into disarray all planning. Obviously,
when the daily work order is issued, the mentioned rule of our
example is easy to follow in the case of the first tasks, but the
inherent randomness of their duration increases the uncertainty
as far as subsequent tasks are concerned, leading to a very ineffi-
cient use of the time.
Even if every task of a maintenance schedule that needs to be
carried out, its periodicity and precise nature of the same may be
known beforehand, scheduling the sequence in which the tasks
should be carried out while taking into account a set of work or-
ders means in many cases coordinating a large number of changing
factors, such as: the work hours of the plant, or more specifically,
the working ours of the machines that are used in each work order;
the number of operators available at any moment; if those who are
available are qualified to carry out the work; the working hours
and the shifts, not to mention the workers’ contracts and the work
conditions laid down by unions; the availability of material re-
sources, basically the tools required for each job and the availabil-
ity of spare parts; when necessary, suitable transport to transport
the personnel or the machinery itself; the geographical layout of
the plant or the dispersal of machines throughout the same – these
to name but few of the factors that have to be taken into account.
Indeed, the set of temporal constraints imposed (Marín & Navarr-
ete, 2003) makes the daily or weekly scheduling of maintenance
tasks a puzzle difficult to resolve.
Unlike planning, scheduling is exposed to numerous constraints
that are the consequence of frequent and random variation in the
resources available. Besides planning repetitive tasks, marked by
periodical intervals or based on the state of a given parameter with
a functional meaning, scheduling must also take into account tasks
of a less foreseeable nature. The tasks that arise daily in mainte-
nance may on occasions rapidly accumulate, throwing into turmoil
all programming. To the list of scheduled jobs others that arise
unforeseen must be added. These are the consequence of condi-
tions unconnected with the initial planning and usually caused
by random events: sickness, weather conditions, breakdown of
the supply chain, etc.
The number of possible combinations of all the tasks to be car-
ried out, together with the variability of each of the factors men-
tioned, makes it impossible to make a prior analysis of the whole
range of possibilities and putative solutions since these grow expo-
nentially with the number of variables. If we consider each of the
factors involved in the problem as constraints, the problem may
be approached as a search for a space of solutions that must satisfy
a set of constraints, which is frequent problem in the field of Arti-
ficial Intelligence.
We are looking at a dynamic problem, then, in which a given
solution is only valid for a given time, a time which lasts only until
the following change in one of the intervening factors, when new
solutions to the new set of constraints must be found.
When the set of factors affecting the problem is reduced and
can be considered static, planning can be made by algorithms of
linear programming (Alardhi & Labib, 2008), since computational
complexity is low. However, when the work orders are many and
complex, the resources limited and the conditions subject to con-
tinuous change, such algorithms lead to an combinatorial explo-
sion that makes it impossible to generate solutions at the same
rate as the problem is changing. In such cases, we can only turn
to heuristic methods, such as genetic algorithms (García et al.,
2003), in which, following a set of logic directives, the system gen-
erates a restricted set of solutions following a reasoning deter-
mined by the time permitted. Other Production Systems have
also been used involving different reasoning methods, such as
backward-chaining (Lee & Kwon, 1995) or fuzzy reasoning (Pereira,
Sanchez, & Rives, 1999).
In this work we approach the design of maintenance plans from
the methodological perspective of de Knowledge Base Systems
(KBS) based on Knowledge Engineering (KE). The problems that
have arisen with the industrialisation of the KBS design process
in the 1980s were gradually resolved in the 1990s with the appear-
ance of methods that cover the whole development process, based
on the idea of modelling knowledge independently of its imple-
mentation. Special mention should be made of approaches like VI-
TAL (Domingue, Motta, & Watt, 1993), MIKE (Angele, Fensel, Lanes,
& Studer, 1998) and CommonKADS (Schreiber et al., 2000) which
have provided a solid framework for development. CommonKADS
particularly has become the de facto standard for developing this
kind of system, besides covering the whole life cycle of KBS devel-
opment. One of the most important aspects of this methodology is
the emphasis that it places on the re-use of knowledge models
when tackling the development of new systems, this being one
of the corner stones in the field of ontological engineering. To facil-
itate the re-use of knowledge models, most methods depend on
the concept of the Problem Solving Method (PSM), which is a high
level structure that indicates how to resolve a given generic task.
One of the main advantages of using PSM is that it provides a set
of knowledge inferences and elements regardless of the specific
knowledge of the domain, organised as extremely re-usable ele-
ments. We have opted to use CommonKADS since it is the most
complete methodology, although we only partially show the re-
sults of its application, focusing on the el knowledge model,the pur-
pose of which is to describe in detail the types and structures of the
knowledge used to perform the task.
Taking into consideration the problem described above and, as
we shall see in the following sections, as we are dealing with a
scheduling problem together with a problem regarding the alloca-
tion of resources (Liu, 1993), which takes into consideration user
preferences, we opt to tackle both aspects simultaneously as a con-
straint satisfaction problem (CSP) (Tsang, 1993), using the forward-
checking technique to verify the solutions.
 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973 2965

In the rest of the article, we shall observe the following struc-

ture: In Section 2 we describe the problem to be treated. In Section
3 we model the problem according to the methodology used and
the constraint and preference processing method. In Section 4 we
describe the application of the model to proposed dominion. Final-
ly, we offer some conclusions and discuss possible future lines of
research.

2. Description of the problem

A specific case of such a situation is provided by a municipal

service whose responsibility is the distribution and supply of
drinking water to a population, whose hydraulic systems are
mainly composed of reservoirs, water pumping stations and a net-
work of pipes.
The main characteristic of such a company is the social and le-
gal repercussions of any breakdown in the supply of water. It is
therefore desirable that the level of maintenance be such that no
interruptions in the supply occur, meaning that planning and pro-
gramming of the tasks to be carried out take on even greater
importance in order to ensure the prompt response to any demand
for maintenance.
Other aspects of this kind of utility company are: the great dis-
tances between the individual installations, the operational inde-
pendence of some of these, the corrosive conditions in which the
equipment has to work, the necessarily strict control of the chlori-
nation equipment and of the product (drinking water). The geo-
graphical location of the installations of the municipality chosen
as study case (Molina de Segura, SE Spain) are shown in Fig. 1,
which only depicts the reservoirs and pumping stations but not,
for obvious reasons, the hundreds of kilometres of tubes and sec-
ondary level (or lower) installations and pipes (in this case running
to thousands of kilometres).
The maintenance department in this case has to manage a large
number of individual pieces of equipment, including motors,
pumps, valves, chlorination equipment, schedulers, civil engineer-
ing installation, electrical control boards, transformers, etc., for
this, as in common in this type of company, the company has a
computerised program of maintenance management which not
only points to the tasks that have to be carried out but also estab-
lishes the criteria for carrying out these planned tasks (Fig. 2). Each
task, that is, each maintenance operation, can be planned:

 For a given date: for example, 1st July of each year.

 With a given periodicity: for example, every six months from a
given date.
 Every time that an ‘‘event” occurs: for example, whenever a
more important operation has to be carried out in the same
installation.
 As a function of a value of a given parameter: for example, after
a given number of operations or hours of operation.
The record that describes each task also has to reflect other data
that permits the task to be correctly carried out; such as the profes-
sional qualification of the operator necessary, whether or not
authorisation is needed and if so from whom, whether the operator
needs supervision (during the work or subsequent to completion),
an indication of the task’s priority standing, the mean time needed
for the task, whether or not any date limit applies, the materials
necessary divided into categories (replacement parts, tools or any
other essential material), etc.
As mentioned above, the scheduled tasks may well be compli-
cated by other unforeseen events, such as emergency repairs, sick-
ness or days off, unavailability of resources, etc. therefore, even if
planning and programming of the operations corresponding to a
Fig. 1. Geographical dispersion of the installations.
given day or period (e.g. week) may seem exhaustive, any change
in the initial conditions of the problem will be accompanied by a
new spectrum of possible solutions that must be looked at before
a suitable response can be provided.
Henceforth, by maintenance task schedules, we mean the dy-
namic design of work plans for a given period of time in which
all the maintenance operations are organised in order to optimise
the time and use of resources available and minimise the cost, at
the same time improving the overall availability of the plant (in
this case utility company) as a whole. The resulting schedule must
provide consistent and specific solutions for each operator and sit-
uation as regards the sequence of tasks to be carried out and the
materials necessary. Each solution will appear in a list of different
work orders, which we shall call route,to be carried out succes-
sively by the respective operators.
To elaborate each route, the head of the maintenance depart-
ment of the company will have a list of tasks that have to be
2966 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
Fig. 2. Criteria for establishing calendar of planned operations.
carried out on a certain date or in a given period. In the best
of cases, these tasks will be prioritised so that the first attempt
to provide a solution will be a sequence of pre-determined
operations.
Unfortunately, this state of affairs gets complicated when, as
frequently happens, many of the tasks are described as urgent.
On other occasions, the operations are not prioritised or, if they
are, the list of tasks at each priority level is very long. To all this
must be added the unforeseen problems as they arise, some of
which must be solved urgently. If the list of tasks to be carried
out during one particular period (e.g. one day) is too long, the less
important tasks will have to be postponed, and if the situation
Fig. 3. Daily list of work orders.
continues, certain tasks will never be carried out on time, increas-
ing the possibility of a breakdown. Far from being an exaggerated
catastrophe scenario, the above may well be regarded as ‘‘just an-
other day” in all too many industrial plants and installations.
In the case that concerns us, the company that is responsible for
providing and distributing drinking water to the general popula-
tion is also charged with other municipal services: rubbish collec-
tion, waste water depuration and the management and
maintenance of traffic lights. The Maintenance Department is com-
mon to all these services, and most operators must turn their hand
to the needs of each section. If, then, it was already difficult to pri-
oritise all the urgent tasks of one service, for example those asso-
ciated with the provision of drinking, water which is the focus of
our study, it now becomes even more of a nightmare if we have
to prioritise two totally different tasks – repair a traffic light, for
example, or repair a valve in the water distribution network – since
the consequences of either fault is unforeseeable and will depend
on the time, the place and the number of people affected, among
other things.
The result is that the number of operators available to carry out
the tasks on a given day, even during the same day, will vary. Fig. 3
depicts a typical list of work orders, which, in our study case, have
a date assigned to them.
3. Constraint satisfaction problem solving
Bearing in mind the description of the problem given above, one
solution to planning the maintenance tasks would be schedule
them into limited time intervals, along with the operators available
and materials to be used each day. As can be appreciated, we are
dealing with a scheduling problem combined with one of resource
allocation, which might be regarded as a constraint satisfaction
problem (CSP). Formally such a problem is defined (Tsang, 1993)
by a tuple {X, D, R}, where:
 X ¼ fX 1 ; X 2 ; . . . ; X n g, is a finite set of variables
 D ¼ fD1 ; D2 ; . . . ; Dn g, is a finite set of domains, and
 R ¼ fR1 ; R2 ; . . . ; Rr g, is a finite set of constraints
Each variable X i takes values in its corresponding domain, Di .
For example, in our problem a variable is the number of operators
available, whose domain is the set of integer numbers. A constraint
among a set of variables fX i1 ; . . . ; X ik g of X can be expressed as a
subset of the Cartesian product fDi1      Dik g, which is formed
 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
by tuples of values that satisfy the constraint; that is, it contains
the combination of values assigned to variables that do not violate
the constraint. The constraints may be unary, binary, etc., that is,
they affect only one variable, or two, etc., respectively.
Another type of constraint which we might consider ‘‘relaxed”
are user preferences. Although, formally these are considered as
constraints, the algorithm may stray from its assigned value until
it reaches a valid solution. In this case, a cost function brings to-
gether the deviations in the initial preferential values introduced
by the system. An example of a preferential constraint in our prob-
lem would be to obtain the best balance of the workload among
operators.
Bearing in mind the above definition, solving a CSP consists of
two well differentiated phases:
1. Modelling the problem. In this phase we start from the prerequi-
sites imposed by the application domain, which are translated
into CSP nomenclature. That is, we have to identify variables
and their corresponding domains, besides identifying con-
straints and preferences.
2. Processing the problem. Once the problem has been modelled,
we must decide what to do with the constraints. There are
two possibilities here:
2.1. Apply consistency techniques which are based on eliminat-
ing the inconsistent values of the domains of the vari-
ables and which enable information on the problem to
be deduced (levels of consistency, possible values of the
variables, minimum domains, etc.).
2.2. Use search algorithms which systematically explore the
space of solutions until a solution is found or until it is
demonstrated that no solution exists. Basically, this usu-
ally consists of choosing the search method best adapted
to the problem in hand.
Obviously, in our case, what interests us is to find a solution to
the problem in the terms described above, although most search
techniques apply consistency techniques to reduce the search
space. In the following sections we shall show how the problem
has been modelled and the technique used to search for a solution.
4. Modelling the problem
Constructing a model for CSP is straightforward as one only
has to formalise the constraints to be satisfied without having
to indicate how. First the problem must be specified by variables,
domains of values and instances of the variables. Then, it must be
decided which configurations of states are valid to construct a
solution. Finally, the information obtained must be expressed as
a set of constraints and preferences that the solutions must
satisfy.
The scheduling of maintenance tasks takes the form of work or-
ders (Wireman, 2008), which are: a written document in which are
recorded the maintenance operations to be carried out on a specific
part of the installation. These operations will be in the order in
which they are to be carried out. Below, we shall look at the infor-
mation necessary for carrying out and scheduling the tasks. The
different routes, organised by days, are the variables of the prob-
lem and a solution consists on an assignation of the maintenance
tasks to each day into specific routes.
The following information is included in the work order (WO):
 Date and time of starting
 Priority
 Location
 Duration
2967
 Number of workers
 Qualification necessary
 Whether or not authorisation is necessary
 Whether supervision is necessary during the task or afterwards
 The materials needed divided into categories
 Spare parts
 Tools or any other machinery to carry out and document the
operation such as auxiliary equipment, camera, manuals, etc.
At the end of the WO it is also necessary to specify the
following:
 Date and time of finishing task.
 Time taken.
 Observations. Commentaries, images, results, variations in the
established procedure, recommendations, etc.
Fig. 4 shows a work order with all the above mentioned fields.
The aim is to spread the work orders over the days of the week.
To schedule these, taking into account all possible constraints,
there are a series of parameters that are of crucial importance for
defining the constraints to which the maintenance tasks are sub-
ject. These are:
 C1: Number of operators available each day.
 C2: Number of operators assigned to the tasks at any time.
 C3: Number of vehicles available each day.
 C4: Number of vehicles assigned at any given time.
 C5: The work hours in a normal day.
 C6: The time needed to carry out each work order.
 C7: Foreseen date for each task.
 C8: Travelling time.
Parameters C 1 and C 3 are integer numbers that reflect the
components of the company each day. The number of workers
varies each week due to factors such as sub-contracting, it also
varies with the time of year, and sometimes a large number of
workers are needed for a specific task. Parameters C 2 and C 4
are also integer numbers and reflect the resources assigned to a
given task ate each moment. The constraints acting on these
parameters are C 2 <¼ C 1 and C 4 <¼ C 3 , which indicate that more
resources than those available or more journeys than are possible,
cannot be used.
Parameters C 5 and C 6 reflect the time-related constraints for
carrying out the tasks each day. The minimum units for expressing
the duration of a task are minutes. The constraint defined is that
C 6 <¼ C 5 , where C 6 is the sum of the duration of the tasks sched-
uled sequentially during each day.
Parameter C 7 corresponds to a given date, to which one can add
an integer number of days’ delay. Parameter C 8 represents the time
needed to travel between the different installations of the com-
pany (in minutes). This parameter is shown in the lower part of
Fig. 5.
The concept of a ‘‘Scheduled Work Order” will also include a
date of programming (date, hour and minute) and the order in
which tasks are to be carried out. Finally the ‘‘Plan”, which is a
set of scheduled work orders will have a start date, a finish date
and the cost – which is what we shall attempt to reduce.
Finally, according to the company’s own criteria, certain Prefer-
ences can be established to guide the search for solutions in one
direction or another, as if they were constraints, too. For the time
being, the preferences expressed by the company lead us in three
directions:
P1: Balance the work load: Priority should be given to keeping
the workforce occupied and to ensuring that the number of opera-
tors needed remains similar during the period in question.
2968 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973

Fig. 4. Detail of a work order.

Fig. 5. User interface.

P2: Minimise number of journeys: Give priority to minimising
travelling.
P3: Keep to the daily work plan: Give priority to the specified
date. When many tasks have to be carried out on a given date or
when the periods between inspections are short, this is the best
option since it avoids medium or low priority orders from being
passed over.
The user’s preferences are reflected in a cost function for the
plan, to elaborate which a value of 0–100 is assigned for each pref-
erence, which is then multiplied by a factor between 0 and 4:
 If a preference is marked as ‘‘exclusive” (i.e. it is the only prefer-
ence), the preference value will be 0 and the others two 4, and
the factor by which it is multiplied will be (4 – OPTIONAL attri-
bute). Consequently, the result of the ‘‘exclusivity” will be the
only factor that influences the function of cost.
 If no preference is marked as exclusive, they will all have values
of 1–3. If the preference is given the score of 1, this means that
the user has estimated the priority as high, and so its multiplier
factor will be 3 (4-1). The same occurs with medium and low
preferences.
 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
Therefore the cost function can be depicted as:
cost=((costOS*factorS)+(costOF*factorF)+(costT*factorT))/
(factorS+factorF+factorT)
Factors factorS, factorF and factorT are the importance of mini-
mising journeys, the importance that orders are not planned for
another day from which they are scheduled (maintain day’s pro-
gramming), and the importance of balancing the workload of oper-
ators (associated to the preference ‘‘balance daily workload”),
respectively. The cost values are:
 costOS: The cost associated with the orders followed by the same
location. The fewer the carried out in the same place, the more
expensive the plan. If ST is the total number of tasks carried
out in the plan and OT is the total number of orders in the plan,
to calculate the percentage of tasks carried out is ðST  100Þ=OT .
The more tasks completed, the nearer this figure will be to
100; as what we are looking for is the inverse, the valueOS will
be 100  ½ðST  100Þ=OT .
 costOF: The cost associated with tasks which must be carried out
on a day other than that planned. The more out-of-date the task,
the more costly the plan. In this case, let us suppose that F T is
the total number of out-of-date tasks and OT is the number of
tasks. As above, the value of valueOT is ðF T  100Þ=OT . This
remains as such because the more out-of-date tasks there are,
the higher the cost.
 costT: The value associated with the differences in the number
of workers on the different days of the plan. The lower the
variation with respect to the number of workers, the lower
this value, which corresponds to the equilibrated workload.
For this, we calculate the variation in the numbers every
day of the week (Monday compared with Tuesday, Wednes-
day; Thursday and Friday; Tuesday compared with Wednes-
day, Thursday and Friday; and so on). Then, we calculate the
percentage with respect to the number of workers, which is
the value we are looking for, since this will be increase as
the differences increase, which is undesirable since it is more
costly.
Any of the options can be marked as exclusive, in which no pref-
erence can be assigned to the others and to calculate the cost, only
the option marked exclusive will be taken into account.
5. Problem processing
The CommonKADS methodology offers support to all the devel-
opment phases of a knowledge-based system (project manage-
ment, organisation analysis and aspects related with Software
and Knowledge Engineering).
CommonKADS is directed at the implantation of a knowledge-
based system in a given organisation. To reflect the different as-
pects of the context in which KBS is to be applied, it offers six mod-
els: organisation, agents, tasks, communication, knowledge and
design.
For each intensive knowledge task identified in the contextual
analysis, a more detailed specification is made of the aspects re-
lated with the structure of the knowledge and of the reasoning pro-
cess involved in the task. In this case, the intensive task that
appears is that of Maintenance Planning.
The modelled task is divided into three categories:
 Task Knowledge: This describes how a high-level task is broken
down into sub-tasks: the task itself (inputs, outputs and goal)
and the method to carry it out (control).
2969
 Domain Knowledge: This specifies application domain facts and
assumptions needed to carry out the reasoning process in the
application domain (the form, structure and content of the
knowledge).
 Inference Knowledge: This describes the primitive reasoning pro-
cesses and the knowledge roles (input, outputs and static
knowledge required) used in the reasoning process.
Since the system does not exist before task execution, we are
dealing with a synthetic task. The output must be the jobs to
be carried out by the maintenance staff with their corresponding
time dependences. The inference structure can be seen in Fig. 6.
In the inference diagram we can see the following com-
ponents:
 Inferences
 Operationalize: Transforms the user’s needs (for the system)
into preferences and constraints. The algorithm is basically
a correspondence.
 Generate: Reads the work orders and plan them in accordance
with the scheduled date (with no optimisation). This will
provide a partial solution with the associated cost.
 Improve solutions: Studies the improvements that can be
made concerning the solution, based on user preferences.
 Modify: Modifies the plan in accordance with the results of
the above inferences.
 Undo: Removes the last modification if it is worse (due to cost
or the violation of some restriction) and the plan left as it was
before.
 Forward checking: Looks at the plan to see if the user’s restric-
tions are being fulfilled.
 Dynamic roles:
 Input data: The input data are the work orders and user
preferences.
 Preferences, constraints.
 Partial solution, improved solution, valid solution, extension
proposed.
 Static or basic rules of knowledge:
 Rules-improvements: Improvements will be proposed as func-
tion of values of certain attributes of user needs.
 Rules-preferences: The needs are ordered as function of user
preferences.
 Rules-specific-plan: Criteria to change the order of the site.
As an example, in Fig. 7 we include the control structure and
scheme of the inference ‘‘Operationalize” that is depicted in
Fig. 8.
As we have mentioned, the aim of the application is to generate
work orders for the time specified by the user, which fulfill the
restrictions and take into consideration the preferences.
Following the CommonKADS methodology and taking into ac-
count the re-use premise, we can classify the PSM into two
groups: those that can be applied to synthetic tasks and those that
can be applied to analytical tasks, further decomposed into more
specific tasks. Obviously, our problem falls in the first group. In-
deed, the method itself and the authors (Motta, Rajpathak, Zdra-
hal, & Roy, 2002) suggest a common characterisation for all the
synthetic tasks using terms as requisites, restrictions, dominions,
etc., which, in agreement with the analysis made in the section
modelling the problem, can be adapted to what we have defined
as a CSP.
The technique behind this type of algorithm is known as Back-
tracking (BT) (Dechter & Pearl, 1988; Frost & Dechter, 1994), which
is a complete search algorithm since it exhaustively explores the
whole space of possible assignations to the variables, finding a
solution, when one exists, or demonstrating that no solution exists.
2970 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973

Work orders and parameters

In put data Generate

Plan

Partial Solution
Task Description
Operacionalize Knowledge

Propose
Extensions

Undo Extension
Extensions
Plan proposed

Order of
Preferences Violation
Modify
Preferences

Optional Work Order

Improved
parameters
solution
Compulsory Plan
parameters Plan

Constraints Check Valid

Forward Solution

Fig. 6. Logic inference diagram of the system.

Fig. 7. Control structure of the inference ‘‘Operationalize”.

Input Data Operationalize Constraints

Task Description
Knowledge Preferences

User Plan specific Optional Compulsory

requirement rules parameters parameters

Fig. 8. Inference ‘‘Operationalize”.

Besides this search strategy, the literature includes numerous ref-
erences to complete search techniques, such as: Backjumping (Gas-
ching, 1979), Conflict-directed Backjumping (Posser, 1993),
Learning (Ftulis, Giordano, Pluss, & Vota, 1998), Forward checking
(Haralick & Elliott, 1980), Minimal forward-checking (Dent & Mer-
cer, 1994) and Full/partial look-Ahead (Haralick & Elliott, 1980),
innumerable modifications and improvements to the above tech-
niques, and hybrid versions. For a more exhaustive revision of
these techniques, see (Tsang, 1993; Dechter, 2003).
For our problem, we have selected Forward checking (FC), first of
all because it is straightforward enough to be transferred into a
PSM and because it can be extended by means of some heuristics
to optimise the process (ordering variables and values), and, sec-
ondly, several studies exist (Rodríguez, Palma, & Quintana, 2003),
in which the PSM corresponding to FC is presented, as well as
empirical evidence concerning the benefits of its re-use in other
application dominions.
The basic idea underlying FC is the fact that, in each step of the
BT search, the assignation of the present variable is checked
against the values of future variables, (which are themselves re-
stricted by the present variable). The values of the future variables
that are inconsistent with the present assignation are temporarily
eliminated from their dominions. If the dominion of a future vari-
able becomes empty, the instance is cancelled and another value is
 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
tried. If no value is consistent, chronological backtracking is carried
out. Therefore, the algorithm constructs the solution in install-
ments, assigning values to variables and testing inconsistencies
in the partial solutions with values of variables not yet included
in the partial solution.
6. Planning maintenance work orders
First, the period for which the system should find a solution
should be specified. Normally, the operational unit would be one
week, so that, in our case, the system must plan the distribution
of work orders to be accomplished during one working week. How-
ever, as a function of the time margins assigned to each operation,
the Controller module will make a search for operations (with a suf-
ficient time margin) that can be carried out before or after the per-
iod (pending operations) in an attempt to optimise the solution
obtained.
Working hours should also be introduced as constraints, partic-
ularly the beginning and end of the working day; also the possibil-
ity of working overtime and the limit in this respect for each
operator; finally, the number of vehicles available at the beginning
of each day (or at the moment of planning). Any other data that the
system needs can be read in a database, since changes occur very
rarely: for example, the installations and personnel referred to in
the work orders, or the distance between installations (or the time
taken to travel between them).
In the example that follows, we have introduced the ten opera-
tors for the installation and the maximum number of vehicles of
different types available, in this case five. Daily maintenance tasks
are to be carried out in five installations (Alcayna, Altorreal, Cone-
jos, Fenazar and Torrealta).
In these conditions and assigning the same priority to all the
preferences, the planning process will generate an initial solution,
to which it will gradually offer improvements; the solutions pro-
vided will serve to modify the last solution offered; these modifica-
tions will be checked to see whether they contain any
Fig. 9. Weekly plan of work orders classified by installation site.
2971
inconsistencies – in which case, the previous solution will be can-
celled to provide another.
The final result is a work order plan organised for the individual
operator’s route. The work orders requiring two or more operators
are timetabled at the beginning of the day because of the difficulty
in synchronising individual times separately for them to coincide
later. Once the common task has been carried out, each operator
will follow his own route, with or without a vehicle.
We show five tables, each for one day. The daily tables are di-
vided into columns that represent routes. Each route is associated
to a vehicle, but may have more than one operator assigned to it
since, as mentioned above, some tasks need more than one
operator.
Fig. 9 shows an example of weekly planning provided by the
program. When a task is selected, the corresponding specific de-
tails are given, including: the exact location of the installations
and the operations to be carried out, the number of workers
needed, whether they can all go in one vehicle or if more than
one is necessary (for example, when one operator is to follow a dis-
tinct route after the first job), the foreseen duration, whether or not
authorisation is needed, supervision or additional tests, and how
much information is needed to complete the task.
This initial plan can be optimised iteratively by the program, an
improved plan being provided each time the ‘‘Optimizar” (opti-
mise) button is pressed. If the number of operators or vehicles is
introduced, the system will provide information as to whether
the plan is feasible or whether some orders should be eliminated
from the maintenance management plan. It is preferable that the
user decides which orders should be omitted rather than the
program.
As we can see in Fig. 10, the system, as best as it can, has
grouped orders for the same site in one route. The orders of two
workers are different but the common tasks for them are put at
the beginning of the day, so that the two workers coincide in the
same place and at the same time, after which each one can con-
tinue with his route.
2972 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973

Fig. 10. Optimized planning.

When the button ‘‘Obtener Información de la Celda” (get informa-
tion from the cell) is pressed, the corresponding information refer-
ring to one of the tasks of a route is presented. The information of
the work order consists of a date and time proposed, priority, local-
ization, duration, number and qualification of workers, and if it is
necessary to provide a previous authorisation before committing
the work order.
The architecture of the software used divides the application
into three parts using the Model-View-Controller pattern (Busch-
mann, 1999), the reference software architecture recommended
by the CommonKADS methodology (see Fig. 11), each one of which
has the following functions:
 Model: Contains data and state of the application. When opera-
tions are being carried out, the control returns to the Controller
which returns the results to the assigned View.
Input MVC Output
 View: Controls what the end-user sees on the screen; shows the
information of the model. The interface classes delegate an
event to the controller when managing an event.
 Controller: Charged with redirecting or assigning an application
of the Model to each request of the View. By means of its own
control logic, it establishes the request-response correspon-
dence map. The Controller not only communicates with the
Model, but also exchanges messages with the Data manager,
which serves as intermediate between the controller and data-
base. In this way, the database remains independent.
The system is implemented in Java for the module View and the
interfaces with the two other modules, and G2 from Genssym
(http://www.gensym.com/ Last visited: 9/10/2008, xxxx) to imple-
ment the knowledge Model and Controller module. G2 is a tool for
developing expert systems with numerous libraries specifically di-
rected at industrial applications. The software application is made
by JDBC and Javalink, which are necessary for connecting with the
maintenance Database which the company already possessed.
Javalink and G2 communicate with each other through remote pro-
cedure call, that is, Javalink can invoke G2 procedures and method,
and G2 can invoke Java methods.

7. Conclusions
Input Output
Controller View Nobody doubts that setting up a maintenance plan these days
(java) (java)
must take advantage of the possibilities offered by information
technology. Useful, efficient and dynamic management of all the
information available requires the use of information technology
solutions. However, the greater the technical complexity, quantity
and variety of machines and the greater the distances over which
Model Data manager
installations are dispersed, not to mention the number of people
(G2) (Acces)
involved, the greater the need for tools that help the decision mak-
ing process, that is, intelligent systems capable of managing, not
only data but also reasoning criteria and information in order to
Fig. 11. Model-View-Controller architecture. find solutions to the logistical problems that arise very day. Such
 J. Palma et al. / Expert Systems with Applications 37 (2010) 2963–2973
is the case with planning maintenance work orders over a period of
time, when the systematically incorrect choice of plan, especially
as regards the tasks to be carried out, will imply needlessly high in-
creased costs.
In this article, we have demonstrated that the problem of plan-
ning maintenance tasks can be regarded as a CSP, where the vari-
ables of the problem, that is, all the data that define the context of
the maintenance to be carried out, are subject to continuously
changing restrictions. The search algorithm used to find solutions
must identify the groups of values of the variables that satisfy all
the restrictions imposed, applying heuristic inferences and elimi-
nating the inconsistent values of the dominions. The approach used
permits us to work with restrictions that may change rapidly and
to which the solution continually adapts, also permits the user to
indicate certain preferences that enable the different possibilities
to be classified. From a methodological point of view, we have
demonstrated that an approximation based on Knowledge Engi-
neering and the CommonKADS methodology, with special atten-
tion paid to the reuse of PSM, facilitates the modelling and
development of the application, leading to a substantial saving in
codification time without affecting the proposed solution.
Future works will follow two main lines of research. In the first
line, we are focusing on improving the efficiency of the planning
and scheduling algorithm, to which end we are analysing other
search algorithms and other heuristics that can be applied to this
particular domain. In the second line, we are looking at the possi-
bility of using a lighter, more portable platform that will be easier
to incorporate in mobile units.
Acknowledgements
This work was partially funded by projects PET2006_0406 and
PET2007_0033 from the Spanish Ministry of Science and
Innovation.
References
Alardhi, M., & Labib, A. W. (2008). Preventive maintenance scheduling of multi-
cogeneration plants using integer programming. Journal of the Operational
Research Society, 59(4), 503–509.
Angele, J., Fensel, D., Lanes, D., & Studer, R. (1998). Developing knowledge-based
systems in MIKE. Automated Software Engineering, 5(4), 389–418.
Buschmann, F. (1999). Pattern-oriented software architecture: A system of patterns
(Vol. 2). John Wiley and Sons.
2973
Cárdenas, M., Marín, R., & Navarrete, I. (2001). Fuzzy temporal constraint logic: A
valid resolution principle. Fuzzy Sets and Systems, 117(2), 231–250.
Dechter, R. (2003). Constraint processing. Morgan-Kaufmann Publishers. ISBN: 1-
55860-890-7.
Dechter, R., & Pearl, J. (1988). Network-based heuristics for constraint-satisfaction
problems. Artificial Intelligence, 34, 1–38.
Dent, M. J., & Mercer, R. E. (1994). Minimal forward checking. ICTAI, 432–438.
Domingue, J., Motta, E., & Watt, S. (1993). The emerging VITAL workbench. In
Aussenac et al. (Ed.), Proceedings of the 7th European knowledge acquisition
workshop (EKAW’93), LNAI (Vol. 723, pp. 320–339).
Frost, D., & Dechter, R. (1994). Dead-end driven learning. In Proceedings of the
national conference on artificial intelligence (pp. 294–300).
Ftulis, S. G., Giordano, M., Pluss, J. J., & Vota, R. J. (1998). Rule-based constraints
programming: Application to crew assignment. Expert Systems with Applications,
15(1), 77–85.
García, M. C., & Sanz Bobi, M. A. (2003). Planificación dinámica del mantenimiento
industrial mediante algoritmos genéticos. Mantenimiento, (Enero-Febrero), 42–
49.
Gasching, J. (1979). Performance measurement and analysis of certain search
algorithms. Technical report CMU-CS-79-124. Carnagie-Mellon University.
Gómez de León, F. C. (1998). Tecnología del mantenimiento industrial (Vol. 2).
Universidad de Murcia: Servicio de Publicaciones.
Gómez de León, F. C., & Ruiz Cartagena, J. J. (2006). Maintenance strategy based on a
multicriterion classification of equipments. Reliability Engineering and System
Safety, 1, 444–451.
Haralick, R. M., & Elliott, G. L. (1980). Increasing tree search efficiency for constraint
satisfaction problems. Artificial Intelligence, 14, 263–313.
http://www.gensym.com/ (lastvisited 9.10.08).
Lee, J. K., & Kwon, S. B. (1995). ES*: An expert systems development planner using a
constraint and rule-based approach. Expert Systems with Applications, 9(1), 3–14.
Research Frontier in the Far East.
Liu, B. (1993). Knowledge-based factory scheduling: Resource allocation and
constraint satisfaction. Expert Systems with Applications, 6(3), 349–359.
Marín, R., & Navarrete, I. (2003). Problemas de satisfacción de restricciones
temporales. Revista Iberoamericana de Inteligencia Artificial, 20, 111–120.
Motta, E., Rajpathak, D., Zdrahal, Z., & Roy, R. (2002). The epistemology of
scheduling problems. In F. van Harmelen (Ed.), Proceedings of the 15th ECAI
(pp. 215–219).
Pereira, R., Sanchez, J. L., & Rives, J. (1999). Knowledge-based maneuver and fire
support planning. Expert Systems with Applications, 17(2), 77–87.
Posser, P. (1993). An empirical study of phase transitions in binary constraint
satisfaction problems. Artificial Intelligence, 81, 81–109.
Rodríguez, A., Palma, J., & Quintana, F. (2003). Experiences in reusing problem
solving methods. An application in constraint programming applications. In
Proceedings of the knowledge-based intelligent information and engineering system
(KES’2003), LNCS (Vol. 2774, pp. 1299–1306).
Schreiber, G., Akkermans, H., Anjewierden, A., de Hoog, R., Shadbolt, N., van de
Velde, W., et al. (2000). Knowledge engineering and management: The
commonKADS methodology. The MIT Press. ISBN: 0-262-19300-0.
Tsang, E. P. K. (1993). Foundations of constraint satisfaction. London and San Diego:
Academic Press. ISBN: 0-12-701610-4.
Wireman, T. (2008). Maintenance strategy series. Preventive maintenance (Vol. 1).
Industrial Press Inc. pp. 62–63.