Documente Academic
Documente Profesional
Documente Cultură
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
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
19
20
Abbreviations ...............................................................................................................20
21
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
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
8.3.4 Specific verification tasks .........................................................................56
8.3.5 Specific validation tasks ...........................................................................56
Phase 3: risk analysis and evaluation...................................................................56
8.4.1 Objectives................................................................................................56
8.4.2 Activities ..................................................................................................57
8.4.3 Deliverables.............................................................................................58
8.4.4 Specific verification tasks .........................................................................58
8.4.5 Specific validation tasks ...........................................................................58
Phase 4: specification of system requirements .....................................................59
8.5.1 Objectives................................................................................................59
8.5.2 Activities ..................................................................................................59
8.5.3 Deliverables.............................................................................................60
8.5.4 Specific verification tasks .........................................................................60
8.5.5 Specific validation tasks ...........................................................................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
8.6.4 Specific verification tasks .........................................................................62
8.6.5 Specific validation tasks ...........................................................................62
Phase 6: design and implementation ....................................................................62
8.7.1 Objectives................................................................................................62
8.7.2 Activities ..................................................................................................62
8.7.3 Deliverables.............................................................................................63
8.7.4 Specific verification tasks .........................................................................63
8.7.5 Specific validation tasks ...........................................................................63
Phase 7: manufacture ..........................................................................................63
8.8.1 Objectives................................................................................................63
8.8.2 Activities ..................................................................................................64
8.8.3 Deliverables.............................................................................................64
8.8.4 Specific verification tasks .........................................................................64
8.8.5 Specific validation tasks ...........................................................................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
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
8.9.4 Specific verification tasks .........................................................................65
8.9.5 Specific validation tasks ...........................................................................65
Phase 9: system validation ..................................................................................65
8.10.1 Objectives................................................................................................65
8.10.2 Activities ..................................................................................................66
8.10.3 Deliverables.............................................................................................66
8.10.4 Specific verification tasks .........................................................................66
8.10.5 Specific validation tasks ...........................................................................66
Phase 10: system acceptance ..............................................................................67
8.11.1 Objectives................................................................................................67
8.11.2 Activities ..................................................................................................67
8.11.3 Deliverables.............................................................................................67
8.11.4 Specific verification tasks .........................................................................67
8.11.5 Specific validation tasks ...........................................................................67
Phase 11: operation, maintenance and performance monitoring............................67
8.12.1 Objectives................................................................................................67
8.12.2 Activities ..................................................................................................67
8.12.3 Deliverables.............................................................................................68
8.12.4 Specific verification tasks .........................................................................69
8.12.5 Specific validation tasks ...........................................................................69
Phase 12: decommissioning.................................................................................69
8.13.1 Objectives................................................................................................69
8.13.2 Activities ..................................................................................................69
8.13.3 Deliverables.............................................................................................69
8.13.4 Specific verification tasks .........................................................................69
8.13.5 Specific validation tasks ...........................................................................69
assessment ..........................................................................................................69
9.1
9.2
9.3
-5-
prEN 50126-1
154
155
156
157
158
159
160
161
162
B.1
B.2
B.3
B.4
B.5
Annex C
163
164
165
166
167
168
D.1
D.2
D.3
Annex E
169
170
171
List of figures
Figure 1 - Interrelation of RAMS-management process and system life-cycle .......................23
172
173
174
175
176
177
178
179
180
181
182
List of tables
Table 1 - System phase related tasks informative .............................................................46
183
184
185
186
187
188
189
190
191
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
prEN 50126-1
-6-
197
198
199
200
Table D.9 - Risk acceptance categories (example 1 for binary decisions) .............................97
201
202
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
210
211
212
20xx-xx-xx
213
214
20xx-xx-xx
215
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
220
221
222
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
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
prEN 50126-1
Scope
285
286
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
296
297
298
299
300
301
302
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
314
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
ISO/IEC
GUIDE 51
325
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.
364
365
366
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 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 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 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".
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
- 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 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.
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.
prEN 50126-1
828
829
- 20 -
Abbreviations
ALARP
COTS
E/E/PE
EMC
Electromagnetic compatibility
EMI
Electromagnetic Interference
FC
Fault Coverage
FMEA
FMECA
FRACAS
FTA
GAME
LAD
LCC
Life-cycle Cost
MDT
MEM
MTBF
MTBM
MUT
Mean Up Time
QMS
RA
Risk assessment
RAM
RAMS
RC
Repair Coverage
SIL
- 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
prEN 50126-1
- 22 -
874
5.5
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
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
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
905
906
prEN 50126-1
- 24 -
907
5.6
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
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
932
933
934
935
936
937
938
939
940
941
942
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
949
950
951
952
953
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
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
978
979
980
981
6.2
System-level approach
982
983
984
985
986
987
988
989
990
991
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
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
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
1065
1066
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
1077
1078
1079
1080
1081
1082
1083
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
1102
1103
1104
maintainers;
1105
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
1112
1113
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
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
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
1199
1200
1201
1202
1203
1204
1205
1206
all possible operation modes and required maintenance (taking into account cost
issues), over the system life-cycle;
1207
1208
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
1213
1214
All system failure modes that could lead to a hazard (safety-related failure modes);
1215
1216
1217
1218
1219
1220
1221
1222
- 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
1227
1228
e) system operation and maintenance of safety-related parts of the system in terms of:
1229
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
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
1252
1253
1254
1255
1256
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
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
1276
1277
1278
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
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
1307
1308
1309
1310
1311
b) operations conditions:
1312
environment;
1313
1314
1315
the constraints imposed by existing infrastructure and systems on the new system
under consideration
1316
- 33 1317
1318
prEN 50126-1
the limited opportunity for testing complete systems in the railway environment.
c) application conditions:
1319
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
1329
human factors;
1330
logistics;
1331
diagnostics;
1332
1333
1334
1335
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
1338
1339
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.
- 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
1373
1374
1375
1376
1377
human competence;
1378
1379
human interworking;
1380
1381
1382
railway culture;
1383
1384
1385
1386
human competence;
1387
1388
1389
operational safeguards;
1390
1391
1392
d) the requirements on the system arising from human information processing capabilities,
including:
1393
human/machine communications;
1394
1395
1396
1397
prEN 50126-1
- 36 -
1398
human training;
1399
1400
1401
1402
1403
the design and operation of the human/system interface; the provision of user
manuals etc.;
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
f)
1414
human competency;
1415
1416
1417
1418
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:
1437
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
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
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
Table D.1 - Frequency of occurrence of events with examples for quantification (time
based);
1466
1467
Table D.2 - Frequency of occurrence of events with examples for quantification (distance
based);
1468
1469
1470
1471
1472
1473
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
1484
1485
6.9
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
1507
1508
- 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
1522
1523
1524
1525
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
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
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
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
1564
1565
1566
1567
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
1576
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
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
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
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
1668
1669
a) assessment of the adequacy of the information, and where appropriate, data or other
statistics, used as input to risk assessment;
1670
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
1680
These validation tasks shall be documented with the following minimum content:
1681
1682
1683
1684
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
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
1695
- 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
10
System Acceptance
Specification of 4
System Requirements
System Validation
Design and
Implementation
Manufacture
1707
1708
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 -
1.
Concept
2.
System definition
and operational
context
3.
4.
Specification of
system
requirements
5.
Architecture and
apportionment of
systems
requirements
- 47 life-cycle phase
1726
1727
prEN 50126-1
Integration
- Assemble system
- Install system
System validation
- Commission
- Perform probationary period of operation
- Undertake training
10. System
acceptance
11. Operation,
maintenance and
performance
12. Decommissioning
6.
Design and
implementation
7.
Manufacture
8.
9.
Perform
Perform
Perform
Perform
Perform
NOTE 1 Change control or configuration management activity applies to all project phases
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
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
1751
1752
1753
1754
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
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
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
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
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
1798
1799
f)
1800
Produce a credible case for the adaptations adequately controlling the risks arising from
the differences;
1801
7.4
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
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.
- 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
1863
1864
physical issues;
1865
1866
social issues;
1867
political issues;
1868
legislative issues;
1869
economical issues.
1870
prEN 50126-1
1871
- 52 -
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
1890
1891
1892
8.3
1893
8.3.1
Objectives
1894
1895
1896
1897
1898
1899
1900
f)
1901
1902
1903
1904
8.3.2
Activities
8.3.2.1 The following issues shall be defined:
1905
1906
1907
1908
1909
1910
logistic considerations.
1911
- 53 -
prEN 50126-1
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
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
1940
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
1947
1948
1949
1950
1951
1952
1953
1954
cost of consumables;
1955
1956
1957
1958
1959
prEN 50126-1
- 54 -
1960
1961
1962
1963
b) reliability, including:
reliability analysis and prediction, including:
1964
1965
top down analysis, for example fault tree analysis and block diagram analysis;
1966
1967
1968
1969
reliability apportionment;
1970
1971
stress analysis.
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
- 55 2003
2004
2005
prEN 50126-1
d) availability, including:
2006
availability analysis;
2007
2008
2009
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
2017
2018
2019
2020
2021
a) the safety analysis, engineering and assessment processes to be applied during the lifecycle, including processes for:
2022
2023
2024
2025
2026
2027
2028
the establishment and on-going review of the adequacy of the safety requirements;
2029
system design;
2030
verification;
2031
2032
2033
achievement of compliance of the management process with the safety plan (e.g.
confirmed via audits);
2034
2035
2036
2037
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
prEN 50126-1
- 56 -
2049
2050
i)
2051
2052
j)
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
There are no specific verification requirements for this life-cycle phase in addition to those tasks
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
2078
8.4.1
Objectives
2079
2080
2081
2082
2083
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
2096
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.
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
2104
2105
2106
2107
e) system interfaces;
2108
f)
2109
2110
2111
i)
2112
j)
human factors;
2113
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
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
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
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
2164
2165
2166
2167
2168
8.4.3
Deliverables
8.4.3.1 The results of this phase shall be documented in an appropriate way, including:
2169
2170
2171
2172
2173
2174
2175
8.4.4
2176
2177
There are no specific verification requirements for this life-cycle phase in addition to those tasks
required in 7.2.14.
2178
2179
2180
8.4.5
Specific validation tasks
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
- 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
2187
8.5.1
Objectives
2188
2189
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
2200
2201
2202
2203
d) interfaces;
2204
2205
f)
2206
2207
2208
i)
2209
j)
2210
2211
2212
tolerable risk levels for the consequences arising from the identified hazards;
2213
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
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
2228
2229
2230
2231
2232
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)
2238
2239
2240
2241
2242
8.5.3
Deliverables
8.5.3.1 The results of this phase shall be documented in an appropriate way, including:
2243
2244
2245
2246
2247
2248
2249
8.5.4
2250
2251
There are no specific verification requirements for this life-cycle phase in addition to those tasks
required in 7.2.14.
2252
2253
2254
8.5.5
Specific validation tasks
8.5.5.1 The following validation tasks shall be undertaken within this phase in addition to those
tasks required in 7.2.8:
2255
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
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
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
8.6.3.1 The results of this phase shall be documented in an appropriate way, including:
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
2317
2318
2319
prEN 50126-1
2320
- 62 -
2321
2322
2323
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
There are no specific validation requirements for this life-cycle phase in addition to those tasks
required in 7.2.8.
2330
2331
2332
8.7
2333
8.7.1
Objectives
2334
2335
2336
2337
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
2346
2347
2348
2349
2350
2351
8.7.2.5 Training measures for operation and maintenance staff including training material shall
be defined.
2352
2353
2354
2355
2356
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
2362
- 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
2374
2375
8.7.3
Deliverables
8.7.3.1 The results of this phase shall be documented in an appropriate way, including:
2376
2377
2378
c) training measures;
2379
d) safety case(s);
2380
2381
f)
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
Specific verification tasks
8.7.4.1 The following verification tasks shall be undertaken within this phase in addition to those
tasks required in 7.2.14:
2388
2389
a) verification that
requirements;
sub-system
and
component
design
complies
with
the
RAMS
2390
2391
2392
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
There are no specific validation requirements for this life-cycle phase in addition to those tasks
required in 7.2.8.
2399
2400
2401
8.8
Phase 7: manufacture
2402
8.8.1
Objectives
2403
2404
2405
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
2409
2410
2411
2412
2413
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
2418
2419
2420
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
There are no specific verification requirements for this life-cycle phase in addition to those tasks
required in 7.2.14.
2427
8.8.5
2428
2429
There are no specific validation requirements for this life-cycle phase in addition to those tasks
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
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
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
2468
2469
2470
2471
2472
8.9.3
Deliverables
8.9.3.1 The results of this phase shall be documented in an appropriate way, including:
2473
a) installation documentation;
2474
2475
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
There are no specific validation requirements for this life-cycle phase in addition to those tasks
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:
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 -
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
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
8.10.3.1 The results of this phase shall be documented in an appropriate way, including:
2513
2514
2515
b) details of process, tools, equipment used for validation tasks against acceptance criteria;
2516
2517
2518
f)
2519
2520
2521
i)
2522
j)
2523
2524
This documentation shall include assumptions and justifications made during this phase.
2525
2526
2527
8.10.4
Specific verification tasks
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
There are no specific validation requirements for this life-cycle phase in addition to those tasks
required in 7.2.9.
2534
2535
- 67 2536
8.11
2537
8.11.1
Objectives
2538
prEN 50126-1
2539
2540
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):
2554
a) verification of the acceptance report with respect to the defined acceptance criteria;
2555
2556
2557
2558
8.11.3
Deliverables
8.11.3.1 The results of this phase shall be documented in an appropriate way, including:
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
2567
2568
2569
8.12
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
2583
2584
2585
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.
2591
2592
2593
2594
2595
2596
2597
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
2612
2613
2614
d) System design;
2615
2616
2617
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
8.12.3.1 The results of this phase shall be documented in an appropriate way, including:
2622
2623
b) records suitable to trace the RAMS tasks undertaken within this phase;
2624
- 69 2625
2626
2627
f)
prEN 50126-1
2628
This documentation shall include assumptions and justifications made during this phase.
2629
8.12.4
2630
2631
There are no specific verification requirements for this life-cycle phase in addition to those tasks
required in 7.2.14
2632
8.12.5
2633
2634
2635
2636
8.13
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
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.
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
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
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
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
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
2734
2735
2736
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
2755
2756
a single signal;
2757
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
2776
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
[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)
2824
Risk Matrix;
2825
2826
2827
2828
NOTE A calibrated Risk Matrix can be used to determine criteria for non-safety issues as well.
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
prEN 50126-1
- 74 -
2841
10
2842
10.1
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.
- 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
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
2921
2922
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
2927
2928
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
2944
specification of requirements;
2945
design control;
2946
2947
application engineering;
2948
2949
2950
2951
2952
2953
- 77 2954
2955
2956
2957
2958
2959
2960
2961
prEN 50126-1
2962
2963
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
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
3013
Independence of items;
3014
3015
Detection of single faults and action following detection (including retention of safe
state);
3016
3017
3018
10.3.5.3.4
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
3022
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
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
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
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
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
RAMS Tasks
PreAcquisition
Feasibility
Study
Contract
Negotiations
Order
Processing:
- Definition of
system
requirements
Order
Processing:
Design and
Implementati
on
RAMS reviews
Design/manufacturing FMEA
Manufacturin
g / Testing
Responsibility
Reference
Document
prEN 50126-1
- 82 -
Project-Phase
Commissioni
ng /
Acceptance
RAMS Tasks
-
Responsibility
Reference
Document
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
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
IEC 60706-1
IEC 60706-2
IEC 60706-3
IEC 60706-5
IEC 60706-6
IEC 60812
IEC 61025
IEC 61078
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
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
MIL-HDBK-764 (MI)
3102
3103
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
IEC 61508-2:2010
IEC 61508-3:2010
IEC 61508-4:2010
IEC 61508-5:2010
IEC 61508-6:2010
IEC 61508-7:2010
prEN 50126-1
3108
3109
3110
3111
3112
3113
3114
3115
- 84 -
IEC 60605-2
IEC 60605-3-1
IEC 60605-4
Part 4: Statistical procedures for exponential distribution Point estimates, confidence intervals, prediction intervals
and tolerance intervals
IEC 60605-6
IEC 61014
IEC 61070
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
- 85 -
prEN 50126-1
3116
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
Reliability parameters
Parameter
Symbol
Dimension
Failure Rate
(t)
Mean Up Time
MUT
MTTF
MTBF
MRT
time
Failure Probability
F(t)
dimensionless
R(t)
dimensionless
Mean operating
3)
Time To Failure
3124
B.2
Maintainability parameters
3125
Symbol
Dimension
MDT
MTBM
MTBM(c), MTBM(p)
MTTM
time
MTTM(c), MTTM(p)
time
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
prEN 50126-1
- 86 -
3130
B.3
Availability parameters
3131
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
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
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
MAD
MUT
mean up time
MLD
MDT
MTTR
MRT
MTBF
3155
Time to
check/test
the system
3156
3157
3158
3159
3160
3161
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
3166
Symbol
O&MC
money
Maintenance Cost
MC
money
MMH
time (hours)
LAD
time
time
Repair time
time
TAT
time
dimensionless
EFR
number
SPS
dimensionless
3167
B.5
3168
Safety parameters
Parameter
3169
Dimension
Symbol
Dimension
Hazard rate
h(t)
1/time, 1/distance,
1/cycle
p WSF
dimensionless
time
- 89 -
prEN 50126-1
3170
3171
3172
3173
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
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
H 1.1
H 1.2
H 1.3
H 1.4
H 1.5
H2
H 2.1
Unsound/unsecured structures/components/objects
H 2.2
H 2.3
H 2.4
H 2.5
H3
H 3.1
H 3.2
H 3.3
H 3.4
H 3.5
H4
H 4.1
Loss of balance
H 4.2
H 4.3
3256
Other 4)
Power 3)
ID
RoSto 2)
Sig 1)
3255
prEN 50126-1
prEN 50126-1
- 92 -
H5
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
H 5.6
H 5.7
H 5.8
H6
H 6.1
H 6.2
H 6.3
H 6.4
H7
H 7.1
H8
H 8.1
H 8.2
H9
H 9.1
H 9.2
H 10
H 10.1
H 11
Hazardous substances
H 11.1
5)
5)
6)
6)
6)
- 93 3257
prEN 50126-1
Example scenarios
Unsound/unsecured
structures/components/objects
Unsound/unsecured
structures/components/objects
Loss of balance
Inappropriate environment
prEN 50126-1
3258
- 94 -
Hazard
Example scenarios
Onset of fire
Intolerable electromagnetic
interference of other systems
Intolerable electromagnetic
interference from other systems
- 95 -
prEN 50126-1
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
Table D.1 - Frequency of occurrence of events with examples for quantification (time
based)
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
Probable
Occasional
about 2 to 15 times
Rare
Improbable
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
3276
3277
prEN 50126-1
3278
- 96 -
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
3284
3285
3286
3287
Table D.2 - Frequency of occurrence of events with examples for quantification (distance
based)
Frequency level
Description
F1
F2
F3
3288
3289
D.2
Severity levels
3290
The following tables give examples of severity levels, related to a particular use.
3291
Major
(service failure)
Minor
3292
Description
A failure that:
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:
- 97 3293
prEN 50126-1
Consequences on
service/property
Catastrophic
Critical
Loss of a major
system
Marginal
Severe system(s)
damage
Insignificant
Minor system
damage
3294
3295
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
S4
S5
3296
3297
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
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
3303
Actions to be applied
Unacceptable
Acceptable
prEN 50126-1
3304
- 98 -
Actions to be applied
Intolerable
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
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
- 99 -
prEN 50126-1
Annex E Bibliography
3307
3308
3309
EN 614
IEC 60300-3-1
IEC 60300-3-2
IEC 60319
IEC 60605-2
IEC 60605-3-1
IEC 60605-4
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
IEC 60706-2
IEC 60706-3
IEC 60706-5
IEC 60706-6
IEC 60812
IEC 61014
IEC 61025
IEC 61070
IEC 61078
IEC 61123
IEC 61160
Design review
IEC 61165
IEC 61508
IEC 61703
IEC 61709
IEC-TR-62380