Railway Delay Management

Models, Algorithms and Evaluation

The Mission
In this game, you have to deal with the following items: Sets of trains, railway stations, tracks between the stations, passengers who want to travel, and a plan for the trains.

If you call the stations nodes, and the tracks edges, nodes and edges form a graph. The edges of the graph have a FIFO-property, which means that you can have several trains on the same edge at the same time, but the train which enters an edge as first, will also leave it as the first. Usually, the edges are directed, but some of them may have the property that their direction can be reversed at certain points of time. A plan tells us, which trains leave and enter which stations at what time.
Moreover, there are passengers, who would like to travel from some origins to destinations. They use a fixed, pre-determined path. At a certain point of time, i.e. their desired starting time, they travel to their start station and take the next train that follows their desired path.

The pitty with this game is that the travel times of the trains from one station to another one is not deterministic. The travel times are only known in form of probability distributions. Thus, trains may arrive later than planned. On the one hand, if a train T arrives late at a certain station, it might be useful to make another train S wait for T, because a lot of passengers desire to change the train from T to S. On the other hand, it might be more profitable not too wait for T, because lots of passengers would then be delayed. A controller has to decide case by case, when a train has to wait for another one, and when not. Additionally, we might also provide another plan in advance, a plan which is more robust against disruptions.

The task is to find a good plan and/or control strategy, such that all passengers reach their destinations, and such that the weighted sum of all travel times of all passengers is minimized.

We have developed a framework for testing such waiting policies. A server is running the schedule and sending out queries, and another program, called the Engine, is supposed to answer these queries. Both are connected via a game client that also provides a graphical user interface and a visualization. Below you find more details about the model that is running on the server and about how to implement your own waiting policy as an Engine. Three simple Engines for testing and presenting are available below. An Engine using Monte Carlo tree search is work in progress.

 

The Model
In our model stations are called nodes and tracks will be directed edges. The nodes and edges form a directed graph on which the trains can move. There may be (physical) tracks that can be used in both directions. These will be modelled as two distinct directed edges, and the server makes sure that only one of these two edges is used at any time. The edges have the FIFO property, i.e. the trains leave an edge in the same order that they entered that edge.
The server will keep an EventQueue that is sorted by time, from which it will generate queries to the Engine. Initially, the EventQueue contains for each train one event at the time that the train is scheduled to start.
The server will the run the following loop until the end of the schedule has been reached:
  • Collect queries at current time from the EventQueue.
  • Send a query message to the Engine.
  • Receive a result message from the Engine.
  • Commit the answers from the result message, if possible.
  • Sample delays for trains that in fact have left a station.
  • Send message about committed decisions and sampled delays to the Engine.
Here are a few more details about how the server methods work:

Collect queries: only those queries will be collected, that could potentially be implemented. E.g. if a station or track is full, a query asking if a train can enter that station or that edge, respectively, will not be sent to the Engine. All queries that are sent to the Engine will be removed from the EventQueue.

Committing answers: unless a train has reached its final destination, for every query that was sent to the Engine, a new event is generated and added back into the EventQueue. This will be done in different ways, dependingon whether the query was committed or not.

Other details: Each edge and each node has a capacity which limits the number of trains that can be in that node or on that edge at the same time. Each edge has a timeslag, which represents the minimum time that has to pass between two trains entering that edge or leaving that edge. There are constants MIN_HALT_TIME and MIN_CHANGE_TIME, which represent the minimum time a train needs to halt in a station and the minimum time a passenger needs to change trains in a station.

The objective function: The objective function currently implemented by the server is the total delay of those passengers that arrive at their final destination, plus a constant value MAX_COST_PER_PASSENGER that is accrued for every passenger that does not reach his/her finald estination due to delays and missed connections. The passenger routes are given a-priori and passengers and trains cannot be rerouted.

 

Connecting to the Competition Server
If you have Internet access, you can use a game client (with GUI) to connect to our server. If you aim at developing an intelligent controller for our simulation world, you have to write a stand-alone console program, which connects to our game client. Your controller - we call it the engine - can then be started with the help of the client program. If your engine follows the game dependent text protocol, it can participate. Your engine does only exchange messages with the client program, all communication between client and server via Internet is hidden for you and fully transparent. An easier way to develop a working optimization engine is to use an existing client-library.

 

Downloads


Link

Version

Description

GUI.zip

0.8.4 (14.10.2008)

Game Client and Graphical User Interface. Used to connect to the competition server, to connect an Engine, and for Visualization. The GUI is started with 'java -cp GUI-0.8.4.jar:Game_3u4.jar topsu.GUI' (unix) or 'java -cp GUI-0.8.4.jar;Game_3u4.jar topsu.GUI' (windows). It is recommended to create a folder 'Error' in the same directory where you start the GUI. Instructions.

RdmBasicEngine.jar

0.8.4 (14.10.2008)

Implementation of a basic Engine creating and maintaining all data structures as they are on the server. Requires GUI.jar. See javadoc for all available classes.

YesEngine.jar
RandomEngine.jar
WaitEngine.jar


Example Engines. These Engines require RdmBasicEngine.jar. All Engines implement the answerQueries() method in RdmBasicEngine differently. By passing the -l option, these engines will write a .log file containing the communication with the server.
YesEngine: Answers every query with YES.
RandomEngine: Randomly answers YES with probability p. The probability p can be set by passing the parameter -p=<float>. By default p=0.5.
WaitEngine: Lets all connecting trains wait. Every passenger will reach his/her destination using those trains as originally scheduled.

YesEngine.java


Example java code to implement your own Engine. Replace the answerQueries() method and getIdentification() method by your own methods. See the javadoc of the RdmBasicEngine for details.

.NET game client

1.2 31.07.2007

Game Client and Graphical User Interface. Used to connect to the competition server, to connect an Engine, and for Visualization.

Never-Wait-Engine executable

1.2 31.07.2007

Simple engine that never waits for passengers, C++/.NET-Exe

RDM1_BahnMicro.sql


Instance data for the BahnMicro example.

RDM1_datamodel.txt
RDM1_majorclasses.txt
RDM1_simulation.txt


SQL based data definition.
Some class definitions.
Rough simulation description.


Contact

Ulf Lorenz (flulo'at'upb.de)
Andre Berger (berger'at'math.tu-berlin.de)
Ralf Hoffmann (rhoffmann'at'math.tu-berlin.de)

Index A – Z | Impressum | Webmaster | Modified: 10.05.2005