RATP Safety Approach For Railway Signalling Systems PDF

RATP safety approach for
railway signalling systems

ReSIST summer School 2007
Pierre CHARTIER
Summary
1. Introduction
2. Hardware fault detection
3. Software fault avoidance
ReSIST summer School 2007 - Pierre CHARTIER - RATP safety approach for railway signalling systems
261
Introduction
Global railway system

Rolling stock
Environment
Signalling / Train
control system
Access / Evacuation
Infrastructure
Operation / Maintenance
Station
Track
Power supply
Introduction
Events to be feared at global system level
Fire / explosion
Derailment / overturning
Panic
Electrocution / burn
Collision
Individual accidents (fall, )
Others (terrorist attack, natural disaster, structure
breaking, )
262
Introduction
Transport system overview (METEOR example)

1. video in train
2. Inter-phone in train
3. video in platform
4. Inter-phone in platform
5. Platform screen doors
6. onboard equipment
7. transmission
8. track-vehicle
communication
9. interlocking
10.trackside equipment
11.operation control center
Introduction
Railway signalling system
Main protection against collision and derailment

Safety critical mission
Historically 2 types of system
Interlocking
Automatic train protection
Main safety measure : stop all trains and power off the
traction power supply
263
Introduction
RATP technical evolution

Permanent ATP
Metro
1970
1980
Fail-safe
equipment
Electronic
Manless interlocking CBTC Manless
METEOR
OURAGAN L1
Permanent ATP
RER - SACEM
1990
2000
Coded processor
B formal
method
Safety-critical
software
2010
SCADE
Redundant
Processors
Introduction
SACEM RER A
Saturation of RER line A (80s) SACEM project

Objective :
To increase transport offer by raising train frequency
But incompatibility between
train spacing reduction,
and traditional signaling
264
Introduction
SACEM RER A
Automatic Train Protection

Control train spacing
Control train speed
Protect switching zones
Switch between cab signal and trackside signalling
First safety-critical computing system in railways
Introduction
SACEM RER A
SACEM functions require the use of computers

Two main concerns :
Detection of errors due to hardware
coded processor
Avoiding faults in software
formal methods
265
10
Hardware fault detection
Coded processor main concepts
Based on data and program encoding

Encoding done automatically by specific tools
Detect run-time errors
If an error is detected, the hardware sets the system
in a fail-safe state
266
12
Coded processor onboard-wayside interface
Fail safe
Safety checking
Train ahead
Encoded processing
Signalling and switching equipment
Wayside
Inputs
encoding
Encoded
fixed data
Onboard
Inputs
encoding
Data
processing
Safety checked
outputs
Transmitter
Receiver
Receiver
Transmitter
Safety checked
outputs
Data processing
Present train
13
Coded processor
Emergency braking
Fail safe
power supply
Cabsignal
Output
Speed and
distance
detector
Dynamic controller
Transmitter
Microprocessor
Coded
treatments
Information
from the cabin
Checking
of date
Signature
Reference signature
PROM
Receiver
Inputs
encoding
Dated
signature
Fail-safe clock
267
14
Coded processor safety data encoding

Data X = functional part X.F and coded part X.C
X.F : NF bits and X.C : NC bits
Tasks for the computer

Acquisition and coding of the fail-safe inputs
Processing the coded data
Conversion of coded data into fail-safe outputs
Setting the system into restrictive state in case of failure
15
Coded processor detected errors (1)
Differents kinds of errors :

Arithmetical error
Operator error
Operand error
Memory non-refreshed error
Branch error
268
16
Coded processor detected errors (2)

Components of the coded part
Arithmetical error ==> remainder r kx
Operator error ==> signature Bx
Operand error ==> signature Bx
memory non refreshed error ==> date D
Branch error ==> compensation, tracer
17
Coded processor architecture

Outputs checking
CES :
Inputs
encoding
Fail-safe
Inputs
Safety
Clock
CUC :
Central
Processing
Unit (coded)
CSS :
Outputs
Conversion
Fail-safe
Outputs
Coded data stream

CKD :
contrle
Energy supply for

Vital outputs
269
18
Coded processor Signature predetermination tool (OPS)

Inputs
Signatures
OPS
Sources
Compensation
Tables
COMPILER
Object code
LINKER
Run time code
Processor
Signature calculated dynamically
Reference
signature
(pre computed)
CKD
The OPS protects from the compiler failures,

therefore the compiler does not require specific qualification
19
Coded processor safety outputs
Setting of safety outputs

