An Object-oriented Approach to an Information and Decision Support System for Railway Traffic Control

Contributed paper

An object-oriented approach to an information and decisionsupport system for railway tra�c control

Michele Missiko� *

IASI-CNR, Rome, Italy

Received 1 November 1996; received in revised form 1 July 1997

Abstract

The paper describes the analysis, design, and fast prototyping of MINT (Manager of Integrated Networks of Train tra�c), an

information and decision support system for railways tra�c control.MINT is a complex system that tightly integrates information management and problem-solving functionalities, by means of

an object-oriented approach. The work is characterized by several issues: (i) object-oriented analysis and design; (ii) knowledge-

based application modeling, by means of a powerful conceptual language (TQL++); (iii) advanced search techniques in theproblem-solving component; (iv) fast prototyping by the automatic generation of executable code; (v) use of an advancedknowledge-based modeling and prototyping environment (Mosaico).

The paper starts with a description of the railway tra�c control problem; then it focuses on the architecture of MINT, payingparticular attention to the database component and its train con¯ict-solving capabilities. Finally, a few experimental results arereported. # 1998 Elsevier Science Ltd. All rights reserved.

Keywords: Object-oriented information systems; Decision support system; Railway tra�c control; Formal speci®cation; Rapid prototyping

1. Introduction

Railway tra�c control (RTC) is a critical task in amodern railway transportation system, and its import-ance is widely recognized by the most important R&Dproject launched within the European Union (Rail etRecherche, 1995). In such systems, RTC does notaddress the safety of the passengers or the rollingstock, a critical task left to unattended automatic elec-tronic systems (human controllers are too error-prone). These devices, often indicated by the acronymATC/ATP (Automatic Train Control/Automatic TrainProtection) operate in order to keep a safe distancebetween trains travelling on the same line. It is possiblefor a train to undergo a speed reduction or even beautomatically stopped, to prevent it from entering atrack segment that is already occupied by anothertrain (in essence, to avoid a collision).

In perturbed situations, when trains have deviationsfrom the scheduled timetable, the goal of RTC is to

reduce delays and to make tra�c return to plannedpaths. Furthermore, it is necessary to avoid lettingtrains get close to a potentially dangerous situation,and therefore undergoing unplanned delays or stops(Lagana et al., 1994). To this end, the railway tra�ccontroller (RTCer) carefully monitors the train tra�c¯owing within his area of competence to identify, assoon as possible, any abnormality that can lead toroute interference or con¯ict. A train con¯ict is a situ-ation in which an ATC/ATP device takes over andautomatically stops a train which is trying to enter adangerous area. Once a potential con¯ict has beenidenti®ed, the RTCer must devise a strategy to preventthe con¯ict from actually taking place. Such a strategyconsists of the modi®cation of routing and/or timingof trains, so that the forecast con¯ict will not occur or,if unavoidable, its e�ect will be minimized.

The development of a decision support system(DSS) to help the railway controller in tra�c problemanalysis, solution construction and decision making, isconsidered nowadays one of the greatest technicalchallenges in railway tra�c management (Rawlings,1994). It has been traditionally addressed by using op-erational research (OR) techniques (Carey, 1994;Jovanovic and Harker, 1991). The main problem with

Engineering Applications of Arti®cial Intelligence 11 (1998) 25±40

0952-1976/98/$19.00 # 1998 Elsevier Science Ltd. All rights reserved.

PII: S0952-1976(97 )00058 -4

PERGAMON

* Correspondence should be sent to: Michele Missiko�, IASI-

CNR, Viale Manzoni 30, 00185 Rome, Italy. Phone: 00-39-6-771-

6422; Fax: 00-39-6-771-6461; e-mail: missiko�@iasi.rm.cnr.it.

such techniques is represented by the domain model-ing, which uses notations that are di�cult for thedomain experts to understand, and rigid with respectto the changes required by evolving scenarios. A di�er-ent approach makes use of rule-based expert systems(Araya and Fukumori, 1984). This approach also exhi-bits several limitations, common to other expert-systemapplications: if the size of the rule-base grows beyonda certain limit, the system becomes unmanageable.

This paper addresses the problem using an object-oriented approach (Khosha®an and Abnous, 1990). Inthe next section, an overview of the architecture of theMINT system is presented. Section 3 illustrates thecon¯ict solving method and Section 4 presents theObject-Oriented conceptual model of the system, im-plemented using the conceptual language TQL++.This language also allows a prototype to be automati-cally generated. Section 5 reports the same quantitativeresults obtained by running the MINT prototype withreal data coming from train tra�c on a railway linesouth of Rome.

2. The architecture of MINT

MINT (Manager of Integrated Networks of Traintra�c) is a complex real-time system, integrating infor-mation-management and decision-support functions toassist railway tra�c controllers in their work.

The main objective of railway tra�c controllers isthe early identi®cation and resolution of con¯icts, orthe avoidance of snowball e�ects (i.e. delays causing achain of other delays). In particular they have thefollowing duties:

. Continuous monitoring of train tra�c evolution inthe railway scenario (a junction or a line) or func-tions within their responsibility.

. Dispatching special (i.e. unscheduled) trains inorder to satisfy variable market demand.

. Early identi®cation of abnormalities in network op-erations, concerning rolling stock, tracks, and way-side equipment.

. Supervision of possessions (i.e. periods when raillines or tracks are reserved for maintenance work).

. Monitoring of trains that show some delay withrespect to the planned journey times.

. Short-term projection of tra�c evolution, and earlyidenti®cation of possible con¯icts between trains.

. Analysis of the impact of identi®ed abnormalitieson scheduled train services.

. Minimization of the negative e�ects due toabnormalities, by constructing suitable strategies toprevent identi®ed con¯icts from actually takingplace.

. Real-time modi®cation of train schedules to im-plement the devised con¯ict-solving strategies.

. Implementation of the identi®ed con¯ict solvingstrategies, issuing suitable commands to modifytrain journeys.

In order to perform this job as well as possible, theRTCer must be equipped with a system that is capableof supplying prompt and accurate information aboutthe railway scenario being monitored, and of support-ing his decision-making activities. In particular, thesystem should provide three types of functionalities: in-formation management, scenario analysis and decisionsupport.

Information Management ± Consists of storing andsupplying basic, real-time information on the state ofthe railway scenario, i.e. the operational state of thenetwork, including:

. pre-planned timetables, o�cially de®ned and pub-lished by the railway company;

. timetables of unscheduled (i.e. supplementary)trains;

. scheduled maintenance operations on the rail infra-structure;

. actual timetables of active train services under thecontrol of the RTCer, with their scheduled evol-ution;

. identi®cation of trains moving in the monitoredarea, with continuous updates of their positionsand states;

. any unforeseen abnormality (e.g. traction linebreakdown, a ®re in the vicinity of a track, or athunderstorm).

Scenario Analysis ± Early identi®cation, within aprede®ned time-window, of abnormalities and theire�ects on the future train ¯ow. In particular, identi®-cation of con¯icting train paths, with all the relevantinformation about each identi®ed con¯ict (place, time,and characteristics of the trains involved).

