Download 264.93 KB

Technical Assistance Consultant’s Report

Project Number: 36330-02 (Technical Assistance No. 4998) March 2009

INDIA: Railway Sector Investment Program (Financed by the Japan's Special Fund)

Prepared by

Scott Wilson Railways Ltd, United Kingdom During the period of engagement from 27 March 2008 to 7 November 2008

For Ministry of Railways Rail Vikas Nigam Ltd

This consultant’s report does not necessarily reflect the views of ADB or the Government concerned, and ADB and the Government cannot be held liable for its contents. (For project preparatory technical assistance: All the views expressed herein may not be incorporated into the proposed project’s design.

Asian Devlopment Bank Railway Investment Programme

Sambalpur to Titlagarh

RailSys Report March 2009

www.scottwilson.com

Revision Schedule

RailSys Report 06 March 2009

Rev Date Details Prepared by Reviewed by Approved by

01 06 Mar 2009 First Issue Jonathan Rix Adam Newman David Coles Graduate Operations Operations Analyst Engineering Director Analyst

Scott Wilson Tricentre -3 Newbridge Square Swindon This document has been prepared in accordance with the scope of Scott Wilson's SY 11BY-UK appointment with its client and is subject to the terms of that appointment. It is addressed to and for the sole and confidential use and reliance of Scott Wilson's client. Scott Wilson United Kingdom accepts no liability for any use of this document other than by its client and only for the purposes for which it was prepared and provided. No person other than the client may copy (in whole or in part) use or rely on the contents of this document, without the prior Tel +44 (0) 1793 508610 written permission of the Company Secretary of Scott Wilson Group plc. Any advice, opinions, or recommendations within this document should be read and relied upon only Fax +44 (0) 1793 508511 in the context of the document as a whole. The contents of this document do not provide legal or tax advice or opinion.

www.scottwilson.com Asian Development Bank Railway Investment Programme

Table of Contents

Definitions ...... 1 Abbreviations ...... 2 1 Introduction ...... 3 1.1 Background...... 3 1.2 Scott Wilson Railways ...... 3 1.3 Requirements ...... 3 1.4 The Network ...... 4 2 RailSys...... 5 2.1 RailSys Overview...... 5 2.2 RailSys Limitations ...... 7 3 Model Development...... 8 3.1 Computer Software...... 8 3.2 Process...... 8 3.3 Source Data...... 8 4 Model Verification ...... 10 4.1 Sectional Running Time Tolerances...... 10 4.2 Punctuality Comparison...... 10 5 Existing Performance...... 11 5.1 Infrastructure...... 11 5.2 Timetable...... 11 5.3 Delay Data...... 11 5.4 On-Time Performance ...... 12 5.5 Spread of Train Delays over the Network...... 13 6 Double Track Performance...... 15 6.1 Infrastructure...... 15 6.2 Timetable...... 15 6.3 Delay Data...... 15 6.4 On-Time Performance (Timetable 1) ...... 15 6.5 Spread of Train Delays over the Network (Timetable 1)...... 16 6.6 On-Time Performance (Timetable 2) ...... 18 6.7 Spread of Train Delays over the Network (Timetable 2)...... 19 7 Conclusions ...... 21

Asian Development Bank Railway Investment Programme

Definitions

Term Definition Conflict A clash of operational actions where one train may be delayed while another moves across its path.

Dwell Time The timetabled time, at which a train stands at an intermediate station, so that passengers can board and alight.

Headway The minimum interval permitted between successive trains on a particular section of track.

Interlocking The setting and releasing of Signals and Points to prevent unsafe conditions arising.

Minimum Dwell Time The minimum allowed time at which a train stands at an intermediate station, so that passengers can board and alight. Services will revert to minimum dwell times if running late.

Signalling Plan A longitudinally scaled or dimensioned track layout showing the signalling functions with their identities.

Turnaround Time The time allowed for a service to reverse direction or between the arrival of a terminating train and its next departure.

RailSys report March 2009 1 Asian Development Bank Railway Investment Programme

Abbreviations

Abbreviation Definition 15s 15 Seconds DMU Diesel Multiple Unit ECS Empty Coaching Stock EMU Electric Multiple Unit FOC Freight Operating Company HST High Speed Train NR Network Rail S&C Switches and Crossings SRT Sectional Running Time TOC Train Operating Company tph Trains per Hour WTT Working Timetable

RailSys report March 2009 2 Asian Development Bank Railway Investment Programme

1 Introduction

1.1 Background

1.2 Scott Wilson Railways Ltd

Scott Wilson Railways Ltd is a specialist consultancy for railways and is a member of the Scott Wilson group - an international transport design and consultancy company of some 5000 permanent staff. Built on years of experience in providing design, construction, maintenance and management advice for the operational railway, Scott Wilson Railways Ltd has a reputation for delivering consistently high standards of engineering and business advice.

Within Scott Wilson Railways Ltd the Rail Consultancy unit fulfils the roles of rail economics and business analysis, integration with engineering, transport planning and business consultancy services, and systems, safety, integration and assurance consultancy. As well as this the main role is operations planning, modelling and assessment using a variety of tools including RailSys. Described in detail in Section 2.

Scott Wilson Railways Ltd were one of the first consultancies in the UK to adopt RailSys as their key performance evaluation tool and have over five years experience using it on various projects, both nationally and internationally. During this time Network Rail have adopted RailSys as the standard modelling tool and we have worked closely with them to develop the standards, which are set down for each UK project.

Rail Consultancy holds five full licences for the RailSys software plus a software support contract in place and has worked with RMCon in the development of an electronic import of existing timetables directly from CIF files. We have also developed advanced evaluation techniques and procedures in Microsoft Excel in order to fully analyse the data produced.

Projects worked on include; Edinburgh Waverley Station, West Coast Route Modernisation, Athens Metro and London Crossrail.

1.3 Requirements

The requirements for this study were to demonstrate how RailSys could be used to show the impact on reliability of any changes to the network or timetable.

RailSys report March 2009 3 Asian Development Bank Railway Investment Programme

1.4 The Network

Model boundaries should be chosen so as to allow sufficient “run-in” time to all key model locations. Railsys train regulation improves with a longer run-in time. For this study Scott Wilson Railways Ltd have taken a section to demonstrate how RailSys would work, this section includes the following stations:

• Sambalpur • Hirakud • Godbhaga • Attabira • Bargarh • Dungripali • Khaliapali • Loisingha • Bolangir • Deogaon Rd • Sainthala • Badmal • Sikir • Titlagarh

RailSys report March 2009 4 Asian Development Bank Railway Investment Programme

2 RailSys

2.1 RailSys Overview

RailSys is a modelling and evaluation program specially developed for the rail industry by Rail Management Consultants (RMCon) in conjunction with the University of Hanover. RailSys is now the UK standard modelling tool adopted by Network Rail, who now produce the standards that all RailSys projects must adhere to.

RailSys has three modules, the Infrastructure manager, the Timetable and Simulation manager and the Evaluation manager.

Infrastructure Manager

The first stage of any operational modelling project is the construction of the rail network and associated infrastructure definitions. The Infrastructure manager allows the user to import, create and modify the infrastructure at both a broad high level and / or at a detailed level to suit the project specifications. For example, RailSys can use different permissible speeds for up to 10 different train types on each section of track, to help simulate differential speed boards or operational conditions for both freight and passenger services.

The rail infrastructure model is built up from a series of links and nodes. A link contains track length, speed and gradient information. A node is a location where there is new or changed infrastructure information. Each network node can be designated as a variety of different signal or track elements such as a signalling release contact, timing point and even stop boards that distinguish between freight and passenger trains. Block sections can be placed between any nodes with their lengths and overlaps explicitly defined. RailSys can discern between different types of block sections for example conventional, Automatic Train Control (ATC), moving block and even dual equipped block sections.

Timetable and Simulation Manager

RailSys can store any number of power car and coaching stock vehicles, each of which can be combined to form the required service sets. Each of these rolling stock types has its own performance characteristics including traction effort, rolling resistance, length and weight (it can also be specified if each set is empty or loaded). There is the option to specify a rolling stock performance margin, which is intended to simulate de-rated performance for older stock, the affect of cautious or ‘defensive driving’ behaviour, and even adverse weather conditions affecting traction.

The timetable entered into RailSys can be either a standard working timetable, client defined or constructed by our experienced train planners. The ability to enter multiple services of the same stopping and timing patterns means a reduction in time spent in this area. The software allows 24 hours a day, 7 days a week to simulate weekday and weekend running as required. Each timetable simulated produces the traditional train graphs and allows repathing due to RailSys’ ‘drag and drop’ facility. RailSys calculates the minimum and required run times taking into account the operational rules and allowances for passenger stops (dwell times), train or bus connections, train servicing, train turn-back or engine run-round times.

Once entered, the timetable (both nominal and perturbed) is run and the train movements are animated over the entered infrastructure. Locations and individual trains can be followed and

RailSys report March 2009 5 Asian Development Bank Railway Investment Programme

analysed in detail to appreciate fully the operational factors contributing to the overall delays. This is particularly useful for the identification of pinch points and inadequate signalling headways.

The key to accurate modelling is to use equipment reliability data, for both the infrastructure and rolling stock elements, which is collected historically or is based on real life situations. For example, the effects of the failure of key infrastructure such as a crossover can be simulated by using RailSys’ line blocking facility. RailSys is able to look forward by a user defined amount of time, which when used in conjunction with prioritised dynamic rerouting, mimics the corrective action that would be taken by a signaller and allows the direct testing of contingency procedures. This can also be used to simulate maintenance being undertaken on the line and the subsequent delay (and the financial ramifications) can be calculated.

The other method of user-defined disruption is via introducing statistical perturbations or disturbances to the designed timetable and then measuring the timetable performance or robustness by running many such timetables through the given network. These random disturbances can be based on either a theoretical probability or empirical distribution based on train running or infrastructure fault data such as TRUST data, provided by Network Rail. The types of delay RailSys simulates are detailed in Table 2.1-1.

Type of Delay Explanation Examples Extended Dwell Time An unscheduled • Slow boarding due to poor station design or extension to a rolling stock choice standard dwell time • Unclear or misleading passenger information • Large amounts of baggage Entry Delays Delays for trains on • All delays picked up outside the model area entering the modelled area, including trains entering from a depot Departure Delays Occurs when a train • A signal or points fault is ready to depart a • Replacement driver not arrived station but is • Power car failure delayed for some reason (other than passenger dwell) Table 2.1-1: Types of RailSys delays

These statistical patterns form the basis of the multiple simulations, 50 of these are run to provide statistical accurate delay figures.

Evaluation Manager

In the evaluation manager, important performance and Passenger Service Requirements such as On Time Running can be calculated and forecast and shown in both graphical and tabular format as the result of multiple simulations over extended periods of time. All the delay statistics in this report are produced in the evaluation manager.

RailSys report March 2009 6 Asian Development Bank Railway Investment Programme

2.2 RailSys Limitations

RailSys, like any computer model, is mechanistic in its approach. Whereas in the real world different drivers will behave differently and use a different driving style, in RailSys all trains are driven in exactly the same way. When approaching a stopping point (whether a station or red signal), all trains will start braking at exactly the right position to follow exactly the same braking curve, to stop in exactly the right place.

In addition, where there is additional time available between two points, RailSys trains will always try to drive at the optimum top speed subject to infrastructure constraints (acceleration and braking are always the same) to arrive exactly at the correct time. Whether or not a train “coasts” at any particular point is laid down prescriptively, rather than using individual driver judgement.

All RailSys trains assume the same passenger loading, and all start at the same moment after a signal clears. All station dwells are identical, and all trains are in optimum condition (so there Comment [s1]: Maybe say is no loss of performance through failed traction motors, for example). RailSys tries to offer all station dwells at the same station and same train service? trains a green signal if at all possible; if this is not possible due to track occupation, then RailSys will display restrictive aspects as appropriate. The trains in RailSys will implement professional driving based on pre-selected speeds to pass each aspect. This means that trains will respond to caution aspects with reduced speed rather than braking at the last possible moment, which gives more realistic results. These speeds are obtained from Network Rail as per the RailSys Standards.

RailSys can only operate if some form of timetable or schedule is created for each train. Thus, trains will show as “on time” based on the defined schedule, and any delay is relative to that schedule. Any delay that would have occurred to create the scenario in the first place is not considered. In addition, RailSys can only operate a full timetable. It is not able to cancel trains or terminate them short of the scheduled destination.

RailSys report March 2009 7 Asian Development Bank Railway Investment Programme

3 Model Development

3.1 Computer Software

All models were created using RailSys version 6.2.52.

3.2 Process

Two infrastructure models have been created. The first is the ‘existing model’ of the current infrastructure, this allows any changes to be measured against current performance. The second is the ‘double track model’, this model provides two tracks between each station.

3.2.1 Existing Model

The typical process for building a model is detailed below, some steps have been skipped:

• Using infrastructure data supplied, (usually in the form of signalling plans and gradient information) a model of the existing infrastructure has been built. An audit was then carried out to confirm the infrastructure was correct in terms of standards and accuracy. • The current timetable (usually supplied with ECS moves included) was then added to the model. • A number of trains runs SRT’s were checked in RailSys to ensure they matched those in the Working Timetable to pinpoint any errors in the model. This is detailed in Section 4.1 Sectional Running Time Tolerances. • The perturbation data supplied by Network Rail was then added and 50 simulations were carried out. An audit was then carried out to make sure the results were meaningful. This was then compared to the input data to ensure the Existing model is realistic. This is detailed in Section 4.2 Punctuality Comparison.

3.2.2 Double Tack Model

The process for building the double track model is detailed below:

• The existing model was ‘double tracked’, based on the gradients and signalling of the single track. • The existing timetable was modified to use both tracks and 50 simulations were carried out. This is detailed in section 6. • An additional timetable was added to see the effects of increased services on the new infrastructure. This is detailed in section 6.

3.3 Source Data

3.3.1 Existing Model

Infrastructure

The infrastructure was based on information received from India.

RailSys report March 2009 8 Asian Development Bank Railway Investment Programme

Traction Data

All the traction data comes from Scott Wilson Railways library of stock types. An estimation was used of the appropriate stock type, a more accurate train can be input into RailSys upon receipt of performance data.

Timetable

A timetable was created based on the current service pattern:

Number of Freight Up direction: 6

Number of Freight Down direction: 6

Number of Passenger Up direction: 7

Number of Passenger Up direction: 8

Delay Data

Delay data on UK projects is provided by Network Rail. For this study an estimation of delays was used to provide figures for investigation. Detailed discussions would normally be required to agree a set of perturbations to reflect real life delays.

3.3.2 Double Tack Model

Infrastructure

The second track was based on the single tack in terms of gradients and signalling.

Traction Data

All the traction data comes from Scott Wilson Railways library of stock types.

Timetable

Timetable 1: Same as Existing Timetable

Timetable 2:

Number of Freight Up direction: 17

Number of Freight Down direction: 10

Number of Passenger Up direction: 7

Number of Passenger Up direction: 8

Delay Data

RailSys report March 2009 9 Asian Development Bank Railway Investment Programme

4 Model Verification

4.1 Sectional Running Time Tolerances

In order to check the model for accuracy, a representative sample of trains are checked for compliance of the SRTs. Trains were visually checked, and notes made only if the SRTs were found to be wrong. The trains were checked for a tolerance of 30 seconds between the Minimum Running times and the Scheduled running times.

Where there are variations between the minimum running times and the scheduled running times, the infrastructure (gradients, signals etc) and timetable (rolling stock, stopping pattern etc) are checked for errors.

In a full investigation this check would be carried out against values supplied by the Indian Railways.

4.2 Punctuality Comparison

RailSys models of existing infrastructure need to be verified against real life to ensure model accuracy, before any new infrastructure can be added. Simulations are run and respective performance figures are compared, making sure that they correlate sufficiently well.

In the UK Network Rail provide real life performance data in order for RailSys models to be compared and validated. If the variance between the calculated figures and those provided by Network Rail is less than 10%, then the model will be accepted by Network Rail as being an accurate representation of the network and its performance.

Once all the figures have been checked and any errors rectified Scott Wilson can continue any modelling confident in the results produced.

RailSys report March 2009 10 Asian Development Bank Railway Investment Programme

5 Existing Performance

Before reviewing the results the following should be noted that this study is an only an example of the type of analysis Scott Wilson Railways Ltd can carry out using RailSys.

5.1 Infrastructure

The infrastructure was based on information received from India.

5.2 Timetable

A timetable was created based on the current service pattern, it is not the actual timetable currently running.

• Number of Freight Up direction: 6 • Number of Freight Down direction: 6 • Number of Passenger Up direction: 7 • Number of Passenger Up direction: 8

No model verification was possible.

5.3 Delay Data

No delay data was available, therefore in order to create some example statistics the following was used:

Dwell Delay

% of Trains Minutes Delay 25% 0 mins (On time departure) 25% 2 mins 25% 5 mins 25% 10 mins

Table 5.3-1: Dwell Delay

Entry Delay

% of Trains Minutes Delay 60% 5 mins 30% 10 mins 10% 15 mins

Table 5.3-2: Entry Delay

The high entry delay of services into the model guaranteed delays at the extremes of the network in order to demonstrate how the infrastructure would cope.

RailSys report March 2009 11 Asian Development Bank Railway Investment Programme

5.4 On-Time Performance

Table 5.4-1 summarises the percentage of trains arriving within three minutes, five minutes and ten minutes at Stations on the network modelled. Figure 5.4-1 shows graphically for four stations on the network the on-time performance.

This information can be used to identify the worst performing stations on a network and then test if timetable or infrastructure improvements will provide a cost effective benefit in terms of delays.

Station TT3 (%) TT5 (%) TT10 (%) Sambalpur 69.56 81.19 96.12 Hirakud 71.83 84.7 95.74 Godbhaga 82.58 90.17 98.08 Attabira 83.33 90.75 98.5 Bargarh 84.09 91.13 99.04 Barpali 82.17 90.08 98.33 Dungripali 82.5 88.58 97.83 Khaliapali 80.83 90.25 99.5 Loisingha 83.04 93.39 99.04 Bolangir 93.22 96.61 100 Deogaon Rd 86.64 95.45 99.55 Sainthala 82.82 90.27 98.73 Badmal 75.91 84.27 97 Sikir 71.81 81.33 95.71 Titlagarh 68.92 79.62 96.23

Table 5.4-1: Summary of TT3, TT5 and TT10 for all Trains

RailSys report March 2009 12 Asian Development Bank Railway Investment Programme

Station Performance

100

% of Trains % of 40

30 Sambalpur 20 Titlagarh Bargarh 10 Bolangir

0 0 10 Minutes Delay

Figure 5.4-1: On-time performance for Sambalpur, Bargarh, Bolangir and Titlagarh.

5.5 Spread of Train Delays over the Network

An analysis of the spread of delays to India services over the entire network has been conducted; the results of this analysis are contained in Figure 5.5-1.

This shows how delays raise and fall over the network to identify areas that may require infrastructure or timetabling changes.

RailSys report March 2009 13 Client Name Project Title

Spread of Delays 200 r 180 h

160 r Titlagar Sambalpu

140 Siki Hirakud

120 r Badmal li

100 arpa B Dungripali Khaliapali Attabira Godbhaga Sainthala

80 Loisingha Bargarh r

60 Deogaon Rd

40 Bolangi

Average Delay per Train (Seconds) Train per Delay Average 20

0 0 20 40 60 80 100 120 Mileage

Figure 5.5-1: Average Delay Trains throughout the Journey

Document Title March 2009 14 Client Name Project Title

6 Double Track Performance

6.1 Infrastructure

In the absence of detailed design plans that we would normally work off, the ‘second’ track is a simple copy of the existing single track.

6.2 Timetable

Two timetables were analysed on the double track model.

1. The existing timetable was put on first based on this service pattern:

• Number of Freight Up direction: 6 • Number of Freight Down direction: 6 • Number of Passenger Up direction: 7 • Number of Passenger Up direction: 8

2. The second timetable was an increase level of service timetable:

• Number of Freight Up direction: 17 • Number of Freight Down direction: 10 • Number of Passenger Up direction: 7 • Number of Passenger Up direction: 8

6.3 Delay Data

The same delay data is used on all timetables for an accurate comparison of performance.

6.4 On-Time Performance (Timetable 1)

Table 6.4-1 summarises the percentage of trains arriving within three minutes, five minutes and ten minutes at Stations on the network modelled. Figure 6.4-1 shows graphically for four stations on the network the on-time performance.

This information can be used to identify the worst performing stations on a network and then test if timetable or infrastructure improvements will provide a cost effective benefit in terms of delays.

Station TT3 (%) TT5 (%) TT10 (%) Sambalpur 39.73 67.2 78.93 Hirakud 47.43 68.29 79.14 Godbhaga 59.36 77.09 85.91 Attabira 55.89 77.44 86.11

Document Title March 2009 15 Client Name Project Title

Bargarh 61.9 82.48 89.9 Barpali 60.64 81.09 89.36 Dungripali 57.91 81.64 89.82 Khaliapali 62.64 81.27 90.91 Loisingha 61.05 81.43 90.95 Bolangir 78 91.14 96.67 Deogaon Rd 71.1 87.2 93.8 Sainthala 68.3 84.7 90.2 Badmal 65.1 81.1 87.2 Sikir 63.68 78.21 84.63 Titlagarh 43.5 69.25 80.33

Table 6.4-1: Summary of TT3, TT5 and TT10 for all Trains (Timetable 1)

Station Performance

100

% of Trains % of 40

30 Sambalpur 20 Titlagarh Bargarh 10 Bolangir

0 0 10 Minutes Delay

Figure 6.4-1: On-time performance for Sambalpur, Bargarh, Bolangir and Titlagarh.

6.5 Spread of Train Delays over the Network (Timetable 1)

An analysis of the spread of delays to India services over the entire network has been conducted; the results of this analysis are contained in Figure 6.5-1.

This shows how delays raise and fall over the network to identify areas that may require infrastructure or timetabling changes.

Document Title March 2009 16 Client Name Project Title

Spread of Delays

200 r

) 180 h s d

160 Sambalpu Hirakud r Titlagar econ 140 (S r n i

120 Siki ra Attabira Godbhaga T 100 Badmal Barpali Bargarh Dungripali Sainthala Loisingha Khaliapali

ay per ay per 80 l e r D 60 Rd Deogaon

40 Bolangi verage verage

A 20

0 0 20 40 60 80 100 12 Mileage

Figure 6.5-1: Average Delay Trains throughout the Journey (Timetable 1)

Document Title March 2009 17 Client Name Project Title

6.6 On-Time Performance (Timetable 2)

Table 6.6-1 summarises the percentage of trains arriving within three minutes, five minutes and ten minutes at Stations on the network modelled. Figure 6.6-1 shows graphically for four stations on the network the on-time performance.

This information can be used to identify the worst performing stations on a network and then test if timetable or infrastructure improvements will provide a cost effective benefit in terms of delays.

Station TT3 (%) TT5 (%) TT10 (%) Sambalpur 40.86 66.55 77.73 Hirakud 49.94 73.37 81.77 Godbhaga 59.72 80.67 87 Attabira 60.1 80.2 86.4 Bargarh 65.67 82.94 89.78 Barpali 62.58 83.79 91.21 Dungripali 61.44 83.99 90.21 Khaliapali 62.63 83.59 90.43 Loisingha 58.54 81.36 89.43 Bolangir 62.84 83.06 90.58 Deogaon Rd 49.29 76.29 85.94 Sainthala 41.91 71.1 81.99 Badmal 37.59 67.47 78.06 Sikir 36 64.48 76.24 Titlagarh 31.16 60.26 75.21

Table 6.6-1: Summary of TT3, TT5 and TT10 for all Trains (Timetable 2)

Document Title March 2009 18 Client Name Project Title

Station Performance

100

% of Trains % of 40

30 Sambalpur 20 Titlagarh Bargarh 10 Bolangir

0 0 10 Minutes Delay

Figure 5.4-1: On-time performance for Sambalpur, Bargarh, Bolangir and Titlagarh.

6.7 Spread of Train Delays over the Network (Timetable 2)

An analysis of the spread of delays to India services over the entire network has been conducted; the results of this analysis are contained in Figure 6.7-1.

This shows how delays raise and fall over the network to identify areas that may require infrastructure or timetabling changes.

Document Title March 2009 19 Client Name Project Title h Spread of Delays r r 200 Titlagar Siki

) 180 s Badmal d Sambalpu 160 Sainthala econ Hirakud 140 r (S n i

120 Rd Deogaon ra r h T Attabira 100 Godbhaga Loisingha argar B Barpali Bolangi Dungripali Khaliapali

ay per ay per 80 l e

D 60

40 verage verage

A 20

0 0 20406080100120 Mileage

Figure 6.7-1: Average Delay Trains throughout the Journey (Timetable 2)

Document Title March 2009 20 Client Name Project Title

7 Conclusions

With all the data processes and displayed as the examples in this report show, Scott Wilson Railways Ltd Operations Analysts can draw conclusions and make recommendations in order to improve performance.

On the existing model, it can be seen that the high level of entry delay at each end of the network results in poor performance at those stations (Sambalpur and Titlagarh). However as the trains move through the model these delays reduce suggesting the timetable is robust for the infrastructure.

Bolangir is the best performing station. This is to be expected due to the extra number of platforms available allows overtaking and a number of freight services stop here for a considerable time which allows them to catch up any time lost. This information could be used to design a similar station along the network to reduce delays, this can then be tested in RailSys to determine the benefit.

A number of different timetables could be tested out on this model to see the optimal number of trains that can be run across the network without experiencing high level of delays. Also modifying the existing timetable, by stopping freight trains at different stations for example, can be reviewed to see if relatively inexpensive timetabling can improve performance rather than expensive infrastructure changes.

On the double track model, timetable 1, which is the existing timetable placed on the new model, the results are very similar to the existing model. In order to realise the benefits of the double tracking a timetable exercise would normally be carried out to re-route services to utilise fully both tracks.

On the double track model, timetable 2, this is the existing timetable but with over double the amount of freight trains, performs similarly to the existing in the central part of the network. At the two ends of the model there is an increase in average delay. This demonstrates that doubling the tracks provides a great deal more capacity without an adverse effect on performance. However a combination of careful timetabling or differing arrangements towards the ends of the network are required to avoid an increase in delay.

This report aims to show some of the benefits of using modelling software to confirm or otherwise the benefits of improved timetables or infrastructure. It can be used to compare designs in terms of performance improvements they may bring so a cost benefit decision can be made.

Document Title March 2009 21