Integrated Station Management System (ISMaS)

Recommendations for future projects to understand the planning, management and potential challenges of integrating stations to improve communications.

Key Challenges

The Thameslink route is unique in London due to its central location and proximity to other transport and building infrastructure. The route funnels trains from multiple destinations through a narrow ‘core’ section of central London on a single railway line in each direction before those trains are then split up again towards multiple final destinations. This creates pressure on the five core stations that are located between St Pancras in the north and London Bridge in the south as every train must pass through them.

Add to this the fact that these stations were operated largely independently of each other prior to Thameslink and there would obviously be a potential for service failure and train disruption. Unlike London Underground stations, where the focus is more on security of the train service, national railway stations tend to be focussed more on passenger throughput and the transfers between services.

It was recognised by the Thameslink Programme that to reach the objective of 24 trains per hour through the core, the route would require several pieces of network infrastructure to work seamlessly together. These pieces included the trains arriving at frequent and correctly spaced intervals, the dwell times in stations being kept to a minimum, the passenger flow on and off the platforms being optimal and the correct passenger information being available and displayed to them. It was clear that a failure in any of these elements could cause service disruption that would be very difficult to recover from.

The challenge was how to optimise and smoothly serve the trains through the core stations and get the door opening to door closing times down to 45 seconds and a maximum station dwell time of two minutes. This challenge led to the creation of the Integrated Station Management System (ISMaS).

Fig 1. Diagram showing breakdown of station dwell times

The objectives of ISMaS

The Thameslink Programme team set out to build a control system that linked up and monitored all of the core stations’ critical facilities using existing systems and available data wherever possible. The requirements were:

  • The system must allow staff to more quickly respond to incidents and have direct contact with the Route Operating Centre.
  • The system would need to be intuitive enough that one person could operate it and oversee all five stations at once.
  • It would need to be based on available technology and not require any costly new installation of equipment on the railway or at the stations.*
  • It would need to be a remotely operated system but fully connected at all times.
  • The system would need to combine incoming digital and analogue information from the various different and incompatible systems in use at each of the five stations.
  • From the mass of incoming data an operator would require simple methods of communication to feed back to the station staff at each of the five stations.

The system’s nine monitored feeds

These feeds of information were identified as critical for ISMaS to function.

  1. A view of live CCTV from the stations.
  2. Access to announcements going out on the Long Line Public Address (LLPA) system.
  3. Communication capabilities with the train operator’s platform radios. This only included Govia Thameslink Railway (GTR) employees although other operators are present in certain stations.
  4. A feed to monitor train dwell times in each station.
  5. A way to monitor platform congestion in each station.
  6. A way to monitor any lifts or escalators that are taken out of public use.
  7. A way to monitor any fire detection or system failures.
  8. A way to monitor the Public Address/ Voice Alarms (PAVA) and any failure or degradation of these.
  9. A way to monitor LUX levels in stations they fall below operational use.

The actual ISMaS ‘desk’ would be located remotely in the Three Bridges Route Operations Centre (TBROC), at the southern end of the route near Crawley. The desk would allow the on-duty GTR Station Control Manager (one of several people manning the role) to monitor the operational performance of the platform-to-train interface across the core stations. Three Bridges is also the Route Operations Control for the rest of the Thameslink route providing far greater route oversight if needed.

The ‘eye in the sky’

Once the system was designed, the supplier, Telent, was tasked with building the software and hardware interface and linking up the required data feeds. This was a complex challenge due to the variety of different systems such as fire alarms, CCTV etc. in use at each station. The ISMaS project at this stage effectively became an IT solution in order to get data collected and sent to Three Bridges.

Using the functionality agreed between Network Rail and GTR, the GTR Station Control Manager can now communicate with and provide advice to the station staff where situations arise that could have an impact on the train service, i.e. platform overcrowding, lifts being out of use, station emergencies and train faults etc.

With better information about what’s happening up and down the line, each station’s platform staff can better control the train dwell times in stations, plan and warn others about potential overcrowding and prepare for disruption recovery.

Outcomes, recommendations and lessons learned

ISMaS was the first system of its kind installed on the national rail network. It was clear after it began that it would be more of a specialist IT project than its initial inception had suggested. For this reason, the system took longer than expected to reach operational readiness because of developing a means to integrate the disparate systems operating at each station.

In some cases this included the need to upgrade to an IP-based connectivity and the need to add new sensors and infrastructure onto the operational platforms for detecting the presence of trains at each station. This ultimately led to improvements being needed in the station’s own monitoring and data connections but it also meant this stage had to be completed first which caused delay.

Other constraints included using Network Rail’s existing station telecoms system which would have to be migrated to an IP based network using FTNx, this required new connectivity infrastructure at each station and at the ROC which proved to be time consuming in terms of design clarifications and commissioning however has become the basis for primary connectivity between station and ROC for future projects.

One of the great successes of the project was the intuitive user interface of ISMaS. Through the early involvement of GTR and Telent in planning the system requirements and by following the example of the London Underground system that was demonstrated to Network Rail, a baseline target for the required features and functions was established. The final system is very easy to navigate and understand for the user and this is thanks to the work that was put in at the start.

Fig 3. The user interface of the system

Since the preliminary system switch-on of ISMaS around Christmas 2018 and then full operation starting in June 2019, the system has been working well. The station teams are already showing a 30% improvement in their recovery times from incidents or disruption at the core stations with a better flow of communication between stations, passengers and the train operator.

Once it is fully proved, there’s potential for ISMaS to be expanded to control other stations on the route such as East Croydon, West Hampstead and Finsbury Park where trains passing through are often impacted by unknown station incidents further up or down the line.

*Note: the majority of the functionality was provided by linking into existing systems, however new detectors were installed for lux level and train dwell time monitoring.



Case Study produced by Laurence Ager, Network Rail, September 2019.

Further information

For more information on this Learning Legacy case study please email

Case study