Decision Support ± Support to the RTCer in thejoint analysis of con¯icts and the railway scenario,aiming at the construction of a solution, i.e. a resche-duling of the train services in order to prevent theidenti®ed con¯icts from actually taking place, or tominimize their e�ects.

The work described in this paper starts from theabove requirements and proceeds through the analysis,design, and fast prototyping of a software system,MINT. The development of the MINT prototype hasbeen based on Mosaico (Missiko� and Toiati, 1994),an environment for the analysis, speci®cation, andrapid prototyping of object-oriented data-intensive ap-plications, developed at IASI-CNR.

In order to accomplish the above functionalities,MINT needs a rich variety of information, as illus-trated below.

M. Missiko� / Engineering Applications of Arti®cial Intelligence 11 (1998) 25±4026

2.1. The information base of MINT

The following types of information were originallystored in three di�erent databases (schematically rep-resented later in Fig. 2), maintained by di�erentdepartments in the railway company. They will bemerged into one single object-oriented database,RODB (Railway Objects Database), which representsa fundamental component of MINT.

Railway Infrastructure (RWI). This database storesthe information about the railway infrastructure andequipment, such as the state and availability of stationtracks and platforms, rail lines, switches, traction, andwayside equipment. The RWI database is also updatedwhen an unexpected abnormality occurs in the infra-structures, or when the operations are altered byplanned or contingent maintenance services, causingfor example a line blockage or a temporary speed re-duction on a line section.

Pre-planned Timetables (PTT). A second databasestores the pre-planned timetables of train services. Thisis a static database that is accessed by MINT in read-only mode during tra�c control operations. PTT isupdated twice a year, in switching from the Summerto the Winter Timetable and vice versa. This databaseincludes the static train descriptions, comprising speci®cinformation on each train, such as category, priority,type of engine, convoy length, and rolling-stock fea-tures.

Scheduled Train Services (STS). The third databaserepresents the core of the RTC operations. STS isupdated daily with all the speci®c tra�c needs thatmay arise, such as ordinary trains cancelled and sup-plementary trains actually activated (i.e. contingencyplanning support). It contains the information aboutactive train services in the given control area (within aprede®ned time-window, typically 24 h). It is createdstarting from the PTT database, extracting the pre-planned services of the speci®c area under control(junction or line) and instantiating the actual train ser-vices with possible schedule variations required by thestate of things. The STS database is organized in threesections, as illustrated in Fig. 1. In the case of a single-direction line, STS is a table where columns and rowsare labeled with station names and train codes, re-spectively.

Past Train Services (PTS). Records the timings androutings that actually took place in the part of thejourney already accomplished by the monitored trains,including all the modi®cations to the original schedule.In modern railway networks, the updating of this kindof information is performed automatically by the way-side equipment.

Future Train Services (FTS). Stores the timetables ofthe monitored trains for the rest of their journeys (inthe controlled area). The reported times re¯ect the

actual history of running trains, with possible delaysand rescheduling decisions, with make-up times andreroutings.

Monitored Train Services (MTS). This is a subset ofFTS, storing the immediate forthcoming services, thatrepresent the critical part of the train scheduling. Itrecords location and speed of running trains, plat-formed trains at the stations, and the tra�c forecast inthe critical time-window (typically, less than 1 hahead).

Fig. 1 schematically describes the content of theSTS database for a railway line. As anticipated, it is inthe form of a table having a ®xed number of columns,one for each station on the line, arranged from left toright, by increasing mileage. Each row represents atrain with its scheduled stopping times in each station.The Time-Now Line (TNL) separates past from future.A new train entering the monitored area is recorded atthe bottom of the table (having a variable number ofrows) and, as time passes, is shifted upwards. Thetrain at the top is removed when it leaves the laststation (corresponding to the rightmost column).Then, all the other trains are shifted upwards.

2.2. The functional architecture

From a functional point of view, the architecture ofMINT is organized in four main subsystems, rep-resented by rounded boxes in Fig. 2. The ScenarioManager (SceMan), the Forecast Subsystem (ForeSys),and the Intelligent Rescheduler (IntRes) correspond tothe main tasks of MINT: (i) tra�c and network infor-mation management, (ii) tra�c monitoring and analy-sis, and (iii) con¯ict resolution, respectively. Finally,we have the Railway Tra�c Controller Interface(RTCI) which is dedicated to the continuous inter-action with the user and the presentation of the rail-way tra�c situation.

Figure 2 also illustrates the databases of MINT. The®gure, besides the three mentioned databases andRODB, includes evidence of the timetable of moni-

Fig. 1. STS: scheduled trains services.

M. Missiko� / Engineering Applications of Arti®cial Intelligence 11 (1998) 25±40 27

tored train services (MTS), which represents the start-ing point of the monitoring operations, and theWorking Timetable (WTT). The latter is a workingcopy of MTS, used in the rescheduling process. At theend of the process, WTT contains the complete sol-ution to the rescheduling problem, i.e. a new timetable,free of con¯icts. Its content is then used to perma-nently modify FTS and send the appropriate com-mands to the station and line managers, to regulatethe train movements accordingly.

This section, after a brief description of the SceMan,concentrates on the control and rescheduling tasks andthe two subsystems that implement them: ForeSys andIntRes. The description of the interface (RTCI) fallsoutside the scope of this paper.

2.2.1. SceMan: the scenario information managerThis module has the primary task of keeping track

of the evolution of train tra�c and the changes of theoperational state of railway network and infrastruc-tures. It is triggered periodically (e.g. every 3 min) or,alternatively, pre-emptively by an unforeseen abnormalevent, such as a delayed departure of a train from astation or a train running slower than expected. Themain tasks of SceMan are as follows:

RWI update. This function is related to the state ofthe railway tracks and wayside equipment. Anyabnormality in¯uences the train services; therefore itmust be timeously signalled to the RTCer to trigger ananalysis of the new network state, assessing its impacton the tra�c, and to perform a short-term reschedul-ing of train services, if necessary.

PTT update. This function is related to any mid-term modi®cation of the general train services timeta-ble. These modi®cations are performed to cope withabnormalities, either known in advance, such as train

speed reductions due to track-maintenance work, orunforeseen but with mid-term e�ects, such as a trackout of service due to some incident. In these cases,there is a regional o�ce dedicated to adjusting thetimetable to cope with the new situation. The newPTT (Pre-planned Timetable) is then stored in the cor-responding database.

Management of STS database. The STS database,that stores the train services of the day, can be modi-®ed on-line. The updates are originated by unforeseenexternal requests, or as the e�ect of the RTCer'srescheduling activities. SceMan is responsible for stor-ing in the PTS section the actual timings and routingsrecorded after the actual train journeys (this operationis implemented automatically in modern control sys-tems), and for the updating of TNL. Furthermore,variations from the daily timetable, recorded in theFTS section, can also occur during the operations (e.g.a supplementary train created at the last minute); theseare recorded in the database and noti®ed to theRTCer.

2.2.2. ForeSys: timetable analysis and con¯ict detectionThe second main task of MINT is concerned with

the analysis of the routes of the monitored train ser-vices (MTS), aiming at identifying abnormalities andpossible future train con¯icts. MINT was initially con-ceived for the control of a double-track railway line (arailway junction will be analysed in a new, forthcom-ing project).

