Railway RAMS Process and Life-Cycle Stages

-1-
prEN 50126-1
1
2
Project number:
prEN 50126-1
3
4
5
6
Railway Applications - The Specification and Demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)
Part 1: Generic RAMS Process
Applications ferroviaires Spcification et dmonstration de la fiabilit, de la

disponibilit, de la maintenabilit et de la scurit (FDMS)
Partie 1: Processus FMDS gnrique
Bahnanwendungen - Spezifikation und Nachweis von Zuverlssigkeit, Verfgbarkeit,

Instandhaltbarkeit und Sicherheit (RAMS)
Teil 1: Generischer RAMS Prozess
7
8
9
10
11
12
13
prEN 50126-1
-2-
14
15
Table of content
Foreword ..............................................................................................................................7
16
Introduction ..........................................................................................................................7
17
Scope ............................................................................................................................9
18
Normative references .....................................................................................................9
19
Terms and definitions ...................................................................................................10
20
Abbreviations ...............................................................................................................20
21
Process overview .........................................................................................................21
5.1 Purpose of overview ............................................................................................21

5.2 Objective .............................................................................................................21
5.3 Management responsibility...................................................................................21
5.4 Adaptability to project scope and size ..................................................................21
5.5 Interrelation of RAMS management process and life-cycle ....................................22
5.6 Short description of life-cycle phases ...................................................................24
Railway RAMS..............................................................................................................25
Introduction .........................................................................................................25
System-level approach ........................................................................................25
6.2.1 Concepts of system hierarchy...................................................................25
6.2.2 A systems requirements and characteristics.............................................26
6.2.3 Defining a system ....................................................................................27
6.3 Railway system overview .....................................................................................28
6.3.1 Introduction..............................................................................................28
6.3.2 Bodies/entities involved in a railway system..............................................28
6.3.3 Railway system environment and the balance of requirements ..................28
6.3.4 Railway system structure and apportionment of RAMS requirements .........29
6.4 Railway RAMS and quality of service ...................................................................29
6.5 Elements of railway RAMS ...................................................................................29
6.6 Factors influencing railway RAMS ........................................................................31
6.6.1 General ...................................................................................................31
6.6.2 Classes of failures ...................................................................................31
6.6.3 Derivation of detailed railway specific influencing factors ..........................32
6.6.4 Evaluation of factors ................................................................................36
6.7 Specification of railway RAMS requirements.........................................................36
6.7.1 General ...................................................................................................36
6.7.2 RAMS specification ..................................................................................37
6.8 Risk based approach ...........................................................................................37
6.9 Risk reduction strategy .........................................................................................38
6.9.1 Introduction..............................................................................................38
6.9.2 Reduction of risks related to safety...........................................................38
6.10 Safety integrity ....................................................................................................39
6.10.1 Safety integrity concept ............................................................................39
Management of railway RAMS ......................................................................................40
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
6.1
6.2
7.1
RAMS
7.1.1
7.1.2
7.1.3
process.....................................................................................................40
General ...................................................................................................40
Safety management within the RAMS Process ..........................................40
Independence of roles..............................................................................41
-360
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
prEN 50126-1
7.2 System life-cycle .................................................................................................41

7.3 Application and tailoring of this standard ..............................................................49
7.4 General requirements on RAMS documentation....................................................50
RAMS life-cycle ............................................................................................................51
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
General ...............................................................................................................51
Phase 1: concept .................................................................................................51
8.2.1 Objectives................................................................................................51
8.2.2 Activities ..................................................................................................51
8.2.3 Deliverables.............................................................................................52
8.2.4 Specific verification tasks .........................................................................52
8.2.5 Specific validation tasks ...........................................................................52
Phase 2: system definition and operational context...............................................52
8.3.1 Objectives................................................................................................52
8.3.2 Activities ..................................................................................................52
8.3.3 Deliverables.............................................................................................56
Phase 3: risk analysis and evaluation...................................................................56
8.4.1 Objectives................................................................................................56
8.4.2 Activities ..................................................................................................57
8.4.3 Deliverables.............................................................................................58
Phase 4: specification of system requirements .....................................................59
8.5.1 Objectives................................................................................................59
8.5.2 Activities ..................................................................................................59
8.5.3 Deliverables.............................................................................................60
Phase 5: architecture and apportionment of system requirements .........................60
8.6.1 Objectives................................................................................................60
8.6.2 Activities ..................................................................................................61
8.6.3 Deliverables.............................................................................................61
Phase 6: design and implementation ....................................................................62
8.7.1 Objectives................................................................................................62
8.7.2 Activities ..................................................................................................62
8.7.3 Deliverables.............................................................................................63
Phase 7: manufacture ..........................................................................................63
8.8.1 Objectives................................................................................................63
8.8.2 Activities ..................................................................................................64
8.8.3 Deliverables.............................................................................................64
prEN 50126-1
-4-
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
Scope..................................................................................................................69
Risk analysis methodology...................................................................................70
Risk evaluation and acceptance ...........................................................................73
9.3.1 Acceptance principles ..............................................................................73
9.3.2 Methods for determining risk acceptance criteria ......................................73
10 Deliverables and structure of a safety case ...................................................................74
144
145
146
147
148
149
150
151
152
153
10.1 Purpose of a safety case .....................................................................................74

10.2 Types of safety case............................................................................................74
10.3 Safety case structure ...........................................................................................74
10.3.1 General ...................................................................................................74
10.3.2 Definition of system .................................................................................76
10.3.3 Quality management report ......................................................................76
10.3.4 Safety management report .......................................................................77
10.3.5 Technical safety report .............................................................................77
10.3.6 Related safety cases ................................................................................78
10.3.7 Conclusion...............................................................................................78
8.9
8.10
8.11
8.12
8.13
Risk
Phase 8: integration.............................................................................................64
8.9.1 Objectives................................................................................................64
8.9.2 Activities ..................................................................................................64
8.9.3 Deliverables.............................................................................................65
Phase 9: system validation ..................................................................................65
8.10.1 Objectives................................................................................................65
8.10.2 Activities ..................................................................................................66
8.10.3 Deliverables.............................................................................................66
Phase 10: system acceptance ..............................................................................67
8.11.1 Objectives................................................................................................67
8.11.2 Activities ..................................................................................................67
8.11.3 Deliverables.............................................................................................67
Phase 11: operation, maintenance and performance monitoring............................67
8.12.1 Objectives................................................................................................67
8.12.2 Activities ..................................................................................................67
8.12.3 Deliverables.............................................................................................68
Phase 12: decommissioning.................................................................................69
8.13.1 Objectives................................................................................................69
8.13.2 Activities ..................................................................................................69
8.13.3 Deliverables.............................................................................................69
assessment ..........................................................................................................69
9.1
9.2
9.3
-5-
prEN 50126-1
154
155
10.3.8 References ..............................................................................................79

Annex A (informative) RAMS plan .......................................................................................80
156
Annex B (informative) Examples of parameters for railway. ..................................................85
157
158
159
160
161
162
B.1
B.2
B.3
B.4
B.5
Annex C
163
164
C.1 Example list.........................................................................................................90

Annex D (informative) Risk matrix calibration and risk acceptance categories ......................95
165
166
167
168
D.1
D.2
D.3
Annex E
Reliability parameters ..........................................................................................85

Maintainability parameters ...................................................................................85
Availability parameters.........................................................................................86
Logistic support parameters .................................................................................88
Safety parameters ...............................................................................................88
(informative) Hazards at railway system level example structured list ..................89
Frequency of occurrence levels............................................................................95

Severity levels .....................................................................................................96
Risk acceptance categories .................................................................................97
Bibliography..........................................................................................................99
169
170
171
List of figures
Figure 1 - Interrelation of RAMS-management process and system life-cycle .......................23
172
Figure 2 Illustration of system hierarchy ...........................................................................26
173
Figure 3 Example of deriving cause/effect relations in a diagrammatic approach ...............34
174
Figure 4 Relationship of cause, hazard and accident ........................................................38
175
Figure 5 The "V" representation drawing ..........................................................................44
176
Figure 6 - verification ..........................................................................................................45
177
Figure 7 - validation ............................................................................................................45
178
Figure 8 Structure of a safety case ...................................................................................75
179
Figure B.1 Availability concept and related terms ..............................................................87
180
181
182
List of tables
Table 1 - System phase related tasks informative .............................................................46
183
Table 2 - Frequency - Severity Matrix ..................................................................................72
184
Table A.1 - Example of a Basic RAMS Plan Outline .............................................................81
185
Table B.1 - Examples of Reliability Parameters ...................................................................85
186
Table B.2 - Examples of Maintainability Parameters ............................................................85
187
Table B.3 - Examples of availability parameters...................................................................86
188
Table B.4 - Examples of logistic support parameters............................................................88
189
Table B.5 - Examples of Safety performance parameters .....................................................88
190
Table C.1 - Example for a hazard list...................................................................................91
191
Table C.2 - Example scenarios............................................................................................93
192
193
Table D.1 - Frequency of occurrence of events with examples for quantification (time
based) ................................................................................................................................95
194
195
Table D.4 - Frequency of occurrence of events with examples for quantification (distance
based) ................................................................................................................................96
196
Table D.5 - Severity categories (example related to RAM) ...................................................96
prEN 50126-1
-6-
197
Table D.6 - Severity categories (example 1 related to RAMS) ..............................................97
198
Table D.7 - Categories (example 2 related to S) ..................................................................97
199
Table D.8 - Financial severity levels (example) ....................................................................97
200
Table D.9 - Risk acceptance categories (example 1 for binary decisions) .............................97
201
Table D.10 - Risk acceptance categories (example 2)..........................................................98
202
Table D.11 - Risk acceptance categories (example related to safety) ...................................98
203
-7-
prEN 50126-1
204
Foreword
205
206
This European Standard was prepared by the Technical Committee CENELEC TC9X, electrical
and electronic applications in railways.
207
208
The text of the draft was submitted to the formal vote and was approved by CENELEC as
EN 50126 on 20xx-xx-xx.
209
The following dates were fixed:
210
211
212
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
213
214
b) latest date by which the national standards conflicting

with the EN have to be withdrawn
(dow)
20xx-xx-xx
215
This document supersedes EN 50126-1:1999, EN 50128:2011 and EN 50129: 2003.
216
217
218
The EN 50126 standard includes under the general title "Railway application - The specification
and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)" the following
parts:
219
EN 50126-1: Generic RAMS process
220
EN 50126-2: Systems Approach to Safety
221
EN 50126-4: Functional Safety Electrical/Electronic/Programmable Electronic systems
222
EN 50126-5: Functional Safety Software
223
224
This EN 50126-1 covers the RAMS process. It is mainly based on EN 50126-1:1999 which is
withdrawn.
225
226
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).
227
Introduction
228
229
230
231
232
233
234
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).
235
236
237
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.
238
239
240
241
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.
242
243
244
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.
245
246
247
EN 50126 is the railway 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 demonstrated.
248
249
With regard to safety EN 50126-1 provides a Safety Management Process which is supported by
guidance and methods described in EN 50126-2.
prEN 50126-1
-8-
250
251
252
253
254
255
256
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.
257
258
259
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.
260
261
The application of this standard should be adapted to the specific requirements of the system
under consideration.
262
263
264
265
266
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.
267
268
269
270
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.
271
272
273
274
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.
275
276
277
278
279
280
281
In accordance with CENELEC 1) , 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.
282
1) CENELEC Internal Regulations Part 3: Rules for the structure and drafting of CEN/CENELEC Publications (200908), Annex H
-9-
283
284
This part 1 of EN 50126
prEN 50126-1
Scope
285
286
considers RAMS, understood as reliability, availability, maintainability and safety and

their interaction;
287
288
considers the generic aspects of the RAMS life-cycle. The guidance in this part is still
applicable in the application of specific standards;
289
defines
290
a process, based on the system life-cycle and tasks within it, for managing RAMS;
291
292
293
294
a systematic process, tailorable to the type and size of system under consideration,
for specifying requirements for RAMS and demonstrating that these requirements are
achieved;
addresses railway specifics;
295
enables conflicts between RAMS elements to be controlled and managed effectively;
296
does not define
297
RAMS targets, quantities, requirements or solutions for specific railway applications;
298
299
rules or processes pertaining to the certification of railway products against the

requirements of this standard;
300
301
an approval process by the safety authority;

does not specify requirements for ensuring system security.
302
This part 1 of EN 50126 is applicable
303
304
305
306
to the specification and demonstration of RAMS 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:
307
to new systems;
308
309
310
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;
311
312
313
to 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;
314
for use by railway duty holders and the railway suppliers.
315
316
317
318
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).
319
320
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.
321
322
323
324
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
Normative references
prEN 50126-1
- 10 -
ISO 9001
Quality management systems Requirements
ISO/IEC
GUIDE 51
Safety aspects Guidelines for their inclusion in standards
325
Terms and definitions
326
327
328
329
330
For the purposes of this standard, the following terms & definitions apply.
3.1
acceptance
the status achieved by a product, system or process once it has been agreed that it is suitable
for its intended purpose
331
332
333
334
335
336
3.2
accident
an unintended event or series of events resulting in loss of human health or life, damage to
property or environmental damage
337
338
339
340
341
342
3.3
application conditions
those conditions which need to be met in order for a system to be safely integrated and safely
operated.
343
344
345
346
347
3.4
approval
the legal act, often focused on safety, to allow a product, system or process to be placed into
service
348
349
350
351
352
3.5
assessment
process to form a judgement on whether a product, system or process meets the specified
requirements, based on evidence
353
354
355
356
3.6
assessor
an entity that carries out an assessment
357
358
359
3.7
assurance
confidence in achieving a goal being pursued. Declaration intended to give confidence
360
361
362
363
3.8
audit
a documented, systematic and independent examination to determine whether the procedures
specific to the requirements
NOTE The term includes losses from accidents arising within a short time scale (e.g. collision, explosion) and also
those incurred over the long-term (e.g. release of a toxic substance).
NOTE: application conditions can for example be: operational restrictions (e.g. speed limit, maximum duration of use)
operational rules, maintenance restrictions (e.g. requested maintenance intervals) or environmental conditions.
NOTE a legal act can be performed by an authorised entity (i.e. a NOBO)
NOTE Independence of assessment is only necessary where explicitly specified.
NOTE Independence of the assessor is only necessary where explicitly specified.
364
comply with the planned arrangements,
365
are implemented effectively and
366
are suitable to achieve the specified objectives
367
368
369
370
371
3.9
availability
the ability of a product to be in a state to perform a required function under given conditions at a
given instant of time or over a given time interval assuming that the required external resources
are provided
- 11 -
prEN 50126-1
372
NOTE Figure B.1 (Annex B) illustrates the concept of availability and clarifies the correct use of contributory terms.
373
374
375
376
377
378
379
380
381
3.10
collective risk
a risk, resulting from e.g. a product, process or system, to which a population or group of people
is exposed
382
383
384
385
3.11
commercial off-the-shelf software
software defined by market-driven need, commercially available and whose fitness for purpose
has been deemed acceptable by a broad spectrum of commercial users
386
387
388
389
3.12
common cause failure
failures of different items resulting from the same cause and where these failures are not
consequences of each other
390
391
392
393
3.13
compliance
a state where a characteristic or property of a product, system or process satisfies the specified
requirements
394
395
396
397
398
399
3.14
configuration management
a discipline applying technical and administrative direction and surveillance to identify and
document the functional and physical characteristics of a configuration item, to control changes
to those characteristics, to record and report change processing and implementation status and
to verify compliance with specified requirements
400
401
402
3.15
consequence analysis
to analyze the consequences of each hazard up to accidents and losses
403
404
405
406
3.16
corrective maintenance
the maintenance carried out after fault recognition and intended to put a product into a state in
which it can perform a required function
407
408
409
410
3.17
data-driven software
software configured by data and/or algorithms for producing the executable software for an
application by making use of an existing generic software
411
412
413
414
3.18
designer
an entity that analyses and transforms specified requirements into acceptable design solutions
which have the required safety integrity
415
416
417
418
419
3.19
deterministic
expresses that a behaviour can be predicted with certainty
420
421
422
423
424
3.20
diversity
a means of achieving all or part of the specified requirements in more than one independent and
dissimilar manner
NOTE 1 Collective risk is not to be confused with multiple victim accidents.

NOTE 2 Collective risk is the sum of the individual risks to those individuals in the population or group. However, the
collective risk divided by the number of individuals will only provide the average individual risk.
NOTE 3 A group of people could be, for example, rail staff working in a restaurant car or all passengers using a
particular network.
NOTE A deterministic event in a system can be predicted with certainty from preceding events which are either known
or are the same as for a proven equivalent system.
NOTE Diversity may be achieved by different physical methods or different design approaches.
prEN 50126-1
- 12 -
425
426
427
3.21
entity
a person, group or organisation who fulfil a role as defined in this standard
428
429
430
431
3.22
equivalent fatality
an expression of fatalities and weighted injuries and a convention for combining injuries and
fatalities into one figure for ease of evaluation and comparison of risks
432
433
434
435
436
437
3.23
error
a discrepancy between a computed, observed or measured value or condition and the true,
specified or theoretically correct value or condition
NOTE 1 An error can be caused by a faulty item, e.g. a computing error made by faulty computer equipment.
NOTE 2 A human error can be seen as a human action or inaction that can produce an unintended result.
438
439
440
441
3.24
fail-safe
a concept which is incorporated into the design of a product such that, in the event of a failure, it
enters or remains in a safe state
442
443
444
445
446
3.25
failure
the termination of the ability of an item to perform a required function
447
448
449
450
3.26
failure mode
a predicted or observed manner in which the product, system or process under consideration
can fail
451
452
453
454
455
456
457
3.27
failure rate
the limit, if this exists, of the ratio of the conditional probability that the instant of time, T, of a
failure of a product falls within a given time interval (t, t+t) and the length of this interval, t,
when t tends towards zero, given that the item is in an up state at the start of the time interval
458
459
460
461
462
463
3.28
fault
the state of an item characterized by inability to perform a required function, excluding the
inability during preventive maintenance or other planned actions
464
465
466
467
3.29
fault detection time
time span which begins at the instant when a failure occurs and ends when the existence of the
fault is detected
468
469
470
471
3.30
fault tolerance
ability of a functional unit to continue to perform a required function in the presence of faults or
errors
472
473
474
475
3.31
firmware
an ordered set of instructions and associated data stored in a way that is functionally
independent of main storage
NOTE 1 After failure the item has a fault.

NOTE 2 "Failure" is an event, as distinguished from "fault", which is a state.
NOTE Failure rates are often assumed as constant. This is not always valid, e.g. for components subject to wear out
(mechanical, pneumatic, electromechanical, etc.).
NOTE A fault is often the result of a failure of the item itself, but may exist without prior failure (e.g. in case of a
design fault).
- 13 -
prEN 50126-1
476
477
478
479
480
3.32
function
a specified action or activity which may be performed by technical means and/or human beings
and has a defined output in response to a defined input
481
482
483
484
485
3.33
functional safety
the perspective of safety focused on the functions of a system
486
487
488
489
490
3.34
generic product
product (hardware and/or software) which can be used for a variety of installations, either
without making any changes or purely trough the configuration of the hardware or the software
(for example by the provision of application-specific data and/or algorithms)
491
492
493
3.35
hazard
a condition that could lead to an accident
494
495
496
3.36
hazard analysis
an analysis comprising hazard identification, causal analysis and common cause analysis
497
498
499
500
501
502
503
3.37
hazard log
the document in which hazards identified, decisions made, solutions adopted and their
implementation status are recorded or referenced
504
505
506
507
3.38
hazard rate
the rate of occurrence of a hazard
508
509
510
3.39
implementation
the activity applied in order to transform the specified designs into their realisation
511
512
513
3.40
implementer
the entity that carries out implementation
514
515
516
517
3.41
independence (functional)
freedom from any mechanism which can affect the correct operation of more than one function
as a result of either systematic or random failure
518
519
520
521
3.42
independence (physical)
freedom from any mechanism which can affect the correct operation of more than one
system/subsystem/ equipment as a result of random failures
522
523
524
525
526
527
3.43
individual risk
a risk, resulting from e.g. a product, process or system, to which an individual person is exposed
NOTE A function can be specified or described without reference to the physical means of achieving it.
NOTE 1 Functional safety does not only consider normal operation.

NOTE 2 Functional safety can be based on safety functions as well as on safety-related functions.
NOTE 1 The Hazard Log compiles evidence on the implementation of safety requirements regarding all identified hazards, thus
supporting the demonstration of completeness of the safety assurance activities
NOTE 2 A "hazard record" is an extract of the hazard log that is suitable for transferring between stakeholders.
NOTE For detailed mathematical understanding of "rate" refer to the definition of "failure rate".
NOTE 1 Individual risk is not to be confused with single victim accidents.

