HomeRail ProjectsTraffic Management - Clarity and Purpose?

Traffic Management – Clarity and Purpose?

Listen to this article

When Traffic Management Systems (TMS) were first described in Rail Engineer (issue 115, May 2014), they were heralded as a quick win to improve train operational performance with systems that could be rolled out in parallel with the Railway Operating Centres (ROCs) then being commissioned. Network Rail staged a ‘beauty parade’ from three suppliers – Hitachi, Thales and Alstom, all of whom had proprietary systems in use elsewhere – to see which ones could be integrated into modern-day signalling practice as employed on the network. From that, two contracts were let with Thales to provide TMS at Romford and Cardiff ROCs and evaluate the effectiveness of the technology.

Things have moved on considerably since that time and it is evident that TMS is a lot harder to implement than first imagined. Neither Cardiff nor Romford can be considered fully operational and other suppliers of systems have since entered the fray. TMS has also positioned itself differently within the Network Rail portfolio, which itself needs explanation, and it has become clear that TMS means different things to different people.

To try and pull this all together, the Institution of Mechanical Engineers (IMechE) and the Institution of Railway Signal Engineers (IRSE) staged a seminar in London recently to attempt to clarify what TMS is all about and to bring the attendees up to speed on the progress being made.

It proved to be an interesting day, although not without a few red herrings being injected into the proceedings.

CTC Control Centre, Hong Kong.
CTC Control Centre, Hong Kong.

TMS and the Digital Railway

If ever a word in our current language is overworked, it is ‘Digital’. Everything you touch these days has to be digital to be of any use and regrettably ‘Digital Railway’ seems to be following the same pattern.

Describing the digital railway as the ‘system of systems’, an opening presentation by Vish Kalsapura described how all the main players in the rail industry are working together to produce a shared vision and a whole-industry approach to achieve a railway that will perform better and give the operational benefits that come with digitisation. The vision of Network Rail, the Department for Transport (DfT), the Rail Delivery Group, Rail Freight Group, Railway Industry Association (RIA), the train companies and the supply chain is to deliver more trains with better connections and greater reliability by means of improved journey management, capacity gains, service delivery improvements and life cycle considerations.

There is recognition that the industry is complex and fragmented, with lots of silos, and thus a consistent architectural model with clearly defined interfaces between systems is all part of the digital railway objective.

Heavily focussed on the roll out of ERTMS, TMS will link into ETCS, GSM-R, C-DAS and associated business systems, all connected together by the FTNx transmission network of Network Rail Telecoms. A customer specification is believed to be needed, but one might ask the question “who is the customer?”

TMS is apparently being specified on a prescriptive basis, which reduces the scope for innovation but observers might comment that the original intention was to purchase off-the-shelf proven systems.

There is a need for a Systems Authority to be created – now where have we heard that before? If this leads to a better understanding of the complexity, a minimisation of unintended consequences and an alignment of interest groups, then that can only be beneficial.

CTC Control Centre, Hong Kong.
CTC Control Centre, Hong Kong.

A European perspective

It seems that it is not just the UK that is struggling with TMS. Pio Guido from the European Railway Agency (ERA) – recently rebranded the European Union Agency for Railways (to keep the UK out post-Brexit? Even the railways are not immune from political posturing) – reminded people that, within ERTMS, there is the European Traffic Management Level (ETML) that has made little progress in the aim of developing a Europe-wide standard.

The interoperability vision has resulted in the ETCS safety-critical layer reaching a stable state whereby railways can confidently procure systems from different suppliers that operate to a common standard.

ETML requirements are a long way from being in a similar state and thus lack compatible innovation and investment protection. Moreover, some of the vital information that has to be supplied from ETCS, such as speed and position of train plus train integrity, is missing.

In short there is a need for a closed loop to permit a constant information exchange between track and train. This in turn demands a much-improved radio link between track and train, way beyond what GSM-R is capable of offering. TMS has to provide governance, regulation and collaboration for the successful running of a railway.

TMS benefits and experiences

The emergence of Indra as a TMS supplier is logical as the company has for years engaged in air traffic control, road tunnel management and seaport operation. Javia Pozo outlined some of the realities of applying TMS to existing rail technology – lots of non-standard infrastructure, non-unified operating procedures, many different interfaces, all of which are non-scalable and expensive to set up and maintain. These make implementing TMS a difficult task. Couple this with TMS suppliers having developed proprietary systems and the scale of the challenge is easy to see.

The subsystems of timetable, operations, resources, track works, C-DAS, interlockings and train-operator management have to be capable of integration if TMS is ever going to work successfully. The roll out of the ROCs is the key to making this happen, but the TMS suppliers should, in turn, aim to agree a unified specification with a standard interface to the sub systems. History would show that such co-operation does not come naturally.

The basics for TMS are relatively easy:

  • Constant timetable and track management data;
  • Constant updating and forecasting of train times and routes;
  • Conflict identification;
  • Display of current network and train running data;
  • Production of a Simplifier to advise (or even direct) signallers/controllers on optimum train routing and control.