Timetable analysis is a periodic transaction, acti-vated automatically (every 3 min in these experiments),or pre-emptively, in the case of unforeseen externalevents. It is composed of two main functions: (i) TNLupdate, performed by SceMan, to re¯ect the actualtrain positions in the network, and (ii) con¯ict detec-

Fig. 2. MINT architecture.


tion, to check if any con¯ict is present in the moni-tored time-window.

Experimental studies have proved that the look-ahead monitoring can be stretched signi®cantly ap-proximately 1 h ahead. There is no need to push theanalysis beyond this time limit. Therefore, on theWTT the monitoring region MTS, which is a diagonaltime-window, is set at 45 min wide, starting at TNL(see Fig. 1).

In the context of a line the con¯icts are essentiallypassing con¯icts ( p-con¯icts). A p-con¯ict arises when-ever, on the basis of their routings and timings, twotrains, running on the same track, in the same direc-tion, are expected to arrive at a station in inverseorder with respect to their departure from the previousstation. In practice, this means that a slower train isleaving a station before a faster train, with a time mar-gin that is not su�cient to reach the next stationbefore the second train.

Con¯ict detection is also important during the con-¯ict resolution process, when for every tentative sol-ution a look-ahead over the tra�c evolution isperformed, to analyse whether a proposed solution willinduce future con¯icts on train routes. In particular,for any new tra�c scenario the task of con¯ict identi®-cation is restarted, the output is used to evaluate thequality of a candidate solution.

2.2.3. IntRes: con¯ict resolution and tra�c reschedulingCon¯ict resolution is the most critical task of

MINT, and represents the core of the decision-supportfunctions. It is activated after the completion of aForeSys transaction, only if some con¯ict has beendetected. IntRes analyses con¯icts and generates sol-utions. A solution is a modi®cation to a train routingand/or timing that avoids the forecast con¯ict. Oftenthere is more than one solution to a con¯ict; therefore,it is important to have good selection criteria, able toidentify the best (or, at least, a satisfactory) one. Thedecision has to take into account the e�ects, propa-gated in time and space, that each correcting actionwill produce on the controlled train tra�c.

The ®nal goal is the construction of a completerescheduling of the tra�c that releases an MTS free ofcon¯icts. The con¯ict-resolution process is based onthe following steps: (i) con¯ict selection, to identify the®rst con¯ict to be solved; (ii) generation of all thepossible solutions to the identi®ed con¯ict; (iii) sol-ution selection, to identify the (best) solution for thecurrent con¯ict.

3. The con¯ict-resolution method

This section focuses on the method of con¯ict detec-tion and resolution. The illustrated method represents

the basis of the intelligent component of MINT,capable of analysing the railway scenario andsuggesting a good replanning strategy, in the presenceof train con¯icts.

3.1. On-line railway tra�c rescheduling

The goal of the decision-support task of MINT isthe construction of a good rescheduling strategy in ashort time. The most time-consuming function ofMINT is the searching in the solution space. The qual-ity of the strategy depends on the solutions selected,which in turn depend on an accurate forecast andweighting, for each alternative solution, of the e�ectson future tra�c evolution. Forecasting requires thateach solution be tentatively applied to the WTT, theworking bu�er containing the pathing of monitoredtrains, to allow an analysis of its e�ects, propagated inspace and time over the monitored area, to be carriedout.

A con¯ict-resolution cycle ends with a modi®edWTT, freed from the current con¯ict. Then, a new,complete, con¯ict-detection step is repeated at everycycle, since the WTT update may signi®cantly modifythe state of things. Indeed, con¯icts, other than theone speci®cally addressed, can be indirectly eliminatedand new con¯icts, not present in the original scenario,generated. Furthermore, con¯icts previously identi®edmay have their parameters modi®ed in the new tra�cscenario.

A rescheduling strategy is represented by a sequenceof con¯ict±solution pairs. A solution is an action thatmodi®es the timetables of the trains involved in thecon¯ict. As anticipated, in the case of a passing con-¯ict, there are two possible solutions for the fastertrain: queuing or passing.

A rescheduling strategy is constructed progressively,repeating the con¯ict-resolution cycle until no morecon¯icts are detected in the controlled area, within themonitored time-window. This complex task is basedon the con¯ict-resolution cycle, brie¯y describedbelow.

Con¯ict detection ± Con¯ict detection is performedby ForeSys, using the WTT, one of the most importantdata structures of MINT. It is used not only for theactual con¯ict-identi®cation function, but also for thefunctions related to the next main task: con¯ict-resol-ution and rescheduling. At the beginning of a controltransaction, WTT is a copy of MTS; it contains onlythe trains that are actually present in the monitoredarea, with their current schedules.

Intuitively (see Fig. 1), each cell wtt(i,k) contains atime-stamp, representing the mean service time of traini at station k (i.e. the central point between arrival anddeparture times). A more precise modeling of stationtra�c is left to the station manager, and is not


addressed in this work. Con¯ict detection is performedby pairwise comparison, in adjacent stations, of thetime-stamps of train services within a given time inter-val. The comparison is performed according to the fol-lowing test:

�wtt�i,k� ÿ wtt� j,k��*�wtt�i,k� 1� ÿ wtt� j,k� 1��< 0:

If the condition holds, a con¯ict involving trains i andj will take place between the adjacent stations k andk + 1. Please note that in the con¯ict-detection phaseit is not necessary to know the exact point of the vir-tual impact. This level is only concerned with the pre-sence of a con¯ict on a line segment.

Con¯ict selection ± In presence of more than onecon¯ict, it is important to establish the order in whichthey will be analysed and solved. There are twooptions: time-based, if earlier con¯icts will be analysed®rst; priority-based, if con¯icts involving the most im-portant trains (e.g. intercity rather than freight trains)will be pre-emptively analysed. The latter approachrequires that a priority be associated to each con¯ict.The priority is given by considering the categories ofthe two trains involved in the con¯ict. For instance,the con¯ict priority is high if an intercity is hinderedby a freight train, but is low if the two con¯ictingtrains have the same category.

Solution generation ± Once a con¯ict has beenselected for resolution, it is analysed, in conjunctionwith the state of the monitored railway area (e.g. con-sidering congestion level, availability of passingtracks), in order to generate one or more possible sol-utions. In general, more than one solution is gener-ated. A solution is a modi®cation to the timing and/orrouting of a train. As anticipated, in the case of a linepassing con¯icts occur, represented by a fast traincatching up a slower one. There are two possible sol-utions: (i) the faster train slows down and proceedsbehind the slower train until the next station; (ii) theslower train undergoes an unplanned stop, on a pas-sing track, waiting for the faster train to overtake.

Solution selection ± Given a con¯ict and a set of sol-utions, it is necessary to select one (possibly, the best)solution to the con¯ict. To this end a weight is associ-ated with each generated solution. A solution inducesa (further) delay to at least one of the two trains. Thelocal weight of a solution is computed as the sum ofthe induced delays, weighted with the train category.Furthermore, it is important to reduce the propagatede�ects of a solution. To this end, the system tries tosolve the problem as close as possible to the placewhere it has been detected (e.g. stopping the slow trainon a passing track as close as possible to the point ofthe con¯ict).

