A fuel distribution knowledge-based decision support system

~ Pergamon Omega, Int. J. Mgmt Sci. Vol. 25, No. 2, pp. 225-234, 1997

© 1997 Elsevier Science Ltd. All rights reserved Printed in Great Britain

PII: S0305-0483(96)00059-X o3o5-0483/97 $17.0o + 0.00

A Fuel Distribution Knowledge-based Decision Support System

M NUSSBAUM M SEPULVEDA

Pontificia Universidad Cat61ica de Chile, Santiago, Chile

A COBIAN J GAETE E PARRA

Soluciones Expertas SA, Santiago, Chile

J CRUZ

COPEC, Santiago, Chile

(Received January 1996; accepted after revision November 1996)

This paper reports the experience of solving the distribution problem for the biggest fuel company in Chile. A planning, execution and control system for fuel distribution was developed. It employs a knowledge-based approach that utilizes a graphical user interface which mimics the mental model of the user. An automatic scheduler solves the Capacity Vehicle Routing Problem. The solution can be manually modified so verifying system consistency. The system is running throughout the country, 13 sites, having a positive impact on the three types of player. Plant managers have increased fleet efficiency and customers receive a higher quality service. Finally, the central administration obtains a report once a month from each of the plants that allows the strong and weak aspects of each site to be analyzed. © 1997 Elsevier Science Ltd

Key words---decision support system, fuel distribution, graphic user interface, Capacity Vehicle Routing Problem

1. INTRODUCTION

THE FUEL DISTRIBUTION problem [1-3] is an instance of the general dispatching problem. There is a set of transportation resources with capacities and capabilities that have to satisfy different transportation requirements. Solving the problem means to determine with which transportation asset and at what time each of the requirements will be satisfied. A typical requirement is composed by fuel type (e.g. gasoline, petroleum, kerosene), quan-

tity, destination (i.e. geographical position and receiving facilities like type of tanks available, parking space, autonomous fuel pump, metering devices, etc.), and required delivery time expressed in date and time of day.

All of the above determines the requirements that the dispatching system has to consider when finding a feasible and good solution. While 'feasible' implies satisfying all restrictions, 'good' involves reconciling a set of tangible and intangible criteria defined by the

225

226 Nussbaum et al.--Fuel Distribution

management, e.g. transportation efficiency and utilization, client satisfaction, etc.

This paper reports the experience of solving the distribution problem for the biggest fuel company in Chile, which has more than 50% of the market share. It has 13 distribution sites, all over the country, that deliver gas to more than 500 gas stations using around 200 trucks, not necessarily belonging to the company, that deliver more than 4 million cubic meters of gas a year. The project started with an agreement between the university and the company to evaluate their fuel distribution operation. There was concern for their operational efficiency, i.e. high cost of transportation, inadequate quality of service and delivery times that were badly accomplished.

A 1 year evaluation was performed, involving the three players. Meetings with customers were carried out by visiting gas stations. The commercial office and management were inter- viewed. Finally, an extensive knowledge acquisition process was performed with the most important player, the operations personnel. These were the people who had all the planning experience and the ones who required adequate support to improve their tasks.

Several problems were detected. There was a lack of management information to control the distribution operation. Almost no statistical information to support the management decision making was available. The scheduling activities were manually performed by the plant personnel and no time was !eft to register adequately statistical data. The only way to obtain information was by decoding the hand-written scheduling sheets, where the delivery programs were recorded, including all dynamic modifications done during the day by writing on top of it. It was therefore very difficult to analyze what really happened. No performance indices were defined, because no real data from where to obtain them were available, and no reliable information about the discrepancies between planned and executed deliveries existed.

Due to the magnitude of the problem, the commercial department and the plant management made several artificial divisions of the scheduling activity to facilitate the resolution. First, three independent scheduling problems were defined: gas station, industrial and home deliveries, assigning each a given pool of trucks,

with no sharing possibility among fleets. This categorization was a commercial classification according to the type of client, but was independent of the distribution problem. Sec- ond, for facilitating the scheduling activity, the day was divided into periods of 2 h, which represented the average turn time of a truck independent of its destination. Even though the average dispatching time for all the customers was 2 h, none had this turn time, and so it was impossible to accomplish delivery times, with unhappy customers due to non-fulfilment of scheduling commitments. All this splitting, a consequence of the human limitation of managing a huge volume of information, resulted therefore in bad resource utilization.

