-14000

4001
4002
4003
4004
4005

Project number:

prEN 50126-2

prEN 50126-2

Railway Applications - The Specification and Demonstration of Reliability, Availability,

Maintainability and Safety (RAMS)
Part 2: Systems Approach to Safety

Applications ferroviaires Spcification et dmonstration de la fiabilit, de la

disponibilit, de la maintenabilit et de la scurit (FDMS)
Partie 2: Approche systmatique pour la scurit

Bahnanwendungen
Spezifikation
und
Nachweis
Instandhaltbarkeit, Wartbarkeit und Sicherheit (RAMS)
Teil 2: Systembezogene Sicherheitsmethodik

4006
4007
4008
4009

von

Zuverlssigkeit,

prEN 50126-2

-2-

4010
4011

Table of content
Foreword ....................................................................................................................... 6

4012

Introduction ................................................................................................................... 6

4013

Scope...................................................................................................................... 8

4014

Normative references................................................................................................ 9

4015

Terms and definitions................................................................................................ 9

4016

Abbreviations ........................................................................................................... 9

4017

Tailoring the life-cycle ............................................................................................. 10

4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057

5.1
5.2
5.3

The life-cycle Model ....................................................................................... 10

The Hourglass Model...................................................................................... 10
Generic and specific safety acceptance processes ............................................ 13
5.3.1 Introduction ........................................................................................ 13
5.3.2 Safety acceptance process .................................................................. 14
5.3.3 After safety acceptance ....................................................................... 16
5.3.4 Dependency between safety cases ....................................................... 16
5.3.5 Relationship between safety case dependencies and system
architecture ........................................................................................ 17
Avoidance of systematic failures .............................................................................. 18
6.1
6.2
6.3
6.4

General......................................................................................................... 18
Independent safety assessment....................................................................... 18
Prevention of systematic failure in the early phases of the life-cycle .................... 19
Detection and correction of systematic failure during the design and
development phases of the life-cycle................................................................ 19
6.5 Detection and correction of systematic failure during integration and following
phases of the life-cycle ................................................................................... 20
Guidance on system definition ................................................................................. 22

7.1
7.2
7.3
7.4
Risk

System definition in an iterative system approach.............................................. 22

Method for defining the structure of a system .................................................... 22
Parties/stakeholders/boundaries of systems...................................................... 23
Guidance on the content of a system definition ................................................. 23
analysis and evaluation.................................................................................... 25

8.1
8.2

General......................................................................................................... 25
Hazard identification - process and methods ..................................................... 25
8.2.1 General .............................................................................................. 25
8.2.2 Empirical hazard identification methods................................................. 25
8.2.3 Creative hazard identification methods .................................................. 26
Hazard classification ...................................................................................... 26
Consequence analysis .................................................................................... 26
8.4.1 General .............................................................................................. 26
8.4.2 The risk model .................................................................................... 27
8.4.3 Techniques for the consequence analysis .............................................. 28
Risk evaluation and acceptance....................................................................... 29
8.5.1 Introduction to the risk acceptance principles ......................................... 29
8.5.2 Use of code of practice ........................................................................ 30
8.5.2.1 Preconditions ........................................................................ 30
8.5.2.2 Applicability to the system under consideration ......................... 30
8.5.3 Use of a similar system as reference..................................................... 30
8.5.3.1 Preconditions ........................................................................ 30

8.3
8.4

8.5

-3-

prEN 50126-2

4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071

4072
4073
4074
4075
4076

9.1 General......................................................................................................... 36
9.2 Functional safety requirements ........................................................................ 37
9.3 Technical safety requirements ......................................................................... 37
9.4 Operational and maintenance safety requirements............................................. 37
10 Apportionment of System Safety Requirements ......................................................... 39

4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094

10.1 Deriving and apportioning system safety requirements....................................... 39

10.1.1 How to proceed with functions implemented by E/E/PE architectures........ 39
10.1.2 How to proceed with functions implemented by non-E/E/PE architecture ... 39
10.2 Functional safety integrity for E/E/PE ............................................................... 39
10.2.1 Deriving functional safety requirements for E/E/PE systems from
defined hazards .................................................................................. 39
10.2.2 The safety integrity concept and its levels.............................................. 40
10.2.3 Random aspects of functional safety integrity......................................... 40
10.2.4 Systematic aspect of functional safety integrity ...................................... 41
10.2.5 Combination of random and systematic aspects ..................................... 41
10.2.6 The SIL table ...................................................................................... 43
10.2.7 SIL allocation...................................................................................... 43
10.2.8 Apportionment of TFFR........................................................................ 45
10.2.9 Demonstration of quantified targets....................................................... 45
10.2.10 SIL0................................................................................................... 45
10.2.11 Prevention of misuse of SILs and warnings ............................................ 46
10.3 Safety Integrity for non-E/E/PE systems Guidance on application of CoP .......... 46
11 Design and implementation...................................................................................... 47

4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105

8.5.3.2 Applicability to the system under consideration ......................... 31

8.5.4 Explicit risk estimation ......................................................................... 31
8.5.4.1 Preconditions ........................................................................ 31
8.5.4.2 Applicability to the system under consideration ......................... 32
8.6 Guidelines to the explicit risk estimation ........................................................... 32
8.6.1 Rationale............................................................................................ 32
8.6.2 Quantitative approach.......................................................................... 32
8.6.2.1 General ................................................................................ 32
8.6.2.2 Determining safety objectives appropriate to a project ............... 32
8.6.2.3 Deriving tolerable accident safety targets and THR ................... 33
8.6.2.4 Responsibilities ..................................................................... 34
8.6.2.5 On the accuracy of data ......................................................... 35
8.7 Qualitative approach ...................................................................................... 35
Specification of system requirements........................................................................ 36

11.1
11.2
11.3
11.4

Causal analysis ............................................................................................. 47

Identification and treatment of additional hazards arising from design.................. 47
Techniques for causal analysis ........................................................................ 48
Functional Safety principles ............................................................................ 48
11.4.1 Functional composition ........................................................................ 48
11.4.2 Independence of functions ................................................................... 49
11.4.3 Supporting rules for evaluating technical aspects of independence........... 49
Annex A (informative) Measures for the avoidance of systematic failures ........................... 51
A.1
A.2
A.3

General remark.............................................................................................. 51
Safety and quality management ....................................................................... 51
System requirements specification ................................................................... 51

prEN 50126-2

-4-

4106
4107
4108
4109

A.4
A.5
A.6
Annex B

System architecture and design ....................................................................... 51

Integration and testing of the system................................................................ 52
Application, operation and maintenance ........................................................... 52
(informative) ALARP, GAME, MEM.................................................................... 53

4110

Annex C (informative) Using failure and accident statistics to derive a THR. ....................... 60

4111
4112

Annex D (informative) CoP on maintenance activities to preserve the safety integrity of

non-E/E/PE systems ............................................................................................... 61

4113

Annex E (informative) Apportionment methods ................................................................ 63

4114

Annex F (informative) Safety Target Quantification Methods ............................................. 67

4115

Annex G (informative) Common mistakes in quantification ................................................ 72

4116

Annex H (informative) Techniques / methods for safety analysis........................................ 73

4117
4118
4119

List of figures
Figure 1 The Hourglass Model .................................................................................... 11

4120

Figure 2 Definition of hazards with respect to the system boundary................................. 13

4121

Figure 3 Generic and specific safety acceptance processes ........................................... 15

4122

Figure 4 Examples of dependencies between Safety Cases ........................................... 16

4123

Figure 5 Organisational structure for early phases ......................................................... 19

4124

Figure 6 Organisational structure for integration and final phases ................................... 21

4125

Figure 7 An example of risk model............................................................................... 27

4126

Figure 8 Tolerable rates in an example of risk model ..................................................... 33

4127

Figure 9 Safety requirements ...................................................................................... 37

4128

Figure 10 Apportionment of functional safety requirements ............................................ 40

4129

Figure 11 Relationship between SILs and techniques .................................................... 42

4130

Figure 12 Impact of functional dependence in a fault-tree analysis.................................. 49

4131
4132

Figure B.1 - Example of simple qualitative risk matrix for use within an ALARP
framework.................................................................................................................... 55

4133

Figure B.2 - Example of semi-quantitative risk matrix for use within an ALARP framework. .. 55

4134

Figure B.3- Differential risk aversion............................................................................... 58

4135

Figure E.1 Functional breakdown ................................................................................ 63

4136

Figure E.2 analysis of the scenario: functional independence .......................................... 64

4137

Figure E.3 1st step of apportionment: analysis of the system .......................................... 65

4138

Figure E.4 example of quantified apportionment............................................................ 66

4139

Figure F.1 - Interpretation of failure and repair times ........................................................ 67

4140

Figure F.2 - Double channel failure with common cause ................................................... 69

4141
4142
4143

List of tables
Table 1 Typical examples for a functional breakdown .................................................... 23

4144

Table 2 Examples of hazards ...................................................................................... 28

4145

Table 3 SIL and SIL-measures .................................................................................... 43

4146

Table A.1 Safety planning and quality assurance activities ............................................... 51

4147

Table A.2 System requirements specification .................................................................. 51

4148

Table A.3 System Architecture and Design...................................................................... 51

4149

Table A.4 Integration and testing of the system ............................................................... 52

-5-

prEN 50126-2

4150

Table A.5 Application, Operation and Maintenance .......................................................... 52

4151

Table D.1 Measures to achieve the necessary safety integrity of non-E/E/PE systems ...... 62

4152

prEN 50126-2

4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163

-6-

Foreword
This European Standard was prepared by the Technical Committee CENELEC TC 9X, electrical
and electronic applications in railways.
The text of the draft was submitted to the formal vote and was approved by CENELEC as
EN 50126 on 20xx-xx-xx.
The following dates were fixed:
a) latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement
(dop)
20xx-xx-xx
b) latest date by which the national standards conflicting
with the EN have to be withdrawn
(dow)

20xx-xx-xx

4164

This document supersedes EN50126-1:1999, EN50128:2011 and EN50129:2003.

4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175

The EN50126 standard includes under the general title "Railway application - The specification
and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)" the following
parts:
EN 50126-1: Generic RAMS process
EN 50126-2: Systems Approach to Safety
EN 50126-4: Functional Safety Electrical/Electronic/Programmable Electronic systems
EN 50126-5: Functional Safety Software
This EN 50126-2 covers the systems approach to safety. It is mainly based on EN50126-1:1999
which is withdrawn.
This European Standard has been prepared under a mandate given to CENELEC by the
European Commission and supports the Directive 2008/57/EC (see Annex ZZ).

4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198

Introduction
The standard EN 50126-1:1999 was produced to introduce the application of a systematic
RAMS management process in the railway sector. For safety-related electronic systems for
signalling the standards EN 50128 and EN 50129 were produced. Through the application of
these standards and the experiences gained over the last years, the need for revision and
restructuring became apparent with a need to deliver a systematic and coherent approach to
RAMS applicable to all the railway application fields Signalling, Rolling Stock and Electric power
supply for Railways (Fixed Installations).
The revision work improved the coherency and consistency of the standards, the concept of
safety management and the practical usage of the standard EN 50126 and took into
consideration the existing and related Technical Reports as well.
This European Standard provides railway duty holders and the railway suppliers, throughout the
European Union, with a process which will enable the implementation of a consistent approach
to the management of reliability, availability, maintainability and safety, denoted by the acronym
RAMS.
Processes for the specification and demonstration of RAMS requirements are cornerstones of
this standard. This European Standard promotes a common understanding and approach to the
management of RAMS.
EN 50126 is the railways sector specific application of IEC 61508. Meeting the requirements in
this European Standard is sufficient to ensure that additional compliance to IEC 61508 does not
need to be evaluated.
With regard to safety EN 50126-1 provides a Safety Management Process which is supported by
guidance and methods described in EN 50126-2.

-74199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231

prEN 50126-2

EN 50126-1 and EN 50126-2 are independent from the technology used. EN 50126-4 and
EN 50126-5 provide guidance specific to safety-related E/E/PE technology of railway
applications. Their application is determined through the application of the general RAMS
process of EN 50126-1 and through the outcome of the safety-related methods described in
EN 50126-2. As far as safety is concerned, the EN 50126 standard takes the perspective of
functional safety. This does not exclude other aspects of safety. However, these are not the
focus.
The aims set for revision of the EN 50126 standard required a better understanding of the
systems approach and improved methods for applying the safety management process
described in EN 50126-1. EN 50126-2 provides this guidance.
The application of this standard should be adapted to the specific requirements of the system
under consideration.
This European Standard can be applied systematically by the railway duty holders and railway
suppliers, throughout all phases of the life-cycle of a railway application, to develop railway
specific RAMS requirements and to achieve compliance with these requirements. The systemslevel approach developed by this European Standard facilitates assessment of the RAMS
interactions between elements of railway applications even if they are of complex nature.
This European Standard promotes co-operation between the stakeholders of Railways in the
achievement of an optimal combination of RAMS and cost for railway applications. Adoption of
this European Standard will support the principles of the European Single Market and facilitate
European railway inter-operability.
The process defined by this European Standard assumes that railway duty holders and railway
suppliers have business-level policies addressing Quality, Performance and Safety. The
approach defined in this standard is consistent with the application of quality management
requirements contained within the ISO 9001.
In accordance with CENELEC1) , mandatory requirements in this standard are indicated with the
modal verb shall. Where justifiable, the standard permits process tailoring. Specific guidance
on the application of this standard in the case of process tailoring is provided in clause 7.3 of
EN 50126-1. EN 50126-2 provides various methods for use in the safety management process.
Where a particular method is selected for the system under consideration, the mandatory
requirements of this method are by consequence mandatory for the safety management of the
system under consideration.

1) CENELEC Internal Regulations Part 3: Rules for the structure and drafting of CEN/CENELEC Publications (200908), Annex H

prEN 50126-2

4232
4233
4234
4235

-8-

1 Scope
This part 2 of EN 50126
considers the safety-related generic aspects of the RAMS life-cycle. The guidance in this
part is still applicable in the application of specific standards;

4236
4237
4238

defines methods and tools which are independent of the actual technology of the
systems and subsystems, whilst following EN 50126-4 and EN 50126-5 are related to
E/E/PE internal systems/subsystems;

4239

provides:

4240
4241
4242
4243
4244

the user of the standard with the understanding of the system approach to safety
which is a key concept of EN 50126;
methods to derive the safety requirements and their safety integrity requirements for
the system and to apportion it to the subsystems, be it for hardware or software;
provides guidance and methods for the following areas:

4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255

system life-cycles as applicable to generic and specific applications, and to the

generic products;
systems safety assurance;
risk assessment process;
risk management process;
application of risk acceptance principles and criteria;
safety integrity concept.
provides the user with the methods to assure safety with respect to the system under
consideration and its interactions. Examples are guidance on safety integrity by the
apportionment amongst the various parts of a system or a method to derive the safetyrelated role of software as a precondition to apply EN 50126-5;

4256
4257
4258

enables the user to define the system under consideration, to identify the interfaces and
the interactions of this system with its subsystems or other systems and to conduct the
risk analysis;

4259

addresses railway specifics;

4260

does not define:

4261
4262
4263
4264
4265

RAMS targets, quantities, requirements or solutions for specific railway applications;

rules or processes pertaining to the certification of railway products against the
requirements of this standard;
an approval process by the safety authority.
does not specify requirements for ensuring system security.

4266

This part 2 of EN 50126 is applicable

4267
4268

to all systems under consideration - as regards safety - within the entire railway system
and the stakeholders involved;

4269
4270
4271
4272

to the specification and demonstration of safety for all railway applications and at all
levels of such an application, as appropriate, from complete railway systems to major
systems and to individual and combined sub-systems and components within these
major systems, including those containing software; in particular:

4273
4274
4275
4276
4277
4278
4279
4280
4281

to new systems;
to new systems integrated into existing systems in operation prior to the creation of
this standard, although it is not generally applicable to other aspects of the existing
system;
for modifications of existing systems in operation prior to the creation of this standard,
although it is not generally applicable to other aspects of the existing system;
at all relevant phases of the life-cycle of an application;
for use by railway duty holders and the railway suppliers.

-9-

prEN 50126-2

4282
4283
4284
4285
4286
4287
4288

It is not required to apply this standard to existing systems including those systems already
compliant with any version of former EN 50126, EN 50128 or EN 50129, which remain
unmodified. Railway applications mean Command, Control & Signalling, Rolling Stock and
Electric Power Supply for Railways (Fixed Installations).
In this standard the term hardware refers to E/E/PE components or systems. If non-E/E/PE
hardware is meant, this is specifically mentioned.

4289
4290

2 Normative references

4291
4292

3 Terms and definitions

4293

4 Abbreviations

4294

Normative references are given in EN 50126-1.

For the purposes of this document, the terms and definitions given in EN 50126-1 apply.

ALARP

As Low As Reas onable Practicable

CBA

Cost Benefit Analysis

CCF

Common Caus e Failure (Analysis)

CoP

Code of Practice

DCCA

Deductive Caus e-Consequenc e Analysis

DRA

Differential Risk A version

E/E/PE

Electrical/electronic/programmable electronic systems

ERE

Explicit Risk Estimation

EMC

Electromagnetic capability

ETA

Event Tree Analysis

FCA

Failure Consequence Analysis

FMECA

Failure Mode Effect & Criticality Analysis

FTA

Fault Tree Analysis

GA, GASC

Generic Application, Generic Application Safety Cas e

GP, GPSC

Generic Product, Generic Product Saf ety Case

GAME

Globalement Au Moins Equivalent

HAZOP

Hazard and Operability study

ISA

Independent Safety Assessment

MEM

Minimum Endogenous Mortality

RAC

Risk Acceptance Criterion

RAMS

Reliability, A vailability, Maintainability, S afety

RBD

Reliability Block Diagram

RRA

Rapid Ranking Analysis

SA, SASC

Specific Application, Specific Application Saf ety Case

SDR

Safe Down Rate

SDT

Safe Down Time

SIL

Safety Integrity Level

SRAC

Safety-r elated Applic ation Conditions

TFFR

Tolerable Functional Failure Rate

THR

Tolerable Hazard Rate

VPF

Value of Preventing a Fatality

prEN 50126-2

- 10 -

4295

5 Tailoring the life-cycle

4296

5.1 The life-cycle Model

4297
4298

The model described in EN 50126-1 covers general RAMS aspect of the whole life-cycle.
From the perspective of safety methods, with the aim of

4299
4300

achieving a clear definition of responsibilities and interfaces between the operator and
the supplier, and

4301

facilitating reuse of existing systems and their related acceptance,

4302
4303
4304

the following sub-clauses are introducing the concept of hourglass model (see 5.2) and the
distinction between generic product, generic application and specific application processes (see
5.3).

4305

5.2 The Hourglass Model

4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323

In this sub-clause, the so-called Hourglass Model is introduced: it offers a simplified approach
that although not containing all aspects implied in the life-cycle model helps to clarify some
issues.
The Hourglass Model provides an overview of the major safety-related activities that are needed
to ensure an acceptable safety level for a technical system, including the corresponding
responsibility areas.
Technical system means a product or an assembly of products including the design,
implementation and support documentation. The development of a technical system starts with
its requirements specification and ends with its acceptance. The design of relevant interfaces
with human behaviour is considered, while human operators and their actions are not included
in a technical system. Both the maintenance process (described in the maintenance manuals)
and the operation are specified but are not considered parts of the technical system itself. They
can be restricted in application conditions.
The purpose of this model is to highlight the separation between risk analysis (at the railway
system level) from hazard analysis (at the level of the system under consideration).
This enhances co-operation between the relevant stakeholders, clarifying responsibilities and
interfaces and has the advantages of reducing complexity and facilitating modularization.
The Hourglass Model describes two main aspects:

4324
4325

risk assessment, i.e. deriving high-level safety requirements for operational and
technical issues (including maintenance), and

4326
4327
4328

hazard control, i.e. design and implementation of the safety-related system under
consideration by determining and analysing causes internal to the system and
implementing control measures on the basis of the given safety requirements.

- 11 -

prEN 50126-2

Risk Assessment

Railway Duty Holders

responsibility

System Definition
Risk Analysis, including:
Hazard Identification
Consequence Analysis
Selection of RAP
Risk Evaluation

Legal framework

B
System Requirement Specification
Identified Hazards
Safety Requirements:
Objectives from ERE
selected Codes of Practice
Reference systems specifications

Additional
hazards
Application
Conditions

Note: during each

project
responsibilities have
to be clarified
unambiguously
in order to avoid
gaps or overlaps

C
Hazard Analysis
Causal Analysis
Hazard Identification
(refinement)
Common Cause Analysis
Demonstration of Compliance
Hazard Control

Suppliers
responsibility

4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353

Figure 1 The Hourglass Model

A Risk assessment
Risk assessment is performed at the railway system level.
It covers system definition, risk analysis, risk evaluation.
It defines the high level system safety requirements, in particular safety requirements for the
system under consideration from the perspective of operator. It takes into account safety-related
operational aspects, previous experience and the regulatory requirements of the railway
application.
The main task for this activity is the risk analysis, which is derived from the system definition.
The risk analysis includes hazard identification, consequence analysis, and selection of risk
acceptance principles (RAP in the picture) and associated criteria.
The specification of safety requirements is the final result of risk assessment; in Figure 1 it is
allocated in box B, because it has an interface function (together with system requirement
specifications and the list of identified hazards) between different responsibilities.
Gaining and sharing system knowledge
All the knowledge gained during the process and the documented analyses, resulting from the
risk assessment, should be considered as relevant information together with the specification of
safety requirements.
This knowledge should be shared and distributed among the stakeholders involved in the
system process. It will provide significant potential benefits in terms of improved awareness of
hazards and risk of accidents in the given operational and maintenance context, and will also
help to understand the scope and limits of the risk reduction measures.

prEN 50126-2

- 12 -

4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377

Conducting risk assessment

The level of detail in a risk assessment should be adequate to the risk. The purpose is not to
catalogue every trivial hazard, nor is it expected that hazards beyond the limits of current
knowledge will always be identified. A suitable and sufficient risk assessment should reflect a
reasonable analysis of hazards and their associated risks within the railway operation and within
the applied technology itself. Where reasonably practicable, risk assessments should be
correlated with historical records of accidents and the records of causes.
When possible, consideration of technical implementation/architecture should be avoided in this
first stage i.e. the system to be developed should be considered as a black box, of which
functions and hazards are evaluated only at the boundaries. These boundaries are well defined
interfaces between the operational environment and the system under consideration.
As an example, an unintentional train motion is a hazard for a train. It can be observed as an
abstraction at the boundary of the system train and it could lead to different accidents
depending on the operational context (e.g. collision in context with over-speeding while running
or fall of persons in connection with a train moving in a station while expected to stand still,
etc.).
Assumptions defined during the risk assessment have to be checked and updated throughout
the life-cycle phases.
B Outcomes of the risk assessment
The results of the first stage of the risk assessment are a set of safety requirements attached to
clearly-identified functions, systems or operating rules. They are part of the System
Requirement Specification that establishes the technical interface between the stakeholders.

4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390

On the basis of the selected risk acceptance principles, safety requirements can refer to Codes
of Practise, to similar systems, or give explicit targets derived from an explicit risk estimation
(ERE in the picture).
Safety requirements include required efficiency of safety functions , that could be assessed
quantitatively (e.g. maximum rates of hazards), semi-quantitatively or qualitatively (e.g. use of
trained drivers for controlling human factor errors).
Safety requirements should be assessed with a holistic approach, i.e. the residual risk should be
evaluated as acceptable taking into consideration the identified hazards.
C Hazard control
The hazard control stage in the hourglass model is dedicated to ensuring that the system under
consideration is compliant with the safety requirements: hence hazard control is performed for a
specific system architecture.

4391
4392
4393
4394
4395
4396

The major impacts of human factors, operational and general maintenance rules as well as
procedures are part of the preceding risk analysis and should have already been taken into
account in the safety requirements. Therefore, during hazard control, the designer of the system
under consideration can focus on the internal causes of the identified hazards, that can be
considered as hazards at the system level.
The main task for this activity is the hazard analysis comprising:

4397
4398
4399
4400
4401
4402
4403
4404

causal analysis;
a dedicated hazard identification focusing on the system under consideration, and;
a Common Cause Analysis.
Hazard identification is a recurring task that can appear on several iteration levels for subsets of
the system under consideration. In order to distinguish these different tasks (and related
documents) the hazard identification has been quoted twice in Figure 1:
1. during risk assessment, it focuses on high level hazards derived from the system
functions (black box) and related operation of the system as well as its environment;

4405
4406
4407
4408

2. within the hazard control, a refined/iterated hazard identification focuses on hazards and
their causes derived from the technical solutions, i.e. from defined architecture and
internal interfaces of the system under consideration, and potential new hazards
introduced by the system itself.

NOTE The project organis ational structure and responsibilities are another factor to c onsider in understanding and
controlling risk. For organis ational aspects and requirements see EN 50126-1, 5.3 and EN 50126-1, 7.1.1.3

NOTE Hazard control as here defined has a narr ow meaning and is limited to the design and implementation phas e.

- 13 4409
4410
4411
4412
4413
4414

prEN 50126-2

Figure 2 shows that the cause of a hazard at the railway system level may be considered as a
hazard on level of the system under consideration, with respect to its boundary. The boundary
for a hazard identification is always given in the system definition that limits the scope of the
task. This implies that the hazards are structured hierarchically hence a hierarchical approach to
hazard analysis and hazard logging should be used.

Cause (railway system level)

=> Hazard (level of system
under consideration)

External occurrence
barriers

Hazard
(railway
system level)
Accident k

Accident l

Cause
(subsystem
level)

Causes

4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427

Boundary of the
system under
consideration

Consequences

Figure 2 Definition of hazards with respect to the system boundary

The picture is hazard-oriented and shows a bow-tie shape, suggesting that several causes
may lead to the same hazard and one hazard may lead to several different accidents.
The demonstration of compliance with the safety requirements of the system under
consideration can be performed in various forms. These forms depend on the nature of the
underlying requirements set at the beginning of the hazard control.
D Revision of risk assessment
During the hazard control stage, fulfilment of safety targets may not be reached at the first
iteration:

4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444

additional hazards may be identified at the level of the system under consideration;
a need of new operational rules may arise;
additional external safety measures may be required to fulfil the safety objectives.
In all these cases, a revision of the risk assessment is necessary.
This revision should also take account of the application conditions that could rise at the level of
the system under consideration.

4445

5.3 Generic and specific safety acceptance processes

4446

5.3.1 Introduction

4447

In terms of safety processes, the development of a system can be considered of three types:

Responsibilities
Risk assessment is mainly within the responsibility of the railway duty holders and operators.
The roles and responsibilities may however be contracted to other parties in relation to their
accountabilities, provided that they have a documented and suitable range of competencies to
consider the whole operational context in detail. They need to take into account safety-related
operational aspects, previous experience and regulatory requirements. In any case the railway
duty holders should approve the results of the risk assessment.
The hazard control, for hazards associated purely with the technical system, is the responsibility
of the supplier of the technical system.
Railway duty holder and supplier need to comply with the prevailing legal requirements.

prEN 50126-2

- 14 -

4448
4449

Generic product: The system is considered from a generic point of view, applicable to
different classes of applications;

4450
4451

Analyses are carried out within an operational context which is application-independent.

The safety process is typically completed within Phase 6 (Design & Implementation).

4452
4453

Generic application: The system is considered suitable for multiple applications of the
same class;

4454
4455
4456

Analyses are carried out within an operational context which is application-dependent.

The safety process is typically completed within Phase 6 (Design & Implementation) and
includes the definition of the application design process.

4457
4458

Specific application: The system is considered for a specific application (including its
physical implementation);

4459
4460
4461
4462
4463
4464
4465

This sub-clause defines the safety acceptance and approval process for safety-related
system/sub-system/equipment. Except where considered appropriate, it does not specify who
should carry out the work at each stage, since this may vary in different circumstances.
Three conditions shall be satisfied before a safety-related system/sub-system/component can be
accepted as adequately safe for its intended application:
evidence of quality management;

4466

evidence of safety management;

4467

evidence of functional and technical safety.

4468
4469
4470
4471

These three conditions have been explained in EN 50126-1, 10.2.

The evidence of quality management, safety management and functional/technical safety are
included in the safety case. Three different categories of safety cases are defined in
EN 50126-1, 10.2.6.

4472

5.3.2 Safety acceptance process

4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484

Before system acceptance can be considered, an Independent Safety Assessment (ISA) of the
system/sub-system/equipment and its safety case may be carried out, to provide assurance that
the necessary level of safety has been achieved. Its results should be presented in a ISA
Report. The report should explain the activities carried out by the ISA to determine how the
system/sub-system/equipment, (hardware and software) has been designed to meet its specified
requirements, and possibly specify some additional conditions for the operation of the
system/sub-system/equipment. The depth of the safety assessment, and the degree of
independence with which it is carried out, are indicated in the Safety Plan as indicated in
EN 50126-1, 8.3.2.6. Specific tests may be required by the independent safety assessor in order
to increase confidence.
The overall documentary evidence should consist of
the system (or sub-system/component) requirements specification;

4485

the safety requirements specification;

4486

the safety case, including

4487
4488
4489
4490
4491
4492
4493

Part 1:
Definition of system/sub-system/component;
Part 2:
Quality Management report (evidence of quality management);
Part 3:
Safety Management Report (evidence of safety management);
Part 4:
Technical Safety Report (evidence of functional/technical safety);
Part 5:
Related Safety Cases (if applicable);
Part 6:
Conclusion.
the Independent Safety Assessment (ISA) Report, if appropriate.

4494
4495
4496
4497
4498

Provided all the conditions for safety acceptance have been satisfied, as demonstrated by the
Safety Case, and subject to the results of the independent safety assessment where necessary,
the system/sub-system/component may be granted safety approval by the relevant safety
authority within the legal framework. Approval may be subject to the fulfilment of additional
conditions imposed by the legal framework.

- 15 4499
4500
4501
4502

prEN 50126-2

For a generic product (i.e. independent of application), and for a generic application (i.e. class
of application), it should be possible for safety acceptance to be based on independent safety
assessment (i.e.: cross-acceptance). This is not considered possible for specific applications.
The safety acceptance process, for all three categories of Safety Case, is illustrated in Figure 3.

Specific Application Safety Process

Generic Product Safety Process

Generic Application Safety Process

(when not using Generic Application)

1

Concept

2 System Definition and

Operational Context
Risk Analysis
and Evaluation

Concept

2 System Definition and

Operational Context
3

Concept

2 System Definition and

Operational Context

Risk Analysis
and Evaluation

Risk Analysis
and Evaluation

Specification of
System Requirements

Specification of
System Requirements

Specification of
System Requirements

Apportionment of
System Requirements

Apportionment of
System Requirements

Apportionment of
System Requirements

Design and
Implementation

Design and
Implementation

Design and
6 / a Implementation

Prepare GPSC &

ISA Report

Prepare GASC &

ISA Report

Manufacture

Incorporation into
System

Specific Application Safety Process

6 /b

System Validation
9

Prepare SASC &

ISA Report

Execution of plans defined in

Phase 6 / a (Application Design,
Manufacturing, Installation, )

Design and
Implementation

Manufacture

Incorporation into
System
System Validation

10 System Acceptance (Specific Application)

10 System Acceptance (Specific Application)

(incl. cross-acceptance of related GPSCs)

(incl. cross-acceptance of related GASC and GPSCs)

Maintain/support system & and

external risk reduction measures

Operation,
11 Maintenance and
Performance
Monitoring

Establish Safety Plan /

Update Application Safety Case

12 Decommissioning

4503
4504
4505

Prepare SASC &

ISA Report

Figure 3 Generic and specific safety acceptance processes

Modification

Re-apply
lifecycle /
Update
Application
Safety Case

prEN 50126-2

- 16 -

4506

5.3.3 After safety acceptance

4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520

After a system/sub-system/component has received safety acceptance, any subsequent

modification is controlled using the same quality management, safety management and
functional/technical safety criteria as would be used for a new design. All relevant
documentation, including the Safety Case, should be updated or supplemented by additional
documentation, and the modified design should be subject to the approval processes in the duty
holders safety management system, and those required by the particular legal framework.
Once an installed system/sub-system/component has been validated, appropriate procedures,
support systems and safety monitoring, as defined in the Safety Plan, are used to ensure
continued safe operation throughout its working life, including operation, maintenance,
alteration, extension and eventual decommissioning. These activities are controlled using the
same quality management, safety management and technical safety criteria as for the original
design. The on-going safety of the system must be managed by the duty holder and this should
require the relevant documentation to be kept up-to-date, including the Safety Case, and any
alterations or extensions submitted for approval.

4521

5.3.4 Dependency between safety cases

4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535

The Safety Case for a system may depend on the Safety Cases of other sub-systems or
components. In such circumstances, safety acceptance of the main system is not possible
without previous safety acceptance of the related sub-systems/components.
If ISA Report has been obtained for a generic product, or for a generic application, a reference
may be made to this in the application for Safety acceptance of a specific application; it is not
necessary to repeat the generic ISA process for each application. This dependency between
Safety Cases is illustrated in Figure 4.
A safety case may be based on demonstration that the proposed specific application is
technically equivalent to an existing application with specific safety approval. A new safety
approval for this specific application is necessary.
It is essential to ensure that the safety-related application conditions stated in the Technical
Safety Report of each Safety Case are fulfilled in the higher-level Safety Case, or else are
carried forward into the Safety-Related Application Conditions (SRACs) of the higher-level
Safety Case.

System K

System J

Speci fic Applic ati o n Sa fety Case

Component B

SystemLJ
Sub-system

Component C
Component W X

Speci fic Applic ati o n Sa fety Case

Ge neric Pro duct Safe ty Cas e

Legend:
Part of higherlevel Safety
Case
Related Generic
Safety Case (&
coverage of its

Component W
W
Component

Component XX
Component

Component
Component ZB

Ge neric Appli cat io n Safe ty Cas e

Ge neric Pro duct Safe ty Cas e

Generic Product Safety

Ge neric Pro duct Safe ty Cas e

Generic Product Safety

Generic Safety Case

(Pro duct / Appli ca tio n up to Phas e
6)

Specific Application
Safety Case
System / Sub-system /
Component

4536
4537
4538

Component
Component YB

(of i nte rest )

Figure 4 Examples of dependencies between Safety Cases

Specific Application S afety Case

- 17 -

prEN 50126-2

4539

5.3.5 Relationship between safety case dependencies and system architecture

4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551

Number, scope and hierarchy of the various safety cases (GPSC, GASC, SASC) does not
necessarily reflect the architectural view of the system under development.
That is, generic product (GP), generic application (GA) and specific application (SA) should
not be confused with system, sub-system and component.
Although a GP is often a component in a GA or SA, those terms could even refer to the same
item, just with different perspectives.
Considering for example a component implementing a safety-related communication over a
transmission system, to exchange the status of a field equipment:
a) It can be considered as a GP, and validated / approved against EN50159, if to the scope
is the mitigation of generic threats to messages (deletion, corruption, re-sequencing,
etc.), regardless of their content. A number of safety-related parameters will be defined
as configurable (e.g., transmission cycle, length of time-outs, number of replies, );

4552
4553
4554

b) It can be considered as a GA, and validated / approved against a set of applications

requirements. Type of field equipment, its dynamics and how the status information is
used will define all the safety-related parameters configurable at the GP level;

4555
4556

c) It can be considered as a SA for a specific site, and validated for its specific use, within
the parameters ranges defined as application conditions in the GA.

4557
4558
4559
4560

These steps may be grouped according to the needs of re-use, e.g. step a) may be useful if the
system is forecast to be used for complete different applications, otherwise the related safety
analyses could be integrated in b). Similarly, step b) is advisable if the system will be replicated
on different sites.

prEN 50126-2

- 18 -

4561

6 Avoidance of systematic failures

4562

6.1 General

4563
4564
4565
4566
4567
4568
4569
4570
4571

Avoidance, detection and elimination of systematic failures at system level shall be considered
over the entire life-cycle. Appendix A summarises the measures to be taken in the different
phases of the life-cycle, with a reference to the clauses in the standard where the measures are
explained in more detail.
In general, verification and validation shall be performed by qualified persons who have no other
role in the project (e.g. they cannot specify requirements, or design the system themselves).
When present, the ISA shall always be independent from the project manager and different
person from other roles.

4572

6.2 Independent safety assessment

4573
4574
4575
4576
4577
4578
4579
4580
4581

The objective of the Independent Safety Assessment (ISA) is to arrive at a judgement through
evaluation that the life-cycle processes and their outputs are such that the system is suitable for
its intended use and fits for its intended application, supporting acceptance.
With regard to RAMS, ISA is not requested in all the application fields: it is mandatory for
signalling and only recommended for Rolling Stock and fixed installations.
However, when applied, ISA shall follow the subsequent requirements.
The ISA shall be independent from the project manager and different person from other roles.
Aspects with which the ISA deals shall be described in a Safety Assessment Plan. This plan
shall comprise also:

4582
4583

activities throughout the independent assessment process and their link to engineering
activities;

4584

documents to be taken into consideration;

4585

statements on pass/fail criteria and the way how to deal with non-conformance cases;

4586

requirements with regard to content and form of the Safety Assessment Report.

4587
4588
4589
4590
4591
4592

The independent safety assessor shall have access to the development process and all project
related documentation.
The independent safety assessor,
shall agree the scope and contents of the quality assurance plan, the safety plan and the
validation plan. This agreement shall also make a statement concerning the presence of
the independent safety assessor during testing.

4593
4594
4595

may carry out audits and inspections (e.g. witnessing tests) throughout the entire
development process. The independent safety assessor may ask for additional
verification and validation work.

4596
4597

shall assess the quality management system and the evidences on its use and
application.

4598
4599

shall assess if an appropriate development process and an appropriate set of

techniques, which are suitable for the intended development, has been selected.

4600
4601

shall review the evidence of the competency of the project staff and shall assess the
organisation for the system development.

4602

shall assess the adequacy and completeness of the safety cases.

4603

shall assess that the safety analyses are complete and correct.

4604

shall assess safety-related application conditions.

4605
4606
4607

shall check for noted deviations, non-compliances to the requirements and recorded
non-conformities if these have an impact on safety, and make a judgment whether the
justification from the project is acceptable.

4608

shall record his/her activities and evaluations in a safety assessment report.

- 19 -

prEN 50126-2

4609

6.3 Prevention of systematic failure in the early phases of the life-cycle

4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624