NOTE 2 Collective risk is the sum of the individual risks to those individuals in the population or group. However, the
collective risk divided by the number of individuals will only provide the average individual risk.
prEN 50126-1
- 14 -
528
529
530
531
532
533
3.44
infrastructure manager
any body or undertaking that is responsible in particular for establishing and maintaining railway
infrastructure, or a part thereof, which may also include the management of infrastructure
control and safety systems. The functions of the infrastructure manager on a network or part of
a network may be allocated to different bodies or undertakings
534
535
536
537
3.45
integration
the process of assembling the elements of a system according to the architectural and design
specification, and the testing of the integrated unit
538
539
540
3.46
integrator
an entity that carries out system integration
541
542
543
3.47
latent fault
an existing fault that has not yet been detected
544
545
546
547
3.48
life-cycle
those activities occurring during a period of time that starts when the product, system or process
is conceived and ends when the product, system or process is no longer available for use
548
549
550
551
3.49
logistic support
the overall resources which are arranged and organised in order to operate and maintain the
system at the specified availability level at the required life-cycle cost
552
553
554
555
3.50
loss analysis
systematic use of all available information to identify losses associated with accidents (or their
RAM equivalent) and estimate their severities
556
557
558
559
560
561
3.51
maintainability
the ability of an item under given conditions of use, to be retained in, or restored to, a state in
which it can perform a required function, when maintenance is performed under given conditions
and using stated procedures and resources
NOTE The maintainability is also used as a measure of maintainability performance.
562
563
564
565
3.52
maintenance
the combination of all technical and administrative actions, including supervision actions,
intended to retain a product in, or restore it to, a state in which it can perform a required function
566
567
568
3.53
mission
an objective description of the fundamental task performed by a system
569
570
571
572
3.54
mission profile
outline of the expected range and variation in the mission with respect to parameters such as
time, loading, speed, distance, stops, tunnels, etc., in the operational phases of the life-cycle
573
574
575
3.55
negation
enforcement of a safe state following detection of a hazardous fault
576
577
578
579
3.56
negation time
time span which begins when the existence of a fault is detected and ends when a safe state is
enforced
- 15 -
prEN 50126-1
580
581
582
583
584
3.57
pre-existing software
all software developed prior to the application currently in question is classed as pre-existing
software including commercial off-the-shelf software, open-source software and software
previously developed but not in accordance with this European Standard
585
586
587
588
3.58
preventive maintenance
the maintenance carried out at pre-determined intervals or according to prescribed criteria and
intended to reduce the probability of failure or the degradation of the functioning of an item
589
590
591
592
3.59
procedural safety
aspects of the safety life-cycle which are governed by procedures and instructions (e.g.
operational and maintenance procedures)
593
594
595
3.60
project management
the administrative and/or technical conduct of a project, including RAMS aspects
596
597
598
3.61
project manager
an entity that carries out project management
599
600
601
602
603
604
605
606
607
608
609
3.62
railway duty holder
the body with the overall accountability for operating a railway system within the legal framework
610
611
612
613
614
3.63
railway undertaking
means any public or private undertaking, whose activity is to provide transport of goods and/or
passengers by rail on the basis that the undertaking must ensure traction; this also includes
undertakings which provide traction only
615
616
617
618
619
620
3.64
RAM plan
a documented set of time scheduled activities, resources and events serving to implement the
organisational structure, responsibilities, procedures, activities, capabilities and resources that
together ensure that an item will satisfy given RAM requirements relevant to a given contract or
project
621
622
623
624
625
626
3.65
RAMS management process
the activities and procedures that are followed to enable the RAMS requirements of a product or
an operation to be identified and met. It provides a systematic and systemic approach to
continually manage RAMS through the whole life-cycle
627
628
629
630
631
3.66
redundancy
the provision of more than one means for accomplishing a given function to improve reliability,
availability and/or safety performance
NOTE 1 Railway duty holder accountabilities for the overall system or its parts and life-cycle activities are sometimes
split between one or more bodies or entities. For example:
the owner(s) of one or more parts of the system assets and their purchasing agents;
the operator of the system;
the maintainer(s) of one or more parts of the system;
NOTE 2 Typically the railway duty holders are railway undertakings and the infrastructure managers.
Such splits are based on either statutory instruments or contractual agreements. Such responsibilities should
therefore be clearly stated at the earliest stages of a system life-cycle.
NOTE This Process should be embedded in a management system at the organisational level
NOTE Each means of accomplishing the function need not necessarily be identical
prEN 50126-1
- 16 -
632
633
634
635
636
637
3.67
reliability
the ability of an item to perform a required function under given conditions for a given time
interval
NOTE The term "reliability" is also used as a measure of reliability performance and may also be defined as a
probability
638
639
640
641
3.68
reliability growth
a condition characterised by a progressive improvement of a reliability performance measure of
an item with time
642
643
644
645
3.69
repair
measures for re-establishing the required state of a system/sub-system/equipment after a
fault/failure
646
647
648
649
3.70
requirements manager
an entity that is responsible for managing the specification or capture and recording of the
requirements
650
651
652
3.71
residual risk
risk remaining once risk control measures have been taken
653
654
655
3.72
restoration
bring an item into a state where it regains the ability to perform its required function after a fault
656
657
658
3.73
risk
the combination of expected frequency of loss and the expected degree of severity of that loss
659
660
661
3.74
risk analysis
systematic use of all available information to identify hazards and to estimate the risk
662
663
664
665
3.75
risk assessment
the overall process comprising system definition, risk analysis and a risk evaluation
666
667
668
669
670
3.76
risk based approach
in relation to safety, the risk based approach is a process for ensuring the safety of products,
processes and systems through consideration of the hazards and their consequent risks
671
672
673
674
3.77
risk evaluation
procedure based on the Risk Analysis results to determine whether the tolerable risk has been
achieved
675
676
677
678
3.78
risk management
systematic application of management policies, procedures and practices to the tasks of
analysing, evaluating and controlling risk
679
680
681
3.79
safety
freedom from unacceptable risk to human health or to the environment
NOTE Risk assessment does not necessarily require independent assessment.
NOTE The approach is applicable to RAM aspects in an analogous manner.
- 17 -
prEN 50126-1
682
683
684
685
3.80
safety authority
the body entrusted with the regulatory tasks regarding railway safety in accordance with the
respective legal framework
686
687
688
689
690
691
3.81
safety barrier
any physical or non-physical means, which reduces the frequency of a hazard and/or a likely
accident arising from the hazard and/or mitigates the severity of likely accidents arising from the
hazard
692
693
694
695
696
3.82
safety case
the documented demonstration that the product, system or process complies with the
appropriate safety requirements
697
698
699
700
701
702
703
3.83
safety function
a function whose sole purpose is to ensure safety
704
705
706
707
708
709
3.84
safety integrity
ability of a safety-related function to satisfactorily perform under all the stated conditions within
a stated operational environment and a stated period of time
710
711
712
713
714
715
3.85
safety integrity level
one of a number of defined discrete levels for specifying the safety integrity requirements of
safety-related functions to be allocated to the safety-related systems
716
717
718
3.86
safety management
the management structure which ensures that the safety process is properly implemented
719
720
721
3.87
safety management process
that part of the RAMS management process which deals specifically with safety aspects
722
723
724
725
726
727
3.88
safety plan
a documented set of time scheduled activities, resources and events serving to implement the
organisational structure, responsibilities, procedures, activities, capabilities and resources that
together ensure that an item will satisfy given safety requirements relevant to a given contract or
project
728
729
730
731
732
733
734
3.89
safety-related
function, component, product, system or procedure in its intended use is safety-related, if in the
event of degradation or failure, directly or in combination with other reasonably foreseeable
failures or errors, a non-negligible increase of risk to human health or to the environment has
been rationally identified by appropriate expert judgement
NOTE This term can be applied to RAM aspects in a similar manner.
NOTE The safety case is not necessarily the subject of approval.
NOTE 1 A safety-related function is a function whose failure affects safety (for details refer to definition of "safetyrelated"). Therefore, all safety functions are safety-related functions, but not vice versa.
Note 2 A safety function may contribute to one or more safety barriers. However, a safety barrier is not necessarily
implemented by a safety function.
NOTE Safety integrity can be a property associated with technical and non-technical functions as well as other
aspects (e.g. operational or architectural aspects).
NOTE 1 Safety Integrity Level with the highest figure has the highest level of safety integrity.
NOTE 2 It is not possible to allocate a Safety Integrity Level to safety-related processes or other measures.
NOTE The term provides no further indication of the importance to safety.
prEN 50126-1
- 18 -
735
736
737
738
3.90
software
an intellectual creation comprising the programs, procedures, rules, data and any associated
documentation pertaining to the operation of a system
739
740
741
742
743
744
745
3.91
software baseline
a complete and consistent set of source code, executable files, configuration files, installation
scripts and documentation that are needed for a software release. Information about compilers,
operating systems, pre-existing software and dependent tools is stored as part of the baseline
NOTE The software baseline will enable the organisation to reproduce defined versions and be the input for future
releases at enhancements or at upgrade in the maintenance phase
746
747
748
3.92
software deployment
transferring, installing and activating a deliverable software
749
750
751
752
753
3.93
software maintainability
the capability of the software to be modified
754
755
756
757
3.94
software maintenance
an action, or set of actions, carried out on software after deployment with the aim of enhancing
or correcting its functionality
758
759
760
761
3.95
stress profile
the degree, duration and number of external influences which a product can withstand whilst
performing its required functionality
762
763
764
765
3.96
system
set of elements which interact according to a design, where an element of a system can be
another system, called a subsystem and may include hardware, software and human interaction
766
767
768
769
3.97
system life-cycle
the activities occurring during a period of time that starts when a system is conceived and end
when the system is no longer available for use, is decommissioned and is disposed
770
771
772
773
774
775
776
777
778
779
780
3.98
systematic failure
a failure due to errors, which cause the product, system or process to fail deterministically under
a particular combination of inputs or under particular environmental or application conditions
781
782
783
784
785
786
3.99
T1
tool class which generates no outputs which can directly or indirectly contribute to the system or
the hardware
NOTE software modification may be necessary to correct faults, improve performance or other attributes, or adapt it
to a different environment
NOTE 1 Corrective maintenance without modification will usually not eliminate the failures cause.
NOTE 2 A systematic failure can be induced by simulating the conditions which cause it to occur.
NOTE 3 Examples of causes of systematic failures include human error in
the safety requirements specification
the design, manufacture, installation, operation of the hardware
the design, implementation, etc. of the software.
NOTE 4 Failures are categorised as random failures or systematic failures.
NOTE T1 examples include: a text editor or a requirements or design support tool with no automatic code generation
capabilities; configuration control tools.
- 19 -
prEN 50126-1
787
788
789
790
791
3.100
T2
tool class which supports the test or verification of the design or the hardware, where errors in
the tool can fail to reveal defects but cannot directly create errors in the system or the hardware
792
793
794
795
796
797
3.101
T3
tool class which generates outputs which can directly or indirectly contribute to the system or
the hardware
798
799
800
801
3.102
technical safety
that part of safety that is dependent upon the characteristics of a product, which derive from the
system functional requirements and/or of the system design
802
803
804
3.103
tester
an entity that carries out testing
805
806
807
808
3.104
testing
the process of operating a product, system or process under specified conditions as to ascertain
its behaviour and performance compared to the corresponding requirements specification
809
810
811
812
3.105
traceability
relationship established between two or more entities in a development process, especially
those having a predecessor/successor or master/subordinate relationship to one another
813
814
815
816
817
3.106
validation
confirmation by examination and provision of objective evidence that the product, system or
process is suitable for a specific intended use
818
819
820
3.107
validator
an entity that is responsible for the validation
821
822
823
824
3.108
verification
confirmation by examination and provision of objective evidence that the specified requirements
have been fulfilled
825
826
827
3.109
verifier
an entity that is responsible for one or more verification activities
NOTE T2 examples include: a test harness generator; a test coverage measurement tool; a static analysis tool.
NOTE T3 examples include: a tool for hardware layout; a compiler that incorporates an executable run-time package
into the executable code.
NOTE 1 Verification is a prerequisite for validation.
prEN 50126-1
828
829
- 20 -
Abbreviations
ALARP
As low as reasonably practicable
COTS
Commercial of the shelf
E/E/PE
Electrical/electronic/programmable electronic systems
EMC
Electromagnetic compatibility
EMI
Electromagnetic Interference
FC
Fault Coverage
FMEA
Failure Mode and Effects Analysis
FMECA
Failure Mode, Effects and Criticality Analysis
FRACAS
Failure Reporting Analysis and Corrective Action System
FTA
Fault Tree Analysis
GAME
Globalement Au Moins Equivalent
LAD
Logistic and Administrative Delay
LCC
Life-cycle Cost
MDT
Mean Down Time
MEM
Minimum Endogenous Mortality
MTBF
Mean Time Between Failure
MTBM
Mean Time Between Maintenance
MUT
Mean Up Time
QMS
Quality Management System
RA
Risk assessment
RAM
Reliability, availability and maintainability
RAMS
Reliability, availability, maintainability and safety
RC
Repair Coverage
SIL
Safety integrity level
- 21 -
prEN 50126-1
830
Process overview
831
5.1
Purpose of overview
832
833
834
835
836
This section is introducing the basic ideas applied in this suite of standards. It should support a
newcomer to the subject of risk management as well as making an expert aware of the changes
/ adaptations in the new merged version of the former EN 50126, EN 50128 and EN 50129.
More detailed information and all requirements are given in following and referenced clauses.
Therefore no requirements are given in this overview.
837
5.2
838
839
840
841
842
843
The objective of the RAMS process described in this standard is to ensure that all aspects of
RAMS are covered in order to provide the safety and quality of railway applications at affordable
cost for the users of the railway (see 6.3.3.1). To achieve safety and quality they have to be
considered right at the beginning of a project and continuously throughout the complete
development and operation. In this manner, safe performance and reliable quality can be
incorporated into a system/subsystem instead of adding on corrective systems in later stages.
844
845
The RAMS process is the core of this standard and this overview briefly introduces the general
concept. Details of RAMS are then elaborated in chapter 6.
846
5.3
847
848
849
850
851
This objective can only be achieved if the management of all stakeholders live up to their
organisational responsibility. The requirements of this standard can only be fulfilled if the
management in charge embodies organisational structures and rules that enable their staff to
comply with the more detailed requirements and ensures that they are being followed. Therefore
this standard requires management commitment and action.
852
5.4
853
854
The described process is applicable to new technologies, new systems as well as modifications
of systems.
855
856
857
858
859
With regard to Safety, the process described is applicable not only to technical but operational
and organisational matters as well. For example, safety-related aspects of operational rules to
be produced or changed, as well as modifications of safety-related organisations are covered by
this process. Activities and processes concerning structures and rules dealing with safety
aspects are expected to be stricter than those dealing with RAM only.
860
861
862
863
864
865
No matter how small the intended change might be, its impact on the RAMS of neighbouring
systems via interfaces and the resulting impact on RAMS of the railway system operation need
to be investigated. The system definition determines the outline of assessment with the
description of boundaries and interfaces and since the process itself is scalable to system,
subsystem or product level, the extent and depth of the analysis can be adjusted to an
appropriate level for the task at hand.
866
867
868
869
870
During the risk analysis the possible hazards resulting out of the change are to be identified
(interfaces included), evaluated and the resulting requirements to be defined and possibly
apportioned. After that only the affected phases of the process have to be reconsidered.
If the change does not create additional risk (e.g. by creating a new hazard, making an existing
hazard more likely or changing the consequences of a hazard) the reasoning is be documented.
871
872
873
All these aspects, regarding the different size, complexity and novelty of the system under
consideration, imply the need to tailor the process described in this standard. For more details
on tailoring please refer to 7.3.
Objective
Management responsibility
Adaptability to project scope and size
prEN 50126-1
- 22 -
874
5.5
Interrelation of RAMS management process and life-cycle
875
876
877
878
879
After a concept for a product has been set up, the general process consists of 3 major blocks:
Risk assessment (on the basis of the system definition including the specification of system
requirements), Demonstration of compliance with requirements and Operation and
Decommissioning. Apart from the regular process flow throughout the life-cycle phases those
blocks are connected
880
881
882
1. via a feedback loop, should new or additional knowledge about risk come up during
the detailing phases of the project that demands the risk to be reassessed and
resulting this some phases have to be readdressed;
883
884
885
886
887
2. via subsequent loops (on the left side of Figure 1) after reassessment that allow
skipping some phases of the regular process flow if the reconsidered RAMS
requirements are not affected in those phases, or, in worst case, demand rephrasing
the remit of the project (concept phase) if the safety requirements cannot be met in
any way.
888
889
890
891
892
893
894
A direct consequence of this is that the logical flow of knowledge and decision is more important
than the time based flow of the phases. Therefore, formally the risk analysis is never completely
finished before the end of the life-cycle. In this general EN 50126-1 the activities connected with
the phases are not allocated to roles. That is to be performed by (project-) management or
might be described in standards dealing with specific technologies as provided in EN 50126-4
and EN 50126-5 for E/E/PE systems. Each of the 3 blocks consists of several life-cycle phases
described in the respective chapters and shown in Figure 1.
895
896
897
It is important to note, that this life-cycle and its phases can be applied for systems on various
levels, varying from the railway system level up to e.g. a switch point function. Therefore, Figure
1 is to be applied in an analogous way.
898
899
900
901
The process may be simplified by reusing existing applicable material. An example of such
material which can be reused in this way is the Technical Specification CLC/TS 50562:2011,
Railway applications - Fixed installations - Process, measures and demonstration of safety for
electric traction systems.
902
903
904
Note that this life-cycle is applicable for each system under consideration independent of its
level within the complete railway system. In this iterative approach each considered system level
can be integrated into the superior system up to the top level of the complete railway system.
Concept
System Definition and

Operational Context
Risk Analysis
and Evaluation
Specification of
System Requirements
Implementation and
Demonstration of Compliance with
Requirements
Architecture &
Apportionment
of System Requirements
Design and
Implementation
Manufacture
Integration
System Validation
*)
*)
Operation
andand
Operation
Decommissioning
Decommisssioning
10 System Acceptance
11
Feedback of subsequent hazard identification into risk analysis
4
Consideration of subsequent RAMS Requirements in product development
prEN 50126-1
Risk
Assessment
- 23 -
Operation,
Maintenance and
Performance
Monitoring
12 Decommissioning
Key:
RA
DoC
O&D
Correlated process steps in

European legal framework
*) may contain many subsystems and components
905
906
Figure 1 - Interrelation of RAMS-management process and system life-cycle
prEN 50126-1
- 24 -
907
5.6
Short description of life-cycle phases
908
909
The following text briefly introduces the life-cycle phases shown in Figure 1 that will be detailed
with their requirements in chapter 8 RAMS life-cycle:
910
1. Concept: remit of the project should be drawn up (details see 8.2);
911
912
913
914
915
916
917
918
919
2. System definition and operational context: the system that is to be developed should
be described in its essential characteristics and functions. Furthermore, the interfaces
to other systems need to be clarified. That includes the input to be provided and the
output that can be expected. On this basis the impact on RAMS-parameters of
neighbouring systems can be derived. The intended operational conditions
(maintenance, environment, etc.) that could impair the safe or good (RAM) function
are to be stated to ensure that the operator is aware of them. The RAMS
management is to be established, including RAM plan and Safety plan (details see
8.3);
920
921
922
923
924
925
926
927
3. Risk analysis and evaluation: several steps (identify hazards associated with the
system, identify events leading to hazards, determine risk associated with hazards,
establish process for on-going risk management) should be followed to decide if a
risk is tolerable. Risk analysis is an ongoing and iterative step and may continue in
parallel with subsequent phases. It may be necessary to define further safety system
requirements induced by the risk acceptance criteria in order to reduce the risk to an
acceptable level. System requirements can be derived / exist at different levels
(details see 8.4);
928
929
930
931
4. Specification of system requirements: detailing the initial system requirements

(expected functions incl. their RAMS requirements) and the ones derived from risk
assessment in phase 3 as well as defining criteria for acceptance and specifying the
overall demonstration of compliance (details see 8.5);
932
933
934
935
936
937
938
939
940
941
942
5. Architecture and apportionment of system requirements: allocation of requirements

(including all safety requirements) to subsystems (this phase might be a part of
demonstration of compliance) (details see 8.6);
943
944
945
6. Design and implementation: during this phase subsystems and components should be
created according to the RAMS requirements. Furthermore plans for future life-cycle
tasks have to be established (details see 8.7);
946
947
948
7. Manufacture: the subsystems and components of the system should be manufactured

and RAMS centred assurance arrangements have to be established and applied
(details see 8.8);
949
950
8. Integration: all subsystems and components should be assembled and installed to

form the complete system (details see 8.9);
951
952
953
9. System Validation: it should be validated that the system, product or process

complies with the RAMS requirements in combination with external risk reduction
measures (details see 8.10);
954
955
10. System acceptance: demonstrate compliance of complete system with overall RAMS
requirements and accept system for entry into service (details see 8.11);
NOTE 1 At each subordinated system level it is to be decided which phases need to be repeated.
Principally this relates to all life-cycle phases. Each subsystem should be assessed in the same manner
at their level of detail and within the boundary of their specific sub-system definition (iterative method).
NOTE 2 Should information about hazards and associated risks in later phases convey additional
hazards or a higher risk than assumed in the beginning the prolonging validity of the initial risk
assessment should be shown again or an update of the initial risk assessment is required.
NOTE 3 Subsystem requirements can be directly allocated if they are already available at this level or
are apportioned by deriving them from system level requirements.
- 25 -
prEN 50126-1
956
957
958
959
960
11. Operation, Maintenance and Performance Monitoring: The objective of this phase is
to operate, maintain and support the product, system or process such that
compliance with system RAMS requirements is maintained. This includes to
continuously evaluate the RAMS performance of the system and to derive measures
(details see 8.12);
961
962
12. Decommissioning: in case of decommissioning the system it has to be ensured that

the risk is controlled during the transition phase (details see 8.13).
963
Railway RAMS
964
6.1
Introduction
965
966
967
968
Clause 6 of this standard provides baseline information on the subject of RAMS. The purpose of
this clause is to provide the reader with sufficient background information to enable the effective
application of this standard to railway systems. All requirements derived from this clause are
specified in clause 8 RAMS life-cycle.
969
970
971
Railway RAMS is a major contributor to the Quality of Service provided by railway duty holder.
Railway RAMS is defined by several contributory elements; consequently, this clause of this
standard is structured as follows:
972
973
1. Subclauses 6.2 and 6.3 provide an overview of the systems approach and system
definition within the context of railways;
974
975
2. Subclause 6.4 examines the relationship between railway RAMS and quality of
service;
976
3. Subclause 6.5 outlines the railway RAMS elements and its interaction;
977
4. Subclauses 6.6 to 6.10 examine aspects of railway RAMS, namely:
978
the elements of RAMS;
979
the factors which influence and means to achieve RAMS targets;
980
risk and safety integrity.
981
6.2
System-level approach
982
983
984
985
986
Concepts of system hierarchy

6.2.1
6.2.1.1 Within this standard, the sequence system, sub-system, component is used to
demonstrate the breakdown of a system into its constituent parts. The precise boundary of each
element (system, sub-system and component), either physical or functional, will depend upon
the specific application. The system itself is contained in an operational environment.
987
988
989
990
991
6.2.1.2 A system can be defined as an assembly of sub-systems and components, connected

together in an organised way, to achieve specified functionality. Functionality is assigned to
sub-systems and components within a system and the behaviour and state of the system may
change if the sub-system or component functionality changes. A system responds to inputs to
produce specified outputs, whilst interacting with an environment.
992
993
6.2.1.3 Basic concept of nested systems in a system hierarchy can be shown diagrammatically
by Figure 2.
994
995
According to the nested systems concept, systems are themselves built up of smaller systems
that themselves are built up of even smaller systems and so on.
996
997
998
999
1000
1001
For convenience, multi level nested systems are usually handled on the basis of successive
groupings of systems at 3 levels of hierarchy. The 3 level hierarchies would consist of a system
under consideration (e.g. sub-system D) containing its intra-related subsystems and / or
components (W, X, Y and Z) and itself being contained, together with its inter-related subsystems and / or components (A, B and C) in a containing or parent system (e.g. Railway
system). This provides visibility of the 3 levels and enables consideration of:
prEN 50126-1
- 26 -
1002
1003
the interactions and interfaces between the system under consideration and its
siblings i.e. the inter-related sub-systems / components and;
1004
1005
the influences and interactions between the system under consideration and its
environment (i.e. the parent or containing system).
1006
1007
1008
1009
1010
1011
1012
Functions of a system are the actions or activities performed by the system as a whole.
Functions and structure provide the internal view of the system properties that produce the
outputs and external properties and are the concern of the body/entity responsible for the
design of the system. The environment consists of anything that could influence, or be
influenced by, the system. This will include anything to which the system connects mechanically,
electrically or by other means, including EMI, thermal, etc. The environment will also include
people and procedures that can effect, or be affected by, the operation of the system.
1013
1014
1015
1016
Understanding the boundary between the system under consideration and its environment and
the interactions with its inter-related sub-systems is a pre-requisite to understanding how the
system might contribute to an accident and what its hazards are (see Figure 2).
system
(environment of system
under consideration)
sub-system /
components
B
A
D
sub-system
(system under consideration)
sub-system /
components
B
Y
Z
X
C
1017
sub-systems / components
(of system under consideration)
1018
Figure 2 Illustration of system hierarchy
1019
1020
1021
1022
6.2.2
A systems requirements and characteristics
6.2.2.1 A systems requirements are elicited from various sources. Requirements may be
categorised, but a unique and unambiguous categorisation is not possible. Therefore, the
following classification is for orientation purposes:
1023
1024
1025
1026
1027
1028
1029
Functional requirements: a system is implemented to fulfil certain functions that are

fundamental to the system and the prime reason for its creation. Depending on the system
design, additional requirements may also be needed to ensure proper functioning of the
system. The fundamental requirements and the additional requirements together are
referred to as Functional requirements. They express the behaviour of the system and
may also need to be complemented by properties qualifying its level of performance (e.g.
reliability, safety, accuracy, timing, etc.).
1030
1031
1032
1033
Contextual requirements: the relation between the system and its environment may need to
be further qualified by means of contextual requirements. They would address issues like
the system mission profile, maintenance and logistics, human factors (e.g. personal
qualification), procedural environment, costs, etc.
- 27 -
prEN 50126-1
1034
1035
1036
1037
1038
1039
1040
Technical requirements: the technical implementation of the system may generate further
requirements that do not derive from the system functions but from its technical
implementation. Such requirements are referred to as Technical requirements. They
impact the system build. Technical requirements may address issues such as
maintainability, environmental conditions, potential threats created by the technology/
equipment regardless of their intended functions (e.g. presence of sharp edges, presence
of electric voltage, presence of combustible material, etc.).
1041
1042
1043
1044
1045
Detailed design involves engineering the sub-systems and equipment that implement the
functional requirements of the system under consideration. It leads to refining the functional
requirements to ensure compatibility between the different sub-systems / equipment, and to
implement the refined functional requirements whilst enforcing the technical and contextual
requirements.
1046
1047
1048
1049
1050
Characteristics of the system and its constituents (user-related characteristics, derived from the
functional, technical and contextual requirements) are determined by the requirements and a
systems compliance with its requirements is demonstrated through its characteristics.
Implementation of the system (i.e. the technical solution) is then likely to give rise to additional
characteristics (referred to as implementation characteristics) introduced by the design.
1051
1052
1053
1054
1055
6.2.3
Defining a system
6.2.3.1 A system comprises not only of its technical components but also the interaction with
humans developing, operating, and maintaining it. Therefore, these should be included in the
definition and documentation of the considered system taking into account the concept of
system hierarchy explained in 6.2.1.
1056
1057
1058
Before any RAMS analysis is undertaken (e.g. hazard identification) boundaries and functions of
the system under consideration have to be established. Therefore, the following aspects, but not
limited to, should be taken into account and clearly documented:
1059
1060
1061
System boundaries and interfaces (interfaces, e.g. with other systems or with the
environment, define the boundaries of the system to be analysed and the interactions
that occur over these boundaries);
1062
1063
Intended function, e.g. system functions which are to be included in the analysis and
system functions which are to be excluded, if any;
1064
Working environment, e.g.:
1065
1066
influence on neighbouring objects, systems, and environment including operational

personnel, passengers, and public;
1067
1068
Definitions of physical and operational conditions and the environment under which
the system works;
1069
1070
1071
Description of necessary operator actions. Also identifying persons that are permitted
to carry out these actions, indicating the skills and qualifications required and the
basis for these actions, if any;
1072
1073
1074
if no human activities have been included in the analysis, the reasons for this should
be stated.
Modes of operation, e.g.:
1075
1076
normal, abnormal/degraded mode of operation, disconnect/connect states and

transitions, etc., and their interactions;
1077
1078
1079
1080
operational scenarios to be considered within the analysis, e.g. effects of

maintenance operations (how, how often and by whom is the system maintained?);
External requirements e.g. external safety requirements resulting from the overall safety
policy of the railway duty holder, from prevailing legal considerations, or from standards;
1081
1082
1083
Version of the system and related documents:

