UK Network Rail and Theory of Constraints

Thanks to a a fellow TOC enthusiast David C who pointed out Network Rail's 85 page CONSULTATION ON CAPACITY STUDY FOR EAST COAST MAIN LINE.  I'm excited because they use Theory of Constraints as their methodology.  This is important stuff.

From the report, here's how they intend apply TOC to railway operations planning (from page 7) :

The railway, or parts of it, can be viewed as a system with a number of bottlenecks, capacity restrictions or constraints. Traditionally these constraints were junctions, but constraints need not necessarily be junctions. The railway lends itself to the ThOC because it is limited to two dimensions which limits the number of variables involved. The constraints can be physical infrastructure constraints or commercially induced constraints. Examples of physical constraints include the Welwyn Viaduct where the railway layout reduces from four tracks to two, the single line section between Gretna and Annan and indeed any single line. An example of a commercial or business decision constraint is where two services use the same piece of infrastructure and we make the decision that one of the service groups will remain unaltered (thus constraining planning options for the other).

In railway operations planning it is not always clear which is the constraint, as there are often a number of pinchpoints or bottlenecks that appear to be constraints. Therefore we need to model each of the possible constraints to establish which is the most severely constrained and thus the constraint that determines the capacity of the whole system.

We have developed a method of representing the constraint on a capacity graph (which can be used to calculate the Capacity Utilisation Index). In simple terms this can be described as follows. A graph plots each half hour of the day on the X axis against the minimum headway on the Y axis. We are then able to plot the number of trains operating in each half hour and adjust the value if they require more than minimum headway (ie. are slower than the fastest train that operates over that constraint). This produces a curve. There is a correlation between this curve and railway performance measures. See the performance section for more detail (section 5).

When adding proposed services to a constraint we can identify if they breach 100% capacity and therefore either reject them or consider retiming something else out of the time band in question. We can also identify where they breach the current curve and would have an adverse impact on performance. The extent of this effect is a matter of professional judgment informed by empirical evidence.

It is necessary for a proposed service to be able to be accommodated at each of the potential constraints. We can therefore construct a table showing the proposed services at each constraint and stating whether it can successfully path through the constraint. Only if it can pass through each constraint is the service viable.

In order to present at the correct time at each constraint and therefore maximise throughput, it will usually be necessary to use pathing time. In the case of a flexible application such as Grand Central’s this will also influence the best timings to develop. In the theory this is the practice of supporting a constraint. This pathing time extends journey time. It is therefore necessary to check that the application of pathing time to present correctly at all constraints does not extend journey times to unrealistic levels. If this were to be the case we would again say the service was not viable.

Once all of these tests have been successfully passed the service is declared viable and outline paths can then be produced in order to sense check the assumptions that have been made. If there are two or more viable services proposed then the decision would have to be made on other grounds e.g. economic, safety etc.

We have explained this methodology to each of the applicants. We have had constructive feedback from each of them. We believe that we have found a way of incorporating all issues raised into the methodology. We have received written comments supporting the ThOC in general from each of the operators concerned.