In the early phases of the life-cycle (from the concept to the system requirement specification),
the emphasis is on the prevention of the systematic failures. This can be met by detecting such
failures using control measures and subsequent correction. One of the main instruments is the
verification of the results at the end of each life-cycle phase. The verification shall be performed
by a qualified person who has not been involved with other roles in the elaboration of the results
of that life-cycle phase.
The system requirements, including the safety requirements shall be validated by a qualified
person who has not been involved in the development of the requirements. The validator shall
judge whether the requirements are adequately analysed and specified in order to allow the
system under consideration to serve the intended purpose.
The validator needs sufficient autonomy and responsibility to reach an independent judgement
of the completeness and adequacy of the safety requirements. Therefore the validator shall be
independent from the project manager.

PM

ISA

RQM

VER

VAL

Key
can be the s ame person

can be the s ame organis ation

Shall report to the Project Manager
can report to the Project Manager
No line

Shall not report to the Project Manager

PM = Project Manager

ISA

RQM = Requirements
Manager

VER

= Verifier

VAL

= Validator

Independent Safety Assessor

4625
4626
4627

Figure 5 Organisational structure for early phases

4628
4629

6.4 Detection and correction of systematic failure during the design and development
phases of the life-cycle

4630
4631
4632
4633

During the design and development phase, if the results of the risk analysis have shown that the
likely consequences of hazards are confined to minor injuries, requirements on independence
can be loosened (see Figure 6, case (B)):
The validator and the verifier can be the same person;

4634
4635
4636
4637
4638

They can both be under the direct dependence of the project manager.
In particular,
for design and development of E/E/PE systems, independence requirements as defined
in EN 50126-4 and EN 50126-5 apply;
for non-E/E/PE systems, Organisational requirements given in Figure 6 apply.

prEN 50126-2

- 20 -

4639
4640
4641

Note that the PM of the design and development may be different from the PM of the first
phases (e.g. when the project has been transferred from the RDH to the supplier or from the
supplier to a sub-supplier).

4642
4643

6.5 Detection and correction of systematic failure during integration and following
phases of the life-cycle

4644
4645
4646

The main focus in the later phases of the life-cycle is to integrate and test the system.
Integration, testing, verification and validation shall be performed by qualified persons who have
neither been involved in the requirement analysis within the same project;

4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660

nor in the architecture, design and implementation of this project.

The validator shall judge whether the system under consideration meets the specified
requirements and thus serves the intended purpose.
The validator needs sufficient autonomy and responsibility to reach an independent judgement
of the acceptability of a product or application from the point of view of safety.
Therefore the validator shall be independent from the project manager, unless the results of risk
analysis show the likely consequences of hazards to be confined to minor injuries.
If the results of the risk analysis have shown that the likely consequences of hazards are
confined to minor injuries, requirements on independence can be loosened (see Figure 6, case
(B)):
The validator and the verifier can be the same person;
They can both be under the direct dependence of the project manager.
When present, the ISA shall always be independent from the project manager and different
person from other roles.

- 21 -

prEN 50126-2

4661

PM

ISA

A
RQM , DES, IM P

INT, TST

VER

VAL

ISA

PM

B
RQM , DES, IM P

INT, TST, VER, VAL

Key
can be the s ame person

can be the same organis ation

Shall report to the Project Manager
can report to the Project Manager
No line
PM = Project Manager

4662
4663

Shall not report to the Project Manager

ISA

= Independent Safety Assessor

RQM = Requirements
Manager
DES = Designer

INT

TST

= Tester

VER

= Verifier

IM P = Implementer

VAL

= Validator

Integrator

Figure 6 Organisational structure for integration and final phases

prEN 50126-2

- 22 -

4664

7 Guidance on system definition

4665

7.1 System definition in an iterative system approach

4666
4667
4668
4669
4670
4671
4672
4673
4674

The risk assessment process is derived from a system definition. The necessary activities and
deliverables in the system definition phase are listed in EN 50126-1, 8.3.
An iterative method, as described for hierarchical systems in EN 50126-1, is used for defining a
system and its subsystems. The iterative method is applicable in different phases of the lifecycle. This could be in early phases of the functional breakdown of a system considering the
safety aspects or in later phases where the method is applicable to the breakdown of functions
or requirements, for example the allocation of functions to subsystems. The detailed procedures
for system definition depend on the phase of the life-cycle or the iterative level of the (sub)
system under consideration.

4675

7.2 Method for defining the structure of a system

4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687

There are several types of breakdown structures, for example functional or architectural breakdown. For RAMS purposes the focus is on a functional breakdown which groups the functions
together in a way that they can be carried out by a subsystem/product. In this case the functions
of the system under consideration (including behaviour following failures, when defined) should
be identified and described in the first stage of the system definition.
Function List
A list of functions to be performed by the system under consideration in the first stage of the
system definition. It can be a preliminary list of functions and/or a preliminary system
requirements specification depending on the level of application and on the level of known
details of the functions.
Functional breakdown
The identified functions should be grouped together on the basis of:

4688

contribution to the same function of higher level;

4689

identified technical constraints (like subsystems/products to be reused).

4690
4691

Major external factors of the system should be also considered, including:

the parties/stakeholders and boundaries of the system (see 7.3);

4692

physical and functional interfaces;

4693

limits of risk assessment.

4694
4695
4696

Typical examples of the system functional breakdowns in the railway context are given below
including subsystems that carry out the function. In addition to that, EN 50126-4 provides an
example for a possible setting of different levels for the definition of functions.

- 23 4697

prEN 50126-2

Table 1 Typical examples for a functional breakdown

System
Fixed
installations

Rolling
stock

Control
command
and
Signalling

Functional
breakdown group

Function

Provide traction energy Distribute and control flow of

for trains
electric energy

(Subsystem that carries

out the function)
substation & switching
stations

Transmit electric current to

vehicle

contact line systems

Decelerate train

Brake system

Hold train in standstill during

stop

Brake system

Control access to train

Hold all exits closed when

vehicle is moving

Door control system

Guide trains through

station

Hold position of point

Interlocking

Indication signal aspect to

driver

Interlocking

Ensure that train does not

exceed maximum speed

Train control

Control speed of train

Manage speed of train

4698

7.3 Parties/stakeholders/boundaries of systems

4699
4700
4701
4702
4703

When defining and analysing the system, consideration should be given to the system interfaces
and boundaries of organisational responsibility. A failure that occurs in a system may propagate
through its interfaces and have implications which can only be controlled by another
organisation. In such cases the findings should be communicated to the other organisation in a
timely manner.

4704

7.4 Guidance on the content of a system definition

4705
4706
4707
4708
4709
4710

The necessary content of a system definition is defined in EN 50126-1, 8.3.2.1. The following
list provides guidance on some aspects that should be taken into account and clearly
documented:
System boundaries and interfaces (related to EN 50126-1, 8.3.2.1 b), for example:
interfaces (with other systems or working environment) define the boundaries of the
system under consideration and their interactions;

4711

location(s) of the system parts and interfaces;

4712

human-machine interfaces.

4713

Working environment (related to EN 50126-1, 8.3.2.1 b), for example:

4714
4715

influence on neighbouring objects, systems, and environment including operational and

maintenance personnel, passengers, and public;

4716
4717

operational requirements in consideration of the environment in which the system under

consideration works;

4718
4719

description of operating procedures, identification of personnel permitted to carry out

these actions and indication of the skills, qualifications and time-resources required;

4720
4721

if no human activities have been included in the analysis, the reasons for this should be
stated.

4722

Modes of operation (related to EN 50126-1, 8.3.2.1 c):

4723
4724

normal, abnormal/degraded mode of operation, disconnected/connected states and

transitions, and their interactions;

4725
4726

operational scenarios considered within the analysis, for example modified operation due
to maintenance operations (how, how often and by whom the system is maintained?).

prEN 50126-2
4727
4728

- 24 -

Examples of external safety requirements and influences resulting from the overall safety policy
of the safety authority (related to EN 50126-1, 8.3.2.1 -c and -d):

4729

prevailing legal considerations;

4730

standards that could impose a pre-defined THR, or;

4731

contractual requirements.

- 25 -

prEN 50126-2

4732

8 Risk analysis and evaluation

4733

8.1 General

4734
4735
4736
4737

The risk analysis should be performed as follows:

1. Hazard identification: identifies the hazards at railway system level together with the
operational context in which the hazards might arise using hazard lists, empirical
methods or creative methods (see 8.2);

4738
4739

2. Hazard classification: classifies identified hazards based on previous experience and

expert judgement (see 8.3);

4740
4741
4742

3. Consequence analysis: identifies the links from the hazards to the accidents, possibly
through barriers, for each accident scenario using cause-consequence diagrams and
event trees (see 8.4);

4743
4744
4745

4. Risk evaluation and acceptance: determines a risk acceptance principle (and if needed
derives risk acceptance criteria within that principle) in order to select and evaluate the
safety measures needed to control the risk (see 8.5).

4746

8.2 Hazard identification - process and methods

4747

8.2.1 General

4748
4749
4750
4751
4752

A Hazard Identification process involves a systematic analysis of a system to determine the

hazards which may arise throughout the life-cycle and develop into accidents.
During the Hazard Identification, the definition of the operational context is necessary to
evaluate the risk specific to a hazard within its accident scenario.
Hazards (what) shall be evaluated within their operational contexts, e.g.:

4753

operational modes (how);

4754

timings and phases (when);

4755

geographical conditions (where).

4756
4757
4758
4759
4760

For example, as part of trying to understand the risk associated with a passenger train in a
given operational context, the following circumstances could be considered: operating driver
only, in normal operation, at a standstill, in a station, with a passenger transfer in progress, etc.
Systematic identification of hazards involves two phases:
empirical phase;

4761
4762
4763

uses knowledge and previous experience to identify potential hazards. This may be, for
example, through application of an appropriate checklist. Methods and techniques used
in this phase are described in 8.2.2.

4764

creative phase;

4765
4766
4767

uses collective, imaginative thinking. In this phase methods and techniques identify
previously unknown hazards that may arise from novel or modified undertakings (refer to
8.2.3 for more details).

4768
4769
4770
4771
4772
4773
4774
4775

The empirical and creative phases of Hazard Identification process complement one another,
increasing confidence that all significant hazards have been identified.
The hazard identification method should provide a classification measure to concentrate on the
important hazards.
For complex or innovative systems more than one hazard identification process should be used
to reduce the probability of significant hazards not being identified.
Railway level hazard lists may prove helpful as a starting point for hazard identification methods
see e.g. EN 50126-1, Annex C.

4776

8.2.2 Empirical hazard identification methods

4777
4778
4779
4780
4781

Empirical hazard identification uses knowledge and previous experience to identify potential
hazards.
It constitutes an identification of potential hazards and ensures that, where possible, previous
errors, failures and losses are avoided.
Typical empirical hazard identification methods are:

prEN 50126-2

- 26 -

4782

checklists of hazardous circumstances;

4783

structured walkthroughs.

4784
4785
4786

More rigorous empirical hazard identification methods are:

Failure Mode Effect & Criticality Analysis (FMECA) for systems/subsystems;
Task Analysis for human-machine interfaces.

4787
4788
4789

These rigorous methods identify particular component failures or human errors that may lead to
an accident. Detailed knowledge of the failure modes of the components and the subsystems is
required, including human actions and possible errors.

4790

8.2.3 Creative hazard identification methods

4791
4792
4793
4794
4795

Creative hazard identification uses techniques and methods to encourage imaginative and
creative thinking. Ideally a team-based approach is employed to exploit the diverse and
complementary backgrounds of a range of individuals. Creative methods generally demonstrate
the following key characteristics:
planning and processing management procedures;

4796

guidelines for team selection and briefing;

4797

hierarchical decomposition and graphical representation of the problem domain;

4798
4799

high level analysis of the key elements of the system and determination of the critical
subsystems and interfaces;

4800
4801
4802

identification and recording of potential hazardous circumstances including causes and

consequences, potential mitigation and control measures useful in next step of risk
analysis process.

4803
4804
4805
4806
4807
4808
4809
4810
4811

Before conducting hazard identification, preliminary ideas about the scope or boundary of the
undertaking concerned, developed during the system definition phase, should be considered.
However, a too rigid adherence to this boundary during the hazard identification process could
prevent identification of interactions that were not previously considered and may lead to
significant hazards (particularly where complex technological and/or human interfaces are
involved). An important feature of creative hazard identification method is its ability to fully
explore the scope and boundary of an undertaking. In particular, they generally allow the full
domain of influence of an undertaking to emerge during the hazard identification study.
Creative hazard identification methods include:

4812

structured what-ifs;

4813

brainstorming;

4814

Hazard and Operability (HAZOP) studies.

4815

8.3 Hazard classification

4816
4817
4818
4819
4820
4821
4822
4823

Hazard classification structures identified hazards in terms of relative risk.

Based on previous experience and expert judgement, risks deriving from each identified hazard
is categorised by a frequency and a severity for the consequences of the hazards. For details on
Consequence Analysis see 8.4.
The hazard classification ensures that subsequent risk assessment is focused on reducing risks
associated with the most significant hazards.
It may be determined at this stage that hazards classified with a low level of risk do not require
further consideration. In such cases, a rationale for this position shall be documented.

4824

8.4 Consequence analysis

4825

8.4.1 General

4826
4827
4828
4829
4830

Consequence analysis analyses the consequences of each hazard up to accidents and losses.
Initially, the analysis is performed qualitatively identifying all contributing factors and their
combination without quantification.
If quantitative explicit risk estimation is adopted, it will be possible to use frequency/probability
of occurrences and units of loss (adequate to the system analysed).

- 27 -

prEN 50126-2

4831
4832
4833
4834
4835
4836

If a code of practice is applied, the consequences of the hazards shall only be analysed
according to the requirements of the corresponding code of practice.
Consequence analysis involves gathering and documenting data that describe the effects of a
hazard. The recommended approach is to use accident data, wherever available, and/or to
query individuals with expert knowledge of the current or future system, or process environment
(so-called domain experts).

4837

8.4.2 The risk model

4838
4839

A risk model should be defined for a consequence analysis.

Causes, hazards and accidents stand in a many-to-many relationship, such as:

4840

a single cause may trigger (or contribute to) several different hazards;

4841

a hazard may be triggered by several different causes;

4842
4843

a hazard may result in different types of accidents under different operational and
environmental contexts;

4844
4845

an accident may have different consequences under different operational and

environmental contexts.

4846
4847

Figure 7 provides a model relating to risk analysis performed for safety purpose. It shows the
various concepts that need to be considered when analysing and estimating risk, i.e.:

4848
4849
4850

how an hazard at the level of the system under consideration, due to technical and
operational cause, are combined with triggering events and barriers, if any, before
resulting in a hazard at the railway system level;

4851
4852

how a hazard at the railway system level may develop under a particular operational and
environmental context into an accident with a specific set of consequences.

4853
4854
4855
4856
4857
4858

When applied, such model should, in a qualitative and flexible way, identify the links between
hazards, triggering events and barriers which prevent them in a given accident scenario.
In specific cases hazards at the level of the system under consideration may directly equate to
hazards at the railway system level, and these may directly develop into accidents. In other
cases the cause may be less direct. Similarly, barriers may or may not exist or be not effective.
Operational and Environmental Context
Including triggering events

operational
and/ or
technical
causes

system under
consideration

4859
4860
4861
4862
4863
4864

&

external
occurence barrier & case
specifies
(reducing frequency)

hazard at the
railway system
level
(pot ential accident)

&

consequences
of the potential
accident

external
mitigation barrier & case
specifies
(reducing severity)

Figure 7 An example of risk model

The operational and environmental context defines where and when a hazard identified at the
railway system level may develop into an accident. A hazard may develop into a different
potential accidents for different operational and/or environmental contexts. Operational and

prEN 50126-2

- 28 -

4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906

environmental context should also include all the operational or environmental conditions that
are necessary to the understanding of the accident scenario. An example of operational context
is a train in normal operation, at standstill in a station, with a passenger transfer in progress.
Some examples of operational or environmental conditions are a driver-only operation, a track
gradient, an icy weather, a crowded platform, and unusual short trains.
Triggering events are all those conditions outside of the system under consideration, and
therefore outside of the projects control, that may directly or indirectly lead or contribute to a
hazard at the railway system level. Some examples are: external environmental occurrences,
human actions (e.g. passengers pushing doors buttons), case specifics and failures of systems
external to the system under consideration. They should be explicitly represented in the risk
model.
The system under consideration is defined by the scope of the project. It might be a technical
system and its associated application conditions or a set of rules and procedures.
Within the system under consideration, hazards may be originated by a mix of:
operational causes (wrong operation or maintenance) and
technical causes (internal to the technical system).
An external occurrence barrier is a feature outside the system under consideration that reduces
the occurrence of a hazard at the railway system level. May be technical or operational (e.g.,
externally induced automatic train brake in case of over-speed caused by wrong speed
signal/display).
The case specifics are those contexts or conditions specific to the regarded scenario that
reduce (or prevent) the occurrence of the hazard transforming into an accident. Such specifics
may for example be: neutralising factors like only one train on the line (therefore no collision
with another train possible), speed limited to 20 km/h (therefore consequences of a
collision/derailment may be lower), only fret traffic (therefore no casualties among passengers).
These specifics can be quantified either reducing the occurrence or the severity of the
potential accident as barriers would. However, they are limiting the use of the system and
become application conditions, therefore when the system is checked for cross acceptance /
mutual recognition, it will be necessary to check whether these specifics still apply, otherwise
the safety case will not be applicable in the new operational context (thus preventing cross
acceptance / mutual recognition).
The hazard at the railway system level is a hazard that affects a railway in operation as a
comprehensive system (some typical railway hazards are presented in EN 50126-1, Annex C).
An external mitigation barrier is a feature outside of the system under consideration that may
reduce the severity of an accident (for example, for a collision at low speed, the mitigation
barrier could be a passive energy absorbing device). In the figure, those barriers are shown
downstream of the hazard, for the sake of simplification.
For the definition of accidents and their consequences in terms of severity see Terms &
Definitions in EN 50126-1.
The following table shows examples of cases of a functional hazards with or without occurrence
barriers.

4907

Table 2 Examples of hazards

Functional hazard

Occurrence barrier

Hazard at the railway system

level

absence of brake
command

no barrier

overpass of allowed braking

distance

insufficient braking

train detection, with safety

distance between each signal

overpass of allowed braking

distance

Wrong aspect of signal

No barrier

Signal passed at danger

4908
4909

8.4.3 Techniques for the consequence analysis

4910
4911

Due to the complexity of the scenarios under analysis, the consequence analysis is performed
using a combination of bottom up techniques or mixed bottom-up top-down techniques.

- 29 -

prEN 50126-2

4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931

Whatever method is chosen, the role of expert judgment is fundamental for the analysis and the
calibration of the techniques used in support.
There are different techniques used, often in combination, to perform the consequence analysis.
Hereinafter the most used are briefly reported and explained. A list of techniques is reported in
Annex H.

4932
4933
4934

The occurrence of an accident can be represented by the top event of the fault tree.
Therefore the Fault Tree Analysis can also be used to model the influence of basic
events (hazards) on the occurrence of the top event (accident).

4935
4936

Event Tree Analysis (IEC 62502)

