IRSE News 150 Nov 09.pdf

A CASE STUDY IN SAFETY
When the Train A passes 3 Signal, 3 Signal is automatically
placed at STOP. When the rear Train A passes the overlap limit
for 3 Signal, 4 Signal is automatically commanded to display a
PROCEED aspect, but only does so if it is safe i.e. there is no
train detained at 4 Signal with the level crossing open.
SYSTEM ARCHITECTURE
The signal interlocking system that performs the safety functions
has a distributed architecture. The system consists of
programmable logic controllers located geographically along the
railway and interconnected with point to point serial data links,
such that, referring to Figure 4, data that needs to go from
Controller C to Controller A needs to go through Controller B.
18
Figure 4: Distributed architecture showing area of control
It is important to note, that the architecture is not a masterslave
architecture, where the slave controllers perform an input/
output function as directed by the master controller. For this
application the interlocking function is distributed over each of
the controllers.
Controller Technology
The controllers are commercial-off-the-shelf (COTS) products
specifically developed for railway signalling interlocking
applications. All of the controllers are of the same type and
version. Each controller maintains a time-stamped event log.
However the controller clocks are not synchronised.
The technology is modular and programmable. It uses plugin
modules for connectivity to different types and quantities of
inputs and outputs. Thus only the hardware actually required for
an application needs to be installed. The technology is supported
by graphical tools for application design, simulation and testing.
The suite of tools is used to define the modules and logical
operation of the system and verify and validate the application
logic.
To satisfy the safety requirements the controllers operate on
a fixed, nominally 1 second time cycle. Consequently an input
change will not be immediately detected, however there is
certainty as to when an input change will be detected and
processed.
IRSE NEWS | ISSUE 150 | NOVEMBER 2009
THE DELIVERY PROCESS
The system was delivered under a design, build, test and
commission contract arrangement, where the contractor is
responsible for delivery in accordance with the specification, and
the railway organisation is responsible for verifying compliance
and validation of the system to key signalling safety and
operating principles.
The contractor organisation was also the developer of the
COTS controller technology and had a considerable history for
deploying that technology on many railway networks, including
that of the railway organisation commissioning the contract
works. However this was the first time that a distributed
interlocking architecture was to be deployed; neither the
contractor personnel undertaking this work, nor the railway
personnel verifying and validating this work had any prior
experience in implementing a distributed interlocking
architecture with this technology.
The delivery model and the underlying processes had been
well established. These had evolved over time and were
considered best railway practice at the time. The personnel
involved were appropriately qualified and experienced in the
design of signal interlocking application logic of this complexity
and in the use of the technology, albeit not in the design and
implementation of the distributed interlocking architecture using
this technology.
Hazard Analysis
Because the project was considered “routine” there was no
specific hazard analysis performed for the application design.
The technology had been used for similar applications, albeit
with a different architecture, and the application scenario
i.e. an actively controlled level crossing in the vicinity of road
traffic signals and station platforms, was not new. The hazards of
the application were well understood. The potential hazards due
to the processing latency of the controllers and their associated
communications links were understood, but how to design for
them was not. The application manual for the controllers did
warn of the latency, but provided no guidance as to how this
latency should be treated to eliminate the hazards or test for them.
Application Logic
The railway organisation specified the interlocking requirements
for this application. The contractor designed the controller
architecture, the modules and the application data and
submitted the “design” for review by the railway.
The reviewed design was amended as appropriate by the
contractor and the application data produced for each of the
controllers. The contractor tested the amended application
design for compliance with the specification using both
simulation tools and the target hardware (the personnel were
required to be independent i.e. they were not involved in
developing for the design under test).
The application logic was then tested by the railway
organisation to validate compliance with the key signalling safety
and operating principles using simulators and the target
hardware. Those tasked with the validation task had no
involvement in the development of either the interlocking
specification or any of the design reviews.