Regulating trains so that they run in the right order and do not delay other services has been a challenge ever since railways started in business. In early times, the decision-making was left to local signalman who, by their intricate knowledge and years of experience, got it right most of the time. Writes Clive Kessell

Everything was relatively easy if trains were running to the timetable, but the challenge came when disruption occurred, maybe a failed locomotive, a section of track needing maintenance, a member of crew not being available, even the insertion of an extra train at the last moment. At such times, the capability of signalmen to sort things out was severely stretched, and running order mistakes could quickly cripple a train service.

Early steps

The advent of Traffic Control Offices in the early part of the twentieth century helped considerably, but having only telephones and telegraph instruments at their disposal severely limited what these offices were aware of and the ability to get things changed.

With the introduction of power signalboxes in the 1950s, a much greater area of control could be viewed with all train movements actively seen on a display diagram. The positioning of regulators at ‘back row’ desks enabled much greater accuracy in the regulating process but, even here, it was a human decision as to how trains should be scheduled to minimise disruption. Big as they became, power boxes still had a limited area of operation and the ability to see the order of approaching trains was restricted.

In later years, computerised systems have been developed to aid the decision making by signallers and controllers. These include:

  • ARS (Automatic Route Setting) whereby trains signal themselves according to the timetable and their train description, thus minimising signaller intervention but with limited facilities for prioritising the order in which trains are processed;
  • JOT (Junction Optimising Technique) in an attempt to look at the order of trains approaching a junction point and then signalling trains through the junction according to type, speed and importance;
  • Computerised Train Graphs – produced primarily for timetable compilation but used in real time for modifying the train service on a daily basis according to need, including the insertion of additional trains;
  • TD NET (Train Describer Networking) whereby Train Describer systems in the various power boxes have their information distributed to a common database so that other signalling centres and control offices can see the real time movement of trains over extended distances;
  • Timetable and train describer interaction for the updating of passenger information.

Various uses

Other systems have been developed to make use of this computerised information external to the signalling centre and control office. Project Darwin is one example. An ATOC (Association of Train Operating Companies) initiative, it captures real time train running information and links this into web sites and social media systems as well as improved displays / announcements at stations. The intention is that customers receive current and relevant data for their intended journey (issue 83, September 2011).

DAS (Driver Advisory Systems) give guidance to drivers on the optimum speed to be observed such that a train arrives at a particular timing point on time having used the least amount of energy by avoiding excessive acceleration and braking (issue 104, June 2013).

Traffic Management Systems

With past developments yielding so much relevant data, what further work is foreseen and needed to improve on the present situation? Current information systems have been designed as separate entities with the potential for data to be both disparate and missed, thus causing inconsistency. There are, however, many other factors that impact on train service performance which need to be integrated into the decision management process.

The result is the Train Management System (TMS) and it is not just a UK requirement as many other railways have invested in the development of such systems. The concept is to produce a single source of data for train timetabling, rolling stock allocation and train crew deployment and to use this data for operations planning and comparison to real time operational events, thus automating the signalling of trains in the optimum way. Included is the detection of potential conflicts and their best resolution, plus probing ‘what if’ scenarios on train running with consequent decision support.

Such a task is clearly challenging and effective results will be most needed at times of severe disruption. Achieving this will essentially be by marrying the signalling control panel with the computerised train planning graph. This will yield a map of train whereabouts over a wide area, derived from both traditional train describers and GPS radio tracking, from which information can be sent to a variety of systems that react to the data.

The result will have impact way beyond the basic objective of running trains to time. The overall TMS will include:

  • Web based distribution with configurable information management applications;
  • Travel information dissemination including display maps to show disruption;
  • Possession management and reduction of human based protection methods;
  • On-site communication to local terminals and smart phones;
  • Rolling stock re-planning;
  • Train crew scheduling and re-assignment when needed;
  • Insertion of additional trains and optimum pathing of these;
  • Feeding of live train running data to DAS so as to alter driver advice to take account of potential junction conflicts.

Network Rail plans and trials

Network Rail operates 24,000 trains per day and passenger demand is expected to increase by 30% in the next 10 years. Around 8,000 people are employed to operate the railway and a high percentage of operator’s time is unproductive. Managing these quantities so as to achieve maximum efficiency will be a challenge. Network Rail thus wants a TMS facility that is already proven on other rail networks.