if assumptions are made about particular functions or subsystems that are different
from an existing version, then the deviations should be explicitly stated and justified;
prEN 50126-1
- 28 -
1084
1085
if the system is modified later during its life-cycle, it may be necessary to revise the
RAMS analysis and may even require a completely new risk assessment;
1086
1087
1088
1089
1090
1091
the potential effects of new system versions on the safety of the railway system
should always be checked by reviewing the risk assessment, in particular the hazard
log.
NOTE For software related items it is clear that software cannot be studied alone. Only through a consideration of the
software loaded into a system operating within a certain environment and fulfilling a certain function is it viable to
perform a comprehensive RAMS analysis.
1092
6.3
1093
1094
1095
1096
Introduction
6.3.1
6.3.1.1 Sub-clause 6.3 gives a perspective of the railway system, the bodies/entities involved in
it and on some of the underlying concepts and RAMS considerations (e.g. risk, hazards). An
understanding of the system and its elements is essential for the management of railway RAMS.
1097
6.3.2
1098
1099
1100
1101
Depending on the social/political environment and the organisational /management structure of

the railway system concerned, a number of bodies/entities, performing different functions, may
be involved within the life-cycle phases of the system. For the purpose of this standard the
bodies/entities are divided into the following main categories:
Railway system overview
Bodies/entities involved in a railway system
1102
railway undertakings (railway duty holder);
1103
infrastructure managers (railway duty holder);
1104
maintainers;
1105
railway supply industry;
1106
safety authorities.
1107
1108
6.3.2.1 As far as the RAMS process is concerned, developing generic products imposes the
obligations of the railway duty holder in this regard on the railway supply industry.
1109
1110
6.3.2.2 The roles and responsibilities of these bodies may be contracted out to several other
stakeholders or sub-contractors, depending on:
1111
social, political or legal considerations;
1112
size and complexity of the system or subsystem concerned;
1113
economic, organisational or managerial considerations.
1114
1115
1116
It is therefore advisable to identify all the stakeholders that can be a part of this relationship and
to examine and document how the roles and responsibilities of dealing with safety, during the
life-cycle of the system/sub-system concerned, are shared between them.
1117
1118
Refer to 7.1.1.3 for further information on the stakeholders of the railway and their roles and
responsibilities.
1119
1120
1121
1122
1123
1124
1125
1126
1127
6.3.3
Railway system environment and the balance of requirements
6.3.3.1 A railway system would normally operate within a prevailing socio-economic/political
environment. The affordability of the rail transport system, both in terms of its design,
construction and implementation and in terms of its subsequent use, also depends on this
environment. Therefore affordability of the railway system and existing RAMS performance
within the prevailing environment or RAMS performance that are socially/politically tolerable
within this environment constitute the context for the RAMS considerations.. Specifically, a
railway system that is unaffordable to the users may well reduce safety within the social
environment, e.g. by displacing users onto other modes of transport that are generally less safe.
- 29 -
prEN 50126-1
1128
1129
1130
1131
1132
1133
1134
6.3.3.2 The legal framework within the prevailing socio-economic/political system defines the
jurisdiction over the rail transport system and determines responsibilities. Within this frame the
relevant bodies should ensure a balance between affordability and safety and therefore for
providing/specifying safety requirements and targets for tolerable levels of safety risk for the
railway system as a whole. Often such targets may not be available at the start of a project and
the body/entity responsible for the railway system (e.g. for its design/configuration) may propose
targets that are endorsed or revised by the relevant authority with jurisdiction.
1135
1136
1137
1138
1139
1140
1141
1142
1143
6.3.3.3 Similarly, considering a hierarchical system structure, when the system under
consideration is a subsystem of the railway system then it would be the body/entity responsible
for the safe operation of the railway system (railway duty holder) that should set or specify the
safety requirements and targets for tolerable levels of risk for the subsystem in agreement with
rules given by the legal framework. In general, therefore, it is the body/entity responsible for the
design/configuration at each system level that would also be responsible for setting or
specifying safety requirements and targets for its subsystems. In some instances, the railway
duty holder may set or specify safety requirements and safety targets for lower level subsystems
or for specific hazards in agreement with rules given by the legal framework.
1144
1145
1146
1147
6.3.4
Railway system structure and apportionment of RAMS requirements
6.3.4.1 The Railways system, as with any system, can be viewed from a physical or functional
perspective. No single view or breakdown of the system will suit all needs, and the view
ultimately adopted is dependent on the user and their requirements.
1148
1149
1150
1151
1152
1153
1154
6.3.4.2 Based on the concept of system hierarchy (6.2.1), it would then be the task of the
body/entity responsible for each of the subsystems to map or apportion the RAMS requirements
to their subsystems/components. Defining precise boundaries and boundary conditions will
support this apportionment. It is often helpful for this task to be carried out with the cooperation
of the responsible body/entity of the subsystems/components to ensure that the requirements
and targets are practicable. This process may require several iterations to ensure that the
overall system is optimised.
1155
1156
1157
1158
1159
6.3.4.3 A similar reference system may be considered to support this apportionment. However
any differences, functional, technical, operational or in the application environment (e.g. system
boundaries and boundary conditions; maintenance and operational competence levels;
functional and technical interfaces with its environment, especially with other systems etc.), and
the effect of the differences on the RAMS performance should be evaluated for acceptability.
1160
6.4
Railway RAMS and quality of service
1161
6.4.1
This subclause introduces the link between RAMS and quality of service.
1162
1163
1164
1165
1166
1167
1168
6.4.2
RAMS is a characteristic of a systems long term operation and is achieved by the
application of established engineering concepts, methods, tools and techniques throughout the
life-cycle of the system. The RAMS of a system can be characterised as a qualitative and
quantitative indicator of the degree that the system, or the sub-systems and components
comprising that system, can be relied upon to function as specified and to be both available and
safe over a period of time. System RAMS, in the context of this European Standard, is a
combination of the interrelated characteristics, reliability, availability, maintainability and safety.
1169
1170
1171
1172
1173
1174
6.4.3
The goal of a railway system is to achieve a defined level of rail traffic at a given time,
safely within certain cost limits. Railway RAMS describes the confidence with which the system
can guarantee the achievement of this goal. Railway RAMS has a clear influence on the quality
with which the service is delivered to the customer. Quality of Service is influenced by other
characteristics concerning functionality and performance, for example frequency of service,
regularity of service and fare structure.
1175
6.5
1176
1177
This subclause introduces the interaction between RAMS elements, reliability,

6.5.1
availability, maintainability and safety, in the context of railway systems.
Elements of railway RAMS
prEN 50126-1
- 30 -
1178
1179
1180
6.5.2
A dependable railway system can be realised through consideration of the interactions
of system's RAMS elements and the specification and achievement of the optimum RAMS
combination for the system.
1181
1182
1183
1184
1185
1186
6.5.3
The RAMS elements are inter-linked in the sense that a weakness in any or
mismanagement of conflicts between their requirements may prevent achievement of a
dependable system. For example, a safety target may be achieved by ensuring the system
enters a safe state in the event of a particular failure. However, should this safe state be
detrimental to reliability/availability (e.g. train at standstill), a different and optimised solution
may be required to achieve the RAMS targets.
1187
1188
1189
1190
6.5.4
Attainment of in-service availability targets will be achieved by optimising reliability &
maintainability whilst considering the influence of maintaining safety. The related requirements
should be met and controlled through the ongoing, long-term, maintenance and operational
activities and the system environment.
1191
1192
1193
1194
6.5.5
Security, as an element that characterises the resilience of a railway system to
vandalism and unreasonable human behaviour, can be considered as a further aspect of RAMS.
Consideration of security is outside the scope of this standard. However, security could be
considered by the same processes and methods.
1195
1196
6.5.6
Technical concepts of availability are based on a knowledge of:
a) reliability and safety in terms of:
1197
all possible system failure modes in the specified application and environment;
1198
the frequency of occurrence or the likelihood of each failure mode;
1199
the consequences of the failure mode on the functionality of the system.
1200
b) maintainability in terms of:
1201
time for the performance of planned maintenance;
1202
time for detection and identification of the faults;
1203
time for the restoration of the failed system (unplanned maintenance).
1204
c) operation and maintenance in terms of:
1205
1206
all possible operation modes and required maintenance (taking into account cost
issues), over the system life-cycle;
1207
the human factor issues;
1208
tools, facilities and procedures for effective maintenance of the system.
1209
1210
1211
6.5.7
Technical concepts of safety are based on a knowledge of:
a) all possible accidents and associated hazards that could result from a failure in the
system, under all operation, maintenance and environment modes;
1212
b) the characteristic of each hazard in terms of the severity of its consequences;
1213
c) safety-related failures in terms of:
1214
All system failure modes that could lead to a hazard (safety-related failure modes);
1215
1216
The frequency of occurrence or the probability of of each relevant safety-related

system failure mode;
1217
1218
1219
Sequence and/or coincidence of events, failures, operational states, environment

conditions, etc., in the application, that may result in an accident (i.e. a hazard
resulting in an accident);
1220
1221
The frequency of occurrence or the probability of the relevant events, failures,

operational states, environment conditions etc., in the application.
1222
d) maintainability of safety-related parts of the system in terms of:
- 31 -
prEN 50126-1
1223
1224
the ease of performing maintenance on those aspects or parts of the system or its
components that are associated with a hazard or with a safety-related failure mode;
1225
1226
possible errors occurring during maintenance actions on those safety-related parts of

the system;
1227
time for restoring the system into a safe state.
1228
e) system operation and maintenance of safety-related parts of the system in terms of:
1229
human factors influence on the maintenance and the operation;
1230
1231
Tools, facilities and procedures for effective maintenance of the system and for safe
operation;
1232
1233
effective controls and measures for dealing with a hazard and mitigating its
consequences.
1234
1235
1236
1237
1238
6.5.8
Failures in a system operating within the bounds of an application and environment will
have some effect on the behaviour of the system. Failures will have an impact on the system's
reliability, availability and safety, with the level of impact being determined by the system
functionality and design. All failures will also have a cost implication. The environment and the
operational rules may also influence these effects.
1239
6.6
1240
1241
1242
1243
1244
General
6.6.1
6.6.1.1 This subclause introduces and defines a process to support the identification of factors
which influence the RAMS performance of railway systems, with particular consideration given
to the influence of human factors. These factors, and their effects, are an input to the
specification of RAMS requirements for systems.
1245
6.6.1.2 The RAMS performance of a railway system is influenced in three ways:
Factors influencing railway RAMS
1246
1247
by sources of failure introduced internally within the system at any phase of the system
life-cycle (system conditions);
1248
1249
by sources of failure imposed on the system during operation (operating & environmental
conditions) and;
1250
1251
by sources of failure imposed on the system during maintenance activities (maintenance

conditions).
1252
1253
1254
1255
1256
These sources of failure can interact.

6.6.1.3 To create dependable systems, factors which could influence the RAMS of the system
need to be identified, their effect assessed and the cause of these effects managed throughout
the life-cycle of the system, by the application of appropriate controls (see 6.7) to optimise
system performance.
1257
1258
1259
6.6.2
Classes of failures
6.6.2.1 Failures in a safety-related system, product or process are categorized as random
failures or systematic failures.
1260
1261
1262
Random failures are due to physical causes. Sometimes it can be challenging to

separate random failures from those which statistically appear as being nearly randomly
occurring, although they are of systematic nature (e. g. wear out);
1263
1264
1265
1266
1267
1268
1269
Systematic failures are failures due to errors, which cause the product, system or
process to fail deterministically under a particular combination of inputs or under
particular conditions (e.g. combination of inputs or/and triggering events such as nonfulfilment of environmental or application conditions). Systematic failures are mainly
caused by human errors in the various stages of the system life-cycle (concept,
requirements specification, design, manufacture, Integration, operation, maintenance
and modification). This applies for systematic failures in software as well as in hardware.
prEN 50126-1
1270
1271
- 32 -
6.6.2.2 The clear distinction between random and systematic failures might be blurred by the
following observations.
1272
1273
1274
1275
Systematic failures are reproducable, if conditions can be exactly replicated. If these

conditions (the combination of input that activates them) are by themselves a random
event, the occurrence of the systematic failures also exhibit a temporal random
behaviour viewed from the outside;
1276
1277
1278
Large fractions of failures, due to environmental conditions (e.g. temperature, moisture,

humidity etc.) and external influences (EMC, vibration), may be considered both
systematic or random as well;
1279
1280
Finally, for both the classes it holds true that the exact time of the occurrence is
practicably not predictable.
1281
1282
1283
6.6.2.3 A major distinguishing feature between random failures and systematic failures is that
random failures are in general due to events that can be statistically monitored and therefore
predicted. Systematic failures are due to events that cannot be statistically predicted.
1284
6.6.3
1285
1286
1287
1288
1289
1290
1291
This subclause details a process for the derivation of those factors which will affect the
successful achievement of a system which complies with specified RAMS requirements.
6.6.3.1 The process of deriving detailed influencing factors can be supported by the use of the
two checklists covering generic and railway specific factors (6.6.3.2.1) as well as human factors
(6.6.3.3), a core aspect within an integrated RAMS management process. Through the
assessment of each generic influencing factor within the context of the specific system, the
detailed factors which influence the RAMS of railway systems can be systematically derived.
1292
6.6.3.2 The railway duty holder should specify any applicable factors in their call for tenders.
1293
1294
1295
6.6.3.2.1 The derivation of detailed railway specific influencing factors should include, but not be
limited to, a consideration of each of the following factors. It should be noted that the following
checklist is non-exhaustive and should be adapted to the scope and purpose of the application:
1296
1297
Derivation of detailed railway specific influencing factors
a) system conditions:
system operation:
1298
1299
the tasks which the system has to perform and the conditions in which the tasks
have to be performed (mission profile, procedures);
1300
1301
the co-existence of passengers, freight, staff and systems within the operating
environment;
1302
maintainability;
1303
1304
system life requirements, including system life expectancy, service intensity and
life-cycle cost requirements.
1305
failure categories:
1306
the effects of failure within a distributed railway system;
1307
random failure (stress degradation, wear out, over stress etc.);
1308
1309
1310
systematic failures (errors in requirements, design & realisation inadequacies,

manufacturing deficiencies, inherent weaknesses, software errors, operating
instruction deficiencies, installation inadequacies, human errors etc.).
1311
b) operations conditions:
1312
environment;
1313
the physical environment;
1314
1315
the constraints imposed by existing infrastructure and systems on the new system
under consideration
1316
the high level of integration of railway systems within the environment;
- 33 1317
1318
prEN 50126-1
the limited opportunity for testing complete systems in the railway environment.
c) application conditions:
1319
the constraints imposed by the system on operation and maintenance;
1320
1321
the need to maintain rail services during life-cycle tasks (e.g. operating under
degraded mode during maintenance);
1322
human factors;
1323
diagnostics;
1324
installation conditions;
1325
1326
the integration of existing systems and new systems during commissioning and
operation.
1327
d) maintenance conditions
1328
preventive & corrective maintenance;
1329
human factors;
1330
logistics;
1331
diagnostics;
1332
trackside-based maintenance conditions.
1333
1334
1335
6.6.3.2.2 It is recommended to use a diagrammatic approach to derive detailed factors, such as

the use of cause/effect diagrams. An example of a much simplified cause/effect diagram is
shown in Figure 3.
prEN 50126-1
- 34 -
Machine
Material
Man
Training
Lubricants
Staff Selection
Consumables
Equipme
Operation
Maintenance
Energy
Raw
Culture
Material
RAMS
performance
Climate
Management
Monitoring
Operational
Procedures
Text Case
Maintenance
Procedures
Organisation
Mother Nature
Measurement
Documentation
Method
1336
1337
Figure 3 Example of deriving cause/effect relations in a diagrammatic approach 2)
1338
1339
6.6.3.3 Human factors
1340
1341
1342
6.6.3.3.1 An analysis of human factors, with respect to their effect on system RAMS, is inherent
within the systems approach applied by this standard. Guidance given by standards is rare but
e.g. guidance on ergonomic design can be found in European Standard EN 614.
1343
1344
1345
1346
1347
6.6.3.3.2 Human factors can be defined as the impact of human characteristics, expectations
and behaviour upon a system. These factors include the anatomical, physiological and
psychological aspects of humans. The concepts within human factors are used to enable people
to carry out work efficiently and effectively, with due regard for human needs on issues such as
health, safety and job satisfaction.
1348
1349
1350
1351
6.6.3.3.3 Each human might react to situations in different ways which impacts the RAMS
performance. The achievement of railway RAMS requires more rigorous control of human
factors, throughout the entire system life-cycle, than is required in many other industrial
applications.
2) based on The 6 Ms by K. Ishikawa (1960)
- 35 -
prEN 50126-1
1352
1353
1354
1355
1356
1357
1358
1359
1360
Humans have the ability to influence the RAMS of a railway system positively or negatively. To
maximise the positive influence and minimise the negative influence, the manner in which
human factors can influence railway RAMS should be identified and managed throughout the
life-cycle. This analysis should not only include the potential impact of human factors on railway
RAMS within the operational phase, but also within the other phases of the system in
accordance with the risk assessment. The precise influence of human factors on RAMS is
specific to the application under consideration. For guidance and methods to analyse the
influence of human factors on RAMS, standards like VDI 4006, Human Reliability may be
considered.
1361
1362
1363
1364
1365
6.6.3.3.4 Human influence can be regarded as having both random and systematic aspects. All
humans are subject to occasional lapses in performance. When these occur in the operational
and maintenance phases of the system life-cycle they tend to result in random failures: when
they occur in earlier phases of the life-cycle they may result in systematic failures in the
operational phase.
1366
1367
1368
6.6.3.3.5 Lack of competence can lead to systematic human error, where lack of knowledge or
understanding can result in the same incorrect action always being taken under the same
circumstances. This can affect all phases of the life-cycle.
1369
1370
1371
6.6.3.3.6 The derivation of detailed human influencing factors should include, but not be limited
to, a consideration of each of the following human factors. It should be noted that the following
checklist is non-exhaustive and should be adapted to the scope and purpose of the application.
1372
a) the allocation of system functions between human and machine;
1373
b) the effect on human performance within the system of:
1374
the human/system interface;
1375
the environment, including the physical environment and ergonomic requirements;
1376
human working patterns;
1377
human competence;
1378
the design of human tasks;
1379
human interworking;
1380
human feedback process;
1381
railway organisational structure;
1382
railway culture;
1383
professional railway vocabulary;
1384
problems arising from the introduction of new technology.
1385
c) requirements on the system arising from:
1386
human competence;
1387
human motivation and aspiration support;
1388
mitigating the effects of human behavioural changes;
1389
operational safeguards;
1390
human reaction time and space;
1391
1392
d) the requirements on the system arising from human information processing capabilities,
including:
1393
human/machine communications;
1394
density of information transfer;
1395
rate of information transfer;
1396
the quality of information;
1397
human reaction to abnormal situations;
prEN 50126-1
- 36 -
1398
human training;
1399
supporting human decision making processes;
1400
other factors contributing to human strain.
1401
e) the effect on the system of human/system interface factors, including:
1402
1403
the design and operation of the human/system interface; the provision of user
manuals etc.;
1404
the effect of human error;
1405
the effect of deliberate human rule violation;
1406
human involvement and intervention in the system;
1407
human system monitoring and override;
1408
human perception of risk;
1409
human involvement in critical areas of the system;
1410
human ability to anticipate system problems;
1411
1412
human reaction under different operating modes (e.g. normal, degraded or

emergency).
1413
f)
human factors in system design and development, including:
1414
human competency;
1415
human independence during design;
1416
human involvement in verification and validation;
1417
interface between human and automated tools;
1418
systematic failure prevention processes (e.g. measures to assure safety integrity).
1419
1420
1421
1422
1423
6.6.4
Evaluation of factors
6.6.4.1 The potential effect of each influencing factor on the RAMS of the railway system under
consideration can be identified through evaluation at the appropriate level. An appropriate and
comprehensive specification of RAMS requirements can be ensured by addressing the
interaction of associated influencing factors including human factors.
1424
6.7
1425
1426
1427
1428
General
6.7.1
6.7.1.1 The main goal of RAMS activities is to achieve a system performance that meets the
RAMS requirements. Therefore, they have to be properly specified. EN 50126-2 provides
methods for deriving and specifying system safety requirements
1429
1430
1431
1432
1433
6.7.1.2 To achieve the required quality the parameters influencing the RAMS performance need
to be controlled throughout the life of the system. Effective control requires the establishment of
mechanisms and procedures to defend against sources of error being introduced during the
realisation and support of the system. Such defences need to take account of both random and
systematic failures.
1434
1435
1436
6.7.1.3 The means used to achieve RAMS requirements are based on the concept of taking
precautions to minimise the possibility of an impairment occurring as a result of an error during
the life-cycle phases. Precaution is a combination of:
Specification of railway RAMS requirements
1437
prevention: concerned with lowering the likelihood of the impairment and
1438
1439
protection / mitigation: concerned with lowering the severity of the consequences of the
impairment.
1440
Prevention is preferred.
- 37 -
prEN 50126-1
1441
1442
6.7.2
RAMS specification
6.7.2.1 The specification of RAMS requirements is a complex process.
1443
1444
1445
1446
1447
1448
6.7.2.2 Suitable parameters to characterise reliability, availability, maintainability, logistic

support and safety requirements of railway systems are shown in Annex B. Specific parameters
will depend on the system under consideration. All RAMS parameters used should be agreed
between the railway duty holder and the railway supplier on the basis of the rules given by the
legal framework. Where parameters may be expressed in alternative dimensions, conversion
factors should be provided.
1449
1450
1451
1452
A list of suitable tools for RAMS activities is also included in Annex A. Selection of an
appropriate tool will depend on the system under consideration and on factors such as the
criticality, novelty, complexity etc. of the system. Annex A and Annex B are for guidance only
and have been populated using rolling stock as an example.
1453
6.8
1454
1455
1456
6.8.1
The risk based approach involves managing RAMS activities based on decisions which
are derived from considerations on risk. Risk is the combination of two elements:
the expected frequency of occurrence of loss and;
1457
Risk based approach
the degree of severity of this loss (consequence).
1458
1459
1460
1461
1462
The risk based approach aims to identify risks, derive requirements and implement measures to
avoid or control these risks. Finally it is characterised by judgement on the acceptance of the
remaining risks by use of acceptance criteria if needed derived by the application of risk
acceptance principles. This approach is fundamental to the RAMS management process which
allows to manage RAMS through the whole product life-cycle.
1463
In the context of safety, loss may imply human and/or environmental harm. Details are given in
1464
1465
based);
1466
1467
based);
1468
Table D.4 - Severity categories (example 1 related to RAMS)
1469
Table D.5 - Categories (example 2 related to Safety)
1470
for safety aspects, and in
1471
Table D.3 - Severity categories (example related to RAM);
1472
Table D.6 - Financial severity levels (example)
1473
for non-safety aspects.
1474
1475
1476
1477
Environmental loss is often taken into account in a qualitative manner, and usually not included
in the safety studies. However, it is recommended that its exclusion be agreed between the duty
holder and the relevant safety authority, as long as there are no contradictions to the given legal
framework.
1478
1479
1480
1481
It should be noted that commercial aspects of safety can be considered for completeness of
safety concepts, but are not usually included in safety studies. The relationship of risk terms is
shown in Figure 4 below, as a safety-related example. It has to be adapted to RAM aspects
correspondingly.
prEN 50126-1
cause
1
- 38 -
hazard 1
hazard
other events or
circumstances
cause
&
hazard x
&
triggering
event
accident A3
accident A1
&
accident A2
other events or
different
circumstances
1482
1483
Figure 4 Relationship of cause, hazard and accident
1484
1485
6.9
Risk reduction strategy
1486
6.9.1
Introduction
1487
1488
The strategy of risk reduction applies to all risks related to RAMS. The objective of the strategy
is to reduce risk to an acceptable level whenever a risk is analysed as being not acceptable
1489
The risk can be reduced by decreasing the frequency of loss and/or its severity.
1490
1491
1492
As an additional perspective to the application of the RAMS management process, the following
guidance derived from ISO/IEC GUIDE 51 is given. It concentrates on risks related to safety.
Nevertheless, these considerations can be applied to RAM as well in an adapted sense.
1493
1494
1495
6.9.2
Reduction of risks related to safety
6.9.2.1 This subclause describes a best practice approach to reduce risk. The following steps
should be applied in order and assessed on the basis of their practicability.
1496
1497
1498
An initial goal of any safety-related activity is to determine if the hazard can be practicably
avoided. If this is not possible, it should be considered if the frequency of occurrence of this
hazard could be reduced to an acceptable level.
1499
1500
If not sufficient, the next goal is to ensure that the frequency of a hazard turning into an accident
is kept as low as possible.
1501
1502
If this cannot be reduced sufficiently, the severity of loss, resulting from the accident (hazards
consequence), should be minimised.
1503
1504
The approach and the steps necessary to ensure safety in designing equipment as well as for
setting operational rules are:
1505
1506
a) make the function under consideration safe.

The best way to achieve this goal is making the function fail-safe.
1507
Failsafe techniques have the following properties:
1508
no single failure leads to an unsafe condition (for reasonably foreseeable failures);
- 39 -
prEN 50126-1
1509
1510
1511
1512
single failures are detected, negated (a safe state is enforced) and such safe state is
retained (the system is locked in the safe state).
More guidance can be found in EN 50126-2. Further guidance for E/E/PE safety-related
systems can be found in EN 50126-4.
1513
1514
1515
1516
The safe failure mode is a relative concept, and the related arguments are part of the
safety analysis. Some systems do not have one single status that is safe under all
circumstances. For example, automatically stopping a train if an emergency is detected
is usually safe but sometimes dangerous (e.g. burning train stopped in a tunnel).
1517
1518
1519
1520
1521
b) If necessary, provide safety functions in addition or any other barrier.

