Case Study:

Integrated Station Management

System (ISMaS)
Thameslink Programme
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
Fig 2. The Three Bridges ‘Eye in the sky’ control desk
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.
 The left screen is divided into
six main areas:

1. Toolbar
2. Subsystem View Pane
3. Alert List
4. PA Pane
5. Inhibit Control
6. CCTV Pane
7. Radio Control Pane
8. Asset Selection

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.

Author

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

Further information

For more information on this Learning Legacy case study please email
[email protected]