rereading of outputs
Safety
Inputs
CES
CUC
Computed
Outputs
Relay
NS1
CKD stream
CSS
CKD
Checking
Fail-safe outputs
Safety Power
Supply
Basic Power
Supply
270
20
Coded processor safety integrity level
Theoretical result:
Coded processor alone 10-12 h-1
Including transmission between onboard and
trackside equipment 10-9 h-1
21
Software fault avoidance
271
ATP role
Speed
ATPs command of
emergency braking
speed limitation
emergency braking
cab signalling
mouvement authority limit
Distance
23
Comunication-based train control (CBTC) systems

power supply
interlocking
equipment
operation control center
maintenance system
zone
controller
section A
I/O interface
platform
equipment
zone
controller
section B
Data communication system (LAN, radio, inductive-loop)
cabsignal
localisation
system
onboard
equipment
rolling stock
272
24
CBTC operation
train B movement
authority limit
zone
controller
train A
position
speed
profile
track circuit
virtual block
25
Comunication-based train control (CBTC) systems
Automatic Train Protection (ATP)

Automatic Train Operation (ATO)
Automatic Train Supervision (ATS)
273
26
Formal methods
1988 SACEM - First safety software in railways
Usual (unformal) software specification issues
lack of global approach with the system designer point of
view
ambiguous, not legible, not coherent, not complete
Validation issues
no certitude that the functionnal tests are sufficient
1998 First run of the subway line 14 Mtor
The B method is used to obtain :
a reliable and exact software design from specifications to
runtime code
27
B formal method
Goal
To get a software which meets completely its functionnal
specification by construction
Application fields
Sequential code with no interruptions (real time aspects, low
level softwares, operating kernels are not taken into account)
Large spectrum language
Unified framework and continuous process from specification to
code
274
28
B formal method
High level language
Abstract operators for specification needs
Concrete instructions similar to ADA or C ones
Model oriented approach
Software = data + properties + operations
Refinement process
Translation of the abstract machines into concrete modules,
and finally into code
Proof obligations
Conditions to check to ensure a strict mathematical
construction of softwares
29
B formal method examples of safety properties
Only equipped train which is located and in automatic

mode can have a target.
The trains locations computed by the SWE must be
correct with the actual trains locations on the line.
275
30
B development process
Unformal Requirements
Formal re-expression
B formal specification
PROOF
B refinement 1
PROOF
B refinement n
PROOF
PROOF
B implementation
Automatic and
Manual code translation
Code
31
B verification process
Functionnal tests
Integration tests
B refinement 1
Module tests
B refinement n
B implementation
Code
B proof obligations
=
exhaustive testing
276
32
B validation process
Formal
re-expression
All requirements are traced

within the B model
B refinement 1
Proof
Proof activities are checked
B refinement n
B implementation
Only for Manual
translation
Code is exhaustively compared

with B implementation
Code
33
B industrialisation
AtelierB : An industrial tool to specify, refine, implement

and prove B models
Statistics about Mtor B model
1150 B components
115 000 lines of B code
27 800 Proof Obligations (all proved)
86 000 lines of safe ADA code
277
34
B today in railway industry
Used by two railway leaders : SIEMENS and ALSTOM

Recent projects :
Canarsie Line (New-York),
North East Line (Singapour)
Projects size has increased more than twofold
35
Interlocking system
Track circuit
202
201
Zone 0
Zone 2
V2
Zone 6
Zone 4
V2Q
Zone 8
Zone 10
VB
Zone 12
VC
101
Zone 1
V1
Zone 3
Zone 5
Zone 7
V1Q
Zone 9
102
Zone 13
Zone 11
VA
103
VR
Route V1 to V2Q
Signals M (V2), H, KR, C
Switches 101, 201
Signal M (V1)
278
36
Relay interlocking
Main technology on
RATP network
Fail-safe relays
Man-machine interface
with button/switch
control panel
Increasing cost and
expensive reconfiguration
37
3
off-line
Electronic interlocking
Configured
interlocking graphs
Generic
signalling rules
Graph interpreter
real-time engine
Electronic interlocking
Z
o
n
e
0
Z
o
n
e
Z
o
2
n
e
Z
o
1
n
e
V
2
V
1
V
R
2
0
1
1
0
1
Z
o
n
e
3
Z
o
n
e
4
1
0
2
Z
o
n
e
Z
o
n
e
Z
o
6
n
e
V
2
Q
V
1
Q
2
0
2
1
0
3
Z
o
n
e
Z
o
8
n
e
9
Z
o
n
e
Z
o
1
n
0
e
V
B
V
A
Z
o
n
e
V
C
1
2
1
1
1
3
Site configuration
Wayside
equipments
Operator
279
38
Interlocking validation
Issue: how to be convinced that any combination of

generic graphs for any site configuration is safe ?
Heavy testing for both supplier and RATP on site
configuration
To reduce test effort for next interlocking sites, formal
proof of safety properties has been considered.
39
Interlocking proof
e.g. If a train is moving towards a switch
and if the signal is green,
then the switch must not move.
Derailment
Collision
17 refined
properties
Site configuration
Interlocking graphs
Generic
feared events
Configured
properties
Configured
interlocking graphs
Proof engine
Validation
280
40
Interlocking proof process (1)