Wherever necessary, functions especially dedicated to increase safety should be
implemented. This applies for all technologies and for operational rules as well. It has to
be ensured, that the performance of this safety functions is adequately checked in the
required intervals.
1522
1523
1524
1525
c) If necessary, provide safety-related information in addition.

According to the above, additional measures might be necessary, expressed as
additional constraints improving safety (e.g. related to application, maintenance,
operation).
1526
1527
1528
1529
6.9.2.2 More guidance for safety aspects can be found in EN 50126-2. The risk reduction
approach presented in sub-clause 6.9.2.1 can also be applied to RAM aspects. See the
examples provided in Annex F. The reduction then relates to losses (e.g. reliability, financial)
rather than hazards/accidents.
1530
6.10
1531
1532
1533
1534
1535
Safety integrity concept

6.10.1
6.10.1.1 Safety integrity is the property of a safety-related requirement, being fulfilled and
maintained constantly over time. This term has a general meaning and can be applied to
different aspects of safety: e.g. one could consider high integrity solutions for functional,
architectural, operational and process requirements.
1536
1537
1538
6.10.1.2 What is important, in the concept of safety integrity, is that no safety-related system
can be viewed as being without any remaining error. Therefore one should expect failures, and
make appropriate provision.
1539
1540
1541
1542
Safety integrity can be affected both by random and systematic failures. It expresses the level of
confidence that the achievement of the safety requirement is not corrupted by both systematic
and random failures respectively.
6.10.1.3 Prevention of systematic and random failures may require different approaches:
Safety integrity
1543
1544
1545
The Random failure aspect of safety integrity is achieved by product design (e.g.
diversity, redundancy, defences for expected environmental conditions foreseen in
specific Codes of Practice etc.);
1546
1547
1548
1549
The Systematic failure aspect of safety integrity can also get advantage from technical
defences embedded in the product (diversity, for instance), but it requires mainly
process solutions such as quality management, safety management, and organizational
measures;
1550
1551
1552
Applying corrective maintenance actions will be sufficient in case of random causes.

However, in the case of systematic errors corrective maintenance can only provide a first
response and further measures will be required;
1553
1554
When well-defined failure models and common data-bases are available, a quantitative
assessment can be carried out for the random failure aspect of safety integrity;
1555
1556
There is currently no commonly accepted basis for quantifying systematic failures. Therefore,
the methods defined in this standard preclude quantification of systematic failures.
prEN 50126-1
- 40 -
1557
Management of railway RAMS
1558
7.1
RAMS process
1559
1560
1561
1562
7.1.1
General
7.1.1.1 Clause 7 of this European Standard defines a management process, based on a system
life-cycle, which will enable the control of RAMS factors specific to railway applications. This
procedure called RAMS process supports the:
1563
definition of RAMS requirements;
1564
assessment and control of threats to RAMS;
1565
planning and implementation of RAMS tasks;
1566
achievement of compliance with RAMS requirements;
1567
on-going monitoring, during the life-cycle, of compliance.
1568
1569
1570
1571
7.1.1.2 Although railway RAMS is the focus of this European Standard, it is one of many aspects
of a total railway system. This standard defines a systematic process for RAMS management
such that the process is one component of an integrated management approach which
addresses all aspects of the complete railway system.
1572
1573
1574
7.1.1.3 The railway duty holders bear the primary responsibility for assessing, controlling and
reducing risk. For this task it may be necessary to obtain the relevant RAMS related information
from the railway suppliers about the involved products.
1575
As a general guideline, for a typical railway project, the following applies:
1576
Requirements are usually established by the customer or a safety (legal) authority;
1577
1578
Approval is carried out by a safety authority or its representative within the legal
framework and acceptance is carried out by the customer;
1579
1580
Solutions, their results and verifications are normally elaborated or performed by the
contractor;
1581
Validation is normally performed jointly.
1582
1583
1584
1585
This general rule, however, depends on the contractual and legal relationship between the
parties involved. However, this standard requires that, in each case, the responsibilities for the
tasks in the various life-cycle phases are defined and agreed.
7.1.1.4 All requirements derived from this clause are specified in clause 8 RAMS life-cycle.
1586
1587
1588
1589
1590
Safety management within the RAMS Process

7.1.2
7.1.2.1 Safety management is a part of the overall management process for RAMS described in
this standard. The focus of this process is to reduce the incidence of safety-related failures
and/or the consequences throughout the life-cycle, and thus minimise the residual risk resulting
from these errors.
1591
1592
1593
1594
1595
In all cases the risk analysis process defined in this standard is necessary in order to identify
the degree of safety required for each particular situation.
7.1.2.2 The tolerable safety risk of a railway system is dependent upon the safety criteria set by
the legal framework, or by the railway duty holder in accordance with the rules given by legal
framework.
1596
1597
7.1.2.3 If required for the derivation of safety requirements for generic products, the suppliers
should use the risk acceptance criteria which are foreseen to be required.
1598
1599
7.1.2.4 The safety management process shall be implemented under the control of an
appropriate organisation, using competent personnel assigned to specific roles.
- 41 -
prEN 50126-1
1600
1601
1602
1603
7.1.2.5 Assessment and documentation of personnel competence, including technical

knowledge, qualifications, relevant experience and appropriate training, shall be carried out in
accordance with documented requirements to be defined by the safety management
organisation.
1604
1605
7.1.2.6 The level of technical education, the extent of experience, and the need for updating or
refreshing of training shall be appropriate to the safety requirements of the application.
1606
1607
1608
1609
7.1.3
Independence of roles
7.1.3.1 Many roles within an organisation, such as verifier, tester, validator or assessor, are
concerned with confirming the RAMS performance of what has been produced by other roles
(e.g. implementer).
1610
1611
7.1.3.2 Within the limits given by requirements on the independence of roles, one person may
carry out more than one role.
1612
1613
1614
1615
1616
1617
7.1.3.3 Independence between roles may be required in order to reduce the probability of
people in different roles suffering from the same misconceptions or making the same mistakes.
This form of independence can be achieved by employing different people in different roles but
does not usually require the roles to be located in different parts of the organisation or in
different companies (unless specifically required). More guidance on this issue can be found in
EN 50126-2.
1618
1619
1620
1621
1622
7.1.3.4 It is also important that people in roles which involve making judgements about the
acceptability of a product or process from the point of view of safety should not be influenced by
pressure from their peers or supervisors, or by considerations of commercial gain. This form of
independence is more likely to require different roles to be located in different parts of the
organisation or to be located in a different company.
1623
1624
1625
1626
1627
7.1.3.5 In general, a greater degree of safety requires a greater degree of independence for
various roles. More specific guidance on what degree of independence between roles for the
general safety management process is given in EN 50126-2. Specific guidance on the
independence between roles for the development of hardware and software is given in
EN 50126-4 and EN 50126-5.
1628
7.2
1629
1630
1631
1632
1633
1634
The system life-cycle is a sequence of phases, each containing tasks, covering the
7.2.1
total life of a system, product or process from initial concept through to decommissioning and
disposal. The life-cycle provides a structure for planning, managing, controlling and monitoring
all aspects of a system, including RAMS, as the system progresses through the phases, in order
to deliver the right product in a cost effective manner within the agreed time scales. The lifecycle concept is fundamental to the successful implementation of this standard.
1635
1636
7.2.2
It is important to note that the life-cycle represents a logical sequence rather than an
absolute chronological order.
1637
1638
1639
1640
1641
1642
7.2.3
A system life-cycle, appropriate in the context of railway application, is shown within
Figure 1 (see 5.5). For each phase of the life-cycle, the main tasks are summarised in the
informative Table 1 below. This figure shows RAMS tasks as components of general project
tasks. The general project tasks are outside the scope of this European Standard. RAMS tasks
contribute to the general project tasks for each phase and requirements for the RAMS tasks are
detailed in subsequent clauses of this European Standard.
1643
1644
1645
1646
7.2.3
This standard acknowledges the balance between the RAMS performance of a system
and the costs of development and ownership of the system, known as life-cycle costs. However,
it does not dictate solutions to RAMS issues on the basis of cost since cost requirements are
outside the scope of this standard.
1647
1648
1649
7.2.4
Clause 8 and its subclauses define the objectives, requirements, inputs and
deliverables for RAMS tasks in a consistent format, and within an overall project context, for
each life-cycle phase.
System life-cycle
prEN 50126-1
- 42 -
1650
1651
1652
1653
1654
7.2.5
In the context of a procurement process, roles and responsibilities for carrying out
RAMS tasks should be clarified.
Responsibilities for carrying out the tasks will depend on the system under consideration and
the contract conditions applicable. Some general guidelines for establishing these
responsibilities are given in 7.1.1.3.
1655
1656
1657
This standard represents the system life-cycle sequentially. This representation shows
7.2.6
individual phases and the links between phases. Other life-cycle representations are widespread
within industry and may be used as long as they follow the requirements of this standard.
1658
1659
1660
1661
1662
7.2.7
A V representation of the life-cycle contained within this standard is shown in Figure
5 below. The top-down branch (left side) is generally called development and is a refining
process ending with the manufacturing of system components. The bottom-up branch (right
side) is related to the assembly, the installation, the receipt and then the operation of the whole
system.
1663
1664
1665
1666
7.2.8
Validation activities in earlier life-cycle phases (requirement validation)
Validation activities in earlier life-cycle phases (before phase 9, see section 8) should be carried
out in order to minimise possible deviations from the RAMS requirements, the results of the risk
analysis and the intended use.
1667
These validation tasks should be documented with the following content:
1668
1669
a) assessment of the adequacy of the information, and where appropriate, data or other
statistics, used as input to risk assessment;
1670
b) evaluation of the consistency and adequacy of the risk analysis;
1671
1672
c) evaluation whether the requirements are adequately analysed and specified in order to
allow the system under consideration to serve the intended purpose.
1673
1674
1675
1676
7.2.9
Validation activities in late life-cycle phases (system validation)
For late life-cycle phases the "V" representation assumes that the validation activities are linked
to the development activities insofar as what is actually designed has to be finally checked with
regard to the requirements (see Figure 5 below as an example).
1677
1678
1679
In systems consisting of subsystems, a hierarchical structure of validation activities according to

the various subsystems may be appropriate. Hence, validation activities shall be planned in an
early life-cycle phase.
1680
These validation tasks shall be documented with the following minimum content:
1681
a) identification of the configuration of the system, product or process subject to validation;
1682
b) evaluation of the consistency and adequacy of the hazard analysis;
1683
1684
c) evaluation of the completeness, correctness, consistency and adequacy of the

verification activities;
1685
1686
d) evidence that all planned validation activities have been carried out with justification of
any deviation from the RAMS Validation Plan;
1687
1688
e) evidence of the completeness, correctness, consistency and adequacy of exported

application conditions and safety-related manuals.
1689
1690
1691
1692
7.2.10
The following validation tasks shall be documented by validation or, if required, by an
Independent Safety Assessment:
a) evaluation of the conformity of the life-cycle process and of the validated item against the
requirements of this European Standard including the required safety integrity;
1693
b) assessment of the competence of all personnel undertaking tasks within the phase;
1694
c) assessment of the adequacy and completeness of the RAMS Validation Plan;
1695
d) assessment of the adequacy and completeness of the safety case;
- 43 -
prEN 50126-1
1696
1697
e) assessment of the adequacy and completeness of the training measures with regard to
RAMS aspects.
1698
1699
1700
7.2.11
The objective of verification is to demonstrate that the deliverables of each phase meet
in all respects the requirements of that phase. Within the scope of verification it may also be
necessary to consider the input and process of a phase.
1701
1702
1703
7.2.12
In this standard, verification tasks are included within each life-cycle phase. This
standard addresses verification and validation tasks in the context of RAMS. Nevertheless,
these tasks should be an integral part of the overall system verification and validation tasks.
1704
1705
7.2.13
All requirements derived from this clause are specified in clause 8 RAMS life-cycle.
1706
Concept
System Definition &

Operational Context
Risk Analysis &

Evaluation
10
System Acceptance
Specification of 4
System Requirements
System Validation
Architecture and Apportionment

of System Requirements
Design and
Implementation
Manufacture
1707
1708
Figure 5 The "V" representation drawing
Integration
11
Operation,
Maintenance and
Performance
Monitoring
12
Decommissioning
- 45 -
prEN 50126-1
verification
Life-cycle
phase
Input
1709
1710
Output
Figure 6 - verification
Requirements
validation
System
User
1711
1712
1713
Figure 7 - validation
1714
1715
7.2.14
In each life-cycle phase, the verification tasks shall include the following:
a) evaluation of the correctness and adequacy of the safety analysis;
1716
1717
b) verification of the deliverables of the phase for compliance with the deliverables of former
phases;
1718
1719
c) verification of the deliverables of the phase for compliance with the requirements for this
phase defined in this standard;
1720
d) assessment of the adequacy of the methods, tools and techniques used within the phase;
1721
1722
e) evaluation of the correctness, consistency and adequacy of test cases and executed
tests.
1723
1724
7.2.15
Any errors or deficiencies found may require the re-application of some or all of the
activities of one or more previous life-cycle phases.
prEN 50126-1
1725
- 46 -
Table 1 - System phase related tasks informative

life-cycle phase
Phase related general tasks
Phase related RAM tasks
Phase related Safety tasks
1.
Concept
- Establish scope and purpose of railway

project
- Define railway project concept
- Undertake financial analysis & feasibility
studies
- Establish management arrangements
- Review previously achieved RAM performance

- Consider RAM implications of project
- Review previously achieved safety

performance
- Consider safety implications of project
- Review safety policy & safety targets
2.
System definition
and operational
context
- Evaluate past experience data for safety

- Establish safety plan (overall)
- Identify influence on safety of existing
infrastructure constraints
3.
Risk analysis and

evaluation
- Undertake project related risk analysis
4.
Specification of
system
requirements
Undertake requirements analysis

Specify system (overall requirements)
Specify environment
Define system demonstration & acceptance
Criteria (overall requirements)
- Establish validation plan
- Establish management, quality & organisation
requirements
- Implement change control procedure
5.
Architecture and
apportionment of
systems
requirements
- Apportion system requirements

Specify sub-system & component
requirements
Define sub-system & component acceptance
criteria
- Apportion system RAM requirements

Specify sub-system & component RAM
requirements
Define sub-system & component RAM
acceptance criteria
- Update RAM plan
Establish system mission profile

Prepare system description
Identify operation & maintenance strategies
Identify operating conditions
Identify maintenance conditions
Identify influence of existing infrastructure
constraints
Evaluate past experience data for RAM

Perform preliminary RAM analysis
Set RAM policy
Establish RAM plan
Identify long term operation & maintenance
conditions
- Identify influence on RAM of existing
infrastructure constraints
- Determine the risk acceptance principles and

criteria
- Perform system risk analysis
- Set-Up hazard log
- Perform risk evaluation
Specify system RAM requirements (overall)
Define RAM acceptance criteria (overall)
Define system functional structure
Update RAM plan
Specify system safety requirements (overall)

Define safety acceptance criteria (overall)
Define safety-related functional requirements
Establish safety validation plan
- Apportion system safety targets &

requirements
Specify sub-system & component safety
requirements
Define sub-system & component safety
acceptance criteria
- Update safety plan and safety validation plan
- 47 life-cycle phase
1726
1727
Phase related general tasks
prEN 50126-1
Phase related RAM tasks
Phase related Safety tasks
- Implement RAM plan by

- Review, analysis, testing and data
- Assessment, covering:
Reliability & availability
Maintenance & maintainability
Optimal maintenance policy
Logistic support
- Undertake programme control, covering:
RAM programme management
Control of sub-contractors & suppliers
- Implement safety plan by review, analysis,

testing and data assessment, addressing:
- Hazard log
- Hazard analysis
- Justify safety-related design decisions
- Undertake programme control, covering:
Safety management
Control of sub-contractors & suppliers
- Prepare generic product safety case
- Prepare (if appropriate) generic application
safety case
- Assess generic safety cases
- Perform production planning

- Manufacture
- Manufacture and test sub-Assembly of
components
- Prepare documentation
- Establish training
- Perform environmental stress screening

- Perform RAM improvement testing
- Commence failure reporting and corrective
action system (FRACAS)
- Implement safety plan by: review, analysis,

testing & data assessment
- Use hazard log
Integration
- Assemble system
- Install system
- Start maintainer training

- Establish spare parts and tool provision
- Establish installation programme

- Implement installation programme
- Derive safety-related application conditions
System validation
- Commission
- Perform probationary period of operation
- Undertake training
- Perform RAM demonstration
10. System
acceptance
- Undertake acceptance procedures, based on

acceptance criteria
- Compile evidence for acceptance
- Entry into service
- Continue probationary period of operation (if
appropriate)
- Assess RAM demonstration
- Assess specific application safety case
11. Operation,
maintenance and
performance
- On going procurement of spare parts & tools

- Perform on going reliability centred
maintenance, logistic support
- Collect, analyse, evaluate and use
performance & RAM statistics
- Undertake on going safety centred

maintenance
- Perform on going safety performance
monitoring and hazard log maintenance
- Collect, analyse, evaluate and use
performance & safety statistics
12. Decommissioning
- Plan decommissioning and disposal

- Undertake decommissioning
- Undertake disposal
- No activity for RAM
- Establish safety plan

- Perform hazard analysis & risk assessment
- Implement safety plan
6.
Design and
implementation
7.
Manufacture
8.
9.
Perform
Perform
Perform
Perform
Perform
design and development

design analysis and testing
design verification
implementation and validation
design of logistic support resources
Long term system operation

Perform on going maintenance
Undertake on going training
Collect operational performance statistics
Acquire, analyse and evaluate data
NOTE 1 Change control or configuration management activity applies to all project phases
Implement commissioning programme

Update validation plan
Implement validation plan
Prepare specific application safety case
prEN 50126-1
1728
1729
1730
1731
1732
- 48 -
NOTE 2 Verification and validation activities apply within most life-cycle phases and are included in the main text
NOTE 3 Note that the scope of this standard is limited to RAMS and does not address all systems assurance activities. However, it is necessary to ensure the synchronisation
between RAMS phases and project related phases, and to agree on the conditions for passing from one phase to another, from RAMS point of view.
NOTE 4 Activities within Phases 9 and 10 may be integrated, depending upon the application under consideration
NOTE 5 The safety plan may be incorporated within an overall RAMS plan.
- 49 -
prEN 50126-1
1733
7.3
Application and tailoring of this standard
1734
1735
This subclause gives requirements to provide a flexible and effective application of this
7.3.1
standard in terms of size, complexity and cost.
1736
1737
1738
1739
7.3.2
The requirements defined in this standard are generic and are applicable to all types of
systems in the railway domain. The railway duty holder shall define the application of the
requirements of this standard to the system under consideration. This definition shall be based
on the applicability of the requirements to the particular system.
1740
1741
1742
1743
7.3.3
In cases of renewal of a system, there is often a "mixed phase" stage where the
operation with the existing and the renewed systems is mixed, or that they are operated at the
same time. In such cases the possible effects of interaction between the existing and the
renewed systems shall be specifically addressed.
1744
1745
1746
7.3.4
A life-cycle model for the development of the system product or process shall be
selected. The life-cycle model shall take into account the possibility of iterations in and between
phases.
1747
1748
1749
7.3.5
The application of this standard shall be tailored to the specific requirements of the
system under consideration. This tailoring should consider the following aspects:
a) constraints given by the railway duty holder;
1750
b) complexity of the system under consideration;
1751
c) the application domain (e.g. signalling, rolling stock, fixed installations);
1752
d) the system development process used;
1753
1754
e) type of development (e.g. generic product, specific application, modification of existing

system).
1755
1756
1757
1758
1759
7.3.6
In case of tailoring the following specifications and justifications shall be elaborated:
a) specify the life-cycle phases which are required to realise the system under
consideration, providing a justification for the life-cycle phases specified and
demonstrating that the tasks undertaken within these life-cycle phases comply with the
principles of the requirements of this standard;
1760
1761
b) specify the life-cycle phases which are not required to realise the system under
consideration and provide an appropriate justification;
1762
1763
1764
c) specify the mandatory activities and requirements of each required life-cycle phase,
using Table 1 and the relevant phase related information of clause 8 RAMS life-cycle as
a checklist, including:
1765
the scope of each requirement in relation to the system under consideration;
1766
1767
the methods, tools and techniques required against each requirement and the scope
and depth of their application;
1768
1769
the verification and validation activities required against each requirement and the
scope of their application;
1770
all supporting documentation.
1771
d) justify any deviation from the activities and requirements of the standard;
1772
e) justify the adequacy of the tasks chosen for the application under consideration;
1773
1774
1775
7.3.7
Even in case of tailoring the following requirements shall be always mandatory:
a) responsibilities for carrying out RAMS tasks including the interfaces between associated
tasks shall be defined for the system under consideration;
1776
1777
b) all personnel with responsibilities within the RAMS management process shall be
competent for those responsibilities;
1778
1779
c) the establishment and implementation of the RAM Plan and Safety Plan are essential
components in the realisation of dependable systems;
prEN 50126-1
- 50 -
1780
1781
1782
d) the RAMS requirements shall be implemented within business processes, supported by a

Quality Management System (QMS) compliant with EN ISO 9001 and appropriate for the
system under consideration;
1783
1784
1785
1786
1787
1788
1789
1790
1791
e) an adequate configuration management system, addressing RAMS tasks, shall be used.

The scope of configuration management will depend on the system under consideration,
but shall at least include all system documentation and all other system deliverables.
7.3.7.1 Mutual recognition (sometimes referred to as cross acceptance) is considered as a
special case of tailoring. The legal aspects which are implied in this topic have to be dealt with
by the legal framework and are not subject of this standard. In order to reuse existing results
and documents compliant with this standard that have been created in other developments the
tailoring discussed above can avoid repetition of processes/tasks. Nevertheless, the following
principles should be addressed:
1792
a) Establish a credible case for the native (baseline) application;
1793
b) Specify the target environment and application;
1794
c) Identify the key differences between the target and native cases;
1795
1796
d) Specify the technical, operational and procedural adaptations required to cater for the
differences;
1797
e) Assess the risks arising from the differences;
1798
1799
f)
1800
g) Develop a generic or specific case for mutual recognition.
Produce a credible case for the adaptations adequately controlling the risks arising from
the differences;
1801
7.4
General requirements on RAMS documentation
1802
1803
The documentation shall record all information relevant to RAMS throughout the life-cycle of the
product.
1804
1805
7.4.1
A process for the maintenance of safety-related documentation shall be defined or
referenced in the safety plan.
1806
1807
7.4.2
For each document, traceability shall be provided in terms of a unique reference
number and a defined and documented relationship with other documents.
1808
1809
7.4.3
Each RAMS document and deliverable shall be placed under configuration control from
the time of its first release.
1810
1811
7.4.4
Any changes to documents under configuration control shall be authorized and
recorded.
1812
1813
1814
7.4.5
Each term, acronym or abbreviation shall have the same meaning in every document.
If this is not possible (e.g. due to historical reasons), the different meanings shall be listed and
the references given.
1815
1816
1817
7.4.6
If documents have a hierarchical relationship, the following requirements shall apply
a) Each document shall contain or implement all applicable conditions and requirements of
the preceding document with which it has a hierarchical relationship;
1818
1819
NOTE Cascading of references increases complexity of verification and validation.
1820
1821
1822
1823
7.4.7
If documents from pre-existing systems, products or processes do not fulfil this subclause it still has to be ensured that these documents are adequately linked to the new
documentation, including applicable conditions. Any contradictions have to be addressed and
the priority level of the documents used to be indicated.
1824
1825
7.4.8
The contents of all documents shall be recorded in a form appropriate for
manipulation, processing and storage.
b) There shall be no contradictions to the preceding document.
- 51 -
prEN 50126-1
1826
1827
1828
7.4.9
When documents which are produced by independent roles are combined into a single
document, the relation to the parts produced by any independent role shall be traced within the
document.
1829
1830
1831
7.4.10
Documents may be combined or divided in accordance with 7.4.9. Where any
alternative life-cycle or documentation structure is adopted it shall be established that it meets
all the objectives and requirements of this European Standard.
1832
1833
1834
7.4.11
Large volumes of detailed information and supporting documentation need not be
included in the RAMS documents, provided precise references are given to such documents and
provided the basic concepts used and the approaches taken are clearly specified.
1835
1836
1837
1838
7.4.12
In this standard, some documents are mentioned several times in the life-cycle
description. This is meant to emphasize that an update of the document might be necessary
depending on the outcome of the respective life-cycle phase. There is no need to produce
separate versions of the document in every instance.
1839
RAMS life-cycle
1840
8.1
General
1841
1842
1843
1844
1845
1846
8.1.1
This clause details objectives, requirements, deliverables and verification & validation
activities to be undertaken throughout each life-cycle phase. Methods, tools and techniques
appropriate to engineering dependable systems are presented in other standards (see
Annex A). The scope and application of the requirements shall be assessed and adapted to
meet the particular requirements of the system under consideration. For further information on
this topic, see 7.3 of this standard.
1847
1848
Generally, the input to each life-cycle phase shall include all relevant information, and
8.1.2
where appropriate, data, necessary to meet the requirements of the phase.
1849
1850
1851
1852
1853
8.1.3
In case of redesign, retrofit or modification all RAMS implications shall be identified.
An impact analysis shall be undertaken in order to decide which parts of the life-cycle shall be
executed.
NOTE The life-cycle can be simplified (by tailoring) since a variety of processes and documents can be reused and
the activities can focus on the deviations to the original system.
1854
1855
1856
8.2
Phase 1: concept
1857
8.2.1
Objectives
1858
1859
The objective of this phase is to develop a sufficient understanding of the system to ensure a
proper performance of all subsequent RAMS life-cycle tasks.
1860
1861
8.2.2
Activities
8.2.2.1 In the context of RAMS performance, the following issues shall be investigated
1862
a) the scope, context and purpose of the system;
1863
b) the environment of the system, including:
1864
physical issues;
1865
potential system interface issues;
1866
social issues;
1867
political issues;
1868
legislative issues;
1869
economical issues.
1870
c) the general RAMS implications of the system.
prEN 50126-1
1871
- 52 -
8.2.2.2 The following issues shall be investigated:
1872
1873
a) previous RAMS requirements and past RAMS performance of similar and/or related
systems;
1874
b) current RAMS policy and targets of the relevant railway duty holders;
1875
1876
1877
c) safety legislation.
8.2.2.3 The scope of the RAMS management requirements for subsequent system life-cycle
RAMS tasks shall be defined.
1878
1879
1880
8.2.3
Deliverables
8.2.3.1 The results of the activities of this phase shall be documented in a concept. This concept
shall include any assumptions and justifications made during this phase.
1881
1882
8.2.3.2 The deliverables shall include the definition of the scope of the RAMS management
requirements.
1883
8.2.4
1884
1885
There are no specific verification requirements for this life-cycle phase in addition to those tasks
required in 7.2.14.
1886
8.2.5
1887
1888
The following validation task shall be undertaken within this phase in addition to those tasks
required in 7.2.8:
-
1889
Specific verification tasks
Specific validation tasks
assessment of the adequacy of the system scope and environment statement.
1890
1891
1892
8.3
Phase 2: system definition and operational context
1893
8.3.1
Objectives
1894
The objectives of this phase are to:
1895
a) define the system and its mission profile;
1896
b) define the boundary of the system;
1897
c) establish the operational requirements influencing the characteristics of the system;
1898
d) define the scope of system risk analysis;
1899
e) establish the RAM plan for the system;
1900
f)
1901
g) define the functions to be provided by the system;
establish the Safety plan for the System;
1902
as far as they affect the potential RAMS performance of the system.
1903
1904
8.3.2
Activities
8.3.2.1 The following issues shall be defined:
1905
a) the system and its mission profile, including:
1906
description of the intended system;
1907
long term operating strategy and conditions;
1908
long term maintenance strategy and conditions;
1909
system life-time considerations;
1910
logistic considerations.
1911
b) the system boundary, including:
- 53 -
prEN 50126-1
1912
1913
interfaces with physical environment (e.g. climatic conditions, mechanical conditions.

altitude);
1914
interfaces with other technological systems;
1915
interfaces with humans;
1916
interfaces with other railway duty holders;
1917
interfaces with existing infrastructure.
1918
c) the scope of operational requirements influencing the system, including:
1919
constraints imposed by existing infrastructure;
1920
system operating conditions and constraints;
1921
system maintenance conditions;
1922
logistic support considerations;
1923
1924
1925
review of past experience data for similar systems.