Rescheduling strategy ± It is important to rememberthat, in general, there will be more than one con¯ict tosolve and more than one solution for each con¯ict.

Even in the presence of a single con¯ict, it is possiblethat a solution will introduce new, di�erent con¯ictslater on. Therefore, it is necessary to retain the poss-ible alternatives in the form of a Strategy Tree (ST),with the goal of selecting the best (or at least, a satis-factory) rescheduling strategy, i.e. a sequence of con-¯ict/solution pairs that produces a railway scenariofree of con¯icts. Selecting the best strategy is a hardtask. The proposed method will approximate it byusing heuristic techniques. This is the key issue of theintelligent component of MINT that will be analysedin detail in the next subsection.

Metrics ± One important point to be tackled is thechoice of the goal function that will lead the search forthe winning rescheduling strategy. There are di�erentalternatives, such as minimizing: (i) the sum of alldelays; (ii) the weighted sum (with the train categories)of all delays; (iii) the sum of the square of the(weighted) delays; (iv) the maximum total lateness; (v)the maximum lateness of a selected category of trains.It is possible to construct more-complex functions,based on a combination of the above criteria, includ-ing other aspects as well, such as connections and per-sonnel shifts. In the prototype, agreement was reachedwith railway experts to adopt the (ii) goal function.

3.2. The searching techniques

In principle, ®nding the optimal rescheduling strat-egy requires the analysis of a very large solution space.An exhaustive search is not compatible with the real-time constraint imposed by the application. A basetransaction, consisting of STS update and con¯ictdetection, is required to be performed in less than20 sec. In the presence of con¯icts, the construction ofa rescheduling strategy must be performed in less than2 min. Such a time constraint forces the system toadopt a search technique without the backtrackingoption (forward search only). There are several heuris-tic search techniques that avoid the use of backtrack-ing. In the prototype, for benchmarking purposes, twowell-known techniques were selected: Hill-Climbingand A* (Rich, 1983). In addition, a third techniquewas also studied, which is a balanced mix of the two.

Hill-Climbing (HC) is one of the simplest and fastestsearch techniques. It consists of the analysis of theproblem, one con¯ict at a time, assuming that the beststrategy can be obtained as the sequence of the bestlocal solutions. HC is very e�cient, but the low re-sponse time is paired with low accuracy. It neglects thefuture impact of a given solution on other train ser-vices. In general, a strategy built upon a local opti-mum is not optimal on a global scale. However, thequality of the strategy constructed with Hill-Climbingdepends heavily on the accuracy of the heuristic func-tion, and in particular on the weighting method, used


in the selection of the (local) candidate solution. Acarefully chosen heuristic function, although locallyevaluated, leads to a good global strategy.

A* represents a search technique that, in selecting alocal solution, considers also the induced e�ects, on aglobal scale. It is based on the idea that the cost of astrategy can be decomposed into two components.One is precisely known: the sum of the weights of thesolutions already selected; the second is estimated: thenumber and weight of the solutions required by theremaining con¯icts, before reaching the goal (i.e. atimetable free of train con¯icts). The quality of theheuristics consists of approximating, at every stage ofthe search, the global weight of di�erent competingstrategies, to select the most promising one. More for-mally, the global cost ci,j of a strategy i, after j solutioncycles, is:

ci,j � gi,j � hi,j

where gi,j is the sum of the weights of the j solutionsalready generated; hi,j is the estimated cost of theremaining part of the strategy.

According to the A* technique, it is possible to con-struct di�erent algorithms depending on how (i) thesolution weight is computed, (ii) di�erent partial strat-egies are compared, and (iii) the remaining cost hi,j isestimated.

The issue of cost estimation is a critical one. In the®rst version of the prototype, the railway expertsagreed to experiment within a simple weightingmethod, based on a simple count of the next forecastcon¯icts. More elaborate techniques require severalvalidation tests; to this end future research will use theMINT prototype to conduct experiments on di�erentalternative solutions.

This con¯ict-resolution method is summarized bythe algorithm shown in Fig. 3.

3.3. The strategy tree

Fig. 4 represents a strategy tree, constructed duringa con¯ict resolution process, that identi®es and solvestwo con¯icts in a sequence. The ®gure depicts an

example of a computation carried out according to the

A* technique. In Fig. 4, WTT1 is a copy of MTS,

modeling the initial situation of the railway tra�c. It is

the starting point of the monitoring transaction. The

®rst cycle (performed by ForeSys) identi®es a set of

con¯icts (not represented in the ®gure) and selects C1

as the ®rst con¯ict to be resolved. According to step 3

of the con¯ict-resolution algorithm, two solutions are

generated. Each of these is analysed and its local

weight computed. Then, each solution is temporarily

applied to WTT1, to obtain the two possible tra�c

scenarios (WTT1,1 and WTT1,2). Each new tentative

scenario is then analysed to produce an estimated cost

of the remaining part of the strategy. The ®gure shows

that, applying the solution s1,1, a timetable with three

con¯icts is produced (WTT1,1), while only one con¯ict

will be found if s1,2 is applied. The system therefore

selects the second solution, which is actually the more

Fig. 3. Con¯ict-solving algorithm.

Fig. 4. A strategy tree.


promising. Then, the solution s1,2 is permanently appliedto the original timetable,WTT1, producingWTT2.

Please note that WTT2=WTT1,2 and C2=C1,2,1.Similarly to the previous cycle, the analysis of C2 pro-duces two solutions, temporarily applied to WTT2 andevaluated for their induced e�ects on the railway net-work. This analysis leads to the selection of the ®rstsolution (s2,1), which, once applied, generates WTT3.This version of the timetable, free of con¯icts, rep-resents the rescheduling strategy being sought, there-fore the monitoring process terminates.

In the case of the Hill-Climbing technique, step 4 ofthe con¯ict-resolution algorithm will be limited to thepoint 4a, and the solutions will be assessed locally,without tentatively applying them to WTT to estimatetheir future e�ects.

4. MINT: the TQL++ prototype

This section describes the main issues of the object-oriented prototype of the MINT system, implementedstarting from the conceptual speci®cation expressed inTQL++. The analysis presented in the previous sec-tions has been modeled by means of more traditionaltechniques: functional decomposition of the architec-ture and algorithmic speci®cation of the key function.After the analysis, an object-oriented approach wasused for the design of the tasks and the database ofMINT. In particular, RODB (Railway ObjectDatabase), the MINT database, has been conceivedwith the aim of integrating in one single repository theinformation contained in the three databases illus-trated in the previous section. These databases,although initially appearing to be separated, are tightlyinterconnected with respect to the RTCer tasks. Forinstance, in the presence of a passing con¯ict, it isessential to know the availability of passing tracks onthe headway of the slow train. Checking this avail-ability requires an integrated analysis of the RWI data-base, storing the current operating state of tracks andwayside equipment, and the projected railway tra�c,according to the STS/FTS database (which will givethe future occupancy of passing tracks ahead). Forthis reason, the ®rst architectural choices have been: (i)extraction of relevant data from the original databases;(ii) reorganization of data according to the object-oriented model; (iii) construction of a single, integratedobject-oriented database, gathering all the informationrequired by the RTC process: the RailwayObjectDatabase (RODB). In essence, there is now asingle database that allows for an integrated, object-oriented view over the union of the three original data-bases.