Discretional human intervention in the scheduling was observed. Since more than one person was responsible for scheduling orders, the quality and style of the delivery program depended on the human scheduler of the shift. Arbitrary decisions were sometimes performed supporting friendly customers, and other con- siderations not related to an efficient fuel distribution.

After 6 months of evaluation, a prototype of the distribution support system was started, and was completed at the end of the evaluation period [4]. It was installed in the main plant that supports one third of all the company's customers, close to Santiago de Chile [5]. Since the project started in 1990, for technological reasons, the implementation was in a DEC Station 5025 under UNIX, in C and MOTIF. Although a knowledge-based application was built, the experience of the group in other expert systems projects [6-10] led them to decide on conventional tools over expert system shells. The shells are too limited, they degrade performance when solving complex problems. They are generally not available in all platforms and, when an additional copy of the system is required, a runtime for execution is needed with the additional associated cost. Flexibility and performance were therefore chosen even though a greater software engineering effort was necessary.

The installation process was a main phase of the project that involved the same plant personnel. Scheduling with the electronic sheet introduced new requirements and features not possible before, and modifications on the planning heuristics. Almost no annoyance

Omega, Vol. 25, No. 2 227

among the users was perceived since the quality of their work immediately improved, even considering the instability of the software in the first stage. This installation process lasted for almost a year, until the software was stable and statistics were regularly obtained.

Due to the positive impact on all three players, it was decided to introduce it on all the company's plants, i.e. a massive deployment at 13 sites. It had, however, to be ported to a cheaper platform, PC under Windows. For t h e same reasons as in the initial system, traditional tools were used: Visual Basic for the interface, C for the scheduler and ACCESS for the database. It took another one and a half years to port the software, add new features, perform the modifications that satisfied the requirements of all the sites, and make it productive in all the plants.

The rest of this paper is organized as follows. Section 2 describes the fuel dispatching problem, Section 3 the interaction of the system with the different players, Section 4 the knowledge- based component and Section 5 the benefits obtained by the implementation. Several conclusions are found in Section 6. There are three Appendices: Appendix A describes the knowledge-base elements that allow knowledge updating; Appendix B describes briefly the Scheduling Heuristic and compares it to the known Capacity Vehicle Routing Problem (CVRP); and finally, Appendix C shows the learning heuristic.

2. T H E F U E L D I S P A T C H I N G P R O B L E M

Fuel dispatching is an activity that is completely performed at the plant. Three types of player, physically located in different parts of

the plant, Fig. 1:

Scheduler:

Dispatcher:

Controller:

can be distinguished, as illustrated in

Receives the data from the customers, orders to be planned, and schedules assigning trucks to orders. Receives a plan and executes it, modifying it when necessary according to the different imponderables that arise. Is located at the plant entrance and uses the plan to verify the truck's load and registers truck events.

The work that these three players carry out has not been changed with the introduction of the system. The system simply provides adequate tools for a smooth operation, as illustrated in Fig. 2. The customer calls the scheduler at the plant, to order fuel for the next day, with the corresponding temporal restric- tion. The scheduler assigns the requirement to a truck and informs the client of the expected arrival time of the truck determined by the system. The truck selection is heuristically obtained and uses a database where it stores the different delivery times for each of the customers (Section 4). This process is repeated until the end of the day, where the scheduler has a complete delivery program for the next day, which includes truck availability and load assignment.

The next day, the dispatcher, on a different machine, takes the schedule to be carried out, and dynamically adjusts it to the incoming data, i.e. truck delays or breakdown, emergency orders (stations that run out of gas), etc., using different heuristics (Section 4). At the plant entrance there is a VT 100 type of (dumb) terminal where all departure and arrival times of trucks are recorded. This information is retrieved automatically by the dispatching subsystem updating dynamically the schedule to

OME 25/2--D

--I S°he u'°r I

+ I Controller I

, . .I ,,--1 Dispatcher ]

Fig. 1. Players' interactions.


Scheduler

Controller

\ Bil l~_

Fig. 2. The fuel dispatching problem.

reflect reality as the schedule is executed. This allows the dispatcher to know the state of a truck, i.e. loading, on a trip to a customer, idle or breakdown, detecting delays on the loading phase and on the delivery. Remedial actions can therefore be immediately taken once a problem is detected.

3. SYSTEMS INTERACTION

A key issue in the deployment of a successful application is to make a detailed and rigorous analysis of all the systems that will interact with the application. Not only does the user have to be understood as a mental model that