8.3.2.2 A RAMS policy shall be established which shall include a policy for resolving conflicts
between safety and other aspects like availability, reliability etc.
1926
1927
1928
8.3.2.3 An organisation shall be established which shall allocate the roles, responsibilities,
competencies, independencies and relationships of organisations undertaking RAMS tasks
within the life-cycle process. This shall also serve to resolve conflicts as indicated above.
1929
1930
1931
8.3.2.4 A process for on-going consideration of safety issues and the communication of relevant
knowledge between the stakeholders has to be established. This includes the review of the
adequacy of the safety requirements if new findings call for reconsiderations.
1932
1933
1934
1935
1936
1937
1938
8.3.2.5 The RAM plan for the remaining life-cycle tasks shall be established. The RAM plan shall
include the tasks which are judged to be the most effective to the attainment of the RAM
requirements for the system under consideration. The RAM plan shall be agreed by the railway
duty holder and the railway suppliers for the system under consideration and shall be
implemented throughout the life-cycle of the system. The RAM plan shall arrange the
management to achieve the RAM requirements. This includes details of the policy and strategy
to be applied, the scope of the plan and the planning of the RAM activities.
1939
8.3.2.6 The RAM plan should include the following tasks:
1940
a) management, including details of:
1941
1942
1943
the system life-cycle and RAM tasks and processes to be undertaken within the lifecycle, specifically the order of RAM tasks to ensure maximum benefit to system
design;
1944
1945
1946
a Failure Reporting Analysis and Corrective Action System (FRACAS) to be applied to

the system from phase 7 of the life-cycle (by the railway duty holder and the railway
suppliers, as appropriate) with records including:
1947
technical data on system;
1948
reason for maintenance action;
1949
type of maintenance action;
1950
man-hours & elapsed time for maintenance action;
1951
maintenance down time;
1952
number and skill level of personnel;
1953
spare parts used;
1954
cost of consumables;
1955
reporting and corrective action.
1956
the arrangements to ensure co-ordination of individual RAM elements;
1957
details of all RAM related deliverables from the life-cycle;
1958
details of RAM acceptance tasks;
1959
interfaces with other related programmes and plans;
prEN 50126-1
- 54 -
1960
constraints and assumptions made in the RAM plan;
1961
subcontractor management arrangements.
1962
1963
b) reliability, including:
reliability analysis and prediction, including:
1964
functional analysis and system failure definition;
1965
top down analysis, for example fault tree analysis and block diagram analysis;
1966
bottom up analysis, for example Failure Modes Effects Analysis (FMEA);
1967
common cause failure or multiple failure analysis;
1968
sensitivity analysis and trade-off studies;
1969
reliability apportionment;
1970
human machine interface analysis;
1971
stress analysis.
1972
reliability planning, including:
1973
reliability design review programme;
1974
component reliability assurance programme;
1975
software quality/reliability assurance programme.
1976
reliability testing, including:
1977
reliability growth testing, based on failure generation;
1978
reliability demonstration testing, based on expected failure modes;
1979
environmental stress screening;
1980
life testing of components;
1981
system life testing during early operation.
1982
1983
1984
reliability data acquisition and assessment:

data analysis for reliability improvement.
c) maintainability, including:
1985
maintainability analysis and prediction, including:
1986
maintainability analysis and verification;
1987
maintenance task analysis;
1988
ease-of-maintenance studies and testing;
1989
human factors maintainability considerations.
1990
maintainability planning, including:
1991
maintainability design review programme;
1992
establishment of the maintenance strategy;
1993
review of reliability centred maintenance options;
1994
software maintenance programme.
1995
logistic support evaluation including:
1996
definition of maintenance requirements;
1997
definition of spares policy and support resource;
1998
maintenance personnel and facilities;
1999
personnel safety precautions;
2000
system support requirements;
2001
training programme requirements;
2002
system transportation, packaging, handling and storage conditions.
- 55 2003
maintainability data acquisition and assessment;
2004
data analysis for maintainability improvement.
2005
prEN 50126-1
d) availability, including:
2006
availability analysis;
2007
sensitivity analysis and trade-off studies;
2008
availability demonstration during early operation;
2009
availability data acquisition and assessment;

data analysis for availability improvement and prediction.
2010
2011
2012
NOTE The RAM plan is considered as a living document. If some contents from the above list is not be fully available
in this early life-cycle phase, this information can be added in later life-cycle phases.
2013
2014
2015
8.3.2.7 The Safety Plan for the system shall be established. The Safety Plan shall be
implemented, reviewed and maintained throughout the life-cycle of the system. The Safety Plan
shall arrange the following safety activities:
2016
a) establish the policy and strategy for achieving safety;
2017
b) define the scope of the plan;
2018
2019
c) plan safety activities.

8.3.2.8 The safety plan should include the following tasks:
2020
2021
a) the safety analysis, engineering and assessment processes to be applied during the lifecycle, including processes for:
2022
2023
ensuring an appropriate degree of personnel independence in tasks, commensurate

with the risk of the system;
2024
hazard identification and analysis;
2025
risk assessment and on-going risk management;
2026
risk acceptance criteria and reviewing risk acceptance;
2027
reviewing the effectiveness of risk reduction measures;
2028
the establishment and on-going review of the adequacy of the safety requirements;
2029
system design;
2030
verification;
2031
validation to achieve compliance between system requirements and realisation;
2032
2033
achievement of compliance of the management process with the safety plan (e.g.
confirmed via audits);
2034
2035
2036
safety assurance during the parameterisation of the system (safety classification of

the configuration parameters, safety confidence in the parameterisation process and
tools used).
2037
b) details of all safety-related deliverables from the life-cycle phases, including:
2038
documentation;
2039
hardware;
2040
software.
2041
2042
c) a process to prepare the safety case, considering the hierarchy between system safety
activities and documentation;
2043
2044
d) a process for the safety approval of the system including the interface to the railway duty
holder and the safety authority;
2045
2046
e) a process for analysing operation and maintenance performance to ensure that realised
safety is compliant with requirements;
2047
f)
2048
g) a process for management of the hazard log;
a process for the maintenance of safety-related documentation;
prEN 50126-1
- 56 -
2049
h) interfaces with other related programmes and plans;
2050
i)
constraints and assumptions made in the plan;
2051
2052
j)
subcontractor management arrangements including the identification of the parts of

EN 50126 for which the subcontractor is responsible;
2053
2054
2055
2056
2057
2058
k) requirements for periodic safety audit, safety assessment and safety review, throughout
the life-cycle and appropriate to the safety relevance of the system under consideration,
including any personnel independence requirements.
NOTE The Safety plan is considered as a living document. If some contents from the above list are not fully available
in this early life-cycle phase or changes in a later life-cycle phase, this information can be added in later life-cycle
phases.
2059
2060
2061
8.3.2.9 Annex A of this standard provides an example outline procedure for the definition of a
RAM/safety plan, based on the requirements of this standard. Annex A is informative and for
guidance only and has been populated using rolling stock as an example.
2062
2063
8.3.3
Deliverables
8.3.3.1 The results of this phase shall be documented in an appropriate way, including:
2064
a) a system definition;
2065
b) a RAM plan;
2066
2067
2068
c) a safety plan.
8.3.3.2 This documentation shall include any assumptions and justifications made during this
phase.
2069
8.3.4
2070
2071
required in 7.2.14.
2072
8.3.5
2073
2074
There are no specific validation requirements for this life-cycle phase in addition to those tasks
required in 7.2.8.
2075
2076
2077
8.4
Phase 3: risk analysis and evaluation
2078
8.4.1
Objectives
2079
2080
a) identify hazards associated with the system;
2081
b) identify the events leading to the hazards;
2082
c) determine the risk associated with the hazards;
2083
d) establish a process for on-going risk management.
2084
2085
2086
2087
2088
For the reason of simplification the life-cycle representation in this standard shows risk analysis
as a one time activity in the early stage of a project. At this stage, for some aspects of the risk
analysis only estimations can be made because the detailed design of the product, system or
process is not yet available and analysed. This early risk analysis serves as a basis for defining
the risk based RAMS requirements (see phase 4 of the life-cycle).
2089
2090
Afterwards, an on-going risk management is required in order to make sure that the final
system, product or process fulfils its safety requirements.
- 57 2091
2092
2093
2094
prEN 50126-1
8.4.2
Activities
8.4.2.1 Risk evaluation and acceptance criteria to be applied shall be defined on the basis of the
system definition (phase 2) in accordance with the requirements on risk analysis and evaluation
given in EN 50126-2. This includes to determine the risk acceptance principles to be applied:
2095
a) use of code of practice;
2096
b) use of a similar system as a reference;
2097
2098
2099
2100
NOTE 1 Detailed requirements and guidance on the use of these risk acceptance principles can be found in clause 9
and in EN 50126-2.
c) explicit risk estimation (qualitative or quantitative).
2101
2102
8.4.2.2 All reasonably foreseeable hazards associated with the system in its application
environment shall be systematically identified. This activity should include hazards arising from:
NOTE 2 Different risk acceptance principles can be chosen for each hazard depending on their relevance.
2103
a) system normal operation;
2104
b) system fault conditions;
2105
c) system emergency operation;
2106
d) foreseeable system misuse;
2107
e) system interfaces;
2108
f)
2109
g) system configuration parameters;
2110
h) system operation, maintenance and support issues;
2111
i)
system disposal considerations;
2112
j)
human factors;
2113
k) occupational health issues;
2114
l)
2115
m) electrical environment;
system functionality;
mechanical environment;
2116
2117
2118
2119
n) natural environment to cover such matters as snow, floods, storms, rain, landslides etc.
8.4.2.3 For the purpose of hazard identification it is beneficial to use a structured list of hazards.
This list serves as a basis and is non-exhaustive. If used it shall be checked against the
application and amended if necessary. Refer to Annex C for example hazard lists.
2120
8.4.2.4 The sequence of events leading to hazards shall be identified.
2121
2122
2123
8.4.2.5 The frequency of occurrence of each hazard and the frequency of occurrence of the
expected consequences shall be evaluated in accordance with the defined risk evaluation
criteria.
2124
2125
8.4.2.6 The likely severity of the consequences of each hazard shall be evaluated in accordance
with the defined criteria.
2126
2127
8.4.2.7 The risk to the system for each hazard shall be evaluated against the previously defined
risk evaluation and acceptance criteria.
2128
2129
2130
8.4.2.8 The identified hazards shall be classified according to the estimated risk arising from
them. The acceptability of the risk shall be determined, having considered the risk in terms of
any conflicts with availability and life-cycle cost requirements of the system.
2131
2132
2133
2134
2135
2136
8.4.2.9 Hazards associated with a broadly accepted risk need not be analysed further but shall
be registered in the hazard log.
NOTE Risks can be described as broadly accepted when they are comparable to risks that people regard as
insignificant or trivial in their daily lives. They are typical of the risk from activities that are inherently not very
hazardous. By its nature, what is called broadly accepted depends on the perception of society and therefore can not
be considered to be constant.
prEN 50126-1
2137
2138
2139
2140
- 58 -
8.4.2.10 A hazard log shall be established as the basis for on-going risk management. It
represents a tool to track hazards and their close out. The hazard log shall be updated,
whenever a change to identified hazards occurs or a new hazard is identified, throughout the
life-cycle. The hazard log shall include or refer to details of:
2141
a) the aim and its purpose;
2142
2143
b) each hazard, its responsibles for managing the hazard and the contributing functions or
components;
2144
2145
c) likely consequences and frequencies of the sequence of events associated with each
hazard;
2146
2147
d) the risk arising from the consequences of each hazard (in quantitative or qualitative
terms);
2148
2149
2150
e) risk acceptance principles selected and in case of explicit risk estimation also the risk
acceptance criteria to demonstrate the acceptability of the risk control related to the
hazards;
2151
2152
f)
for each hazard: the measures taken to reduce risks to a tolerable level or to remove the
risks, including evidence that the measures are effectively implemented;
2153
2154
2155
2156
2157
2158
2159
g) exported safety constraints.

8.4.2.11 There may be several types of hazard logs; e.g. internal ones (for managing the
companys internal processes) and external ones, called hazard record. A hazard record is an
extract of the hazard log that is suitable for transferring information between stakeholders. It
aims to inform other stakeholders about the relevant safety aspects at the interfaces to their
systems or subsystems and about hazards which cannot be controlled by one stakeholder
alone.
2160
2161
8.4.2.12 A hazard record shall provide an extract of the exported safety constraints from the
hazard log, including the entities responsible for their implementation
2162
8.4.2.13 Any analyses produced during the process should include or refer to:
2163
a) the limits of any analysis carried out;
2164
b) assumptions made during the analysis;
2165
c) confidence limits applying to data used within the analysis;
2166
d) the methods, tool and techniques used.
2167
2168
8.4.3
Deliverables
2169
a) the risk analysis;
2170
b) the hazard log;
2171
c) updated safety plan (if appropriate);
2172
2173
2174
d) updated RAM plan (if appropriate).

phase.
2175
8.4.4
2176
2177
required in 7.2.14.
2178
2179
2180
8.4.5
8.4.5.1 The following validation task shall be undertaken within this phase in addition to those
tasks required in 7.2.8:
2181
a) assessment of the risk acceptability classification;
- 59 2182
2183
prEN 50126-1
b) assessment of the suitability of the hazard log process for the system under
consideration.
2184
2185
2186
8.5
Phase 4: specification of system requirements
2187
8.5.1
Objectives
2188
2189
a) specify the overall RAMS requirements for the system;
2190
b) specify the overall demonstration and criteria for acceptance for RAMS for the system;
2191
c) provide a comprehensive and identified set of requirements for the subsequent phases;
2192
2193
d) specify necessary monitoring requirements (that enable the system to perform the
required tasks in phase 11).
2194
2195
2196
2197
2198
8.5.2
Activities
8.5.2.1 The overall RAMS requirements for the system shall be specified on the basis of the
system definition of section 8.3 and the risk analysis and evaluation of section 8.4 taking into
account the results of sub-clause 7.2.3. The RAMS Requirements, for the system under
consideration, shall include:
2199
a) functional requirements and supporting performance requirements, including safety ;
2200
2201
b) functional requirements and safety integrity requirements for each safety-related

function;
2202
c) logistic support requirements;
2203
d) interfaces;
2204
e) application environment and mission profile;
2205
f)
2206
g) external measures necessary to achieve the requirements;
2207
h) system support requirements;
2208
i)
details of the limits of the analysis;
2209
j)
details of any assumptions made;
2210
k) identification of technology related standards;
2211
2212
tolerable risk levels for the consequences arising from the identified hazards;
l) scope of diagnosis and monitoring.

8.5.2.2 The requirements should be expressed and structured in such a way that:
2213
a) they are complete, precise, unambiguous, verifiable, testable and maintainable;
2214
2215
b) they are written to aid comprehension by those who are likely to utilise the information at
any stage of the system life-cycle;
2216
2217
2218
c) they are expressed in natural or formal language and/or logic, sequence or cause and
effect diagrams. The requirements should define the necessary functions with each
function being individually defined;
2219
2220
2221
2222
d) the defined set of requirements is suitable to define a system that is fit for the intended
purpose.
8.5.2.3 The overall requirements for achieving compliance with RAMS requirements for the
system shall be specified, including
2223
a) acceptance criteria for the overall RAMS requirements;
2224
2225
b) a demonstration and acceptance process for the overall RAMS requirements facilitated
by the system RAMS validation plan.
prEN 50126-1
2226
- 60 -
8.5.2.4 A RAMS validation plan shall be established. This RAMS validation plan should include:
2227
a) identification of the system, product or process subject to validation;
2228
2229
2230
b) identification of the steps necessary to demonstrate the adequacy of the deliverables of

each phase of the system, product or process to be validated, in fulfilling the specified
requirements;
2231
2232
c) identification of the steps necessary to demonstrate the adequacy of planned testing

activities against the specified requirements;
2233
2234
d) justification of the validation and testing strategy under consideration of the required
safety integrity;
2235
2236
e) the RAMS tests and analysis to be carried out for the validation including details of the
required environment, tools, facilities etc.;
2237
f)
the validation management structure including requirements for personnel independence;
2238
2239
2240
g) procedures for dealing with non-compliance.

8.5.2.5 The Safety Plan and the RAM plan shall be updated (if appropriate) to ensure that all
planned tasks are consistent with the systems emergent RAMS requirements.
2241
2242
8.5.3
Deliverables
2243
a) the RAMS requirement specification;
2244
b) the RAMS validation plan;
2245
c) updated safety plan (if appropriate);
2246
2247
2248
d) updated RAM plan (if appropriate).

phase.
2249
8.5.4
2250
2251
required in 7.2.14.
2252
2253
2254
8.5.5
8.5.5.1 The following validation tasks shall be undertaken within this phase in addition to those
2255
a) A RAMS validation plan shall be established according to chapter 8.5.2.4;
2256
b) validation of the safety requirements against any safety targets and safety policies;
2257
2258
c) validation of the RAM requirements against any RAM targets and RAM policies of the
railway duty holders.
2259
2260
2261
8.6
Phase 5: architecture and apportionment of system requirements
2262
8.6.1
Objectives
2263
2264
2265
a) design sub-systems and components that work together as a system which fulfils the
required functions;
2266
2267
2268
b) describe the RAMS requirements and specify the interfaces for all sub-systems and
components derived from the RAMS requirements (which prepares later integration
activities);
- 61 -
prEN 50126-1
2269
2270
c) apportion the system RAMS requirements to the designated sub-systems and/or

components;
2271
2272
d) define the acceptance criteria to demonstrate fulfilment of the RAMS requirements for the
designated sub-systems and/or components in subsequent phases;
2273
2274
2275
e) identify and evaluate the significance of the interactions between the sub-systems.
NOTE Interactions can be defined at different abstraction levels. Such interactions should be described in
interface specifications.
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
8.6.2
Activities
8.6.2.1 A system architecture shall be developed and defined that fulfils the RAMS
requirements. The architecture shall be based on a structured decomposition into sub-systems
and/or components with completely defined interfaces between the sub-systems and/or
components. For each subsystem or component a set of RAMS requirements shall be allocated
which is derived from the system requirements and from a design in sufficient depth. To achieve
this, a structured design methodology shall be applied.
2286
2287
2288
2289
2290
8.6.2.2 Particular attention is required for the specification of RAMS requirements for the control
of interfaces where safe and reliable interaction may be compromised. Constraints on the choice
of technology (i.e. independence of functions or processes of development) shall be identified.
All safety relevant assumptions made during the development of the system architecture shall
be specified and documented.
2291
2292
2293
8.6.2.3 The designated sub-systems and/or components shall be specified to achieve the
system RAMS requirements, including the impact of common cause and multiple failures. For
the concept of taking precautions see also chapter 6.7.1.
2294
2295
2296
8.6.2.4 If new hazards are identified arising from the architecture, requirements to control these
hazards shall be derived from the new hazards and allocated to the related sub-systems and/or
components.
2297
2298
2299
8.6.2.5 If pre-existing sub-systems and/or components are used to fulfil system requirements it
shall be ensured additionally that the requirements for integration of the pre-existing subsystems and/or components are clearly identified and fulfilled.
2300
2301
2302
2303
8.6.2.6 In cases where safety-related functions are developed according to a code of practice,
the relationship of these functions to the used code of practice shall be given and justified in the
system architecture.
2304
2305
2306
8.6.2.7 Acceptance criteria, acceptance processes and procedures as well as demonstration for
sub-systems and/or components including their interfaces shall be specified to ensure
compliance with the sub-system and/or component requirements .
2307
2308
2309
2310
2311
8.6.2.8 The Safety Plan, RAM plan and the RAMS Validation Plan should be updated (if
appropriate) to ensure that all planned tasks are consistent with the systems emergent RAMS
requirements following the apportionment.
NOTE Key areas of concern include requirements for personnel independence and the control of system interfaces
where safety functionality may be compromised.
2312
2313
8.6.3
Deliverables
NOTE The system architecture should be expressed and structured in a way that it is clear, precise, unambiguous,
verifiable, testable, maintainable and feasible. It should aid the comprehension by those who are likely to utilise the
information at any phase of the life-cycle; and be traceable to the system requirement.
NOTE The realisation of safety-related functions shall be performed in accordance with the related code of practice.
2314
2315
2316
a) system architecture (structure of decomposition into subsystems etc.) including interface

specifications and system hazard analysis (architecture and hazard analysis of
subsystem and components);
2317
b) RAMS requirement specification for sub-systems and/or components;
2318
c) acceptance criteria and demonstration and acceptance processes and procedures;
2319
d) updated safety plan (if appropriate);
prEN 50126-1
2320
- 62 -
e) updated RAM plan (if appropriate);
2321
2322
2323
f) updated RAMS validation plan (if appropriate).

phase.
2324
8.6.4
2325
2326
There are no specific verification requirements for this phase in addition to those tasks required
in 7.2.14.
2327
8.6.5
2328
2329
required in 7.2.8.
2330
2331
2332
8.7
Phase 6: design and implementation
2333
8.7.1
Objectives
2334
2335
a) create sub-systems and components conforming to RAMS requirements;
2336
b) demonstrate sub-systems and components conform to RAMS requirements;
2337
c) establish plans for future life-cycle tasks involving RAMS.
2338
2339
8.7.2
Activities
8.7.2.1 The sub-systems and components shall be designed to meet the RAMS requirements.
2340
2341
8.7.2.2 The design of the sub-systems and components shall be implemented to meet RAMS
requirements.
2342
2343
8.7.2.3 The RAMS tasks of further life-cycle phases shall be planned. These phases shall
include:
2344
a) Integration;
2345
b) Operation and maintenance;
2346
2347
2348
2349
c) Performance monitoring (if appropriate / contractually agreed).

