IADIS Virtual Multi Conference on Computer Science and Information Systems 2005

BRAIL REQUIREMENT ANALYSIS

Jean-Louis Boulanger
Universit de Technologie de Compigne
Laboratoire HEUDIASYC, UMR CNRS 6599,
60205 Compigne Cedex, France

ABSTRACT
In the European railways standards (CENELEC EN 50126, EN 50128 and EN 50129), it is required to obtain evidence of
safety in system requirements specifications. In the railway domain, safety requirements are obviously severe. It is very
important to keep requirements traceability during software development process even if the different used models are
informal, semi formal or formal. This study is integrated into a larger one that aims at linking an informal approach
(UML notation) to a formal (B method) one.
KEYWORDS
Formalization, Level Crossing, Risk analysis, System Requirements, Traceability, UML.

1. INTRODUCTION
The focus of this paper is on the development of system requirements specifications with respect to fulfilling
demands of European railways standards. In spite of progress carried out in software development, designing
a complex system while respecting its safety requirements, remains very hard. Ambiguities and defects in
system requirements specification may have consequences on the whole system development. We investigate
how the Unified Modelling Language (UML), can be used to formally specify and verify critical railways
systems. A benefit of using UML is it status as an international standard (OMG) and its widespread use in the
software industries. The reader interested by more details in syntax and semantic aspects can refer to the
reference guide of UML. Even if UML notation is a language in which models can be represented, it doesnt
define the making process of these models. Nevertheless, several dedicated tools have strengthened the
popularity of UML. These tools allow graphic notation and partial generation of the associated code and
documentations. The UML notation is known by most computer scientists and is now used in several
domains. Using UML class diagrams to define information structures has now become standard practice in
industry. Recently, the critical application domains have used the notation and several questions exist around
this use. Safety invariants can be derived from hazard analysis and can be supported by a system model in
diagrams of UML.

2. CASE STUDY
To illustrate our approach, we will choose to design a level crossing. This example is inspired by [3]. The
term level crossing, in general a crossing at the same level, i.e. without bridge or tunnel, is especially used in
the case where a road crosses a railway; it also applies when a light rail line with separate right-of-way
crosses a road; the term "metro" usually means by definition that there are no level crossings. Firstly, a
single-track line, which crosses a road in the same level, is modelled (figure 1). The crossing zone is named
danger zone. The most important security rule is to avoid collision by prohibiting road and railway traffic
simultaneously on level crossing. The railway crossing is equipped with barriers and road traffic lights to
forbid the car passage. Two sensors appear on the railroad to detect the beginning (train entrance) and the end
(train exit) of the level crossing protection procedure. The level crossing is not in an urban zone this implies a

343

ISBN: 972-8939-00-0 2005 IADIS

sound signalisation. Traffic lights consist of two lights: one red and one yellow. When they are switched off,
road users (drivers, pedestrians,) can cross. When the yellow light is shown road users (drivers, cyclists,
pedestrians etc.) shall stop at the level crossing if possible. In the other case, the level crossing is closed and
railway traffic has priority. The yellow and red light never must be shown together.
Road
Train

Barriers

Sensors

D1
Sensors

Red Lights

Figure 1. Single-track line level crossing

3. ENVIRONNEMENT
It is often difficult to understand requirements if they are stated as a list. For that reason, functional
requirements (and even some non-functional requirements) can be expressed by using some use cases. A
use case analysis involves the following steps:
o Determine the actors, i.e. any outside entities (people, systems, etc.) that interact with the system.
o Identification of Use Cases (name, purpose, goal, pre- and post-condition, ..).
A use case diagram describes and traces the functional requirements of the system and describe how the
system can and will be used. The use case diagram gives an overview of the model.
UR3: The railway crossing is equipped with barriers and road traffic lights. Traffic lights at the level
crossing consist of a red and a yellow light.
1: off
4: yellow
5: red

OP

Light

LC
8: sendDefault
6: lower,
3: isActivated
7: timeout
2: activation