The technique is particularly well suited to represent the way in which a range of accidents
might occur, once a hazard has occurred.
ETA helps with the derivation of barriers by facilitating a structured understanding of the
succession of causes from the initiating event through to each final outcome or accident. ETA
analyses the occurrence of an initiating (or triggering) event and each following sequences of
events and their probabilities to a possible end condition, e.g. a resulting accident.
If a quantitative approach is applied with ETA, a frequency can be calculated or estimated for
each accident and combined with the severity of its consequences to calculate a risk estimate
for each possible accident. An average risk given the occurrence of the initiating event can then
be calculated by aggregating the risk of all possible accidents. The tree is often graphically
made by expanding the possible outcome along a horizontal or vertical axis.
ETAs may also include those risk-reducing intermediate events and states that do not lead to an
accident.

Failure Mode Effect & Criticality Analysis (FMECA IEC 60812)

4937
4938
4939

This method helps to analyse the consequences of single failures. It can be based upon
a complete list of the system functions or/and a complete list of individual parts of the
system under consideration. It is not suited to analyse the effect of multiple failures;

4940

Cause-consequence diagram.

4941
4942
4943
4944
4945
4946

The technique graphically illustrates the relationship between a given outcome and all the
factors that influence the outcome; it helps to identify all possible causes of a problem or
hazard. It can be regarded as a combination of fault tree (FTA) and event tree analysis (ETA). A
set of standard symbols are defined for use in cause consequence diagrams. The diagrams can
be used to compute the probability of occurrence of certain critical consequences.
Deductive Cause-Consequence Analysis (DCCA) ;

4947
4948
4949
4950

The technique uses formal methods to perform safety analysis. DCCA is a formal
generalization of the two techniques: Failure Modes and Effects Analysis (FMEA) and
Fault Tree Analysis (FTA). It shows mathematically whether a failure on component level
is the cause for system failure or not;

4951
4952

The standard IEC 60300-3-1:2003 provides a comprehensive overview over techniques

in conjunction with their applicability.

4953

8.5 Risk evaluation and acceptance

4954

8.5.1 Introduction to the risk acceptance principles

4955
4956
4957
4958
4959
4960
4961

As a result of the risk assessment, the safety requirement specifications are issued under the
responsibility of the railway duty holder.
The safety requirement specifications, together with the application conditions, define technical,
procedural and organisational safety measures to be put in place to control risks to an
acceptable level.
These safety requirements shall be supported and justified by the demonstration of the
following:

prEN 50126-2

- 30 -

4962
4963

For each hazard, the risk and its countermeasures have been evaluated on the basis of
one or more of the following risk acceptance principles:

4964
4965
4966
4967

use of a code of practice (see 8.5.2);

use of a similar system as a reference(see 8.5.3);
explicit risk estimation (see 8.5.4).
The selected risk acceptance principles meet their preconditions;

4968

Applicability criteria to the system under consideration have been met;

4969

Traceability is provided between safety requirements and related risks.

4970
4971

Guidance to item 2 (preconditions for risk acceptance principles) and item 3 (applicability
criteria) is given in the following paragraphs.

4972

8.5.2 Use of code of practice

4973

8.5.2.1 Preconditions

4974
4975
4976
4977
4978
4979

A Code of Practice (CoP) is a well-known and recognised set of recommendations that, when
correctly applied, can be used to control one or more specific hazards.
The application of a code of practice can be used as a risk acceptance principle if the CoP
meets the following preconditions:
be widely recognised in the railway domain. If this is not the case, the CoP will have to
be justified and be accepted by the validator or ISA when appropriate;

4980

be relevant for the control of the considered hazards in the system under consideration.

4981

8.5.2.2 Applicability to the system under consideration

4982

Conditions for applicability, when a code of practice is used, consist of:

4983
4984

verifying its ability to control adequately the identified hazards in the given operational
context and in interaction with other systems;

4985

justifying the application of qualitative/quantitative safety targets expressed in this CoP;

4986
4987

checking and justifying gaps or differences between the system under consideration and
the related CoP.

4988
4989
4990
4991
4992
4993
4994
4995

The hazards and associated risks that are covered by the application of CoP are considered
acceptable, provided the above conditions for applicability are fulfilled. That means that no other
risk acceptance principles need to be applied for the hazards completely controlled by
application of a CoP. Furthermore, a consequence shall only be analysed according to the
requirements of this code of practice, see 8.4.1.
When a Code of Practise is applied:
The practices of the code of practice directly become the safety requirements for the
hazards they control;

4996
4997

The use of a code of practice does not imply that the requirements defined in this
European Standard are no longer valid.

4998
4999
5000
5001

If the risk for a particular hazard cannot be made acceptable by the application of a CoP,
additional safety measures shall be identified by applying other risk acceptance principles. This
may also occur when the related code of practice does not sufficiently cover the identified
hazards, for example the code of practice is not applicable to the full range of hazards.

5002

8.5.3 Use of a similar system as reference

5003

8.5.3.1 Preconditions

5004
5005
5006
5007
5008
5009
5010

An existing, similar system accepted as safe and state of the art can be used as a reference for
the system under consideration.
A system under assessment can be compared with a similar reference system for risk
acceptance if the following preconditions are met by the reference system:
it has already been in service for a period of time sufficient to give confidence on the
coverage of a range of observed hazards or accidents; that is consistent with the
required level of safety in the proposed application;

- 31 5011

prEN 50126-2

represents good practice and would still qualify for acceptance.

5012

8.5.3.2 Applicability to the system under consideration

5013
5014
5015

Conditions for applicability, when the similar reference system principle is used, consist of:
verifying the relevance of the selected reference system to adequately control the
identified hazards;

5016
5017

checking gaps or differences between the system under consideration and the scope of
the reference system. The reference system should, in particular at least:

5018
5019
5020
5021
5022
5023
5024

have similar functions and interfaces as foreseen by the system under consideration;
be used under similar operational conditions as foreseen by the system under
consideration;
be used under similar environmental conditions as foreseen by the system under
consideration.
NOTE
This approach implies that the information above was rec orded for the project that introduced th e
referenc e system and that the inf ormation has been retained.

5025
5026
5027
5028
5029
5030
5031
5032

If one or more of these conditions are not fulfilled, the safety requirements for the
hazards, covered by the reference system, can still be used. It is necessary to
demonstrate that the additional risk due to the difference between the reference system
and the system under assessment are adequately controlled. It is also necessary to
demonstrate that the system under consideration will reach at least the same safety level
as the reference system. This may require also the application of other risk acceptance
principles in order to show that the level of risk is at least comparable to the one of the
reference system.

5033
5034
5035
5036
5037
5038

The hazards and associated risks that are covered by comparison of the system under
assessment to a similar reference system are considered acceptable, provided the above
conditions for applicability are fulfilled. That means that no other risk acceptance principles
need to be applied for the hazards completely controlled by comparison with a similar reference
system.
When a similar reference system principle is applied:

5039
5040

the safety requirements for the hazards covered by the reference system may be derived
from the safety analyses or from an evaluation of safety records of the reference system;

5041
5042

if a tolerable level of risk was defined as an acceptance criterion for the reference
system, then the same criteria will be applied to the system under consideration;

5043
5044
5045
5046

if a CoP was used for the reference system with a set of risk acceptance criteria, then
the same CoP will be applied with the same criteria to the system under consideration .
If this CoP has changed since designing the reference system, the changes shall be
considered;

5047
5048

NOTE
This could sometimes lead to the reus e of the previous version of the CoP, provided that it is
justified and accepted by the appropriate body;

5049
5050

the use of a similar system as a reference does not imply that the requirements defined
in this European Standard can be skipped;

5051
5052
5053

if the same safety level as the reference system cannot be demonstrated, additional
safety requirements shall be identified for the deviations, applying one of the two other
risk acceptance principles.

5054

8.5.4 Explicit risk estimation

5055

8.5.4.1 Preconditions

5056
5057
5058
5059

Explicit risk estimation evaluates the risks of a given system in a particular operational context.
The estimation can be done quantitatively and/or qualitatively.
In the following areas the quantitative approach is not feasible and risk estimation and
acceptance arguments should remain qualitative:

5060
5061

mechanical parts that rely on material endurance and design tolerance properties over a
stated product lifetime;

prEN 50126-2

- 32 -

5062
5063

electrical hazards that rely on technical measures to avoid electrocution, induced

voltages, etc.;

5064
5065

operational rules (including operating staff, maintenance workers, etc.), where it may be
almost impossible to distinguish whether Tolerable Hazard Rates (THR) have been met.

5066

8.5.4.2 Applicability to the system under consideration

5067

Conditions for applicability, when explicit risk estimation is used, consist of:

5068

defining the tolerable level of risk for the consequences of the relevant hazards;

5069
5070

demonstrating that the safety measures applied are able to reduce the risk to this
tolerable level.

5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084

There are different methods to derive the tolerable level of risk, based on legal or other
requirements (for example, prevailing legal requirements, existing technical standards, existing
safety systems or processes, etc.). These criteria are not established by this European
Standard.
Annex B describes some well-known methods to define risk acceptance criteria.
When explicit risk estimation is appropriate the railway duty holders may allocate safety targets
for hazards at the railway system level.
Units for these safety targets can vary.
When, as a result of the risk analysis, these targets are transferred to the technical system as
Tolerable Hazard Rates (THR) (see 8.6.2), a transformation shall be provided since THR shall
be expressed in unit per hour.
If no THR are provided by the railway duty holder then either the railway supply industry will
propose them (along with the systems and sub-systems to be integrated into the whole railway
system) or the railway duty holder and the railway supplier will work together to define them.

5085

8.6 Guidelines to the explicit risk estimation

5086

8.6.1 Rationale

5087
5088
5089
5090
5091

Explicit risk estimation is performed by estimating the frequency of occurrence of an accident

and its severity of its consequences for the consequences from each identified scenario or
hazard, using data and or expert judgement.
These frequencies and severities may be assessed qualitatively, semi-quantitatively or
quantitatively.

5092

8.6.2 Quantitative approach

5093

8.6.2.1 General

5094
5095
5096
5097
5098
5099
5100
5101

The quantitative approach involves the elaboration of elements of the risk model shown in
Figure 7 using modelling techniques to produce a calculated estimate of risk. These approaches
can be used to set numerical targets for application to sub-projects, systems and sub-systems
and also to demonstrate that such targets have subsequently been met.
Fault Tree Analysis is commonly used to calculate the frequency of occurrence of hazards, as
well as Event Trees Analysis to calculate the probability of these hazards leading to accidents.
There are many ways and hybrid approaches in which such techniques can be combined and
structured to calculate risk estimates.

5102

8.6.2.2 Determining safety objectives appropriate to a project

5103
5104
5105
5106

Figure 8, development of Figure 7 shows THR mapped onto the accident scenario. Safety
targets relate to a potential accident occurring under a given operational and environmental
context and caused by a hazard identified at the railway system level. The THR is applicable to
a specific technical hazard of the system under consideration.

- 33 -

prEN 50126-2

Operational and Environmental Context

including triggering events

operational
and/ or
technical
causes

system
under
consideration

&

hazard at the
railway system
level
(pot ential accident)

external
occurence barrier & case
specifies
(reducing frequency)

&

consequences
of the potential
accident

external
mitigation barrier & case
specifies
(reducing severity)

THR
allocating THRs
and apportioning
further

deriving verification THR from

accident safety targets
railway duty
holders activity

demonstrating
compliance
suppliers
activity

5107
5108
5109

Figure 8 Tolerable rates in an example of risk model

5110

8.6.2.3 Deriving tolerable accident safety targets and THR

5111
5112

Tolerable tolerable accident safety targets can be derived for a system under consideration in its
specific operational and environmental context through the use of:

5113
5114

high level safety targets that may be set by the relevant safety authority within the legal
framework;

5115
5116

suitable existing models, data or analysis of previous accident occurrences and

severities;

5117
5118

suitable data, models or information on the occurrence rate of known hazards in

particular those known to be relevant to the system under consideration.

5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129

An example method for undertaking such an approach is presented in Annex B.

Cumulative safety statistics may deal with a set of different systems and different accident
scenarios. Typically the safety authority or railway duty holder should establish this link, when
setting targets to specific accident scenarios. In order to do this, the accident statistics need to
contain sufficient contextual and technical information to be able to establish the relevance to a
given project (see for instance Annex C).
This standard does not require a link to be made between tolerable accident safety targets and
cumulative national safety statistics, however such statistics may be able to be used to verify or
inform the setting of THRs.
Where cumulative targets are used, they shall be scaled down to the system under
consideration in its specific operational and environmental context, in particular:

5130
5131

A cumulative safety target for an accident, caused by different hazards, needs to be

scaled appropriately to the various hazards causing it;

prEN 50126-2

- 34 -

5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148

A cumulative safety target for an hazard, referred to a population of systems, needs

to be scaled appropriately to the system under consideration.
The Tolerable Hazard Rate (THR) shall be derived for the system under consideration through
discussion, investigation and agreement between the railway duty holder and the supplier.
The partitioning of the overall railway into its constituent technical systems is made, usually,
according to the specific project scopes / contractual frameworks and allocated targets are set
accordingly.
The railway duty holder can also directly assign the THR to the technical hazards as a target to
be reached by the supplier. On the basis of the above stipulated risk analysis methods and
principles.
External occurrence barriers may be considered between the technical hazards and the
potential accidents. The risk reduction provided by a barrier may depend on the operational
context.

5149
5150
5151
5152
5153
5154

The approach here described is a top-down one (from tolerable accident safety targets to THR).
Alternatively, a bottom-up method can be followed, starting from THR and verifying that the
tolerable accident safety targets are observed. In any case, the complete accident chain has to
be analysed and the acceptable risks apportioned between different accident types and different
functional and operational hazards so as to meet an acceptable level of safety for the complete
Railway System.

5155

8.6.2.4 Responsibilities

5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167

In principle, the railway duty holder should specify the THR so that the system designer is able
to determine whether their system design is capable of meeting the criteria. In practice, the
railway duty holder will determine targets at the railway system level and may need to work
together with the railway supplier to define THR at the technical hazard level.
The railway duty holder should define their system under consideration and its operational and
environmental context and provide this information to the supplier along with the THR of the
identified hazards so that the supplier can review the assumptions and confirm their validity for
the system under development.
The duty holder and the supplier need to discuss and agree on the list of hazards associated
with the system under consideration. This is so that:
a) hazards which are known by either party are communicated to all parties to help ensure
completeness;

NOTE
To illustrate the possible dependenc e of the risk reduction to the operational c ontext, the barrier traction
cut-off when tr ain doors are open is efficient only when the train is at standstill bec aus e it prevents the train from
moving due to a traction demand. Therefore this barrier pr ovides no risk reduction factor for this scenario when th e
train is running.

5168
5169
5170

b) the railway duty holder can make reasonable assumptions about the frequency of
occurrence of hazards associated with the technical system in its target setting, risk
assessments and safety management activities;

5171
5172
5173

c) the supplier is aware of the operational context in which hazards occur, and the other
hazards outside of the technical system that might be relevant, so that it can take
account of these in the system design.

5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185

The supplier will then demonstrate that the hazard rates estimated for the design meet the THR
possibly under a number of assumptions made to support the analysis, and in the hypothesis
that all assumed mitigations are subsequently applied. All of the sets of assumptions should be
documented by the supplier and passed to the integrator or railway duty holder as the so-called
application conditions.
Lastly, another possibility has to be considered: when designing a generic product, system,
subsystem, hardware or software for a wide range of applications. In this case, the specific
context cannot be defined. Therefore the system designer might make assumptions about the
context of the system under development, which enable the chain of causality from the technical
hazards to the potential accidents to be developed. The designer may then use that to assign a
THR to the technical hazards. These assumptions would then become application conditions for
the use of the system.

- 35 -

prEN 50126-2

5186

8.6.2.5 On the accuracy of data

5187
5188
5189
5190
5191
5192
5193

Methods used give approximate estimates of the levels of risk generated by hazards. The
results obtained from these methods should be used with an awareness of the uncertainties
inherent within them.
At the very early stage of the project life-cycle a major issue in the process of allocating safety
requirements is the high level of uncertainty in risk estimates. Dealing with this uncertainty in an
appropriate manner is a vital part of the risk management process. Three approaches are
applied:

5194
5195
5196

The most conservative approach for dealing with uncertainty is to take a worst possible
scenario. This is done throughout the requirement allocation process. Depending on the
specific project data available, the worst possible scenario might be applied as follows:

5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215

It is assumed that if a hazard could lead to a number of possible accidents the worst
possible scenario has to be considered;
If the frequency at which a hazard occurs is estimated by a range of failure
occurrence tolerability, based on a statistical analysis of data, then the highest
frequency of the range is used in analysis;
If the only way to estimate the frequency or effect of a hazard is expert judgement
then the worst considered scenario assessment of any expert is taken.
The recommended methodology for dealing with uncertainty of data is to use reasonable
estimates throughout the risk management process, including setting targets (THR at
higher level). These estimates may include the likelihood of a particular hazard based on
the operational profile and taking account of all factors that might avert or reduce the
severity of an accident including human actions. Estimates of frequency and
consequence can be based on actual data for existing railways, extrapolated data from
similar situations on other railways or even other modes of transport, using generic
failure rate prediction tools, and by expert judgement. At the end of the process some
kind of uncertainty estimation can be made taking account of the way that the different
uncertainties in individual estimates may cancel or add up. This estimation can then be
used to either adjust targets or change the acceptance criterion so as to give a
reasonable safety allowance.

5216
5217
5218
5219

An alternative approach is to employ a reasonable worst case for one of the dominant
factors in the safety analysis so as to introduce a reasonable measure of conservatism.
Having done this best estimates should then be accepted for other elements otherwise
the whole analysis will degrade to the worst case analysis.

5220
5221

8.7 Qualitative approach

5222
5223
5224
5225
5226
5227
5228
5229

In a semi-quantitative or qualitative methodology, explicit risk estimation is carried out using

judgement to allocate the frequency and severity into predefined categories which may be more
or less numerical in nature. This approach is particularly useful early in the project life-cycle
when little analysis or information may be available. At the early stage of a project the
categorisation of hazards is useful in order to understand their risk relative to each other so that
proportionate attention can be paid to managing them.
Examples of and rules for the calibration of accident frequency categories and severity
categories and risk tolerability matrix are shown in EN 50126-1, Annex D.

prEN 50126-2

- 36 -

5230

9 Specification of system requirements

5231

9.1 General

5232
5233
5234
5235
5236
5237
5238
5239

The process of risk assessment will result in a set of system requirements.

These requirements can cover both safety-related and not safety-related issues.
Non-safety requirements comprise features of the systems relating to non-safety-related
functions, non-safety-related failures of safety-related functions, RAM, comfort, appearance,
physical properties, etc. These requirements are still relevant to the understanding of safety as
they comprise the definition of the system under consideration.
Safety requirements shall consider the following types of requirements and assumptions:
safety-related functions;

5240
5241

tolerable hazard rates (THR), if defined during the explicit risk estimation and should
consider the following types of requirements and assumptions:

5242

definition of safe states (if any) and of the maximum permitted time to enter a safe state;

5243

organisational rules;

5244

operational rules;

5245

maintenance rules;

5246

failure detection measures or facilities or devices;

5247

environmental conditions;

5248
5249
5250

safety-related assumptions such as occurrence or mitigation barriers (e.g. protection

systems, redundancies) with their required effectiveness (probability of failure on
demand, per hour, etc.);

5251

legal requirements;

