International Journal of Computer Applications in Technology, Volume 13, Nos.

3/4/5, 2000 251

Computerized dynamic
Gantt-chart for maintenance
scheduling and management

A. Radwan
Industrial Engineering Program, Faculty of Engineering, King Saud University,
P.O. Box 800, Riyadh 11421, Saudi Arabia

Abstract: The static Gantt-chart accommodates planned dates for preventative main-
tenance, or evenually planned maintenance. This is converted to a dynamic Gantt-chart
to deal with situations involving on-line analysis for real-time maintenance signatures pro-
viding predictive functions, in addition to breakdown situations. This is in addition to the
planned preventative maintenance. Thus, the work presents a proposed software design
for a complete maintenance scheduling and management system. The system considers
the integration of maintenance and the other manufacturing activities. Meanwhile, the
related interfaces are also de¢ned. The output of the system is a daily maintenance work
plan, listed on a display for the maintenance team, so they can perform the required every
day maintenance operations.

Keywords: maintenance scheduling, management, database, relational model.

Reference to this article should be made as follows: Radwan, A. (2000) ‘Computerized

Dynamic Gantt-chart for maintenance scheduling and management’, Int. J. of Computer
Applications in Technology, Vol. 13, Nos. 3/4/5, pp. 251^260.

Grunwald [7] have described the objectives of inte-