In addition to the objects derived from the scenariodatabases, RODB stores the control objects, produced

and managed during the railway control activities.They represent con¯icts and solutions that, suitablyconnected, form rescheduling strategies.

The object-oriented design of MINT starts with thede®nition of TQL++ types, describing the structuralcomponents of MINT objects, enriched with integrityconstraints (Formica and Missiko�, 1993). Sub-sequently, the behavioural component is added. Forthe sake of conciseness, the latter will only besketched, while the former will be reported in moreextended form.

4.1. Object-oriented information management

The design of the RODB started with the identi®-cation of the entities relevant to the problem, and thede®nition of the corresponding types. For the sake ofbrevity, formal de®nition of the TQL++ syntax isomitted here, in the hope that the reported examplesare su�ciently intuitive (for further detail on the con-ceptual language, please refer to Formica et al., 1996).

Train ± The most important type is the train. Eachtrain object carries the fragment of the timetable con-cerning its journey in the monitored area. The trainjourney is divided into sections, each of which corre-sponds to a run between adjacent stations. The traintype has three complex attributes:

planned_tt set of journey times as originally planned (extracted

from PTT database);

past_tt set of journey times, recorded at the moment of the

transit in the corresponding stations (PTS);

future_tt future timings obtained from the planned timetable

reconciled with the actual history of the train

journey (FTS).

These complex attributes hold the same three subattri-butes: line_section, entry and exit times. In addition tothe above attributes, the train type has further infor-mation, such as the travelling direction on the line andthe category.

Please note that the syntax denotes set-valued attri-butes with curly brackets and ordered sets (i.e. list-valued attributes) with angular parenthesis. Please notealso that set-values can be used with complex attri-butes, implying the repetition of the whole nestedstructure.

train:=[train_nr:integer,delay:integer,planned_tt: < [run:line_section,

entry_time:integer,exit_time:integer]>,

past_tt: < [run:line_section,entry_time:integer,exit_time:integer]>,

future_tt: < [run:line_section,


entry_time:integer,exit_time:integer]>,

direction:(odd,even),category:(intercity,express,local,

ordinary_freight,extraordinary_freight),priority:integer].

It is important to note the mechanism that allowsfor the updating of the time-now line. Every time amonitoring cycle starts, the current time-now is usedto check for each train: (i) if an exit time, in future_tt,has expired and an acknowledge message from thestation is present, then (ii) the 3-tuple correspondingto the line segment just completed is removed fromfuture_tt and is appended to past_tt.

One special case of ``train'' is generated when a fasttrain is queued behind a slow one. This is an anoma-lous situation that must be corrected as soon as poss-ible, allowing the fast train to pass the slow one (forexample, by stopping the slow train in the next stationwith an available passing track). However, from thecirculation point of view this is a safe situation: thetwo trains run together keeping a safe, interlockingdistance. For a queued train, the future_tt representsthe fact that it is running behind a slow train. In ad-dition to that, an extra attribute is needed that recordsthe potential timings, reachable if the obstacle isremoved: make_up_tt.

queued_train: = ISA train[make_up_tt: < [run:line_section,

entry_time:integer,exit_time:integer]>].

Railway ± The railway is represented by the line, itssegments and stations. Each line segment starts andends with a station. The line contains references to thetrains currently circulating. At the beginning of amonitoring transaction the TNL is updated; thereforea train that has only one element in future_tt can beremoved from line.current_trains. It means that thetrain has left the line and is then in the charge of theneighbour railway control area. The railway is rep-resented by an ISA hierarchy of railway elements.

railway_elem:=[code:string,start_km:integer,end_km:integer,elem_type:(station,segment,junction,

line,line_section)];&

station: = ISA railway_elem[tracks:integer,avail_tracks:integerelem_type:(station)];&

line: = ISA railway_elem[current_trains:{train},sections: < line_section>,elem_type:(line)];&

line_section: = ISA railway_elem[section_begin:station,section_end:station,elem_type:(line_section)].

The above types are concerned with the informationmanagement of the railway scenario. The correspond-ing objects are extracted from the RWI database. Thenext subsection models the types concerned in the de-cision-support task.

4.2. Object-oriented decision-support task

Here the two main concepts are con¯icts and sol-utions. They are modeled by interconnected types.With this modeling solution, the key structure beingmanaged during the con¯ict-resolution process, i.e. thestrategy tree, does not exist per se, as an instance of adeclared type. Instead, the strategy tree will coincidewith the graph of the interconnected con¯ict and sol-ution objects.

The monitoring transaction starts by updating thetime-now line; it can be seen as the moving from leftto right of the solid polyline of Fig. 1. In RODB theMTS table is not materialized; it exists virtually, as thesum of the components of train objects. Therefore, aTNL update is implemented by updating the trainobjects and their timetables. Having updated the time-now line, the monitoring process starts trying to ®ndtrain con¯icts.

Con¯icts ± This type models a generic binary con¯ict(it is always assumed to occur between two trains) thatwill take place in a given line segment, at a given time.Depending on the characteristics of the trains, theplace, and other factors, one can associate a weight toit.

generic_con¯ict:=[train1:train,train2:train,con¯_type:(passing,crossing,switching),place:line_segment,time:integer,weight:integer].

For each identi®ed con¯ict a new object is created. Itstores the reference to the two trains involved in thecon¯ict, the place (line segment) and time, and thetype of con¯ict. Con¯icts, as well as solutions, whichwill be formally de®ned below, are types of objectsthat belong to the kernel of the railway control task.


Please recall that, in general, there are three kinds ofcon¯ict. A passing con¯ict occurs when a fast trainencounters a slow train on its headway. A crossingcon¯ict occurs on bi-directional lines when two trainsrunning in opposite directions need to use the sameline segment. Switching con¯icts mainly occur in theapproach area of a station, if two trains are enteringin parallel and their paths have a common switch, sup-posedly traversed at the same time. This work concen-trates on passing con¯icts ( p_con¯icts), but theproposed method is easily generalized to crossing con-¯icts. Switching con¯icts are not of interest to traintra�c controllers, but rather to station operation con-trollers.

In case of a p_con¯ict, one additional item of infor-mation must be speci®ed in the case of two track lines:the track on which the two trains are circulating.Conventionally, the tracks are indicated as ``odd'' or``even''. The former refers to trains running south-bound or eastbound, the latter indicate the oppositedirections.

p_con¯ict: = ISA generic_con¯ict[direction:(odd,even)].

In a monitoring transaction, in general, several con-¯icts are identi®ed. The ®rst decision that a RTCermust make is about the order in which the con¯ictsshould be tackled. There are di�erent alternatives; thesimplest is that of analysing the con¯icts in chronologi-cal order. In this case, the ®rst p_con¯ict is consideredas the candidate_con¯ict and a nested transaction istriggered, aimed at constructing all the possible sol-utions for this con¯ict.

candidate_con¯ict: = ISA p_con¯ict[proposed_solutions:{solution}].

