Proceedings 2002/2003 - IRSE

54
SIGNALLING CONTROL CENTRES TODAY AND TOMORROW
many options to choose from, and there is even a
facility to embed “area specific code” to tailor the
decision making to special requirements of each
site. All this means that there is a significant risk of
under-performance of ARS if there is insufficient
understanding of the true operating requirements at
the design stage. This did happen in practice,
particularly in the early years, where ARS data
preparation was being undertaken at a number of
sites by relatively inexperienced staff. Lessons have
been learned and the process is now much more
robust due to:
• dedicated staff undertaking all IECC data
preparation work;
• co-location of the data preparers with the
software/system developers;
• formal dialogue with operators using questionnaires
and specifications;
• system testing with simulated train movements
to a real timetable.
There is also now a much better understanding of
what are the reasonable limits to flexible utilisation of
the infrastructure. An example of this has been the
approach to routing of trains over the 6-track
bi-directional approach to Paddington station in
London. As originally specified there were a large
number of alternative routes available and no
pre-determined rules for their selection. This was not
a problem for ARS, which applied its regulation
algorithms to determine the optimum choice of route
for each train. However, this resulted in decisions
which appeared unpredictable to signallers and
drivers as ARS varied route setting decisions for the
same train from day to day to achieve a few seconds
of train delay savings. As part of the general review
and simplification of signalling on the approaches to
Paddington in the aftermath of the Ladbroke Grove
accident, the timetable and ARS rules have been
changed so that each train now has a preferred
route and a small number of alternatives from which
ARS can select. If future the application of ARS will
be one of the factors to be considered when undertaking
track layout risk assessments for new
schemes.
Another factor which has only slowly been
recognised is that there is a case for more frequent
updating of ARS than traditional signalling control
centre systems. The traditional expectation is that an
update occurs only when there are track layout
changes or equipment replacement. In the case of
ARS there are reasons why updates may be required
more frequently:
• the complexity and novelty of ARS means that
there is a steady stream of ideas for minor
improvements to the software;
• there may be a need to make changes to deal
with the evolution of traffic patterns and timetables.
Funding of such changes has often been a
problem, as budget allocations tend to go to
projects which produce physical results, such as
track remodelling, but there is a growing realisation
that regular updates of a complex system such as
ARS can be regarded as routine maintenance to
keep the system performing at peak efficiency. This
can often be justified in a business case by predicting
the reduction in train delays which can be
achieved – on the privatised UK railway today the
conversion of train delays to money is precisely
defined. Railtrack now recognises that ARS subsystems
are likely to be updated more frequently
that other parts of IECC, and intends to use the new
CD-ROM facility to make these changes as
efficiently as possible.
TIMETABLE PROCESSOR
As well as its fixed rules and real-time information,
ARS requires timetable data including information on
conditional and special workings on a daily basis.
The Timetable Processor (TTP) is the IECC
sub-system which provides the interface between
the real-time ARS and the off-line train service
database (TSDB), the Railtrack system used to
create and update timetables. TTP uses the same
processors as the real-time IECC sub-systems, but
running the Unix operating system with a hard disc
drive. The data flows between TTP, ARS and the
signaller are shown in Figure 4.
TTP provides a number of facilities to ensure that
ARS gets a complete and correct timetable, both by
checking the incoming information and making
corrections and additions if necessary. Validation
facilities include a check that the incoming data
provides all the necessary information about each
train required by ARS, and output of summary
timetables showing arrivals, departures, platforming
and next workings at major stations. Normally a new
timetable is loaded into ARS twice a day, but there is
a facility for “very short term” changes to be loaded
as soon as they are entered. This allows changes
such as swapping a defective train set for a healthy
one at a terminus, or termination of a train short of
its usual destination, to be entered into TTP and
implemented via ARS without fallback on to manual
route-setting.
There is also a facility for a signaller to create a
timetable for a train using a pre-defined “special
timing pattern”. This allows the signaller to select a
pre-defined route and stopping pattern for the train.
TTP then calculates a complete timetable starting at
the train's current location and sends it back to ARS.
On one occasion when a strike was cancelled at the
last minute and there was no timetable available, a
complete day’s operations at one IECC were run
using special timing patterns.
Another facility available to the signaller is the
option to invoke a contingency plan. This is a set of
rules for modifications to the timetable to deal with a
predefined change to the normal pattern of working.
An example of this would be operating all traffic on
a 4-track railway over two tracks only between
selected crossovers during engineering work. The
rules are pre-defined as part of the ARS data
preparation process and, when a contingency plan
is invoked, TTP calculates the changes to the
timetable and sends them to ARS. Trains running to
contingency plans or special timing patterns are
distinguished on the signaller’s workstation screen