1 INTRODUCTION
The need for an effective maintenance management sys-
tem to cope with high demands in automated systems is
highly recommended. Where time is an important
and critical event, a fast and ef¢cient maintenance man-
agement system is a must. Maintenance management
techniques are well covered in several references [1^3].
This work presents a computerized maintenance man-
agement system to cope with the demand of automated
and computer integrated systems.
Few systems have been mentioned, which specify the
hardware and system con¢guration for implementing
computerized maintenance management systems [4].
Also, the same case applies when it comes to on-line
real-time data acquisition concerning parametric data
for Predictive Maintenance (PM) [5]. Such parameters
may be the degree of vibration, acceleration, velocity,
displacement, temperature, etc.
Not many references touch on the area of the inte-
gration of maintenance and other manufacturing
activities, although Computer Integrated Manufactur-
ing (CIM) systems are. These will become increasingly
important in coming decades. Dippenaar [6], and
grating the maintenance activity with the production
control, inventory control, and cost engineering
activities.
There have been attempts at providing computer-
aided maintenance management [8], and expert systems
[9], but most are limited to a speci¢c technique, and
are in£exible.
The human side of computerizing maintenance, has
been analysed by Steinbly [10]. Gehl [11] addresses many
of the issues related to choosing a computerized main-
tenance management system.
This work aims to develop a complete computerized
system for maintenance scheduling and management.
The scheduling provides schedules of preventative
maintenance, planned maintenance, and the breakdown
maintenance, in addition to on-line condition
monitoring. Various types of sensors can be attached
to the critical places in the machines. The management
part of the system has to follow a deterministic priority
mechanism, or at least to provide the maintenance
personnel with a daily list, reminding them when
recurring tasks need to be done. At the same time it
has to report the actual progress of the task, and
reschedule any delayed work depending on the cause
252
of the delay. The system integrates the related activities
(e.g., production control, spare parts inventory, cost
engineering, etc.). Thus, the interfaces within a CIM
enterprise are de¢ned.
2 SYSTEM STRUCTURE
This system contains three databases (Figure 1). One
static and two dynamic. Dynamic in this context means
that the data changes regularly and automatically with
or without the human interferring. The static one is a
database for details of maintenance work. The other
two are the Gantt-chart, and the daily maintenance
work plan.
2.1 Description of the databases
The keywords common to the three databases are:
machine number (mach-num), Fault (code). The three
databases are internally interconnected to facilitate
the £ow of data automatically. For example, the daily
maintenance work plan database gets its data from
the other two databases as shown in Figure 1. The con-
tent of each database are as follows.
2.1.1 Details of maintenance work (DMW) database
This is the only static database in the system. That
means the data is fed in manually, or under control,
and is not subject to regular changes. Thus, this
database is cataloging each machine, its location, the
Figure 1
A. RADWAN
regular or preventative maintenance work, and the poss-
ible faults. These are described as job description
statements, in addition to the time required (time-req.)
to execute or perform each maintenance job or
operation, and the service manual catalog number as
a code for cataloging purposes. Similarly, spare parts
numbers and the number of special tools, if any, are
recorded.
2.1.2 Gantt-chart (GC) database
The Gantt-chart (GC) database is partially static, when
it accepts scheduling information from the chart. These
data are probably about the preventative and planned
maintenance work. The dynamic part comes from the
delayed schedules, which may be transferred to the
GC-database from the daily maintenance work plan
database. The typical data residing in this database
are simply the data available from the GC. These
may be listed as the start date (day-month-year) for
a maintenance task, on a speci¢c machine (mach-num),
situated in the location (loc-num). The maintenance task
or job description which describe the maintenance oper-
ation (MO) in a short statement, whether it is allowed to
call it MO, and the work duration as the time required
(time-req.) for this speci¢c MO are also listed.
2.1.3 Daily-maintenance work plan (DMWP)
database
This is a fully dynamic database, in that every day the
content is emptied or renewed. Thus, the data which
System structure.
COMPUTERIZED DYNAMIC GANTT-CHART FOR MAINTENANCE SCHEDULING AND MANAGEMENT
is scheduled for a speci¢c date will be transferred from
the GC-database as a daily work plan, when its date
comes to the calender day. The same key words
mach-num and fault (code) are used to access the related
data such as service-manual (DOCUMT) spare parts
numbers, special tools, if any, from the details of the
maintenance work (DMW) database. Added to that,
there are empty data-input domains for reporting the
actual time-used, and the actual maintenance work pro-
gressing. These are entered as remarks. The remarks are
short statements describing the maintenance work
progressing for each machine or activity. For example,
a statement (¢nished) informs about a completed main-
tenance job on a speci¢c machine. However, statements
such as spare-part-NOT-available (SPNA), man-power
(MP), special-tools (ST), etc. give the causes for
uncompleted work, and according to each cause or
reason, a decision is made for rescheduling the con-
cerned maintenance work, and indicating the new data.
Here, the interefaces with the related activities are
de¢ned. Thus, for example the SPNA statement necessi-
tates establishing an interface link to the purchasing
department to provide the estimated time for nego-
tiation and expediting the concerned spare part. This
time can be used by the maintenance scheduler to assign
a new start date in the GC-database. Also, the appear-
ance of an SPNA remark indicates the necessity for
establishing an interface link with the inventory control
department. This is to coordinate between the purchas-
ing and maintenance activities, thus allowing the system
to automatically provision the required spare parts or
special tools, and to ensure the availability of these items
on time. Maintenance costs consist mainly of two types
of cost; labour costs and the costs of the spare parts.
2.2 System interfaces
The GC scheduling information is based on the
preventative and planned maintenance work. Thus,
for the sake of establishing a complete integrated and
£exible maintenance system, the interfaces with the
following activities may be addressed.
2.2.1 Machine breakdown situations
In this case, a maintenance analyser may be started to
detect any machine breakdown, before the work pro-
ceeds to schedule and allocate resources to the task.
The analyzer has to de¢ne the defect and the cause, then
provide the key words; Mach-num and Fault (code) of
the concerned out-of-order equipment or machines.
These data are fed directly to the DMWP-Database,
which in turn accesses the related information from
the DMW-Database.
2.2.2 On-line data acquisition
This is similar to the system described by Anon [5].
Sensors are attached to each concerned machine to
measure vibration levels, and other parameters (e.g.
253
acceleration, rpm, displacement, DC-temperature etc.)
from the machines used throughout the plant. The
measured signals are forwarded to signal conditioning
boards, and further to industrial computers. Thus, these
data may be compared against reference data, to point
out if a serious problem is about to arise. An Expert
Analysis System (EAS) may ¢lter out the defects and
¢nd out the possible causes. This leads to a maintenance
plan for the concerned machine and again provides the
key words for the system databases, and automatically
edits the new maintenance task into the
DMWP-Database.
2.2.3 Condition monitoring
This is concerned mainly with detecting oil and fuel level
issues, to prevent possible catastrophic failures. These
check procedures may be done manually, or automati-
cally through a sensory system.
2.2.4 Production planning and control (PPC)
This is one of the most important and complicated inter-
face links, regarding the aspect of maintenance integrat-
ion. This interface is necessary to coordinate between
the production planning and the maintenance planning
to accommodate long-term planning, and short-term
planning, when unexpected events happen, or when a
machine breaks down or is about to break down.
Here, there are two interface links, one connected to
the GC-database for long-term planning, and the other
is connected to the DMWP-database. The ¢rst link
to the GC-database (Figure 1) provides scheduling
dates for preventative and planned maintenance work,
also scheduling or assigning dates for delayed or
uncompleted schedules. The second link assigns priority
levels for DMWP-database through an interactive eval-
uating for the daily-maintenance-work.
2.2.5 Inventory control and purchasing
It is a simple interface link providing a two way data
transfer link: one from the GC-database about spare
parts orders schedules; and a feedback link from the
inventory control system about the estimated dates of
spare parts availability.
2.2.6 Man-power and cost engineering systems
As mentioned by Grunwald [7], maintenance is mostly
manpower constrained. To plan for the human resource
to cover the needed maintenance classes of skills, is not
an easy task. Wherever possible managers plan for
preventative and planned maintenance, but it is not
possible to plan for unexpected events such as equi-
pment breakdown, unless the planning is supported
by a local experience.
The interaction with the maintenance system provides
information for the payroll and the costing systems.
Thus, the use of the same key words will access the data
of man-power and cost domains, or even transfer the
data of all completed maintenance work to the related
254
activity. The total cost may be calculated from the item
cost, and the labour rate multiplied by the time used,
as indicated in Figure 1.
3 USER INTERFACE AND DATA ACQUISITION
This is assumed to be an interactive maintenance man-
agement system. There are several types of users who
may use this system, for example:
3.1 Some user types
The user may be a maintenance man, a production or
maintenance planner, a manager, etc. One may select
any of the three databases through a menu-driven
interactive system.
3.1.1 Maintenance man
When the maintenance man starts the system, and
selects the daily maintenance work plan (DMWP)
-database, a list is displayed for this speci¢c day
showing the maintenance tasks of that day. The list
includes information about the machine number, the
type of fault, the machine location, the job description,
and the estimated time required. In addition it includes
information about the related service manual or
documents, spare parts, special tools if any, and a pri-
ority level. The jobs are arranged automatically accord-
ing to the priority level. There are empty domains for
inputting data about the actual time used to update
the time-required attributes, in addition to the
calculation of costing, and the remarks about the work
progressing [Figure 1]. This list is subject to some
changes either manually by editing new items (e.g.
reporting machines breakdown), or automatically,
through for example, the on-line equipment detecting
system detecting an out-of-range machine measurable
parameter.
3.1.2 Maintenance planner
The maintenance planner may be interested in select-
ing the GC-database to set schedules for maintenance
work in coordination with the production planning
department. Here, it is possible to edit the start date
for maintaining a speci¢c machine number, which is
situated at a speci¢c location number, and the estimated
time required to perform a speci¢c described mainten-
ance work on this machine. It is possible to up-date
or modify records, or to scroll the database to display
day-by-day maintenance work, by just giving the date
of any day (Figure 2), and the maintenance work already
started but not yet completed during the day. This work
may be rescheduled for the next day.
3.1.3 Maintenance supervisor
The maintenance supervisor may be interested in
selecting the details of maintenance work (DMW)
A. RADWAN
to edit in the necessary information for his men, such
as the service manual or the index of the maintenance
documents of each machine or the necessary spare
parts, or any special tools, for a speci¢c maintenance
task. The items of the old machines may be deleted
or cleared from the database. Any modi¢cation or
data up-dating may be done on the database through
the interactive menu driven system (Figure 2). It is
possible to display or show any part or information
from any database, in addition to listing, or printing
out this information.
3.2 Data acquisition
As noted, the data acquisition for the DMW-database
is completely manual, except that the time required
attribute may be up-dated automatically with the
actual-time-used attribute. However, for the other
two databases, the data or the information is fed
partially manually and partially automatically. The
GC-database is based mainly on the scheduled
preventative and planned maintenance information,
which is fed in manually in coordination with the
production planning department. Otherwise, the
delayed schedules are fed in automatically to a buffer
area to be rescheduled, each according to whether the
cause of the delay was the unavailability of spare
parts, or special tools, or both. A new date may
be assigned by the purchasing department. If the
cause was a lack of manpower, which is a common
reason, the production control people may assign
another date for the delayed maintenance task, or
assign a higher priority level for the urgent mainten-
ance work. The DMWP-database is a fully dynamic
database. Thus, all the data of the previous day
would be automatically transferred to the
GC-database buffered area at the end of the day,
and the maintenance task, which is scheduled for
the date of the new day will replace the old one,
and so on. At the same time this database is con-
nected directly on-line to a data acquisition system
to detect machine breakdowns, or whether the
machine is about to breakdown in the near future.
Continuously, the priority levels for unstarted jobs
are evaluated by the production planning and control
department, which assigns higher priority levels to the
most urgent maintenance work. That means the
attributes of the priority level is changing all day.
Also, it is possible to manual interfer with this
database to add, delete, and modify any item, and
this makes it a completely £exible maintenance man-
agement system.
The cost of a maintenance task may be easily calcul-
ated from the actual time used, the labour rate, and
the price of the spare parts.
The required manpower capacity for preventative
and planned maintenance work may be calculated
directly from the GC-database. Otherwise, the esti-
COMPUTERIZED DYNAMIC GANTT-CHART FOR MAINTENANCE SCHEDULING AND MANAGEMENT 255