corresponds with the system, but also the whole concern has to be examined through the information flow within the company.

The user interface was designed so as to emulate, in an intelligent way, what people performing the task were doing before. Ad- ditionally, the knowledge model was defined as closely as possible to the expert mental model. All this allowed a smooth transition from the traditional manual paperwork to a computer- supported environment. It is people with no computing background that solve the scheduling problem of the company, getting all the benefits of using such a system.

Figure 3 illustrates an abstract model of the

I Mimics the mental model o f the user

Interfaces with other Corporate Systems

Gathers expertise and evolves with changes

Fig. 3. Abstract model of the system.


system. It can be seen that the user interface is the systems skin. It is the interconnecting element between the user and the information system. In order to achieve the optimal bandwidth, it reflects the mental model of the user. Ideally, no change should be perceived by the user once the system is introduced, only things might now be as they always should have been. The system was conceived to mimic the original hand-written scheduling process in an intelligent way. The first step was to implement an improved electronic version of the manual scheduling sheet, Fig. 4. Using this graphical planning sheet the user can perform the same tasks as before in an efficient way. To avoid frustration, functionality is kept to what is required in order to avoid overloading the user.

An additional feature of the interface is to retrieve data in an easy way. At any moment, graphical reports (Fig. 4) and hard copies of the state of the schedule or dispatching information can be obtained. The first allows flexibility and facilitate visualization. The second makes the data available to those who have no direct access to the computing environment.

As shown in Fig. 3, the information system is the interconnecting element of the knowledge- based problem solver and all systems that interact with the application. It defines the flow of informat ion within the system and its data model.

The risk of implementing a stand alone system is that the data it uses become easily outdated since it is not possible to dynamically update the information required for scheduling. The same is true for the output. The generated schedule and the corresponding statistics may not adequately arrive on time for the people that require them.

The system was therefore designed to be capable of interacting with all necessary databases and information systems in the company. A strongly coupled integration with other systems allowed dynamic data interchange and information sharing, integrating the scheduling results into all corporate needs. For example, the control system immediately feeds information into accounting, billing and other corporate systems. All this integration was easily achieved due to the fact that our main data interfaces were initially ASCII files resident

didos Camiones C!ientes Opciones _Salir _Ayuda

NNNNNNNNNNINN ,

Fig. 4. Systems interface.


in UNIX, and once moved to PCs they were stored in an ACCESS database.

As shown in Fig. 2, the presented fuel dispatching decision support system has a distributed architecture. When any of the users introduces some modification or updates data, the result of this operation is displayed on each users terminal, with the benefit of constantly having up-to-date information. The scheduler has visual on-line information of what is actually happening, taking remedial action when necessary. Additionally all corresponding databases are updated to maintain systems integrity and consistency.

A key point of a decision support system is to assist management with a valid and updated picture of the company. A side benefit of storing dynamically all the scheduling activities is to always have data available on sales, customers, trucks and service, which is necessary to calculate the required statistics to visualize the company's performance. A set of statistics was defined, e.g. sales of the different products within a day, or a week, for the whole fleet, or per customer (Fig. 4), client commitment to routine deliveries, truck utilization (number of trips per day, capacity utilization, frequency of break-downs, number of clients per trip, etc.), difference between scheduled and real delivery times, etc.

4. A KNOWLEDGE-BASED DECISION SUPPORT SYSTEM

There is a need for expert decision making to find a good solution to the problem. A knowledge-based system was implemented because expertise was available in the plant that could be extracted and introduced into the system[l 1]. The resolution process is well understood by some people in the plant. This kind of system has the benefit of making any user act as an expert in fuel distribution scheduling. Knowledge is kept in the system, and thus company know how does not depend on a group of people and is accessible to all concerned. Additionally, whenever new knowledge is available, it is introduced into the knowledge base allowing system evolution by knowledge gathering (Appendix A).

Customer requirements trigger the scheduling process. This is a constraint satisfaction problem [12] where temporal restrictions, avail-

ability of resources, distribution requirements and commercial conditions have to be satisfied. Once the constraint satisfaction problem is solved, it can occur that none, one, or more solutions are possible. In this last case, an heuristic optimization is performed so as to use efficiently the transportation assets (Appendix B).

Rescheduling is also necessary when updating the plan through the control facility, when a truck delay occurs. When a breakdown of a truck happens, the whole schedule has to be reshuffled, trying to maintain the already promised delivery times. In some cases, this is not achievable, and new delivery times have to be proposed, suggesting the ones with the shortest travelling time.

