Proceedings 2002/2003 - IRSE
Proceedings 2002/2003 - IRSE
Proceedings 2002/2003 - IRSE
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
60<br />
SIGNALLING CONTROL CENTRES TODAY AND TOMORROW<br />
display of text messages, advisory speed limits, and<br />
updated timetables, and these are defined in a draft<br />
CENELEC standard. However, with the exception of<br />
text messages, these additional features are not<br />
supported in the UNISIG Class 1 standards which<br />
are the current baseline for ETCS specification. The<br />
paring down of features in the Class 1 specifications<br />
is a deliberate policy to limit the scope to those<br />
functions which are essential for safety and interoperability.<br />
This has undoubtedly been a good move<br />
to curtail the debate on specifications and move<br />
ETCS from concept to reality, but it would be<br />
unfortunate if “value added” features can never be<br />
added to the basic system.<br />
In fact, although these messages would appear on<br />
the ETCS DMI, they do not actually need to be part<br />
of the ETCS SIL4 safety critical system, ie the RBC<br />
at the control centre and the EVC (European Vital<br />
Computer) on the train. The DMI in the cab is similar<br />
in many respects to the signaller’s workstation in the<br />
control centre. It is a lower-integrity system<br />
(typically SIL2) which provides the human interface<br />
to the safety system and implements some<br />
additional less critical functions. One of the fundamental<br />
principles of safety critical systems design is<br />
to partition the design to minimise the complexity of<br />
the high-SIL components, so we should be thinking<br />
of architectures which allow the signalling control<br />
centre systems to talk to the DMI as a SIL2-SIL2<br />
interface without adding complexity to the SIL4<br />
ETCS components (see Figure 8). There are a<br />
number of ways in which this could be implemented.<br />
1 Define additional messages at the ETCS<br />
“air-gap” interface, and implement software in<br />
RBC and EVC to pass these through to control<br />
centre and DMI.<br />
2 Use the existing text message facility by defining<br />
special messages which are recognised as an<br />
instruction to update the DMI instead of a genuine<br />
text message direct to the driver – no change<br />
required to RBC and EVC.<br />
3 Establish a direct link between the DMI and the<br />
GSM-R radio on the train, bypassing the EVC, and<br />
a similar link at the signalling control centre<br />
bypassing the RBC – again no change required to<br />
RBC and EVC.<br />
CONCLUSION<br />
The recent report of the UK ERTMS National<br />
Programme Team 5 identified improvements in<br />
network capacity as a possible foundation for a<br />
business case for the investment that will be<br />
required in ETCS. The report showed that to achieve<br />
this requires the adoption of ETCS Level 2 without<br />
lineside signals. This type of signalling system could<br />
Signalling<br />
Control<br />
System<br />
ETCS<br />
trackside<br />
(RBC)<br />
Communication via ETCS SIL4 systems<br />
Communication independently of SIL4<br />
systems<br />
GSM-R communications<br />
Driver<br />
machine<br />
interface<br />
ETCS<br />
trainborne<br />
(EVC)<br />
Figure 8: Architectures for control centre<br />
communications to driver<br />
be controlled from existing signalling control centre<br />
systems with minimal change, but greatest benefits<br />
are likely to come if we establish a traffic management<br />
layer of communications between the control<br />
centre and the cab to complement the safety layer<br />
provided by ETCS. Defining the requirements for<br />
such systems and implementing them in a manner<br />
which achieves interoperability will be a significant<br />
challenge for signalling control systems engineers<br />
and operators.<br />
ACKNOWLEDGEMENT<br />
I would like to thank AEA Technology Rail for<br />
permission to publish this paper, and my colleagues<br />
in AEA Technology Rail and Railtrack who have<br />
supplied information and comments.<br />
REFERENCES<br />
1 Yoker Integrated Electronic Control Centre, R C<br />
Nelson, <strong>IRSE</strong> <strong>Proceedings</strong> 1986/7<br />
2 IECC Development, K.Thomas, <strong>IRSE</strong> News Issue<br />
69, November 2000.<br />
3 IECC Upgrades and SPAD Alarm, T Weston, <strong>IRSE</strong><br />
News Issue 78, May <strong>2002</strong>.<br />
4 Human Factors and York Signalling Centre, J<br />
Wood, <strong>IRSE</strong> News Issue 72, May 2001.<br />
5 The ERTMS Programme Team Final Report Issue<br />
to HSC – April <strong>2002</strong>, D Waboso, Railway Safety.