Once the set of proposed_solutions has been generated,the system identi®es the solution that should beapplied, and the con¯ict migrates to its ®nal state ofsolved_con¯ict.

solved_con¯ict: = candidate_con¯ict[chosen_solution:candidate_solution];ic: this.chosen_solution in this.proposed_solutions.

As can be seen from the type declaration, a solvedcon¯ict is an immediate child of candidate_con¯ict,from which it inherits the attributes de®ned there. Inaddition, there is the attribute concerning the chosen_-solution, which stores an element of the set-valuedattribute proposed_solutions. This feature is modeled asan integrity constraint, constructed by using the set-membership operator in.

A ®nal type of con¯ict is connected to the resolutiontechnique of MINT, as already described. In the sol-

ution-®nding transaction there is a need to identify allpossible remaining con¯icts, referred to as virtual_con-¯ict, after which the current one has been solved.Virtual con¯icts are used by the A* algorithm to esti-mate the global cost of a given strategy.

virtual_con¯ict: = ISA generic_con¯ict[strategy_code:integer].

Solutions ± A solution to a con¯ict essentially com-prises one or more actions to be undertaken in orderto avoid the actual occurrence of a forecast con¯ict. Indealing with passing con¯icts, one can introduce a ®rsttype, generic_solution, that contains information aboutthe two trains involved in the con¯ict, the actions thatcan be performed on either train and, in the case ofpassing, the station where the slower train will standaside.

generic_solution:=[slow_train: train,fast_train: train,slowTrain_action:(stop,none),fastTrain_action:(queue,none),stopping_site: station];

ic_solution1:NOT(this.slowTrain_action =``none'' ANDthis.fastTrain_action = ``none'')

ic_solution2:NOT(this.slowTrain_action = ``stop'' ANDthis.fastTrain_action = ``queue'')&.

Since a generic solution can consist of either passing(if the faster train wins) or queuing, an integrity con-straint, ic_solution, was introduced, which guaranteesthat a solution's objects contain only one pair ofmeaningful actions. The existence of a null value forthe station class (null_station) is assumed to be used incase of the queuing solution object (this object will beupdated to a passing solution as soon as the scenariowill allow it).

For each con¯ict, more than one solution can begenerated. In order to select the candidate one, eachsolution object is weighted. The decision procedure,described in the previous section, requires an estimateof the e�ects of the choice on the scenario ahead_cost,corresponding to the hi,j summand in the expression ofSection 3.2. The past, computed cost, is summed withthe cost of the current solution to give the local_cost(summand gi,j). This cost is added to the estimate offuture costs, yielding the global_cost, which will deter-mine which solution will be the candidate one.

weighted_solution: = ISA generic_solution[local_cost:integer,ahead_cost:integer,global_cost:integer];


ic_weight_sol:this.global_cost = this.local_cost + this.ahead_cost&.

Having computed all the necessary parameters, the sys-tem selects the candidate_solution. This type of objecthas an explicit reference to the current con¯ict. Then,the commitment to the selected solution causes anupdate of the WTT (essentially the future_tt of thetrains involved) and the migration of the candidate_so-lution into the implemented_solution class.

candidate_solution: = ISA weighted_solution[processed_con¯ict: candidate_con¯ict]&

implemented_solution: = ISA weighted_solution[con¯ict: solved_con¯ict]&.

The latter solution type has a reference to a solved_-con¯ict, which in turn is the natural evolution of a can-didate_con¯ict. Please note that a solved_con¯ict isstored in the RODB only for statistical purposes, sinceit has been removed from the current, updated WTT.

4.3. Behaviour modeling

The most signi®cant part of MINT, beside the de-sign of RODB schema, is the set of transactions aimedat discovering and solving train con¯icts. The actionsthat implement these transactions are brie¯y presentedbelow.

Monitoring and con¯ict identi®cation. A periodictransaction aimed at discovering the possible con¯icts.This transaction also has the task of updating thetime-now line and recording the deviations (delays orearly running) in the current and projected timetablesof the trains.

Con¯ict selection. This transaction starts after themonitoring has completed. It analyses all the con¯ictsand determines the ®rst one to be solved (i.e. candida-te_con¯ict).

Con¯ict resolution. This transaction aims at ®ndingsolutions for the candidate con¯ict selected. It will pro-duce all the possible solutions, and delegates to thenext transaction the selection of the candidate one.

Solution selection. Having weighted all the solutionsproduced by the previous transaction, a candidate sol-ution is selected.

Solution application. The selected solution is used bythis transaction to update the WTT. Actually, it a�ectsthe future_tt of the train that will lose the con¯ict (the``winning'' train will continue its journey as planned).

After the completion of the last transaction, thereleased WTT will be free of the candidate con¯ict(but new, ongoing con¯icts could have been gener-ated). Then a new monitoring transaction is needed to

identify other con¯icts or, in the case of an absence ofcon¯icts, to terminate.

It is important to recall that the con¯ict-resolutioncycle, reported above, is di�erent for di�erent searchtechniques. In the MINT prototype three techniqueswere implemented, brie¯y recalled below, aimed at theconstruction of the strategy tree.

Section 3 described the heuristic techniques thathave been adopted to solve the problem. These tech-niques have been revised and integrated in an object-oriented frame. Furthermore, the detailed analysisidenti®ed three levels of resolution techniques that canbe selected, depending on the degree of congestion andthe importance of the abnormality. In any case, noneof the selected techniques includes backtracking, whichis too time-consuming for this application.

Hill-Climbing ± This technique is known to be fast,to the detriment of accuracy. It is selected automati-cally by the system in situations of high congestion,when satisfactory solutions are good enough, if quicklyformulated.

A* ± The key aspect of this technique is the estimateof the cost of the e�ects of applying a solution. Tocompute these costs, it is actually necessary to modifythe WTT for each possible solution and estimate thefuture costs, in terms of possible forthcoming con¯icts.In the object-oriented approach there is no materializa-tion of the WTT; it is represented by the timetables as-sociated to train objects. The analysis of the futuree�ects of a candidate solution implies the generationof new train objects with tentative timetables, thatform a future possible world. The system needs to con-struct many possible worlds and analyse them com-paratively to select the most promising one.

Mixed technique ± This technique is a compromisebetween the speed of the former and the accuracy ofthe latter. It is based on the idea that early con¯ictsmust be processed urgently, when a certain suboptim-ality is acceptable, while for con¯icts further away intime, it is possible to spend more time searching formore accurate solutions. In this perspective the moni-tored time-window was divided into a ®rst critical zone(15 min from time-now line) and a secondary zone(15±45 min past the time-now line). Hill-Climbing andA* are applied in the former and latter zones, respect-ively. It is important to note that in the secondaryzone the con¯icts are not necessarily analysed inchronological order, but in order of importance, usingan approach drawn from the human RTCer beha-viour.

The object-oriented conceptual model of MINT,brie¯y described in this section, consists of 27 typesand 43 actions: approximately 650 lines of TQL++code. This analysis and speci®cation activity has beensupported by the Mosaico system, which, among otherfeatures, allows executable code to be automatically


generated, starting from the TQL++ speci®cation. Inthis way a ®rst prototype of MINT was produced.