5252

requirements resulting from the hazard analysis performed at the higher level.

5253
5254
5255

Safety requirements can either be contained in a separate safety requirements specification, or

be tagged as safety requirement in the system requirement specification.
Safety requirements may be categorized as follows:

5256

functional safety requirements;

5257

technical safety requirements;

5258

operational and maintenance safety requirements.

- 37 -

prEN 50126-2

(sub-)systems

safety
requirements

functional
safety
requirements

non-safety
requirements

technical
safety
requirements

operational and
maintenance
safety
requirements

5259
5260
5261

Figure 9 Safety requirements

5262

9.2 Functional safety requirements

5263
5264

Functional safety requirements shall comprise:

the expected functional behaviour of safety-related functions;

5265

the failure behaviour of the safety-related functions, divided into:

5266
5267
5268

hazardous failure behaviour;

non hazardous failure behaviour.
the required quantitative target or qualitative category for the hazardous behaviour.

5269

9.3 Technical safety requirements

5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280

Technical safety requirements do not derive from the system functions but from their technical
implementation. They impact the system build. Technical requirements for each product may
address issues such as maintainability, environmental conditions, potential threats created by
the technology/system/subsystem regardless of their intended functions (e.g. fire safety, interior
safety such as sharp edges, presence of electric voltage, presence of combustible material,
structural integrity, absence of harmful agents/substances, mechanical strength, behaviour
under physical conditions such as moisture, heat, fire, etc.). Technical safety requirements also
comprise technical constraints for design/installation/use such as insulation coordination,
earthing, environmental conditions, electromagnetic compatibility.
They may also include safety requirements such as conformity to external standards, relevant
regulations, codes of practice.

5281

9.4 Operational and maintenance safety requirements

5282

Operational safety requirements comprise:

5283

specific actions expected for any category of personnel concerned;

5284

the expected operational procedures for normal and abnormal operation modes;

5285
5286

assumptions about safety-related operational restrictions (such as speed, number of

trains operating, average operating time, signalling instruction, etc.);

5287
5288

human interface rules, training demand, demand on staff, set of available competences
of operational staff, etc.

5289
5290

Operators shall ensure the implementation of these operational safety requirements.

prEN 50126-2
5291
5292

- 38 -

The maintenance safety requirements consist of a list of safety-related maintenance actions

such as:

5293

maintenance intervals;

5294

maintenance rules;

5295

maintenance procedures for specific applications;

5296
5297

limitations of spare storage, limitations on type of tools used, limitations on physical

characteristics of tools to be used, etc.

- 39 5298

prEN 50126-2

10 Apportionment of System Safety Requirements

10.1 Deriving and apportioning system safety requirements

5299
5300

This chapter displays how the different kinds of safety requirements stipulated in clause 9 are
apportioned to the system architecture during the hazard control phase.

5301

10.1.1 How to proceed with functions implemented by E/E/PE architectures

5302
5303
5304
5305
5306

Sub-clause 10.2 details how to deal with functional requirements (see 9.2) when transforming
them into a compliant system architecture and in the end assigning SIL on the functional
subsystem level and applying concrete measures.
As regards technical requirements such as climatic conditions, electromagnetic compatibility it is
a well-established approach to apply a code of practice. For more details see EN 50126-4.

5307

10.1.2 How to proceed with functions implemented by non-E/E/PE architecture

5308
5309
5310
5311
5312

Sub-clause 10.3 gives guidance on how to deal with technical requirements (see 9.2) for nonE/E/PE systems. For these systems it is a well-established approach to apply a code of practice.
For functional requirements to be implemented by a non-E/E/PE architecture it is often possible
to apply the methods presented in 10.2. It is also possible to use the methods described in the
corresponding technology specific standards.
10.2 Functional safety integrity for E/E/PE

5313

10.2.1 Deriving functional safety requirements for E/E/PE systems from defined hazards

5314
5315
5316
5317
5318
5319

During the apportionment of system requirements phase, detailed functional and system
requirements will be derived from the Overall Functional Requirements, as described in
EN 50126-1, 8.6.
Figure 10 displays the two main aspects of hazard control:
1. Initially, the quantitative integrity requirements (i.e., the Tolerable Hazard Rate, THR) for
each hazard shall be apportioned to functions, by defining:

5320
5321
5322
5323
5324
5325
5326
5327
5328

the safe state and its related fault negation time (permitted time to reach a safe
state). Being in this safe state, the system is not allowed to fall back into a
dangerous state if an additional failure occurs;
the Tolerable Functional Failure Rate (TFFR). This target may be specified at the
level of the technical system, or it may be specified at the level of a sub-function of
the system as it will always be specified at the lowest level of independence of the
system function (see also 10.2.7).
TFFR are rates. In the case that failure probabilities on demand are given, they shall be
transformed in appropriate continuous mode models.

5329
5330

It is important to note that the THR is a target measure with respect to both systematic
and random failure integrity:

5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341

It is accepted that only with respect to random failure integrity it will be possible to
quantify and to verify that the TFFR target is fulfilled;
Qualitative measures are also needed to enforce protection against random and
systematic failures.. This is covered by the measures derived from the safety
integrity level as described in more detail in 10.2.5.
2. In a refinement of the hazard control (after SIL allocation, when the safety-related
function is apportioned in a number of sub-functions) the TFFR is further apportioned
leading to failure rates for the subsystems/elements. The SIL remain unchanged at these
lower levels of apportionment, as no further independence can be proven. This is
described in more detail in 10.2.8.

5342
5343

The concept of SIL is applied only for E/E/PE systems (see 10.2.2); requirements for nonE/E/PE systems are dealt with in 10.3.

prEN 50126-2

- 40 From Risk
Analysis

List of hazards
with THR

for each hazard

Apportionment
(e.g. through fault tree, causal analysis, )
Check
independence
assumptions

System
architecture
for each
independent function

SIL table

Determine
TFFR and SIL

Function distribution
and apportionment
to subsystems

SIL and TFFR

for functions

FR for
elements

5344
5345
5346

Figure 10 Apportionment of functional safety requirements

5347

10.2.2 The safety integrity concept and its levels

5348
5349
5350
5351
5352
5353
5354
5355
5356

These sub-clauses cover the requirements for E/E/PE safety-related functions (or E/E/PE parts
of complex functions made with various technologies).
During the apportionment of system requirements, each hazard is related to one or more safetyrelated functions able to counteract the hazard.
When a function failure could lead to a hazard, or the protection against the hazard provided by
the function is no longer given, this is said to be an unsafe functional failure. TFFR refer to
these kind of failures.
The confidence that can be placed in the achievement and maintenance of functional safety
requirements is expressed as the safety integrity of the function.

5357

10.2.3 Random aspects of functional safety integrity

5358
5359
5360
5361
5362
5363
5364
5365
5366
5367

Quantitative targets on hazards can be transferred to their related functions on the basis of a
system model and a quantification of random fault events.
Random fault events could rise from random faults or external influences. Failures caused by
environmental conditions (e.g.: EMC, temperature, vibration, etc.) should be included within
systematic and random failure integrity as appropriate.
If a Tolerable Functional Failure Rate (TFFR) is defined, the relevant quantitative target for each
function can be set and demonstrated to be sufficient to guarantee the coverage of the THR
target defined at the hazard level.
The functional failure model should also show the actions to be taken to manage the fault after
its occurrence:

- 41 -

prEN 50126-2

5368

how the system is able to detect the fault;

5369
5370

which are the safety engineering techniques (safety design principles and fail-safe
architectures) that assure a safe reaction;

5371

how the system contains the fault effects (system recovery, emergency procedures);

5372
5373

which are the procedural and maintenance actions to be implemented and what is the
periodicity of those actions to be implemented.

5374

Auxiliary functions (diagnostics) and preventive maintenance will also be taken in account.

5375

10.2.4 Systematic aspect of functional safety integrity

5376
5377
5378
5379
5380

An effective safety management has to be considered to minimise systematic faults during all
the phases of the life-cycle.
Quality and safety processes, including verification & validation activities, should prevent and
remove systematic design faults during the design phase as well as other human errors in the
other phases.

5381

10.2.5 Combination of random and systematic aspects

5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395

From what has been said, the quantitative safety target expressed through the TFFR is only one
of the aspects of the safety integrity to be fulfilled.
The safety integrity of a function addresses different aspects, each of them necessary to provide
confidence in the achievement of the requirement. That is, besides the quantitative aspects,
safety integrity shall also address factors as quality management, safety management and
technical safety conditions.
Quality management, safety management and technical safety conditions are addressed in this
standard as qualitative measures.
The more stringent the quantitative requirement expressed as TFFR, the more stringent the
qualitative measures will be. To balance between qualitative measures and TFFR, five levels of
integrity (namely Safety Integrity Levels, SIL) are defined, from 0 to 4 (highest level of safety
integrity).

5396
5397
5398
5399
5400
5401
5402
5403
5404

For each one, a set of qualitative measures (from here on, SIL-measures) is correlated to a
range of TFFR. These measures are defined, for E/E/PE systems, in EN 50126-4 and
EN 50126-5.
It is important to recognize that fulfilment of a particular quantified safety target does not, by
itself, mean that the corresponding safety integrity level has been achieved. Similarly, fulfilment
of the quality management conditions, safety management conditions and technical safety
conditions associated with a particular safety integrity level does not mean that the
corresponding quantified safety target, or the safety integrity level itself, have been achieved. All
of the factors in Figure 11 shall be fulfilled in order to achieve the specified safety integrity.

NOTE
Other standards address similar c onc epts of SIL; however, due to fundamental differenc es between the
concepts, these SILs are not directly comparable without further analysis.

prEN 50126-2

- 42 -

Safety Integrity

SI Levels

Quality
management
conditions

5405
5406

Safety
management
conditions

Technical
safety
conditions

Compliance
to the SIL-measures

Figure 11 Relationship between SILs and techniques

Quantified Safety
Targets

Demonstration of
quantified targets

- 43 5407

10.2.6 The SIL table

5408

The following SIL table can be used in two opposite ways:

prEN 50126-2

5409
5410
5411

It identifies the required SIL for the safety-related function from the TFFR. Thus if the
TFFR for a function F has been derived by a quantitative method the required SIL shall
be determined by the use of the table;

5412
5413
5414

When a TFFR cannot be derived from high level targets, but a SIL has been assigned on
the basis of qualitative consideration, then the most restrictive TFFR of the
corresponding possible range shall be demonstrated.

5415
5416

In both the cases, the relevant SIL-measures described in EN 50126-4 and EN 50126-5 shall be
applied.

5417

Table 3 SIL and SIL-measures

SIL
attribution

[TFFR] h -1

10 -9

TFFR < 10 -8

10 -8

TFFR < 10 -7

10 -7

TFFR < 10 -6

10 -6

TFFR < 10 -5

10 -5

SIL-measures

see EN 50126-4
and EN 50126-5

TFFR

5418
5419

10.2.7 SIL allocation

5420
5421
5422

The following definitions apply for this sub-clause:

1. Two safety-related functions are unrelated (in respect of hazards) if they do not control
the same hazards;

5423
5424

2. Two safety-related functions are correlated (in respect of a certain hazard), if they
control the same hazard:

5425
5426
5427

2.1 Two functions are autonomous if they are correlated, but each of them performs its
control autonomously, no matter whether the other is present or not. In the context of
former EN50129 this had to be read as independent for further details see 11.4.2;

5428
5429

2.2 Two functions are not autonomous if they are correlated, and they do not perform
their control autonomously, i.e. the other has to be present too.

5430
5431
5432
5433
5434

SIL allocation follows different rules according to these cases described above:
1. For unrelated functions. They are linked to unrelated hazards, therefore derivation of
TFFR and SIL allocation (according to 10.2.6) can be performed independently;
NOTE For example, locking train doors and braking control are two unrelated functions.
SILs will be separately alloc ated.

5435
5436

2. For correlated functions. They are linked to a same hazard. SILs shall be allocated only
to the lowest autonomous safety-related functions and not further. This means that:

5437
5438
5439
5440
5441
5442

2.1 If the functions are autonomous, the THR defined for the hazard is apportioned to
TFFRs, one for each of the autonomous functions. Then SIL is allocated for each
function according to 10.2.6. Independence with respect to systematic and random
causes of wrong-side failures has to be demonstrated;

5443
5444
5445
5446
5447
5448
5449

2.2 If the functions are not autonomous, a single TFFR and a corresponding single SIL
shall be defined. The TFFR can then be further apportioned to the not autonomous
functions, provided that independence with respect to random causes of wrong-side
failures is demonstrated.

NOTE For example, barriers control and light control at the level crossing are corr elated but
autonomous functions, with respect to the hazard of trespassing. Each of them will have its own SIL.

NOTE Examples of correlated and non autonomous functions depend on the architectural design.
Locking and closing of passenger doors, or Automatic Train Protection trackside and Automatic Train
Protection onboard functions may be c orrelated and not autonomous functions.

prEN 50126-2
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468

- 44 -

Guidance on SIL allocation

1. Is it correct to say that SIL is related to the systematic part of the safety integrity,
and TFFR is related to the random part?
This is not correct. Whilst it is correct to state that TFFR is related only to the random
part of the safety integrity, the association of SIL only with the systematic part is
incorrect. SIL defines a set of qualitative measures. Many of them aim at protecting
against systematic failures, but some are defences against random failures (e.g.,
specific architectures or the single-fault principle)
2. For a single function, are the SIL-measures to be applied also to sub-functions in
the functional decomposition?
A part of the requirements expressed for the function apply all over the development,
therefore are also applicable to its constituents (e.g. quality and safety measures). Some
other requirements, such as the architectural safety constraints, are applicable only at
the level of the function. Other again, such as failure rates, can be apportioned to lower
levels.
3. Can two unrelated functions share the same SIL-measures? For instance, same
design features same dynamic fault detection, etc.

5469
5470
5471
5472

Yes they can. Safety-related functions within a system are implemented through a
development process and by sub-systems. The process has to fulfil quality and safety
measures, and the sub-system has to follow the architectural measures measures
defined within the set of the respective SIL-measures.

5473

Both the process and the sub-system will be common to a number of unrelated functions.

5474
5475
5476

4. What if a sub-system implements a number of unrelated functions, each of which

could require different SIL?
Where this is the case, two alternative options are possible:

5477
5478
5479
5480

every function meets the highest SIL demanded

if demonstration of mutual non-intrusiveness can be provided, every function can
satisfy its own required SIL
5. Can a higher SIL be claimed when integrating several lower SIL functions?

5481
5482

That is not possible. The idea of combining the SIL of two or more correlated functions is
a misuse of the SIL concept as it is here defined:

5483
5484
5485
5486
5487
5488
5489
5490
5491

if the functions are not autonomous, their combination does not assure any SIL
increase, as a common mode exist which renders therefore the combination
inefficient;
if the functions are autonomous, the random integrity may increase but the
systematic integrity does not increase.
Example: A SIL 4 function cannot be obtained by a combination of SIL 2 and SIL 3
functions. The systematic part of a SIL 2 function covers the measures of SIL 2. The
systematic part of a SIL 3 function covers the measures of SIL 3. Nevertheless both of
them do not cover the measures of a SIL 4 function.

5492
5493
5494
5495
5496
5497
5498
5499

6. Can the SIL of a function be apportioned to its sub-functions?

That is not possible. When a function is divided into a number of sub-functions, this
apportionment should not be reflected in an apportionment of the SIL itself as the SIL
is assigned only once during the apportionment. Then, during its design and
implementation, if mechanisms exist to prevent the failure of a component from causing
the function to go to an unsafe state, the SIL of this component may be reduced.
7. How can SIL be allocated for a E/E/PE part of a complex function made with
various technologies?

5500

In this case, no general rule can be given.

5501
5502

Consider for instance a door locking system. To keep the door locked, safety is
guaranteed both by a mechanical lock and an electronic control. The mechanical part will

- 45 5503
5504
5505

prEN 50126-2

be built according to a CoP, therefore the hazards are sufficiently dealt with according to
the CoP approach. However, SIL may also be higher if the control is needed for other
safety-related functions.

5506

10.2.8 Apportionment of TFFR

5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519

After SIL allocation, when the safety-related function is apportioned in a number of subfunctions (maybe allocated on different systems/subsystems) the TFFR is further apportioned
leading to failure rates for the sub-functions, but on this physical or implementation level subfunctions are not assigned with another SIL. The SIL shall remain associated to the safetyrelated function which the sub-functions belong to.
Consequently, the choice of SIL measures defined in EN 50126-4 and EN 50126-5 shall
correspond to the SIL defined at the functional level.
The TFFR apportionment process may be performed by any method which allows a suitable
representation of the combination logic, e.g. reliability block diagrams, fault trees, binary
decision diagrams, Markov models, Petri nets, etc. In any case particular care has to be taken
when independence of items is required.
Assumptions made in this phase should be checked and may lead to safety-related application
conditions.

5520

10.2.9 Demonstration of quantified targets

5521
5522

For demonstrating the fulfilment of the quantified targets, it is accepted that

Only random failures are considered in the evaluation of the TFFR (and related THR);

5523
5524
5525
5526
5527

Systematic failures are to be controlled by the adequate process and qualitative

requirements stipulated by the SIL-measures and therefore are not contributing to the
calculation and quantitative fulfilment of the required safety integrity requirements. Thus
having followed the measures and methods required for SIL x there is no requirement to
consider the systematic failures when demonstrating the TFFR is achieved.

5528
5529
5530
5531

A function having quantitative requirements more demanding than 10-9 [h -1] shall be treated in
one of the following ways:
if it is possible to divide the function into functionally independent functions, the TFFR
can be split between those functions and a SIL allocated to each function;

5532
5533
5534
5535

if the function cannot be divided, the measures and methods for SIL 4 shall at least be
fulfilled, as required in EN 50126-4 and EN 50126-5, and the function shall be used in
combination with other technical or operational measures in order to achieve the
necessary TFFR.

5536

10.2.10 SIL0

5537

SIL0 shall be allocated in two ways:

5538

if the TFFR is less demanding than 10-5 per hour (quantitative apportionment);

5539

if the function has a low impact on safety (qualitative judgment).

5540
5541
5542
5543
5544
5545
5546

SIL0 is recommended as a minimum level of quality for any software-based functions.

Examples of SIL0 qualitative allocation are:
Functions that contribute to hazards only indirectly, for example by influencing the
operational context in such a way as to increase human error with respect to other
functions by creating unsafe contexts, such as auxiliary functions (e.g. distraction
caused by advisory information for the operator or train dispatcher). Their contribution is
not always quantifiable;

5547
5548

Functions that not induce directly hazardous faults but affect the availability of the
interacting SIL functions, e.g. the transmission layer of a distributed SIL 4 system;

5549

Functions that mitigate the consequences of an accident (e.g. tunnel operating systems);

5550
5551
5552

Some functions may be differently considered as SIL 0 or no-SIL. For example,

supporting systems like energy optimisation, ventilation, climatic, passenger information
systems.

prEN 50126-2

- 46 -

5553

10.2.11 Prevention of misuse of SILs and warnings

5554
5555
5556

This sub-clause provides some warnings about the use of SIL for E/E/PE systems. Sometimes
the SIL concept is misunderstood and used for non-intended applications.
The following non-comprehensive list gives advice on how SILs should not be used.

5557
5558

SILs should be assigned only after a risk analysis. It is meaningless to assign SILs prior
to completing such an analysis;