It can be done: Spain and Lithuania have national-level TMS implementation based on a single-supplier system but integrated with several different types of interlockings. While they are smaller railway systems than the UK, there may perhaps be lessons to be learned.

Thameslink will have one of the first live TMS applications in the UK.
Thameslink will have one of the first live TMS applications in the UK.

The London Underground experience

London Underground claims to have TMS structured in two layers, according to Ivan Curties from Thales: Automatic Train Supervision (ATS) and Automatic Train Regulation (ATR). The former is there to achieve timetable adherence, the latter detects perturbations that the operators might not see. LU operation is recognised as simpler than the main line as trains are usually the same length with the same station stops, have identical performance and do not split or join. Increasingly, LU trains are ATO (Automatic Train Operation) and performance comes from the sequence of ATO –>  ATP (Automatic Train Protection) –> ATS –> ATR.

Traffic management has resulted in some time-honoured practices being revised. Junction control is one example; it used to be first-come first-served, regardless of the timetable. TM now calculates whether it is beneficial to hold a train until the late train goes through. The whole purpose is to give greater flexibility and providing expert decisions to reduce operator workload.

Even on LU, the software to link ATR and ATS is complex, with the number of inputs involved, and the systems do not always deliver what was intended. ATR has, however, proved successful on the Victoria Line and is an inherent feature of the Thales Seltrac system, where its effectiveness has been independently verified on the Jubilee line.

Lessons learned will be applied to the 4LM upgrade involving Metropolitan, District, Circle and Hammersmith & City lines. Using simulators for testing and training is essential, with ATR particularly difficult to test and understand. It is necessary to have people on hand who have the knowledge to recognise how undocumented ‘work arounds’ are used when things start going wrong – good advice for future main line plans.

Platform Docker output from Resonate's Luminate TMS. Photo: Resonate.
Platform Docker output from Resonate’s Luminate TMS. Photo: Resonate.

UK experience to date

Reporting on progress with TMS is not easy. Andy Bourne – ex-LU but now with Arcadis – gave an honest assessment. The prime aim is to achieve timetable de-confliction and reduce knock-on delays when problems occur. Whilst incidents are statistically down in number, the delay per incident has increased, hence the need for TMS.

How to use TMS is also a challenge. There is isolated TMS, which uses it as a decision-support tool to give advice to signallers, and also integrated TMS that will provide semi or fully automatic implementation of a revised timetable plan. Linkage to other systems is vital, as has been noted, but particularly to stock and crew deployment, C-DAS and signalling systems, also to business systems that are the contractual boundaries for how the railway operates.

The project-by-project progress shows mixed results:

  • Romford – Thales Aramis system yet to go fully live;
  • Cardiff – Thales Aramis system is live and used for timetable de-confliction;
  • Thameslink – Hitachi Tranista system is trialling timetable data but not expected to go live before mid-2019;
  • Western London to Bristol – Using the Resonate (ex BR Research expertise) Luminate system, it is live since June 2018 on a trial basis with updates expected during the trial. Whether to proceed further will be decided in mid 2019.

Future schemes are planned for the South East, East Coast main line, TransPennine, Manchester ROC, Anglia, Wessex and Chiltern. Three Northern areas will merge into a single TMS scheme based upon a 20-minute look-back at train running data.

The future intent will be for route-based schemes with standard procurement components and alignment to ROCs. Not having TMS as a standard product is a real problem, as it leads to difficult interfaces and linkage to C-DAS.

Getting TMS provided on Thameslink, with its ATO capability, represents a significant challenge and will require close co-operation between the ETCS/ATO supplier and the TMS contractor, according to Andy Powell from Siemens.

With difficult junctions at both ends and nominal 60-second dwell time at stations, the opportunities for things to go wrong are considerable. The operator’s workstations will need more information, so leaving space for TMS screens is important. Being able to simulate a full workstation with TMS added will be essential for achieving successful system integration.

The Swiss experience

Awareness emerged during the recent IRSE convention that SBB has developed an in-house TMS system for the entire Swiss rail network, and Daniel Achermann provided more detail at this seminar. On a 2,000-mile network, handling 10,500 trains per day, SBB has four operational control centres that absorbed three area centres, 21 local centres and 130 local signal boxes.

The result is a standardised signaller’s desk and MMI from which can be displayed the track layout and signalled movements, the train graph, connections management, station management, energy optimisation and telecoms facilities.

Incorporated into the TMS is timetable, topology, train formation and train movement information that links into and out of signalling, C-DAS and ARS (Automatic Route Setting).

Since 2009, SBB has seen a 28 per cent increase in passenger numbers, a 16 per cent increase in train movements, a nine per cent improvement in track usage, a four per cent reduction in energy consumption and a 25 per cent reduction in train running costs, much of this down to the TMS system.

It’s quite remarkable what a railway organisation can achieve with the right determination, expertise and organisational structure.

Hitachi is supplying the TMS for Thameslink.
Hitachi is supplying the TMS for Thameslink.

Train-braking and TMS

The variables in braking performance of rolling stock are well known, with adhesion in the autumn being a dominant problem. Whilst different types of sanding, and even magnetic track brakes, may be part of the solution, Neil Ovenden from the Rail Delivery Group questioned whether TMS could be used to modify the timetable on a day-by-day basis when adhesion problems were predicted?