5. Experiments with the MINT prototype

This section describes the experiments carried outwith the prototype of MINT. The MINT prototype, inits executable form, corresponds to approximately12 MB of executable code. The experiments have beencarried out on a Sun SparcStation 10, with 32 MB ofmain memory.

The experiment had the primary goal of verifyingand validating with the users (representatives of rail-way operation controllers) that the conceptual modelwas correctly re¯ecting the way they address and solverailway tra�c control problems (®delity of the concep-tual model). The validation concerned:

. Information content of the RODB, ®rst presentedto the RTCer in the form of an object-oriented data-base schema, i.e. the de®nition of the object types.

. Data and knowledge management functions, essen-tially the possibility of introducing sample data andinteracting with the system for query and updateoperations.

. Decision process. The implemented method wasagreed with the domain experts in the analysisphase. Then the RTCers could check that their sug-gestions and directions were correctly speci®ed inthe design model, and the corresponding operationswere behaving accordingly.

. E�ciency, in terms of the response time. One keyconstraint was that the whole decision cycle shouldlast no more than 2 min, in order to give the possi-bility to the RTCer, in a congested scenario, to use theoutput ofMINT and take a decision within 3-5 min.

. E�ectiveness, in terms of the merit of the proposedsolution. In particular, having three searchingmethods to test, it was desirable to see which onecould perform better and give better results, indi�erent situations.

The design validation was done partially on paper, byinspecting the TQL++ speci®cation, and partially onthe prototype generated by means of Mosaico. Thenthe tests were set up on a real scenario, loading rail-way tra�c data. The latter has been the ®rst opportu-nity to check the conceptual model of MINT with realdata, supplied by the CCL (Command and Control ofthe Line) computer centre, currently in operation onthe Rome±Naples line (which represents the selectedtest ®eld).

5.1. The scenario and the test case

The choice of the test case was agreed with therepresentatives of the railway company and RTC

experts. The test ®eld is represented by a double-trackline, 129 km long (ca. 80 miles), south of Rome. Therailway tra�c data concerned the trains circulating inthe morning of a typical working day. Other detailsare summarized in Table 1.

Starting with this scenario, 10 of the most signi®canttrains were extracted, and an initial delay of 30 minwas imposed on one of these. In so doing an abnorm-ality was introduced in the scenario, and MINT wasactivated to detect the con¯icts caused by the delay,and to try to solve the problem by rearranging thetimetable. To collect su�cient data the monitoring/con¯ict-resolution process was activated at di�erenttimes. Essentially this was obtained by moving thetime-now line (which represents the starting point ofthe control cycle) to di�erent positions within themonitoring time-window. This yielded measures thatcorrespond to ®ve positions of TNL: from 510 to 550,with an increment of 10 min at each step (the times arereported in minutes from midnight).

5.2. E�ciency: required time for a control cycle

In the experiment, the two basic techniques wereanalysed: Hill-Climbing and A*. The former wasexpected to be faster but less e�ective than the latter.In the two histograms, in Figs. 5 and 6, the averagetimes required by the two techniques are shown. Theprocessing time has been given for each of the sixbasic steps of the con¯ict-resolution decision cycle:

Monitoring and con¯ict identi®cation (Cft Find),Con¯ict selection,Solution production (Sol Prod),Solution weighting,Solution selection,Solution implementation.

As could be expected, the main di�erence between thetwo techniques is in the fourth step: solution weight-ing. In fact, in the case of the HC only the local weightof each solution is computed, while for A*, the systemneeds to analyse the future e�ects caused by the appli-cation of each possible solution. To this end, the time-table is updated and analysed for a number of timesequal to the number of solutions produced. Please

Table 1

Details of the test case

Starting station: Roma Termini

Ending station: Formia

No. of stations: 13

Circulating trains, on 24 h: ca. 380

Monitored time-window:

width: 1 h 30

starting at: 8:30 am (510 min past midnight)


note that the ®gures reported in the histograms rep-resent the averages of the computation times obtainedin all ®ve tests, for which the number of con¯icts wasapproximately 2.5, on average.

It is interesting to note that the MINT prototypewas fast enough to cope with the original time con-straints indicated by the representatives of the users.In particular an average response time of 9 and 30 sec

Fig. 6. H2: A* con¯ict-resolving steps (time in sec); A*.

Fig. 5. H1: Hill-Climbing ± con¯ict-resolving steps (time in sec).


was obtained for HC and A*, respectively. This is thecost of a single con¯ict-resolution cycle. The completerescheduling transaction is performed in one or morecon¯ict solving cycles. The time required by a cycle isbarely in¯uenced by the total number of con¯ictsfound, since at each cycle only one con¯ict is selectedfor resolution. However, the number of con¯icts issomehow related to the number of cycles to be per-formed before the WTT is released free of con¯icts.

As will be seen in the next subsection, the worst caserequired seven cycles, which is acceptable for HC (inef-®cient but fast) but is in principle too much for A*. Infact the whole rescheduling transaction required 54and 210 sec for HC and A*, respectively. However, itshould be noted that, from previous experiments onselected functions, it was discovered that, when usingan e�cient programming language (e.g. C++) and awise software engineering approach, it is possible toincrement the performances of a TQL++ prototypeby a factor of 3 to 8, therefore proportionally reducingthe response time.

Therefore, it can be concluded that the result of therapid prototyping gave important data on the indus-trial feasibility of systems of the class of MINT.

5.3. E�ciency: number of con¯ict solving cycles

The present measure indicates the number of cyclesrequired to clean up the scenario and release aWTT freeof con¯icts (within the 45 min interval from the TNL).

Fig. 7 gives a histogram showing the number of con-¯ict-solution cycles required to perform a reschedulingtransaction when using the HC technique. The resche-duling has been activated at ®ve di�erent moments,starting at 510. For each transaction, the number ofcon¯icts identi®ed at each con¯ict-resolution cycle isshown. It can be seen that the most expensive trans-action was the 520 one, having identi®ed three con¯ictsin the ®rst two cycles. It required a total of six cyclesto terminate. Transactions starting after 520 are get-ting shorter since the monitored window gets smaller(the arrival of new trains and the consequent WTTupdate were not simulated).

Similarly, in Fig. 8 the histogram concerning the A*

technique is reported. Quite surprisingly, in the ®rstreplanning task, started at 510, A* performed muchmore poorly than its competing HC technique. In factit required one additional con¯ict-resolution cycle(seven instead of six). Furthermore, it seems that thetechnique is non-monotonic, in general. In fact, in therescheduling transaction starting at 510 a bounce isseen in the fourth cycle: the solution of a con¯ict hada negative e�ect overall, and from two con¯icts incycle 3 it jumps to four con¯icts in the next cycle.Another bounce is presented at cycle 6, where thereare two con¯icts, compared with one con¯ict in theprevious cycle. This phenomenon is further strength-ened by the behaviour of the rescheduling transactionstarting at 530. Here too the second cycle presents arebound with respect to the previous one. In fact thesolution selected by A* did solve a con¯ict, but at the

Fig. 7. H3: Hill-Climbing ± number of con¯icts for each con¯ict-resolving cycle; H6 (®ve con¯ict-resolving transactions).


