A distributed constraint-based scheduler

PII:

ELSEVIER

ArG$cial Indigence in Engineering11 (1997) 91-105 0 1997 Elsevier Science Ltd. All rights reserved Printed in Great Britain 0954-1810/97/$17.00

550954(96)00002-7

A distributed constraint-based scheduler E. Lamma, P. Mello & M. Milan0 DEIS Viale Risorgimento, 2, I-40136 Bologna, Italy (Received

11 January

1995; revised version

received

13 June 1995; accepted

20 December

1995)

This paper presents the design and implementation of a distributed advisory system which helps different human experts in the management and control of traffic within railway stations and along railway branches. Our approach allows the management of a whole railway line in a modular, expandable and scalable way. The scheduling of trains along a railway line is performed by several modules each one controlling a certain number of resources. These modules solve the scheduling of trains by interacting and communicating with each other. Each module has to deal with temporal constraints, priority between trains and constraints due to the structure of the station and railway branches. Our approach is based on the constraint logic programming (CLP) paradigm for solving the constraints involved in the problem. Therefore, this paper shows the versatility and adequacy of the CLP approach for the problems of this type. (0 1997 Elsevier Science Ltd. All rights reserved. Key words: railway traffic control, logic programming, distribution

scheduling,

temporal

reasoning,

constraint

only contains the arrival and departure times for every train, but also the resources that should be assigned to the train itself in every station it passes through. In Italy, railway traffic is regulated by human experts. Inside big railway stations there is a human expert (i.e. Station Master-SM) who has to assign resources (i.e. routes and tracks within the station) to trains. Small stations, instead, are managed together with railway branches by another human expert (i.e. Central Operative Manager-COM) whose task is to assign resources of the stations and of the branches to trains, and to sequence trains in order to prevent conflicts and queuing along a branch. If the railway traffic respects the time-table, then human experts’ decisions are already set. Anyway, a lot of events could delay trains, and therefore make the time-table information obsolete. Let us consider, for instance, faults in some station device or, again, a delayed train that requires a resource allocated by the time-table to another train. In these cases, human experts have to modify the time-table assignments of resources according to the station’s degrees of freedom (usually, stations are over-dimensioned so that, on average, the number of resources engaged are less than the number of resources available). When modifying the time-table assignments, the SM and COM have to deal with a very complex problem that involves:

1 INTRODUCTION the last decade, every field of artificial intelligence has exploited a great effort in order to research and develop intelligent support systems. These systems support rather than replace human expertise and knowledge. In particular, these new techniques are devoted to applications that are characterized by vast amounts of data and constraints, wide search spaces, optimization requirements and rapidity in taking decisions. One of the fields that involve all these requirements is the control and management of transport. The efficiency of transport is of primary importance for a prosperous economy. In particular, railway traffic control and management are very complex and important tasks to be considered in a modern society. They do not only involve technical but also social and psychological aspects. Trains are a suitable tool to move a great number of people and goods. They always reach a good trade-off between cost and rapidity. Anyway, trains are not always regulated in the best way and this problem leads to delays and troubles. In this paper, we concentrate our attention on the railway traffic regulation and in particular on the development of an intelligent support system that solves this task. Railway traffic within stations and along the branches is regulated by a time-table which would assure, when respected, the regularity and optimization of train movements. The time-table not In

l

91

a great amount

of data and constraints

that not

92

l

l

E. Lamma, P. Mello, M. Milan0

only involve the knowledge of all the possible and feasible assignments of resources to trains, but also the consequences of these assignments on the subsequent trains; the capability of choosing the best solution among the feasible ones, according to the goals of optimizing the railway traffic and preserving the safety of the service itself; taking decisions in a very short time.

At the state of the art, SM and COM are not supported by any intelligent automatic advisory system for their activities. Therefore, their decisions on resource allocation to trains are sometimes quite hurried and not precise. This paper presents the design and the implementation of an intelligent advisory system that helps human experts in their task. Railway traffic management concerns the optimal allocation of scarce resources to trains over a period of time. Therefore railway traffic management can be seen as a .scheduling problem. A scheduhng problem can be defined as fitting jobs to available and limited (in terms of capacity) resources in a restricted time interval. Each job consists of several tasks constrained by temporal relations (e.g. precedence). The system presented here is part of a wider project whose main aim is to intensively apply artificial intelligence techniques to railway traffic control.’ The project leads to a four level architecture: the lower level consists of the set of logic circuits controlling station devices (e.g. signals, switches, tracks and level crossings), and is called the Automatic Train Protection (ATP) system. The ATP system avoids physical conflict among trains. Therefore, SM and COM has to route trains and manage only emergency situations. The second level, Station Master Assistant (SMA), determines the so-called route feasibility. In particular, the SMA determines whether a particular route can be safely covered by a train. In fact, only if there are no faults or other trains on it can a resource be assigned to a train. These two levels can be considered as the ‘static’ part of the whole project. This part of the project is described in Ref. 2. The third and fourth levels constitute the ‘dynamic’ part of the system because they have to deal with temporal knowledge about the present (real) and the future (supposed) state of the station and the branches. The third level solves the scheduling of trains within the railway station and on the railway branches. The scheduling system can itself be divided into two communicating modules: the temporal manager which is a temporal reasoner and assures the maintenance of the temporal knowledge of the problem; the scheduler which assigns station and branches resources to trains according to the temporal manager information. The higher level of the project concerns the communication manager. In order to manage a railway line we

adopted a distributed approach. In fact, we divided the line into identical base modules. Every module manages a station and part of the railway branches. These modules have to communicate in order to exchange information about the scheduling of trains, and to update information according to new situations of traffic. In this paper, we describe the third and fourth parts in detail which deal with the train scheduling problem, while the first two levels are described in Ref. 1. The train scheduling problem has interested many researchers3.4.5 who have faced it with the conventional operational research techniques. However, the most recent literature has shown that an artificial intelligence approach can be adopted for optimizing traffic control (see Refs 6, 7, 8, 9, 10, 11, 12). Most of these works are based on constraint logic programming (CLP).” CLP is a recent programming technique. It was introduced in 1987 by J. Jaffar and J. L. Lassez14 as a general scheme. CLP combines the advantages of logic programming (LP) with specialized and efficient constraint solving methods. So, problems like scheduling, planning, combinatorial research and, in general, all the constraint satisfaction problems (CSP) can be suitably solved by using constraint logic programming techniques. This paper is organized as follows. In section 2, we first introduce the problem domain and the constraints involved. In section 3, we give a brief overview of the CLP techniques and applications. Section 4 is devoted to the architecture of the distributed system. As already said, facing the railway line we divided it into different modules. Therefore, we first present how this module is composed, then we present the scheduling system, and at the end we show how these modules communicate and which kind of information they exchange. In particular the scheduling system description is articulated in three points: data structures scheduling manager 0 temporal manager. l

l

At the end, we will present the management of faults and unexpected events. We will show how a CLP approach to this kind of problem makes the system not only a suitable real-time support system which reacts to unexpected troubles, but also an intelligent scheduler which avoids routing a train to an obstructed way. In section 5, we present the implementation by using constraint logic programming, the extensions we developed for handling the constraint solving and the distributed communication and some experimental results. Conclusions and future works follow.

2 THE PROBLEM

The problem

DOMAIN

we have to face concerns the regulation of a railway line which is composed of a number of big and

93

A distributed constraint-based scheduler

Stat

Stat3

1 _

-

-

A?5

Stat6

ITi

r

Fig.1. A railway line small stations and branches. Two stations can be connected by one, two or four branches. For the sake of clarity, we consider only stations connected by a couple of branches. In Fig. 1 a very simple railway line is depicted. Every pair of stations is connected by two arrow-signed branches. The arrows show which are the legal directions for trains. Usually, trains travel on the left branch which is called in fact, the legal direction. Anyway, because of faults or troubles, trains can travel in the illegal direction (i.e. the right one) provided that no train is travelling on the same branch on the other direction. Big railway stations are regulated by the station master (SM) whose task is to assign resources of the station itself to trains. On the other hand, small stations are controlled, together with railway branches, by the central operative manager (COM) whose task is to assign resources of small stations and of the branches to trains. Therefore, we can consider two distinct problems: the regulation of traffic within the station and the management of the railway branches. These problems are very different, even if they are characterized by common features. In the next two sections, we will describe the two problems paying attention to the common and distinguishing peculiarities. 2.1 Railway station management Railway station management is much more complicated than the railway branches regulation. In a station we can find entrance and departure points from which trains arrive and leave the station. These resources cannot be changed because they depend on the origin, the destination of the train and on the branch on which the train is travelling. On the other hand, when a train is going to enter a station, the SM has to decide where to route the train itself since there are alternatives resources for a train. The time-table, which perfectly regulates the railway traffic, contains not only the arrival and departure times of the train but also the time-table track on which the train should stop. As already said there are lots of events which can alter the time-table information. Therefore, in these cases the SM has to schedule resources for trains in order to respect the following principles: l

assure the safety of the service in order to preserve travellers and personnel;

l l

minimize train delays; respecting as far as possible, the time-table information.

The first goal to reach is the most important because it has to be definitively respected. The ATP system, mentioned in the previous section, helps the expert to avoid unsure situations. It avoids physical conflicts among trains by controlling the station’s switches, signals, tracks and level crossings. ATP has to be designed according to the station topology and to the National Railways Authority guidelines. Anyway, there are emergency situations which should be managed directly by the human expert under his own responsibility. Concerning the second requirement, within a railway station a train can be delayed at the entrance point or on the track. In the first case, the reasons for the delay can be, for example, that there is no resource available for the train itself. On the other hand, a train can be delayed on the track (i.e. it has to stop for a time longer than that required by the time-table) because, for instance, it has to wait for a faster train which has to overtake the first. Along the railway branches a train can not pass another. So the previous station has to ensure that trains leave the station in the correct order to avoid possible ‘conflicts’ (i.e. queuing) along the railway branches. The third goal which has to be achieved concerns keeping to the time-table information, in particular the track assigned to a train by the time-table. Even if there is another track available for the train, it can be better, in some cases, to delay the train and route it on the timetable track in order to minimize the travellers’ uneasiness. According to the above mentioned goals, the human expert has to face two kinds of problem. The first problem concerns the so-called route feasibility which is the safe routing of trains as they enter or leave the station. A route is composed of a number of low level resources (i.e. switches, signals, tracks and level crossings). Before the assignment of a route to a train, the SM has to check that all these resources are free and available, that is the route is feasible. To determine route feasibility, a system called station master assistant (SMA) has been developed.’ The second kind of problem for the SM concerns the allocation of resources to trains. When a train is going to enter the station it is announced. The SM then knows

E. Lamma, P. Mello, M. Milan0

94

the number of the train and its delay, and all the information on the train itself reported in the time-table (see Section 4.2.1). The SM has to assign resources (i.e. an arrival route, a track for stopping and a departure route) to the train over a period of time. This period can be that required by the train or a delayed one. The SM’s choice has to be taken according to some principles: l

l

l

l

Minimizing train delays: as already said, within the station a train can be delayed at the entrance point or on the track because, for instance the time-table resources for the train are engaged. Anyway, if these resources will be engaged for a long temporal interval the human expert has to change the theoretical assignment. Avoid conflicts and interference: this is also a very important goal to achieve. Conflicts are prevented not only by the SM but also by a low level system (i.e. ATP) which avoids train crashes. Anyway, the SM has to manage emergency situations. With ‘conflicts’ we mean train crashes and all the unsafe situations which can threaten travellers and personnel safety. ‘Interference’ means more complex situations. The assignment of resources to a train can interfere with the assignment to later and higher priority trains and the interference can be forward propagated. Therefore, interferences cause delays and troubles to travellers and they have to be avoided as well as conflicts. Respecting priorities among trains: trains can be characterized by the different distances covered (e.g. international, national, regional), by the quality of the services (e.g. dining cars, sleeping cars) and the ticket price. Human experts should give precedence to the most important trains (e.g. a passenger train should have precedence over goods trains) in order to minimize delays and avoid, whenever possible, changing the time-table track and the queuing of trains. Anyway, the priorities of trains can be changed dynamically according to their delay. In fact, for instance, there are high speed trains whose ticket price is overcharged by a supplement. This surcharge has to be refunded to travellers if the delay exceeds a minimum fixed time. Respecting the time-table information: the timetable accurately regulates the railway traffic. It contains information such as train numbers, their arrival and departure time, their priority, the track on which they should stop and so on. However there are frequent unexpected events which alter the time-table, and the SM has to handle such situations in the best way. He has to respect, as far as possible, for example, the time-table track. In the time-table there is also another very important parameter. It concerns waiting for a connection. In

0

this situation a train has to wait for the travellers of another train. The SM, according to the delay of the second train, has to decide if to respect the connection or not. Ordering the train departure in order to prevent queuing on the branches: the highest speed of a train is limited according to its priority. It is very important that the departure is regulated so that faster trains leave the station before slower ones. As already said, along the railway branches there is no possibility to overtake another train. By ordering the departure of trains, the SM prevents queuing. Usually, these situations are managed by the timetable: they are called precedence. One train has to wait for a faster one and give it precedence for the next branch. Anyway, the slower train has to wait for the second only if it travels without delay. The SM has to choose whether to respect the precedence or not. This is a very important point because it represents liaison between the railway station management and the control of the railway branches.

The human expert has to find a compromise between these principles and his task requires much skill and experience. He has to handle temporal information about the present (real), the future (supposed) state of the station, and constraints due to the structure of the station, the time-table and priorities between trains (see section 2.3). These human experts often suffer from information overload and, moreover, scheduling has to be produced in a limited time (less than 1 or 2 min). Therefore, SMs always take hurried and not precise decisions. 2.2 The railway branch management The railway branch management and control are simpler that in the previous case. In fact, at first glance, the problem can be simplified as a problem of sequencing trains in a sort of pipe. A branch is composed of a number of adjoining blocks. On each block only one train at a time can travel and trains cannot pass one another. The human expert who manages the branches (COM) has to forecast possible queuing of trains along a branch (i.e. a faster train which is travelling behind a slower one) and communicate it to the previous station. Otherwise, this situation could introduce a delay for the first train. In our analysis, we consider double branch railways (one branch for each direction). However, there are particular situations (not discussed in this paper) in which a fault along a railway branch leads to routing trains on a single branch in both directions. In that case, the COM has to manage a more complex situation. Moreover, the COM has to deal with constraints due to the branch structure (simpler than the station structure), but also with priority and temporal constraints.

95

A distributed constraint-based scheduler ,Blk2

Blk4

Blkl

z 2

,'

23 22 21

\ '\ ‘\

3

Blkla Blk2a

4

Blk3a

Blk3

Blk4a

Fig. 2. Topology of a sample station.

2.3 The constraints involved The fact that not all combinations of assignments of resources to trains are compatible and acceptable is modelled by constraints. Figure 2 shows the topology of a small station and the adjoining branches. In the station we can find entrance and departure points (characterized by numbers 1, 2, 3, 4), tracks (numbers 19, 20, 21, 22 and 23) and routes that connect a switch with a track (for example there is a route called ~1-21 leading to track 21 from point 1). We now describe the constraints involved in the problem which can be divided into three groups: compatibility, priority and interference avoidance constraints. 2.3.1 Compatibility constraints Compatibility constraints represent the topological aspect in a station or along the branches. Two resources are incompatible if they cannot be assigned to two trains at the same time. Of course every resource is selfincompatible. This means that the same resource cannot be assigned to two or more trains in the same time. Looking at the station topology we can find couples of incompatible routes. There are three reasons for incompatibility: l

l

l

a common initial point (e.g. route ~1-21 and Pl_22); a common track-segment (e.g. route ~1-20 and P2_20; a crossing point along the routes (e.g. route ~1-19 and ~2-20).

The corresponding constraints for the branches are simpler. In fact, we can divide a branch into several blocks (Blkl, Blk2, Blkla, and so on), and constrain a block to be occupied by no more than one train at a time. Precedence between trains should be solved in the previous station. Compatibility constraints should use some form of temporal knowledge. In fact, two trains cannot cover two incompatible resources in the same temporal interval or in overlapping temporal intervals. 2.3.2 Priority constraints Priority constraints lead to preference for configurations of assignments when the most ‘important’ trains are privileged (e.g. a passenger train over a goods train). These constraints are common to both problems (stations and branches). As already presented in section 2, trains can be characterized by the different distances

covered, by the quality of services and the ticket price. Human experts should give precedence to the most important trains in order to minimize train delays and avoid, whenever possible, changing the time-table track and the queuing of trains. 2.3.3 Interference avoidance constraints The last subclass of constraints is the most complex, and concerns the possible interference to the subsequent trains caused in a station by the assignment of a route to a train. For instance, assume that a train Trl with low priority is arriving at the station in Fig. 2. Assume also that route ~1-20 is assigned to Trl which stops on the track 20 for 10min. During this temporal interval a more important train Tr2 is going to arrive from point number 4. The departure direction of Tr2 (point number 2) does not allow the assignment to Tr2 to tracks number 21, 22 and 23 because the train will not find a suitable departure route. Therefore the only track which can be assigned to Tr2 is track 19. Suppose track 19 is engaged. The assignment of Trl interferes with the assignment of Tr2 which has to be delayed. A more ‘intelligent’ solution would assign the required track to Tr2 and delay the less important train Trl at the entrance point. Anyway, the train waiting outside the station could prevent the entrance of subsequent trains travelling on the same railway branch. Thus, the proposed solution could be adopted if the delay of Trl will not cause a further delay for a subsequent train Tr3 more important than Tr2. Therefore, we have to reach a compromise between delays and priorities in order to find the optimum scheduling and minimize troubles.

3 THE CLP APPROACH The overall system has been implemented by using constraint logic programming (CLP).14,‘5 In the following, we briefly survey the main features of CLP and some applications in the field of artificial intelligence. 3.1 Constraint logic programming: an overview CLP is a class of programming languages combining the advantages of logic programming (LP)16,17 and the efficiency of constraint solving. CLP ‘inherits’ from LP the operational and declarative semantics which lead to simple, elegant and natural programs. However, CLP

96

E. Lamma, P. Mello, M. Milan0

overcomes both the disadvantages of LP by enhancing LP with constraint solving techniques. These disadvantages concern mainly the inefficiency of typical LP searching techniques that lead to a combinatorial explosion when the dimension of the program becomes great. The second limitation of LP concerns the syntactic unification. In LP, terms are uninterpreted structures. Two terms can be considered unifiable if they are syntactically, and not semantically, identical. CLP solves these limitations, and has hence two complementary lines of descent corresponding to the two limitations of LP. The first concerns the CLP scheme which allows working in pre-defined domains such as real, integer, rational, boolean or finite domains. Working in a pre-dehned domain ensures the programmer uses concepts that ar’eclose to the domain of discourse. Associated with each domain are primitive operations and relations (constraints) on the domain itself. The second field of CLP concerns the so-called consistency techniques.13 They can be defined as intelligent search techniques. These techniques are based on the a-priori pruning of the search space by propagating constraints. A-priori pruning consists of reducing the search space of the problem by preventing a priori failures. Each variable is associated with a domain, i.e. a set of feasible values for the variable itself. When a constraint involving this variable is solved, the associated domain is consequently reduced by eliminating the values incompatible with the constraint. Therefore, the possible values for the variable are reduced a priori, limiting the search space of the problem. Our approach to the train scheduling problem is based on CLP in finite domains. Working on finite domains we can associate with every resource of the station and of the branches a variable whose domain represents temporal information of the resource itself. The propagation of temporal and incompatibility constraints on these domains allows exploitation of efficient searching techniques. 3.2 Applications of CLP In this section, we will give an overview of real-life CLP applications. Recent literature’3’18 demonstrates that the CLP approach is very useful in order to solve constraint satisfaction problems (CSPs). A CSP can be defined in the following way: assume the existence of a set of variables (X1, X2,. . . , X,) whose values range in finite domains (O,, Dz, . . . , D,), and a set of constraints. A constraint c (Xii, Xi2,. . , Xik) on k variables is a subset of the Cartesian product Dil x Di2 x . . . x Dik that represents which values of the variables are compatible with each other. A solution of a CSP is an assignment of values to all variables, which satisfies all the constraints. The class of constraint satisfaction problems involves different application areas such as planning, scheduling, resource allocation, assignment, placement and logistics. They are characterized by common features. For instance, there are no general and efficient methods to

solve them as they often belong to the NP-complete class of problem. Therefore, different strategies and heuristics have been tested. The classical language solution to these problems usually take very long to develop, are expensive to maintain and difficult to modify. Decision support systems are required to solve the CSPs. These systems support rather than replace human capability and skills. The systems have to cooperate with users instead of taking independent decisions, and user-friendly interfaces and explanation tools are needed. Moreover, these systems should be sensitive to real-time changes such as faults and unexpected events. The requirements of this class of applications are quickly changing and programs should be flexible enough to adapt to these changes rapidly. Moreover, the changes should be incremental. CLP is an effective and flexible tool that meets these requirements. CLP adopts a general step by step methodology to solve CPSs. In particular, we can identify the following steps: l

l

l

l

model the problem: find out the constraint, heuristics, strategies and rules; constrain the problem (e.g. with precedence and disjunctive constraint); solve the problem using propagation of constraint and backtracking; evaluate the solution.

Quite recently, an increasing number of CLP tools have been developed. The most important are CHIP,‘9’20 CLP (R),21 Prolog III,22 ECLiPSe23 and ILOG. These tools contain constraint solvers on specified domains. The most common constraint solvers are built on: rational and real numbers based mainly on simplex and gaussian elimination; boolean algebra based on variable elimination on a graph representation; finite domains based on local consistency techniques and bound propagation. Our application has been developed by using a very flexible tool (SEPIA,25 Standard ECRC Prolog integrating advanced applications). SEPIA is a logic programming language that supplies flexible primitives for developing constraint logic programming extensions. The first extension concerns the possibility to treat meta-term data-type. Meta-terms are variables with an associated term. They can be interpreted in many different ways: for instance a variable with an attribute or a variable whose value is known only partially. The second extension is coroutining. This mechanism allows the user to delay the execution of a predicate until a user-defined condition is satisfied. In this way a programmer can alter the control flow of the program by introducing constraints which actively drive the computation.

91

A distributed constraint-based scheduler Moreover, SEPIA allows the development of C language interfaces. Therefore, it is a suitable tool for implementing high-level communication primitives. In section 5, we will show how these mechanisms are exploited in the prototype we developed.

4 THE ARCHITECTURE SYSTEM

OF THE DISTRIBUTED

The management of a railway line demands coordination and communication among different experts in order to schedule trains within each railway station. In fact, the decisions taken in a station can interfere with the railway traffic within a neighbouring station. Therefore, our system has to reflect this kind of organization. The basic idea is to divide the railway line into identical modules, each one controlling a station and part of the railway branches. These modules have to cooperate and communicate in order to exchange information and regulate the traffic together. In this section, we first present how a module is composed and which resources it controls. Then, we show the architecture of a single module. In particular, we present the scheduling algorithm and the temporal manager which maintains temporal information. Finally, we will show the communication mechanisms and information that is exchanged between modules. 4.1 The base module We face a railway line as a sequence of communicating modules St 1, St2, , Stn. Every station is regulated by a station manager. For the branches, instead we have lots of alternatives in order to build these modules. The first distinction to consider for the railway branches regulation is the one between a centralized module or a distributed one. A centralized module should manage the whole railway line by communicating with the station managers. Therefore, station managers should assign station resources to trains and communicate with the global manager for the line in order to pass the control for departure and entrance trains. The advantage of having a centralized module is to provide global control. In fact, the decision for a branch can be taken according to the conditions of traffic on other branches and stations. For example, if a station is overloaded by heavy traffic because of some faults, the global controller decides to send no more I’OmZ:;E1on

trains to the congested station. So having a global point of view allows one to optimize the whole railway traffic. On the other hand, a centralized controller can be overloaded by the management of a great number of resources. It becomes a bottleneck when the communication traffic is very heavy. Therefore, it is the best solution in terms of global management but bottleneck situations can occur in conditions of heavy traffic. These situations are the most complex, and in these cases human experts really need a system which helps them to take the best decision. Moreover, it is not fault tolerant. In fact, if the communication manager is out of order, all the stations are isolated with drawbacks on the whole system. This solution is depicted in Fig. 3. According to the requirements of the project, a number of factors influenced our decision to adopt a distributed system. If fact, all local solutions are not so efficient from the global control point of view, but are not overloaded by a great number of resources to manage as is the centralized module. In fact, the distributed approach is scalable. Moreover, a local solution is fault tolerant. A fault by the communication manager isolates only a few stations and it does not involve the whole railway line. Another advantage of a local solution is that it is suitable for the real situation. In fact, our system has to support human experts. Each of these experts needs an advisory system in order to manage his ‘control field’ resources. A centralized module should be given to a central higher level expert who does not exist. Once the distributed approach has been chosen, the second choice is to decide whether to build a special purpose system for the branches or to assign the railway branch control to a station manager. Let us analyse the two approaches. The special purpose system for the branches is depicted in Fig. 4. We have a system which controls the branches (Brl and Br2) between the two stations. In this case the modules for branches have to manage a smaller number of resources. Let us analyse the pattern of communication between the stations and the branch managers. When a train is going to leave the station Stl, the station itself has to ask Brl to allocate the branches’ resources to the train. Brl then performs the assignments by analysing the branches’ resources. Then Brl should ask St2 if the train can enter the station when it arrives at StZ. If both the modules accept the train, the station St/ allows the train itself to leave. and passes the

1 @

a

-r-J St1

Fig. 3.

I__ st2

st3

A centralized module Ihr railway branch regulation.

st2

St1 Fig. 4.

Special purpose

schedulers

st3

for railway branches.

98

E. Lamma, P. Mello, M. Milan0

St1 Fig 5.

A single

St2 model

Now we have to define the high-level interface between two modules (e.g. St2 and SO). Suppose that a train Tr should travel from St2 to St3. When Tr leaves St2 it has to be announced in St3. Module St3 decides either to accept Tr at its arrival time in the station or to delay the train itself outside the station. The possible delay of Tr has to take place on the last block of the railway branch (i.e. Blkn) before St3. The delay should be communicated to St2 which manages the last block of the railway branch, In this latter approach the communications between modules are reduced with respect to the other approaches discussed here. The only drawback of this approach is that the solution found is local, and each scheduler does not have a complete vision of the traffic along the railway line. Anyway, we prefer a local solution taken in a very short time instead of a global and optimal solution whose computational time is too high.

st3

for the scheduling branches.

of station

and

control to Brl. Otherwise, the departure of the train has to be delayed according to the decisions of the subsequent modules. The scheduling system of St1 then has to re-analyse the train extending the time for stopping, and this can interfere with assignments to other trains leading to a new allocations of resources. This process could not even converge. We prefer choosing another approach that is to assign the scheduling system for the branches in the system for the station. In that case we have to define the precise action field for every station. Therefore, in our approach each module controls a whole station whose topology is extended to the railway branches starting from the station itself. As already pointed out, in double branch railways we have a default direction for each branch. Trains must travel on the left branch, the so-called legal direction (see arrow signed branches in Fig. 5). The base module then controls the whole station and the two railway branches on which trains leaving the station travel in the legal direction. Note that in Fig. 5. the communication managers do not appear because they are part of the scheduling system of the station. In real situations, every station controls the departure of trains and not their arrival. Every train is announced when it is going to enter the station, and it can be accepted by the station itself or can be delayed at the entrance point if the entrance routes are not available. In this approach, we can focus on conflicts concerning the queuing of trains travelling in the same direction on a railway branch (e.g. a faster train behind a slower one), and solve them within the same module. In fact, these conflicts have to be solved in the previous station. Therefore, the same module can forecast future conflicts on the branch, and solve them without communicating with other managers, thus reducing communication.

r

COMMUNICATION - MANAGER

II

SM i

COMMUNICATION MANAGER * f 1

TM

SM

TM

t

i

T

I

_

SMA

SMA

I

The base module that controls the resources mentioned in section 4.1 is structured on four levels. (see Fig. 6): the lower level concerns the system which controls station devices, i.e. the Automatic Train Protection (ATP) system. The second level concerns the Station Master Assistant (SMA) that implements route feasibility. The SMA is an expert system implemented in KEE (knowledge engineering environment).26 SMA has been described in Ref. 1 and we do not present it in this paper. The third level concerns the scheduling of trains within the station and the branches. It assigns resources to trains in order to minimize train delays and also the change of time-table information. This level is structured in two related and communicating modules. The first, temporal manager (TM), maintains the temporal knowledge, while the second, scheduling manager (SM), takes decisions about the scheduling by consulting the TM. The higher level is the communication module which represents the interface between neighbouring stations. We will discuss this level in section 4.3.

T ’

i

I

4.2 The scheduler

T

I

ATP J

Fig-d

SMA

I

1

ATP

1

1

1

LI

I

The overall architecture.

A distributed

constraint-based

4.2.1 Data modelling

We first present a model of the static part of the problem, consisting of the description of the structure of the station and the branches, the incompatibility relationship between resources, and the time-table information. Within the station, the resources are routes and tracks.. Every resource has unitary capacity (i.e. only one train on it in every temporal interval). A route is represented by an initial point IP, a final point FP (track) and a unique resource identifier Rid: route (IP, FP, Rid)

A track is characterized

by a unique identifier Tid.

track( Tid)

Railway branches can be seen as sort of pipes composed of adjoining blocks (Blk). Blocks have to be sequenced in the following way: branch (Initial_Station, Final_Station, [Blkl, Blk2,. . ,Blkn] )

Switch,

Travel,

where Initial_Station and Final-Station are the names of the two stations adjoining the branch, Switch is the starting point of the branch itself and Travel is the method of travelling. The parameter Travel is necessary because in double branch railway lines trains travel in a default direction. In fact, trains must travel on the left branch, the so-called legal direction. The incompatibility constraints between couples of resources are represented by: incompatible(Rid1,

Rid2)

Obviously two incompatible resources cannot be assigned to two trains in overlapping temporal intervals. Moreover, every resource has unitary capacity (i.e. only one train on it in every temporal interval) and therefore it is incompatible with itself. As already said, all the trains are regulated by a timetable that contains information for each train (Trid) entering or leaving a particular station. This time-table contains the theoretical temporal intervals of stopping, calculated as the difference between the arrival (At) and the departure time (Dt), the theoretical resources (Res) the train should occupy, the priority (Pr) of the train (eventually modified during the computation according to the train delay). Furthermore, we have to represent the minimal time stopping (Min) in the station in order to allow the travellers’ operations, and the maximum delay threshold (Maxi) after which the priority of a train will be decreased. Finally, there are trains which travel in predefined periods, so it is necessary to represent the initial day and month (ID and I&f), and the final day and month (FD and FM) of the service. So the information contained in the system for a particular station is: time_table(Trid, FD, FM)

At, Dt, Res, Pr, Min, Maxd,

ID, IA4,

99

scheduler

This information should be the ‘best’ choice for the train but has to be considered only a sort of default knowledge, since the dynamic evolution of the state of the railway station can make this choice impossible or no longer convenient. Notice that the system is general and can be used for any railway station just by changing the databases describing the station topology and the time-table. Besides this static information we also have to model dynamic data i.e. data which change during the computation. For instance, delays of trains should be continuously updated by previous stations. Delays have to be communicated to a station when they change. In that way, the analysis at a station can be done according to updated information about trains that are going to arrive at the station itself. When a previous station communicates the delay for a train, in the dynamic data-base a fact is asserted: delay( Tr, Delay)

The fact is removed when the train has left the station. Another kind of data concerns the run-time assignments of resources to trains. Suppose the scheduling system assigns a resource Rid to a train Tr in the temporal interval Interval. Then, the system asserts a fact as: occupied(Rid,

Tr, Interval)

That fact is definitely accepted because it comes from an analysis already performed, and it is part of the state of the station. Finally, we have to deal with information about faults. We can distinguish between real faults and ‘propagated faults’. A real fault on the resource Rid is described by: fault( Rid)

A real fault can be propagated. Suppose that track number 22 does not work. Then all the routes ending in that track cannot be covered, and can be considered faulty as well. Therefore, in the example of Fig. 2, there is a propagated fault on the routes ~1-22, ~3-22 and ~4-22. We wili show these situations in detail in Section 4.4. 4.2.2 The scheduling system The scheduling system is structured in two modules, SM and TM. We now present the heart of the system: the scheduling manager SM and in particular the scheduling algorithm adopted. It can be logically divided in to different steps: announcement of train and collection of information; creation of the temporal window; extraction of trains that are going to arrive during the temporal window; sorting of trains; analysis of trains; final assignment of resources to the first train.

100

E. Lamma, P. Mello, M. Milan0

A train Tr is announced when it is going to enter the station. The scheduling manager, by consulting the timetable data-base, collects all the information on the train such as for example is arrival time, the departure time, the track and so on. Then, the program calculates the real arrival time by adding the dynamic and possible delay of Tr to its theoretical arrival time. Starting from this time the system builds a temporal window. One of the goals of the system is to avoid interferences between trains. Building a temporal window and analysing the trains that are going to arrive during it, the system can reach that goal. The length of the window is a userdefined parameter. The larger it is, the more precise is the analysis because we can be sure that the interference of the performed assignment has elapsed, but the computational time increases accordingly. The next step of the program determines which trains have an arrival or departure time within the temporal interval. This operation can be done by consulting the time-table data-base which contains, among others, the period of service for trains. For example, in Fig. 7. The announced train is number 350 and the window starts at the point START and ends at the point END. The trains analysed are the 350,450 and 7200 but not the 12039 and 411. These trains then are sorted by using an accurate heuristic function designed by talking with experts. This function takes care of priorities of trains, their distance form the station and their entrance point. Of course trains are ordered so that more important trains have a large number of resources available. The system takes the ordered list of trains, and starts the analysis. When all the trains have been assigned, the program terminates, and we can be sure that all the eliminable interferences have been avoided. Now we describe in detail the analysis that is performed for each train. The system has to assign an arrival route, a track, a departure route and resources of the railway branch to every train. The time-table database contains informations that should be respected as far as possible. The system calculates the temporal intervals in which the train should occupy the required resources if no delay occurs. Then, for every resource,the program checks if it is available in the required interval (by consulting the temporal manager described in section 4.2.3). If it is the case, the resource is assigned and no delay is added to the train; otherwise. the system calculates the necessary delay in order to acquire the resource itself. Anyway, we have to find a trade-off between the delay and the changing of the time-table resource. Therefore we have introduced a temporal threshold according to the number of attempts and the priority of the train. At the first attempt the threshold is low (in the example below it is 2 min). If it is not respected for a particular resource, the system changes resource and restarts the search. If there is not a resource leading to a delay less than the first threshold the system relaxes constraints. and restarts the analysis. The last value leaves

END

START

t ~

’ ~

4

350

450

7200

Fig. 7.

time

t -

t I 12039

A sample temporal

441

window.

the system free of delaying the train with no limit. In this case the SM assigns the time-table track to the train whatever the delay of the train. Example 1. Consider a class following associated list of delays:

of

trains

with

the

[Dl = 2 min, 02 = 6 min, 03 = no delay]. Each train has another list associated with it. It contains all tracks reachable by the train considered, ordered in increasing degree of traveller uneasiness: [RI, R2, R3]. The first track of this list is that scheduled for the train in the time-table. When a train belonging to this class cannot be assigned to Rl in the required temporal interval, the system delays the train only if the delay itself is smaller that Dl. Otherwise, the program tries to assign to the train a different track R2, and if this choice again implies a delay greater that DI it tries with R3. If these attempts fail (no track available for the train that leads to a delay smaller that Dl), the system relaxes the delay constraints and accepts the delay only if it is smaller than 02 restarting the analysis. At the third attempt the computed delay is accepted whatever it is (03 = no constraint). When the system reaches an assignment for every train, it can be sure that no interference among trains occurs. The last step of the program performs the final assignment of resources to the announced train (number 350) as a result of the whole computation. The analysis of the next train does not interfere with the state of the station because it is only necessary to eliminate possible interferences with the first (announced) train. 4.2.3 Temporal manager As already pointed out, the system has to handle temporal information which is managed by the TM, the temporal manager. The engagement of resources, the constraints and the interferences between trains involve some form of temporal reasoning. Therefore, one of the most important aspects of the whole system concerns the efficient and easy treatment of time. The TM maintains the temporal consistency of the present (real) and the future (supposed) state of the station. Temporal systemsz7 can be divided into two main groups: in the first the computation is performed through suitable searching processes when a query is raised while in the other a constraint progagation takes place each time new temporal information is introduced, leading to a constant query time. The latter group has all the disadvantages concerning the creation of completed

A distributed constraint-based scheduler

acyclic graphs that maintains updated temporal knowledge every time a new fact is introduced in the database. The TM classifies in the second group, but it does not suffer from these problems. In fact, it is based on the creation of temporal domains. The systems associates with every resource of the station and of the railway branches (identified by Rid) a temporal domain of feasibility. This domain contains the temporal intervals during which the associated resource is free. The modelling of dynamic knowledge of the program is represented by the creation of the above-mentioned domains with the predicate: domain(Rid, Intervals )

where Intervals is a list of temporal intervals of feasibility. The temporal knowledge of the system is based on the persistency rule, which assumes that a property persists until an event occurs which terminates it. At start-up, every resource is supposed to be always free. Therefore, the system associates with every resource an ‘infinite length’ temporal interval, so temporal intervals are initially set to Intervals = [0, +oo] where 0 represents the midnight of the current day. (It is worth noting that we are working on finite domains, so +m is represented by a great number. In the following +cc is a conventional symbol). Then the system must update the domains according to the analysis already performed (i.e. the assignments for already announced trains). The assignments for these trains can be considered definitive because they have been decided according to the goals of the system and they are part of the ‘state of the station’. Therefore, the program has to cancel from the domain of each resource the temporal intervals in which Rid itself has already been occupied. Now every resource’s domain is updated according to the present state of the station and the system can start its search. As already stated in section 4.2.2, the SM collects all the trains that are expected to arrive during the temporal windows previously built. The system has to assign, to every train considered, resources by analysing their temporal domains. When a train requires a resource in a particular temporal interval the system checks if the resource’s domain contains the interval itself. If this is the case, the resource is free and can be assigned to the train. However, the domain could not contain the required interval. In this case the program should decide whether to delay the train or assign it another resource. This decision can be taken accordingly to the temporal threshold imposed by the number of attempts already performed. E.xampIe 2. Let us consider the station described in Fig. 2, where route ~2-20 has the associated domain: D ={[O, 7.321, [7.35, 7.501, [7..55, +co]}. It means that ~2-20 is engaged during the intervals [7.33, 7.341 and [7.51, 7.541. If a train requires the temporal interval

101

[7.40, 7.431 the route ~2-20 can be assigned. Notice that the internal representation of time is implemented using minutes referred to the starting time (midnight) of the day in which the analysis is performed. In the examples we use a more comprehensive notation for the reader. Instead, if a train requires the interval [7.53, 7.561, it should be delayed, ‘shifting’ the required interval of 2 min because the resource is free 2 min later. The delay can be calculated by finding in the domain D the closest interval whose length is large enough to contain the required interval and making the difference between the lower bounds of the two intervals. Then the delay can be accepted or rejected by the program according to the threshold. Once the system finds all the resources for a train, it propagates the incompatibility constraints by eliminating from the domain of the physically engaged resource the temporal interval assigned to the train. Moreover, the program has to delete the same interval from the domains of all the incompatible resources. In this way we can be sure that the temporal knowledge about the feasibility state of resources is updated and always consistent during the computation. E.xampZe 3. Suppose that a train occupies the route called ~2-20 in the temporal interval [7.40, 7.431. Suppose either that ~2-20 is incompatible with ~1-19 and not with ~1-21. Let the domains associated with these resources be:

Dl ={[O, 7.321. [7.35, 7.501, [7.55, + co]} associated with ~2-20; 02 ={[0,7.30], [7.35, S.OO], [8.05, 8.101, [8.13, +cQ]} associated with ~1-19; 03 ={[O, 7.201, [7.23, 8.001, [8.05, 8.211, [8.25, +co]} associated with p l-2 1. The program (incompatible) domains are:

has to eliminate from Dl and D2 the interval [7.40, 7.431. The update

Dl ={[O, 7.321, [7.35, 7.391, [7.44, 7.501, [7.55, +cQ]> 02 ={[O, 7.301, [7.35, 7.391, [7.44, 8.001, [8.05, 8.101, L8.13, + co]} 03 ={[O, 7.201, [7.23, 8.001, [8.05, 8.211, [8.25, +w]}

(it does not change). Note the forward propagation of constraints allows one to maintain a correct and updated state of the station during the computation. In fact, if the system finds a temporal interval in a resource’s domain we can be sure that neither the resource itself nor some incompatible one is engaged. Notice that by using constraint logic programming with finite domains we obtain a direct implementation of the mechanisms described above. It is worth noting that the use of these domains is different from their standard use but it maintains the main characteristic of a CLP approach. In fact, we can easily find a correspondence between the two approaches. Domains usually represent the

102

E. Lamma,

P. Mello, M. Milan0

disjunctive set of possible values for a variable. The propagation of constraints reduces the domains by pruning apriori the search space of the problem. When a domain becomes empty, a failure occurs because it means that the variable does not have any value compatible with constraints involved in the problem. Our approach is very similar even if the representation is quite different. Finite domains allow us to maintain an updated and complete knowledge about the present and future state of resources in order to facilitate the search and the scheduling. In particular, domains contain the feasible intervals for a resource, i.e. the intervals during which the resource is free. The forward propagation of constraints reduces a priori the temporal domain of incompatible resources according to an assignment of a resource to a train in a particular temporal interval. When the domain associated with a resource contains a particular temporal interval, we are sure that the resource itself and all the incompatible ones are free in the above-mentioned temporal interval. Therefore, when a train is asking for a resource, the search space to consider is reduced to the resources whose domain contains the temporal interval required. The resources domain can collapse into an empty set whenever the resource itself is out of order for an unpredictable time. It means that there is no value (in this case time interval) that can be assigned according to the constraints. In this case the system fails only when there are no alternative resources for a train. Otherwise, the system tries to change its choice by scheduling an alternative resource or delaying the train. 4.3 Communication

mechanisms

In this section we show which kind of information is exchanged between modules. Different modules advise different human experts that control a station and a couple of branches along a railway line. These experts, as well as the scheduling systems should do, do not work in the same place. Anyway, they need to interact with other human experts. In particular, they communicate with the experts who control adjoining stations. Let us consider, for instance, a train that is going to leave station Srl and travel along a branch towards station Sr2. If there is a fault on the entrance point of St2, the train cannot reach the next station, and it has to travel in the illegal direction in order to arrive at St2. Moreover, the illegal direction is controlled by the human expert of St2, and St1 has to wait until the human expert of St2 allows the train to leave. In the same way, the scheduling system which manages a particular station and the arrow signed branches in Fig. 5 needs to exchange information with the systems that control the adjoining stations. A possible approach to this problem provides one communication manager for each adjoining station, but each manager requires synchronization and communication mechanisms with other managers. Therefore,

for each station, we developed a single communication manager which allows the interactions with adjoining stations. Of course, while in the simplest cases there are two neighbouring stations (one on the left and one.on the right), in more complex situations (node stations) there can be more than two adjoining stations. The communication manager presents two channels of communications for each neighbouring station. In Fig. 5 the communication manager of St2 presents four channels: two for station St1 and two for St3. Let us analyse the interactions between St2 and Stl. The two channels correspond to the two branches linking the stations. The action field of St2 concerns the arrow signed branch, while the action field of St1 is related to the other. It means that the trains leaving Sr2 and travelling their left branch are controlled by the scheduling system of St2 itself. The opposite situation happens for the trains leaving St1 and arriving at St2. Hence, St2 after having scheduled its resources for a train, has to ask Stl to analyse the train itself in order to know the possible delay for the train on the entrance point of St1 or if there is a fault. Again, another communication between the two stations may concern the alignment of knowledge bases. In this way all the stations can work with updated and consistent knowledge. For example, the changing of the delay for a train is very important information that should be exchanged between modules. Let us consider, for instance, a train which is travelling with 5 min delay. Suppose the same train has to wait for 2min at the entrance point or on the track of St2. The total delay for the train is no longer 5min but 7min. This change has to be communicated to St1 which has to know quite precisely the arrival time for trains because it has to analyse these trains, and assign them resources. On the other hand, St1 has to pass the same queries to St2 for the trains travelling in the other direction. Therefore the communication manager of a particular station has to be a server when the near station makes a query and waits for an answer. For instance, the communication manager of St1 is a server when St2 asks him to analyse a train that is going to arrive at Stl, and communicate to St2 the answer which is the computed delay at the entrance point. On the other hand, St1 is a client when asking for a service from the communication manager of St2. Besides the client-server peculiarity of the system, there is another important distinction with this problem. It concerns the different types of messages exchanged. Mainly there are two different kinds of messages. The first concerns a sort of alignment of knowledge bases of the modules. These messages contain information that should be constantly updated in order to maintain consistency in the distributed knowledge bases. Let us consider for example the update of a delay. There are messages that require an answer, e.g. the kind of queries for analysis. The server makes the analysis, and gives an answer. The other kind of message

A distributed constraint-based scheduler

concerns the communication of a fact, which can be for instance a delay. This kind of message requires only an acknowledgement to the client. In the first case, we develop a client-server model while in the second case the model is a simple message passing (simple rendezvous). These mechanisms have been developed building a layer of non-blocking C primitives that allow one to use Internet stream sockets (i.e. TCP protocol based sockets).28 On top of the C primitives we developed a Prolog communication interface which controls the communication channels with other stations. The Prolog approach to the communication is very simple, flexible and re-configurable. Each communication manager contains a configuration database which stores the name, host and port of the station itself and of the neighbouring stations. Just by changing these facts we can re-configure the communication manager for each station along the line. Besides, we have developed Prolog primitives that control the initial connections between stations. The primitives consult the configuration database and create input and output sockets for the connections. As already pointed out, every couple of stations has two communication bi-directional channels, one for the server behaviour (when answering queries from other modules) and one for the client behaviour (when querying other modules). Therefore, during the initial connection every couple of stations has to create two channels. Each station performs client behaviour creating an output socket, and trying to connect with each neighbouring station, and a server behaviour creating an output socket which accepts connections from all the adjoining stations. When connections are installed, the base modules can start their communication by sending and receiving messages and queries. Each communication manager monitors all the channels and serves queries. It also provides for sending queries to other modules and waiting for answers needed from the scheduling system. This module has also to monitor the user queries. In fact, the user can decide to close a branch putting it out of service for a period of time. This choice, as well as messages from other stations, has to be communicated to the system. 4.4 Faults and unexpected events The system we developed is an advisory system for human experts. As already said, this kind of application has to support, rather than replace, human decisions and skills. Furthermore, these systems have to be sensitive to real-time changes such as faults and unexpected events. Our system satisfies this requirement. In fact, it is sensitive to real-time events such as faults. As an example, suppose the scheduler assigns a track to a train until 7.30pm. Therefore, at 7.30 the train is expected to leave the station. Anyway, because of trouble (e.g. travellers who arrived late) the train

103

cannot leave at 7.30. The system has to be flexible enough for handling such an event. In fact, the system has to be informed by a low-level interface with the station and the scheduler has to perform another analysis according to the new traffic situation (i.e. it has to re-allocate resources to trains that are expected to arrive on the out of service track). Another event that should be handled by the system is the management of faults. These events are regulated by strict rules that preserve travellers and personnel safety. In fact, when a train is travelling on a resource that is going out of order, it should be regulated by ‘hand made’ emergency movements. When a fault occurs the rule to be followed is that a train cannot cover an out or order resource and also it should not be routed on an obstructed way. Therefore, faults are controlled by a propagation mechanism. A fault on a resource implies that the resource itself cannot be assigned to a train. This constraint induces other constraints on other resources. Let us consider, for instance, a fault on a track. Of course, every route that converges on the track itself cannot be covered as well. Therefore, these routes can be considered out of order on the track. Again, if every route that starts from an entrance point or converges in a departure point is fault, the fault can be propagated on the point. Therefore, every time a resource goes out of order, the system propagates this fault to other resources in order to detect as far as possible an obstructed way, and consequently a failure. This behaviour is typical of CLP techniques. In fact, a CLP approach is based on the prevention of failures instead of a recovery from failures that have already happened.

5 PERFORMANCE RESULTS The overall system has been implemented by using a constraint logic programming language in order to efficiently exploit pruning techniques on the search space of the problem. A prototype of the system has been developed on a SUN SparcStation 2 by using the logic programming language SEPIAz5 (Standard ECRC Prolog integrating advanced applications) suitably extended to solve constraints on finite domains and primitives for distributed communication. A finite domain library has been developed by using the meta-term data-type available in SEPIA, briefly described in Section 3.2. In the prototype, meta-terms are domain variables used to store the temporal intervals of feasibility. In the following, we show the performances of a single module scheduling system in terms of computational time, and the ratio between the number of failures and number of calls. The second parameter is significant because of the tool used to develop the scheduling system, SEPIA. During the computation, Prolog develops a tree by calling predicates and backtracking when

E. Lamma, P. Mello, M. Milan0

104 Table 1. Trains

Time (s)

Failure/call

I 2 4 6 9 16 23 31

0.13 0.16 0.33 0.44 0.60 1.47 2.70 5.40

0.20 0.19 0.20 0.19 0.22 0.24 0.25 0.26

this fails. The smaller the ratio between the number of failures and the number of calls, the better is the search procedure in the tree itself. We have tested the system for an increasing number of trains. The most interesting parameter is the failure call ratio (Table 1). We can see that the search techniques based on propagation are very efficient and make CLP an effective implementation support for the train scheduling problems. Moreover, the computational time of the program is very promising. A station master will take from 30 s to 1 min in order to assign resources to a train, taking into account the interferences caused on the two or three following trains. On the other hand, our system takes 540s to reach the same decision (assigning resources to a train) considering 31 following trains. For the sake of completeness, a complete analysis usually involves a query at the neighbouring station in order to receive, as an answer, the eventual delay, for the analysed train, at the entrance point. Therefore. the computational time should be multiplied by two in order to have a correct speed parameter. To handle communications between different stations, we developed a layer of non-blocking C primitives for TCP sockets. The main advantages in using TCP protocol is that the order of messages is guaranteed and the communications are safe. The first advantage is very important in order to prevent inconsistency situations. In fact, a station, before asking another for the analysis, communicates to it a delay. Therefore, the next station can start its analysis with correct information on the arrival time for trains. The second advantage concerns the safety of messages. Using TCP we can be sure that every message arrives without errors and there is no loss of information. The choice of non-blocking primitives comes from the need of the system to be open to every channel, and to recognize the different messages. 6 CONCLUSIONS AND FUTURE WORK In this paper, we have presented a distributed system for train scheduling within railway stations and along railway branches. The first prototype has been tested on small and average-sized railway stations with very good results. In the future, we intend to apply it to big railway stations.

This paper has shown the versatility of CLP paradigm for the scheduling problems. In particular, CLP on finite domains is a flexible and declarative paradigm for solving many scheduling problems such as the train scheduling problem. The consistency techniques and the forward propagation of constraints greatly reduce the search space of the problem, and therefore make CLP an effective tool for facing the scheduling of trains. Temporal knowledge can be easily represented and maintained by using domains of temporal intervals. A layer of C primitives has been added to a CLP language in order to provide communication mechanisms between distributed schedules. The system described in this paper provides only local (to adjoining modules) optimization. Future work will concern the creation of an intelligent system which monitors the whole railway line (i.e. many modules), and gives advice for global optimization of traffic. Moreover, we will develop a user-friendly interface in order to make the system an effective and usable tool for human experts involved in managing railway traffic. In the current implementation, we have developed a constraint solver on finite domains by using SEPIA meta-terms. An improvement in the prototype can be obtained by using a CLP system which embeds directly in the compiler a constraint solver on finite domains. Therefore, further implementations will be developed by using ECL’PS”.*’ In fact, ECL’PS is characterized by an efficient and flexible implementation of a large number of built-in predicates for constraint solving over finite domains.

ACKNOWLEDGEMENTS

This work has been partially supported by SASIB SpA and MURST 60%. We would like to thank Paolo Lasagni who implemented the finite domain library for SEPIA, Albert0 Torreggiani for his help in implementing and debugging the base module of the scheduling system, and Andrea Dalfiume for his help in implementing the communication mechanisms.

REFERENCES Fringuelli, El. Lamma, E. Mello, P. Santocchia, G. ‘Knowlege based technology for controlling railway stations’. IEEE Expert, 1992, pp. 45-52. Fringuelli, B. Lamma, E. Mello, P. & Santocchia, G. ‘An expert system for train traffic control’. Proceedings Expert Systems and Their Applications - Avignon91, Vol. 6 Avignon, 1991, pp, 43-53. Accardi, L. Fabrini, E. & Lucentini, M. ‘Study and experimentation for optimising railway traffic’. First National Conference CNR, ‘Progetto Finalizzato Trasporti II’, Vol. 4, Rome, 1993, pp. 2033-60 (in Italian). Cullyer, W. J. & Wise, W. ‘Application of formal methods to railway signalhng’. Proceedings of the Safety and Reliability Society Symposium, Bath, 1989, pp. 1l-28.

A distributed

constraint-based

5. Mascis, A. & Sassano, A. ‘Job-shop, no-wait in process with blocking models for the ordering of trains within big railway stations’. First National Conference CNR, ‘Progetto Finalizzato Trasporti II’, Vol. 4, Rome, 1993, pp. 2075-94 (in Italian). 6. Baptiste, P. Legeard, B. Manier, M. A. & Varnier, C., ‘A Scheduling problem optimisation solved with constraint logic programming’. Proceedings Practical Applications Of Prolog, London, 1994, pp. 47-66. 7. Breitinger, S. Lock, H. C. R. Modeling and scheduling in CLP (FD). Proceedings Practical Applications of Prolog, London, 1994, pp. 95-110. 8. Caseau, Y. Laburthe, F. Improved CLP scheduling with task intervals. Proceedings International Conference of Logic Programming, S. Margherita, Italy, 1994, pp. 36983. 9. Christodoulou, N. Stefanitsis, E. Kaltsas, E. & Assimakopoulos, V. ‘A constraint logic programming approach to the vehicle-fleet scheduling problem’. Proceedings Practical Applications of Prolog, London, 1994, pp. 137-48. 10. Duncan, T. ‘Intelligent vehicle scheduling: experiences with a contraint-based approach’. Proceedings of Expert System 94: the Fourteenth Annual Conference of the British computer Society Specialist Group on Expert Systems Cambridge, UK, 1994. 11. Fox, M. S. & Sadeh, N. ‘Why is scheduling difficult? A CSP perspective’. Proceedings ECAI 90, 1990, pp. 75467. 12. Sauthier, E. & Faltings, B. ‘Model-based traffic control’. Artificial Intelligence in Engineering, 1992, 7, 139-51. 13. Van Hentenryck, P. ‘Constraint Satisfaction in Logic Programming’. MIT Press. 1989. 14. Jaffar, J. & Lassez, J. L. ‘Constraint Logic Programming’,

15.

16. 17. 18.

19. 20.

21.

22. 23. 24. 25. 26. 27. 28.

scheduler

105

Proceedings Conference on Principles of Programming Languages, Munich, 1987. Jaffar, J. & Maher, M. J. ‘Constraint Logic Programming: a survey’ Journal of Logic Programming, Special Issue for 10 Years of Logic Programming, 1994. Kowalski, R. ‘Logic for Problem Solving’. North-Holland, 1979. Lloyd, J. W. ‘Foundation of Logic Programming’. 2nd extended edn. Springer-Verlag, 1987. El Fattah, Y. ‘Constraint logic programming: applications and implication’. Arttficial Intelligence in Engineering, 1992, 7, 175-82. CHIP User’s Guide. Version 4.0. A. COSYTEC SA, France, 1993. Dincbas, M. Van Hentenryck, P. Simonis, M. Aggoun, A. Graf, T. & Berthier, F. ‘The constraint logic programming language CHIP. Proceedings International Conference on Fifth Generation Computer Systems, Tokyo 1988, pp. 693-702. Jaffar, J. Michaylov, S. Stuckey, P. J. & Yap, R. H. C., ‘The CLP(R) language and system’. ACM Transaction on Programming Language and Systems, 1992,14(3), 339-95. Colmerauer, A. ‘An introduction to Prolog III’. ACM Communication, 1990, 33(7), 70-90. ECL’PS’ User Manual Release 3.3, ECRC, 1992. Puget, J. F. ‘A C++ implementation of CLP’. Technical Report 94-01, ILOG Headquarters, France. SEPIA User Manual Release 3.1, ECRC, 1991. Sabharwal, A., et al. ‘Asynchronous production system’. Knowledge Based Systems, Vol. 2, 1989, 2(2) 117-27. Yaampratoom, E. & Allen, J. F. Performance of temporal reasoning system. SZGART Bulletin, 1993, 4(3). Stevens, R. UNIX Network Programming. Prentice Hall, 1991.