8.7.2.4 Operation and maintenance procedures shall be prepared. These procedures shall
include all the relevant information for providing spare parts, particularly items in safety-related
functions.
2350
2351
8.7.2.5 Training measures for operation and maintenance staff including training material shall
be defined.
2352
2353
8.7.2.6 A manufacturing process capable of producing RAMS-validated sub-systems and

components shall be defined and established. The following aspects should be considered:
2354
a) environmental stress screening;
2355
b) RAM improvement testing;
2356
c) inspection and testing for RAMS-related failure modes;
2357
2358
2359
2360
d) activities, defined in the safety plan, which are relevant to this life-cycle phase.
8.7.2.7 A process for the integration into the system capable of producing RAMS-validated subsystems and components shall be defined and established. The following aspects should be
considered:
2361
a) measures to prevent installation errors;
2362
b) testability of installed sub-systems and components;
- 63 -
prEN 50126-1
2363
2364
2365
2366
2367
c) activities, defined in the safety plan, which are relevant to this life-cycle phase.
8.7.2.8 A safety case shall be prepared, justifying that the system, product or process, as
designed, meets the safety requirements. The safety case may require acceptance by the
railway duty holder or approval based on the legal framework. The contents and documentation
structure of the safety case shall follow the requirements stated in sub-clause 10.3.
2368
2369
2370
8.7.2.9 A safety case shall be a generic product safety case, a generic application safety case
or a specific application safety case as defined in sub-clause 10.2. The type(s) of safety case(s)
prepared shall be suitable to meet the scope of the product, system or process.
2371
2372
8.7.2.10 The RAMS Validation Plan shall be updated (if appropriate) to ensure that all planned
tasks are consistent with the systems emergent RAMS requirements following the design.
2373
8.7.2.11 Installation and commissioning procedures shall be prepared.
2374
2375
8.7.3
Deliverables
2376
a) plan(s) for further life-cycle tasks;
2377
b) operation and maintenance procedures;
2378
c) training measures;
2379
d) safety case(s);
2380
e) updated validation plan;
2381
f)
updated hazard log.
2382
2383
2384
This documentation shall include any assumptions and justifications made during this phase.
8.7.3.2 A record of all RAMS validation tasks undertaken within the phase shall be maintained
following the requirements given in sub-clause 7.2.9.
2385
2386
2387
8.7.4
8.7.4.1 The following verification tasks shall be undertaken within this phase in addition to those
2388
2389
a) verification that
requirements;
sub-system
and
component
design
complies
with
the
RAMS
2390
b) verification that sub-systems and components implementation complies with designs;
2391
2392
c) verification that the manufacturing arrangements produce RAMS-validated sub-systems

and components;
2393
2394
2395
d) verification that all future life-cycle activity plans are consistent with RAMS requirements
for the system.
NOTE Verification is based on results of analyses and tests.
2396
8.7.5
2397
2398
required in 7.2.8.
2399
2400
2401
8.8
Phase 7: manufacture
2402
8.8.1
Objectives
2403
2404
a) manufacture the sub-systems and components;
2405
b) establish and apply RAMS-centred assurance arrangements.
prEN 50126-1
- 64 -
2406
2407
8.8.2
Activities
8.8.2.1 The manufacturing process defined in phase 6 shall be implemented and operated.
2408
8.8.2.2 RAMS-centred assurance arrangements shall be established, including:
2409
a) quality assurance measures suitable to meet RAMS requirements;
2410
b) manufacturing process improvement and assurance measures as appropriate;
2411
c) environmental stress screening as appropriate;
2412
d) inspection and testing for RAMS-related failure modes;
2413
e) material handling and logistic arrangements suitable to meet RAMS requirements.
2414
2415
2416
8.8.3
Deliverables
8.8.3.1 The results of this phase shall be documented in an appropriate way, including RAMS
related aspects of:
2417
a) quality assurance reports;
2418
b) inspection and testing reports;
2419
c) material handling and logistic arrangements;
2420
d) updated hazard log.
2421
2422
2423
This documentation shall include any assumptions and justifications made during this phase.
8.8.3.2 A record of all RAMS validation tasks undertaken within the phase shall be maintained
following the requirements given in sub-clause 7.2.9.
2424
8.8.4
2425
2426
required in 7.2.14.
2427
8.8.5
2428
2429
required in 7.2.8.
2430
2431
2432
8.9
Phase 8: integration
2433
8.9.1
Objectives
2434
2435
2436
a) assemble and install the total combination of sub-systems and components required to
form the complete system;
2437
2438
b) demonstrate that all subsystems and components work together as defined by the
interfaces;
2439
c) demonstrate that all subsystems and components meet their RAMS requirements;
2440
d) initiate system support arrangements.
2441
2442
2443
2444
2445
2446
2447
8.9.2
Activities
8.9.2.1 The subsystems and components shall be integrated according to the integration
planning and the fulfilment of the systems functionality as well as the specified RAMS
requirements shall be demonstrated. The integrated system may have to be installed into a
higher level system. Therefore, the requirements of this phase shall apply both to the integration
of components and subsystems and to the incorporation of a system into the superordinate
system. This could be regarded as a two-tiered integration for which similar activities apply.
- 65 -
prEN 50126-1
2448
2449
2450
2451
2452
8.9.2.2 In case of modifications or changes are introduced to the integrated system during
integration, an impact analysis of the system architecture from phase 5 shall be performed to
ensure that the subsystems interact safely and perform the intended functions after the
modification or change. On the basis of the impact analysis it shall be evaluated to which extent
previous life-cycle activities should be repeated.
2453
2454
2455
2456
2457
2458
8.9.2.3 The system shall be tested and analysed in accordance with the system integration
planning. These tests and analyses shall show that all sub-systems and components of the
system interact correctly as specified in the interface specifications to perform their intended
function and do not perform unintended functions.
2459
2460
2461
2462
8.9.2.4 During the integration of the sub-systems and components of the system the fulfilment of
all application conditions defined for that subsystems and components shall be shown, this
includes for subsystems developed according to a code of practice, the evidence for the
conformance of the realisation according to the used code of practice.
2463
2464
2465
8.9.2.5 From all application conditions of the subsystems and components which can not be
solved during the integration the application conditions for the integrated system shall be
derived.
2466
8.9.2.6 The system support arrangements shall be initiated, including:
NOTE For integration and integration tests for E/E/PE software, subsystems and components EN 50126-4 and
EN 50126-5 are to be considered.
2467
a) start staff training;
2468
b) make system support procedures available;
2469
c) establish spare parts provision;
2470
d) establish tool provision.
2471
2472
8.9.3
Deliverables
2473
a) installation documentation;
2474
b) action taken to resolve failures and incompatibilities;
2475
c) system support arrangements.
2476
2477
2478
This documentation shall include assumptions and justifications made during this phase.
8.9.3.2 A record of all RAMS validation tasks undertaken within the phase, including the
installation activity, shall be maintained following the requirements given in sub-clause 7.2.10.
2479
8.9.4
2480
There are no specific verification requirements for this phase to those tasks required in 7.2.14.
2481
8.9.5
2482
2483
required in 7.2.8.
2484
2485
2486
8.10
2487
2488
8.10.1
Objectives
8.10.1.1 The objectives of this phase are to:
Phase 9: system validation
2489
2490
a) validate that the system, product or process in combination with its application conditions
complies with the RAMS requirements;
2491
2492
b) confirm or update the safety case for the system, product or process appropriate to the
results of the validation;
prEN 50126-1
2493
- 66 -
c) prepare the acquisition and assessment of operational data.
2494
2495
2496
8.10.2
Activities
8.10.2.1 The system, product or process shall be validated according to the RAMS validation
plan considering external risk reduction measures.
2497
2498
2499
8.10.2.2 A probationary period of operation may be undertaken, to resolve potential in-service

system problems. In this case, the need for demonstrating system safety shall be considered
prior to the probationary operation and the entry into revenue service.
2500
2501
2502
8.10.2.3 The Hazard Log shall be reviewed and updated to record any residual hazards
identified during system validation and to ensure that the risks from any such hazards are
effectively managed.
2503
2504
8.10.2.4 The safety plan shall be reviewed with regard to its continued applicability. Any
deviations shall be justified and documented.
2505
2506
2507
8.10.2.5 The safety case for the system, product or process shall be updated. The safety case
shall justify, that the system, product or process, as specifically applied within this application,
complies with the system safety requirements.
2508
2509
8.10.2.6 A process for the acquisition and assessment of operational data and maintenance
data shall be established and implemented as an input to a system improvement process.
2510
8.10.2.7 The adequacy of the impact analysis from sub-clause 8.9.2.2 shall be evaluated.
2511
2512
Deliverables
8.10.3
2513
2514
a) details of RAMS validation tasks against acceptance criteria, including RAM

demonstrations and safety analysis following the requirements given in sub-clause 7.2.9;
2515
b) details of process, tools, equipment used for validation tasks against acceptance criteria;
2516
c) results of validation tasks for all acceptance criteria;
2517
e) problem reporting and assessment tasks;
2518
f)
2519
g) action taken to resolve failures and incompatibilities;
2520
h) updated hazard log;
2521
i)
updated safety plan (if appropriate);
2522
j)
updated safety case;
2523
k) process for the acquisition and assessment of operational data.
any limitations and constraints applying to the system;
2524
2525
2526
2527
8.10.4
8.10.4.1 The following verification tasks shall be undertaken within this phase in addition to
those tasks required in 7.2.14:
2528
2529
a) verification that the commissioning activity was carried out in accordance with the
Commissioning Plan;
2530
b) verification of the adequacy and effectiveness of the operational data collection system.
2531
8.10.5
2532
2533
required in 7.2.9.
2534
2535
- 67 2536
8.11
Phase 10: system acceptance
2537
8.11.1
Objectives
2538
prEN 50126-1
2539
2540
a) assess compliance of the total combination of sub-systems, components, their interfaces

and application conditions with the overall RAMS requirements;
2541
2542
2543
2544
NOTE In this European standard, the term system acceptance is used only for technical aspects of the acceptance
procedure. Legal aspects of the system acceptance are not considered in this standard. It is recommended to clarify
the legal aspects of system acceptance between the customer and the supplier in advance.
2545
2546
2547
2548
8.11.2
Activities
8.11.2.1 All system verification and validation tasks, specifically the RAMS verification &
validation and the safety case, shall be assessed in accordance with the defined acceptance
criteria.
2549
2550
2551
8.11.2.2 The results of this assessment shall be recorded in an acceptance report. The
acceptance report should include a confirmation that the delivered product, system or process is
fit for entry into service.
2552
2553
8.11.2.3 The following tasks shall be undertaken by the entity which is accepting the system
(Railway Duty Holder or other):
b) accept the system for entry into service.
2554
a) verification of the acceptance report with respect to the defined acceptance criteria;
2555
b) verification of the safety plan with regard to its continued applicability;
2556
c) verification of the updated hazard log.
2557
2558
8.11.3
Deliverables
2559
2560
2561
a) acceptance report.
8.11.3.2 This documentation shall include assumptions and justifications made during this
phase.
2562
8.11.4
2563
2564
There are no specific verification requirements for this phase in addition to those tasks required
in 7.2.14
2565
8.11.5
2566
There are no specific validation requirements for this phase.
2567
2568
2569
8.12
Phase 11: operation, maintenance and performance monitoring
2570
8.12.1
Objectives
2571
2572
2573
2574
The objective of this phase is to operate, maintain and support the product, system or process
such that compliance with RAMS requirements is maintained. This includes to continuously
monitor and evaluate the RAMS performance of the system and to derive measures for
addressing shortcomings and for achieving improvements.
2575
2576
2577
2578
2579
8.12.2
Activities
8.12.2.1 The operation and maintenance procedures shall be implemented, particularly with
regard to system performance and life-cycle cost issues. This requires considering the product,
system or process in its operational environment, e.g. including the application of external risk
reduction measures.
prEN 50126-1
- 68 -
2580
8.12.2.2 Compliance with RAMS requirements shall be assured throughout this phase, by:
2581
a) regular review and update of operation and maintenance plans and procedures;
2582
b) conformity with operational plans and procedures;
2583
c) conformity with maintenance plans and procedures;
2584
d) regular review of system training documentation;
2585
e) regular review and update (if appropriate) of an operational Hazard Log;
2586
2587
f)
conformity with support agreements including logistics, spare parts, repairs, tools,
calibration;
2588
2589
2590
NOTE The operational Hazard Log is based on the Hazard Record extracted from the Hazard Log resulting from
phase 10.
g) maintenance of the failure reporting and corrective action system (FRACAS).
2591
8.12.2.3 A process for:
2592
a) the acquisition of RAMS performance data;
2593
b) the analysis and evaluation of RAMS performance data;
2594
2595
2596
2597
c) recording of RAMS performance data, associated analysis and evaluation as appropriate

shall be implemented and maintained.
8.12.2.4 A competence management system shall be put in place to evaluate, manage, assure
and document the competence requirements of personnel. This shall include:
2598
a) Technical knowledge;
2599
b) Qualifications;
2600
c) Relevant experience;
2601
2602
2603
d) Training needs.
NOTE Competence management helps to protect against systematic and deterministic errors being made during
operation and maintenance which might lead to a safety-related incident or a service affecting availability failure.
2604
2605
2606
2607
8.12.2.5 Throughout the operational lifetime the system baseline shall be recorded and kept
traceable under configuration management control.
NOTE This is of special importance when critical faults are discovered and need to be corrected in more than one
installation.
2608
2609
2610
8.12.2.6 Anomalies or errors observed during deployment, operation and maintenance shall be
recorded and evaluated against the required RAMS functions of the system. The evaluation
should include a review of the following:
2611
a) Operation and maintenance procedures and manuals;
2612
b) System training documentation;
2613
c) Operational Hazard Log;
2614
d) System design;
2615
2616
2617
e) Human factors aspects of operation and maintenance.

8.12.2.7 Based on the analysis and evaluation of RAMS performance recommendations shall
be developed to assure or improve the RAMS performance.
2618
2619
8.12.2.8 For each identified recommendation a decision shall be taken whether the
recommendation shall be realised or not. These decisions shall be justified and recorded.
2620
2621
8.12.3
Deliverables
2622
a) updated system and support documentation, as appropriate, within this phase;
2623
b) records suitable to trace the RAMS tasks undertaken within this phase;
2624
c) reports of RAMS performance analyses and evaluations;
- 69 2625
d) identified recommendations and record of associated decisions;
2626
e) updated operational Hazard Log, if appropriate;
2627
f)
prEN 50126-1
updated Operation and Maintenance Plans and processes.
2628
2629
8.12.4
2630
2631
required in 7.2.14
2632
8.12.5
2633
2634
2635
2636
8.13
Phase 12: decommissioning
2637
8.13.1
Objectives
2638
2639
The objective of this phase is to control RAMS implications of system decommissioning and
disposal tasks.
2640
2641
2642
8.13.2
Activities
8.13.2.1 The RAMS impact of decommissioning and disposal on any relevant external system
or facility shall be identified.
2643
8.13.2.2 The decommissioning shall be planned, including the establishment of procedures for:
2644
a) the safe closing down of the system;
2645
2646
2647
NOTE As external systems or facilities may be affected, these systems or facilities may also need consideration. It
shall be taken into account that the disposal may represent a modification of the external system or facility.
b) the safe dismantling of the system;
2648
8.13.3
2649
2650
The results of this phase shall be documented in an appropriate way. This documentation shall
include any assumptions and justifications made during this phase.
2651
8.13.4
2652
2653
The following verification task shall be undertaken within this phase in addition to those tasks
required in 7.2.14
2654
8.13.5
2655
Deliverables
2656
2657
2658
Risk assessment
2659
9.1
Scope
2660
9.1.1
Risk assessment comprises both risk analysis and risk evaluation
2661
2662
2663
9.1.2
Risk analysis is the systematic use of all available information to identify hazards and
to estimate the risk. It is a very important step in the RAMS process based on the life-cycle. This
subclause provides a methodology to support chapter 8.4.
prEN 50126-1
- 70 -
2664
2665
2666
9.1.3
Risk analysis shall be initially performed at phase 3 of the system life-cycle and
continued as appropriate at various phases of the system life-cycle by the railway duty holder
responsible for that phase and shall be documented.
2667
2668
9.1.4
One of the outcomes of the risk analysis is to distinguish between the hazards which
do not need to be analysed further from the hazards that needs to be further analysed.
2669
2670
9.1.5
Risk evaluation consists of comparing the determined risk against the associated
acceptance criteria and a judgement on the acceptance.
2671
2672
2673
2674
2675
2676
2677
9.1.6
Acceptance of risk depends on how a risk is perceived which, differs greatly between
parties or people involved. The reasons being, prevailing social and cultural conditions,
psychological and physical factors and also factors such as whether the risk is voluntary (e.g.
self imposed) or involuntary (e.g. imposed by others) and whether it has large consequences
feared by the society. Voluntary risk is generally better accepted than involuntary risk or where
the person exposed to the risk does not have control over the risk. Such factors need to be
taken into account for establishing risk acceptance criteria.
2678
9.2
2679
2680
2681
To produce a risk analysis, the following methodology should be applied:

9.2.1
Risk analysis, using qualitative, quantitative or hybrid approaches, is a systematic and
structured process for
2682
2683
2684
2685
1. identifying the undesired events that may lead directly or indirectly to losses during the
operation and maintenance of a system. In the context of railway operations, losses could
mean harm to passengers, workers or members of the public, harm to the environment or
losses related to RAMS;
2686
2687
2688
2. identifying the undesired events, i.e. the component, sub-system or system failures, physical
effects, which, perhaps combined with human errors or operational conditions, can result in
losses related to RAMS;
2689
2690
3. identifying the control measures that are in place to control or limit the occurrence of each
undesired event that cannot be eliminated;
2691
2692
2693
2694
4. where appropriate, estimating the frequencies at which undesired events can occur and
estimating the consequences that could occur for the different outcomes that may follow the
occurrence of a loss. This would include identifying, where risk reduction is necessary and
which control measures that have to be in place to control or limit
2695
2696
the frequency of occurrence of each undesired event that cannot be eliminated after
identification of causes and triggering event, and
2697
the consequences of the related losses.
Risk analysis methodology
2698
2699
2700
2701
Triggering events shall be taken into account, because their impact can be very important on
frequencies as well as on the severity of consequences.
NOTE If feasible and practicable, the best approach to control a risk is elimination. However this often cannot be
achieved and reduction of frequency of undesired events or their consequence shall be applied.
2702
2703
2704
5. determining, where necessary, the additional measures to apply that are required to ensure
that the risk is mitigated to levels accepted within the applicable legal framework by the
appropriate entity (e.g. it satisfies the defined risk acceptance criteria or legal requirements);
2705
2706
6. providing clear and comprehensive documentary evidence of the methodologies,

assumptions, data, judgments and interpretations used in carrying out the risk assessment.
2707
2708
Details with regard to the use of a code of practice or use of a similar system as a reference can
be found in EN 50126-2.
2709
2710
9.2.2
Consequence analysis shall be used to estimate the impact given different scenarios
(including different triggering events).
- 71 -
prEN 50126-1
2711
2712
2713
2714
2715
2716
2717
2718
2719
9.2.3
To assess/estimate the risk of systems in a mathematical fashion based on
dependable data is not always possible. Often the required information (i.e. data, causal
connections as well as interrelations/interactions between the systems constituents ...) is not
fully available or known. Therefore a method known as expert judgement is an indispensable
tool in the risk assessment process, but not only applicable here. In some cases the expert
judgement can be the only approach if dependable data cannot be produced and in other cases
it may simply be the best option.
Even though it is a good way to make use of knowledge and experience, expert judgement is
often mistrusted because it is basically subjective.
2720
2721
2722
2723
2724
9.2.4
To make it a credible basis for risk assessment expert judgement should be made
more objective. This implies that
the assessment/estimation should not be of the opinion of a single person. Agreement
among several (independent) experts and approved knowledge enhances the confidence
in an assessment;
2725
it shall be ensured that the experts have adequate knowledge of the area in question;
2726
2727
2728
2729
2730
all necessary areas of expertise (which can arrive at differing classifications) have to be
included in the judgement. Aspects of skirting functions/systems can have an effect on
the assessed system and may have to be regarded in more complex systems. Therefore
the team has to be selected wide enough if a problem cannot be considered fully
isolated;
2731
2732
2733
a clear understanding of the categories shall be provided to promote a common

interpretation, if the expert judgement is applied to estimate the frequency and
consequences of hazards or of accidents;
2734
2735
2736
documentation of the results of expert judgement is necessary to support objectivity and

to ensure the transparency and plausibility of the conclusions. The documentation shall
also enable further refinement should new information be available.
2737
2738
2739
2740
9.2.5
The participants and their respective area of expertise should be recorded. Further
information like references to publications, sources, assumptions, deliberately excluded aspects
with justification, rationale of conclusion etc. should be recorded in order to demonstrate the
integrity and enable third parties to trace the conclusion.
2741
2742
2743
2744
2745
2746
9.2.6
For the purpose of classifying any events Table D.1 and Table D.2 in Annex D provide,
in qualitative terms, typical categories of probability or frequency of occurrence of events and a
typical description of each category for railways. Based on these typical categories, their
numbers, and their numerical scaling (provided that numerical estimates are feasible) to be
applied shall be defined by the railway duty holder, appropriate to the application under
consideration.
2747
2748
2749
2750
2751
2752
2753
9.2.7
It is important to note, that given safety targets referring to frequency categories
should be related to the item under consideration (an instance of the function or system under
consideration), but not to the sum of items in use or intended to be used. In other words not to
the fleet of them, but to the single instance of this function or system. Otherwise compliance to
a safety objective could require revising a system in case additional identical equipment will be
put into operation.
Example: The frequency categories could apply to:
2754
a door system (per door);
2755
a brake system (per independent braking unit);
2756
a single signal;
2757
a main switch in a power supply station.
2758
2759
2760
It is important to note however that there can be different consequences when losing a single
system, or multiple instances of the same system. In such case, safety requirements are to be
achieved for all accident scenarios.
prEN 50126-1
- 72 -
2761
Example:
2762
A single door opening when the train is running might trigger a fatality.
2763
All doors opening when the train is running might however trigger multiple fatalities.
2764
2765
This means that the overall control command function could have a more stringent safety target
than the local function.
2766
2767
2768
2769
9.2.8
Table D.4 and Table D.5 in Annex D describe typical severity levels and the associated
consequences. The number of severity levels and the consequences for each severity level to
be applied shall be defined by the railway duty holder, appropriate for the application under
consideration.
2770
2771
2772
9.2.9
With regard to safety it is recommended that the relationship between injuries and
fatalities (equivalent fatalities as defined in 3.22 , efat), for the purpose of predicting and
comparison only, be agreed with the railway duty holder based on the relevant legal framework.
2773
2774
9.2.10
Examples of such relationship may be:
one equivalent fatality 1 fatality 10 major injuries 100 minor injuries or
2775
severe injuries and fatalities are fully equivalent or
2776
any other weighted equivalence.
2777
By nature, the use of equivalent fatalities (efat) for prediction can not provide any certainty.
2778
2779
2780
2781
2782
9.2.11
Considering safety, risk can be expressed in terms of collective risk or individual risk.
Both terms are interrelated and can be converted to a certain extent. If quantified or semiquantified safety targets are given, in most cases they are expressed in terms of collective risk.
In this subclause and the related annexes this applies as well.
Examples:
2783
2784
Collective risk: 810 -5 fatalities/year - the risk of death for the collective taking part in national
road traffic, e.g. 5000 fatalities within a collective of 60 Million within a period of one year
2785
2786
Individual risk: x10 -y fatalities/(year and person) - the risk of death as a bus driver taking part in
national road traffic each working day for one year
2787
2788
2789
2790
2791
9.2.12
Assessing risk does not necessarily imply considering worst-case scenarios. In other
words, a hazard leading to an accident can have a variety of consequences with varying
severity. This needs to be reflected in the risk analysis. One way for that is to conduct a
consequence analysis, where the likeliness (not necessarily expressed quantitatively, can be
purely qualitative) of each scenario will be identified
2792
2793
9.2.13
One of the main methods is the use of a matrix for evaluation of the results of risk
analysis, risk categorisation and deriving actions for risk reduction.
2794
2795
2796
2797
9.2.14
The risk determined can be displayed by combining the frequency of occurrence of
loss (e.g. accident) with its severity to establish the anticipated level of risk generated. A
"frequency - severity" matrix is shown in Table 2.
2798
Table 2 - Frequency - Severity Matrix