Similarly Ian Hersey and Matthew Hattersley from TfL explained the safe-braking model that purports to ensure safe train separation whilst at the same time obtaining capacity improvements. The scope for errors is considerable, with the worst case being a first train stopping short and a following train over-running. Could TMS be used to optimise train propulsion commands, braking instructions and emergency braking rates to obtain a reduced separation between trains whilst retaining a safe distance? Food for thought and probably something the TMS suppliers have yet to consider.

Train Graph output from Resonate's Luminate TMS. Photo: Resonate.
Train Graph output from Resonate’s Luminate TMS. Photo: Resonate.

TMS for the Elizabeth line

The specification for the impending Crossrail train service performance is demanding and requires scheduled departure times on the surface sections to be kept, precision timings at the tunnel portals, and consistent train separation intervals with no bunching through the central London section.

Russell Parish, the performance manager for the Elizabeth line operations team, explained the factors that will make this a considerable challenge. With four different types of signalling system (CBTC with ATO in central core, ETCS, TPWS and AWS on the different surface railways), many trains terminating and reversing at Paddington, three signalling control centres (Romford, Liverpool Street and Didcot) plus Swindon and the underground-section control centre, mixing in with other traffic including freight on the surface lines, some flat junctions, even minor delays will have an exaggerated effect. TMS is needed to re-plan services when the need arises. Forecasting and re-forecasting is likely to be a continuous process.

Blue Sky thinking?

A somewhat fanciful prediction on how the future might look was given by Andy Doherty, the chief technical officer at Network Rail. Expanding on the Digital Railway theme, with the somewhat dubious statement that ETCS Level 2 and TMS is now the norm, he predicted that ETCS Level 3 (both normal and hybrid versions), 5G radio and an open backbone, a supplier-agnostic approach to radio block centres, interlockings and trackside components will all lead to a reduction in signalling costs.

Station systems for customers, dynamic ticketing, real time timetable planning, live interfaces between train and road traffic at level crossings, plus adoption of automotive digital techniques, were all part of the vision. The statement ‘data, data everywhere but not a drop of information’ is thought to be where we are currently, with the Digital Railway being needed to pull it all together. Whether this is realism or a dream world was up to attendees to judge

All in all, it was a strange day with differing requirements for TMS emerging out of the proceedings. One could not help thinking, particularly with the present timetable fiasco, that more concentration on getting TMS put to good use on the present railway is perhaps where the effort should be concentrated right now.


Acronyms defined:

  • 4LM – Four Lines Modernisation programme
  • 5G – Fifth-generation GSM mobile communications
  • ARS – Automatic Route Setting
  • ATO – Automatic Train Operation
  • ATP – Automatic Train Protection
  • ATR – Automatic Train Regulation
  • ATS – Automatic Train Supervision
  • AWS – Automatic Warning System
  • C-DAS – Connected Driver Advisory System
  • CBTC – Computer-Based Train Control
  • DfT – Department for Transport
  • ERA – European Railway Agency
  • ERTMS – European Rail Traffic Management System
  • ETCS – European Train Control System
  • ETML – European Traffic Management Level
  • FTNx – Fibre-optic upgrade to the Future Telecoms Network
  • GSM-R – GSM mobile communications for railways
  • IMechE – Institution of Mechanical Engineers
  • IRSE – Institution of Railway Signal Engineers
  • LU – London Underground
  • MMI – Man/Machine Interface
  • RIA – Railway Industry Association
  • ROC – Railway Operating Centre
  • SBB – Swiss State Railways
  • TfL – Transport for London
  • TMS – Traffic Management System
  • TPWS – Train Protection and Warning System

Read more: Building a world heritage tunnel in Switzerland


Clive Kessell
Clive Kessellhttp://therailengineer.com
SPECIALIST AREAS Signalling and telecommunications, traffic management, digital railway Clive Kessell joined British Rail as an Engineering Student in 1961 and graduated via a thin sandwich course in Electrical Engineering from City University, London. He has been involved in railway telecommunications and signalling for his whole working life. He made telecommunications his primary expertise and became responsible for the roll out of Cab Secure Radio and the National Radio Network during the 1970s. He became Telecommunications Engineer for the Southern Region in 1979 and for all of BR in 1984. Appointed Director, Engineering of BR Telecommunications in 1990, Clive moved to Racal in 1995 with privatisation and became Director, Engineering Services for Racal Fieldforce in 1999. He left mainstream employment in 2001 but still offers consultancy services to the rail industry through Centuria Comrail Ltd. Clive has also been heavily involved with various railway industry bodies. He was President of the Institution of Railway Signal Engineers (IRSE) in 1999/2000 and Chairman of the Railway Engineers Forum (REF) from 2003 to 2007. He continues as a member of the IRSE International Technical Committee and is also a Liveryman of the Worshipful Company of Information Technologists. A chartered engineer, Clive has presented many technical papers over the past 30 years and his wide experience has allowed him to write on a wide range of topics for Rail Engineer since 2007.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.