Consistency checking is performed every time a modification is made so as to maintain a consistent database and to verify that the performed operation obeys the internal rules. The user can over-ride the system because it is sometimes the case, especially at the installation phase, that the systems knowledge base is incomplete and new rules have to be introduced. The user is allowed to manipulate orders manually by inserting, modifying and deleting them; to modify the plant configuration including fuel types; and to manipulate the fleet by inserting, modifying and deleting trucks. Orders can be moved from one truck to another, checks can be made on truck capacity, configuration, type of fuel being transported, metering accessories available, fuel pump, etc. Truck maintenance and out of service periods can be defined verifying that no machine usage is already scheduled within the interval. All interventions to the schedule are recorded for statistical purposes and to make each user responsible for his acts.

When inserting an order in the schedule, the shortest travelling time is suggested to the customer to increase fleet efficiency. Time required to deliver products varies considerably depending on whether it is done on weekdays or weekends, and the time of day (traffic during peak hours). The system learns the transportation times required in the scheduling process (Appendix C), thus enabling a dynamic adjust- ment of transportation duration to reflect real traffic changes. The overall transportation time is composed of the round-trip time from the plant to the customer facility, the loading time


at the plant and the unloading time at the fuel destination.

Time to load and unload is truck dependent. Bottom loading and unloading is considerably faster than operations on upper openings. Additionally, unloading time is customer dependent, i.e. the gas station setting may allow parallel off-loading when tanks are suitably located or, in the worse case, the truck has to be moved to reach the next tank. Since unloading requires the temporary closure of the gas station, unloading time depends on the time and day of the week, since the truck has to wait until all customers leave the site.

5. BENEFITS OF THE KNOWLEDGE BASED DECISION SUPPORT SYSTEM

Atl of the players have perceived the system's introduction in a positive manner. Before the introduction of the system, the plant managers dedicated their time simply to operational tasks. Now these jobs are left to the system, leaving time for customer support and service management. Plant efficiency, truck operation and driver satisfaction are therefore increased. Optimizing routes reduces the fleet while minimizing the truck usage. The fleet has been reduced by around 40%, supporting the standardization of truck models, which was difficult before since a wide variety of tanks eased the scheduling. Customer calls were almost eliminated. Due to truck delays, their calls were formerly frequent since the station manager had to wait for the truck reception as he pays for the load.

The main impact for customers has been on time delivery, which allows them to schedule adequately the fuel reception. A customer's main problems were to close the station, so stopping selling, and then to wait hours for the arrival of the truck which made him a slave of the station. He now has time to do his job, i.e. looking after his business and forgetting about the gas delivery, which is now automatic for him, as it always should have been.

Finally, the biggest impact has been from a commercial point of view. The distribution problem has been shifted to a distribution product. The customer now selects one of three options, each with a different cost. He can fix truck delivery to a given day and time of the week (routine deliveries), he can order from one

day to the other, and finally, he can have emergency delivery, i.e. within hours. A second major impact for the company has been to have a decision support system that runs throughout the whole country. Once a month each plant submits a report to the deputy director that contains the statistics obtained by the system. This is a standard mechanism to analyze and compare each of the plant's throughput observing the strong and weak aspects of each site.

6. CONCLUSIONS

A planning, execution and control system for fuel distribution was developed: It employs a knowledge-based approach which utilizes a graphical user interface that mimics the mental model of the user. Automatic scheduling delivers a program that can be manually modi f ied so verifying system consistency. Dispatch monitoring permits the maintenance of an updated record that allows accurate and efficient control, enabling the detection and resolution of failures and delays. A learning component allows the maintenance of precise dispatching times which allows a high level of accuracy in delivery. Finally, the availability of high quality historical information, with its corresponding statistical analysis, improves operations and supports the management decision making process.

There are two main differences from a conventional decision support system. First, the system not only stores and retrieves the data regarding the action of the trucks and the customer demands, but also schedules and reschedules them. Second, the automatic learning component yields accurate estimates of the different possible travelling times within the city, which allows a better use of the fleet to be made. Although these two components caused the system to have a longer development time, compared to a conventional one, now that the system has been used for almost 5 years, and even moved to a cheaper platform, it can be concluded that the support it requires is the same as for any information system. No manual over-rides are required, and if a system breakdown occurs, the dynamic back-up of data allows restoration to the last known state.