Frequency of
consequence
[frequency
categories]
[Risk]
[severity categories]
Severity of consequence
2799
- 73 -
prEN 50126-1
2800
2801
The axes of the matrix have to be calibrated and the judgement on calibration shall be
documented. The calibration depends on the purpose of the application of the matrix.
2802
2803
2804
9.2.15
If an axis calibration scheme is given mandatory by law or safety authorities, it shall be
used. If several matrixes on the same subject are used in parallel, their coherence should be
ensured.
2805
9.3
2806
2807
2808
2809
2810
2811
Acceptance principles
9.3.1
9.3.1.1 To evaluate the identified risks and to enable a decision on their acceptance, a risk
acceptance principle shall be chosen. It indicates the type of argument which partially or fully
shows that the respective hazard and the resulting risk are assured as being under control. The
principle used should be chosen depending on the type of evidence to be provided. There are
three principles mainly used and given in clause 8.4.2.1.
2812
2813
2814
9.3.1.2 In case the legal framework requires the risk analysis to be approved by a safety
authority, the choice of the principles should be communicated to this authority at the earliest
possible stage of the project.
2815
Existing applicable material can be reused, for example when tailoring the process.
2816
2817
For details regarding these 3 principles please refer to chapter 8.5 in EN 50126-2 of this
standard.
2818
2819
2820
9.3.2
Methods for determining risk acceptance criteria
9.3.2.1 Once an acceptance principle is chosen, criteria should be determined in order to have a
limit for deciding whether a risk is deemed acceptable or not.
2821
2822
2823
9.3.2.2 Risk acceptance should be based on generally accepted criteria. A number of methods
for deriving them are available that may be utilised. Some examples are as follows: (Also see
Annex B in EN 50126-2 for more information on these methods for deriving acceptance criteria)
Risk evaluation and acceptance
2824
Risk Matrix;
2825
As Low As Reasonably Practicable (ALARP);
2826
Globalement Au Moins Equivalent (GAME) ;
2827
Minimum Endogenous Mortality (MEM).
2828
NOTE A calibrated Risk Matrix can be used to determine criteria for non-safety issues as well.
2829
2830
2831
Requirements can be given by legal obligations as well.

9.3.2.3 One of the main methods is the use of a "frequency - consequence" matrix for risk
acceptance.
2832
2833
2834
2835
2836
2837
2838
2839
2840
It can be performed by allocating appropriate acceptance criteria to an axes-calibrated risk

matrix. This calibration with regard to risk acceptance shall be justified and documented. If an
acceptance calibration scheme is given mandatory by the legal framework or safety authorities,
it shall be used. Examples of risk acceptance categories and the actions to be applied against
each category are given in Table D.7 and Table D.8 in Annex D. The allocation of such
categories to a risk matrix is shown in Table D.9 in Annex D.
9.3.2.4 Note that such matrices are more appropriate for risk ranking than for assessment. One
of the essential preconditions for applying a matrix for risk assessment purposes it its calibration
for the specific application.
prEN 50126-1
- 74 -
2841
10
Deliverables and structure of a safety case
2842
10.1
Purpose of a safety case
2843
2844
2845
2846
2847
2848
2849
10.1.1
A safety case is defined as a structured argument, supported by a body of evidence
that provides a compelling, comprehensible and valid case that a system is safe for a given
application in a given operating environment. It takes the form of structured safety justification
documentation which sets out and explains the evidence for the safety of the system/subsystem/equipment. This section is concerned with the documentary representation of that
explanation and evidence. The techniques and processes involved in the demonstration of
safety are already covered in chapters 7 and 8.
2850
2851
2852
All requirements derived from this clause are specified in clause 8 RAMS life-cycle.
10.1.2
Further details concerning safety cases for E/E/PE systems may be found in EN 50126-4, and
further details concerning safety cases for software may be found in EN 50126-5.
2853
2854
2855
2856
10.2
Types of safety case
10.2.1.1 Safety cases may vary in scope and purpose. It is common to produce separate
product and application safety cases as described below, but where appropriate matters
concerning both product and application safety may be included within the same safety case.
2857
2858
Generic product safety case (independent of application): a generic product can be reused for different independent applications;
2859
2860
Generic application safety case (for a class of application): a generic application can be
re-used for a class/type of application with common functions;
2861
2862
Specific application safety case (for a specific application): a specific application is used
for only one particular instance.
2863
2864
2865
It is essential to demonstrate for each specific application that the environmental conditions
and context of use, including maintenance arrangements, are compatible with the generic
application conditions.
2866
2867
2868
2869
2870
2871
2872
2873
The way in which these types of safety case are used in the safety acceptance and approval
process is described in EN 50126-2.
10.2.1.2 In all three categories the structure of the safety case is basically the same. However,
there is an additional factor for specific applications: in this category, separate safety approval
may be needed for the application design of the system and for its physical implementation (i.e.
the material product which is the subject of manufacture, installation, and test, and the facilities
for its operation and maintenance), especially where final testing is possible only a short time
before the system is to be brought into use.
2874
2875
10.2.1.3 For this reason, it may be convenient to divide the safety case for specific applications
into two portions:
2876
2877
the Application Design Safety Case: this shall contain the safety evidence for the
theoretical design of the specific application;
2878
2879
the physical implementation safety case: this shall contain the safety evidence for the
physical implementation of the specific application.
2880
10.3
2881
2882
2883
2884
2885
General
10.3.1
10.3.1.1 The purpose of a safety case is to demonstrate that all relevant hazards have been
identified and that suitable measures have been taken to control or mitigate risks. The first of
these demonstrations is provided by a Safety Management Report and the second by a
Technical Safety Report.
Safety case structure
- 75 -
prEN 50126-1
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
10.3.1.2 In order to make these demonstrations the safety case need to include two types of
arguments. Firstly it needs to argue that the set of identified requirements is sufficient to secure,
assuming that all requirements are implemented, that the system is acceptably safe. Secondly,
it needs to include arguments to show that sufficient evidence has been provided to prove that
the requirements have been fulfilled. It also has to be shown how it is ensured that the safety
measures presented in the Technical Safety Report are actually implemented in practice. The
evidence for this is presented in the Quality Management Report. In addition, there needs to be
sufficient description of the system/subsystem/equipment in question to enable a reader of the
safety case to understand the adequacy of the evidence provided in the Quality Management,
Safety Management and Technical Safety Reports.
2896
2897
2898
2899
10.3.1.3 The way in which a safety case should be structured to contain this information is set
out in this section, together with an outline of how the material which is required should be
included in each part of the safety case. The structure of the safety case is illustrated in Figure
8.
2900
2901
2902
2903
2904
10.3.1.4 The use of a standardised structure for safety case documentation has the advantage
of enabling readers familiar with that structure to more rapidly locate selected material within the
safety case. However, alternative structures may be used provided they contain the material
defined by this Standard and provided it is demonstrated that the alternative structure is
equivalent to the structure defined here.
2905
Part 6: Conclusion
Part 5: Related
Safety Cases
Part 4: Technical
Safety Report
Part 3: Safety
Management Report
Part 2: Quality
Management Report
Part 1: Definition of System
Safety Case
2906
2907
Figure 8 Structure of a safety case
prEN 50126-1
- 76 -
2908
2909
2910
2911
2912
2913
2914
2915
2916
10.3.2
Definition of system
10.3.2.1 This part of the safety case shall precisely define or reference the system/subsystem/equipment to which the safety case refers, including version numbers and modification
status of all requirements, design and application documentation. In order to ensure that the
safety case is appropriate to the operational context of the system being analysed the system
definition shall identify and outline its operational environment as defined in section 8.3 above.
In order to ensure that the system is appropriate for its intended use, the system definition shall
identify and outline the technical boundary of the system under consideration operating within
the given environment under given operating conditions as defined in section 8.3 above
2917
2918
2919
10.3.2.2 The system definition may refer the reader to other documents for details of the
system design, but the description contained within the safety case contain at least the
following.
2920
A summary of the system requirements, including:
2921
functional safety requirements;
2922
non-functional safety requirements relevant to the safety case;
2923
environmental conditions;
2924
2925
targets or acceptance criteria by which the safety of the system will be judged.
An outline of the systems architecture and structure;
2926
A summary of the system elements involved (including software);
2927
Identification of all system interfaces, including:
2928
interfaces of the system to its environment;
2929
technical interfaces;
2930
man-machine interfaces.
2931
2932
2933
2934
2935
2936
2937
2938
2939
10.3.3
Quality management report
10.3.3.1 An essential condition for the assurance of safety is that the quality of the system, subsystem or equipment has been, and shall continue to be, controlled by an effective quality
management system throughout its life-cycle. Documentary evidence to demonstrate this shall
be provided in the Quality Management Report, which forms Part 2 of the safety case. Where
appropriate this may be provided by reference to the Quality Management System of the
company or organisation concerned, including evidence of certification against ISO 9001.
However, the depth of the evidence presented and the extent of the supporting documentation
should be appropriate to the safety targets of the system/sub-system/equipment under scrutiny.
2940
2941
10.3.3.2 Examples of aspects which should be controlled by the quality management system
and included in the Quality Management Report are listed below:
2942
organisational structure;
2943
quality planning and procedures;
2944
specification of requirements;
2945
design control;
2946
design verification and reviews;
2947
application engineering;
2948
procurement and manufacture;
2949
product identification and traceability;
2950
handling and storage;
2951
inspection and testing;
2952
non-conformance and corrective action;
2953
packaging and delivery;
- 77 2954
installation and commissioning;
2955
operation and maintenance;
2956
quality monitoring and feedback;
2957
documentation and records;
2958
configuration management/change control;
2959
personnel competency and training;
2960
quality audits and follow-up;
2961
decommissioning and disposal.
prEN 50126-1
2962
2963
10.3.3.3 Further requirements/guidance on the relevance of quality management to safety is set

out in Annex A of EN 50126-2.
2964
2965
2966
2967
2968
2969
2970
2971
2972
10.3.4
Safety management report
10.3.4.1 A further essential condition for the assurance of safety is that the safety of the
system, subsystem or equipment has been, and shall continue to be, managed by means of an
effective safety management process. Documentary evidence to demonstrate compliance with
all elements of the safety management process throughout the life-cycle shall be provided in the
Safety Management Report. Large volumes of detailed evidence and supporting documentation
need not be included, provided precise references are given to such documents. However, the
depth of the evidence presented and the extent of the supporting documentation should be
appropriate to the safety targets of the system/sub-system/equipment under scrutiny
2973
10.3.4.2 The Safety Management Report should be arranged under the following headings:
2974
safety life-cycle;
2975
safety organisation;
2976
safety plan;
2977
hazard log.
2978
2979
Requirements/guidance on safety management are set out in section 7.1.2 above as well as in
Annex A.2 in EN 50126-2.
2980
2981
2982
2983
2984
10.3.5
Technical safety report
10.3.5.1 The Technical Safety Report consists of technical evidence for the safety of the design
and shall explain the technical principles which assure the safety of the design, including (or
giving references to) all supporting evidence (for example, design principles and calculations,
test specifications and results, and safety analyses).
2985
2986
2987
10.3.5.2 All safety cases shall include a Technical Safety Report. However, the depth of the
information and the extent of the supporting documentation should be appropriate to the safety
targets of the system/subsystem/ equipment under scrutiny.
2988
10.3.5.3 The Technical Safety Report should be arranged under the following headings:
2989
10.3.5.3.1
2990
2991
2992
2993
This section shall provide a summary of the technical safety principles that are relied on for
safety and the extent to which the system/sub-system/equipment is claimed to be safe in
accordance with this standard, together with an overview description of the design if this is not
already sufficiently covered by the system definition (see section 10.3.1 above).
2994
2995
This section shall also indicate the standards (and their issues) used as the basis for the
technical safety of the design.
2996
10.3.5.3.2
2997
2998
2999
This section shall contain all the evidence necessary to demonstrate correct operation of the
system/subsystem/ equipment under fault-free normal conditions (that is, with no faults in
existence), in accordance with the specified operational and safety requirements.
Introduction
Assurance of correct functional operation
prEN 50126-1
- 78 -
3000
10.3.5.3.3
Effects of faults
3001
3002
3003
This section shall demonstrate that the system/sub-system/equipment continues to meet its
specified safety requirements, including the quantified safety targets, in the event of random
hardware faults.
3004
3005
3006
In addition, a systematic fault could still exist, despite following the quality and safety
management processes defined in this standard. This section shall demonstrate which technical
or operational measures have been taken to reduce the consequent risk to an acceptable level.
3007
3008
3009
This section shall also include demonstration that faults in any system/sub-system/equipment
having a Safety Integrity Level lower than that of the overall system, including Level 0, cannot
reduce the safety of the overall system.
3010
3011
The following headings should be used in this section, for which more detailed requirements are
contained in EN 50126-2:
3012
Effects of single faults;
3013
Independence of items;
3014
3015
Detection of single faults and action following detection (including retention of safe
state);
3016
Effects of multiple faults;
3017
Defence against systematic faults.
3018
10.3.5.3.4
Operation with external influences
3019
3020
This section shall demonstrate that when subjected to the external influences defined in the
System Requirements Specification, the system/sub-system/equipment
3021
continues to fulfil its specified operational requirements;
3022
continues to fulfil its specified safety requirements (including fault conditions).
3023
3024
3025
The safety case is therefore valid only within the specified range of external influences, as
defined in the System Requirements Specification. Safety is not assured outside these limits,
unless additional special measures are provided.
3026
3027
The methods used to withstand the specified external influences shall be fully explained and
justified.
3028
10.3.5.3.5
3029
3030
This section shall specify (or reference) the rules, conditions and constraints which shall be
observed in the application of the system under consideration.
3031
10.3.5.3.6
3032
3033
This section shall contain evidence to demonstrate successful completion, under operational
conditions, of the Safety Qualification Tests.
3034
10.3.6
3035
3036
3037
This shall contain references to the safety cases of any sub-systems or equipment on which the
main safety case depends. It shall explain how the main safety case depends on the related
safety cases.
3038
3039
3040
It shall also demonstrate that all the safety-related application conditions specified in each of the
related sub-system/equipment safety cases are either fulfilled in the main safety case, or carried
forward into the safety-related application conditions of the main safety case.
3041
10.3.7
3042
3043
3044
This shall summarise the evidence presented in the previous parts of the safety case, and argue
that the relevant system/sub-system/equipment is adequately safe, subject to compliance with
the specified application conditions.
Application conditions
Safety qualification tests
Related safety cases
Conclusion
- 79 -
prEN 50126-1
3045
10.3.8
References
3046
3047
3048
3049
Large volumes of detailed evidence and supporting documentation need not be included in the
safety case and in its parts, provided this section contains precise references to such
documents and provided the base concepts used and the approaches taken are clearly
specified.
prEN 50126-1
- 80 -
3050
Annex A (informative) RAMS plan
3051
3052
3053
A.1 This annex gives an example of an outline procedure for a basic RAM plan/safety plan describing a
RAMS programme and shows an example of a basic RAMS plan (RAM plan/safety plan). It also lists
some methods and tools for RAMS management and analysis.
3054
3055
3056
3057
A.2 The supplier should establish a RAMS plan which will effectively facilitate meeting the RAMS
requirements of the application under consideration. The RAMS Programmes of similar projects or
system requirements of a supplier may yield a standard RAMS programme which establishes the
RAMS-Baseline of a company.
3058
A.3 Procedure
3059
3060
3061
3062
An outline example procedure for a basic RAMS plan is given below.

1. Define the appropriate life-cycle phases respectively project phases which are in line
with the companys business process;
Result: The Companys life-cycle or project phases are established
3063
3064
3065
3066
2. Assign to each life-cycle or project phase the phase related RAM and safety tasks
which are necessary to confidently meet the project and system specific
requirements;
Result: All necessary RAMS tasks in the life-cycle or project are identified
3067
3068
3. Define the responsibilities in the company to carry out each RAMS task;
Result: The responsible staff and necessary RAMS resources are identified
3069
3070
3071
4. The necessary instructions, tools and reference documents for each RAMS task are
defined;
Result: Documented RAMS management
3072
3073
5. The RAMS activities are implemented in the processes of the company.

Result: Process integrated RAMS management (RAMS-Baseline)
3074
3075
3076
A.4
Basic RAMS plan example
An outline for a basic RAMS plan is given in Table A.1. The outline consists of an example of a
set of tasks which could be applied to a particular project.
- 81 3077
prEN 50126-1
Table A.1 - Example of a Basic RAMS Plan Outline

Project-Phase
RAMS Tasks
PreAcquisition
Evaluate RAMS targets of specific application
Feasibility
Study
Evaluate RAMS requirements
Evaluate past data and experience of RAMS
- Identify influence on Safety imposed by

specific application
Invitation for
Tenders
Consult customer on RAMS (if necessary)
- Perform preliminary RAMS analysis (Worst

case)
- Apportion system RAMS requirements (Subsystems/equipment, other relevant systems etc.)
-
Perform system hazard & safety risk analysis
Perform RAM related risk analysis
Prepare for future RAMS data assessment
Clause to clause comments concerning RAMS
Contract
Negotiations
- Review/update preliminary RAMS analysis

and RAMS apportionment
Order
Processing:
Establish project specific RAMS management
Specify system RAMS requirements (overall)
- Definition of
system
requirements
- Establish RAMS plan (Standard RAMS plan

sufficient?)
- Assign RAMS requirements to subcontractors, suppliers
Order
Processing:
Design and
Implementati
on
Define RAMS acceptance criteria (overall)
Reliability analysis (FMEA)
Safety analysis (FMECA), if applicable
- Maintenance/repair analysis; define

maintenance/repair policy
- Availability analysis based on the
maintenance/repair policy
-
RAMS reviews
Life-cycle Cost estimation
RAMS demonstration, evidence compilation
Design/manufacturing FMEA
- Reliability and maintainability testing, if

applicable
Procurement
- Provide RAMS specification for subcontractors/suppliers
Manufacturin
g / Testing
- RAMS related quality assurance/process

assurance
Responsibility
Reference
Document
prEN 50126-1
- 82 -
Project-Phase
Commissioni
ng /
Acceptance
RAMS Tasks
-
Perform RAM demonstration
Prepare specific application safety case
Initiate RAMS data assessment
Responsibility
Reference
Document
- RAM testing during early operation, data

screening and evaluation
Operation /
Maintenance
- Provisional operation and maintenance

(Maintenance/repair policy)
-
Operation and maintenance personnel training
RAMS data assessment
Life-cycle Cost assessment
Performance review
3078
3079
3080
3081
A.5
List of tools
Some appropriate methods and tools for conducting and managing a RAMS programme are
listed below. The choice of the relevant tool will depend on the system under consideration and
the criticality, complexity, novelty etc., of the system.
3082
3083
1. An outline form of RAMS specification in order to assure assessment of all relevant

RAMS requirements.
3084
3085
2. Procedures for formal design reviews with emphasis on RAMS, using some general
and application specific check lists as appropriate, e.g.
IEC 61160:2006
3086
3087
3088
3089
3090
3091
3. Procedures for performing "top down" (deductive methods) and "bottom up" (inductive
methods) preliminary, worst case and in-depth RAM analysis for simple and complex
functional system structures
An overview of commonly used RAM analysis procedures, methods, advantages and
disadvantages, data input and other requirements for the various techniques is given
in:
IEC 60300-3-1
3092
3093
Design review
Dependability management - Part 3: Application guide Section 1: Analysis techniques for dependability: Guide on
methodology
The various RAM analysis techniques are described in separate standards, some of
these are as follows:
- 83 -
3094
3095
3096
3097
IEC 60706
Guide on maintainability of equipment
IEC 60706-1
Part 1 - Sections 1, 2 and 3: Introduction, requirements and

maintainability programme
IEC 60706-2
Part 2 - Maintainability requirements and studies during the

design and development phase
IEC 60706-3
Part 3 - Verification and collection, analysis and

presentation of data
IEC 60706-5
Part 5 - Testability and diagnostic testing
IEC 60706-6
Part 6 - Section 9: Statistical methods in maintainability

evaluation
IEC 60812
Analysis techniques for system reliability - Procedures for

failure mode and effects analysis (FMEA)
IEC 61025
Fault tree analysis (FTA)
IEC 61078
Analysis techniques for dependability - Reliability block

diagram and boolean methods
IEC 61165
Application of Markov techniques
Availability of supportable statistical "RAM" data, for the components used in a
design, (typically: failure rates, repair rates, maintenance data, failure modes, event
rates, distribution of data and random events etc.) is fundamental to RAM analysis,
e.g.
IEC 61709
3098
3099
3100
3101
prEN 50126-1
Electronic components - Reliability - Reference conditions

for failure rate and stress models for conversion
MIL-HDBK-217F_2
Reliability Prediction for Electronic Systems
A number of computer programmes for system RAM analysis and statistical data
analysis are also available.
4. Procedures for performing hazard & safety/risk analysis
Some of these are described in:
MIL-STD-882D
Standard Practise for System Safety
MIL-HDBK-764 (MI)
3102
3103
System Safety Engineering Design Guide For Army

Materiel
The same basic techniques and analysis methods listed for RAM (item 3), are also
applicable for safety/risk analysis.
3104
3105
3106
Also see IEC 61508 Parts 1-7 under the general title "Functional safety of
electrical/electronic/programmable electronic safety-related systems", consisting of
the following parts:
3107
IEC 61508-1:2010
Part 1: General requirements
IEC 61508-2:2010
Part 2: Requirements for

electrical/electronic/programmable electronic systems
IEC 61508-3:2010
Part 3: Software requirements
IEC 61508-4:2010
Part 4: Definitions and abbreviations
IEC 61508-5:2010
Part 5: Examples of methods for the determination of safety

integrity levels
IEC 61508-6:2010
Part 6: Guidelines on the application of Parts 2 and 3
IEC 61508-7:2010
Part 7: Overview of techniques and measures
5. RAMS testing plans and procedures
prEN 50126-1
3108
3109
3110
3111
3112
3113
3114
3115
- 84 -
This step is in order to test the long-term operating behaviour of components,

equipment or systems and to demonstrate compliance with the requirements.
Furthermore RAMS analysis and test results are used to devise RAMS improvement
programmes, e.g.
IEC 60605
Equipment reliability testing
IEC 60605-2
Part 2: Design of test cycles
IEC 60605-3-1
Part 3: Preferred test conditions. Indoor portable equipment

- Low degree of simulation
IEC 60605-4
Part 4: Statistical procedures for exponential distribution Point estimates, confidence intervals, prediction intervals
and tolerance intervals
IEC 60605-6
Part 6: Tests for the validity of the constant failure rate or

constant failure intensity assumptions
IEC 61014
Programmes for reliability growth
IEC 61070
Compliance test procedure for steady-state availability
IEC 61123
Reliability testing - Compliance test plan for success ratio
Of greater importance is the assessment of RAMS data from the field (RAMS testing
during operation), e.g.:
IEC 60300-3-2
Dependability management - Part 3: Application guide Section 2: Collection of dependability data from the field
IEC 60319
Presentation of reliability data on electronic components (or

parts)
6. Procedures/tools to perform LCC analysis (Life-cycle Cost)

Various computer programmes are available for LCC analysis.
- 85 -
prEN 50126-1
3116
Annex B (informative) Examples of parameters for railway.
3117
3118
Examples of typical parameters and symbols, suitable for use in railway applications, are
tabulated below:
3119
3120
In general any time-based parameter like MTBF can be converted/ derived from the respective
operated distance or operation cycles as well.
3121
Definition and detailed guidance on mathematical treatment of RAM terms is given in EN 61703.
3122
B.1
3123
Table B.1 - Examples of reliability parameters
Reliability parameters
Parameter
Symbol
Dimension
Failure Rate
(t)
1/time, 1/distance, 1/cycle
Mean Up Time
MUT
time (distance, cycle)
MTTF
MTBF
Mean Repair Time
MRT
time
Failure Probability
F(t)
dimensionless
Reliability (Success Probability)
R(t)
dimensionless
Mean operating
3)
Time To Failure
(for non-repairable items)

Mean operating 3) Time Between
Failure
(for repairable items)
3124
B.2
Maintainability parameters
3125
Table B.2 - Examples of maintainability parameters

Parameter
Mean Down Time
Symbol
Dimension
MDT
MTBM
time (distance, cycles)
MTBM (corrective or preventive)
MTBM(c), MTBM(p)
time (distance, cycles)
Mean Time To Maintain
MTTM
time
MTTM (corrective or preventive)
MTTM(c), MTTM(p)
time
Mean Time To Restore
MTTR
time
Fault Coverage
FC
dimensionless
Repair Coverage
RC
dimensionless
Mean operating
Maintenance
3)
Time Between
3126
3127
3128
Operating signifies the time, distance or cycles where the item under consideration is
effectively in use.
3129
3) According to EN 61703 and IEC 60050-191-2
prEN 50126-1
- 86 -
3130
B.3
Availability parameters
3131
Table B.3 - Examples of availability parameters