Figure 2 Main system £ow-chart.

256 A. RADWAN

mated manpower necessary to cope with unexpected For all ðm; f Þ, ðf ; jÞ 2 R, we have ðm; jÞ 2 R, the
events such as equipment breakdowns, depends on relation is transitive where
the experience of the equipment history and
reliability. Fn ¼ f f1 ; f2 ; . . . ; fn g
Jd ¼ f j 1 ; j 2 ; . . . ; j n g

The DMW-database may be thought as a table that lists

4 THE SEMANTIC DATA MODELLING the relationship of machine number and fault number to
other elements as indicated:
4.1 The mathematical model
[ [
n

The concept of the database is simply any collection f¼ Si

i¼1
of data sets. For example, a machine set may be [
as such: fðDMWÞ ¼ fMn ; Fn ; Ln ; Jd ; Tr ; Dm ; Sp ; St g

M ¼ fm1 ; m2 ; m3 ; . . . mn g where Dm ¼ document of maintenance work for a

speci¢c machine
Therefore assume that each database contains a col-
Sp ¼ spare parts required for a speci¢c mainten-
lection of data sets:
ance work
f ¼ fS1 ; S2 ; . . . ; Sn g St ¼ special tools required for a speci¢c main-
tenance work.
The GC-database may contain the following union of For all ðm; ai Þ 2 R with m 6¼ ai
the arbitary family fðGCÞ of sets: We have ðai ; mÞ 62 R. The relation is antisymmetric,
[ [
n where
f¼ Si
Ai ¼ fFn ; Ln ; Jd ; Tr ; Dm ; Sp ; St g
i¼1
[
fðGCÞ ¼ fPd ; Mn ; Fn ; Ln ; Jd ; Tr g For all ðm; f Þ, ð f ; bi Þ 2 R, we have ðm; bi Þ 2 R.
The relation is transitive
where Pd ¼ planned date for a maintenance task Thus, Bi ¼ fJd ; Tr ; Dm ; Sp ; St g
Mn ¼ machine number of a maintained machine The DMWP-database is a dynamic database, and is
Fn ¼ fault code for the fault to be maintained generated from the other two databases:
Ln ¼ location number of the machine to be main- [ [
tained fðDMWPÞ ¼ fðGCÞ fðDMWÞ fE
Jd ¼ job description of the maintenance task [ [n
Tr ¼ estimated time required for the mainten- fE ¼ Ei
ance task. i¼1

The union of an arbitrary family f of sets may be Ei ¼ fPl ; Tu ; Rn ; Sc ; Lr ; Tc g

de¢ned as those elements x belonging to at least one
set X in f [12]: where Ei ¼ empty sets to input data about the mainten-
[ ance work progressing
f ¼ fxjx 2 X for some X 2 fg: Pl ¼ priority level for a maintenance job
Tu ¼ the actual time used for a maintenance job
The GC-database may be thought of as a table that lists Rn ¼ remarks about the maintenance work
the relationship of date elements to other elements so progressing
that: Sc ¼ spare parts cost
Lr ¼ labour rate
f p 2 Pd jðp; mÞ 2 R for some m 2 Mn g: Tc ¼ total cost of a maintenance task.
For all ð p; mÞ 2 R with p 6¼ m, we have
ðm; pÞ 62 R: 4.2 The extended entity-relationship (EER) model
The relation is antisymmetric. This is the case with all Entities represent objects to be modelled. For example,
the other sets in the family fðGCÞ of sets. the Gantt-chart can be an object to be modelled. A
For all ð p; ai Þ 2 R with p 6¼ ai we have property of this object may be the scheduled date to
start maintaining a speci¢c machine, to cure a speci¢c
ðai ; pÞ 62 R
fault. This machine is placed in a speci¢c location. Also
where given is the description of the maintenance task and the
estimated time required to perform this task. Thus,
Ai ¼ fMn ; Fn ; Ln ; Jd ; Tr g these properties may be de¢ned as the attributes of
COMPUTERIZED DYNAMIC GANTT-CHART FOR MAINTENANCE SCHEDULING AND MANAGEMENT
an entity type named Gantt-chart. The values of these
attributes may be de¢ned as instances of the speci¢ed
entity type.
The GC-entity type may include the following
attributes:
DATE: planned date for a maintenance task
MACH-NUM: the number of a machine scheduled
for a maintenance work at a speci¢c
date
FAULT: the code of a speci¢c fault
LOC-NUM: the number of the location of the
machine which is to be maintained
JOB-DESCRIP: the job description of the concerned
maintenance task
TIME-REQ: The estimated time required to per-
form a speci¢c maintenance task.
Since, the values of the DATE attribute uniquely ident-
i¢es the instances of a speci¢c date within the GC-entity
type, the DATE attribute can be a candidate key for the
GC-entity type.
Further, the details of maintenance work may be
represented by DMW-entity type, which may include
the attributes: MACH-NUM, FAULT, LOC-NUM,
JOB-DESCRIP, and TIME-REQ in addition to the
attributes:
DOCUMT: document index of the service
manual of a speci¢c machine-fault
maintenance
SPARE-PART: the necessary spare parts
SPECIAL-TOOL: special tools, if needed.
Here, the values of the MACH-NUM and FAULT
attributes may uniquely identify each instance of the
DMW-entity type. Thus, these attributes may be de¢ned
as candidate keys.
Consequently, the daily maintenance work plan
object may be represented by a DMWP-entity type. This
entity type can include both attributes of the GC-entity
type and DMW-entity type in addition to the following
empty attributes as data inputs:
PRIOR-LEVEL: the priority level, which is assigned
by the production planning and con-
trol department
TIME-USED: the actual time used to ¢nish a
speci¢c maintenance task
REMARKS: the remarks statements given about
the actual progressing of a speci¢c
maintenance task.
As with DMW-entity type, the values of the
MACH-NUM and FAULT attributes can be de¢ned
as candidate keys.
4.3 The relational data model
A relationship may be de¢ned as a named association
between two or more entity types. There are two
257
relationships: a relationship of Maintenance Schedules
(MS) between GC-entity type and DMWP-entity type;
the second relationship is a Maintenance-Details for
Daily-Work (MDDW) between the DMW-entity type
and the DMWP-entity type.
Every instance of DMWP-entity type participates in
the MDDW-relationship. The membership class of
the DMWP-entity type is mandatory in that MDDW-
relationship. In other words, every maintenance job
must be related to the MDDW-relationship. However,
the membership class of DMW-entity type in the
MDDW-relationship is optional.
4.3.1 Structural de¢nition of a relation
The structural de¢nition of a relation may be as follows
[13]:
^ The tabular relation is a collection of sets, R is a
relation on those sets such that, the columns represent
attributes.
^ Each attribute has an associated domain: all the
allowable values of this attribute are data elements
of this domain.
^ The domain is known as a data type.
^ The number of domains determine the degree of the
relation.
^ Each row is de¢ned as a tuple, which contains an
instance.
^ The number of tuples determine the cardinality of a
relation.
^ The tuple may be represented as a record.
^ A key uniquely identi¢es each tuple (record) in R.
^ The attributes may be represented as ¢elds.
4.3.2 Transformation of extended entity relationship
(EER) model
To convert an EER model into a relational scheme each
entity-type is represented by a relation scheme. In that
way, the attributes of the entity type become attributes
of the relation.
Thus, the GC-entity type may be represented by a
relation scheme of the form:
GC (DATE #, MACH-NUM, FAULT,
LOC-NUM, JOB-DESCRIP, TIME-REQ)
Here, the DATE attribute is considered to be a candi-
date key, to locate all the records assigned to a speci¢c
date.
The relation scheme of DMW-entity type may look
like:
DMW (MACH-NUM #, FAULT #, LOC-NUM,
JOB-DESCRIP, TIME-REQ, DOCUMT,
SPAR-PART, SPECIAL-TOOL)
The MACH-NUM and FAULT (code) attributes are
considered to be the candidate keys, which uniquely
identi¢es each record in the DMW-database.
258 A. RADWAN

Further, the DMWP-entity type may be represented FOREIGN KEY (MACH NUM #, FAULT #)
by such a relation scheme: REFERENCES DMW);
DMWP (MACH-NUM #, FAULT #, LOC-NUM,
Further, the base table for the DMW relation scheme
JOB-DESCRIP, TIME-REQ, DOCUMT,
may be created by the following SQL statements:
SPAR-PART, SPECIAL-TOOL, PRIOR-LEVEL,
TIME-USED, REMARKS, ITEM-COST,
CREATE TABLE ____ DMW
LABOUR-RATE, TOTAL-COST)
(MACH NUM # CHAR(7) NOT NULL ,
Here also, the attributes of MACH-NUM and FAULT FAULT ____ # SMALLINT NOT NULL ,
(code) are de¢ned as candidate keys. The values of LOC ____ NUM SMALLINT NOT NULL ,
the PRIOR-LEVEL, TIME-USED, REMARKS, JOB ____DESCRIP CHAR(50) NOT NULL ,
ITEM-COST, LABOUR-RATE, TOTAL-COST REQ TIME TIME NOT NULL ,
attributes. These values would be null, or simply DOCUMT ____ CHART(7) NOT NULL ,
unknown at the begining of the day, until data are SPAR PART ____ CHAR(8) ,
assigned as input data to the system by the relevant SPECIAL ____ TOOL CHAR(7) ,
persons. PRIOR____ LEVEL SMALLINT ,
However, the degree of the DMWP-relation scheme USED TIME TIME ,
seems to be too large. This may be divided to three REMARKS ____ CHAR(50) ,
relation schemes as follows: ITEM COST ____ SMALLINT ,
LABOUR RATE SMALLINT ____ ,
DMWP: Daily Maintenance Work Plan
PRIMARY KEY (MACH NUM #,
DDMWP: Detailed Daily Maintenance Work Plan
FAULT
____ #) ,
DMWC: Daily Maintenance Work Cost.
FOREIGN KEY (MACH NUM #,
The attributes for each may be as follows: FAULT #)
REFERENCES TEMP);
DMWP (MACH-NUM #, FAULT #, LOC-NUM,
JOB-DESCRIP, TIME-REQ, ____
PRIOR-LEVEL) ____One may notice the attributes: PRIOR ____ LEVEL, USED
TIME, REMARKS,
____ ITEM COST, and the
DDMWP (MACH-NUM #, FAULT #, LOC-NUM,
LABOUR RATE. These attributes are joined the
DOCUMT, SPAR-PART,
DMW-table to facilitate the concerned relational
SPECIAL-TOOL, TIME-USED,
algebra, as will be indicated. Also, these attributes will
REMARKS),
remain null in this DMW-table.
DMWC (MACH-NUM #, FAULT #, LOC-NUM,
The DMWP table may be considered as a virtual table
TIME-USED, ITEM-COST,
[14] i.e. a table that does not exist in the physical storage.
LABOUR-RATE, TOTAL-COST).
This DMWP table is the join of the two tables DMW
and TEMP. Thus, the TEMP is a snapshot table, like
a view. But, a snapshot is a real table with its own stored
4.3.3 Relational algebra and language
data. The TEMP table may be generated from the GC
In fact, the relation scheme which is mentioned in the
table, and includes the maintenance work which is
previous section is understood by the user as a
assigned to a speci¢c date:
database. This relation scheme is a table and the
database is a collection of tables [14]. Although we
CREATE SNAPSHOT TEMP____
sometimes allow ourselves to call a table a database,
AS SELECT MACH NUM #, FAULT #
which may be a special case, the relational algebra
FROM GC
deals with the relation scheme as a base table. The
WHERE SDATE # ¼ 0 DATE0
relational language SQL, which stands for Structural
REFRESH EVERY DAY;
Query Language, is used to formulate relational
operations.
Thus, the current value of the snapshot is reviewed every
To create a new, empty base table called GC, by using
day.
the SQL might look like:
As mentioned, the DMWP table is considered to be
CREATE TABLE GC the join of DMW and TEMP tables. This join is a natu-
(SDATE____# DATE NOT NULL , ral join over the machine number and the type of fault.
MACH NUM # CHAR(7) , The relational algebra of this kind of join may be as
FAULT ____ # SMALLINT , follows, using the y-join as described by Mittra [13]:
LOC ____ NUM SMALLINT , Let RTEMP and RDMW be two relations of degrees m
JOB ____DESCRIP CHAR(50) , and n, respectively; and let y be any valid arithmetic
REQ TIME TIME , comparison operation. The y-join of the RTEMP on
PRIMARY KEY (DATE # , attribute ATEMP , and the relation RDMW on attribute
COMPUTERIZED DYNAMIC GANTT-CHART FOR MAINTENANCE SCHEDULING AND MANAGEMENT 259

ADMW , is the set of all tuples t such that t is the con- . Each database displays or shows an interactive
catenation of a tuple tTEMP , where menu containing all the related functions as shown
in Figure 2.
tTEMP 2 RTEMP and a tuple . The DMW-database may include the related infor-
tDMW 2 RDMW mation as indicated in Figure 1 for all the available
equipment.
and the condition tTEMP . ATEMP y tDMW . A____DMW holds. . The yearly scheduled preventative and planned main-
Since, the attribute values of MACH NUM and tenance jobs may be entered to the GC-database.
FAULT are identical for both relations RTEMP and The information may be represented as the start date
RDMW , the y-join is an equijoin. Consequently, the of the maintenance job for a speci¢c machine number,
relation of the DMWP may be represented as: which is situated in a speci¢c location number, in
RDMWP ¼ RTEMP JOINT RDMW addition to the estimated time required to perform
this speci¢c maintenance job.
The degree of RDMWP is m þ n ÿ 2. This may be . A real-time clock is programmed in the main module.
expressed by SQL as: Every day, this clock triggers the date of the present
____ day. The consequence of this action is the transferring
CREATE ____ VIEW DMWP ____ (MACH NUM #, ____ FAULT #, of all the related maintenance jobs scheduled for
LOC NUM, JOB ____ DESCRIP, REQ ____TIME,
this speci¢c day, from the GC-database to the
DOCUMT, ____ SPAR PART, ____ SPECIAL TOOL, DMWP-database.
PRIOR____ LEVEL, ____ USED TIME, REMARKS, . The DMWP-database shows the information when
ITEM COST, LABOUR RATE) transferred from the GC-database for the present day.
AS SELECT DMW.* A priority level code is given to each maintenance job
FROM TEMP, DMW ____ by the production control department.
WHERE TEMP . MACH NUM #¼ . There is a real-time function with a programmed
____
DMW. MACH NUM #, sampling time to open a gate for transferring
AND TEMP . FAULT # ¼ DMW. information: from the defect and cause analyser
FAULT #; (DCA) buffer area reporting any equipment break-
down; from the buffer area of the expert analysis sys-
Under the additional operators, Date [14] has described tem (EAS) to report on machines about to break
the EXTEND operator, as an operator which provides
down in the near future; in addition to detecting
an additional attribute. The values of this attribute
the levels for fuel and oil from the condition
may be obtained by evaluating some speci¢ed (scalar)
monitoring system (CMS).
computational expression. Thus, in our case, ____ the . Input data from the maintenance section about the
DMWP table may be extended by the TOTAL COST
maintenance work progressing, such as the time used
attribute as:
for each completed job, also the respective remarks
____
EXTEND DMWP ____ ADD (ITEM____ COST þ about if the task started/not-started, and if not, what
(LABOUR the causes or reasons are, are used to assign attributes
____ RATE * USED TIME)) AS
TOTAL COST in the DMW-database. The cost of a completed main-
tenance work may be calculated on the basis of the
prices of the spare parts and the rates of maintenance
labour.
5 THE ALGORITHM . The estimated manpower capacity required for
preventative and planned maintenance work may
As mentioned, this is assumed to be an interactive main-
be calculated from the GC-database. This is based
tenance management system. It is a modular type
on the attribute of the time required for maintenance
system, and may consist of a main module and
tasks.
submodules. Each submodule is dedicated to perform
. At the end of the day, the information related to the
a speci¢c job to realize the necessary database manage-
uncompleted maintenance jobs may be transferred
ment functions (Figure 2). These include e.g. open,
to the buffer area of the delayed schedules in the
append, delete, browse, etc. and others concerning
GC-database, for further rescheduling. Each main-
the interfaces between this maintenance management
tenance job is evaluated individually based on what
system and the other related systems (e.g. production
is hindering the work progress, and in coordination
planning and control, inventory, control, purchasing,
with the production planning and control department
etc.).
and the uncompleted work because of the
The following steps may be considered during the
unavailability of spare parts. This may be rescheduled
system development phase:
according to the information provided by the pur-
. The user may select any of the databases or tables to chasing department about the estimated delivery
work with. time.
260
. The completed maintenance work is reported and
documented. The time used is entered, and the
attribute of the time required in the DMW-database
is up-dated.
6 CONCLUSIONS
As one may notice, the system is not only concerned with
the maintenance management functions, but also de¢n-
ing the interface links between the maintenance depart-
ment and the other related departments such as the
production, planning and control, inventory control
and purchasing, cost engineering, etc.
This system is not only interactive from the user side,
but also internally between the maintenance activity
and all the related manufacturing activities. It is a
dynamic, £exible, and integrated system. This may
realize the CIM enterprise, however, data is communi-
cated to all respective activities on-line.
Most of the available maintenance management
systems stand alone, or partially provide information
to the respective departments. Here, the maintenance
planning and work organizing may be executed in
coordination with the respective departments. Thus,
the production planning and control must be involved
directly in maintenance planning and management
activities, so as to achieve a smooth as possible pro-
duction £ow, to realize the planned production level.
All the available maintenance techniques may be
incorporated in one £exible maintenance management
system: the preventative, planned, and machine break-
down maintenance, in addition to the on-line machine
data acquisition; and the condition monitoring for fuel
and lubrication levels. All these are integrated and
interrelated.
A. RADWAN
REFERENCES
1 Corder, A.S. (1976) Maintenance Management Technique,
McGraw-Hill.
2 Heintzelman, J.E. (1976) The Complete Handbook of
Maintenance Management, Prentice-Hall, Inc.
3 Criswell, J.W. (1983) Planned Maintenance for Pro-
ductivity and Energy Conservation, The Fairmont Press
Inc.
4 Woodring, B. (1987) Maintenance Tracking with a
Micro/Mainframe System, Published by ASCE, New
York, pp. 484^491.
5 Anon, (1991) Health Maintenance for Machines, Tooling
and Production, Vol. 57, No. 8, Nov. pp. 58^60.
6 Dippenaar, D. (1988) ‘Integrated maintenance information
management’, South African Mechanical Engineer, Vol.
38, No. 11^12, pp. 6, Nov-Dec.
7 Grunwald, A. (1992) ‘Integration of maintenance and pro-
duction control systems’, Proceedings of the APICS 35th
International Conference 1992, pp. 639^640, Published
by APICS, Falls Church, VA, USA.
8 Gelis, N. (1989) Ceric Launches Computer-Aided Mainten-
ance Management, Ziegelindustrie International, Vol. 42,
No. 5, pp. 279^281, May.
9 Paz, Noemi, Leigh, William, Pullin, Jim, Ragusa, Jim
(1990) Information Systems Con¢guration by Expert
System. The Case of Maintenance Management, Com-
puters & Industrial Engineering, Vol. 19, No. 1-4,
pp. 553^556.
10 Steibly, R.L. (1989) Human Side of Computerizing
Maintenance, SME Technical Paper (Series) various pp.
MM89^594.
11 Gehl, P. (1989) Choosing a Computerized Maintenance
Management System, SME Technical Paper (Series)
MS, various pp. MS89^341.
12 Johnsonbaugh, R. (1989) Discrete Mathematics,
Macmillan Publishing, Inc.
13 Mittra, S.S. (1991) Principles of Relational Database
Systems, Prentice Hall International, Inc.
14 Date, C.J. (1990) An Introduction to Database Systems,
Vol. I, Addison-Wesley Pub., Inc.