Physical
Train

: TrainSensor

Barriers
10: repair

9: repair

11: repair

: Human

Figure 2. Contextual diagram

344

IADIS Virtual Multi Conference on Computer Science and Information Systems 2005

3.1 Failures
The user requirement gives information concerning the failures and their direct effects on the system.
UR12 : Possible failure conditions have to be taken into account for a safe control of the level crossing and
the train.
In our model, failures of yellow or red traffic lights (to be separately), barriers, the vehicle sensor and the
delay or loss of radio network are considered.

<<communicate>>

Unavailable receiver

Broken Link

(from cas d'util isation)

(from cas d'util isation)

<<include>>

<<include>>

Operation center
(from acteurs)

<<include>>
Bad behaviours for level crossing
communication system

Saturated Link
(from cas d'util isation)

(from cas d'util isation)

<<communicate>>

<<include>>
Railways system
(from acteurs)

Unavailable Modem
(from cas d'util isation)

Figure 3. Use case

Use case of figure 3 is an example where we model some communication failures. Operational scenarios can
be specified by means of sequence diagrams of UML (see Figure 4).

Barriers :
(Barriers)

Light : Light

LC : LC

: TrainSensor

Physical Train :
(Physical Train)

OP

: Human

off

yellow

activation

isActivated

red

lower,

timeout

sendDefault

repair

repair

repair

Figure 4. Sequence diagram

3.2 Risk analysis

According to EN 50129, risk analysis essentially consists of four steps: 1) system definition, 2) identification
of operational hazards, 3) consequence analysis and 4) risk assessement. The identification of operational
hazards (step 2) can be done by the analysis the user requirement (UR) and/or by analysis of classical risk. In
our case, the UR contains:

345

ISBN: 972-8939-00-0 2005 IADIS

UR2: The intersection area of the road and the railway line is called danger zone, since trains and
road traffic must not enter it at the same time to avoid collision.
In figure 5, this UR introduces a use case that introduces the basic risk.
Access to the danger zone

<<include>>

<<include>>

Train

Road Traffic

one access

Figure 5. Use case from UR2

In first time, we derive safety requirement by using FTA (Fault Tree Analysis). A FTA is a graphical
technique that provides a systematic description of the combinations of possible occurrences in a system,
which can result in an undesirable outcome (for more information see International standard IEC 61025).
This method can combine hardware failures and human failures. For safety-critical systems, the root node of
the tree will often represent a system-wide, catastrophic event taken from an existing hazards list. From the
collision risk we can derive the next FTA:
Collision

Train
access
granted
and not
car
access
denied A

Car
access
granted
and not
train
access
denied B

Train
doesnt
respect
signal

Car
doesnt
respect
signal

Car
access
granted
and
train
access
granted C

Figure 6. Fault Tree Analysis

The first FTA is split in some part. The D part concerns some human errors. The C part introduces the
principle property for the system: The system does not granted access in same time to train and road traffic.
The A and B part deals with absence and failures of equipments (barrier, traffic light, communication, train
sensor).
Train access granted and not car
d i d

No Traffic Light

No traffic
Light

Traffic Light is
always turn off

No Barrier

Bad
color

No
barrier

Figure 7. Fault Tree Analysis continue

346

Barrier is
always up

IADIS Virtual Multi Conference on Computer Science and Information Systems 2005

3.3 System Modelling

For modelling the system structure and interfaces between system objects class diagrams are suitable (see
Figure 8). The class diagram describes the relationships between classes and shows the logical view of a
system (static view). In respect with safety analysis, the control system provides the capability to authorise
the danger zone access for road traffic or for train. This system immediately reports the occurrence and repair
of failures to the Operation Center.

Operating Center
(from User Requirement)

control system
(from User Requirement)
OpenedLevelCrossingAndAccessGrantedToRoadTraffic()
ClosedLevelCrossingAndAccessGrantedToTrain()
sendMessage()

Road Traffic

Train
(from User Requirement)

(from User Requirement)

Figure 8. First Class diagram

3.4 Sub-System Modelling

UR 3: Decentralized radio-based control system
This UR indicates that the system is split in 3 parts: 1) Communication sub system, 2) Train control system,
and 3) Level crossing system.
Projet TX
Maquette de diagramme de classes en s'inspirant
des diagrammes de squence servant l'analyse
de la problmatique.