Parameter
3132
3133
Dimension
Availability
inherent
operational
A
Ai
Ao
dimensionless
Fleet Availability
FA
dimensionless
Schedule Adherence
SA
dimensionless or time
Under certain conditions, for instance constant failure rate and constant repair rate, the steadystate availability may be expressed by
3134
3135
Symbol
MUT
1.
MUT MDT
with 0 A 1 and generally has a value close to 1. Its complement is called unavailability U.
U 1 A
3136
MDT
0 .
MTBF MDT
3137
3138
3139
Depending from the type of availability A to be considered, it has to be decided which fractions
of MDT are relevant and therefore, taken into consideration for calculation. These fractions are
to be defined.
3140
3141
Detailed guidance on calculations for systems with different properties and different repair
characteristics is given in EN 61703.
3142
The availability concept is illustrated by Figure B.1
3143
3144
3145
3146
For an item / system which is permanently in operation mode and no planned preventive
maintenance is applied, MUT=MTBF holds. In this case MUT and MTBF can be used
interchangeably for calculating the (steady state) operational availability. It may then be
expressed by
3147
3148
MTBF is typically based on the time the system is in use (operated).
3149
3150
3151
3152
The parties involved should agree on the understanding of all the terms used (e.g. the MTBF
time basis suitable for the specific application under consideration or which type of delay is
taken into account). In case of contractual obligations it is highly recommended to stipulate the
agreements.
MUT
MTBF
1
MUT MDT MTBF MDT
- 87 -
prEN 50126-1
3153
3154
READY FOR
SERVICE
CORRECTIVE
MAINTENANCE START
FAILURE
up state
up state
down state
Administrative and
logistics delay
Investigation
time
Repair/exchange
time
MRT
MAD + MLD
MTBF MUT
MTBF MUT
MTTR = MDT
mean (operating) time between failures
MAD
mean administrative delay
MUT
mean up time
MLD
mean logistics delay
MDT
mean down time
MTTR
mean time to restore (for corrective maintenance)
MRT
mean repair time
MTBF
3155
Time to
check/test
the system
Definitions can be found in EN 61703.
3156
3157
3158
3159
3160
3161
Figure B.1 Availability concept and related terms
3162
3163
3164
The definitions of Fleet Availability (FA) as well as of Schedule Adherence (SA) are normally the
subject of contractual negotiations. Therefore the elaboration of both parameters is not provided
in this standard.
NOTE 1 Detailed guidance on calculations with different system properties and different repair characteristics is given
in EN 61703.
NOTE 2 Restoration can be achieved by repair, exchange, reset or other means.
prEN 50126-1
- 88 -
3165
B.4
Logistic support parameters
3166
Table B.4 - Examples of logistic support parameters

Parameter
Symbol
Operation and Maintenance Cost
O&MC
money
Maintenance Cost
MC
money
Maintenance Man Hours
MMH
time (hours)
Logistic and Administrative Delay
LAD
time
Fault correction time
time
Repair time
time
Turn Around Time
TAT
time
Maintenance support performance
dimensionless
Employees for Replacement
EFR
number
Probability that Spare Parts are

available (in Stock) when needed
SPS
dimensionless
3167
B.5
3168
Table B.5 - Examples of Safety performance parameters
Safety parameters
Parameter
3169
Dimension
Symbol
Dimension
Hazard rate
h(t)
1/time, 1/distance,
1/cycle
Probability of wrong-side failure
p WSF
dimensionless
Active time to return to safe state
time
- 89 -
prEN 50126-1
3170
3171
Annex C (informative) Hazards at railway system level example structured

list
3172
The objectives of this annex are:
3173
to provide generic guidance on the creation of hazard lists and,
3174
3175
to provide guidance on how hazards lists can be structured and on how hazards at
different levels interface with each other and;
3176
to provide, through example, guidance for the naming or description of hazards and,
3177
to exemplify a structured list of hazards applicable to railway applications.
3178
3179
It does not intend to provide guidance on hazard identification since this is covered in EN
50126-2 (clause 8.2).
3180
3181
3182
3183
The result of hazard identification exercises is often a list of scenarios which have been derived
from failures, both operational and technical, from possible accidents, from brainstorming or
from pre-existing lists of hazards. These scenarios will often need honing into a structured list in
keeping with the system under consideration.
3184
3185
3186
3187
3188
3189
In general, hazards can be derived and structured based on various perspectives (e.g.
functional, physical, organisational etc.) and the choice of perspective or combination of
perspectives needs to consider the requirements of the specific application. Where possible,
hazards should be defined at a sufficiently high level that they remain generic and independent
of specific solutions or implementation issues of railway operation, yet also be detailed enough
to provide a good focus point for safety control.
3190
3191
3192
3193
3194
3195
3196
In defining a hazard it is important to consider that a hazard has a causal domain and
consequence domain. Consequently, the hazards should be defined at level facilitating causal
analysis (identification of and relationship between the underlying causes) and consequence
analysis. With regard to the consequence analysis and in accordance with the definition of the
term hazard, the hazard should not be defined at the accident level. This allows the
consideration of safety barriers and factors which influence the progression of the hazard to
potential consequences, including accidents.
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
It is best practice to define a hazard at the boundary of the system under consideration, i.e. the
point where the causes of the hazard come from within the system or the operation of the
system, considering human interaction where appropriate. Ideally, the consequence domain of
the hazard would then consider the influences of the environment within which the system under
consideration operates, but not further influences of the system itself. However, this may not
always be possible and there may be cases where the system can also influence the
consequence domain (e.g. consider a hazard train braking ability impaired or lost from the
perspective of the train sub-system. This hazard could be caused by failures in the transmission
of the brake command and there may be nothing more that the system can do to avoid this
hazard. However, the use of the onboard train radio could mitigate the consequences by alerting
the signaller and other drivers).
3208
3209
In general, hazards should consider technical and operation as well as circumstantial aspects
where applicable, since typically these can not be easily or meaningfully separated.
3210
3211
3212
When defining a hazard and its scope, consideration of the mechanisms present in the
consequence domain should be taken. For the purpose of analysis, it is sensible to separate
scenarios associated with dissimilar mechanisms and define separate hazards.
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
It is often beneficial to group hazards together based on hazard characteristics and structure the
hazards in a hierarchy. As mentioned previously the chosen grouping and structure need to
reflect the requirements of the specific application. It is important to note that it is unlikely that
hazards will be mutually exclusive. That is to say that hazard domains (causal and
consequence) will interact with each other and, for example, certain hazards will be the causes
for other hazards. Although a mutually exclusive hazard structure is beneficial and should be
strived for, in reality this will often be difficult to achieve. A simple example of the interaction
between hazards and a hierarchy of hazards can be seen via the systems approach, whereby a
systems hazards may form the causal events for hazards of the next higher level system.
Furthermore, a systems hazard may be a causal event in two or more hazards in the next
system level.
prEN 50126-1
- 90 -
3224
C.1
3225
3226
3227
3228
3229
The list presented below in Table C.1 can be used as a basis for hazard identification and in the
standardisation of hazard naming. However, the list is not exhaustive, and since any hazard
identification depends on the system under consideration and the perspective of the entity
undertaking the identification, the list, as with any predefined hazard list, requires adaptation in
accordance with the specific application.
3230
3231
3232
3233
3234
3235
3236
3237
The list has been derived on the basis of two hazard levels. The 1st hazard level represents
hazards from the perspective of the railway applications system as a whole. The 2nd level
hazards are those seen at the boundaries of subsystems, in this case the subsystems of the
three application fields (Signalling, Rolling Stock, Fixed Installations) within the scope of this
standard. Dependent on the specific application the 1st or 2nd level of hazards may be sufficient
for analysis. In other cases, the 2nd level hazards may need to be broken down further into
lower level hazards (e.g. to consider hazards at the boundaries of the next level of subordinate
subsystems).
3238
3239
3240
3241
The 2nd level hazards may be assigned to the application fields where the hazards would likely
feature in the risk analysis of the related subsystems. Such an assignment at an early stage of
the analysis helps to identify the stakeholders involved and to optimise the agreement of the
necessary hazard and risk control measures.
3242
3243
3244
3245
3246
3247
3248
3249
The railway system behind this structure is based on the architecture and organisation of some
traditional railway applications. Since hazards are not necessarily confined to the three
application fields within the scope of this standard, a column other application field(s) has
been included to indicate where this may be the case. Again, the exact assignment of hazards is
dependent on the specific application. However, the list serves to demonstrate that a hazard
may be influenced by sub-systems under the responsibility of one or several entities and to
highlight the necessity to consider the interfaces between entities in the safety management
process.
3250
This hazard list was primarily derived from the functional perspective of the railway.
3251
3252
3253
Table C.2 provides some example scenarios associated with the listed hazards. The examples
aim to provide an understanding of the scope of the hazard, primarily through, but not limited to
example causal scenarios.
3254
Example list
- 91 -
H1
Inadequate separation between trains
H 1.1
Degraded ability to locate train
H 1.2
Insufficient control of train speed
H 1.3
Inappropriate control of train movement
H 1.4
Train braking ability impaired or lost
H 1.5
Unintended loss of train integrity
H2
Structure clearance impaired or straight line not cleared
H 2.1
Unsound/unsecured structures/components/objects
H 2.2
Train kinematic envelope outside tolerable limit
H 2.3
Object in path of train
H 2.4
H 2.5
Inappropriate separation between train and level crossing user
H3
Insufficient track guidance
H 3.1
Infrastructure guidance function degraded
H 3.2
Vehicle guidance function degraded
H 3.3
H 3.4
H 3.5
H4
Safe boarding and alighting impaired
H 4.1
Loss of balance
H 4.2
Inappropriate separation between persons and closing doors
H 4.3
3256
1) Command Control & Signalling

2) Rolling Stock
3) Traction Power Supply
4) Other Application Field(s)
Other 4)
Hazards (1 st and 2 nd level)
Power 3)
ID
RoSto 2)
Table C.1 - Example for a hazard list
Sig 1)
3255
prEN 50126-1
prEN 50126-1
- 92 -
H5
Safe stay impaired (trackside/ inside train)
H 5.1
Loss of balance
H 5.2
H 5.3
Inappropriate environment
H 5.4
Unsound/unsecured structures/components/objects
H 5.5
Inappropriate separation between persons and running railway
H 5.6
Exposure to excessive noise levels
H 5.7
Inadequate containment of harmful substances
H 5.8
Inappropriate separation between person and heat source
H6
Insufficient control of emergency situations
H 6.1
Inadequate crash worthiness
H 6.2
Inadequate emergency exit or entry of train
H 6.3
Insufficient emergency equipment
H 6.4
Inability to reach safe location
H7
Onset of fire or smoke
H 7.1
Onset of fire or smoke
H8
Impaired protection against electric shock
H 8.1
Inappropriate separation between live conductor and person
H 8.2
Inappropriate touch voltage
H9
Inappropriate levels of electro-magnetic Interference (EMI)
H 9.1
Intolerable electromagnetic interference of other systems
H 9.2
Intolerable electromagnetic interference from other systems
H 10
Shock wave (explosion, air, pressure)
H 10.1
H 11
Hazardous substances
H 11.1
Inappropriate separation between persons and hazardous

substances
5)
5)
6)
6)
5) hazard not confined to the functional perspective

6) hazard define other than the functional perspective
6)
- 93 3257
prEN 50126-1
Table C.2 - Example scenarios

Hazard
Example scenarios
Degraded ability to locate train
faulty signalling equipment (e.g. axle counters), train

axle resistance too high for detection by track circuit
tachometer information incorrect, failure of ATP system

to intervene (e.g. through incorrect tacheometry or
failure to initiate emergency brake), uncontrolled
approach to buffer
Inappropriate control of train

movement
Signalling wrong side failure / signals or points

incorrectly set for safe train movement (interlocking
failure), train movement in wrong direction, unintended
train departure, failure of ATP system to intervene (e.g.
through incorrect tacheometry or failure to initiate
emergency brake)
failure of brake sub system, failure to transmit brake

command
undesired separation at automatic/manual/fixed

coupler during journey
Door opens during journey, window smashes
Unsound/unsecured
structures/components/objects
infrastructure (e.g. signalling equipment, overhead

contact system) out of gauge
Lineside structures (e.g. bridges, signalling structures,
overhead contact system) fall
Train kinematic envelope outside

tolerable limit
door/door step opens during journey, failure or train

suspension or train tilting function
Object in path of train
Animals, road vehicles and other objects normally

outside the railway system on line or hung/thrown in
front of oncoming train
Unsound/unsecured
structures/components/objects
Train components become loose and fall (inside train

or from train, e.g. onto track), luggage falls from
luggage rack, catenary or its parts fall down
Infrastructure guidance function

degraded
track condition degraded
Vehicle guidance function degraded
Wheel-rail interface impaired as a result of blocked

axle / hot axle (including monitoring), suspension /
damper failure
failure of brake sub system, failure to transmit brake

command
Loss of balance
excessive change in acceleration / deceleration,

slippery surface, trip hazards in walkways etc.
Inappropriate environment
climate too hot, excessive pressure wave
Inappropriate separation between

persons and closing doors
lack of train perception, passengers too close to

platform edge
prEN 50126-1
3258
- 94 -
Hazard
Example scenarios
Exposure to excessive noise levels
considers sources of noise levels harmful to humans in

the long or short term
Inadequate containment of harmful

substances
Leakage or generation of toxic, corrosive substances,

asphyxiate etc. which may be detrimental to human
health or to the environment.
Inadequate crash worthiness
insufficient car strength, inadequate anticlimbing

devices
Inadequate emergency exit or entry of

train
doors cannot be opened, lack of emergency windows

etc., inadequate emergency exits in tunnel
Insufficient emergency equipment
lack of fire extinguishers, emergency lighting etc.
Inability to reach safe location
running capability in the event of fire
Onset of fire
electrical isolation failures, exposure of flammable

liquids/gases to ignition source, overheating of
components due to friction.
excessive build up of pressure in components/sealed

or pressurised vessels (through fire, electric currents
etc.), loss of structural integrity of pressure vessels.
Inappropriate separation between live

conductor and person
Touch voltage exceeded, inadequate separation

between high voltage equipment and person etc.
Intolerable electromagnetic
interference of other systems
EM radiation from equipment interferes and degrades

the operation of a safety related function (e.g.
pacemakers, axel counters)
Intolerable electromagnetic
interference from other systems
EM radiation from external source interferes and

degrades the operation of a safety related function of
the system under consideration
- 95 -
prEN 50126-1
Annex D (informative) Risk matrix calibration and risk acceptance

categories
3259
3260
3261
This annex provides examples of application of a risk matrix and its parameters.
3262
D.1
3263
3264
The following Table D.1 and Table D.2 give examples of frequency levels, adapted to a
particular use.
3265
3266
The use of these particular examples is not mandatory, other classification can be used. More
than one matrix can be used when this method is applied.
3267
3268
based)
Frequency of occurrence levels
Frequency
level
Description
Example of a range of
frequency based on
operation of
24h / day
Example of
equivalent
occurrence in a 30
year lifetime of
5000 h operation /
year
Expected to happen
Frequent
Likely to occur frequently.

The event will be
frequently experienced.
more than once within a

period of approximately
6 weeks
more than about 150

times
Probable
Will occur several times.

The event can be
expected to occur often.
approximately once per

6 weeks to once per
year
about 15 to 150 times
Occasional
Likely to occur several

times.
The event can be
expected to occur several
times.

1 year to once per 10
years
about 2 to 15 times
Rare
Likely to occur sometime

in the system life-cycle.
The event can reasonably
be expected to occur.

10 years to once per
1 000 years
perhaps once at most
Improbable
Unlikely to occur but

possible.
It can be assumed that the
event may exceptionally
occur.

1 000 years to once per
100 000 years
not expected to
happen within the
lifetime
Highly
improbable
Extremely unlikely to
occur. It can be assumed
that the event may not
occur.
once in a period of
approximately 100 000
years or more
extremely unlikely to
happen within the
lifetime
3269
3270
3271
NOTE This table is related to a single item (system/function/component). The examples given depend from the
number of systems and/or the number of e.g. operational hours considered.
3272
3273
3274
The expected mean time between two events is determined by the given reciprocal value of the
frequency. For a frequency level bandwidth this formula has to be applied for its upper as well
as its lower limit.
3275
Example for a rate of 10 -4 h -1 :
3276
1/ 10 -4 h -1 = 10 000 h which means an expected event frequency of approximately:
3277
1,2 years in case of 24 h operation
prEN 50126-1
3278
- 96 -
or 2 years in case of assumed 5 000 h operating time per year.
3279
3280
3281
The expected occurrence or number of events in a time period is determined by the given time
period multiplied by the given rate or frequency of occurrence. The time period has to be
reduced if calendar time is not appropriate.
3282
3283
E.g.: 10 -4 h -1 x (30 years x 5 000 h/years) = 15 The event is expected to happen

approximately 15 times within 30 years if 5 000 operational hours per year are assumed.
3284
The considered time is an average and not necessarily a continuous time.
3285
A distance based approach is given in Table D.2.
3286
3287
based)
Frequency level
Description
Example of a range of frequency
F1
Likely to occur often
more than once every 5 000 km per train
F2
Will occur several times
once every 25 000 km per train
F3
Might occur sometimes
Once every 100 000 km per train
3288
3289
D.2
Severity levels
3290
The following tables give examples of severity levels, related to a particular use.
3291
Table D.3 - Severity categories (example related to RAM)

RAM severity
level
Significant
(immobilising
failure)
Major
(service failure)
Minor
3292
Description
A failure that:
prevents train movement or
causes a delay to service greater than a specified time
and/or generates a cost greater than a specified level
A failure that:
must be rectified
performance and
does not cause a delay or cost greater than the minimum threshold
specified for a significant failure
for
the
system
to
achieve
its
specified
A failure that:
does not prevent a system achieving its specified performance and
does not meet criteria for Significant or Major failures
- 97 3293
prEN 50126-1
Table D.4 - Severity categories (example 1 related to RAMS)

Severity level
Consequences to persons or environment
Consequences on
service/property
Catastrophic
Many fatalities and/or extreme damage to the

environment.
Critical
Severe injuries and/or few fatalities and/or large

damage to the environment.
Loss of a major
system
Marginal
Minor injuries and/or minor damage to the

environment
Severe system(s)
damage
Insignificant
Possible minor injury
Minor system
damage
3294
3295
Table D.5 - Categories (example 2 related to Safety)

Severity
level
Consequences to persons or environment
S1
Many equivalent fatalities (likely more than about 10) or extreme damage to the
environment.
S2
Multiple equivalent fatalities (likely less than about 10) or large damage to the
environment.
S3
Single fatality or severe injury or significant damage to the environment.
S4
Minor injuries or minor damage to the environment
S5
Possible minor injury
3296
3297
Table D.6 - Financial severity levels (example)

Severity
level
Financial consequences
SF1
The incident will incur people suing the company, severe impact to the public
image of the company, and/or incur costs higher than 1000 000.
SF2
The incident may have an impact on the public image of the company and/or
incur costs higher than 100 000
SF3
The incident will not incur costs higher than 100 000
3298
D.3
Risk acceptance categories
3299
3300
3301
Risk acceptance categories allocated to identified risks allow classification for the purpose of
decision making. Examples of risk acceptance categories are shown in Table D.7 and Table D.8
below:
3302
Table D.7 - Risk acceptance categories (example 1 for binary decisions)

Risk
Acceptance
Category
3303
Actions to be applied
Unacceptable
The risk needs further reduction to be accepted
Acceptable
The risk is accepted provided adequate control is maintained
prEN 50126-1
3304
- 98 -
Table D.8 - Risk acceptance categories (example 2)

Risk
Acceptance
Category
Actions to be applied
Intolerable
The risk shall be eliminated
Undesirable
The risk shall only be accepted if its reduction is impracticable and with the
agreement of the railway duty holders or the responsible Safety Regulatory
Authority.
Tolerable
The risk can be tolerated and accepted with adequate control (e.g.
maintenance procedures or rules) and with the agreement of the responsible
railway duty holders.
Negligible
The risk is acceptable without the agreement of the railway duty holders.
3305
3306
Table D.9 - Risk acceptance categories (example related to safety)

Frequency of
occurrence of an
accident (caused by a
hazard)
Risk Acceptance Levels
Frequent
Undesirable
Intolerable
Intolerable
Intolerable
Probable
Tolerable
Undesirable
Intolerable
Intolerable
Occasional
Tolerable
Undesirable
Undesirable
Intolerable
Rare
Negligible
Tolerable
Undesirable
Undesirable
Improbable
Negligible
Negligible
Tolerable
Undesirable
Highly improbable
Negligible
Negligible
Negligible
Tolerable
II
III
IV
Severity of an accident (caused by a hazard)
- 99 -
prEN 50126-1
Annex E Bibliography
3307
3308
3309
EN 614
Safety of machinery - Ergonomic design principles
IEC 60300-3-1
Dependability management Part 3-1: Application guide Analysis

techniques for dependability Guide on methodology
IEC 60300-3-2
Dependability management Part 3-2: Application guide Collection of

dependability data from the field
IEC 60319
Presentation and specification of reliability data for electronic

components
IEC 60605-2
Equipment reliability testing Part 2: Design of test cycles
IEC 60605-3-1
Equipment reliability testing. Part 3: Preferred test conditions. Indoor

portable equipment - Low degree of simulation
IEC 60605-4
Equipment reliability testing Part 4: Statistical procedures for

exponential distribution Point estimates, confidence intervals,
prediction intervals and tolerance intervals
IEC 60605-6
Equipment reliability testing Part 6: Tests for the validity and estimation
of the constant failure rate and constant failure intensity
IEC 60706-1
Guide on maintainability of equipment Part 1: Sections 1, 2 and 3:

Introduction, requirements and maintainability programme
IEC 60706-2
Maintainability of equipment Part 2: Maintainability requirements and

studies during the design and development phase
IEC 60706-3
Maintainability of equipment Part 3: Verification and collection, analysis

and presentation of data
IEC 60706-5
Maintainability of equipment Part 5: Testability and diagnostic testing
IEC 60706-6
Guide on maintainability of equipment Part 6: Section 9: Statistical

methods in maintainability evaluation
IEC 60812
Analysis techniques for system reliability Procedures for failure mode

and effects analysis (FMEA)
IEC 61014
Programmes for reliability growth
IEC 61025
Fault tree analysis (FTA)
IEC 61070
Compliance test procedures for steady-state availability
IEC 61078
Analysis techniques for dependability Reliability block diagram and

boolean methods
IEC 61123
Reliability testing; compliance test plans for success ratio
IEC 61160
Design review
IEC 61165
Application of Markov techniques
IEC 61508
Functional safety of electrical/electronic/programmable electronic safetyrelated systems
IEC 61703
Mathematical expressions for reliability, availability, maintainability and

maintenance support terms
IEC 61709
Electronic components Reliability Reference conditions for failure

rate and stress models for conversion
IEC-TR-62380
Reliability data handbook - Universal model for reliability prediction of

electronics components, PCBs and equipment

Railway RAMS Process and Life-Cycle Stages

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Railway RAMS Process and Life-Cycle Stages

Transféré par

Droits d'auteur :

Formats disponibles

-1-

Applications ferroviaires Spcification et dmonstration de la fiabilit, de la

Bahnanwendungen - Spezifikation und Nachweis von Zuverlssigkeit, Verfgbarkeit,

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

Terms and definitions ...................................................................................................10

Process overview .........................................................................................................21

5.1 Purpose of overview ............................................................................................21

7.2 System life-cycle .................................................................................................41

10.1 Purpose of a safety case .....................................................................................74

10.3.8 References ..............................................................................................79

Annex B (informative) Examples of parameters for railway. ..................................................85

C.1 Example list.........................................................................................................90

Reliability parameters ..........................................................................................85

Frequency of occurrence levels............................................................................95

Figure 2 Illustration of system hierarchy ...........................................................................26

Figure 3 Example of deriving cause/effect relations in a diagrammatic approach ...............34

Figure 4 Relationship of cause, hazard and accident ........................................................38

Figure 5 The "V" representation drawing ..........................................................................44

Figure 6 - verification ..........................................................................................................45

Figure 7 - validation ............................................................................................................45

Figure 8 Structure of a safety case ...................................................................................75

Figure B.1 Availability concept and related terms ..............................................................87

Table 2 - Frequency - Severity Matrix ..................................................................................72

Table A.1 - Example of a Basic RAMS Plan Outline .............................................................81

Table B.1 - Examples of Reliability Parameters ...................................................................85

Table B.2 - Examples of Maintainability Parameters ............................................................85

Table B.3 - Examples of availability parameters...................................................................86

Table B.4 - Examples of logistic support parameters............................................................88

Table B.5 - Examples of Safety performance parameters .....................................................88

Table C.1 - Example for a hazard list...................................................................................91

Table C.2 - Example scenarios............................................................................................93

Table D.5 - Severity categories (example related to RAM) ...................................................96

Table D.6 - Severity categories (example 1 related to RAMS) ..............................................97

Table D.7 - Categories (example 2 related to S) ..................................................................97

Table D.8 - Financial severity levels (example) ....................................................................97

Table D.10 - Risk acceptance categories (example 2)..........................................................98

Table D.11 - Risk acceptance categories (example related to safety) ...................................98

The following dates were fixed:

a) latest date by which the EN has to be implemented

b) latest date by which the national standards conflicting

This document supersedes EN 50126-1:1999, EN 50128:2011 and EN 50129: 2003.

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

The standard EN 50126-1:1999 was produced to introduce the application of a systematic

This part 1 of EN 50126

considers RAMS, understood as reliability, availability, maintainability and safety and

enables conflicts between RAMS elements to be controlled and managed effectively;

does not define

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

rules or processes pertaining to the certification of railway products against the

an approval process by the safety authority;

This part 1 of EN 50126 is applicable

to modifications of existing systems in operation prior to the creation of this standard,

for use by railway duty holders and the railway suppliers.

Quality management systems Requirements

Safety aspects Guidelines for their inclusion in standards

Terms and definitions

NOTE a legal act can be performed by an authorised entity (i.e. a NOBO)

NOTE Independence of assessment is only necessary where explicitly specified.

NOTE Independence of the assessor is only necessary where explicitly specified.