There are several factors that have helped to secure a successful application, the main issue


being the knowledge acquisition process. It is necessary to get involved in the problem area by talking to domain experts, understanding all direct and related problems, visiting the plant, getting feedback from the system users and above all, to be very open minded to new alternatives and suggestions.

For flawless distribution, there are still some steps to go. Customer orders, checking their status and the modification, are now being handled manually. A change to the automatic electronic system would connect the customer directly to the distribution system giving access to all the data he could require. He would, however, lose the direct human interaction with the company, which has been the major reason for not doing this so far.

In the near future all plants will be on-line. This will permit the central administration to have dynamic access to the statistics stored in each of the plant's system. This change will allow the move from a pulling type of management, i.e. once a month feedback is given directly from the authority, to a pushing one, where the plants are given instructions on demand.

This is a generic tool that serves the needs of companies where distribution is a critical and strategic problem. A similar system is now beginning to be used by the major Chilean natural gas distributor. Other immediate applications are ready mix transport, and supermar- ket distribution of big retailers.

APPENDIX A

A1. KNOWLEDGE-BASE ELEMENTS THAT ALLOW KNOWLEDGE UPDATING

For each truck the following data elements are recorded in each trip.

1. Loading start time 2. Loading finish time 3. Time leaving the plant 4. Time returning to the plant

For each customer the following data elements are recorded at each delivery.

1. Arrival time 2. Unloading start time 3, Unloading finish time 4. Leaving time

From these records, the system infers the following data used for updating the parameters required in the heuristics and also shown in the reports.

For each truck:

1. Loading speed 2. Number of turns done in a day For each customer:

1. Unloading speed 2. Waiting time 3. Number of trips done in a period

For each visited customer the time required from and to the plant, or from and to another customer, is registered (Appendix C).

APPENDIX B

B1. SCHEDULING HEURISTIC

The problem solved is mainly a Capacity Vehicle Routing Problem (CVRP)[3, 13-15]. A set of clients has to be visited by a given vehicle that belongs to a set of identical resources, initially localized in a central depot. Each vehicle takes a given route that begins and ends at the depot, visiting a set of clients without exceeding its load capacity. The problem objective is to find a set of routes for the vehicles which minimizes the distance travelled for all the vehicles. The following modifications were added to the standard problem formulation, increasing the complexity of the CVRP, restricting the use of known heuristics.

(i) It is a heterogeneous fleet, i.e. not all trucks have the same capacity, and each tank is separated into a set of compart- ments.

(ii)The vehicle is available 24 h a day, or one, or more, predefined time windows.

(iii) Customer demands are for a set of fuels (for example 91, 97, diesel, etc.) which does no t necessarily complete the truck capacity.

(iv) Customers have time restrictions for receiving a vehicle, defining one or more time intervals in which the truck can go to the gas station.

(v) Set up times, i.e. loading, unloading and waiting times are customer, truck and load dependent.

Omega, 1Iot. 25, No. 2 233

(vi) There is one depot and it has a limited amount of different types of fuel.

(vii) Trucks may be preloaded the previous • day.

Additionally it has to be considered that a load balance in the fleet usage has to be achieved since it is necessary that all trucks, on average, complete the same amount of work since the drivers are paid for the trips they make, considering the distance travelled. Also, time gaps f o r a t ruck , within a predefined time window, have to be avoided since idle resources diminish the fleet efficiency.

Global search is used [11, 16-18], where the solution is incrementally built, i.e. in each iteration a new assignment of a truck to a customer is determined. Each time a customer is visited, visiting others that are close by is attempted. Additionally, each time a truck is assigned, the capacity is employed to its maximum, minimizing the distance travelled. A mixed algorithm is used, that on one side partitions the orders so to assign them to a truck, and on the other, optimal routes are defined to which trucks are allocated.

When a schedule is established, two independent heuristics are run, selecting the solution that transports the most number of tons, minimizing the transportation costs. The first heuristic schedules trucks, i.e. an iterative loop selects the different trucks planning a whole day at once. The truck selection is performed on the truck's relative cost (ratio between transportation cost per kilometre and the trucks' capacity) and its priority. Customers are assigned considering how close they are and their time window restrictions. The second heuristic schedules orders based on their time requirements, fuel needs and geographical position assigning them to a given truck, based on the distance travelled, left capacity, relative cost and distance from the last visited customer.

APPENDIX C

C1. LEARNING HEURISTIC