5559
5560

SILs shall not be used for non-functional safety, e.g. applying SILs to safety against
slips, trips and falls;

5561
5562
5563
5564
5565

Assigning SILs without having defined appropriate measures and techniques for each
level is meaningless. In this standard only measures and techniques for electronic
subsystems have been defined (see EN 50126-4 and EN 50126-5). Therefore, if a safety
integrity level is assigned to a mechanic or mechatronic equipment then this is to be
considered not applicable and in the demonstration process this has to be stated;

5566
5567
5568

SIL refers to doing things right, not doing the right thing. Fulfilling all quantitative and
qualitative integrity requirements does not guarantee that the related function is correctly
defined;

5569
5570
5571

SILs should not be used for describing systems attributes, e.g. this is a SIL 4
computer. The correct wording would be: "this is a computer used to perform a SIL 4
safety-related function".

5572

10.3 Safety Integrity for non-E/E/PE systems Guidance on application of CoP

5573
5574
5575
5576
5577
5578

This sub-clause contains requirements for the non-E/E/PE parts of safety-related functions.
Examples of non-E/E/PE-Systems in the context of this standard (non exhaustive):
mechanical systems, like doors, windows, bellows, gangways, cable ducts, brackets,
supports, fixtures, wheels, axles, bogies, bearings, gears, brake discs and callipers, car
body shells, car body interiors, seats, grab poles, mechanical couplers, mechanical parts
of pantographs or current collectors, Diesel engines, etc.;

5579

pneumatic systems, like compressors, hoses, pipes, valves, actuators, etc.;

5580

hydraulic systems, like compressors, hoses, pipes, valves, actuators, etc.

5581
5582
5583
5584
5585
5586
5587
5588
5589
5590

Non-E/E/PE-Systems are often designed in accordance with one or several CoP. If a CoP is
applied for designing a safety-related function or for achieving the specific safety characteristics
of a system, this is deemed sufficient to reduce the residual risk to an acceptable level for the
hazards addressed by the CoP. The CoP shall meet the requirements of sub-clause 8.5.2 and
shall be applied as required by the same sub-clause.
If the CoP does not recommend or require specific methods for the failure analysis, suitable
techniques shall be selected from Annex H. Special attention shall be paid to the following
causes of failures for non-E/E/PE systems and functions:
1. natural end of life time due to mechanical wear, degradation or fatigue (e.g. number of
duty cycles of a wheelset, minimum wheel diameter);

5591
5592

2. natural end of life time due to environmental influences (e.g. thermal stress, sun,
pollution, chemical degradation of rubber or plastic material);

5593
5594

3. early end of lifetime due to improper application or insufficient maintenance (e.g. cracks,
corrosion);

5595

4. defective components (e.g. broken pin, leakage, etc.).

5596
5597
5598
5599
5600
5601
5602
5603

The topics 1 and 2 are inherent physical properties, whereas topics 3 and 4 can be minimized or
avoided by correct application of the CoP and by appropriate quality assurance measures during
design, manufacturing and maintenance as recommended in Annex D.
In most cases, the application of a CoP does not provide information about the expected
frequency of random failures of the non-E/E/PE functions and systems. If such systems and
functions are included in quantitative failure analyses (e.g. FTA), then special care must be
taken in the correct modelling of their failure frequency, taking into consideration possible wear,
preventive maintenance and field data.

- 47 -

prEN 50126-2

5604
5605
5606
5607
5608
5609

In addition to the application of a CoP, measures for the avoidance of systematic failures shall
be taken in accordance with clause 6 and Annex A as far as applicable for non-E/E/PE systems.
This standard does not allow the allocation of safety integrity levels to non-E/E/PE systems or
functions. SILs are defined for E/E/PE systems only (or for the E/E/PE part of a mechatronic
function).

5610

11 Design and implementation

5611

11.1 Causal analysis

5612
5613
5614
5615
5616
5617
5618

Causal analysis shall be performed during the design and implementation phase. Causal
analysis is the systematic investigation of the hierarchy of causes, its aim being to identify the
logic sequences of hazardous events that may lead to an undesirable effect.
All the functions, systems/subsystems, human mistakes and/or external factors (permanent or
not) that may cause technical hazards, as well as all the operating rules, functions and-or
systems/subsystems that implement barriers, shall be identified during the causal analysis.
Causal analysis consists of:

5619
5620

identification of all causal factors: environmental, functional, interface, hardware,

software, human;

5621
5622

identification of logical relationship between cause and effect at the analyzed level of
hierarchy (i.e. Hazard);

5623
5624

identification of the combination of events or mechanisms linking cause to the effect (i.e.
hazard);

5625
5626

identification and modelling of common cause failures by applying common cause

analysis.

5627

11.2 Identification and treatment of additional hazards arising from design

5628
5629
5630
5631
5632

Realisation of a system may lead to unforeseen or undesirable properties with a potential to

cause harm to people, in particular if the system or technology is new. New hazards may arise
because of several aspects:
new technology has a potential for new hazards, that could be not immediately identified
due to a lack of experience or knowledge;

5633
5634

emergence of additional hazards in the existing system due to a technological transfer

(e.g. from analogue to digital technology);

5635

mistakes in new design due to a lack of adequate/proper specification;

5636
5637
5638

special operation modes in an existing system may not fit well and may create new
hazards associated to actions performed by operators, maintainers or other members of
the staff, public, etc.;

5639
5640

design errors may create new hazards but they can often be related to the already
identified ones

5641
5642
5643
5644
5645
5646
5647

These aspects may give rise to hazardous circumstances and states which require the same
systematic treatment as applied to the already identified hazards.
Then it is possible to proceed in at least two different ways:
if the hazard can be associated to an identified one, or the severity of potential
consequences has not changed: in this case the supplier should make sure that the
resulting hazard rate of the combination of these two hazards is still compliant with the
THR that has been fixed by the railway duty holder;

5648
5649
5650
5651
5652
5653
5654

If the hazard has nothing to do with any of the identified ones, or the severity is different:
in this case the supplier shall communicate it to the railway duty holder and provide all
the information from the hazard analysis (causes, consequences, risk,). The railway
duty holder should then analyse these new hazards. Depending on the perceived risks,
these would require qualitative or quantitative assessment, with a view to forecast and
agree an appropriate tolerable level (THR) for each. These will lead to updated
requirements.

prEN 50126-2

- 48 -

5655

For both cases all the actions should be recorded in the hazard log and the safety case.

5656

11.3 Techniques for causal analysis

5657
5658
5659
5660
5661
5662
5663
5664

The causal analysis techniques aim to identify the logic sequence of the events developing into
a hazard. The analysis may be performed either qualitatively or quantitatively; in any case,
generally, the approach used is the top down approach. Depending upon the complexity of the
scenarios under consideration, in order to deeply investigate the logic cause-effect sequence,
the causal analysis is completed using a combination of bottom up techniques or mixed bottomup top-down techniques (see 8.4.3).
Annex H shows details and references to techniques/methods
Typical causal analysis techniques are:

5665

Fault Tree Analysis (FTA);

5666

FMECA;

5667

Markov analysis;

5668

Human factor analysis;

5669

Guidance on Human Aspects of Dependability (IEC 62508 Ed. 1.0.).

5670

11.4 Functional Safety principles

5671

11.4.1 Functional composition

5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696

The hazard analysis shall identify system failures and their potential to create hazards. Failure
analysis should be qualitative. It may be also quantitative where credible data is available.
Quantitative failure analysis may consider random hardware failure rates or probabilities of
component failures. When available, reliable field data should be used to support this analysis.
Hazardous failures of each safety-related function shall be detected either by a preventive
maintenance action or through a dedicated detection device or function.
If a hazard may occur only from the combination of failures of distinct and independent functions
the functional composition principle may be applied.
When using functional composition the safety demonstration shall consider independent and
dependent failures.
The system hazard analysis should give evidence that one of the independent functions is able
to contain the hazard potentially raised by the failures of the adjacent function.
Upon occurrence of single fault, the exposure time for a second fault to happen (leading to an
hazard) should be considered as the time to detect the fault plus either the time to restore
system function or the time to negate it (i.e. enforce a safe state for the system).
Dependent failures resulting from a single fault shall be considered when dealing with single
fault analysis.
Proof of independence of failures shall be performed to confirm any hypothesis of independence
of causes for multiple faults.
A common-cause failure analysis shall be performed when the functional composition principle
is adopted.
The common-cause failure section in the left-hand part of the following figure designates the
subset of the failures that cause both function A and function B to fail simultaneously. Hence
these common-cause failures have to be modelled separately as shown in the fault tree on the
right-hand side of the following figure.

- 49 -

prEN 50126-2
hazard

faults leading to
function A
failure

common
cause
failure

faults leading to
function B
failure

common
cause
failure
function A
failure

function B
failure

5697
5698
5699

Figure 12 Impact of functional dependence in a fault-tree analysis

5700

11.4.2 Independence of functions

5701
5702
5703
5704
5705
5706
5707

For the purpose of apportionment of integrity requirements, the following two aspects of
independence are considered:
physical independence, implying that, at a given architectural level of implementation,
the set of items building up this architecture do not fail, simultaneously or in cascade, as
consequence of a given single physical cause. If physical independence is assured then
random integrity requirements may be apportioned to the next lower architectural level of
implementation;

5708
5709
5710
5711

functional independence, implying that, under defined conditions, neither systematic nor
random failures cause a set of functions to fail simultaneously. If functional
independence is assured, then random and systematic integrity requirements may be
apportioned to the next lower level.

5712
5713

The following three aspects (physical, functional, process) of common causes shall be
addressed in the evaluation of independence:

5714
5715

physical causes, e.g. random failures or environmental conditions able to cause a set of
functions to fail together (either simultaneously or in cascade);

5716
5717

functional causes, all credible systematic and random failures able to cause a set of
functions to fail together (either simultaneously or in cascade);

5718
5719
5720

process causes( i.e. systematic causes), that may result from organizational issues,
preventing the designer, verifier or validator from identifying design or implementation
flaws that inherit the potential for common cause, physical or functional, failures;

5721
5722

NOTE
This standard considers that there is no implicit hierarchy or link between thes e three aspects of
common caus es.

5723
5724
5725

the result of common cause analysis is either the demonstration of independence or the
understanding of existing common causes. These shall be considered in subsequent
analyses.

5726

11.4.3 Supporting rules for evaluating technical aspects of independence

5727

For the purpose of evaluating independence, the common cause analysis, shall comprise:

5728
5729

the identification of interfaces (intentional and unintentional) between the system under
consideration and the external entities (external interfaces);

5730
5731

the identification of interfaces (intentional and unintentional) between the items of the
system under consideration (internal interfaces).

5732
5733
5734
5735
5736

The following rules are given to support the detailed demonstration of the two technical aspects
of independence (physical and functional) from internal and external influences.
Physical internal influence
If no physical connection or interaction exists between internal items of a system, there are
neither physical nor functional internal influences. Therefore, internal independence is achieved.

prEN 50126-2
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753

- 50 -

A physical internal influence may cause a loss of independence between items of a system. It
could originate from a physical connection or interaction of these items with other items of the
system. Measures shall be taken to avoid non-intentional physical internal influences.
Functional internal influences
A functional internal influence may cause a loss of independence between items of a system. It
could originate from a functional connection or interaction of these items with other items of the
system. Measures shall be taken to avoid non-intentional functional internal influences.
Physical external influences
A physical external influence may cause a loss of independence between items of a system. It
could originate from a physical connection or interaction of these items with the environment or
items external to the system. Measures shall be taken to avoid non-intentional physical external
influences (e.g. due to electromagnetic pulse).
Functional external influences
A functional external influence may cause a loss of functional independence between items of a
system. It could originate from a functional connection or interaction of these items with items
external to the system. Measures shall be taken to avoid non-intentional functional external
influences.

- 51 -

prEN 50126-2

Annex A (informative) Measures for the avoidance of systematic failures

5754
5755

A.1

General remark

5756
5757
5758

The following tables summarise the techniques and measures for the avoidance of systematic
failures which are mentioned in different parts of the standard, with a reference to the relevant
clauses.

5759

A.2

5760

Table A.1 Safety planning and quality assurance activities

Safety and quality management

Technique / M easures

Ref.

The organis ation responsible for the system c ertified to ISO 9001 or
equivalent

EN 50126-1, 7.3.7

Safety Plan to define key pers ons, their qualification and roles

EN 50126-1, 7.3.7

Safety Plan to define the risk acceptance criteria

EN 50126-1, 8.3.2.6

Safety Plan to be agreed between railway duty holder, supplier and / or

safety authority

EN 50126-1, 8.3.2.6

Validator independent from other key functions, in particular from

designer / implementer.

EN 50126-1, 7.1.3
EN 50126-2, 6.1, 6.2

5761
5762

A.3

System requirements specification

5763

Table A.2 System requirements specification

Technique / M easures

Ref.

Description of the relevant operational scenarios, e.g. by means of use

cases

EN 50126-2, 7.4

Safety-related system requirements to be clearly specified

EN 50126-2, 9.1

Safety Requirements derived from hazards to be back trac eable to thes e

hazards

EN 50126-1, 8.5.2.1

Hazardous failure modes to be defined for each specified s afety-r elated

function

EN 50126-2, 9.2

Safety states (if any) to be clearly defined

EN 50126-2, 9.1

System requirements specification (including safety requirements) to be

checked for completeness and suitability by the validator

EN 50126-1, 7.1.3
EN 50126-2, 6.1, 6.2

5764
5765

A.4

System architecture and design

5766

Table A.3 System architecture and design

Technique / M easures

Ref.

Application of appropriate fail s afe principles in the system arc hitecture

EN 50126-1, 8.6

System architecture to be documented and justified

EN 50126-2, 7.2

Apportionment and translation of safety requirements to subs ystems and

components to be performed with suitable qualitative or quantitative
methods

EN 50126-2, 10

Subsystem safety requirements traceable back to s ystem safety

requirements and hazards

EN 50126-1, 8.6.2.1

Separation of safety-related subsystems from non-s afety-related subsystems

EN 50126-2, 9.1

Common c ause analysis to be performed.

EN 50126-2, 11.1 and 11.3

prEN 50126-2

- 52 Technique / M easures

Ref.

Common c auses to be c onsidered in failure analysis using suitable

models

EN 50126-2, 11.1

System architecture, failure analysis, common caus e analysis and

subsystem safety requirements to be reviewed and accepted by validator

EN 50126-1, 7.1.3

5767
5768

A.5

Integration and testing of the system

5769

Table A.4 Integration and testing of the system

Technique / M easures

Ref.

Test cases to be defined and executed to test the correct behaviour of all
specified safety-related functions of the s ystem, including safety barriers,
as far as possible.

EN 50126-1, 8

Test cases to be defined and executed to test the correct behaviour of all
specified fault detection and negation mechanisms, as far as possible.

EN 50126-1, 8

Tests to be specified and executed to confirm the correct behaviour of

the s ystem under the specified environmental conditions as far as
possible. Environmental c onditions are climatic conditions (temperature,
humidity), mechanical c onditions (vibration, shock, dirt and dust) and
electrical c onditions (supply voltage variation, electromagnetic fields,
surges and transients)

EN 50126-1, 8

The persons in charge of the specification and exec ution of test cases,
and of the interpretation of test results shall be independent from the
pers ons responsible for the detailed design and manufacturing of the
system.

EN 50126-1, 7.1.3
EN 50126-2, 6.2

5770
5771

A.6

Application, operation and maintenance

5772

Table A.5 Application, operation and maintenance

Technique / M easures

5773

Ref.

Safety-r elated applic ation c onditions relevant for operation to be

implemented in operating manuals or in equivalent procedures .

EN 50126-1, 8.7.2.4 and 8.12.2

Operating staff to be trained specifically for the adherenc e to the relevant

safety-r elated application conditions

EN 50126-1, 8.12.2

Safety-r elated applic ation c onditions relevant for maintenanc e to be

implemented in maintenance manuals or in equivalent procedures.

EN 50126-1, 8.7.2.4 and 8.12.2

Maintenance staff to be trained specifically for the adherenc e to the

relevant safety-related application conditions

EN 50126-1, 8.7.2.5

Systematic reporting and critical analysis of any safety-r elated incidents to

be established and maintained.

EN 50126-1, 8.3.2.3 / b

Field data (failures, reported malfunctions) to be fed back to the suppliers

of the s afety-related systems to enable them to improve their systems.

EN 50126-1, 8.3.2.3 / b

Periodic review and improvement of operating proc edures and

maintenance manuals bas ed on field experience.

EN 50126-1, 8.12.2.2 / a

Periodic audits of the safety-related aspects of operation and maintenance

EN 50126-1, 8.3.2.4 / p

- 53 -

prEN 50126-2

5774

Annex B (informative) ALARP, GAME, MEM

5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786

In order to settle for an explicit risk acceptance principle, it is necessary to define the
acceptable level of risk. There are different methods and ways to derive and express the
acceptable level of risk for the relevant hazards.
The following sections describe numerous methods to define risk acceptance criteria in case of
explicit risk estimation.
The way to demonstrate that the level of risk achieved is acceptable has to be compliant with
national law and application of any of these principles should take account of this. Within this
context, use of such principles can provide a basis for establishing risk acceptance levels.
However, in the absence of any legal or other such provisions or guidance, the choice of the
principle will depend, to a large extent, on the prevailing social/political environment. The
relevant parties including any RA and/or SRA should therefore agree the choice and use of
these principles.
Criteria

ALARP

GAME

General
approach

Imposes a relative duty, stating that

the duty holder must apply any safety
measures that will reduce risk ALARP.
The judgement of whether or not a
particular control is ALARP is based
on a c omparison of the net costs,
taking account of any commercial
benefits, with the extent of risk
reduction of any safety
measure/s afety r equirement under
consideration.

comparis on of two systems;

the new s ystem has to be
globally equal or less risky
than the existing one

calculation of THR directly

derived from a c ommon
independent safety target

Referenc e of risk

The change in collective risk

associated with each option/s afety
measure.

referenc e system

normally to individual risk

Assumptions

Assumes a certain relative value

associated the risk from different
types of injury/fatality.

similar s ystem like the new

system has to be already
existing; requires to analyse
the existing (old) system;
then GAME can be applied

further assumptions on
apportionment of risks to
subsystems and
components to be made

Acceptanc e
criteria

If the costs of a measure are judged

to be disproportionate to the s afety
benefits, taking into account any
uncertainties in the risk estimates then
the measure is judged to be ALARP
(and theref ore acceptable).

the new system is less risky

or equal compared with the
existing (old) s ystem

the individual risk (fatalities

per pers on and time)
caused by the s ystem is
lower than the tolerable risk
derived from MEM

Area of
application

Safety optioneering on projects.

Further work to map potential safety
controls to hazards is needed if the
approach is to be us ed to set THR.

setting quantitative risk

targets for systems;
construct qualitative s afety
arguments; compare two or
more equivalent s ystems
(functional or technical
equivalence)

setting quantitative risk

targets for systems and
sub-systems

Strengths

no reference s ystem needed. Allows

the c ost effectiveness of safety
measures to be explicitly considered.

Keeps, at least, the existing

level of safety and tends to
improve the level of safety.

no reference system
needed; independent safety
target is given

W eaknesses

The mapping of controls/safety

measures to hazards is not simple and
further work is required to understand
their relationship.

referenc e system with

