Timetabling for suburban railway operations

Preparation of suburban timetables in Mumbai is a skilled and highly sensitive task undertaken by the railways. It takes a few months of detailed discussion, data collection, analysis and finalisation every year, done by experienced persons in the railway organisation. It requires input from multiple departments, commercial, operations, safety, signaling, track, electrical (rakes), traction, etc. to finally come up with a "good" timetable.

The team at IIT Bombay has been designing and providing semi-automated support for a variety of planning decisions involved in the preparation of timetables. These are at various levels of detail and hierarchical planning.

Level 1:The simplest one is for visualisation and monitoring of existing timetables and platform occupancies.

Level 2: A further level is to facilitate incremental changes to timetables, starting from an existing one. Here, it is required to verify the operational feasibility and achieve performance goals of service as well as asset optimisation, while maintaining continuity with an existing operational plan.

Level 3: A final level is to be able to automatically generate timetables (perhaps from scratch and perhaps radically different from existing ones) which satisfy all operational constraints and which "optimise" performance in various dimensions.

The last level of timetabling is a difficult task both technically and organisationally. It is technically difficult as it involves a very large number of operating variables (of rake usage, train timings at stations and platform occupancies) and a huge number of constraints (headway because of track availability, platform availability, number of rakes, signalling and overhead traction constraints) and a large number of objectives as well (mix of services, starting location benefits and transit time benefits to customers as well as supply side measures of efficiency and reliability). It is organisationally difficult for the same reason, that a number of different departments and entities are involved, both from the railways as well as the customer side. A tool has been designed to look at this large problem in totality - at least for the technical part of the problem - but it is still far from being deployable realistically.

We briefly describe the first two levels of application.

Part 1: Charting and visualisation Tool

The charting tool is designed to represent, graph and print the Master Chart or Working Timetable of a section on Indian Railways. It is useful for viewing, analyzing and perhaps modifying (preponeing/postponing) the timings of selected services in a given time window. The main feature is the automatic display chart utility, which has a view panel, which displays the services from the timetable. The output is a panel containing a distance vs time view of different services in a given time interval (typically, 6, 8 or 24 hours).

For each section of interest, the inputs are the description of the network, timings for long distance up/down services at specified stations, details of block timings and stations.

The following are some of the major applications of the tool.

Part 2: Timetabling support for incremental modifications to operating plans

A set of further utilities have been designed based on a common database to allow a timetabler to check the operational feasibility of simultaneous movement of several trains according to a proposed plan. The three main constraints are track usage, station platform occupancy and rake availability. The rake constraint is handled separately (but with appropriate linkages) by the Rake Management System.

An abstraction that is useful here in suburban services is that of a pattern manager, which captures typical train service descriptions and uses them to facilitate the movement (preponement/postponement) of a certain service or to introduce a new service of a certain type.

In this application, the timetabler is in charge of deciding what set of services to run and the utilities described above help her to check constraints, and move them if necessary. This is done in a tabular as well as charting mode as per the convenience of the timetabler. The outcome is finally used in conjunction with the Rake Management System.

For a final operational plan, there has to be a crew allocation system as well, which assigns crew sets to various services. A preliminary version of this has been proposed.