A database stores the time a truck requires for travelling from one customer to another, from the plant to a customer and f rom a customer to the plant.

The city is divided geographically, the week is partitioned into weekdays and holidays, and each type of day distributed in six periods of time, e.g. f rom 7 A.M. to 10 A.M., I0 A.M. to 4 P.M., etc. The control subsystem keeps track of the actual duration of deliveries, adjusting the length of the trip when a permanent difference is detected. It updates the duration by keeping an average of the last n trips to a given geographic locat ion for the corresponding type of day and period of time. The reactivity parameter, n, can be adjusted in order to be more or less sensitive to changes. When n is small, isolated events, e.g. car accidents, can have a strong impact over duration and thus give a bad estimate of a future trip duration. A large n, on the other hand, ensures high inertia and reflects changes only very slowly, e.g. road construction. This parameter has to be empiri- cally adjusted.

This temporal feedback allows accurate time estimation, increasing the customers' confidence on the system, and augments the fleet's efficiency.

REFERENCES

1. Basnet, C., Foulds, L. and Igbaria, M., Fleet Manager: a microcomputer-based decision support system for vehicle routing. Decision Support Systems, 1996, 16, 195-207.

2. Bodin, L., Twenty years of routing and scheduling. Operations Research, 1990, 38, 571-579.

3. Laporte, G. and Osman, I. H., Routing problems: a bibliography. Ann. Operational Research, 1995, 61, 227-262.

4. Torregrosa, S., Prototipo de sistema experto para Ia distribuci6n de combustibles de Copec. Technical report, Departamento de Ciencia de la Computaci6n, Escuela de Ingenieria, Pontificia Universidad Cat61ica de Chile, 1991.

5. Ilabaca, R., Interfaces gr/tficas para sistemas expertos: Una metodologia de desarrollo. Technical report, Departamento de Ciencia de la Computaci6n, Escuela de Ingenieria, Pontificia Universidad Cat61ica de Chile, 1992.

6. Nussbaum, M. and Molina, O., Intelligent manual: an aid for process engineering. Engineering Applications of Artificial Intelligence, 1992, 5, 43-49.

7. Nussbaum, M. and Parra, E., A production scheduling system. ORSA Journal on Computing, 1993, 5, 168-181.

8. Parra, E. and Nussbaum, M., Sistema experto para la planificaci6n de cursos y asignaci6n de salas. Proceed- ings XIV Taller de Ingenieria de Sistemas, Santiago, Chile, July 1991.

9. Sepfilveda, M., Nussbaum, M. and Levy, P., Visiplan: a knowledge based modeling tool. lEE Proceedings on Control Theory and Applications, 1996, 143, 73-84.

10. Vinet, A., Parra, E. and Nussbaum, M., Un sistema

234 Nussbaum et al.--Fuel DistributDn

basado en conocimiento pars la planificacion de tripulaciones. Proceedings XVl l Conferencia Lati- noamerieana de Informdttica, PANEL "91, Caracas, Venezuela, July 1991.

11. Noronha, S. J. and Sarma, V. V. S., Knowledge-based approaches for scheduling problems: a survey. 1EEE Transactions on Knowledge and Data Engineering, 1991, 3(2).

12. Rich, E. and Knight, K., Artificial Intelligence. McGraw-Hill, New York, 1991.

13. Li, Ch., Simchi-Levi, D. and Desrochers, M., On the distance constrained vehicle routing problem. Oper- ations Research, 1992, 40, 790-799.

14. Fisher, M., Optimal solution of vehicle routing problems using minimum k-trees. Operations Research, 1994, 42, 626-642.

15. Reinelt, G., Fast heuristics for large geometric travelling salesman problems. ORSA Journal on Computing, 1992, 3, 206-217.

16. Morton, T. and Pentico, D., Heuristic Scheduling Systems. Wiley, New York, 1993.

17. Pinedo, M., Scheduling: Theory, Algorithms and Systems. Prentice Hall, Englewood Cliffs, NJ, 1995.

18. Zanakis, H., Evans, J. R. and Vazacopoulos, A. A., Heuristic methods and applications: a categorized survey. European Journal of Operational Research, 1989, 43, 88-I 10.

ADDRESS FOR CORRESPONDENCE: Dr M Nussbaum, Depart- ment of Computer Science (143), School of Engineering, Pontificia Universidad Catolica de Chile, Casilla 306, Santiago 22, Chile.

Documents

A fuel distribution knowledge-based decision support system