06.03.2014 Views

Proceedings 2002/2003 - IRSE

Proceedings 2002/2003 - IRSE

Proceedings 2002/2003 - IRSE

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!