experienc e data needed;
mutual compensation of
more and less risky subsystems not clarified.

not widely accepted;

arbitrary assumptions for
risk target alloc ation to
sub-systems (share in
system overall risk)

The approach of assigning a monetary

value to prevented fatality/injury is not
acceptable in s ome c ountries.

MEM

5787
5788

B.1.

ALARP (As Low As Reasonably Practicable)

5789
5790
5791
5792

ALARP means As Low As Reasonably Practicable and refers to a legal duty to reduce risk.
The ALARP principle originally arose as a legal requirement in the UK. It imposes a relative
duty, stating that the duty holder must apply any safety measures that will reduce risk ALARP.
The judgement of whether or not a particular control is ALARP is based on a comparison of the

prEN 50126-2

- 54 -

5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805

net costs, taking account of any commercial benefits, with the extent of risk reduction of any
safety measure/safety requirement under consideration.
In reality, the application of established good practice, including formal codes of practice, can
often be considered to be a suitable demonstration that risk is reduced ALARP. However in
some cases there is a need to undertake the analysis of costs and benefits more formally, for
example via quantified risk assessment and Cost Benefit Analysis (CBA). Clear guidance on
how to make ALARP judgements and undertake ALARP CBA is included in the publication
Taking Safe Decisions (RSSB, 2008, http://www.rssb.co.uk/).
Important points to note are that:
The ALARP principle considers the change in risk and the net cost of a control measure.
Therefore the risk being considered may relate to a range of hazards, affecting a range
of people to some extent. ALARP therefore uses collective risk estimates, and is applied
to control measures;

5806
5807
5808

The ALARP principle does not take into account absolute risk levels or considerations of
the tolerability of risk. It is purely based on a comparison of the costs of a measure with
the risk reduction is achieves;

5809
5810
5811

The ALARP principle is the main criterion for establishing whether or not a safety
measure is required. However there are alternative criteria which can be usefully
considered to support judgements. These are:

5812
5813
5814
5815
5816

The residual level of risk on a railway, which can be used as a benchmark of the
acceptability of an absolute level of risk calculated;
The totality of fatality risk to which a particular category of individual is exposed. This
may be set by the regulator and is unlikely to be relevant when all ALARP
measures have been applied on a railway project.

5817

B.1.1. Application of the ALARP principle to a project (duty holder)

5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832

Part of the philosophy of the ALARP principle is that safety risks should have a proportionate
amount of time, trouble and effort applied to them. Therefore when hazards are identified at the
start of a project it is sensible to rank them using a qualitative or semi-quantitative matrix. This
allows the hazards to be sorted in order of the relative scale of the risk they present.
Subsequent attention, consideration and analysis is undertaken in proportion to the risk ranking.
It may be determined at this stage that hazards classified with a low level of risk do not require
further consideration. In such cases, a rationale for this position should be documented.
Figure B.1 shows an example of a qualitative risk matrix for use within an ALARP framework.
This matrix might be more suitable for application by a system designer who is dealing with
hazards at the boundary of the system under consideration. Figure B.2 shows an example of a
semi-quantitative risk matrix, for use in cases where data is available or a good degree of
judgement can be applied to estimates of the frequency and consequences of each hazard. This
type of matrix would be more suitable for use by a railway duty holder in order to develop the
requirements of a particular project. Note that neither of the matrices includes 'tolerability' or
acceptability criteria for hazards as:

5833
5834
5835

ALARP acceptance criteria are based on evaluation of the various options and their
impact on cost and safety risk, not the absolute level of safety risk associated with
individual hazards;

5836
5837
5838

Ultimately the acceptability of the hazard risk, in absolute terms is a function of the size
of the railway, the number of trains it runs etc and cannot be evaluated on a hazard by
hazard basis without consideration of this2) .

2) On a given project the railway duty holder might choos e to develop a matrix with defined acceptanc e criteria based
on the size of the project to c ascade to their suppliers. However these criteria would need to be set with an
awareness of the overall ALARP criteria, and the supplier would need to c onsider thes e criteria as inf ormative,
and exc eed them in areas where informed c onsideration of ALARP criteria required this

- 55 -

Frequency Band
A
Frequent
B
Probable
C
Occasional
D
Remote
E
Improbable
F
Incredible
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848

prEN 50126-2

Severity Band
3
2
Critical
Marginal
High
High
High
Medium
Medium
Medium
Medium
Low
Medium
Low
Low
Low

4
Catastrophic
High
High
High
Medium
Medium
Medium

1
Minor
Medium
Medium
Low
Low
Low
Low

Figure B.1 - Example of simple qualitative risk matrix for use within an ALARP framework.
As these matrices are used for ranking and comparing the risk of different hazards, for the semiquantitative approach in particular, the matrix must be calibrated so that relative risk of different
hazards is preserved across the various risk classifications. In the example of Figure B.2 this is
achieved by having the same factor difference (a factor of 5) between each frequency and
consequence category. The rankings are then added rather than multiplied. Following this
approach it can be seen that hazards ranked as the same risk category equate to similar levels
of risk regardless of the particular frequency or consequence category.

frequency

multiple
fatalities

multiple major
/single fatality

major injury

once in

no/year

0.005

0.025

0.125

0.625

3.125

12 days

31.25

10

2 months

6.25

9 months

1.25

4 years

0.25

20 years

0.05

NOTE 1 fatality
5849
5850
5851
5852
5853
5854

minor injury

severity

multiple minor
injuries/more
severe injury

severity
average equivalent fatalities per hazard

10 major injuries

200 minor injuries

Figure B.2 - Example of semi-quantitative risk matrix for use within an ALARP framework
Throughout the remainder of the project the various design options and safety requirements are
considered and adopted according to the ALARP principle. Codes of Practice are applied where
this can be justified. Where there are no formal Codes of Practice, or other established good
practice, the duty holder must decide what options are available and evaluate, in a qualitative or

prEN 50126-2

- 56 -

5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870

quantitative sense, what the costs and benefits of each are. If the costs of a measure are judged
to be disproportionate to the safety benefits, taking into account any uncertainties in the risk
estimates then the measure is judged to be ALARP. A Value of Preventing a Fatality (VPF)
figure is used to translate the change in risk to a financial value to allow comparison. Evidence
that such options have been considered and solutions which reduce risk ALARP adopted forms
the key component of any subsequent safety demonstration.
The residual risk estimated from all hazards can be aggregated and compared with any
available data on the safety performance or residual risk of the railway to benchmark the
expected safety performance with that of the current railway. Such a comparison will need to
take into account the scope of the project and any change in the amount of railway activity
resulting from it. For example if the number of trains using a section of the railway increases as
a result of a project then it is not sensible to expect that the same absolute level of safety will be
achieved. Note that this comparison only provides a sense check. Even if the absolute, residual
level of risk has increased as a result of a project, the risk will still be acceptable if there is
sufficient evidence that all ALARP measures have been applied.

5871

B.1.2. Tolerability and ALARP

5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883

A risk may be deemed to be tolerable, but if there are reasonably practicable measures which
can be adopted to achieve further reduction in the risk it cannot be considered to be ALARP
until these measures have been adopted.
The ALARP principle is not generally applied to risks that are comparable to those that people
regard as insignificant or trivial in their daily lives, typically risks from activities that are
inherently not very hazardous or from hazardous activities that can be, and are, readily
controlled to produce very low risks. In such instances it would be disproportionate to seek
further reduction in risk.
It is conceivable that a risk might be both ALARP and intolerable, i.e. even when everything that
is reasonably practicable has been done the residual risk remains at an intolerable level. In such
a case the activity responsible for generating the risk should not be permitted.

5884

B.2.

5885

B.2.1. Principle

5886
5887
5888
5889

The GAME approach is legally required in France. Some other countries use parts of the
application described as well.
The principle reads as follows:
any new guided public transport system/subsystem or

5890
5891

any modification of an existing system/subsystem must offer a level of risk globally at

least equivalent to the one offered by a similar system (accepted as a reference system).

5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905

To achieve this level, the system or modification must be designed and carried out so that the
overall level of safety for users, operating staff and third party 3) is at least equivalent to the
safety level of existing systems providing similar services.
This formulation takes into account the experience of the past and requires that the safety
performance of the projected system is not worse than those of similar systems (reference), by
the phrase at least. It does not consider safety at a particular risk level, but at the global safety
level of the studied system/subsystem, by using the requirement globally. The transport
system supplier is free to allocate risk portions to subsystems within the system or between
similar risks and applies the relevant approach, i.e. qualitative or quantitative (depending of
the type of failure that lead to the hazard. For example, a quantitative analysis could be useful
to evaluate the failure rate of an equipment item but could not be relevant for a hazard due to a
human factor).
When applying GAME principle both collective and individual risks should be taken into
consideration.

Globalement Au Moins Equivalent (GAME) principle

3) third party could be residents, pedestrians, external workmen/employee or emergency staff (policemen, firemen,
medical staff...) who c ould be present in particular circumstances

- 57 -

prEN 50126-2

5906

B.2.2. Using GAME

5907
5908
5909
5910
5911
5912
5913

GAME principle can be used in different ways for different purposes. This sub-clause explains
the different ways in which GAME can be an effective and efficient approach to assess the
acceptability of risk associated with a certain system.
Basic principles
There are a few important prerequisites for applying GAME:
the system under consideration can be compared to an equivalent or similar (with
respect to application) reference system;

5914

a clear system boundary can be defined for both new and reference systems;

5915
5916

the properties relevant to the risks considered are known for both the new as well as the
reference systems;

5917
5918

any differences in properties need to be compensated in the setting of risk targets or in

demonstration of compliance.

5919
5920
5921

The GAME demonstration shall be done through:

a systematic approach to safety that allows to identify hazards for the overall system and
to define the requirements which have to be fulfilled;

5922

the proof that each hazard is prevented by barriers or lessened by mitigations;

5923
5924

the proof that each barrier and mitigation is effective regarding the corresponding
hazard;

5925
5926

the proof that the reference system is considered acceptable in respect of safety
(otherwise, this system cannot be taken as reference);

5927
5928
5929

a relevant safety management process (based on recognized and relevant standard)

intended to record, manage and control the hazards (and their corresponding barriers or
mitigations) and the requirements that have to be fulfilled.

5930
5931
5932
5933
5934
5935
5936

Using GAME to construct a qualitative safety argument

In some cases a qualitative argument can be used to demonstrate compliance using the GAME
principle. If GAME is used in this way it is very important to establish and demonstrate that the
application conditions for both systems are identical. Any differences in application conditions
need to be scrutinized for a potential to:
introduce new hazards;

5937

affect the probability of occurrence of known hazards;

5938

extend the consequences of known hazards.

5939
5940
5941
5942
5943
5944
5945

Using GAME for setting quantitative risk targets

Another way of applying GAME is for setting quantitative risk targets. This can be done on any
integration level in the railway system (both for a complete railway system and for a subsystem).
The reference will always be the contribution from the system to the risk of the complete railway
system.

prEN 50126-2

- 58 -

5946

B.3.

Minimum Endogenous Mortality MEM

5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961

MEM is a method to derive absolute values for risk acceptance based on the natural death rate
of human beings of specified young age.
MEM is an approach with predefined assumptions and is based on the work of A. Kuhlmann in
Germany in 1981. The MEM criterion allocates the same risk to an individual, independent of
any technical system. This homogeneous allocation needs to be justified if MEM criterion is
used.
For more comprehensive explanation of the MEM principle see bibliography. Following
paragraphs give a summary of that paper.
MEM incorporates the lowest natural death rate and uses this to assure that the total additional
technical risk for an individual does not exceed a value equivalent to this natural risk. The
natural death rate is focusing only on natural causes of death without any kind of accidents and
native malformation influences.
In the range between 5 years and 15 years of age for humans, the natural death rate (R m) in
industrial developed states reaches a minimum for human individuals:
R m = 2 x 10 -4 fatalities / (person * year)

5962
5963
5964

The MEM requirement states that the additional overall hazard death rate caused by technical
systems (Rt ) shall not exceed this limit:
Rt Rm

5965
5966
5967

and each single system shall not contribute more than 5 % because each individual is
endangered by n different technical systems in parallel; the assumption in the MEM principle is:
n 20

5968
5969
5970

It means that a single technical system shall not lead to a risk of fatality (R) of a single person
with a rate of:
R 10 -5 fatality / (person x year)

5971
5972

Because accidents with a high number of fatalities are not accepted, MEM introduces a factor
"differential risk aversion" (DRA), which results in the following curve.
Tolerable
Individual
Risk

10 -3

10
Fatalities
person* year

-4

10

-5

10

-6

10

Minimum Endogenous Mortality

-7

10 -8
10

-9

10 -10
10 0

5973
5974
5975
5976

10 1 10 2 10 3 10 4
Number of fatalities

10

10 6

Figure B.3- Differential risk aversion

For MEM calculation the relationship between fatalities, major injuries and minor injuries is
given by:

5977
5978
5979

One fatality = 10 major injuries = 100 minor injuries (major injuries

people disabled)

EXAMPLE An accident with 2 major injuries and 40 minor injuries will corr espond to 2/10+40/100 = 0,6 equivalent
fatalities.

5980
5981
5982

This calculation may also be used when other principles are applied.
The principle does not define what a system is. Since the criterion is based on fatalities it is
especially applicable for systems that directly affect human health. It can be interpreted that no

- 59 5983
5984
5985

prEN 50126-2

more than 20 systems impose fatal hazards on a specific group of people at the same time.
Therefore this method can be used to assess these hazards separately since none of them is
allowed to increase the mortality rate significantly.

prEN 50126-2

- 60 -

5986

Annex C (informative) Using failure and accident statistics to derive a THR.

5987
5988
5989
5990
5991
5992
5993

THRs cannot be calculated from accident statistics unless rigorously collected statistics and
models are available. However, even if such models do not exist the use of such statistics can
be a part of the process of reaching an informed judgement of the level at which to set THRs.
Railway network statistics and data can be used to determine sensible THRs in some
circumstances. This can be done, as is current practise in the UK, by:
Reviewing the frequency of occurrence of functional/technical hazards across the railway
network;

5994
5995
5996

Using this information, and information on the number of units installed across a given
scope of railway to calculate average failure rates per unit in that given area (e.g.
national rail network, or part of it);

5997
5998
5999

Reviewing safety accident and incident rates to estimate the residual risk on the network
from such functional hazards and, by implication, whether the current functional hazard
rates are acceptable.

6000
6001
6002
6003

The failure rate for a given railway system per operational hour can be estimated by:
hour per unit = year /(hours year * number of units).
For example if we assume that:
a national railway has 60,000 track circuits on its network;

6004
6005

on average 6 of these fail wrongside i.e. in such a way that they do not indicate when
they are occupied, in any given year; 4)

6006
6007

Each track circuit is operational for 19 hours per day, 365 days per year (6.935
operational hours per year).

6008
6009

Then:

6010
6011
6012
6013
6014
6015
6016
6017

However to understand whether or not this functional hazard rate is acceptable for adoption as a
THR there needs to be some understanding of whether or not the residual risk associated with it
is acceptable. This would be based on a review of the accident statistics over a number of years
to determine whether a hazard of this type had led to any accidents. If over a reasonable period
the hazard had resulted in no accidents then there could be a conclusion that the rate of failure
was acceptable, given the other risk controls that are in place and circumstantial factors. If a
number of accidents had occurred then investigation of whether the hazard, and other barriers
that might be relevant, were relevant to their occurrence might form part of the judgement.

hour

per unit =6/(6935*60,000) = 1.4E-08 failures per hour.

4) this calculation does not need to include a mean time to repair if it is assumed that each failure would be detected
when the next train arrives at the track circuit, so that it could be assumed that, for every failure, there would be a
similar opportunity for an accident to arise).

- 61 -

prEN 50126-2

6018
6019

Annex D (informative) CoP on maintenance activities to preserve the safety

integrity of non-E/E/PE systems

6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032

In order to preserve the built-in safety integrity over the lifetime, maintenance measures have to
be defined, e.g. proper preventive maintenance according to a maintenance plan.
The preventive maintenance measures may vary from system to system, but the following
examples may give a non exhaustive impression.
Normal servicing: oiling, greasing, cleaning, providing necessary agents, visual checks about
wear, damage or dirt, measurement of parameters for condition monitoring, operational tests,
etc.
Functional testing (periodic proof checks): The main purpose of such tests is the detection of
latent failures. This is particularly important for systems or functions which are not used
permanently, for systems containing redundant structures, and for protection functions operating
on demand in case of other failures.

6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052

Special testing: Not all latent failures can be detected by functional tests. Special tests using
methods like ultra sonic, x-ray, insulation measurements etc may be necessary to monitor the
condition of safety-related systems and detect any deterioration before a critical failure can
occur. Such special tests are common practice for structural elements which could lead to
severe consequences in case of failure (e.g. wheels, axles, bogies, car body shells, high voltage
insulators, protective earth)..
Overhaul or replacement: Depending on the condition of the system or component, (wear,
deterioration, damage) it may be necessary to overhaul or replace the system or component as
a preventive maintenance activity.
Systems which are highly important to safety, i.e. with severe consequences in case of failure,
should be replaced or overhauled before they are worn-out, and in case of damage.
For systems which are less important to safety, because the consequences of failures would be
less severe, e. g. systems with redundant structures, the decision for replacement or overhaul
may be based on condition monitoring on selected items of a fleet or a large system. The
overhaul or replacement of subsystems or components will be taken when the monitored
samples show signs of wear or deterioration.
For systems which have only very low or no importance to safety (because of the insignificant
consequences of failures), it could economically be reasonable to overhaul or replace them only
in case of failure. For this maintenance strategy, the insignificance for safety must be justified.

6053

A maintenance plan shall be created and shall comprise the following information:
maintenance actions and intervals;

6054

EXAMPLE: periodic proof check of the fire detection system by means of heat stimulus to confirm the c orr ect
operation of the temperature s ensors and switches.

NOTE This is also called "reliability c entred maintenance (RCM). See IEC 60300-3-11 Ed. 2.0.

6055

infrastructure requirements;

6056

tools;

6057

manpower;

6058

spare parts;

6059

qualification or training of the maintainers.

6060

The maintenance actions and intervals shall consider the requirements of

6061
6062

the supplier of the system (defined in the maintenance manual and in safety-related
application conditions);

6063
6064

the system integrator (defined in the maintenance manual and in safety-related

application conditions);

6065
6066

the operator (planned operation and maintenance intervals, availability requirements in

the contract);

6067

the maintainer (available infrastructure, staff).

prEN 50126-2

- 62 -

6068
6069
6070
6071
6072
6073

If an operator or maintainer intends to alter the maintenance activities, he has to perform the
risk assessment for the planned changes and to ensure that at least the same level of safety
can be maintained. The operator and maintainer are responsible for the maintenance activities
and for the consequences arising from alterations in the maintenance activities and intervals.
Therefore, it is recommended to agree changes with the relevant suppliers and with the
competent safety authorities.

6074

Table D.1 Measures to achieve the necessary safety integrity of non-E/E/PE systems
activity/design practice
Activities/features during design/manufacture
Independent technical verification
Calculations, tests, simulations, verifications
De-rating
Full assembly and wear tolerance analysis
QA inspection on all parts or on samples
Full functional tests on first production (type test)
Full functional test on each item produced (routine test)
Fault simulation testing (usually as part of the type test)
Environmental testing (type test)
Life testing/accelerated life testing (type test)
Overstress testing (type test)
Corrosion testing (type test, but also part of routine test / inspection)
Maintenance activities
Maintenance plan
Normal servicing
Functional testing (periodic proof checks)
Special testing
Overhaul or replacement
Regular condition monitoring on sample of population or on each item