Trial applications are underway with three providers: Hitachi, Thales and Signalling Solutions Ltd (SSL). All have reached the stage where demonstration systems have been set up, modelled on a particular operating area and including simulations of SSI interlockings and train movements. This is allowing Network
Rail engineers and operators to evaluate the effectiveness of the offering.

Part of the testing is to see whether the decision-making algorithms are better than an experienced railway controller. Unsurprisingly, controllers see this as something of a challenge!

The trials aim to show various combinations of how TMS might assist signallers, ranging from full intervention to advising on the best route settings. The chosen area for modelling is Leeds, as this contains a multitude of routes and a complex station layout. The Rail Engineer was shown all three systems by Richard Beddow, Network Rail’s project manager, and Gary Pierce, one of the ‘challenged’ controllers, in conjunction with the three manufacturers.


The Hitachi TMS, known as Tranista, is based on experience in Japan where Hitachi systems are used on both Shinkansen high-speed lines and busy commuter and mixed traffic lines, notably in the Tokyo area. On this simulation, trains are shown on entry and exit routes as the next three in running timetabled order. This list is displayed adjacent to the appropriate train describer window.

If a train fails or is stopped for an unduly long time at a platform, then that train is ‘suspended’ from the system and the next three trains are re-ordered. This process takes account of the types of train, their permitted speed, the ongoing stopping patterns and the impact of delay. Thus the recommended sequence of dispatch may not be the same as per the timetable. Once the problem with the ‘stopped’ train is rectified, then it is re-inserted into the system and a revised running order calculated.


Thales offers a similar simulation structured around a single operating information system that gives re-configurable control and use of decision support tools. The system is branded ARAMIS and has a modular architecture that can be structured for links to interlockings, radio block centres, fringe train describers, alarms and so forth. It is aimed at providing help in several rail activities: planning, station management, passenger information, controllers and train crew, and will cover timetable, despatch, movement authorities, network availability, incident / delay management and service information.

To link to the several types of interlocking that currently exist, Thales intends to use the WestCad system originating from Invensys (now Siemens Rail Automation) as a programmable interface. The Leeds simulation includes for normal, degraded and emergency working as defined by the nominated controllers.

ARAMIS will not optimise train crew or rolling stock diagramming / rostering, these being achieved by links to other systems.


The proposal from SSL centres around Alstom’s ICONIS and Atos’s Integrale products with the emphasis being on the management of a mixed traffic railway. This offering is based on a consortium approach involving Alstom (one of two parent companies of SSL), Atos (an international IT organisation that acquired significant elements of CAP and SEMA Group) and Parsons Brinckerhoff.

The ICONIS TMS system is used in a number of countries but the deployment in Bologna, which is one of 12 signalling centres in Italy using different manufacturers’ equipment, equates best to the Network Rail scene. Here, TMS has enabled a significant improvement in punctuality whilst having to cope with a 30% increase in traffic. A shadow system is included to allow final validation of upgrades and changes in the live environment before loading to the operational system with no down time.

The Atos Integrale product provides a high level, national management solution to co-ordinate local TMS systems provided at individual signalling centres. For the UK proposal, linkage to other existing IT and signalling equipment such as rolling stock, crew rosters, etc. will be via the LINX integration layer, this feeding both local and overview TMS architecture.

Train running is shown by + or – minutes for early or late against the individual train descriptions on the signaller’s route setting screen. From this, optimised ARS will be advised. Any change to planned timetable routing will require human intervention. A mouse click on the description will establish a voice call to the train using GSM-R.

Conflict detection currently compares only one train to another (Pair Wise Comparison) but more variables will be developed as the system matures. A key factor will be the time taken to assess what options are available; the optimum solution might not be best if too much time is taken.

Common elements

All three suppliers envisage electronic train graphs on the signallers’ desks so that they can compare the dynamic timetabling to the normal route setting screen. This element will potentially give the signallers more information and expert advice on the optimum routing of trains. The train graph will show both the planned path and the real time actual running time of a train. From this, future conflict points will be determined with advice as to the best running order to be followed.