TCSUInterface
confirmation : BOOL
OperationCentre
1

askConfirmSafetyMode()
showFailure()
TCSComManage
r

send()
receive()
connect()
deconnect()

TCS = Train Control System

LC = Level Crossing
LCTS = Level Crossing Train Sensor

LCComManager

1
Communication

send()
receive()
connect()
deconnect()
reportError()
askControlCenter()
sendFailureState()
sendSafeStatus()

LCLightManager
Current_Color : L_Color
switchRed()
switchYellow()
switchOff()

1
1
TCSLevelCrossingCo
mManager

1
TCSLevelCrossingBehavior
state : TRAIN_STATE
1

<<physical>>
Light
(from conception)

state : LIGHT_STATE
1

red()
yellow()

2
on()
off()

detectLC()
askActivate()
askDeactivate()
getLCSState()

reportLCSFailureState()
changeState()

<<physical>>
LightManager +connect to

1
LCMain

activate()
deactivate()

1
LCBarriersManager
barrier_STATE
1
lowerBarrier()
upperBarrier()
1

<<physical>>
TrainPhysical
speed : SPEED
previous_speed : SPEED
position
decreaseSpeed()
increaseSpeed()
brake()
unbrake()

<<physical>>
TrainSensor
State : Occupation
Position : POSITION

PresenceTrain()
Activated()
Desactivated()
Fail()

+connect to

<<physical>>
Barrier
Barrier_State : BARRIER_STATE
upper()
lower()

1
LCTSManager
2

activate()
deactivate()

Figure 9. Complete class diagram

347

ISBN: 972-8939-00-0 2005 IADIS

The figure 9 purposes a complete class diagram which introduced some interactions between:
o Level crossing control system and physical equipment (barrier, traffic light, train sensors),
o Train control system and physical equipment (train sensor),
o Level crossing control system and communication,
o Train control system and communication,
o Operation center and communication.
Statechart diagrams, also referred to as State diagrams, are used to document the various modes ("state") that
a class can go through, and the events that cause a state transition. The state-transitions graph formalism is
not a UML innovation. It has often been employed in other contexts and a large consensus, from David
Harels works, exists around this notation. It introduces the description of possible sequences of states or
actions which can occur to an element during its life. Such sequences arise from element reaction to discrete
events. We coded all properties in UML by using OCL constraints attached to classes or sets of associations
to specify safety and operational invariants of reactive systems in a concise manner.

4. CONCLUSIONS
The main difficulty to specify railway case study is the less of harmonisation between the different European
systems. The level crossing modelling presented here gives a first step to a computerised management of
level crossing. In this paper, we purpose a method for modelling a safety railways application. But the
precondition to use UML diagrams for system specification, which is usable for formal correctness proofs
and refutation checks, is that the UML has to be used with a precise semantics. This is possible by definitions
of translation rules for the conversion of UML notation in a formal language. Our global project (see [2])
purposes to transform a semi formal modelling (UML model) to a formal specification (B method, for more
information see [1]).

REFERENCES
[1]Abrial, JR. (1996). The B Book - Assigning Programs to Meanings. Cambridge University Press, August 1996.
[2] Jean-Louis Boulanger, Philippe Bon et Georges Mariano (2004) From UML to B - a level crossing case study,
COMPRAIL 2004, 17-19 May 2004, Dresden Germany.
[3] Jansen, L. and Schneider, E. (2000) Traffic Control Systems Case Study: Problem Description and a Note on
Domain-Based Software Specification , Institute of Control and Automation Engineering, Technical UNIVERSITY
of Braunschweig, 2000.

348