Safety
properties
Configured
graphs
1
Configured
graphs
1
Translator 1
format 1
Configured
graphs
1
Configured
graphs +
properties
TECLA
TECLA
2
Configured
graphs
2
Translator 2
format 2
2
Configured
graphs +
properties
TECLA
TECLA
Translation process
41
Interlocking proof process (2)
1
Configured
graphs +
properties
2
Configured
graphs +
properties
TECLA
Equivalence
system
TECLA
Equivalence
constructor
TECLA
Proof engine
Properties
OK/KO
Proof Checker
Proof engine
Proof
OK/KO
Evquivalence
OK/KO
Proof Checker
ProofLog
Proof
OK/KO
ProofLog
Proof certification
Translation certification
281
42
Interlocking proof
The proof engine (from Prover Technology) is based on

combination of SAT techniques and other automatic
proof techniques.
Work in progress
Feasibility is established
Complete proof of a real interlocking configuration is
expected in a few months
43
Apparition of SCADE tools in railway industry
For a few years, SCADE has found favour with railway

industry
fitted for designing command-control systems
reduces developement cost
facilitates communication between specialist
engineers and software engineers
282
44
SCADE brief overview
based on a declarative synchronous language

Lustre, encapsulated in graphical representation
Software = variables + equations
Time is discrete (var n)N
clocks, temportal operators (pre, when, )
Equations between inputs and outputs
outn = (inn, , inn-p, varn, , varn-q)
45
SCADE proof process (1)

Safety
properties
1
System
Translator 1
SCADE
TECLA
TECLA
2
System
System
Translator 2
Code
System
TECLA
1
System +
properties
2
System +
properties
TECLA
Translation process
283
46
SCADE proof process (2)
1
System +
properties
2
System +
properties
TECLA
Equivalence
system
TECLA
Equivalence
constructor
TECLA
Properties
OK/KO
Proof engine
Proof Checker
Proof engine
Proof
OK/KO
Evquivalence
OK/KO
Proof
OK/KO
Proof Checker
ProofLog
ProofLog
Proof certification
Translation certification
47
SCADE proof
Example of safety property :

Two distinct trains must not cross their movement
autority limit
Work in progress
Feasibility on a real site configuration
System requirements specification coverage
Method to complete proof when safety properties are
not totally proved
284
48
Formal methods
reduce drastically test effort

provide a high level of quality and safety for
software
are applicable to industrial software projects
but have to take more into account the practical
aspects for using them (cost, competence, )
49
RATP renewal program: software development methods

OURAGAN CBTC
B method
Coded
processor
Manless CBTC
L3
L1
L5 WaySide
Equipement
SCADE
L3
L5
Redundant
processors
L13
285
50

RATP Safety Approach For Railway Signalling Systems PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RATP Safety Approach For Railway Signalling Systems PDF

Uploaded by

Copyright:

Available Formats

RATP safety approach for

railway signalling systems

Global railway system

Events to be feared at global system level

Transport system overview (METEOR example)

Railway signalling system

Main protection against collision and derailment

RATP technical evolution

Saturation of RER line A (80s) SACEM project

Automatic Train Protection

SACEM functions require the use of computers

Hardware fault detection

Hardware fault detection

Coded processor main concepts

Based on data and program encoding

Hardware fault detection

Coded processor onboard-wayside interface

Signalling and switching equipment

Hardware fault detection

Hardware fault detection

Coded processor safety data encoding

Tasks for the computer

Hardware fault detection

Coded processor detected errors (1)

Differents kinds of errors :

Hardware fault detection

Coded processor detected errors (2)

Hardware fault detection

Coded processor architecture

Coded data stream

Energy supply for

Hardware fault detection

Coded processor Signature predetermination tool (OPS)

The OPS protects from the compiler failures,

Hardware fault detection

Coded processor safety outputs

Setting of safety outputs

Hardware fault detection

Coded processor safety integrity level

Software fault avoidance

Software fault avoidance

mouvement authority limit

Software fault avoidance

Comunication-based train control (CBTC) systems

operation control center

Data communication system (LAN, radio, inductive-loop)

Software fault avoidance

Software fault avoidance

Comunication-based train control (CBTC) systems

Automatic Train Protection (ATP)

Software fault avoidance

Software fault avoidance

Software fault avoidance

Software fault avoidance

B formal method examples of safety properties

Only equipped train which is located and in automatic

Software fault avoidance

Software fault avoidance

Software fault avoidance

All requirements are traced

Proof activities are checked

Code is exhaustively compared

Software fault avoidance