same time introduced two more con¯icts, causing anincrease from three to four con¯icts.

Looking more carefully at the histograms, one cansee that in the replanning task triggered at 520, A*takes only three control cycles, while HC requires sixcycles. In reality this is a factor 2 that does not com-pensate for the factor 3 in terms of the time requiredto perform a single cycle. Nevertheless, this experimentdoes show that there are scenarios in which A* per-forms better. This is particularly interesting if, in theengineering phase, the programmer introduces signi®-cant improvements in the implementation of the A*,aiming at reducing the factor 3 in the processing time.

5.4. E�ectiveness of heuristic techniques

Now consider the results of the experiments in termsof the e�ectiveness of di�erent techniques. The exper-iment started with a delay of 30 min, all assigned toone train, causing a total of three con¯icts. The endproduct is a WTT free of con¯icts but with an incre-ment of delayed trains. The total minutes of additionaldelays introduced at the end of the rescheduling trans-action can be measured.

Following an indication given by the domainexperts, two di�erent metrics were considered to assessthe merit of a rescheduling process: one in terms of

total minutes of delay introduced, and the other as the

sum of the delays weighted with the categories of the

trains. The second metric allows one to cope with situ-

ations in which a greater delay, if assigned to low-cat-

egory trains (e.g. local and freight trains) has a limited

importance.

The analysis of the results shows that from all points

of view the simpler technique, Hill-Climbing, is more

e�ective than A*. The ratio is signi®cantly in favour of

HC, equal to 6.25 in terms of additional delays and

6.97 if weighted delays are considered.

The experiment was then repeated with a di�erent

philosophy in the choice of the con¯icts to be solved

at each control cycle. The results presented above con-

cerned con¯icts selected in chronological order, that is

closer con¯icts are selected ®rst (time-based selection).

A subsequent experiment reports the results obtained

when the con¯ict selection is performed on the basis of

the category of the trains (priority-based selection). In

practice a con¯ict involving two trains with the largest

di�erence in categories is selected ®rst.

The results showed that the former technique (time-

based selection) leads to better performances for both

HC and A* techniques.

Fig. 8. H4: A* ± number of con¯icts for each con¯ict-resolving cycle; A* (®ve con¯ict-resolving transactions).


6. Conclusions

In this paper the main lines of the MINT projecthave been presented. They concern the analysis, de-sign, and rapid prototyping of a prototype aimed atsupporting the work of railway tra�c controllers. Tothis end, MINT combines information managementand decision-support functions in a single, tightly inte-grated system. Such an integration has been realisedby means of an object-oriented approach (Missiko�and Vazzana, 1993), and all the development has beensupported by Mosaico. Mosaico is a software environ-ment for the analysis, design and rapid prototyping ofcomplex object-oriented, data-intensive applications.The speci®cation of an application is constructed byusing the TQL++ conceptual language, starting fromwhich a rapid prototype is automatically generated.The rapid prototype of MINT has been used to carryout the experiments described, whose results are sum-marized as follows.

The integration of the informationmanagement andcon¯ict-resolving functions is feasible and advisable.The resulting system uses an integrated object-orienteddatabase (RODB, in this implementation) that appearsto be both e�ective and ¯exible.

The availability of the running prototype allowedexperiments to be conducted on the design of MINTon real railway tra�c data, and to derive a quantity ofuseful information.

Useful results were gathered on the search tech-niques, used to construct the replanning strategy in thepresence of train con¯icts.

The most interesting conclusion is that in thisapproach, when comparing a simple technique, Hill-Climbing, with a more advanced one, A*, it turnedout that the former was outperforming the latter.

The lesson learned is that in complex problems asimpler solution performs better. In fact, to take ad-vantage of a more sophisticated solution it is necessaryto undertake signi®cant work in tuning the underlyingmechanisms (such as the cost evaluation for the sol-ution selection). In the absence of such ®ne-tuningrequired by a complex technique, it is better to choosea simpler one.

Acknowledgements

Work partially supported by ``Progetto Finalizzato,Trasporti 2'', Research line 3.2.1, of CNR. Thanks aredue to Pier Luigi Guida for the time he spent in read-ing the manuscript and helping to improve its contentand form, also to Marco Caporro for the massive

amount of work carried out on MINT and on the sup-porting environment, Mosaico.

References

Araya, S. and Fukumori, K. (1984) ESTRAC-II: An expert system for

train tra�c control in distributed situations. In Proc. ECAI-84, Pisa,

September.

Carey, M. (1994) A model and strategy for train pathing with choice of

lines, platforms, and routes. Transportation Research-B, Vol. 28B,

No. 5. Pergamon Press.

Formica, A. and Missiko�, M. (1993) Integrity constraint represen-

tation in object-oriented databases. In Information and Knowledge

Management, eds T. W. Finin, C. K. Nicholas and Y. Yesha,

LNCS 752. Springer-Verlag.

Formica, A., Missiko�, M. and Pizzicannella, R. (1996) TQL++

User Manual ± Vers. 4.2. Technical Note IASI-CNR, Rome,

November.

Jovanovic, D. and Harker, P.T. (1991) Tactical scheduling of rail op-

erations: The SCAN I system. Transportation Science, 25(1), 46±64.

Khosha®an, S. and Abnous, R. (1990) Object Orientation: Concepts,

Languages, Databases, User Interfaces. John Wiley.

Lagana, A., Maestrini, E., Paganelli, G. and Ripamonti, P. (1994)

Command and control systems in the light of European projects.

In Proc. WCRR ± World Congress on Railway Research, Paris,

September.

Missiko�, M., Toiati, M. 1994 MOSAICO ± A system for conceptual

modeling and rapid prototyping of object-oriented database appli-

cations. In Proc. ACM SIGMOD Conf., eds R. T. Snodgrass and

M. Winslett, Minneapolis, May.

Missiko�, M., Vazzana, S., 1993. An object oriented approach to

structural knowledge-bases. Int. J. Control and Computers

(Canada) 21 (2), 52±60.

Rail et Recherche (1995) Special Issue on World Congress on Railway

Research, No. 5, January.

Rawlings, D. (1994) Control center of the future gives operators the

means to regulate e�ectively. Railway Gazette International. RB

Publishing, Sutton, U.K., September.

Rich, E. (1983) Arti®cial Intelligence. McGraw Hill.

Dr. Michele Missiko� is a Senior Sta� Scientist atIASI, the Institute for Systems Analysis andInformatics, of CNR, the Italian National ResearchCouncil, in Rome, Italy. His main interests are in dataand knowledge bases, and object-oriented knowledgerepresentation for OOA&D. He leads the Mosaicoproject, which includes the development of an exper-imental system for object-oriented conceptual model-ing. The Mosaico methodology has been used inexperiments in a number of application ®elds; cur-rently, in the area of strategic decision support andbusiness process modeling. In his activities he hasauthored over 100 papers, which have appeared inbooks, journals and conference proceedings. He is aco-founder and president for almost a decade of theEDBT (Extending Database Technology) Foundation.Currently, he is member of the National Committeefor Computer Science Research Programs of CNR.


Documents

An Object-oriented Approach to an Information and Decision Support System for Railway Traffic Control