The use of this facility is likely to be split between the signallers who have around a 10 minute window to change things, and the train planners on the ‘back row’ desks who will view the likely changes and train movements at greater distances from the immediate station area. The train graph can be used to block out sections of route if a major problem is encountered. Options will then be to terminate, turnback or divert according to the nature of the blockage. Dealing with a suicide or a broken rail are instances where this can occur inside a normal day.

The TMS programme will be aligned to the introduction of the Regional Operating Centres (ROCs). Current plans show 12 of these nationally, with 5 already open and the remainder all due to be in partial service by the end of 2015. The ROCs are intended to cover the majority of Network Rail but it will take many years before all rail routes are controlled from these places.

TMS however, to be effective, must take account of the whole railway so TMS information and applications must be made available to the existing Integrated Electronic Control Centres (IECCs), older style Power Boxes (PSBs) and even to the remaining mechanical signalboxes whilst they remain in service. Current thoughts are to display optimised train running orders at these places with instructions to signallers to maintain this order unless exceptional circumstances intervene. This will need careful handling and a lot of lessons will no doubt be learnt in the process.


With the ever increasing ridership and the need to run more trains, capacity on the network is becoming a real problem. Building more infrastructure is expensive and takes time, so are there any quick fixes that can help?

TMS is envisaged as a tool for improving train running sequences and minimising delay at pinch points and from this, more train paths should become available, thus increasing capacity. Exactly how beneficial this can be will be part of the evaluation period but a broad order assessment is that 10% more throughput can be obtained at the busiest parts of the network.

Other applications and the future

Once train operation is known in real time on a national scale, it will enable much improved information to be given to travellers at times of disruption. The portrayal of information by digital maps on displays boards at stations has been tried in the past (at Peterborough) and was judged to be successful. By using TMS the maps can be made more dynamic and can show for example a line being closed and the diversionary routes that trains will be taking.

Getting information into web sites and social media will continue to be a feature of Project Darwin, but the feeds to the system will have greater accuracy.

DAS is a technology that is being adopted by many of the train operating companies, but it is currently limited to the provision of data for a specific train journey. It has always been foreseen that information given to drivers on optimum running speeds needs to take account of other train movements and TMS will be a natural feeder in the accomplishment of this aim. DAS set-up information such as train set, platform diagramming and suchlike will be fed into TMS, whence the data will have to be centralised at some kind of hub and then distributed in processed form to trains via a 3G or 4G mobile network.

Information on freight trains will be particularly important as the locomotive type, speed, weight and loading all vary from train to train. Since freight trains rarely run to the same rigorous timetable of passenger services, ‘queue paths’ may be created to show available capacity if a freight train is running late or indeed to offer a path to another train should a cancellation or significant late running occur.

Possession Management is an ongoing challenge with the present methodology seen as inefficient and carrying big safety risks caused by human error. With the ability to know the real and predicted whereabouts of every train within an area plus the capability of networking this information to a local terminal (iPad or tablet), it should become possible to present more timely information to persons responsible for managing a possession. This will be aimed at planned possessions in the first instance but could potentially be useful in enabling work to be done between trains and taking emergency possessions.

Another consideration is how TMS will fit in with the future ERTMS (European Rail Traffic Management System) programme, and some form of integration will be necessary. By electing to have a TMS system that is already in service, it is anticipated that this will have been used in conjunction with ERTMS on another rail administration.


Once the test room simulation period is completed, one of the TMS products will be chosen for deployment in Cardiff and Romford (Essex Thameside section) ROCs to gain real- time experience. These will become operational in Dec 2015. At some stage, a high-level national system has to be included to get a UK overview on how trains are running. An individual ROC will probably only need to see approaching trains within a 60 minute time period for conflict detection purposes but a three hour window will be possible if required

Just how the ultimate procurement will evolve has still to be worked out but if a multi-supplier scenario is chosen then interoperability will be required between the different products. The single national overview system must be capable of seamlessly linking all of the ROC-based equipment.

A collaborative effort from suppliers will be needed. There is a lot at stake so keen eyes will be watching progress with interest.

UPDATE: Thales has been awarded the TMS contract for ROCS in Cardiff and Romford.