6075
6076

NOTE

The content of this table (specifically the design activities) may also be partly applicable f or E/E/PE systems.

- 63 -

prEN 50126-2

6077

Annex E (informative) Apportionment methods

6078
6079
6080
6081
6082
6083

In this annex, examples of methods for apportionment are provided. These examples are not to
be considered as exhaustive, and do not provide any evaluation on the correctness /
applicability (or not) of other methods.
Furthermore, this annex concentrates on examples using fault trees. There are methods
applicable for Markov graphs as well, or for other representation.
The main aspects to assess the method that can be used are:

6084

validation of the method itself (is the method recognized and proven correct?);

6085

internal validation of its application (is the method applicable in the system);

6086
6087

external validation of the method in the project (approval from the authority / client
depending on the contract)

6088

E.1.

Goal

6089
6090
6091

The goal of a risk apportionment activity is to be able to break down the safety targets
determined at the level of a system to the lower levels, i.e. onto sub-functions and subsystems,
and when necessary between the different actors (e.g. suppliers, sub-contractors).

6092

E.2.

6093
6094
6095
6096
6097
6098

The first step of the apportionment method is to analyse the different contributors to the studied
hazards, and to check whether the sub-elements are independent.
Independence has to be ensured both in terms of random and systematic aspects of failures.
In the following example, B is a function of the system under consideration (itself composed of 2
sub-functions) that is combined with another function C and integrated into a higher level
function A.

Analysis of the system

Higher level Function

(A)

System under
consideration

And
Function (B)
Function (C)
And
Failure of
subfunction
(B1)
6099
6100
6101

Failure of
subfunction
(B2)

Figure E.1 Functional breakdown

Then the independence between each function is analysed with the following result:

prEN 50126-2

- 64 hazard (A)

& is valid when functional

independence between items (B and C)
can be proven

&

failed barrier /
technical hazard
caused by
another
functions failure
(C)

failure of
function (C)

6102
6103
6104
6105
6106
6107
6108
6109
6110
6111

technical hazard
(B)

failure of function
(B)

&
failure of
subfunction
(B1)

& is not valid for

systematic failures then
functional
independence between
items at lower level (B1
and B2) cannot be
proven

failure of
subfunction
(B2)

Figure E.2 analysis of the scenario: functional independence

In this example, functions B and C are independent, while sub-functions B1 and B2 are not.
This means that B and C can be allocated separate requirements both for systematic and
random failures, while B1 and B2 can only be allocated different random failures requirements
(e.g. TFFR), the systematic failures requirements for B1 and B2 will be those of B.
An apportionment below level B may only be possible in terms of random failures, but not in
terms of systematic failures.
The random failures apportionment continues as described in the following sub-clauses.

6112

E.3.

Apportionment

6113

The apportionment can be made in 3 ways:

6114

qualitatively;

6115

quantitatively;

6116

mixing qualitative and quantitative data.

6117

E.4.

Example of qualitative methods

6118
6119

Example of qualitative apportionment with fault tree

- 65 -

prEN 50126-2

6120
technical hazard (A)

When independence
between items (B and
C) can be proven
barrier
availability

Tolerable Hazard
Rate (THR)

&

independent barrier
/ technical hazard
caused by another
function failure
(C)

Tolerable
Functional
Failure Rate
(TFFR)
technical hazard (B)

failure of function (B)

failure of
function (C)

6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133

Figure E.3 1 st step of apportionment: analysis of the system

At the level of (A), a THR is allocated. This THR is allocated from the accident possible
consequences, taking into account existing barriers (reducing the severity and/or frequency of
the accident).
This THR is then apportioned between sub-levels into lower levels TFFR.
When a level is identified as the lowest level where independence can be proven, then a SIL
can be allocated. This SIL will then be allocated to the lower levels, and cannot be apportioned.
If a function (e.g. C in our example) is a barrier, then the barrier availability needs to be
identified and treated as a safety-related application condition for the system under
consideration (B), in order to check whether the barrier risk reduction will occur in all cases, or if
it is dependent on a specific context. This can be evaluated through qualitative method,
eventually guided by a semi-quantitative set of guidelines (see Annex F).

6134

E.5.

6135
6136
6137
6138

The quantitative method allows for more precise apportionment of a safety target to sub-levels.
It is the most cost effective in terms of design, as it allows for less safety margins.
It however depends on:
the adequacy of the hypotheses taken during the calculation, and

6139
6140

the experience gained on similar reference systems already in service (to validate the
feasibility and adequacy of an apportioned target)

6141
6142
6143
6144
6145
6146

Example of quantitative methods

It is important to export the maintenance action to be taken into account.

Example of quantitative apportionment with Fault Tree
When dealing with probabilities, the following formulas apply for the apportionment:

probability to be apportioned

apportioned probabilities

probability to be apportioned

apportioned probabilities (contribute in AND)

(contribute in OR)

6147
6148

Apportionment through an OR gate is done ensuring the sum of the apportioned failure rate or
probabilities remains inferior or equal to the target.

6149
6150
6151
6152

Apportionment through an AND gate of of rates, requires to make assumptions on the

safe down time. The equivalent lambda of an AND-GATE between B and C would be
(SDTB SDTC ) , therefore when apportioning B and C , a conservative
B
C
assumption on the values of SDT B and SDT C should be made.

6153

It is important to ensure the maximum probability or equivalent failure rate is apportioned.

prEN 50126-2

- 66 -

6154
6155
6156
6157

The maximum probability is achieved at the smallest common multiple of safe down times (thus
where the probability of failure is the highest for each individual component).
An example of apportionment could be the following:
C has a safe down time of 12 hours, i.e. SDT C =12h

6158
6159

B has a safe down time of 15 years (assuming 15 years with 300 days per year use),
SDT B = 12 x 300 x 30 / 2 = 5000h

6160
6161
6162

If we apply this method to a case where the top-level THR is 10 -9 / h, one possible
apportionment could be the following.
-14
10 -9 / h = C x B x (54000 h + 12 h)
/ h
C x B = 1,85 . 10

6163
6164

The following apportionments could thus be made:

-7
/ h and C = 10-7 / h
B = 1,85 . 10

6165
THR = 10-9 / h

hazard (A)
&

10

6166
6167

-7

failure of
function (C)

failure of
function (B)

10 -7

Figure E.4 Example of quantified apportionment

- 67 -

prEN 50126-2

6168

Annex F (informative) Safety Target Quantification Methods

6169
6170
6171
6172
6173
6174
6175
6176

The overall model to be considered for combination of two independent functional failures
leading to an hazard is given in the following.

6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187

Taking a brief look at two repairable items, which are usually defined by their failure and repair
rates, and a closer look at AND combinations a different interpretation of the repair rates (or
equivalent repair times) is necessary. Usually after a fault within an item has appeared, at least
two things have to happen in order to get the item working again:
The fault has to be detected and negated (this means a safe state has to be entered).
The item has to be repaired and restored.
With repair and restore time the logistic time for repair after detection, actual repair time (fault
finding, repair, exchange, check) and time to restore equipment into operation is meant. While in
a reliability context usually the detection time is neglected, this time becomes important in the
safety context. Safety-critical applications may not rely on self-tests or similar measures, but the
detection and negation has to be performed independently of the item. Sufficient failure
detection and negation mechanisms should be demonstrated in the safety case.
In a safety context generally the actual repair and restore time can be neglected, if other control
measures are taken during this period. In this case the repair rate from reliability analysis can
be interpreted as the detection and negation time, here defined as safe down time (SDT) or
equivalent safe down rate (SDR).

Fault

Restore

Detection

Negation
6188
6189
6190
6191
6192
6193
6194

Figure F.1 - Interpretation of failure and repair times

Modelling the composition of two independent items in an AND-gate the following basic formula
for the (asymptotic) tolerable hazard and detection rates for highly available systems can be
used, assuming that the rates are constant over time:

THRS
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205

FR A
SDRA

FR B
SDRB

SDRA

SDRB

SDRS

SDRA

SDRB
(A1)

where the FRs stand for potential hazardous Failure Rates.

If periodic testing times are used as detection times, then (A1) may be used with mean test
times:
T/2+negation time =SDT=1/SDR.
(A2)
This means that in order to use AND combinations properly each item shall have an
independent failure detection and shut-down mechanism. If an item does not have such
mechanism, then the installed lifetime of the item has to be taken into account.

prEN 50126-2

- 68 -

6206
6207
6208
6209
6210
6211

Another aspect, which has to be taken into account in the design, and in fact limits the free
choice of parameters is the availability of the system.

6212
6213

System architecture and operational context (including external barriers assumptions /

application conditions);

6214

Failure rates (or on demand probabilities);

6215
6216

Safe Down Time (maximum time that can occur between a failure potentially dangerous
if combined with others and a safe state to be reached).

The goal of safety target quantification is to be able to demonstrate the conformity to a safety
target combining the functions that participate in the hazard.
The inputs for this work are:

6217

F.1.

Safety Target Quantification

6218
6219

The verification can be made in 3 ways:

Quantitatively;

6220

Qualitatively;

6221

Mixing qualitative and quantitative data.

6222

F.2.

Example of quantitative methods

6223
6224
6225

The quantitative method allows for more precise knowledge of functions safety performances. It
is the most cost effective in terms of design, as it allows for less safety margins.
It is however highly dependent on:

6226

The adequacy of the hypotheses taken during the calculation;

6227

And the experience on previous systems (to validate the failure rates used in the study).

6228
6229
6230

The quantitative verification can be made through various methods. It is however important not
to forget the impact of maintenance, as the lower the maintenance is, the more reliable/safe an
item needs to be in order to maintain the same level of overall availability.

6231

F.3.

6232
6233

Before quantifying, here are the steps to be checked as precondition to ensure the results will
be valid:

6234
6235

Check that the hypotheses taken for each component are valid as well for the system in
which the component integrates;

6236

Check that the environment is compliant with all components (temperature, EMC, );

6237
6238
6239

Check that the operational environment considered for each component is compliant with
the operational environment considered for the system as a whole (using time, powered
time, number of solicitations, );

6240
6241

Check that the operational conditions are really applicable, and will be applied
(reference to the appropriate operation/maintenance documentations).

Validity of the safety target quantification

6242

F.4.

Example of quantitative verification with Fault Tree

6243
6244
6245

If one regards a system that implements the function of generating a command based on the
independent calculations of two channels A and B, i.e. a two-out-of-two system with an
identified common cause failure (e.g. power supply).

- 69 -

prEN 50126-2

failure of function
F

common cause Failure

double channel failure

caused by independent
channel failures

CCF

DCF

&

failure channel
A

failure channel
B

check

6246
6247
6248

check

Figure F.2 - Double channel failure with common cause

Thus one can apply the formulas stipulated in IEC61025 and IEC61165:
A

ACheck

BCheck

ACheck

6249

BCheck

CCF

6250

F.5.

6251
6252
6253
6254
6255
6256
6257
6258
6259

The equivalent failure rate is used for a generic system where more than two functions failures
are necessary to trigger an hazard.
The calculation for an equivalent lambda (failure rate) uses the following inputs for each
elementary event: failure rates and safe down times.
Note that when an equivalent lambda is calculated, an equivalent safe down time needs also to
be defined (see formulas below).
The formulas below, based on a linear approximation of the exponential distribution, are only
valid if
eq x SDT eq << 1

6260
6261

The formulas used are the following:

for an OR gate:

6262

Formulas for safety target evaluation

eq

( i Ti)
6263
6264

T eq =
for an AND gate:

i Ti
6265

eq max

1
Ti

prEN 50126-2

1
2i 1
eq average =
1
1
Ti
T eq =

6266

6267
6268
6269
6270

6273

eq

T1

T eq =

1
Ti

T2

for an AND gate:

6274

eq max

6275

6276

i Ti

These formulas can be simplified when only 2 events are combined in the following way:
for an OR gate:

6271

6272

- 70 -

eq average

(T1 T2 )
2

(T1
2

T2 )

T1 T2
T T2
T eq = 1

6277
6278

F.6.

Example of qualitative method (assessment of barriers availability)

6279
6280
6281
6282
6283
6284
6285
6286
6287

The qualitative method allows for faster verification than quantitative method to the detriment of
precision (thus impeding optimisation of safety/reliability vs. cost).
This method is generally best used to deal with events whose consequences lead to low risks
(where therefore it does not appear necessary to spend too much money on the study).
The qualitative method will generally concentrate on the cut sets (how many failures are
necessary to lead to the incident?), and on expert judgment (based on a not always statisticdriven return of experience).
It is important to note that for an expert judgement to be valid, the following steps should be
ensured:

6288

The judgment is not done by a single person, but via:

6289
6290
6291
6292

a group of experts (collective argument);

and/or on documented arguments (e.g. from a supplier).
The judgment uses as much as possible returns of experience (with however proper
caution => is the data applicable in that use?)

6293
6294

An example of qualitative verification can be the following:

Expert judgement on the components failures / LRU (E F )

Value

The component has never failed in the lifetime of previously existing s ystems using this
component

E FI

A few failures occurred during the lifetime of previously existing systems using this
component (less than one per system)

E FII

At least one failure occurred during the lifetime of each system using this component

E FIII

At least one failure occurred each year for the systems (less than one per s ystem)

E FIV

- 71 -

prEN 50126-2

At least one failure occurred each year for each system

6295
6296
6297

E FV

NOTE E F = 1 is considered an impossible value for most components. In most cases, the only c omponents that may
achieve this value are mechanic al components which are replac ed via a criteria-bas ed preventive maintenanc e (thus,
no failure ever occurs, since the component is changed bef ore it can fail
e.g. bogies)

6298
Expert judgement on the components knowledge / LRU (EK)

Value

The component / LRU is widely used in the company

E KI

The component / LRU is used in the c ompany, but not in important applications (high safety
/ reliability expectations)

E KII

The component / LRU is not us ed in the company, but is a replac ement for a component
used in the c ompany

E KIII

The component / LRU is not us ed in the company, and not known

E KIV

6299
Expert judgement on the use of the component / LRU (EU)
The component / LRU is already us ed the same applications

Value

EUI

The component / LRU is not us ed the s ame applic ations, but in similar ones (e.g. not in the
same function, not in railway application but in airplanes, ) => similar constraints on the
component / LRU

EUII

The component / LRU is not us ed in the railway or in similar applications (e.g. constraints
are too different)

EUIII

6300
Expert judgement on the maintenance (EM )

Value

The component / LRU is to be tested daily, and the system is not authorized to be us ed
bef ore repair

EMI

The component / LRU is to be tested online, but the repair can be postponed to a week
(maximum)

EMII

The component / LRU is to be tested, but the repair can be postponed to a month
(maximum)

E MIII

The component / LRU is to be tested, but the repair can be postponed to 6 months
(maximum)

E MIV

The component / LRU is to be tested, but the repair can be postponed to a year (maximum)

EMV

The component / LRU is to be tested, but the repair can be postponed to mid-life of the
system (maximum)

E MVI

The component / LRU is not tested, no repair is needed in the lifetime

E MVII

6301

NOTE in this table, Y is the number of years the system is suppos ed to operate before refurbishment

6302
6303
6304

These different criteria will then be combined to provide a components efficiency. This
combination is generally made through a multiplication:
E = E F x E K x E U x EM

6305
6306

It is then necessary to combine the efficiencies of different components / LRUs. This is generally
done through the following formulas (given independence between the components / LRUs):

E
6307

For an OR gate:

6308

For an AND gate:

6309
6310

E 1

1
1
Ei

1 Ei

prEN 50126-2

- 72 -

6311

Annex G (informative) Common mistakes in quantification

6312

Here are some common misuses in quantification methods which can lead to erroneous results:

6313

G.1.

6314
6315
6316
6317
6318

This mistake often comes from the use of constant failure rates components, and associated
probability laws. This is typically the case when using the exponential law which does provide
this constant failure rate simplification.
Calculating a failure rate for a system using only the failure rates of the components (thus not
using any safe down time) will generally largely overestimate the safety of the system:

Mixing failure rates with probabilities

command not
transmitted to the
engine
Pr(10) = 1.00e-11
G3

transistor does not convey

the command (no passage
from the collector to the
emitter)
exponential 1e-7;

Relay does not convey the

command (blocked in non
powered position)
periodic-test 1e-6 10 0;
R1

T1

6319
6320
6321
6322
6323

Using the example provided above, if I simply multiply the failure rates (10 -7 / h x 10 -6 / h), it is
obtained 10 -13 / h, and the unit is no longer correct (/h x /h = /h).
The formula used for AND gates where a multiplication is used is only valid for a probability
(thus a failure rate multiplied by a time).

6324

G.2.

6325
6326
6327
6328
6329
6330

An example of mistake is the use of the equivalent lambda when the failure rate is high (close or
higher than 1/h), and/or when the safe down time is very long (e.g. the failure cannot be
detected
safe down time = system lifetime).
In such cases, where eq x Teq << 1 is not valid, the results will be wrong (error not negligible
with respect to the analytic models, i.e. integral of probabilities density functions over their safe
down time).

Using formulas out of their range of applicability

- 73 -

prEN 50126-2

6331

Annex H (informative) Techniques / methods for safety analysis

6332
6333
6334

The following tables provide a non-exhaustive overview for various techniques and methods
used during the phases of the life-cycle. More details are to be found in the corresponding IEC
standards.

6335

Table H.1 Techniques / Methods for safety analysis

Technique/M ethod

Hazard
identification

Safety requirements /
iazard analysis

Safety
demonstration

Reference to IEC
standard

for preliminary
purposes

useful for preliminary

hazard analysis and for
identifying and ranking
hazards for further
detailed analysis.

possible for
recording rationale
for not performing
further detailed
analysis for low
ranking hazards

useful

partially useful as
supporting element.

61882: 2001

useful

useful for parallel

structures in addition to
ETA

Useful for single and

parallel structures in
addition to FTA and
for causal analysis

60812:2006
Analysis
techniques for
system reliability
Procedure for
failure modes and
effects analysis
(FMEA)

sometimes useful to
visualize
consequenc es of a
(sub-) system f ailure

IEC 62502:2010 Analysis

techniques for
dependability Event tree
analysis (ETA).

useful for multiple

structures, causal
analysis

IEC61025:2010
Analysis
techniques for
system reliability
Fault Tree
Analysis.

complementary and
often s olved with a
FMECA. Also
needed to justify
AND-gates in FTA

Markov

useful especially for

modelling states and
fault sequences (in
particular when FTA is
not applic able)

useful especially for

modelling states and
fault sequences (in
particular when FTA
is not applic able)

61165:2006

RBD

useful as a support to
HAZOP and FTA

61078:2006

technique shall be
calibrated according to a
clearly defined risk
acceptance criterion and
applied to a clearly
defined s ystem level

IEC 61508 part 5

Annex E

RRA
Rapid Ranking
Analysis;
Hazard Ranking

HAZOP
Hazard and Operational
Analysis
FMECA
Failure Mode, Effects
and Criticality Analysis

ETA
Event Tree Analysis

FTA
Fault Tree Analysis

CCF
Common Caus e
Analysis

Reliability Block
Diagram
risk graph