Proceedings 2002/2003 - IRSE

EURORADIO AND THE RBC 33
another while maintaining their normal operation in
ERTMS Level 2.
To ensure safe communication between the
trackside signalling system and the train whilst
maintaining operational efficiency requires that the
RBC is based on a high integrity architecture that
can tolerate failures. When in normal operation, the
RBC sends to each of the trains with which it
communicates in its area of control movement
authority information, together with route
geographic information that the train must observe
in calculating a safe speed. The train sends
information about its location to the RBC to enable
calculation of appropriate movement authority
parameters by the RBC. Communication between
the RBC and the train is therefore bi-directional via
the mandated GSM-R communications network,
using the protocol defined later in this paper.
The regulation and traffic control system (CTC or
Local Control) sends requests for route
establishment to the interlockings. The interlockings
set up and lock the routes requested by the
CTC/Local Control, and send the information that
the route is set up and locked to the RBC. When the
RBC undertakes control of a train that requires to
use a route, it checks that the interlocking has
reserved that route for that train before sending the
movement authority for the train to use it. Once the
train has entered the route, or in the event that the
train does not use the route, the RBC and the
interlocking co-operate to release the route, so as to
ensure the consistency of the information managed
by the RBC and by the interlocking. The CTC/Local
Control retains its current functions of requesting
route establishment. The interlocking retains its
current functions, together with the additional
functions of proceed and approach locking release
to the RBC.
For the ERTMS Level 2 system, the train’s location
is mainly determined by means of axle counters or
track circuit occupancy. The interlocking detects
track occupancy and sends this information to the
RBC. The RBC uses this track occupancy information
to determine the movement authority limit for
the train (regardless of whether the train ahead is
under its control). The location information sent by
the train to the RBC is used for various functions,
such as: association of track circuit occupancy with
the train; determination of the point where the
geographic information associated with the
movement authority begins; and diverse checking of
the train’s location once the routes are released.
When a train is approaching the boundary between
two RBCs, the RBCs start to communicate with
each other so that the movement authority can be
extended across the boundary. As the train is
crossing the boundary, control passes from the
“Handover RBC” to the “Accepting RBC”.
3 INTRODUCTION TO EURORADIO
The choice of GSM for the radio bearer network
was made some years ago, and work progressed in
the EIRENE project to specify the additional
requirements for railways. The MORANE project was
given responsibility for the detailed specifications
and for demonstrating the suitability of GSM-R (ie
GSM for Railways). However, because of the
complexity of a modern digital radio system, it is
impossible to guarantee safe transmission, or even,
in general, that it cannot be hacked into. It was
therefore necessary to define an additional module
between the application and the bearer that would
be responsible for the safe transmission of data
across the radio network – this was EuroRadio.
Specifications for EuroRadio have been available
for about seven years, written by various groups and
in various stages of release. The specifications have
always assumed concept implementation on
GSM-R, which is regarded as an Open Transmission
System as defined by CENELEC prEN50159-2. It
must be remembered that the specifications are only
concerned with interoperability, not with defining a
complete system, although they are limited to a
circuit switched network. Even so, there is scope for
a number of different implementations where
interoperability is unaffected – this particularly
affects functions that are local to one end of the link.
In this paper, a typical implementation is described,
but it is not necessarily the only one possible.
The form and electronic etiquette of the
communication, known as the Protocol Stack
design, has been stable for several years (see Figure
1). The reason for having layers within the protocol is
to allocate particular functions to particular software
modules, leading to a design where changes in one
module do not have a knock-on effect on other
modules. There is an important principle here, that a
layer does not need to ‘look into’ the message that
it is given from the layer above for any information it
needs, which means a layer can (at least in theory)
be changed without changing the layers above or
below.
7
6
5
4
3
2
1
APPLICATION
APPLICATION LAYER (EMPTY)
PRESENTATION LAYER (EMPTY)
SESSION LAYER (EMPTY)
SAFETY LAYER
TRANSPORT LAYER
NETWORK LAYER
DATA LINK LAYER
PHYSICAL LAYER (GSM)
Figure 1 – OSI Model