50126

- 1 - prEN 50126-1

1

Project number: prEN 50126-1 2

3

4

5

6

Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS)

Part 1: Generic RAMS Process Applications ferroviaires – Spécification et démonstration de la fiabilité, de la disponibilité, de la maintenabilité et de la sécurité (FDMS)

Partie 1: Processus FMDS générique Bahnanwendungen - Spezifikation und Nachweis von Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit (RAMS)

Teil 1: Generischer RAMS Prozess

7

8

9

10

11

12

13

prEN 50126-1 - 2 -

Table of content 14

Foreword ..............................................................................................................................7 15

Introduction ..........................................................................................................................7 16

1 Scope ............................................................................................................................9 17

2 Normative references .....................................................................................................9 18

3 Terms and definitions ...................................................................................................10 19

4 Abbreviations ...............................................................................................................20 20

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

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

5.2 Objective .............................................................................................................21 23

5.3 Management responsibility...................................................................................21 24

5.4 Adaptability to project scope and size ..................................................................21 25

5.5 Interrelation of RAMS management process and life-cycle....................................22 26

5.6 Short description of life-cycle phases ...................................................................24 27

6 Railway RAMS..............................................................................................................25 28

6.1 Introduction .........................................................................................................25 29

6.2 System-level approach ........................................................................................25 30

6.2.1 Concepts of system hierarchy...................................................................25 31

6.2.2 A system’s requirements and characteristics.............................................26 32

6.2.3 Defining a system ....................................................................................27 33

6.3 Railway system overview .....................................................................................28 34

6.3.1 Introduction..............................................................................................28 35

6.3.2 Bodies/entities involved in a railway system..............................................28 36

6.3.3 Railway system environment and the balance of requirements ..................28 37

6.3.4 Railway system structure and apportionment of RAMS requirements .........29 38

6.4 Railway RAMS and quality of service ...................................................................29 39

6.5 Elements of railway RAMS...................................................................................29 40

6.6 Factors influencing railway RAMS ........................................................................31 41

6.6.1 General ...................................................................................................31 42

6.6.2 Classes of failures ...................................................................................31 43

6.6.3 Derivation of detailed railway specific influencing factors ..........................32 44

6.6.4 Evaluation of factors ................................................................................36 45

6.7 Specification of railway RAMS requirements.........................................................36 46

6.7.1 General ...................................................................................................36 47

6.7.2 RAMS specification ..................................................................................37 48

6.8 Risk based approach ...........................................................................................37 49

6.9 Risk reduction strategy .........................................................................................38 50

6.9.1 Introduction..............................................................................................38 51

6.9.2 Reduction of risks related to safety...........................................................38 52

6.10 Safety integrity ....................................................................................................39 53

6.10.1 Safety integrity concept ............................................................................39 54

7 Management of railway RAMS ......................................................................................40 55

7.1 RAMS process.....................................................................................................40 56

7.1.1 General ...................................................................................................40 57

7.1.2 Safety management within the RAMS Process ..........................................40 58

7.1.3 Independence of roles..............................................................................41 59

- 3 - prEN 50126-1

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

7.3 Application and tailoring of this standard ..............................................................49 61

7.4 General requirements on RAMS documentation....................................................50 62

8 RAMS life-cycle ............................................................................................................51 63

8.1 General ...............................................................................................................51 64

8.2 Phase 1: concept .................................................................................................51 65

8.2.1 Objectives................................................................................................51 66

8.2.2 Activities ..................................................................................................51 67

8.2.3 Deliverables.............................................................................................52 68

8.2.4 Specific verification tasks .........................................................................52 69

8.2.5 Specific validation tasks ...........................................................................52 70

8.3 Phase 2: system definition and operational context...............................................52 71

8.3.1 Objectives................................................................................................52 72

8.3.2 Activities ..................................................................................................52 73

8.3.3 Deliverables.............................................................................................56 74



8.4 Phase 3: risk analysis and evaluation...................................................................56 77

8.4.1 Objectives................................................................................................56 78

8.4.2 Activities ..................................................................................................57 79

8.4.3 Deliverables.............................................................................................58 80



8.5 Phase 4: specification of system requirements .....................................................59 83

8.5.1 Objectives................................................................................................59 84

8.5.2 Activities ..................................................................................................59 85

8.5.3 Deliverables.............................................................................................60 86



8.6 Phase 5: architecture and apportionment of system requirements .........................60 89

8.6.1 Objectives................................................................................................60 90

8.6.2 Activities ..................................................................................................61 91

8.6.3 Deliverables.............................................................................................61 92



8.7 Phase 6: design and implementation ....................................................................62 95

8.7.1 Objectives................................................................................................62 96

8.7.2 Activities ..................................................................................................62 97

8.7.3 Deliverables.............................................................................................63 98



8.8 Phase 7: manufacture ..........................................................................................63 101

8.8.1 Objectives................................................................................................63 102

8.8.2 Activities ..................................................................................................64 103

8.8.3 Deliverables.............................................................................................64 104



prEN 50126-1 - 4 -

8.9 Phase 8: integration.............................................................................................64 107

8.9.1 Objectives................................................................................................64 108

8.9.2 Activities ..................................................................................................64 109

8.9.3 Deliverables.............................................................................................65 110



8.10 Phase 9: system validation ..................................................................................65 113

8.10.1 Objectives................................................................................................65 114

8.10.2 Activities ..................................................................................................66 115

8.10.3 Deliverables.............................................................................................66 116



8.11 Phase 10: system acceptance..............................................................................67 119

8.11.1 Objectives................................................................................................67 120

8.11.2 Activities ..................................................................................................67 121

8.11.3 Deliverables.............................................................................................67 122



8.12 Phase 11: operation, maintenance and performance monitoring............................67 125

8.12.1 Objectives................................................................................................67 126

8.12.2 Activities ..................................................................................................67 127

8.12.3 Deliverables.............................................................................................68 128



8.13 Phase 12: decommissioning.................................................................................69 131

8.13.1 Objectives................................................................................................69 132

8.13.2 Activities ..................................................................................................69 133

8.13.3 Deliverables.............................................................................................69 134



9 Risk assessment ..........................................................................................................69 137

9.1 Scope..................................................................................................................69 138

9.2 Risk analysis methodology...................................................................................70 139

9.3 Risk evaluation and acceptance ...........................................................................73 140

9.3.1 Acceptance principles ..............................................................................73 141

9.3.2 Methods for determining risk acceptance criteria ......................................73 142

10 Deliverables and structure of a safety case ...................................................................74 143

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

10.2 Types of safety case............................................................................................74 145

10.3 Safety case structure ...........................................................................................74 146

10.3.1 General ...................................................................................................74 147

10.3.2 Definition of system .................................................................................76 148

10.3.3 Quality management report ......................................................................76 149

10.3.4 Safety management report .......................................................................77 150

10.3.5 Technical safety report .............................................................................77 151

10.3.6 Related safety cases................................................................................78 152

10.3.7 Conclusion...............................................................................................78 153

- 5 - prEN 50126-1

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

Annex A (informative) RAMS plan .......................................................................................80 155

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

B.1 Reliability parameters ..........................................................................................85 157

B.2 Maintainability parameters ...................................................................................85 158

B.3 Availability parameters.........................................................................................86 159

B.4 Logistic support parameters .................................................................................88 160

B.5 Safety parameters ...............................................................................................88 161

Annex C (informative) Hazards at railway system level – example structured list ..................89 162

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

Annex D (informative) Risk matrix calibration and risk acceptance categories ......................95 164

D.1 Frequency of occurrence levels............................................................................95 165

D.2 Severity levels .....................................................................................................96 166

D.3 Risk acceptance categories .................................................................................97 167

Annex E Bibliography..........................................................................................................99 168

169

List of figures 170

Figure 1 - Interrelation of RAMS-management process and system life-cycle .......................23 171

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

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

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

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

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

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

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

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

180

List of tables 181

Table 1 - System phase related tasks – informative .............................................................46 182

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

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

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

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

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

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

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

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

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

Table D.1 - Frequency of occurrence of events with examples for quantification (time 192 based) ................................................................................................................................95 193

Table D.4 - Frequency of occurrence of events with examples for quantification (distance 194 based) ................................................................................................................................96 195

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

prEN 50126-1 - 6 -

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

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

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

Table D.9 - Risk acceptance categories (example 1 for binary decisions) .............................97 200

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

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

203

- 7 - prEN 50126-1

Foreword 204

This European Standard was prepared by the Technical Committee CENELEC TC9X, electrical 205 and electronic applications in railways. 206

The text of the draft was submitted to the formal vote and was approved by CENELEC as 207 EN 50126 on 20xx-xx-xx. 208

The following dates were fixed: 209

a) latest date by which the EN has to be implemented 210 at national level by publication of an identical 211 national standard or by endorsement (dop) 20xx-xx-xx 212

b) latest date by which the national standards conflicting 213 with the EN have to be withdrawn (dow) 20xx-xx-xx 214

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

The EN 50126 standard includes under the general title "Railway application - The specification 216 and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)" the following 217 parts: 218

EN 50126-1: Generic RAMS process 219

EN 50126-2: Systems Approach to Safety 220

EN 50126-4: Functional Safety – Electrical/Electronic/Programmable Electronic systems 221

EN 50126-5: Functional Safety – Software 222

This EN 50126-1 covers the RAMS process. It is mainly based on EN 50126-1:1999 which is 223 withdrawn. 224

This European Standard has been prepared under a mandate given to CENELEC by the 225 European Commission and supports the Directive 2008/57/EC (see Annex ZZ). 226

Introduction 227

The standard EN 50126-1:1999 was produced to introduce the application of a systematic 228 RAMS management process in the railway sector. For safety-related electronic systems for 229 signalling the standards EN 50128 and EN 50129 were produced. Through the application of 230 these standards and the experiences gained over the last years, the need for revision and 231 restructuring became apparent with a need to deliver a systematic and coherent approach to 232 RAMS applicable to all the railway application fields Signalling, Rolling Stock and Electric power 233 supply for Railways (Fixed Installations). 234

The revision work improved the coherency and consistency of the standards, the concept of 235 safety management and the practical usage of the standard EN 50126 and took into 236 consideration the existing and related Technical Reports as well. 237

This European Standard provides railway duty holders and the railway suppliers, throughout the 238 European Union, with a process which will enable the implementation of a consistent approach 239 to the management of reliability, availability, maintainability and safety, denoted by the acronym 240 RAMS. 241

Processes for the specification and demonstration of RAMS requirements are cornerstones of 242 this standard. This European Standard promotes a common understanding and approach to the 243 management of RAMS. 244

EN 50126 is the railway sector specific application of IEC 61508. Meeting the requirements in 245 this European Standard is sufficient to ensure that additional compliance to IEC 61508 does not 246 need to be demonstrated. 247

With regard to safety EN 50126-1 provides a Safety Management Process which is supported by 248 guidance and methods described in EN 50126-2. 249

prEN 50126-1 - 8 -

EN 50126-1 and EN 50126-2 are independent from the technology used. EN 50126-4 and 250 EN 50126-5 provide guidance specific to safety-related E/E/PE technology of railway 251 applications. Their application is determined through the application of the general RAMS 252 process of EN 50126-1 and through the outcome of the safety-related methods described in 253 EN 50126-2. As far as safety is concerned, the EN 50126 standard takes the perspective of 254 functional safety. This does not exclude other aspects of safety. However, these are not the 255 focus. 256

The aims set for revision of the EN 50126 standard required a better understanding of the 257 systems approach and improved methods for applying the safety management process 258 described in EN 50126-1. EN 50126-2 provides this guidance. 259

The application of this standard should be adapted to the specific requirements of the system 260 under consideration. 261

This European Standard can be applied systematically by the railway duty holders and railway 262 suppliers, throughout all phases of the life-cycle of a railway application, to develop railway 263 specific RAMS requirements and to achieve compliance with these requirements. The systems-264 level approach developed by this European Standard facilitates assessment of the RAMS 265 interactions between elements of railway applications even if they are of complex nature. 266

This European Standard promotes co-operation between the stakeholders of Railways in the 267 achievement of an optimal combination of RAMS and cost for railway applications. Adoption of 268 this European Standard will support the principles of the European Single Market and facilitate 269 European railway inter-operability. 270

The process defined by this European Standard assumes that railway duty holders and railway 271 suppliers have business-level policies addressing Quality, Performance and Safety. The 272 approach defined in this standard is consistent with the application of quality management 273 requirements contained within the ISO 9001. 274

In accordance with CENELEC1), mandatory requirements in this standard are indicated with the 275 modal verb “shall”. Where justifiable, the standard permits process tailoring. Specific guidance 276 on the application of this standard in the case of process tailoring is provided in clause 7.3 of 277 EN 50126-1. EN 50126-2 provides various methods for use in the safety management process. 278 Where a particular method is selected for the system under consideration, the mandatory 279 requirements of this method are by consequence mandatory for the safety management of the 280 system under consideration. 281

282

—————————

1) CENELEC “Internal Regulations Part 3: Rules for the structure and drafting of CEN/CENELEC Publications (2009-

08), Annex H

- 9 - prEN 50126-1

1 Scope 283

This part 1 of EN 50126 284

considers RAMS, understood as reliability, availability, maintainability and safety and 285 their interaction; 286

considers the generic aspects of the RAMS life-cycle. The guidance in this part is still 287 applicable in the application of specific standards; 288

defines 289

a process, based on the system life-cycle and tasks within it, for managing RAMS; 290

a systematic process, tailorable to the type and size of system under consideration, 291 for specifying requirements for RAMS and demonstrating that these requirements are 292 achieved; 293

addresses railway specifics; 294

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

does not define 296

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

rules or processes pertaining to the certification of railway products against the 298 requirements of this standard; 299

an approval process by the safety authority; 300

does not specify requirements for ensuring system security. 301

This part 1 of EN 50126 is applicable 302

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

to new systems; 307

to new systems integrated into existing systems in operation prior to the creation of 308 this standard, although it is not generally applicable to other aspects of the existing 309 system; 310

to modifications of existing systems in operation prior to the creation of this standard, 311 although it is not generally applicable to other aspects of the existing system; 312

at all relevant phases of the life-cycle of an application; 313

for use by railway duty holders and the railway suppliers. 314

It is not required to apply this standard to existing systems including those systems already 315 compliant with any version of former EN 50126, EN 50128 or EN 50129, which remain 316 unmodified. Railway applications mean Command, Control & Signalling, Rolling Stock and 317 Electric Power Supply for Railways (Fixed Installations). 318

In this standard the term hardware refers to E/E/PE components or systems. If non E/E/PE 319 hardware is meant, this is specifically mentioned. 320

2 Normative references 321

The following referenced documents are indispensable for the application of this document. For 322 dated references, only the edition cited applies. For undated references, the latest edition of the 323 referenced document (including any amendments) applies. 324

prEN 50126-1 - 10 -

ISO 9001 Quality management systems – Requirements

ISO/IEC GUIDE 51

Safety aspects – Guidelines for their inclusion in standards

3 Terms and definitions 325

For the purposes of this standard, the following terms & definitions apply. 326

3.1 327 acceptance 328 the status achieved by a product, system or process once it has been agreed that it is suitable 329 for its intended purpose 330

3.2 331 accident 332 an unintended event or series of events resulting in loss of human health or life, damage to 333 property or environmental damage 334

NOTE The term includes losses from accidents arising within a short time scale (e.g. collision, explosion) and also 335 those incurred over the long-term (e.g. release of a toxic substance). 336

3.3 337 application conditions 338 those conditions which need to be met in order for a system to be safely integrated and safely 339 operated. 340

NOTE: application conditions can for example be: operational restrictions (e.g. speed limit, maximum duration of use) 341 operational rules, maintenance restrictions (e.g. requested maintenance intervals) or environmental conditions. 342

3.4 343 approval 344 the legal act, often focused on safety, to allow a product, system or process to be placed into 345 service 346

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

3.5 348 assessment 349 process to form a judgement on whether a product, system or process meets the specified 350 requirements, based on evidence 351

NOTE Independence of assessment is only necessary where explicitly specified. 352

3.6 353 assessor 354 an entity that carries out an assessment 355

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

3.7 357 assurance 358 confidence in achieving a goal being pursued. Declaration intended to give confidence 359

3.8 360 audit 361 a documented, systematic and independent examination to determine whether the procedures 362 specific to the requirements 363

comply with the planned arrangements, 364

are implemented effectively and 365

are suitable to achieve the specified objectives 366

3.9 367 availability 368 the ability of a product to be in a state to perform a required function under given conditions at a 369 given instant of time or over a given time interval assuming that the required external resources 370 are provided 371

- 11 - prEN 50126-1

NOTE Figure B.1 (Annex B) illustrates the concept of availability and clarifies the correct use of contributory terms. 372

3.10 373 collective risk 374 a risk, resulting from e.g. a product, process or system, to which a population or group of people 375 is exposed 376

NOTE 1 Collective risk is not to be confused with multiple victim accidents. 377

NOTE 2 Collective risk is the sum of the individual risks to those individuals in the population or group. However, the 378 collective risk divided by the number of individuals will only provide the average individual risk. 379

NOTE 3 A group of people could be, for example, rail staff working in a restaurant car or all passengers using a 380 particular network. 381

3.11 382 commercial off-the-shelf software 383 software defined by market-driven need, commercially available and whose fitness for purpose 384 has been deemed acceptable by a broad spectrum of commercial users 385

3.12 386 common cause failure 387 failures of different items resulting from the same cause and where these failures are not 388 consequences of each other 389

3.13 390 compliance 391 a state where a characteristic or property of a product, system or process satisfies the specified 392 requirements 393

3.14 394 configuration management 395 a discipline applying technical and administrative direction and surveillance to identify and 396 document the functional and physical characteristics of a configuration item, to control changes 397 to those characteristics, to record and report change processing and implementation status and 398 to verify compliance with specified requirements 399

3.15 400 consequence analysis 401 to analyze the consequences of each hazard up to accidents and losses 402

3.16 403 corrective maintenance 404 the maintenance carried out after fault recognition and intended to put a product into a state in 405 which it can perform a required function 406

3.17 407 data-driven software 408 software configured by data and/or algorithms for producing the executable software for an 409 application by making use of an existing generic software 410

3.18 411 designer 412 an entity that analyses and transforms specified requirements into acceptable design solutions 413 which have the required safety integrity 414

3.19 415 deterministic 416 expresses that a behaviour can be predicted with certainty 417

NOTE A deterministic event in a system can be predicted with certainty from preceding events which are either known 418 or are the same as for a proven equivalent system. 419

3.20 420 diversity 421 a means of achieving all or part of the specified requirements in more than one independent and 422 dissimilar manner 423

NOTE Diversity may be achieved by different physical methods or different design approaches. 424

prEN 50126-1 - 12 -

3.21 425 entity 426 a person, group or organisation who fulfil a role as defined in this standard 427

3.22 428 equivalent fatality 429 an expression of fatalities and weighted injuries and a convention for combining injuries and 430 fatalities into one figure for ease of evaluation and comparison of risks 431

3.23 432 error 433 a discrepancy between a computed, observed or measured value or condition and the true, 434 specified or theoretically correct value or condition 435

NOTE 1 An error can be caused by a faulty item, e.g. a computing error made by faulty computer equipment. 436

NOTE 2 A human error can be seen as a human action or inaction that can produce an unintended result. 437

3.24 438 fail-safe 439 a concept which is incorporated into the design of a product such that, in the event of a failure, it 440 enters or remains in a safe state 441

3.25 442 failure 443 the termination of the ability of an item to perform a required function 444

NOTE 1 After failure the item has a fault. 445

NOTE 2 "Failure" is an event, as distinguished from "fault", which is a state. 446

3.26 447 failure mode 448 a predicted or observed manner in which the product, system or process under consideration 449 can fail 450

3.27 451 failure rate 452 the limit, if this exists, of the ratio of the conditional probability that the instant of time, T, of a 453 failure of a product falls within a given time interval (t, t+∆t) and the length of this interval, ∆t, 454 when ∆t tends towards zero, given that the item is in an up state at the start of the time interval 455

NOTE Failure rates are often assumed as constant. This is not always valid, e.g. for components subject to wear out 456 (mechanical, pneumatic, electromechanical, etc.). 457

3.28 458 fault 459 the state of an item characterized by inability to perform a required function, excluding the 460 inability during preventive maintenance or other planned actions 461

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 462 design fault). 463

3.29 464 fault detection time 465 time span which begins at the instant when a failure occurs and ends when the existence of the 466 fault is detected 467

3.30 468 fault tolerance 469 ability of a functional unit to continue to perform a required function in the presence of faults or 470 errors 471

3.31 472 firmware 473 an ordered set of instructions and associated data stored in a way that is functionally 474 independent of main storage 475

- 13 - prEN 50126-1

3.32 476 function 477 a specified action or activity which may be performed by technical means and/or human beings 478 and has a defined output in response to a defined input 479

NOTE A function can be specified or described without reference to the physical means of achieving it. 480

3.33 481 functional safety 482 the perspective of safety focused on the functions of a system 483

NOTE 1 Functional safety does not only consider normal operation. 484

NOTE 2 Functional safety can be based on safety functions as well as on safety-related functions. 485

3.34 486 generic product 487 product (hardware and/or software) which can be used for a variety of installations, either 488 without making any changes or purely trough the configuration of the hardware or the software 489 (for example by the provision of application-specific data and/or algorithms) 490

3.35 491 hazard 492 a condition that could lead to an accident 493

3.36 494 hazard analysis 495 an analysis comprising hazard identification, causal analysis and common cause analysis 496

3.37 497 hazard log 498 the document in which hazards identified, decisions made, solutions adopted and their 499 implementation status are recorded or referenced 500

NOTE 1 The Hazard Log compiles evidence on the implementation of safety requirements regarding all identified hazards, thus 501 supporting the demonstration of completeness of the safety assurance activities 502

NOTE 2 A "hazard record" is an extract of the hazard log that is suitable for transferring between stakeholders. 503

3.38 504 hazard rate 505 the rate of occurrence of a hazard 506

NOTE For detailed mathematical understanding of "rate" refer to the definition of "failure rate". 507

3.39 508 implementation 509 the activity applied in order to transform the specified designs into their realisation 510

3.40 511 implementer 512 the entity that carries out implementation 513

3.41 514 independence (functional) 515 freedom from any mechanism which can affect the correct operation of more than one function 516 as a result of either systematic or random failure 517

3.42 518 independence (physical) 519 freedom from any mechanism which can affect the correct operation of more than one 520 system/subsystem/ equipment as a result of random failures 521

3.43 522 individual risk 523 a risk, resulting from e.g. a product, process or system, to which an individual person is exposed 524

NOTE 1 Individual risk is not to be confused with single victim accidents. 525

NOTE 2 Collective risk is the sum of the individual risks to those individuals in the population or group. However, the 526 collective risk divided by the number of individuals will only provide the average individual risk. 527

prEN 50126-1 - 14 -

3.44 528 infrastructure manager 529 any body or undertaking that is responsible in particular for establishing and maintaining railway 530 infrastructure, or a part thereof, which may also include the management of infrastructure 531 control and safety systems. The functions of the infrastructure manager on a network or part of 532 a network may be allocated to different bodies or undertakings 533

3.45 534 integration 535 the process of assembling the elements of a system according to the architectural and design 536 specification, and the testing of the integrated unit 537

3.46 538 integrator 539 an entity that carries out system integration 540

3.47 541 latent fault 542 an existing fault that has not yet been detected 543

3.48 544 life-cycle 545 those activities occurring during a period of time that starts when the product, system or process 546 is conceived and ends when the product, system or process is no longer available for use 547

3.49 548 logistic support 549 the overall resources which are arranged and organised in order to operate and maintain the 550 system at the specified availability level at the required life-cycle cost 551

3.50 552 loss analysis 553 systematic use of all available information to identify losses associated with accidents (or their 554 RAM equivalent) and estimate their severities 555

3.51 556 maintainability 557 the ability of an item under given conditions of use, to be retained in, or restored to, a state in 558 which it can perform a required function, when maintenance is performed under given conditions 559 and using stated procedures and resources 560

NOTE The maintainability is also used as a measure of maintainability performance. 561

3.52 562 maintenance 563 the combination of all technical and administrative actions, including supervision actions, 564 intended to retain a product in, or restore it to, a state in which it can perform a required function 565

3.53 566 mission 567 an objective description of the fundamental task performed by a system 568

3.54 569 mission profile 570 outline of the expected range and variation in the mission with respect to parameters such as 571 time, loading, speed, distance, stops, tunnels, etc., in the operational phases of the life-cycle 572

3.55 573 negation 574 enforcement of a safe state following detection of a hazardous fault 575

3.56 576 negation time 577 time span which begins when the existence of a fault is detected and ends when a safe state is 578 enforced 579

- 15 - prEN 50126-1

3.57 580 pre-existing software 581 all software developed prior to the application currently in question is classed as pre-existing 582 software including commercial off-the-shelf software, open-source software and software 583 previously developed but not in accordance with this European Standard 584

3.58 585 preventive maintenance 586 the maintenance carried out at pre-determined intervals or according to prescribed criteria and 587 intended to reduce the probability of failure or the degradation of the functioning of an item 588

3.59 589 procedural safety 590 aspects of the safety life-cycle which are governed by procedures and instructions (e.g. 591 operational and maintenance procedures) 592

3.60 593 project management 594 the administrative and/or technical conduct of a project, including RAMS aspects 595

3.61 596 project manager 597 an entity that carries out project management 598

3.62 599 railway duty holder 600 the body with the overall accountability for operating a railway system within the legal framework 601

NOTE 1 Railway duty holder accountabilities for the overall system or its parts and life-cycle activities are sometimes 602 split between one or more bodies or entities. For example: 603

− the owner(s) of one or more parts of the system assets and their purchasing agents; 604

− the operator of the system; 605

− the maintainer(s) of one or more parts of the system; 606

NOTE 2 Typically the railway duty holders are railway undertakings and the infrastructure managers. 607 Such splits are based on either statutory instruments or contractual agreements. Such responsibilities should 608 therefore be clearly stated at the earliest stages of a system life-cycle. 609

3.63 610 railway undertaking 611 means any public or private undertaking, whose activity is to provide transport of goods and/or 612 passengers by rail on the basis that the undertaking must ensure traction; this also includes 613 undertakings which provide traction only 614

3.64 615 RAM plan 616 a documented set of time scheduled activities, resources and events serving to implement the 617 organisational structure, responsibilities, procedures, activities, capabilities and resources that 618 together ensure that an item will satisfy given RAM requirements relevant to a given contract or 619 project 620

3.65 621 RAMS management process 622 the activities and procedures that are followed to enable the RAMS requirements of a product or 623 an operation to be identified and met. It provides a systematic and systemic approach to 624 continually manage RAMS through the whole life-cycle 625

NOTE This Process should be embedded in a management system at the organisational level 626

3.66 627 redundancy 628 the provision of more than one means for accomplishing a given function to improve reliability, 629 availability and/or safety performance 630

NOTE Each means of accomplishing the function need not necessarily be identical 631

prEN 50126-1 - 16 -

3.67 632 reliability 633 the ability of an item to perform a required function under given conditions for a given time 634 interval 635

NOTE The term "reliability" is also used as a measure of reliability performance and may also be defined as a 636 probability 637

3.68 638 reliability growth 639 a condition characterised by a progressive improvement of a reliability performance measure of 640 an item with time 641

3.69 642 repair 643 measures for re-establishing the required state of a system/sub-system/equipment after a 644 fault/failure 645

3.70 646 requirements manager 647 an entity that is responsible for managing the specification or capture and recording of the 648 requirements 649

3.71 650 residual risk 651 risk remaining once risk control measures have been taken 652

3.72 653 restoration 654 bring an item into a state where it regains the ability to perform its required function after a fault 655

3.73 656 risk 657 the combination of expected frequency of loss and the expected degree of severity of that loss 658

3.74 659 risk analysis 660 systematic use of all available information to identify hazards and to estimate the risk 661

3.75 662 risk assessment 663 the overall process comprising system definition, risk analysis and a risk evaluation 664

NOTE Risk assessment does not necessarily require independent assessment. 665

3.76 666 risk based approach 667 in relation to safety, the risk based approach is a process for ensuring the safety of products, 668 processes and systems through consideration of the hazards and their consequent risks 669

NOTE The approach is applicable to RAM aspects in an analogous manner. 670

3.77 671 risk evaluation 672 procedure based on the Risk Analysis results to determine whether the tolerable risk has been 673 achieved 674

3.78 675 risk management 676 systematic application of management policies, procedures and practices to the tasks of 677 analysing, evaluating and controlling risk 678

3.79 679 safety 680 freedom from unacceptable risk to human health or to the environment 681

- 17 - prEN 50126-1

3.80 682 safety authority 683 the body entrusted with the regulatory tasks regarding railway safety in accordance with the 684 respective legal framework 685

3.81 686 safety barrier 687 any physical or non-physical means, which reduces the frequency of a hazard and/or a likely 688 accident arising from the hazard and/or mitigates the severity of likely accidents arising from the 689 hazard 690

NOTE This term can be applied to RAM aspects in a similar manner. 691

3.82 692 safety case 693 the documented demonstration that the product, system or process complies with the 694 appropriate safety requirements 695

NOTE The safety case is not necessarily the subject of approval. 696

3.83 697 safety function 698 a function whose sole purpose is to ensure safety 699

NOTE 1 A safety-related function is a function whose failure affects safety (for details refer to definition of "safety-700 related"). Therefore, all safety functions are safety-related functions, but not vice versa. 701

Note 2 A safety function may contribute to one or more safety barriers. However, a safety barrier is not necessarily 702 implemented by a safety function. 703

3.84 704 safety integrity 705 ability of a safety-related function to satisfactorily perform under all the stated conditions within 706 a stated operational environment and a stated period of time 707

NOTE Safety integrity can be a property associated with technical and non-technical functions as well as other 708 aspects (e.g. operational or architectural aspects). 709

3.85 710 safety integrity level 711 one of a number of defined discrete levels for specifying the safety integrity requirements of 712 safety-related functions to be allocated to the safety-related systems 713

NOTE 1 Safety Integrity Level with the highest figure has the highest level of safety integrity. 714

NOTE 2 It is not possible to allocate a Safety Integrity Level to safety-related processes or other measures. 715

3.86 716 safety management 717 the management structure which ensures that the safety process is properly implemented 718

3.87 719 safety management process 720 that part of the RAMS management process which deals specifically with safety aspects 721

3.88 722 safety plan 723 a documented set of time scheduled activities, resources and events serving to implement the 724 organisational structure, responsibilities, procedures, activities, capabilities and resources that 725 together ensure that an item will satisfy given safety requirements relevant to a given contract or 726 project 727

3.89 728 safety-related 729 function, component, product, system or procedure in its intended use is safety-related, if in the 730 event of degradation or failure, directly or in combination with other reasonably foreseeable 731 failures or errors, a non-negligible increase of risk to human health or to the environment has 732 been rationally identified by appropriate expert judgement 733

NOTE The term provides no further indication of the importance to safety. 734

prEN 50126-1 - 18 -

3.90 735 software 736 an intellectual creation comprising the programs, procedures, rules, data and any associated 737 documentation pertaining to the operation of a system 738

3.91 739 software baseline 740 a complete and consistent set of source code, executable files, configuration files, installation 741 scripts and documentation that are needed for a software release. Information about compilers, 742 operating systems, pre-existing software and dependent tools is stored as part of the baseline 743

NOTE The software baseline will enable the organisation to reproduce defined versions and be the input for future 744 releases at enhancements or at upgrade in the maintenance phase 745

3.92 746 software deployment 747 transferring, installing and activating a deliverable software 748

3.93 749 software maintainability 750 the capability of the software to be modified 751

NOTE software modification may be necessary to correct faults, improve performance or other attributes, or adapt it 752 to a different environment 753

3.94 754 software maintenance 755 an action, or set of actions, carried out on software after deployment with the aim of enhancing 756 or correcting its functionality 757

3.95 758 stress profile 759 the degree, duration and number of external influences which a product can withstand whilst 760 performing its required functionality 761

3.96 762 system 763 set of elements which interact according to a design, where an element of a system can be 764 another system, called a subsystem and may include hardware, software and human interaction 765

3.97 766 system life-cycle 767 the activities occurring during a period of time that starts when a system is conceived and end 768 when the system is no longer available for use, is decommissioned and is disposed 769

3.98 770 systematic failure 771 a failure due to errors, which cause the product, system or process to fail deterministically under 772 a particular combination of inputs or under particular environmental or application conditions 773

NOTE 1 Corrective maintenance without modification will usually not eliminate the failure’s cause. 774

NOTE 2 A systematic failure can be induced by simulating the conditions which cause it to occur. 775

NOTE 3 Examples of causes of systematic failures include human error in 776

– the safety requirements specification 777

– the design, manufacture, installation, operation of the hardware 778

– the design, implementation, etc. of the software. 779

NOTE 4 Failures are categorised as random failures or systematic failures. 780

3.99 781 T1 782 tool class which generates no outputs which can directly or indirectly contribute to the system or 783 the hardware 784

NOTE T1 examples include: a text editor or a requirements or design support tool with no automatic code generation 785 capabilities; configuration control tools. 786

- 19 - prEN 50126-1

3.100 787 T2 788 tool class which supports the test or verification of the design or the hardware, where errors in 789 the tool can fail to reveal defects but cannot directly create errors in the system or the hardware 790

NOTE T2 examples include: a test harness generator; a test coverage measurement tool; a static analysis tool. 791

3.101 792 T3 793 tool class which generates outputs which can directly or indirectly contribute to the system or 794 the hardware 795

NOTE T3 examples include: a tool for hardware layout; a compiler that incorporates an executable run-time package 796 into the executable code. 797

3.102 798 technical safety 799 that part of safety that is dependent upon the characteristics of a product, which derive from the 800 system functional requirements and/or of the system design 801

3.103 802 tester 803 an entity that carries out testing 804

3.104 805 testing 806 the process of operating a product, system or process under specified conditions as to ascertain 807 its behaviour and performance compared to the corresponding requirements specification 808

3.105 809 traceability 810 relationship established between two or more entities in a development process, especially 811 those having a predecessor/successor or master/subordinate relationship to one another 812

3.106 813 validation 814 confirmation by examination and provision of objective evidence that the product, system or 815 process is suitable for a specific intended use 816

NOTE 1 Verification is a prerequisite for validation. 817

3.107 818 validator 819 an entity that is responsible for the validation 820

3.108 821 verification 822 confirmation by examination and provision of objective evidence that the specified requirements 823 have been fulfilled 824

3.109 825 verifier 826 an entity that is responsible for one or more verification activities 827

prEN 50126-1 - 20 -

4 Abbreviations 828

ALARP As low as reasonably practicable

COTS Commercial of the shelf

E/E/PE Electrical/electronic/programmable electronic systems

EMC Electromagnetic compatibility

EMI Electromagnetic Interference

FC Fault Coverage

FMEA Failure Mode and Effects Analysis

FMECA Failure Mode, Effects and Criticality Analysis

FRACAS Failure Reporting Analysis and Corrective Action System

FTA Fault Tree Analysis

GAME Globalement Au Moins Equivalent

LAD Logistic and Administrative Delay

LCC Life-cycle Cost

MDT Mean Down Time

MEM Minimum Endogenous Mortality

MTBF Mean Time Between Failure

MTBM Mean Time Between Maintenance

MUT Mean Up Time

QMS Quality Management System

RA Risk assessment

RAM Reliability, availability and maintainability

RAMS Reliability, availability, maintainability and safety

RC Repair Coverage

SIL Safety integrity level

829

- 21 - prEN 50126-1

5 Process overview 830

5.1 Purpose of overview 831

This section is introducing the basic ideas applied in this suite of standards. It should support a 832 newcomer to the subject of risk management as well as making an expert aware of the changes 833 / adaptations in the new merged version of the former EN 50126, EN 50128 and EN 50129. 834 More detailed information and all requirements are given in following and referenced clauses. 835 Therefore no requirements are given in this overview. 836

5.2 Objective 837

The objective of the RAMS process described in this standard is to ensure that all aspects of 838 RAMS are covered in order to provide the safety and quality of railway applications at affordable 839 cost for the users of the railway (see 6.3.3.1). To achieve safety and quality they have to be 840 considered right at the beginning of a project and continuously throughout the complete 841 development and operation. In this manner, safe performance and reliable quality can be 842 incorporated into a system/subsystem instead of adding on corrective systems in later stages. 843

The RAMS process is the core of this standard and this overview briefly introduces the general 844 concept. Details of RAMS are then elaborated in chapter 6. 845

5.3 Management responsibility 846

This objective can only be achieved if the management of all stakeholders live up to their 847 organisational responsibility. The requirements of this standard can only be fulfilled if the 848 management in charge embodies organisational structures and rules that enable their staff to 849 comply with the more detailed requirements and ensures that they are being followed. Therefore 850 this standard requires management commitment and action. 851

5.4 Adaptability to project scope and size 852

The described process is applicable to new technologies, new systems as well as modifications 853 of systems. 854

With regard to Safety, the process described is applicable not only to technical but operational 855 and organisational matters as well. For example, safety-related aspects of operational rules to 856 be produced or changed, as well as modifications of safety-related organisations are covered by 857 this process. Activities and processes concerning structures and rules dealing with safety 858 aspects are expected to be stricter than those dealing with RAM only. 859

No matter how small the intended change might be, its impact on the RAMS of neighbouring 860 systems via interfaces and the resulting impact on RAMS of the railway system operation need 861 to be investigated. The system definition determines the outline of assessment with the 862 description of boundaries and interfaces and since the process itself is scalable to system, 863 subsystem or product level, the extent and depth of the analysis can be adjusted to an 864 appropriate level for the task at hand. 865

During the risk analysis the possible hazards resulting out of the change are to be identified 866 (interfaces included), evaluated and the resulting requirements to be defined and possibly 867 apportioned. After that only the affected phases of the process have to be reconsidered. 868 If the change does not create additional risk (e.g. by creating a new hazard, making an existing 869 hazard more likely or changing the consequences of a hazard) the reasoning is be documented. 870

All these aspects, regarding the different size, complexity and novelty of the system under 871 consideration, imply the need to tailor the process described in this standard. For more details 872 on tailoring please refer to 7.3. 873

prEN 50126-1 - 22 -

5.5 Interrelation of RAMS management process and life-cycle 874

After a concept for a product has been set up, the general process consists of 3 major blocks: 875 Risk assessment (on the basis of the system definition including the specification of system 876 requirements), Demonstration of compliance with requirements and Operation and 877 Decommissioning. Apart from the regular process flow throughout the life-cycle phases those 878 blocks are connected 879

1. via a feedback loop, should new or additional knowledge about risk come up during 880 the detailing phases of the project that demands the risk to be reassessed and 881 resulting this some phases have to be readdressed; 882

2. via subsequent loops (on the left side of Figure 1) after reassessment that allow 883 skipping some phases of the regular process flow if the reconsidered RAMS 884 requirements are not affected in those phases, or, in worst case, demand rephrasing 885 the remit of the project (concept phase) if the safety requirements cannot be met in 886 any way. 887

A direct consequence of this is that the logical flow of knowledge and decision is more important 888 than the time based flow of the phases. Therefore, formally the risk analysis is never completely 889 finished before the end of the life-cycle. In this general EN 50126-1 the activities connected with 890 the phases are not allocated to roles. That is to be performed by (project-) management or 891 might be described in standards dealing with specific technologies as provided in EN 50126-4 892 and EN 50126-5 for E/E/PE systems. Each of the 3 blocks consists of several life-cycle phases 893 described in the respective chapters and shown in Figure 1. 894

It is important to note, that this life-cycle and its phases can be applied for “systems” on various 895 levels, varying from the railway system level up to e.g. a switch point function. Therefore, Figure 896 1 is to be applied in an analogous way. 897

The process may be simplified by reusing existing applicable material. An example of such 898 material which can be reused in this way is the Technical Specification CLC/TS 50562:2011, 899 “Railway applications - Fixed installations - Process, measures and demonstration of safety for 900 electric traction systems”. 901

Note that this life-cycle is applicable for each system under consideration independent of its 902 level within the complete railway system. In this iterative approach each considered system level 903 can be integrated into the superior system up to the top level of the complete railway system. 904

- 23 - prEN 50126-1

Op

era

tio

n a

nd

D

ec

om

mis

ss

ion

ing

Ris

k

As

sess

me

nt

Imp

lem

en

tati

on

an

d

De

mo

ns

tra

tio

n o

f C

om

plia

nc

e w

ith

R

eq

uir

em

en

ts

System Validation 9

Operation, Maintenance and

Performance Monitoring

11

Integration8

System Acceptance10

Fe

edb

ack

of s

ubse

que

nt h

aza

rd id

ent

ifica

tion

into

ris

k a

naly

sis

Op

era

tio

n a

nd

D

ec

om

mis

sio

nin

g

Decommissioning12

Key:

Correlated process steps in

European legal frameworkDoC

RA

O&D

Design and Implementation

6

Manufacture 7

Co

nsid

era

tion

of s

ubse

que

nt R

AM

S R

equ

ire

me

nts

in p

rodu

ct d

eve

lopm

ent

Concept 1

System Definition and Operational Context

2

Architecture & Apportionment

of System Requirements

5

*)

*)

*) may contain many subsystems and components

Specification of System Requirements

4

Risk Analysis and Evaluation

3

905

Figure 1 - Interrelation of RAMS-management process and system life-cycle 906

prEN 50126-1 - 24 -

5.6 Short description of life-cycle phases 907

The following text briefly introduces the life-cycle phases shown in Figure 1 that will be detailed 908 with their requirements in chapter 8 RAMS life-cycle: 909

1. Concept: remit of the project should be drawn up (details see 8.2); 910

2. System definition and operational context: the system that is to be developed should 911 be described in its essential characteristics and functions. Furthermore, the interfaces 912 to other systems need to be clarified. That includes the input to be provided and the 913 output that can be expected. On this basis the impact on RAMS-parameters of 914 neighbouring systems can be derived. The intended operational conditions 915 (maintenance, environment, etc.) that could impair the safe or good (RAM) function 916 are to be stated to ensure that the operator is aware of them. The RAMS 917 management is to be established, including RAM plan and Safety plan (details see 918 8.3); 919

3. Risk analysis and evaluation: several steps (identify hazards associated with the 920 system, identify events leading to hazards, determine risk associated with hazards, 921 establish process for on-going risk management) should be followed to decide if a 922 risk is tolerable. Risk analysis is an ongoing and iterative step and may continue in 923 parallel with subsequent phases. It may be necessary to define further safety system 924 requirements induced by the risk acceptance criteria in order to reduce the risk to an 925 acceptable level. System requirements can be derived / exist at different levels 926 (details see 8.4); 927

4. Specification of system requirements: detailing the initial system requirements 928 (expected functions incl. their RAMS requirements) and the ones derived from risk 929 assessment in phase 3 as well as defining criteria for acceptance and specifying the 930 overall demonstration of compliance (details see 8.5); 931

5. Architecture and apportionment of system requirements: allocation of requirements 932 (including all safety requirements) to subsystems (this phase might be a part of 933 demonstration of compliance) (details see 8.6); 934 NOTE 1 At each subordinated system level it is to be decided which phases need to be repeated. 935 Principally this relates to all life-cycle phases. Each subsystem should be assessed in the same manner 936 at their level of detail and within the boundary of their specific sub-system definition (iterative method). 937

NOTE 2 Should information about hazards and associated risks in later phases convey additional 938 hazards or a higher risk than assumed in the beginning the prolonging validity of the initial risk 939 assessment should be shown again or an update of the initial risk assessment is required. 940

NOTE 3 Subsystem requirements can be directly allocated if they are already available at this level or 941 are apportioned by deriving them from system level requirements. 942

6. Design and implementation: during this phase subsystems and components should be 943 created according to the RAMS requirements. Furthermore plans for future life-cycle 944 tasks have to be established (details see 8.7); 945

7. Manufacture: the subsystems and components of the system should be manufactured 946 and RAMS centred assurance arrangements have to be established and applied 947 (details see 8.8); 948

8. Integration: all subsystems and components should be assembled and installed to 949 form the complete system (details see 8.9); 950

9. System Validation: it should be validated that the system, product or process 951 complies with the RAMS requirements in combination with external risk reduction 952 measures (details see 8.10); 953

10. System acceptance: demonstrate compliance of complete system with overall RAMS 954 requirements and accept system for entry into service (details see 8.11); 955

- 25 - prEN 50126-1

11. Operation, Maintenance and Performance Monitoring: The objective of this phase is 956 to operate, maintain and support the product, system or process such that 957 compliance with system RAMS requirements is maintained. This includes to 958 continuously evaluate the RAMS performance of the system and to derive measures 959 (details see 8.12); 960

12. Decommissioning: in case of decommissioning the system it has to be ensured that 961 the risk is controlled during the transition phase (details see 8.13). 962

6 Railway RAMS 963

6.1 Introduction 964

Clause 6 of this standard provides baseline information on the subject of RAMS. The purpose of 965 this clause is to provide the reader with sufficient background information to enable the effective 966 application of this standard to railway systems. All requirements derived from this clause are 967 specified in clause 8 RAMS life-cycle. 968

Railway RAMS is a major contributor to the Quality of Service provided by railway duty holder. 969 Railway RAMS is defined by several contributory elements; consequently, this clause of this 970 standard is structured as follows: 971

1. Subclauses 6.2 and 6.3 provide an overview of the systems approach and system 972 definition within the context of railways; 973

2. Subclause 6.4 examines the relationship between railway RAMS and quality of 974 service; 975

3. Subclause 6.5 outlines the railway RAMS elements and its interaction; 976

4. Subclauses 6.6 to 6.10 examine aspects of railway RAMS, namely: 977

the elements of RAMS; 978

the factors which influence and means to achieve RAMS targets; 979

risk and safety integrity. 980

6.2 System-level approach 981

6.2.1 Concepts of system hierarchy 982

6.2.1.1 Within this standard, the sequence “system, sub-system, component” is used to 983 demonstrate the breakdown of a system into its constituent parts. The precise boundary of each 984 element (system, sub-system and component), either physical or functional, will depend upon 985 the specific application. The system itself is contained in an operational environment. 986

6.2.1.2 A system can be defined as an assembly of sub-systems and components, connected 987 together in an organised way, to achieve specified functionality. Functionality is assigned to 988 sub-systems and components within a system and the behaviour and state of the system may 989 change if the sub-system or component functionality changes. A system responds to inputs to 990 produce specified outputs, whilst interacting with an environment. 991

6.2.1.3 Basic concept of nested systems in a system hierarchy can be shown diagrammatically 992 by Figure 2. 993

According to the nested systems concept, systems are themselves built up of smaller systems 994 that themselves are built up of even smaller systems and so on. 995

For convenience, multi level nested systems are usually handled on the basis of successive 996 groupings of systems at 3 levels of hierarchy. The 3 level hierarchies would consist of a “system 997 under consideration” (e.g. sub-system D) containing its intra-related subsystems and / or 998 components (W, X, Y and Z) and itself being contained, together with its inter-related sub-999 systems and / or components (A, B and C) in a containing or parent system (e.g. Railway 1000 system). This provides visibility of the 3 levels and enables consideration of: 1001

prEN 50126-1 - 26 -

the interactions and interfaces between the “system under consideration” and its 1002 “siblings” i.e. the inter-related sub-systems / components and; 1003

the influences and interactions between the “system under consideration” and its 1004 environment (i.e. the “parent” or “containing system”). 1005

Functions of a system are the actions or activities performed by the system as a whole. 1006 Functions and structure provide the “internal” view of the system properties that produce the 1007 outputs and external properties and are the concern of the body/entity responsible for the 1008 design of the system. The environment consists of anything that could influence, or be 1009 influenced by, the system. This will include anything to which the system connects mechanically, 1010 electrically or by other means, including EMI, thermal, etc. The environment will also include 1011 people and procedures that can effect, or be affected by, the operation of the system. 1012

Understanding the boundary between the system under consideration and its environment and 1013 the interactions with its inter-related sub-systems is a pre-requisite to understanding how the 1014 system might contribute to an accident and what its hazards are (see Figure 2). 1015 1016

1017

Figure 2 − Illustration of system hierarchy 1018

6.2.2 A system’s requirements and characteristics 1019

6.2.2.1 A system’s requirements are elicited from various sources. Requirements may be 1020 categorised, but a unique and unambiguous categorisation is not possible. Therefore, the 1021 following classification is for orientation purposes: 1022

Functional requirements: a system is implemented to fulfil certain functions that are 1023 fundamental to the system and the prime reason for its creation. Depending on the system 1024 design, additional requirements may also be needed to ensure proper functioning of the 1025 system. The fundamental requirements and the additional requirements together are 1026 referred to as “Functional requirements”. They express the behaviour of the system and 1027 may also need to be complemented by properties qualifying its level of performance (e.g. 1028 reliability, safety, accuracy, timing, etc.). 1029

Contextual requirements: the relation between the system and its environment may need to 1030 be further qualified by means of contextual requirements. They would address issues like 1031 the system mission profile, maintenance and logistics, human factors (e.g. personal 1032 qualification), procedural environment, costs, etc. 1033

A

B

C

A

B

C

D

W

X

Y

Z

system (environment of system under consideration)

sub-system / components

sub-system / components

sub-system (system under consideration)

sub-systems / components (of system under consideration)

- 27 - prEN 50126-1

Technical requirements: the technical implementation of the system may generate further 1034 requirements that do not derive from the system functions but from its technical 1035 implementation. Such requirements are referred to as “Technical requirements”. They 1036 impact the system build. Technical requirements may address issues such as 1037 maintainability, environmental conditions, potential threats created by the technology/ 1038 equipment regardless of their intended functions (e.g. presence of sharp edges, presence 1039 of electric voltage, presence of combustible material, etc.). 1040

Detailed design involves engineering the sub-systems and equipment that implement the 1041 functional requirements of the system under consideration. It leads to refining the functional 1042 requirements to ensure compatibility between the different sub-systems / equipment, and to 1043 implement the refined functional requirements whilst enforcing the technical and contextual 1044 requirements. 1045

Characteristics of the system and its constituents (user-related characteristics, derived from the 1046 functional, technical and contextual requirements) are determined by the requirements and a 1047 system’s compliance with its requirements is demonstrated through its characteristics. 1048 Implementation of the system (i.e. the technical solution) is then likely to give rise to additional 1049 characteristics (referred to as implementation characteristics) introduced by the design. 1050

6.2.3 Defining a system 1051

6.2.3.1 A system comprises not only of its technical components but also the interaction with 1052 humans developing, operating, and maintaining it. Therefore, these should be included in the 1053 definition and documentation of the considered system taking into account the concept of 1054 system hierarchy explained in 6.2.1. 1055

Before any RAMS analysis is undertaken (e.g. hazard identification) boundaries and functions of 1056 the system under consideration have to be established. Therefore, the following aspects, but not 1057 limited to, should be taken into account and clearly documented: 1058

System boundaries and interfaces (interfaces, e.g. with other systems or with the 1059 environment, define the boundaries of the system to be analysed and the interactions 1060 that occur over these boundaries); 1061

Intended function, e.g. system functions which are to be included in the analysis and 1062 system functions which are to be excluded, if any; 1063

Working environment, e.g.: 1064

influence on neighbouring objects, systems, and environment including operational 1065 personnel, passengers, and public; 1066

Definitions of physical and operational conditions and the environment under which 1067 the system works; 1068

Description of necessary operator actions. Also identifying persons that are permitted 1069 to carry out these actions, indicating the skills and qualifications required and the 1070 basis for these actions, if any; 1071

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

Modes of operation, e.g.: 1074

normal, abnormal/degraded mode of operation, disconnect/connect states and 1075 transitions, etc., and their interactions; 1076

operational scenarios to be considered within the analysis, e.g. effects of 1077 maintenance operations (how, how often and by whom is the system maintained?); 1078

External requirements e.g. external safety requirements resulting from the overall safety 1079 policy of the railway duty holder, from prevailing legal considerations, or from standards; 1080

Version of the system and related documents: 1081

if assumptions are made about particular functions or subsystems that are different 1082 from an existing version, then the deviations should be explicitly stated and justified; 1083

prEN 50126-1 - 28 -

if the system is modified later during its life-cycle, it may be necessary to revise the 1084 RAMS analysis and may even require a completely new risk assessment; 1085

the potential effects of new system versions on the safety of the railway system 1086 should always be checked by reviewing the risk assessment, in particular the hazard 1087 log. 1088

NOTE For software related items it is clear that software cannot be studied alone. Only through a consideration of the 1089 software loaded into a system operating within a certain environment and fulfilling a certain function is it viable to 1090 perform a comprehensive RAMS analysis. 1091

6.3 Railway system overview 1092

6.3.1 Introduction 1093

6.3.1.1 Sub-clause 6.3 gives a perspective of the railway system, the bodies/entities involved in 1094 it and on some of the underlying concepts and RAMS considerations (e.g. risk, hazards). An 1095 understanding of the system and its elements is essential for the management of railway RAMS. 1096

6.3.2 Bodies/entities involved in a railway system 1097

Depending on the social/political environment and the organisational /management structure of 1098 the railway system concerned, a number of bodies/entities, performing different functions, may 1099 be involved within the life-cycle phases of the system. For the purpose of this standard the 1100 bodies/entities are divided into the following main categories: 1101

railway undertakings (railway duty holder); 1102

infrastructure managers (railway duty holder); 1103

maintainers; 1104

railway supply industry; 1105

safety authorities. 1106

6.3.2.1 As far as the RAMS process is concerned, developing generic products imposes the 1107 obligations of the railway duty holder in this regard on the railway supply industry. 1108

6.3.2.2 The roles and responsibilities of these bodies may be contracted out to several other 1109 stakeholders or sub-contractors, depending on: 1110

social, political or legal considerations; 1111

size and complexity of the system or subsystem concerned; 1112

economic, organisational or managerial considerations. 1113

It is therefore advisable to identify all the stakeholders that can be a part of this relationship and 1114 to examine and document how the roles and responsibilities of dealing with safety, during the 1115 life-cycle of the system/sub-system concerned, are shared between them. 1116

Refer to 7.1.1.3 for further information on the stakeholders of the railway and their roles and 1117 responsibilities. 1118

6.3.3 Railway system environment and the balance of requirements 1119

6.3.3.1 A railway system would normally operate within a prevailing socio-economic/political 1120 environment. The affordability of the rail transport system, both in terms of its design, 1121 construction and implementation and in terms of its subsequent use, also depends on this 1122 environment. Therefore affordability of the railway system and existing RAMS performance 1123 within the prevailing environment or RAMS performance that are socially/politically tolerable 1124 within this environment constitute the context for the RAMS considerations.. Specifically, a 1125 railway system that is unaffordable to the users may well reduce safety within the social 1126 environment, e.g. by displacing users onto other modes of transport that are generally less safe. 1127

- 29 - prEN 50126-1

6.3.3.2 The legal framework within the prevailing socio-economic/political system defines the 1128 jurisdiction over the rail transport system and determines responsibilities. Within this frame the 1129 relevant bodies should ensure a balance between affordability and safety and therefore for 1130 providing/specifying safety requirements and targets for tolerable levels of safety risk for the 1131 railway system as a whole. Often such targets may not be available at the start of a project and 1132 the body/entity responsible for the railway system (e.g. for its design/configuration) may propose 1133 targets that are endorsed or revised by the relevant authority with jurisdiction. 1134

6.3.3.3 Similarly, considering a hierarchical system structure, when the system under 1135 consideration is a subsystem of the railway system then it would be the body/entity responsible 1136 for the safe operation of the railway system (railway duty holder) that should set or specify the 1137 safety requirements and targets for tolerable levels of risk for the subsystem in agreement with 1138 rules given by the legal framework. In general, therefore, it is the body/entity responsible for the 1139 design/configuration at each system level that would also be responsible for setting or 1140 specifying safety requirements and targets for its subsystems. In some instances, the railway 1141 duty holder may set or specify safety requirements and safety targets for lower level subsystems 1142 or for specific hazards in agreement with rules given by the legal framework. 1143

6.3.4 Railway system structure and apportionment of RAMS requirements 1144

6.3.4.1 The Railways system, as with any system, can be viewed from a physical or functional 1145 perspective. No single view or breakdown of the system will suit all needs, and the view 1146 ultimately adopted is dependent on the user and their requirements. 1147

6.3.4.2 Based on the concept of system hierarchy (6.2.1), it would then be the task of the 1148 body/entity responsible for each of the subsystems to map or apportion the RAMS requirements 1149 to their subsystems/components. Defining precise boundaries and boundary conditions will 1150 support this apportionment. It is often helpful for this task to be carried out with the cooperation 1151 of the responsible body/entity of the subsystems/components to ensure that the requirements 1152 and targets are practicable. This process may require several iterations to ensure that the 1153 overall system is optimised. 1154

6.3.4.3 A similar reference system may be considered to support this apportionment. However 1155 any differences, functional, technical, operational or in the application environment (e.g. system 1156 boundaries and boundary conditions; maintenance and operational competence levels; 1157 functional and technical interfaces with its environment, especially with other systems etc.), and 1158 the effect of the differences on the RAMS performance should be evaluated for acceptability. 1159

6.4 Railway RAMS and quality of service 1160

6.4.1 This subclause introduces the link between RAMS and quality of service. 1161

6.4.2 RAMS is a characteristic of a system’s long term operation and is achieved by the 1162 application of established engineering concepts, methods, tools and techniques throughout the 1163 life-cycle of the system. The RAMS of a system can be characterised as a qualitative and 1164 quantitative indicator of the degree that the system, or the sub-systems and components 1165 comprising that system, can be relied upon to function as specified and to be both available and 1166 safe over a period of time. System RAMS, in the context of this European Standard, is a 1167 combination of the interrelated characteristics, reliability, availability, maintainability and safety. 1168

6.4.3 The goal of a railway system is to achieve a defined level of rail traffic at a given time, 1169 safely within certain cost limits. Railway RAMS describes the confidence with which the system 1170 can guarantee the achievement of this goal. Railway RAMS has a clear influence on the quality 1171 with which the service is delivered to the customer. Quality of Service is influenced by other 1172 characteristics concerning functionality and performance, for example frequency of service, 1173 regularity of service and fare structure. 1174

6.5 Elements of railway RAMS 1175

6.5.1 This subclause introduces the interaction between RAMS elements, reliability, 1176 availability, maintainability and safety, in the context of railway systems. 1177

prEN 50126-1 - 30 -

6.5.2 A dependable railway system can be realised through consideration of the interactions 1178 of system's RAMS elements and the specification and achievement of the optimum RAMS 1179 combination for the system. 1180

6.5.3 The RAMS elements are inter-linked in the sense that a weakness in any or 1181 mismanagement of conflicts between their requirements may prevent achievement of a 1182 dependable system. For example, a safety target may be achieved by ensuring the system 1183 enters a safe state in the event of a particular failure. However, should this safe state be 1184 detrimental to reliability/availability (e.g. train at standstill), a different and optimised solution 1185 may be required to achieve the RAMS targets. 1186

6.5.4 Attainment of in-service availability targets will be achieved by optimising reliability & 1187 maintainability whilst considering the influence of maintaining safety. The related requirements 1188 should be met and controlled through the ongoing, long-term, maintenance and operational 1189 activities and the system environment. 1190

6.5.5 Security, as an element that characterises the resilience of a railway system to 1191 vandalism and unreasonable human behaviour, can be considered as a further aspect of RAMS. 1192 Consideration of security is outside the scope of this standard. However, security could be 1193 considered by the same processes and methods. 1194

6.5.6 Technical concepts of availability are based on a knowledge of: 1195

a) reliability and safety in terms of: 1196

all possible system failure modes in the specified application and environment; 1197

the frequency of occurrence or the likelihood of each failure mode; 1198

the consequences of the failure mode on the functionality of the system. 1199

b) maintainability in terms of: 1200

time for the performance of planned maintenance; 1201

time for detection and identification of the faults; 1202

time for the restoration of the failed system (unplanned maintenance). 1203

c) operation and maintenance in terms of: 1204

all possible operation modes and required maintenance (taking into account cost 1205 issues), over the system life-cycle; 1206

the human factor issues; 1207

tools, facilities and procedures for effective maintenance of the system. 1208

6.5.7 Technical concepts of safety are based on a knowledge of: 1209

a) all possible accidents and associated hazards that could result from a failure in the 1210 system, under all operation, maintenance and environment modes; 1211

b) the characteristic of each hazard in terms of the severity of its consequences; 1212

c) safety-related failures in terms of: 1213

All system failure modes that could lead to a hazard (safety-related failure modes); 1214

The frequency of occurrence or the probability of of each relevant safety-related 1215 system failure mode; 1216

Sequence and/or coincidence of events, failures, operational states, environment 1217 conditions, etc., in the application, that may result in an accident (i.e. a hazard 1218 resulting in an accident); 1219

The frequency of occurrence or the probability of the relevant events, failures, 1220 operational states, environment conditions etc., in the application. 1221

d) maintainability of safety-related parts of the system in terms of: 1222

- 31 - prEN 50126-1

the ease of performing maintenance on those aspects or parts of the system or its 1223 components that are associated with a hazard or with a safety-related failure mode; 1224

possible errors occurring during maintenance actions on those safety-related parts of 1225 the system; 1226

time for restoring the system into a safe state. 1227

e) system operation and maintenance of safety-related parts of the system in terms of: 1228

human factors influence on the maintenance and the operation; 1229

Tools, facilities and procedures for effective maintenance of the system and for safe 1230 operation; 1231

effective controls and measures for dealing with a hazard and mitigating its 1232 consequences. 1233

6.5.8 Failures in a system operating within the bounds of an application and environment will 1234 have some effect on the behaviour of the system. Failures will have an impact on the system's 1235 reliability, availability and safety, with the level of impact being determined by the system 1236 functionality and design. All failures will also have a cost implication. The environment and the 1237 operational rules may also influence these effects. 1238

6.6 Factors influencing railway RAMS 1239

6.6.1 General 1240

6.6.1.1 This subclause introduces and defines a process to support the identification of factors 1241 which influence the RAMS performance of railway systems, with particular consideration given 1242 to the influence of human factors. These factors, and their effects, are an input to the 1243 specification of RAMS requirements for systems. 1244

6.6.1.2 The RAMS performance of a railway system is influenced in three ways: 1245

by sources of failure introduced internally within the system at any phase of the system 1246 life-cycle (system conditions); 1247

by sources of failure imposed on the system during operation (operating & environmental 1248 conditions) and; 1249

by sources of failure imposed on the system during maintenance activities (maintenance 1250 conditions). 1251

These sources of failure can interact. 1252

6.6.1.3 To create dependable systems, factors which could influence the RAMS of the system 1253 need to be identified, their effect assessed and the cause of these effects managed throughout 1254 the life-cycle of the system, by the application of appropriate controls (see 6.7) to optimise 1255 system performance. 1256

6.6.2 Classes of failures 1257

6.6.2.1 Failures in a safety-related system, product or process are categorized as random 1258 failures or systematic failures. 1259

Random failures are due to physical causes. Sometimes it can be challenging to 1260 separate random failures from those which statistically appear as being nearly randomly 1261 occurring, although they are of systematic nature (e. g. wear out); 1262

Systematic failures are failures due to errors, which cause the product, system or 1263 process to fail deterministically under a particular combination of inputs or under 1264 particular conditions (e.g. combination of inputs or/and triggering events such as non-1265 fulfilment of environmental or application conditions). Systematic failures are mainly 1266 caused by human errors in the various stages of the system life-cycle (concept, 1267 requirements specification, design, manufacture, Integration, operation, maintenance 1268 and modification). This applies for systematic failures in software as well as in hardware. 1269

prEN 50126-1 - 32 -

6.6.2.2 The clear distinction between random and systematic failures might be blurred by the 1270 following observations. 1271

Systematic failures are reproducable, if conditions can be exactly replicated. If these 1272 conditions (the combination of input that activates them) are by themselves a random 1273 event, the occurrence of the systematic failures also exhibit a temporal random 1274 behaviour viewed from the outside; 1275

Large fractions of failures, due to environmental conditions (e.g. temperature, moisture, 1276 humidity etc.) and external influences (EMC, vibration), may be considered both 1277 systematic or random as well; 1278

Finally, for both the classes it holds true that the exact time of the occurrence is 1279 practicably not predictable. 1280

6.6.2.3 A major distinguishing feature between random failures and systematic failures is that 1281 random failures are in general due to events that can be statistically monitored and therefore 1282 predicted. Systematic failures are due to events that cannot be statistically predicted. 1283

6.6.3 Derivation of detailed railway specific influencing factors 1284

This subclause details a process for the derivation of those factors which will affect the 1285 successful achievement of a system which complies with specified RAMS requirements. 1286

6.6.3.1 The process of deriving detailed influencing factors can be supported by the use of the 1287 two checklists covering generic and railway specific factors (6.6.3.2.1) as well as human factors 1288 (6.6.3.3), a core aspect within an integrated RAMS management process. Through the 1289 assessment of each generic influencing factor within the context of the specific system, the 1290 detailed factors which influence the RAMS of railway systems can be systematically derived. 1291

6.6.3.2 The railway duty holder should specify any applicable factors in their call for tenders. 1292

6.6.3.2.1 The derivation of detailed railway specific influencing factors should include, but not be 1293 limited to, a consideration of each of the following factors. It should be noted that the following 1294 checklist is non-exhaustive and should be adapted to the scope and purpose of the application: 1295

a) system conditions: 1296

system operation: 1297

the tasks which the system has to perform and the conditions in which the tasks 1298 have to be performed (mission profile, procedures); 1299

the co-existence of passengers, freight, staff and systems within the operating 1300 environment; 1301

maintainability; 1302

system life requirements, including system life expectancy, service intensity and 1303 life-cycle cost requirements. 1304

failure categories: 1305

the effects of failure within a distributed railway system; 1306

random failure (stress degradation, wear out, over stress etc.); 1307

systematic failures (errors in requirements, design & realisation inadequacies, 1308 manufacturing deficiencies, inherent weaknesses, software errors, operating 1309 instruction deficiencies, installation inadequacies, human errors etc.). 1310

b) operations conditions: 1311

environment; 1312

the physical environment; 1313

the constraints imposed by existing infrastructure and systems on the new system 1314 under consideration 1315

the high level of integration of railway systems within the environment; 1316

- 33 - prEN 50126-1

the limited opportunity for testing complete systems in the railway environment. 1317

c) application conditions: 1318

the constraints imposed by the system on operation and maintenance; 1319

the need to maintain rail services during life-cycle tasks (e.g. operating under 1320 degraded mode during maintenance); 1321

human factors; 1322

diagnostics; 1323

installation conditions; 1324

the integration of existing systems and new systems during commissioning and 1325 operation. 1326

d) maintenance conditions 1327

preventive & corrective maintenance; 1328

human factors; 1329

logistics; 1330

diagnostics; 1331

trackside-based maintenance conditions. 1332

6.6.3.2.2 It is recommended to use a diagrammatic approach to derive detailed factors, such as 1333 the use of cause/effect diagrams. An example of a much simplified cause/effect diagram is 1334 shown in Figure 3. 1335

prEN 50126-1 - 34 -

1336

Figure 3 − Example of deriving cause/effect relations in a diagrammatic approach2) 1337

1338

6.6.3.3 Human factors 1339

6.6.3.3.1 An analysis of human factors, with respect to their effect on system RAMS, is inherent 1340 within the “systems approach” applied by this standard. Guidance given by standards is rare but 1341 e.g. guidance on ergonomic design can be found in European Standard EN 614. 1342

6.6.3.3.2 Human factors can be defined as the impact of human characteristics, expectations 1343 and behaviour upon a system. These factors include the anatomical, physiological and 1344 psychological aspects of humans. The concepts within human factors are used to enable people 1345 to carry out work efficiently and effectively, with due regard for human needs on issues such as 1346 health, safety and job satisfaction. 1347

6.6.3.3.3 Each human might react to situations in different ways which impacts the RAMS 1348 performance. The achievement of railway RAMS requires more rigorous control of human 1349 factors, throughout the entire system life-cycle, than is required in many other industrial 1350 applications. 1351

—————————

2) based on “The 6 Ms” by K. Ishikawa (1960)

RAMS performance

Machine Material Man

Mother Nature Measurement Method

Equipme

Consumables

Climate

Monitoring

Management

Text Case

Organisation

Maintenance Procedures

Operational Procedures

Documentation

Maintenance

Staff Selection

Training

Operation

Culture Energy

Lubricants

Raw Material

- 35 - prEN 50126-1

Humans have the ability to influence the RAMS of a railway system positively or negatively. To 1352 maximise the positive influence and minimise the negative influence, the manner in which 1353 human factors can influence railway RAMS should be identified and managed throughout the 1354 life-cycle. This analysis should not only include the potential impact of human factors on railway 1355 RAMS within the operational phase, but also within the other phases of the system in 1356 accordance with the risk assessment. The precise influence of human factors on RAMS is 1357 specific to the application under consideration. For guidance and methods to analyse the 1358 influence of human factors on RAMS, standards like VDI 4006, “Human Reliability” may be 1359 considered. 1360

6.6.3.3.4 Human influence can be regarded as having both random and systematic aspects. All 1361 humans are subject to occasional lapses in performance. When these occur in the operational 1362 and maintenance phases of the system life-cycle they tend to result in random failures: when 1363 they occur in earlier phases of the life-cycle they may result in systematic failures in the 1364 operational phase. 1365

6.6.3.3.5 Lack of competence can lead to systematic human error, where lack of knowledge or 1366 understanding can result in the same incorrect action always being taken under the same 1367 circumstances. This can affect all phases of the life-cycle. 1368

6.6.3.3.6 The derivation of detailed human influencing factors should include, but not be limited 1369 to, a consideration of each of the following human factors. It should be noted that the following 1370 checklist is non-exhaustive and should be adapted to the scope and purpose of the application. 1371

a) the allocation of system functions between human and machine; 1372

b) the effect on human performance within the system of: 1373

the human/system interface; 1374

the environment, including the physical environment and ergonomic requirements; 1375

human working patterns; 1376

human competence; 1377

the design of human tasks; 1378

human interworking; 1379

human feedback process; 1380

railway organisational structure; 1381

railway culture; 1382

professional railway vocabulary; 1383

problems arising from the introduction of new technology. 1384

c) requirements on the system arising from: 1385

human competence; 1386

human motivation and aspiration support; 1387

mitigating the effects of human behavioural changes; 1388

operational safeguards; 1389

human reaction time and space; 1390

d) the requirements on the system arising from human information processing capabilities, 1391 including: 1392

human/machine communications; 1393

density of information transfer; 1394

rate of information transfer; 1395

the quality of information; 1396

human reaction to abnormal situations; 1397

prEN 50126-1 - 36 -

human training; 1398

supporting human decision making processes; 1399

other factors contributing to human strain. 1400

e) the effect on the system of human/system interface factors, including: 1401

the design and operation of the human/system interface; the provision of user 1402 manuals etc.; 1403

the effect of human error; 1404

the effect of deliberate human rule violation; 1405

human involvement and intervention in the system; 1406

human system monitoring and override; 1407

human perception of risk; 1408

human involvement in critical areas of the system; 1409

human ability to anticipate system problems; 1410

human reaction under different operating modes (e.g. normal, degraded or 1411 emergency). 1412

f) human factors in system design and development, including: 1413

human competency; 1414

human independence during design; 1415

human involvement in verification and validation; 1416

interface between human and automated tools; 1417

systematic failure prevention processes (e.g. measures to assure safety integrity). 1418

6.6.4 Evaluation of factors 1419

6.6.4.1 The potential effect of each influencing factor on the RAMS of the railway system under 1420 consideration can be identified through evaluation at the appropriate level. An appropriate and 1421 comprehensive specification of RAMS requirements can be ensured by addressing the 1422 interaction of associated influencing factors including human factors. 1423

6.7 Specification of railway RAMS requirements 1424

6.7.1 General 1425

6.7.1.1 The main goal of RAMS activities is to achieve a system performance that meets the 1426 RAMS requirements. Therefore, they have to be properly specified. EN 50126-2 provides 1427 methods for deriving and specifying system safety requirements 1428

6.7.1.2 To achieve the required quality the parameters influencing the RAMS performance need 1429 to be controlled throughout the life of the system. Effective control requires the establishment of 1430 mechanisms and procedures to defend against sources of error being introduced during the 1431 realisation and support of the system. Such defences need to take account of both random and 1432 systematic failures. 1433

6.7.1.3 The means used to achieve RAMS requirements are based on the concept of taking 1434 precautions to minimise the possibility of an impairment occurring as a result of an error during 1435 the life-cycle phases. Precaution is a combination of: 1436

prevention: concerned with lowering the likelihood of the impairment and 1437

protection / mitigation: concerned with lowering the severity of the consequences of the 1438 impairment. 1439

Prevention is preferred. 1440

- 37 - prEN 50126-1

6.7.2 RAMS specification 1441

6.7.2.1 The specification of RAMS requirements is a complex process. 1442

6.7.2.2 Suitable parameters to characterise reliability, availability, maintainability, logistic 1443 support and safety requirements of railway systems are shown in Annex B. Specific parameters 1444 will depend on the system under consideration. All RAMS parameters used should be agreed 1445 between the railway duty holder and the railway supplier on the basis of the rules given by the 1446 legal framework. Where parameters may be expressed in alternative dimensions, conversion 1447 factors should be provided. 1448

A list of suitable tools for RAMS activities is also included in Annex A. Selection of an 1449 appropriate tool will depend on the system under consideration and on factors such as the 1450 criticality, novelty, complexity etc. of the system. Annex A and Annex B are for guidance only 1451 and have been populated using rolling stock as an example. 1452

6.8 Risk based approach 1453

6.8.1 The risk based approach involves managing RAMS activities based on decisions which 1454 are derived from considerations on risk. Risk is the combination of two elements: 1455

the expected frequency of occurrence of loss and; 1456

the degree of severity of this loss (consequence). 1457

The risk based approach aims to identify risks, derive requirements and implement measures to 1458 avoid or control these risks. Finally it is characterised by judgement on the acceptance of the 1459 remaining risks by use of acceptance criteria if needed derived by the application of risk 1460 acceptance principles. This approach is fundamental to the RAMS management process which 1461 allows to manage RAMS through the whole product life-cycle. 1462

In the context of safety, loss may imply human and/or environmental harm. Details are given in 1463

Table D.1 - Frequency of occurrence of events with examples for quantification (time 1464 based); 1465

Table D.2 - Frequency of occurrence of events with examples for quantification (distance 1466 based); 1467

Table D.4 - Severity categories (example 1 related to RAMS) 1468

Table D.5 - Categories (example 2 related to Safety) 1469

for safety aspects, and in 1470

Table D.3 - Severity categories (example related to RAM); 1471

Table D.6 - Financial severity levels (example) 1472

for non-safety aspects. 1473

Environmental loss is often taken into account in a qualitative manner, and usually not included 1474 in the safety studies. However, it is recommended that its exclusion be agreed between the duty 1475 holder and the relevant safety authority, as long as there are no contradictions to the given legal 1476 framework. 1477

It should be noted that commercial aspects of safety can be considered for completeness of 1478 safety concepts, but are not usually included in safety studies. The relationship of risk terms is 1479 shown in Figure 4 below, as a safety-related example. It has to be adapted to RAM aspects 1480 correspondingly. 1481

prEN 50126-1 - 38 -

1482

Figure 4 − Relationship of cause, hazard and accident 1483

1484

6.9 Risk reduction strategy 1485

6.9.1 Introduction 1486

The strategy of risk reduction applies to all risks related to RAMS. The objective of the strategy 1487 is to reduce risk to an acceptable level whenever a risk is analysed as being not acceptable 1488

The risk can be reduced by decreasing the frequency of loss and/or its severity. 1489

As an additional perspective to the application of the RAMS management process, the following 1490 guidance derived from ISO/IEC GUIDE 51 is given. It concentrates on risks related to safety. 1491 Nevertheless, these considerations can be applied to RAM as well in an adapted sense. 1492

6.9.2 Reduction of risks related to safety 1493

6.9.2.1 This subclause describes a best practice approach to reduce risk. The following steps 1494 should be applied in order and assessed on the basis of their practicability. 1495

An initial goal of any safety-related activity is to determine if the hazard can be practicably 1496 avoided. If this is not possible, it should be considered if the frequency of occurrence of this 1497 hazard could be reduced to an acceptable level. 1498

If not sufficient, the next goal is to ensure that the frequency of a hazard turning into an accident 1499 is kept as low as possible. 1500

If this cannot be reduced sufficiently, the severity of loss, resulting from the accident (hazard’s 1501 consequence), should be minimised. 1502

The approach and the steps necessary to ensure safety in designing equipment as well as for 1503 setting operational rules are: 1504

a) make the function under consideration safe. 1505

The best way to achieve this goal is making the function fail-safe. 1506

Failsafe techniques have the following properties: 1507

no single failure leads to an unsafe condition (for reasonably foreseeable failures); 1508

hazard x

&

&

&

triggering event

other events or different

circumstances

other events or circumstances

accident A1

accident A3

accident A2

hazard 1

hazard …

cause 1

cause …

- 39 - prEN 50126-1

single failures are detected, negated (a safe state is enforced) and such safe state is 1509 retained (the system is locked in the safe state). 1510

More guidance can be found in EN 50126-2. Further guidance for E/E/PE safety-related 1511 systems can be found in EN 50126-4. 1512

The safe failure mode is a relative concept, and the related arguments are part of the 1513 safety analysis. Some systems do not have one single status that is safe under all 1514 circumstances. For example, automatically stopping a train if an emergency is detected 1515 is usually safe but sometimes dangerous (e.g. burning train stopped in a tunnel). 1516

b) If necessary, provide safety functions in addition or any other barrier. 1517

Wherever necessary, functions especially dedicated to increase safety should be 1518 implemented. This applies for all technologies and for operational rules as well. It has to 1519 be ensured, that the performance of this safety functions is adequately checked in the 1520 required intervals. 1521

c) If necessary, provide safety-related information in addition. 1522

According to the above, additional measures might be necessary, expressed as 1523 additional constraints improving safety (e.g. related to application, maintenance, 1524 operation…). 1525

6.9.2.2 More guidance for safety aspects can be found in EN 50126-2. The risk reduction 1526 approach presented in sub-clause 6.9.2.1 can also be applied to RAM aspects. See the 1527 examples provided in Annex F. The reduction then relates to losses (e.g. reliability, financial) 1528 rather than hazards/accidents. 1529

6.10 Safety integrity 1530

6.10.1 Safety integrity concept 1531

6.10.1.1 Safety integrity is the property of a safety-related requirement, being fulfilled and 1532 maintained constantly over time. This term has a general meaning and can be applied to 1533 different aspects of safety: e.g. one could consider high integrity solutions for functional, 1534 architectural, operational and process requirements. 1535

6.10.1.2 What is important, in the concept of safety integrity, is that no safety-related system 1536 can be viewed as being without any remaining error. Therefore one should expect failures, and 1537 make appropriate provision. 1538

Safety integrity can be affected both by random and systematic failures. It expresses the level of 1539 confidence that the achievement of the safety requirement is not corrupted by both systematic 1540 and random failures respectively. 1541

6.10.1.3 Prevention of systematic and random failures may require different approaches: 1542

The Random failure aspect of safety integrity is achieved by product design (e.g. 1543 diversity, redundancy, defences for expected environmental conditions foreseen in 1544 specific Codes of Practice etc.); 1545

The Systematic failure aspect of safety integrity can also get advantage from technical 1546 defences embedded in the product (diversity, for instance), but it requires mainly 1547 process solutions such as quality management, safety management, and organizational 1548 measures; 1549

Applying corrective maintenance actions will be sufficient in case of random causes. 1550 However, in the case of systematic errors corrective maintenance can only provide a first 1551 response and further measures will be required; 1552

When well-defined failure models and common data-bases are available, a quantitative 1553 assessment can be carried out for the random failure aspect of safety integrity; 1554

There is currently no commonly accepted basis for quantifying systematic failures. Therefore, 1555 the methods defined in this standard preclude quantification of systematic failures. 1556

prEN 50126-1 - 40 -

7 Management of railway RAMS 1557

7.1 RAMS process 1558

7.1.1 General 1559

7.1.1.1 Clause 7 of this European Standard defines a management process, based on a system 1560 life-cycle, which will enable the control of RAMS factors specific to railway applications. This 1561 procedure called RAMS process supports the: 1562

definition of RAMS requirements; 1563

assessment and control of threats to RAMS; 1564

planning and implementation of RAMS tasks; 1565

achievement of compliance with RAMS requirements; 1566

on-going monitoring, during the life-cycle, of compliance. 1567

7.1.1.2 Although railway RAMS is the focus of this European Standard, it is one of many aspects 1568 of a total railway system. This standard defines a systematic process for RAMS management 1569 such that the process is one component of an integrated management approach which 1570 addresses all aspects of the complete railway system. 1571

7.1.1.3 The railway duty holders bear the primary responsibility for assessing, controlling and 1572 reducing risk. For this task it may be necessary to obtain the relevant RAMS related information 1573 from the railway suppliers about the involved products. 1574

As a general guideline, for a typical railway project, the following applies: 1575

Requirements are usually established by the customer or a safety (legal) authority; 1576

Approval is carried out by a safety authority or its representative within the legal 1577 framework and acceptance is carried out by the customer; 1578

Solutions, their results and verifications are normally elaborated or performed by the 1579 contractor; 1580

Validation is normally performed jointly. 1581

This general rule, however, depends on the contractual and legal relationship between the 1582 parties involved. However, this standard requires that, in each case, the responsibilities for the 1583 tasks in the various life-cycle phases are defined and agreed. 1584

7.1.1.4 All requirements derived from this clause are specified in clause 8 RAMS life-cycle. 1585

7.1.2 Safety management within the RAMS Process 1586

7.1.2.1 Safety management is a part of the overall management process for RAMS described in 1587 this standard. The focus of this process is to reduce the incidence of safety-related failures 1588 and/or the consequences throughout the life-cycle, and thus minimise the residual risk resulting 1589 from these errors. 1590

In all cases the risk analysis process defined in this standard is necessary in order to identify 1591 the degree of safety required for each particular situation. 1592

7.1.2.2 The tolerable safety risk of a railway system is dependent upon the safety criteria set by 1593 the legal framework, or by the railway duty holder in accordance with the rules given by legal 1594 framework. 1595

7.1.2.3 If required for the derivation of safety requirements for generic products, the suppliers 1596 should use the risk acceptance criteria which are foreseen to be required. 1597

7.1.2.4 The safety management process shall be implemented under the control of an 1598 appropriate organisation, using competent personnel assigned to specific roles. 1599

- 41 - prEN 50126-1

7.1.2.5 Assessment and documentation of personnel competence, including technical 1600 knowledge, qualifications, relevant experience and appropriate training, shall be carried out in 1601 accordance with documented requirements to be defined by the safety management 1602 organisation. 1603

7.1.2.6 The level of technical education, the extent of experience, and the need for updating or 1604 refreshing of training shall be appropriate to the safety requirements of the application. 1605

7.1.3 Independence of roles 1606

7.1.3.1 Many roles within an organisation, such as verifier, tester, validator or assessor, are 1607 concerned with confirming the RAMS performance of what has been produced by other roles 1608 (e.g. implementer). 1609

7.1.3.2 Within the limits given by requirements on the independence of roles, one person may 1610 carry out more than one role. 1611

7.1.3.3 Independence between roles may be required in order to reduce the probability of 1612 people in different roles suffering from the same misconceptions or making the same mistakes. 1613 This form of independence can be achieved by employing different people in different roles but 1614 does not usually require the roles to be located in different parts of the organisation or in 1615 different companies (unless specifically required). More guidance on this issue can be found in 1616 EN 50126-2. 1617

7.1.3.4 It is also important that people in roles which involve making judgements about the 1618 acceptability of a product or process from the point of view of safety should not be influenced by 1619 pressure from their peers or supervisors, or by considerations of commercial gain. This form of 1620 independence is more likely to require different roles to be located in different parts of the 1621 organisation or to be located in a different company. 1622

7.1.3.5 In general, a greater degree of safety requires a greater degree of independence for 1623 various roles. More specific guidance on what degree of independence between roles for the 1624 general safety management process is given in EN 50126-2. Specific guidance on the 1625 independence between roles for the development of hardware and software is given in 1626 EN 50126-4 and EN 50126-5. 1627

7.2 System life-cycle 1628

7.2.1 The system life-cycle is a sequence of phases, each containing tasks, covering the 1629 total life of a system, product or process from initial concept through to decommissioning and 1630 disposal. The life-cycle provides a structure for planning, managing, controlling and monitoring 1631 all aspects of a system, including RAMS, as the system progresses through the phases, in order 1632 to deliver the right product in a cost effective manner within the agreed time scales. The life-1633 cycle concept is fundamental to the successful implementation of this standard. 1634

7.2.2 It is important to note that the life-cycle represents a logical sequence rather than an 1635 absolute chronological order. 1636

7.2.3 A system life-cycle, appropriate in the context of railway application, is shown within 1637 Figure 1 (see 5.5). For each phase of the life-cycle, the main tasks are summarised in the 1638 informative Table 1 below. This figure shows RAMS tasks as components of general project 1639 tasks. The general project tasks are outside the scope of this European Standard. RAMS tasks 1640 contribute to the general project tasks for each phase and requirements for the RAMS tasks are 1641 detailed in subsequent clauses of this European Standard. 1642

7.2.3 This standard acknowledges the balance between the RAMS performance of a system 1643 and the costs of development and ownership of the system, known as life-cycle costs. However, 1644 it does not dictate solutions to RAMS issues on the basis of cost since cost requirements are 1645 outside the scope of this standard. 1646

7.2.4 Clause 8 and its subclauses define the objectives, requirements, inputs and 1647 deliverables for RAMS tasks in a consistent format, and within an overall project context, for 1648 each life-cycle phase. 1649

prEN 50126-1 - 42 -

7.2.5 In the context of a procurement process, roles and responsibilities for carrying out 1650 RAMS tasks should be clarified. 1651

Responsibilities for carrying out the tasks will depend on the system under consideration and 1652 the contract conditions applicable. Some general guidelines for establishing these 1653 responsibilities are given in 7.1.1.3. 1654

7.2.6 This standard represents the system life-cycle sequentially. This representation shows 1655 individual phases and the links between phases. Other life-cycle representations are widespread 1656 within industry and may be used as long as they follow the requirements of this standard. 1657

7.2.7 A “V” representation of the life-cycle contained within this standard is shown in Figure 1658 5 below. The top-down branch (left side) is generally called development and is a refining 1659 process ending with the manufacturing of system components. The bottom-up branch (right 1660 side) is related to the assembly, the installation, the receipt and then the operation of the whole 1661 system. 1662

7.2.8 Validation activities in earlier life-cycle phases (requirement validation) 1663

Validation activities in earlier life-cycle phases (before phase 9, see section 8) should be carried 1664 out in order to minimise possible deviations from the RAMS requirements, the results of the risk 1665 analysis and the intended use. 1666

These validation tasks should be documented with the following content: 1667

a) assessment of the adequacy of the information, and where appropriate, data or other 1668 statistics, used as input to risk assessment; 1669

b) evaluation of the consistency and adequacy of the risk analysis; 1670

c) evaluation whether the requirements are adequately analysed and specified in order to 1671 allow the system under consideration to serve the intended purpose. 1672

7.2.9 Validation activities in late life-cycle phases (system validation) 1673

For late life-cycle phases the "V" representation assumes that the validation activities are linked 1674 to the development activities insofar as what is actually designed has to be finally checked with 1675 regard to the requirements (see Figure 5 below as an example). 1676

In systems consisting of subsystems, a hierarchical structure of validation activities according to 1677 the various subsystems may be appropriate. Hence, validation activities shall be planned in an 1678 early life-cycle phase. 1679

These validation tasks shall be documented with the following minimum content: 1680

a) identification of the configuration of the system, product or process subject to validation; 1681

b) evaluation of the consistency and adequacy of the hazard analysis; 1682

c) evaluation of the completeness, correctness, consistency and adequacy of the 1683 verification activities; 1684

d) evidence that all planned validation activities have been carried out with justification of 1685 any deviation from the RAMS Validation Plan; 1686

e) evidence of the completeness, correctness, consistency and adequacy of exported 1687 application conditions and safety-related manuals. 1688

7.2.10 The following validation tasks shall be documented by validation or, if required, by an 1689 Independent Safety Assessment: 1690

a) evaluation of the conformity of the life-cycle process and of the validated item against the 1691 requirements of this European Standard including the required safety integrity; 1692

b) assessment of the competence of all personnel undertaking tasks within the phase; 1693

c) assessment of the adequacy and completeness of the RAMS Validation Plan; 1694

d) assessment of the adequacy and completeness of the safety case; 1695

- 43 - prEN 50126-1

e) assessment of the adequacy and completeness of the training measures with regard to 1696 RAMS aspects. 1697

7.2.11 The objective of verification is to demonstrate that the deliverables of each phase meet 1698 in all respects the requirements of that phase. Within the scope of verification it may also be 1699 necessary to consider the input and process of a phase. 1700

7.2.12 In this standard, verification tasks are included within each life-cycle phase. This 1701 standard addresses verification and validation tasks in the context of RAMS. Nevertheless, 1702 these tasks should be an integral part of the overall system verification and validation tasks. 1703

7.2.13 All requirements derived from this clause are specified in clause 8 RAMS life-cycle. 1704

1705

1706

System Validation 9

11

3

5

6

7

8

10 Operation, Maintenance and Performance Monitoring

Decommissioning12

Concept

4Specification of System Requirements

System Acceptance

Integration

Risk Analysis & Evaluation

Architecture and Apportionment of System Requirements

Design andImplementation

Manufacture

1

System Definition & Operational Context

2

1707 Figure 5 − The "V" representation drawing 1708

- 45 - prEN 50126-1

1709 Figure 6 - verification 1710

1711 Figure 7 - validation 1712

1713

7.2.14 In each life-cycle phase, the verification tasks shall include the following: 1714

a) evaluation of the correctness and adequacy of the safety analysis; 1715

b) verification of the deliverables of the phase for compliance with the deliverables of former 1716 phases; 1717

c) verification of the deliverables of the phase for compliance with the requirements for this 1718 phase defined in this standard; 1719

d) assessment of the adequacy of the methods, tools and techniques used within the phase; 1720

e) evaluation of the correctness, consistency and adequacy of test cases and executed 1721 tests. 1722

7.2.15 Any errors or deficiencies found may require the re-application of some or all of the 1723 activities of one or more previous life-cycle phases. 1724

Life-cycle

phase Input Output

verification

System Requirements

User

validation

prEN 50126-1 - 46 -

Table 1 - System phase related tasks – informative 1725

life-cycle phase Phase related general tasks Phase related RAM tasks Phase related Safety tasks

1. Concept - Establish scope and purpose of railway project

- Define railway project concept - Undertake financial analysis & feasibility

studies - Establish management arrangements

- Review previously achieved RAM performance- Consider RAM implications of project

- Review previously achieved safety performance

- Consider safety implications of project - Review safety policy & safety targets

2. System definition and operational context

- Establish system mission profile - Prepare system description - Identify operation & maintenance strategies - Identify operating conditions - Identify maintenance conditions - Identify influence of existing infrastructure

constraints

- Evaluate past experience data for RAM - Perform preliminary RAM analysis - Set RAM policy - Establish RAM plan - Identify long term operation & maintenance

conditions - Identify influence on RAM of existing

infrastructure constraints

- Evaluate past experience data for safety - Establish safety plan (overall) - Identify influence on safety of existing

infrastructure constraints

3. Risk analysis and evaluation

- Undertake project related risk analysis - Determine the risk acceptance principles and criteria

- Perform system risk analysis - Set-Up hazard log - Perform risk evaluation

4. Specification of system requirements

- Undertake requirements analysis - Specify system (overall requirements) - Specify environment - Define system demonstration & acceptance

Criteria (overall requirements) - Establish validation plan - Establish management, quality & organisation

requirements - Implement change control procedure

- Specify system RAM requirements (overall) - Define RAM acceptance criteria (overall) - Define system functional structure - Update RAM plan

- Specify system safety requirements (overall) - Define safety acceptance criteria (overall) - Define safety-related functional requirements - Establish safety validation plan

5. Architecture and apportionment of systems requirements

- Apportion system requirements ● Specify sub-system & component

requirements ● Define sub-system & component acceptance

criteria

- Apportion system RAM requirements ● Specify sub-system & component RAM

requirements ● Define sub-system & component RAM

acceptance criteria - Update RAM plan

- Apportion system safety targets & requirements

● Specify sub-system & component safety requirements

● Define sub-system & component safety acceptance criteria

- Update safety plan and safety validation plan

- 47 - prEN 50126-1

life-cycle phase Phase related general tasks Phase related RAM tasks Phase related Safety tasks

6. Design and implementation

- Perform design and development - Perform design analysis and testing - Perform design verification - Perform implementation and validation - Perform design of logistic support resources

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

- Implement safety plan by review, analysis, testing and data assessment, addressing:

- Hazard log - Hazard analysis - Justify safety-related design decisions - Undertake programme control, covering: ● Safety management ● Control of sub-contractors & suppliers - Prepare generic product safety case - Prepare (if appropriate) generic application

safety case - Assess generic safety cases

7. Manufacture - Perform production planning - Manufacture - Manufacture and test sub-Assembly of

components - Prepare documentation - Establish training

- Perform environmental stress screening - Perform RAM improvement testing - Commence failure reporting and corrective

action system (FRACAS)

- Implement safety plan by: review, analysis, testing & data assessment

- Use hazard log

8. Integration - Assemble system - Install system

- Start maintainer training - Establish spare parts and tool provision

- Establish installation programme - Implement installation programme - Derive safety-related application conditions

9. System validation - Commission - Perform probationary period of operation - Undertake training

- Perform RAM demonstration - Implement commissioning programme - Update validation plan - Implement validation plan - Prepare specific application safety case

10. System acceptance

- Undertake acceptance procedures, based on acceptance criteria

- Compile evidence for acceptance - Entry into service - Continue probationary period of operation (if

appropriate)

- Assess RAM demonstration - Assess specific application safety case

11. Operation, maintenance and performance

- Long term system operation - Perform on going maintenance - Undertake on going training - Collect operational performance statistics - Acquire, analyse and evaluate data

- On going procurement of spare parts & tools - Perform on going reliability centred

maintenance, logistic support - Collect, analyse, evaluate and use

performance & RAM statistics

- Undertake on going safety centred maintenance

- Perform on going safety performance monitoring and hazard log maintenance

- Collect, analyse, evaluate and use performance & safety statistics

12. Decommissioning - Plan decommissioning and disposal - Undertake decommissioning - Undertake disposal

- No activity for RAM - Establish safety plan - Perform hazard analysis & risk assessment - Implement safety plan

1726 NOTE 1 Change control or configuration management activity applies to all project phases 1727

prEN 50126-1 - 48 -

NOTE 2 Verification and validation activities apply within most life-cycle phases and are included in the main text 1728

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 1729 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. 1730

NOTE 4 Activities within Phases 9 and 10 may be integrated, depending upon the application under consideration 1731

NOTE 5 The safety plan may be incorporated within an overall RAMS plan. 1732

- 49 - prEN 50126-1

7.3 Application and tailoring of this standard 1733

7.3.1 This subclause gives requirements to provide a flexible and effective application of this 1734 standard in terms of size, complexity and cost. 1735

7.3.2 The requirements defined in this standard are generic and are applicable to all types of 1736 systems in the railway domain. The railway duty holder shall define the application of the 1737 requirements of this standard to the system under consideration. This definition shall be based 1738 on the applicability of the requirements to the particular system. 1739

7.3.3 In cases of renewal of a system, there is often a "mixed phase" stage where the 1740 operation with the existing and the renewed systems is mixed, or that they are operated at the 1741 same time. In such cases the possible effects of interaction between the existing and the 1742 renewed systems shall be specifically addressed. 1743

7.3.4 A life-cycle model for the development of the system product or process shall be 1744 selected. The life-cycle model shall take into account the possibility of iterations in and between 1745 phases. 1746

7.3.5 The application of this standard shall be tailored to the specific requirements of the 1747 system under consideration. This tailoring should consider the following aspects: 1748

a) constraints given by the railway duty holder; 1749

b) complexity of the system under consideration; 1750

c) the application domain (e.g. signalling, rolling stock, fixed installations); 1751

d) the system development process used; 1752

e) type of development (e.g. generic product, specific application, modification of existing 1753 system). 1754

7.3.6 In case of tailoring the following specifications and justifications shall be elaborated: 1755

a) specify the life-cycle phases which are required to realise the system under 1756 consideration, providing a justification for the life-cycle phases specified and 1757 demonstrating that the tasks undertaken within these life-cycle phases comply with the 1758 principles of the requirements of this standard; 1759

b) specify the life-cycle phases which are not required to realise the system under 1760 consideration and provide an appropriate justification; 1761

c) specify the mandatory activities and requirements of each required life-cycle phase, 1762 using Table 1 and the relevant phase related information of clause 8 RAMS life-cycle as 1763 a checklist, including: 1764

the scope of each requirement in relation to the system under consideration; 1765

the methods, tools and techniques required against each requirement and the scope 1766 and depth of their application; 1767

the verification and validation activities required against each requirement and the 1768 scope of their application; 1769

all supporting documentation. 1770

d) justify any deviation from the activities and requirements of the standard; 1771

e) justify the adequacy of the tasks chosen for the application under consideration; 1772

7.3.7 Even in case of tailoring the following requirements shall be always mandatory: 1773

a) responsibilities for carrying out RAMS tasks including the interfaces between associated 1774 tasks shall be defined for the system under consideration; 1775

b) all personnel with responsibilities within the RAMS management process shall be 1776 competent for those responsibilities; 1777

c) the establishment and implementation of the RAM Plan and Safety Plan are essential 1778 components in the realisation of dependable systems; 1779

prEN 50126-1 - 50 -

d) the RAMS requirements shall be implemented within business processes, supported by a 1780 Quality Management System (QMS) compliant with EN ISO 9001 and appropriate for the 1781 system under consideration; 1782

e) an adequate configuration management system, addressing RAMS tasks, shall be used. 1783 The scope of configuration management will depend on the system under consideration, 1784 but shall at least include all system documentation and all other system deliverables. 1785

7.3.7.1 Mutual recognition (sometimes referred to as cross acceptance) is considered as a 1786 special case of tailoring. The legal aspects which are implied in this topic have to be dealt with 1787 by the legal framework and are not subject of this standard. In order to reuse existing results 1788 and documents compliant with this standard that have been created in other developments the 1789 tailoring discussed above can avoid repetition of processes/tasks. Nevertheless, the following 1790 principles should be addressed: 1791

a) Establish a credible case for the native (baseline) application; 1792

b) Specify the target environment and application; 1793

c) Identify the key differences between the target and native cases; 1794

d) Specify the technical, operational and procedural adaptations required to cater for the 1795 differences; 1796

e) Assess the risks arising from the differences; 1797

f) Produce a credible case for the adaptations adequately controlling the risks arising from 1798 the differences; 1799

g) Develop a generic or specific case for mutual recognition. 1800

7.4 General requirements on RAMS documentation 1801

The documentation shall record all information relevant to RAMS throughout the life-cycle of the 1802 product. 1803

7.4.1 A process for the maintenance of safety-related documentation shall be defined or 1804 referenced in the safety plan. 1805

7.4.2 For each document, traceability shall be provided in terms of a unique reference 1806 number and a defined and documented relationship with other documents. 1807

7.4.3 Each RAMS document and deliverable shall be placed under configuration control from 1808 the time of its first release. 1809

7.4.4 Any changes to documents under configuration control shall be authorized and 1810 recorded. 1811

7.4.5 Each term, acronym or abbreviation shall have the same meaning in every document. 1812 If this is not possible (e.g. due to historical reasons), the different meanings shall be listed and 1813 the references given. 1814

7.4.6 If documents have a hierarchical relationship, the following requirements shall apply 1815

a) Each document shall contain or implement all applicable conditions and requirements of 1816 the preceding document with which it has a hierarchical relationship; 1817

b) There shall be no contradictions to the preceding document. 1818 NOTE Cascading of references increases complexity of verification and validation. 1819

7.4.7 If documents from pre-existing systems, products or processes do not fulfil this sub-1820 clause it still has to be ensured that these documents are adequately linked to the new 1821 documentation, including applicable conditions. Any contradictions have to be addressed and 1822 the priority level of the documents used to be indicated. 1823

7.4.8 The contents of all documents shall be recorded in a form appropriate for 1824 manipulation, processing and storage. 1825

- 51 - prEN 50126-1

7.4.9 When documents which are produced by independent roles are combined into a single 1826 document, the relation to the parts produced by any independent role shall be traced within the 1827 document. 1828

7.4.10 Documents may be combined or divided in accordance with 7.4.9. Where any 1829 alternative life-cycle or documentation structure is adopted it shall be established that it meets 1830 all the objectives and requirements of this European Standard. 1831

7.4.11 Large volumes of detailed information and supporting documentation need not be 1832 included in the RAMS documents, provided precise references are given to such documents and 1833 provided the basic concepts used and the approaches taken are clearly specified. 1834

7.4.12 In this standard, some documents are mentioned several times in the life-cycle 1835 description. This is meant to emphasize that an update of the document might be necessary 1836 depending on the outcome of the respective life-cycle phase. There is no need to produce 1837 separate versions of the document in every instance. 1838

8 RAMS life-cycle 1839

8.1 General 1840

8.1.1 This clause details objectives, requirements, deliverables and verification & validation 1841 activities to be undertaken throughout each life-cycle phase. Methods, tools and techniques 1842 appropriate to engineering dependable systems are presented in other standards (see 1843 Annex A). The scope and application of the requirements shall be assessed and adapted to 1844 meet the particular requirements of the system under consideration. For further information on 1845 this topic, see 7.3 of this standard. 1846

8.1.2 Generally, the input to each life-cycle phase shall include all relevant information, and 1847 where appropriate, data, necessary to meet the requirements of the phase. 1848

8.1.3 In case of redesign, retrofit or modification all RAMS implications shall be identified. 1849 An impact analysis shall be undertaken in order to decide which parts of the life-cycle shall be 1850 executed. 1851 NOTE The life-cycle can be simplified (by tailoring) since a variety of processes and documents can be reused and 1852 the activities can focus on the deviations to the original system. 1853

1854

1855

8.2 Phase 1: concept 1856

8.2.1 Objectives 1857

The objective of this phase is to develop a sufficient understanding of the system to ensure a 1858 proper performance of all subsequent RAMS life-cycle tasks. 1859

8.2.2 Activities 1860

8.2.2.1 In the context of RAMS performance, the following issues shall be investigated 1861

a) the scope, context and purpose of the system; 1862

b) the environment of the system, including: 1863

physical issues; 1864

potential system interface issues; 1865

social issues; 1866

political issues; 1867

legislative issues; 1868

economical issues. 1869

c) the general RAMS implications of the system. 1870

prEN 50126-1 - 52 -

8.2.2.2 The following issues shall be investigated: 1871

a) previous RAMS requirements and past RAMS performance of similar and/or related 1872 systems; 1873

b) current RAMS policy and targets of the relevant railway duty holders; 1874

c) safety legislation. 1875

8.2.2.3 The scope of the RAMS management requirements for subsequent system life-cycle 1876 RAMS tasks shall be defined. 1877

8.2.3 Deliverables 1878

8.2.3.1 The results of the activities of this phase shall be documented in a concept. This concept 1879 shall include any assumptions and justifications made during this phase. 1880

8.2.3.2 The deliverables shall include the definition of the scope of the RAMS management 1881 requirements. 1882

8.2.4 Specific verification tasks 1883

There are no specific verification requirements for this life-cycle phase in addition to those tasks 1884 required in 7.2.14. 1885

8.2.5 Specific validation tasks 1886

The following validation task shall be undertaken within this phase in addition to those tasks 1887 required in 7.2.8: 1888

- assessment of the adequacy of the system scope and environment statement. 1889

1890

1891

8.3 Phase 2: system definition and operational context 1892


The objectives of this phase are to: 1894

a) define the system and its mission profile; 1895

b) define the boundary of the system; 1896

c) establish the operational requirements influencing the characteristics of the system; 1897

d) define the scope of system risk analysis; 1898

e) establish the RAM plan for the system; 1899

f) establish the Safety plan for the System; 1900

g) define the functions to be provided by the system; 1901

as far as they affect the potential RAMS performance of the system. 1902


8.3.2.1 The following issues shall be defined: 1904

a) the system and its mission profile, including: 1905

description of the intended system; 1906

long term operating strategy and conditions; 1907

long term maintenance strategy and conditions; 1908

system life-time considerations; 1909

logistic considerations. 1910

b) the system boundary, including: 1911

- 53 - prEN 50126-1

interfaces with physical environment (e.g. climatic conditions, mechanical conditions. 1912 altitude); 1913

interfaces with other technological systems; 1914

interfaces with humans; 1915

interfaces with other railway duty holders; 1916

interfaces with existing infrastructure. 1917

c) the scope of operational requirements influencing the system, including: 1918

constraints imposed by existing infrastructure; 1919

system operating conditions and constraints; 1920

system maintenance conditions; 1921

logistic support considerations; 1922

review of past experience data for similar systems. 1923 8.3.2.2 A RAMS policy shall be established which shall include a policy for resolving conflicts 1924 between safety and other aspects like availability, reliability etc. 1925

8.3.2.3 An organisation shall be established which shall allocate the roles, responsibilities, 1926 competencies, independencies and relationships of organisations undertaking RAMS tasks 1927 within the life-cycle process. This shall also serve to resolve conflicts as indicated above. 1928

8.3.2.4 A process for on-going consideration of safety issues and the communication of relevant 1929 knowledge between the stakeholders has to be established. This includes the review of the 1930 adequacy of the safety requirements if new findings call for reconsiderations. 1931

8.3.2.5 The RAM plan for the remaining life-cycle tasks shall be established. The RAM plan shall 1932 include the tasks which are judged to be the most effective to the attainment of the RAM 1933 requirements for the system under consideration. The RAM plan shall be agreed by the railway 1934 duty holder and the railway suppliers for the system under consideration and shall be 1935 implemented throughout the life-cycle of the system. The RAM plan shall arrange the 1936 management to achieve the RAM requirements. This includes details of the policy and strategy 1937 to be applied, the scope of the plan and the planning of the RAM activities. 1938

8.3.2.6 The RAM plan should include the following tasks: 1939

a) management, including details of: 1940

the system life-cycle and RAM tasks and processes to be undertaken within the life-1941 cycle, specifically the order of RAM tasks to ensure maximum benefit to system 1942 design; 1943

a Failure Reporting Analysis and Corrective Action System (FRACAS) to be applied to 1944 the system from phase 7 of the life-cycle (by the railway duty holder and the railway 1945 suppliers, as appropriate) with records including: 1946

technical data on system; 1947

reason for maintenance action; 1948

type of maintenance action; 1949

man-hours & elapsed time for maintenance action; 1950

maintenance down time; 1951

number and skill level of personnel; 1952

spare parts used; 1953

cost of consumables; 1954

reporting and corrective action. 1955

the arrangements to ensure co-ordination of individual RAM elements; 1956

details of all RAM related deliverables from the life-cycle; 1957

details of RAM acceptance tasks; 1958

interfaces with other related programmes and plans; 1959

prEN 50126-1 - 54 -

constraints and assumptions made in the RAM plan; 1960

subcontractor management arrangements. 1961

b) reliability, including: 1962

reliability analysis and prediction, including: 1963

functional analysis and system failure definition; 1964

top down analysis, for example fault tree analysis and block diagram analysis; 1965

bottom up analysis, for example Failure Modes Effects Analysis (FMEA); 1966

common cause failure or multiple failure analysis; 1967

sensitivity analysis and trade-off studies; 1968

reliability apportionment; 1969

human machine interface analysis; 1970

stress analysis. 1971

reliability planning, including: 1972

reliability design review programme; 1973

component reliability assurance programme; 1974

software quality/reliability assurance programme. 1975

reliability testing, including: 1976

reliability growth testing, based on failure generation; 1977

reliability demonstration testing, based on expected failure modes; 1978

environmental stress screening; 1979

life testing of components; 1980

system life testing during early operation. 1981

reliability data acquisition and assessment: 1982

data analysis for reliability improvement. 1983

c) maintainability, including: 1984

maintainability analysis and prediction, including: 1985

maintainability analysis and verification; 1986

maintenance task analysis; 1987

ease-of-maintenance studies and testing; 1988

human factors maintainability considerations. 1989

maintainability planning, including: 1990

maintainability design review programme; 1991

establishment of the maintenance strategy; 1992

review of reliability centred maintenance options; 1993

software maintenance programme. 1994

logistic support evaluation including: 1995

definition of maintenance requirements; 1996

definition of spares policy and support resource; 1997

maintenance personnel and facilities; 1998

personnel safety precautions; 1999

system support requirements; 2000

training programme requirements; 2001

system transportation, packaging, handling and storage conditions. 2002

- 55 - prEN 50126-1

maintainability data acquisition and assessment; 2003

data analysis for maintainability improvement. 2004

d) availability, including: 2005

availability analysis; 2006

sensitivity analysis and trade-off studies; 2007

availability demonstration during early operation; 2008

availability data acquisition and assessment; 2009

data analysis for availability improvement and prediction. 2010 NOTE The RAM plan is considered as a living document. If some contents from the above list is not be fully available 2011 in this early life-cycle phase, this information can be added in later life-cycle phases. 2012

8.3.2.7 The Safety Plan for the system shall be established. The Safety Plan shall be 2013 implemented, reviewed and maintained throughout the life-cycle of the system. The Safety Plan 2014 shall arrange the following safety activities: 2015

a) establish the policy and strategy for achieving safety; 2016

b) define the scope of the plan; 2017

c) plan safety activities. 2018

8.3.2.8 The safety plan should include the following tasks: 2019

a) the safety analysis, engineering and assessment processes to be applied during the life-2020 cycle, including processes for: 2021

ensuring an appropriate degree of personnel independence in tasks, commensurate 2022 with the risk of the system; 2023

hazard identification and analysis; 2024

risk assessment and on-going risk management; 2025

risk acceptance criteria and reviewing risk acceptance; 2026

reviewing the effectiveness of risk reduction measures; 2027

the establishment and on-going review of the adequacy of the safety requirements; 2028

system design; 2029

verification; 2030

validation to achieve compliance between system requirements and realisation; 2031

achievement of compliance of the management process with the safety plan (e.g. 2032 confirmed via audits); 2033

safety assurance during the parameterisation of the system (safety classification of 2034 the configuration parameters, safety confidence in the parameterisation process and 2035 tools used). 2036

b) details of all safety-related deliverables from the life-cycle phases, including: 2037

documentation; 2038

hardware; 2039

software. 2040

c) a process to prepare the safety case, considering the hierarchy between system safety 2041 activities and documentation; 2042

d) a process for the safety approval of the system including the interface to the railway duty 2043 holder and the safety authority; 2044

e) a process for analysing operation and maintenance performance to ensure that realised 2045 safety is compliant with requirements; 2046

f) a process for the maintenance of safety-related documentation; 2047

g) a process for management of the hazard log; 2048

prEN 50126-1 - 56 -

h) interfaces with other related programmes and plans; 2049

i) constraints and assumptions made in the plan; 2050

j) subcontractor management arrangements including the identification of the parts of 2051 EN 50126 for which the subcontractor is responsible; 2052

k) requirements for periodic safety audit, safety assessment and safety review, throughout 2053 the life-cycle and appropriate to the safety relevance of the system under consideration, 2054 including any personnel independence requirements. 2055

NOTE The Safety plan is considered as a living document. If some contents from the above list are not fully available 2056 in this early life-cycle phase or changes in a later life-cycle phase, this information can be added in later life-cycle 2057 phases. 2058

8.3.2.9 Annex A of this standard provides an example outline procedure for the definition of a 2059 RAM/safety plan, based on the requirements of this standard. Annex A is informative and for 2060 guidance only and has been populated using rolling stock as an example. 2061


8.3.3.1 The results of this phase shall be documented in an appropriate way, including: 2063

a) a system definition; 2064

b) a RAM plan; 2065

c) a safety plan. 2066

8.3.3.2 This documentation shall include any assumptions and justifications made during this 2067 phase. 2068




There are no specific validation requirements for this life-cycle phase in addition to those tasks 2073 required in 7.2.8. 2074

2075

2076

8.4 Phase 3: risk analysis and evaluation 2077



a) identify hazards associated with the system; 2080

b) identify the events leading to the hazards; 2081

c) determine the risk associated with the hazards; 2082

d) establish a process for on-going risk management. 2083

For the reason of simplification the life-cycle representation in this standard shows risk analysis 2084 as a one time activity in the early stage of a project. At this stage, for some aspects of the risk 2085 analysis only estimations can be made because the detailed design of the product, system or 2086 process is not yet available and analysed. This early risk analysis serves as a basis for defining 2087 the risk based RAMS requirements (see phase 4 of the life-cycle). 2088

Afterwards, an on-going risk management is required in order to make sure that the final 2089 system, product or process fulfils its safety requirements. 2090

- 57 - prEN 50126-1


8.4.2.1 Risk evaluation and acceptance criteria to be applied shall be defined on the basis of the 2092 system definition (phase 2) in accordance with the requirements on risk analysis and evaluation 2093 given in EN 50126-2. This includes to determine the risk acceptance principles to be applied: 2094

a) use of code of practice; 2095

b) use of a similar system as a reference; 2096

c) explicit risk estimation (qualitative or quantitative). 2097 NOTE 1 Detailed requirements and guidance on the use of these risk acceptance principles can be found in clause 9 2098 and in EN 50126-2. 2099

NOTE 2 Different risk acceptance principles can be chosen for each hazard depending on their relevance. 2100

8.4.2.2 All reasonably foreseeable hazards associated with the system in its application 2101 environment shall be systematically identified. This activity should include hazards arising from: 2102

a) system normal operation; 2103

b) system fault conditions; 2104

c) system emergency operation; 2105

d) foreseeable system misuse; 2106

e) system interfaces; 2107

f) system functionality; 2108

g) system configuration parameters; 2109

h) system operation, maintenance and support issues; 2110

i) system disposal considerations; 2111

j) human factors; 2112

k) occupational health issues; 2113

l) mechanical environment; 2114

m) electrical environment; 2115

n) natural environment to cover such matters as snow, floods, storms, rain, landslides etc. 2116

8.4.2.3 For the purpose of hazard identification it is beneficial to use a structured list of hazards. 2117 This list serves as a basis and is non-exhaustive. If used it shall be checked against the 2118 application and amended if necessary. Refer to Annex C for example hazard lists. 2119

8.4.2.4 The sequence of events leading to hazards shall be identified. 2120

8.4.2.5 The frequency of occurrence of each hazard and the frequency of occurrence of the 2121 expected consequences shall be evaluated in accordance with the defined risk evaluation 2122 criteria. 2123

8.4.2.6 The likely severity of the consequences of each hazard shall be evaluated in accordance 2124 with the defined criteria. 2125

8.4.2.7 The risk to the system for each hazard shall be evaluated against the previously defined 2126 risk evaluation and acceptance criteria. 2127

8.4.2.8 The identified hazards shall be classified according to the estimated risk arising from 2128 them. The acceptability of the risk shall be determined, having considered the risk in terms of 2129 any conflicts with availability and life-cycle cost requirements of the system. 2130

8.4.2.9 Hazards associated with a broadly accepted risk need not be analysed further but shall 2131 be registered in the hazard log. 2132

NOTE Risks can be described as broadly accepted when they are comparable to risks that people regard as 2133 insignificant or trivial in their daily lives. They are typical of the risk from activities that are inherently not very 2134 hazardous. By its nature, what is called broadly accepted depends on the perception of society and therefore can not 2135 be considered to be constant. 2136

prEN 50126-1 - 58 -

8.4.2.10 A hazard log shall be established as the basis for on-going risk management. It 2137 represents a tool to track hazards and their close out. The hazard log shall be updated, 2138 whenever a change to identified hazards occurs or a new hazard is identified, throughout the 2139 life-cycle. The hazard log shall include or refer to details of: 2140

a) the aim and its purpose; 2141

b) each hazard, its responsibles for managing the hazard and the contributing functions or 2142 components; 2143

c) likely consequences and frequencies of the sequence of events associated with each 2144 hazard; 2145

d) the risk arising from the consequences of each hazard (in quantitative or qualitative 2146 terms); 2147

e) risk acceptance principles selected and in case of explicit risk estimation also the risk 2148 acceptance criteria to demonstrate the acceptability of the risk control related to the 2149 hazards; 2150

f) for each hazard: the measures taken to reduce risks to a tolerable level or to remove the 2151 risks, including evidence that the measures are effectively implemented; 2152

g) exported safety constraints. 2153

8.4.2.11 There may be several types of hazard logs; e.g. internal ones (for managing the 2154 company’s internal processes) and external ones, called hazard record. A hazard record is an 2155 extract of the hazard log that is suitable for transferring information between stakeholders. It 2156 aims to inform other stakeholders about the relevant safety aspects at the interfaces to their 2157 systems or subsystems and about hazards which cannot be controlled by one stakeholder 2158 alone. 2159

8.4.2.12 A hazard record shall provide an extract of the exported safety constraints from the 2160 hazard log, including the entities responsible for their implementation 2161

8.4.2.13 Any analyses produced during the process should include or refer to: 2162

a) the limits of any analysis carried out; 2163

b) assumptions made during the analysis; 2164

c) confidence limits applying to data used within the analysis; 2165

d) the methods, tool and techniques used. 2166



a) the risk analysis; 2169

b) the hazard log; 2170

c) updated safety plan (if appropriate); 2171

d) updated RAM plan (if appropriate). 2172





8.4.5.1 The following validation task shall be undertaken within this phase in addition to those 2179 tasks required in 7.2.8: 2180

a) assessment of the risk acceptability classification; 2181

- 59 - prEN 50126-1

b) assessment of the suitability of the hazard log process for the system under 2182 consideration. 2183

2184

2185

8.5 Phase 4: specification of system requirements 2186



a) specify the overall RAMS requirements for the system; 2189

b) specify the overall demonstration and criteria for acceptance for RAMS for the system; 2190

c) provide a comprehensive and identified set of requirements for the subsequent phases; 2191

d) specify necessary monitoring requirements (that enable the system to perform the 2192 required tasks in phase 11). 2193


8.5.2.1 The overall RAMS requirements for the system shall be specified on the basis of the 2195 system definition of section 8.3 and the risk analysis and evaluation of section 8.4 taking into 2196 account the results of sub-clause 7.2.3. The RAMS Requirements, for the system under 2197 consideration, shall include: 2198

a) functional requirements and supporting performance requirements, including safety ; 2199

b) functional requirements and safety integrity requirements for each safety-related 2200 function; 2201

c) logistic support requirements; 2202

d) interfaces; 2203

e) application environment and mission profile; 2204

f) tolerable risk levels for the consequences arising from the identified hazards; 2205

g) external measures necessary to achieve the requirements; 2206

h) system support requirements; 2207

i) details of the limits of the analysis; 2208

j) details of any assumptions made; 2209

k) identification of technology related standards; 2210

l) scope of diagnosis and monitoring. 2211

8.5.2.2 The requirements should be expressed and structured in such a way that: 2212

a) they are complete, precise, unambiguous, verifiable, testable and maintainable; 2213

b) they are written to aid comprehension by those who are likely to utilise the information at 2214 any stage of the system life-cycle; 2215

c) they are expressed in natural or formal language and/or logic, sequence or cause and 2216 effect diagrams. The requirements should define the necessary functions with each 2217 function being individually defined; 2218

d) the defined set of requirements is suitable to define a system that is fit for the intended 2219 purpose. 2220

8.5.2.3 The overall requirements for achieving compliance with RAMS requirements for the 2221 system shall be specified, including 2222

a) acceptance criteria for the overall RAMS requirements; 2223

b) a demonstration and acceptance process for the overall RAMS requirements facilitated 2224 by the system RAMS validation plan. 2225

prEN 50126-1 - 60 -

8.5.2.4 A RAMS validation plan shall be established. This RAMS validation plan should include: 2226

a) identification of the system, product or process subject to validation; 2227

b) identification of the steps necessary to demonstrate the adequacy of the deliverables of 2228 each phase of the system, product or process to be validated, in fulfilling the specified 2229 requirements; 2230

c) identification of the steps necessary to demonstrate the adequacy of planned testing 2231 activities against the specified requirements; 2232

d) justification of the validation and testing strategy under consideration of the required 2233 safety integrity; 2234

e) the RAMS tests and analysis to be carried out for the validation including details of the 2235 required environment, tools, facilities etc.; 2236

f) the validation management structure including requirements for personnel independence; 2237

g) procedures for dealing with non-compliance. 2238

8.5.2.5 The Safety Plan and the RAM plan shall be updated (if appropriate) to ensure that all 2239 planned tasks are consistent with the system’s emergent RAMS requirements. 2240



a) the RAMS requirement specification; 2243

b) the RAMS validation plan; 2244

c) updated safety plan (if appropriate); 2245

d) updated RAM plan (if appropriate). 2246





8.5.5.1 The following validation tasks shall be undertaken within this phase in addition to those 2253 tasks required in 7.2.8: 2254

a) A RAMS validation plan shall be established according to chapter 8.5.2.4; 2255

b) validation of the safety requirements against any safety targets and safety policies; 2256

c) validation of the RAM requirements against any RAM targets and RAM policies of the 2257 railway duty holders. 2258

2259

2260

8.6 Phase 5: architecture and apportionment of system requirements 2261



a) design sub-systems and components that work together as a system which fulfils the 2264 required functions; 2265

b) describe the RAMS requirements and specify the interfaces for all sub-systems and 2266 components derived from the RAMS requirements (which prepares later integration 2267 activities); 2268

- 61 - prEN 50126-1

c) apportion the system RAMS requirements to the designated sub-systems and/or 2269 components; 2270

d) define the acceptance criteria to demonstrate fulfilment of the RAMS requirements for the 2271 designated sub-systems and/or components in subsequent phases; 2272

e) identify and evaluate the significance of the interactions between the sub-systems. 2273 NOTE Interactions can be defined at different abstraction levels. Such interactions should be described in 2274 interface specifications. 2275


8.6.2.1 A system architecture shall be developed and defined that fulfils the RAMS 2277 requirements. The architecture shall be based on a structured decomposition into sub-systems 2278 and/or components with completely defined interfaces between the sub-systems and/or 2279 components. For each subsystem or component a set of RAMS requirements shall be allocated 2280 which is derived from the system requirements and from a design in sufficient depth. To achieve 2281 this, a structured design methodology shall be applied. 2282

NOTE The system architecture should be expressed and structured in a way that it is clear, precise, unambiguous, 2283 verifiable, testable, maintainable and feasible. It should aid the comprehension by those who are likely to utilise the 2284 information at any phase of the life-cycle; and be traceable to the system requirement. 2285

8.6.2.2 Particular attention is required for the specification of RAMS requirements for the control 2286 of interfaces where safe and reliable interaction may be compromised. Constraints on the choice 2287 of technology (i.e. independence of functions or processes of development) shall be identified. 2288 All safety relevant assumptions made during the development of the system architecture shall 2289 be specified and documented. 2290

8.6.2.3 The designated sub-systems and/or components shall be specified to achieve the 2291 system RAMS requirements, including the impact of common cause and multiple failures. For 2292 the concept of taking precautions see also chapter 6.7.1. 2293

8.6.2.4 If new hazards are identified arising from the architecture, requirements to control these 2294 hazards shall be derived from the new hazards and allocated to the related sub-systems and/or 2295 components. 2296

8.6.2.5 If pre-existing sub-systems and/or components are used to fulfil system requirements it 2297 shall be ensured additionally that the requirements for integration of the pre-existing sub-2298 systems and/or components are clearly identified and fulfilled. 2299

8.6.2.6 In cases where safety-related functions are developed according to a code of practice, 2300 the relationship of these functions to the used code of practice shall be given and justified in the 2301 system architecture. 2302

NOTE The realisation of safety-related functions shall be performed in accordance with the related code of practice. 2303

8.6.2.7 Acceptance criteria, acceptance processes and procedures as well as demonstration for 2304 sub-systems and/or components including their interfaces shall be specified to ensure 2305 compliance with the sub-system and/or component requirements . 2306

8.6.2.8 The Safety Plan, RAM plan and the RAMS Validation Plan should be updated (if 2307 appropriate) to ensure that all planned tasks are consistent with the system’s emergent RAMS 2308 requirements following the apportionment. 2309

NOTE Key areas of concern include requirements for personnel independence and the control of system interfaces 2310 where safety functionality may be compromised. 2311



a) system architecture (structure of decomposition into subsystems etc.) including interface 2314 specifications and system hazard analysis (architecture and hazard analysis of 2315 subsystem and components); 2316

b) RAMS requirement specification for sub-systems and/or components; 2317

c) acceptance criteria and demonstration and acceptance processes and procedures; 2318

d) updated safety plan (if appropriate); 2319

prEN 50126-1 - 62 -

e) updated RAM plan (if appropriate); 2320

f) updated RAMS validation plan (if appropriate). 2321



There are no specific verification requirements for this phase in addition to those tasks required 2325 in 7.2.14. 2326



2330

2331

8.7 Phase 6: design and implementation 2332



a) create sub-systems and components conforming to RAMS requirements; 2335

b) demonstrate sub-systems and components conform to RAMS requirements; 2336

c) establish plans for future life-cycle tasks involving RAMS. 2337


8.7.2.1 The sub-systems and components shall be designed to meet the RAMS requirements. 2339

8.7.2.2 The design of the sub-systems and components shall be implemented to meet RAMS 2340 requirements. 2341

8.7.2.3 The RAMS tasks of further life-cycle phases shall be planned. These phases shall 2342 include: 2343

a) Integration; 2344

b) Operation and maintenance; 2345

c) Performance monitoring (if appropriate / contractually agreed). 2346

8.7.2.4 Operation and maintenance procedures shall be prepared. These procedures shall 2347 include all the relevant information for providing spare parts, particularly items in safety-related 2348 functions. 2349

8.7.2.5 Training measures for operation and maintenance staff including training material shall 2350 be defined. 2351

8.7.2.6 A manufacturing process capable of producing RAMS-validated sub-systems and 2352 components shall be defined and established. The following aspects should be considered: 2353

a) environmental stress screening; 2354

b) RAM improvement testing; 2355

c) inspection and testing for RAMS-related failure modes; 2356

d) activities, defined in the safety plan, which are relevant to this life-cycle phase. 2357

8.7.2.7 A process for the integration into the system capable of producing RAMS-validated sub-2358 systems and components shall be defined and established. The following aspects should be 2359 considered: 2360

a) measures to prevent installation errors; 2361

b) testability of installed sub-systems and components; 2362

- 63 - prEN 50126-1

c) activities, defined in the safety plan, which are relevant to this life-cycle phase. 2363

8.7.2.8 A safety case shall be prepared, justifying that the system, product or process, as 2364 designed, meets the safety requirements. The safety case may require acceptance by the 2365 railway duty holder or approval based on the legal framework. The contents and documentation 2366 structure of the safety case shall follow the requirements stated in sub-clause 10.3. 2367

8.7.2.9 A safety case shall be a generic product safety case, a generic application safety case 2368 or a specific application safety case as defined in sub-clause 10.2. The type(s) of safety case(s) 2369 prepared shall be suitable to meet the scope of the product, system or process. 2370

8.7.2.10 The RAMS Validation Plan shall be updated (if appropriate) to ensure that all planned 2371 tasks are consistent with the system’s emergent RAMS requirements following the design. 2372

8.7.2.11 Installation and commissioning procedures shall be prepared. 2373



a) plan(s) for further life-cycle tasks; 2376

b) operation and maintenance procedures; 2377

c) training measures; 2378

d) safety case(s); 2379

e) updated validation plan; 2380

f) updated hazard log. 2381

This documentation shall include any assumptions and justifications made during this phase. 2382

8.7.3.2 A record of all RAMS validation tasks undertaken within the phase shall be maintained 2383 following the requirements given in sub-clause 7.2.9. 2384


8.7.4.1 The following verification tasks shall be undertaken within this phase in addition to those 2386 tasks required in 7.2.14: 2387

a) verification that sub-system and component design complies with the RAMS 2388 requirements; 2389

b) verification that sub-systems and components implementation complies with designs; 2390

c) verification that the manufacturing arrangements produce RAMS-validated sub-systems 2391 and components; 2392

d) verification that all future life-cycle activity plans are consistent with RAMS requirements 2393 for the system. 2394

NOTE Verification is based on results of analyses and tests. 2395



2399

2400

8.8 Phase 7: manufacture 2401



a) manufacture the sub-systems and components; 2404

b) establish and apply RAMS-centred assurance arrangements. 2405

prEN 50126-1 - 64 -


8.8.2.1 The manufacturing process defined in phase 6 shall be implemented and operated. 2407

8.8.2.2 RAMS-centred assurance arrangements shall be established, including: 2408

a) quality assurance measures suitable to meet RAMS requirements; 2409

b) manufacturing process improvement and assurance measures as appropriate; 2410

c) environmental stress screening as appropriate; 2411

d) inspection and testing for RAMS-related failure modes; 2412

e) material handling and logistic arrangements suitable to meet RAMS requirements. 2413


8.8.3.1 The results of this phase shall be documented in an appropriate way, including RAMS 2415 related aspects of: 2416

a) quality assurance reports; 2417

b) inspection and testing reports; 2418

c) material handling and logistic arrangements; 2419

d) updated hazard log. 2420

This documentation shall include any assumptions and justifications made during this phase. 2421

8.8.3.2 A record of all RAMS validation tasks undertaken within the phase shall be maintained 2422 following the requirements given in sub-clause 7.2.9. 2423





2430

2431

8.9 Phase 8: integration 2432



a) assemble and install the total combination of sub-systems and components required to 2435 form the complete system; 2436

b) demonstrate that all subsystems and components work together as defined by the 2437 interfaces; 2438

c) demonstrate that all subsystems and components meet their RAMS requirements; 2439

d) initiate system support arrangements. 2440


8.9.2.1 The subsystems and components shall be integrated according to the integration 2442 planning and the fulfilment of the systems functionality as well as the specified RAMS 2443 requirements shall be demonstrated. The integrated system may have to be installed into a 2444 higher level system. Therefore, the requirements of this phase shall apply both to the integration 2445 of components and subsystems and to the incorporation of a system into the superordinate 2446 system. This could be regarded as a two-tiered integration for which similar activities apply. 2447

- 65 - prEN 50126-1

8.9.2.2 In case of modifications or changes are introduced to the integrated system during 2448 integration, an impact analysis of the system architecture from phase 5 shall be performed to 2449 ensure that the subsystems interact safely and perform the intended functions after the 2450 modification or change. On the basis of the impact analysis it shall be evaluated to which extent 2451 previous life-cycle activities should be repeated. 2452

8.9.2.3 The system shall be tested and analysed in accordance with the system integration 2453 planning. These tests and analyses shall show that all sub-systems and components of the 2454 system interact correctly as specified in the interface specifications to perform their intended 2455 function and do not perform unintended functions. 2456

NOTE For integration and integration tests for E/E/PE software, subsystems and components EN 50126-4 and 2457 EN 50126-5 are to be considered. 2458

8.9.2.4 During the integration of the sub-systems and components of the system the fulfilment of 2459 all application conditions defined for that subsystems and components shall be shown, this 2460 includes for subsystems developed according to a code of practice, the evidence for the 2461 conformance of the realisation according to the used code of practice. 2462

8.9.2.5 From all application conditions of the subsystems and components which can not be 2463 solved during the integration the application conditions for the integrated system shall be 2464 derived. 2465

8.9.2.6 The system support arrangements shall be initiated, including: 2466

a) start staff training; 2467

b) make system support procedures available; 2468

c) establish spare parts provision; 2469

d) establish tool provision. 2470



a) installation documentation; 2473

b) action taken to resolve failures and incompatibilities; 2474

c) system support arrangements. 2475

This documentation shall include assumptions and justifications made during this phase. 2476

8.9.3.2 A record of all RAMS validation tasks undertaken within the phase, including the 2477 installation activity, shall be maintained following the requirements given in sub-clause 7.2.10. 2478


There are no specific verification requirements for this phase to those tasks required in 7.2.14. 2480



2484

2485

8.10 Phase 9: system validation 2486


8.10.1.1 The objectives of this phase are to: 2488

a) validate that the system, product or process in combination with its application conditions 2489 complies with the RAMS requirements; 2490

b) confirm or update the safety case for the system, product or process appropriate to the 2491 results of the validation; 2492

prEN 50126-1 - 66 -

c) prepare the acquisition and assessment of operational data. 2493


8.10.2.1 The system, product or process shall be validated according to the RAMS validation 2495 plan considering external risk reduction measures. 2496

8.10.2.2 A probationary period of operation may be undertaken, to resolve potential in-service 2497 system problems. In this case, the need for demonstrating system safety shall be considered 2498 prior to the probationary operation and the entry into revenue service. 2499

8.10.2.3 The Hazard Log shall be reviewed and updated to record any residual hazards 2500 identified during system validation and to ensure that the risks from any such hazards are 2501 effectively managed. 2502

8.10.2.4 The safety plan shall be reviewed with regard to its continued applicability. Any 2503 deviations shall be justified and documented. 2504

8.10.2.5 The safety case for the system, product or process shall be updated. The safety case 2505 shall justify, that the system, product or process, as specifically applied within this application, 2506 complies with the system safety requirements. 2507

8.10.2.6 A process for the acquisition and assessment of operational data and maintenance 2508 data shall be established and implemented as an input to a system improvement process. 2509

8.10.2.7 The adequacy of the impact analysis from sub-clause 8.9.2.2 shall be evaluated. 2510



a) details of RAMS validation tasks against acceptance criteria, including RAM 2513 demonstrations and safety analysis following the requirements given in sub-clause 7.2.9; 2514

b) details of process, tools, equipment used for validation tasks against acceptance criteria; 2515

c) results of validation tasks for all acceptance criteria; 2516

e) problem reporting and assessment tasks; 2517

f) any limitations and constraints applying to the system; 2518

g) action taken to resolve failures and incompatibilities; 2519

h) updated hazard log; 2520

i) updated safety plan (if appropriate); 2521

j) updated safety case; 2522

k) process for the acquisition and assessment of operational data. 2523



8.10.4.1 The following verification tasks shall be undertaken within this phase in addition to 2526 those tasks required in 7.2.14: 2527

a) verification that the commissioning activity was carried out in accordance with the 2528 Commissioning Plan; 2529

b) verification of the adequacy and effectiveness of the operational data collection system. 2530



2534

2535

- 67 - prEN 50126-1

8.11 Phase 10: system acceptance 2536



a) assess compliance of the total combination of sub-systems, components, their interfaces 2539 and application conditions with the overall RAMS requirements; 2540

b) accept the system for entry into service. 2541 NOTE In this European standard, the term system acceptance is used only for technical aspects of the acceptance 2542 procedure. Legal aspects of the system acceptance are not considered in this standard. It is recommended to clarify 2543 the legal aspects of system acceptance between the customer and the supplier in advance. 2544


8.11.2.1 All system verification and validation tasks, specifically the RAMS verification & 2546 validation and the safety case, shall be assessed in accordance with the defined acceptance 2547 criteria. 2548

8.11.2.2 The results of this assessment shall be recorded in an acceptance report. The 2549 acceptance report should include a confirmation that the delivered product, system or process is 2550 fit for entry into service. 2551

8.11.2.3 The following tasks shall be undertaken by the entity which is accepting the system 2552 (Railway Duty Holder or other): 2553

a) verification of the acceptance report with respect to the defined acceptance criteria; 2554

b) verification of the safety plan with regard to its continued applicability; 2555

c) verification of the updated hazard log. 2556



a) acceptance report. 2559

8.11.3.2 This documentation shall include assumptions and justifications made during this 2560 phase. 2561


There are no specific verification requirements for this phase in addition to those tasks required 2563 in 7.2.14 2564


There are no specific validation requirements for this phase. 2566

2567

2568

8.12 Phase 11: operation, maintenance and performance monitoring 2569


The objective of this phase is to operate, maintain and support the product, system or process 2571 such that compliance with RAMS requirements is maintained. This includes to continuously 2572 monitor and evaluate the RAMS performance of the system and to derive measures for 2573 addressing shortcomings and for achieving improvements. 2574


8.12.2.1 The operation and maintenance procedures shall be implemented, particularly with 2576 regard to system performance and life-cycle cost issues. This requires considering the product, 2577 system or process in its operational environment, e.g. including the application of external risk 2578 reduction measures. 2579

prEN 50126-1 - 68 -

8.12.2.2 Compliance with RAMS requirements shall be assured throughout this phase, by: 2580

a) regular review and update of operation and maintenance plans and procedures; 2581

b) conformity with operational plans and procedures; 2582

c) conformity with maintenance plans and procedures; 2583

d) regular review of system training documentation; 2584

e) regular review and update (if appropriate) of an operational Hazard Log; 2585

f) conformity with support agreements including logistics, spare parts, repairs, tools, 2586 calibration; 2587

g) maintenance of the failure reporting and corrective action system (FRACAS). 2588 NOTE The operational Hazard Log is based on the Hazard Record extracted from the Hazard Log resulting from 2589 phase 10. 2590

8.12.2.3 A process for: 2591

a) the acquisition of RAMS performance data; 2592

b) the analysis and evaluation of RAMS performance data; 2593

c) recording of RAMS performance data, associated analysis and evaluation as appropriate 2594 shall be implemented and maintained. 2595

8.12.2.4 A competence management system shall be put in place to evaluate, manage, assure 2596 and document the competence requirements of personnel. This shall include: 2597

a) Technical knowledge; 2598

b) Qualifications; 2599

c) Relevant experience; 2600

d) Training needs. 2601 NOTE Competence management helps to protect against systematic and deterministic errors being made during 2602 operation and maintenance which might lead to a safety-related incident or a service affecting availability failure. 2603

8.12.2.5 Throughout the operational lifetime the system baseline shall be recorded and kept 2604 traceable under configuration management control. 2605

NOTE This is of special importance when critical faults are discovered and need to be corrected in more than one 2606 installation. 2607

8.12.2.6 Anomalies or errors observed during deployment, operation and maintenance shall be 2608 recorded and evaluated against the required RAMS functions of the system. The evaluation 2609 should include a review of the following: 2610

a) Operation and maintenance procedures and manuals; 2611

b) System training documentation; 2612

c) Operational Hazard Log; 2613

d) System design; 2614

e) Human factors aspects of operation and maintenance. 2615

8.12.2.7 Based on the analysis and evaluation of RAMS performance recommendations shall 2616 be developed to assure or improve the RAMS performance. 2617

8.12.2.8 For each identified recommendation a decision shall be taken whether the 2618 recommendation shall be realised or not. These decisions shall be justified and recorded. 2619



a) updated system and support documentation, as appropriate, within this phase; 2622

b) records suitable to trace the RAMS tasks undertaken within this phase; 2623

c) reports of RAMS performance analyses and evaluations; 2624

- 69 - prEN 50126-1

d) identified recommendations and record of associated decisions; 2625

e) updated operational Hazard Log, if appropriate; 2626

f) updated Operation and Maintenance Plans and processes. 2627



There are no specific verification requirements for this life-cycle phase in addition to those tasks 2630 required in 7.2.14 2631



2634

2635

8.13 Phase 12: decommissioning 2636


The objective of this phase is to control RAMS implications of system decommissioning and 2638 disposal tasks. 2639


8.13.2.1 The RAMS impact of decommissioning and disposal on any relevant external system 2641 or facility shall be identified. 2642

8.13.2.2 The decommissioning shall be planned, including the establishment of procedures for: 2643

a) the safe closing down of the system; 2644

b) the safe dismantling of the system; 2645 NOTE As external systems or facilities may be affected, these systems or facilities may also need consideration. It 2646 shall be taken into account that the disposal may represent a modification of the external system or facility. 2647


The results of this phase shall be documented in an appropriate way. This documentation shall 2649 include any assumptions and justifications made during this phase. 2650


The following verification task shall be undertaken within this phase in addition to those tasks 2652 required in 7.2.14 2653



2656

2657

9 Risk assessment 2658

9.1 Scope 2659

9.1.1 Risk assessment comprises both risk analysis and risk evaluation 2660

9.1.2 Risk analysis is the systematic use of all available information to identify hazards and 2661 to estimate the risk. It is a very important step in the RAMS process based on the life-cycle. This 2662 subclause provides a methodology to support chapter 8.4. 2663

prEN 50126-1 - 70 -

9.1.3 Risk analysis shall be initially performed at phase 3 of the system life-cycle and 2664 continued as appropriate at various phases of the system life-cycle by the railway duty holder 2665 responsible for that phase and shall be documented. 2666

9.1.4 One of the outcomes of the risk analysis is to distinguish between the hazards which 2667 do not need to be analysed further from the hazards that needs to be further analysed. 2668

9.1.5 Risk evaluation consists of comparing the determined risk against the associated 2669 acceptance criteria and a judgement on the acceptance. 2670

9.1.6 Acceptance of risk depends on how a risk is perceived which, differs greatly between 2671 parties or people involved. The reasons being, prevailing social and cultural conditions, 2672 psychological and physical factors and also factors such as whether the risk is voluntary (e.g. 2673 self imposed) or involuntary (e.g. imposed by others) and whether it has large consequences 2674 feared by the society. Voluntary risk is generally better accepted than involuntary risk or where 2675 the person exposed to the risk does not have control over the risk. Such factors need to be 2676 taken into account for establishing risk acceptance criteria. 2677

9.2 Risk analysis methodology 2678

9.2.1 To produce a risk analysis, the following methodology should be applied: 2679

Risk analysis, using qualitative, quantitative or hybrid approaches, is a systematic and 2680 structured process for 2681

1. identifying the undesired events that may lead directly or indirectly to losses during the 2682 operation and maintenance of a system. In the context of railway operations, losses could 2683 mean harm to passengers, workers or members of the public, harm to the environment or 2684 losses related to RAMS; 2685

2. identifying the undesired events, i.e. the component, sub-system or system failures, physical 2686 effects, which, perhaps combined with human errors or operational conditions, can result in 2687 losses related to RAMS; 2688

3. identifying the control measures that are in place to control or limit the occurrence of each 2689 undesired event that cannot be eliminated; 2690

4. where appropriate, estimating the frequencies at which undesired events can occur and 2691 estimating the consequences that could occur for the different outcomes that may follow the 2692 occurrence of a loss. This would include identifying, where risk reduction is necessary and 2693 which control measures that have to be in place to control or limit 2694

the frequency of occurrence of each undesired event that cannot be eliminated after 2695 identification of causes and triggering event, and 2696

the consequences of the related losses. 2697

Triggering events shall be taken into account, because their impact can be very important on 2698 frequencies as well as on the severity of consequences. 2699 NOTE If feasible and practicable, the best approach to control a risk is elimination. However this often cannot be 2700 achieved and reduction of frequency of undesired events or their consequence shall be applied. 2701

5. determining, where necessary, the additional measures to apply that are required to ensure 2702 that the risk is mitigated to levels accepted within the applicable legal framework by the 2703 appropriate entity (e.g. it satisfies the defined risk acceptance criteria or legal requirements); 2704

6. providing clear and comprehensive documentary evidence of the methodologies, 2705 assumptions, data, judgments and interpretations used in carrying out the risk assessment. 2706

Details with regard to the use of a code of practice or use of a similar system as a reference can 2707 be found in EN 50126-2. 2708

9.2.2 Consequence analysis shall be used to estimate the impact given different scenarios 2709 (including different triggering events). 2710

- 71 - prEN 50126-1

9.2.3 To assess/estimate the risk of systems in a mathematical fashion based on 2711 dependable data is not always possible. Often the required information (i.e. data, causal 2712 connections as well as interrelations/interactions between the system’s constituents ...) is not 2713 fully available or known. Therefore a method known as expert judgement is an indispensable 2714 tool in the risk assessment process, but not only applicable here. In some cases the expert 2715 judgement can be the only approach if dependable data cannot be produced and in other cases 2716 it may simply be the best option. 2717

Even though it is a good way to make use of knowledge and experience, expert judgement is 2718 often mistrusted because it is basically subjective. 2719

9.2.4 To make it a credible basis for risk assessment expert judgement should be made 2720 more “objective”. This implies that 2721

the assessment/estimation should not be of the opinion of a single person. Agreement 2722 among several (independent) experts and approved knowledge enhances the confidence 2723 in an assessment; 2724

it shall be ensured that the “experts” have adequate knowledge of the area in question; 2725

all necessary areas of expertise (which can arrive at differing classifications) have to be 2726 included in the judgement. Aspects of skirting functions/systems can have an effect on 2727 the assessed system and may have to be regarded in more complex systems. Therefore 2728 the team has to be selected wide enough if a problem cannot be considered fully 2729 isolated; 2730

a clear understanding of the categories shall be provided to promote a common 2731 interpretation, if the expert judgement is applied to estimate the frequency and 2732 consequences of hazards or of accidents; 2733

documentation of the results of expert judgement is necessary to support objectivity and 2734 to ensure the transparency and plausibility of the conclusions. The documentation shall 2735 also enable further refinement should new information be available. 2736

9.2.5 The participants and their respective area of expertise should be recorded. Further 2737 information like references to publications, sources, assumptions, deliberately excluded aspects 2738 with justification, rationale of conclusion etc. should be recorded in order to demonstrate the 2739 integrity and enable third parties to trace the conclusion. 2740

9.2.6 For the purpose of classifying any events Table D.1 and Table D.2 in Annex D provide, 2741 in qualitative terms, typical categories of probability or frequency of occurrence of events and a 2742 typical description of each category for railways. Based on these typical categories, their 2743 numbers, and their numerical scaling (provided that numerical estimates are feasible) to be 2744 applied shall be defined by the railway duty holder, appropriate to the application under 2745 consideration. 2746

9.2.7 It is important to note, that given safety targets referring to frequency categories 2747 should be related to the item under consideration (an instance of the function or system under 2748 consideration), but not to the sum of items in use or intended to be used. In other words not to 2749 the “fleet” of them, but to the single instance of this function or system. Otherwise compliance to 2750 a safety objective could require revising a system in case additional identical equipment will be 2751 put into operation. 2752

Example: The frequency categories could apply to: 2753

a door system (per door); 2754

a brake system (per independent braking unit); 2755

a single signal; 2756

a main switch in a power supply station. 2757

It is important to note however that there can be different consequences when losing a single 2758 system, or multiple instances of the same system. In such case, safety requirements are to be 2759 achieved for all accident scenarios. 2760

prEN 50126-1 - 72 -

Example: 2761

A single door opening when the train is running might trigger a fatality. 2762

All doors opening when the train is running might however trigger multiple fatalities. 2763

This means that the overall control command function could have a more stringent safety target 2764 than the local function. 2765

9.2.8 Table D.4 and Table D.5 in Annex D describe typical severity levels and the associated 2766 consequences. The number of severity levels and the consequences for each severity level to 2767 be applied shall be defined by the railway duty holder, appropriate for the application under 2768 consideration. 2769

9.2.9 With regard to safety it is recommended that the relationship between injuries and 2770 fatalities (“equivalent fatalities” as defined in 3.22 , efat), for the purpose of predicting and 2771 comparison only, be agreed with the railway duty holder based on the relevant legal framework. 2772

9.2.10 Examples of such relationship may be: 2773 one equivalent fatality ≈ 1 fatality ≈ 10 major injuries ≈ 100 minor injuries or 2774

severe injuries and fatalities are fully equivalent or 2775

any other weighted equivalence. 2776

By nature, the use of equivalent fatalities (efat) for prediction can not provide any certainty. 2777

9.2.11 Considering safety, risk can be expressed in terms of collective risk or individual risk. 2778 Both terms are interrelated and can be converted to a certain extent. If quantified or semi-2779 quantified safety targets are given, in most cases they are expressed in terms of collective risk. 2780 In this subclause and the related annexes this applies as well. 2781

Examples: 2782

Collective risk: 8•10-5 fatalities/year - the risk of death for the collective taking part in national 2783 road traffic, e.g. 5000 fatalities within a collective of 60 Million within a period of one year 2784

Individual risk: x•10-y fatalities/(year and person) - the risk of death as a bus driver taking part in 2785 national road traffic each working day for one year 2786

9.2.12 Assessing risk does not necessarily imply considering worst-case scenarios. In other 2787 words, a hazard leading to an accident can have a variety of consequences with varying 2788 severity. This needs to be reflected in the risk analysis. One way for that is to conduct a 2789 consequence analysis, where the likeliness (not necessarily expressed quantitatively, can be 2790 purely qualitative) of each scenario will be identified 2791

9.2.13 One of the main methods is the use of a matrix for evaluation of the results of risk 2792 analysis, risk categorisation and deriving actions for risk reduction. 2793

9.2.14 The risk determined can be displayed by combining the frequency of occurrence of 2794 loss (e.g. accident) with its severity to establish the anticipated level of risk generated. A 2795 "frequency - severity" matrix is shown in Table 2. 2796

2797

Table 2 - Frequency - Severity Matrix 2798

Frequency of consequence

[frequency categories]

[Risk]

[severity categories]

Severity of consequence

2799

- 73 - prEN 50126-1

The axes of the matrix have to be calibrated and the judgement on calibration shall be 2800 documented. The calibration depends on the purpose of the application of the matrix. 2801

9.2.15 If an axis calibration scheme is given mandatory by law or safety authorities, it shall be 2802 used. If several matrixes on the same subject are used in parallel, their coherence should be 2803 ensured. 2804

9.3 Risk evaluation and acceptance 2805

9.3.1 Acceptance principles 2806

9.3.1.1 To evaluate the identified risks and to enable a decision on their acceptance, a risk 2807 acceptance principle shall be chosen. It indicates the type of argument which partially or fully 2808 shows that the respective hazard and the resulting risk are assured as being under control. The 2809 principle used should be chosen depending on the type of evidence to be provided. There are 2810 three principles mainly used and given in clause 8.4.2.1. 2811

9.3.1.2 In case the legal framework requires the risk analysis to be approved by a safety 2812 authority, the choice of the principles should be communicated to this authority at the earliest 2813 possible stage of the project. 2814

Existing applicable material can be reused, for example when tailoring the process. 2815

For details regarding these 3 principles please refer to chapter 8.5 in EN 50126-2 of this 2816 standard. 2817

9.3.2 Methods for determining risk acceptance criteria 2818

9.3.2.1 Once an acceptance principle is chosen, criteria should be determined in order to have a 2819 limit for deciding whether a risk is deemed acceptable or not. 2820

9.3.2.2 Risk acceptance should be based on generally accepted criteria. A number of methods 2821 for deriving them are available that may be utilised. Some examples are as follows: (Also see 2822 Annex B in EN 50126-2 for more information on these methods for deriving acceptance criteria) 2823

Risk Matrix; 2824

As Low As Reasonably Practicable (ALARP); 2825

Globalement Au Moins Equivalent (GAME) ; 2826

Minimum Endogenous Mortality (MEM). 2827

NOTE A calibrated Risk Matrix can be used to determine criteria for non-safety issues as well. 2828

Requirements can be given by legal obligations as well. 2829

9.3.2.3 One of the main methods is the use of a "frequency - consequence" matrix for risk 2830 acceptance. 2831

It can be performed by allocating appropriate acceptance criteria to an axes-calibrated risk 2832 matrix. This calibration with regard to risk acceptance shall be justified and documented. If an 2833 acceptance calibration scheme is given mandatory by the legal framework or safety authorities, 2834 it shall be used. Examples of risk acceptance categories and the actions to be applied against 2835 each category are given in Table D.7 and Table D.8 in Annex D. The allocation of such 2836 categories to a risk matrix is shown in Table D.9 in Annex D. 2837

9.3.2.4 Note that such matrices are more appropriate for risk ranking than for assessment. One 2838 of the essential preconditions for applying a matrix for risk assessment purposes it its calibration 2839 for the specific application. 2840

prEN 50126-1 - 74 -

10 Deliverables and structure of a safety case 2841

10.1 Purpose of a safety case 2842

10.1.1 A safety case is defined as a structured argument, supported by a body of evidence 2843 that provides a compelling, comprehensible and valid case that a system is safe for a given 2844 application in a given operating environment. It takes the form of structured safety justification 2845 documentation which sets out and explains the evidence for the safety of the system/sub-2846 system/equipment. This section is concerned with the documentary representation of that 2847 explanation and evidence. The techniques and processes involved in the demonstration of 2848 safety are already covered in chapters 7 and 8. 2849

10.1.2 All requirements derived from this clause are specified in clause 8 RAMS life-cycle. 2850

Further details concerning safety cases for E/E/PE systems may be found in EN 50126-4, and 2851 further details concerning safety cases for software may be found in EN 50126-5. 2852

10.2 Types of safety case 2853

10.2.1.1 Safety cases may vary in scope and purpose. It is common to produce separate 2854 product and application safety cases as described below, but where appropriate matters 2855 concerning both product and application safety may be included within the same safety case. 2856

Generic product safety case (independent of application): a generic product can be re-2857 used for different independent applications; 2858

Generic application safety case (for a class of application): a generic application can be 2859 re-used for a class/type of application with common functions; 2860

Specific application safety case (for a specific application): a specific application is used 2861 for only one particular instance. 2862

It is essential to demonstrate for each “specific” application that the environmental conditions 2863 and context of use, including maintenance arrangements, are compatible with the “generic” 2864 application conditions. 2865

The way in which these types of safety case are used in the safety acceptance and approval 2866 process is described in EN 50126-2. 2867

10.2.1.2 In all three categories the structure of the safety case is basically the same. However, 2868 there is an additional factor for specific applications: in this category, separate safety approval 2869 may be needed for the application design of the system and for its physical implementation (i.e. 2870 the material product which is the subject of manufacture, installation, and test, and the facilities 2871 for its operation and maintenance), especially where final testing is possible only a short time 2872 before the system is to be brought into use. 2873

10.2.1.3 For this reason, it may be convenient to divide the safety case for specific applications 2874 into two portions: 2875

the Application Design Safety Case: this shall contain the safety evidence for the 2876 theoretical design of the specific application; 2877

the physical implementation safety case: this shall contain the safety evidence for the 2878 physical implementation of the specific application. 2879

10.3 Safety case structure 2880

10.3.1 General 2881

10.3.1.1 The purpose of a safety case is to demonstrate that all relevant hazards have been 2882 identified and that suitable measures have been taken to control or mitigate risks. The first of 2883 these demonstrations is provided by a Safety Management Report and the second by a 2884 Technical Safety Report. 2885

- 75 - prEN 50126-1

10.3.1.2 In order to make these demonstrations the safety case need to include two types of 2886 arguments. Firstly it needs to argue that the set of identified requirements is sufficient to secure, 2887 assuming that all requirements are implemented, that the system is acceptably safe. Secondly, 2888 it needs to include arguments to show that sufficient evidence has been provided to prove that 2889 the requirements have been fulfilled. It also has to be shown how it is ensured that the safety 2890 measures presented in the Technical Safety Report are actually implemented in practice. The 2891 evidence for this is presented in the Quality Management Report. In addition, there needs to be 2892 sufficient description of the system/subsystem/equipment in question to enable a reader of the 2893 safety case to understand the adequacy of the evidence provided in the Quality Management, 2894 Safety Management and Technical Safety Reports. 2895

10.3.1.3 The way in which a safety case should be structured to contain this information is set 2896 out in this section, together with an outline of how the material which is required should be 2897 included in each part of the safety case. The structure of the safety case is illustrated in Figure 2898 8. 2899

10.3.1.4 The use of a standardised structure for safety case documentation has the advantage 2900 of enabling readers familiar with that structure to more rapidly locate selected material within the 2901 safety case. However, alternative structures may be used provided they contain the material 2902 defined by this Standard and provided it is demonstrated that the alternative structure is 2903 equivalent to the structure defined here. 2904

2905

2906

Figure 8 − Structure of a safety case 2907

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

prEN 50126-1 - 76 -

10.3.2 Definition of system 2908

10.3.2.1 This part of the safety case shall precisely define or reference the system/sub-2909 system/equipment to which the safety case refers, including version numbers and modification 2910 status of all requirements, design and application documentation. In order to ensure that the 2911 safety case is appropriate to the operational context of the system being analysed the system 2912 definition shall identify and outline its operational environment as defined in section 8.3 above. 2913 In order to ensure that the system is appropriate for its intended use, the system definition shall 2914 identify and outline the technical boundary of the system under consideration operating within 2915 the given environment under given operating conditions as defined in section 8.3 above 2916

10.3.2.2 The system definition may refer the reader to other documents for details of the 2917 system design, but the description contained within the safety case contain at least the 2918 following. 2919

A summary of the system requirements, including: 2920

functional safety requirements; 2921

non-functional safety requirements relevant to the safety case; 2922

environmental conditions; 2923

targets or acceptance criteria by which the safety of the system will be judged. 2924

An outline of the systems architecture and structure; 2925

A summary of the system elements involved (including software); 2926

Identification of all system interfaces, including: 2927

interfaces of the system to its environment; 2928

technical interfaces; 2929

man-machine interfaces. 2930

10.3.3 Quality management report 2931

10.3.3.1 An essential condition for the assurance of safety is that the quality of the system, sub-2932 system or equipment has been, and shall continue to be, controlled by an effective quality 2933 management system throughout its life-cycle. Documentary evidence to demonstrate this shall 2934 be provided in the Quality Management Report, which forms Part 2 of the safety case. Where 2935 appropriate this may be provided by reference to the Quality Management System of the 2936 company or organisation concerned, including evidence of certification against ISO 9001. 2937 However, the depth of the evidence presented and the extent of the supporting documentation 2938 should be appropriate to the safety targets of the system/sub-system/equipment under scrutiny. 2939

10.3.3.2 Examples of aspects which should be controlled by the quality management system 2940 and included in the Quality Management Report are listed below: 2941

organisational structure; 2942

quality planning and procedures; 2943

specification of requirements; 2944

design control; 2945

design verification and reviews; 2946

application engineering; 2947

procurement and manufacture; 2948

product identification and traceability; 2949

handling and storage; 2950

inspection and testing; 2951

non-conformance and corrective action; 2952

packaging and delivery; 2953

- 77 - prEN 50126-1

installation and commissioning; 2954

operation and maintenance; 2955

quality monitoring and feedback; 2956

documentation and records; 2957

configuration management/change control; 2958

personnel competency and training; 2959

quality audits and follow-up; 2960

decommissioning and disposal. 2961

10.3.3.3 Further requirements/guidance on the relevance of quality management to safety is set 2962 out in Annex A of EN 50126-2. 2963

10.3.4 Safety management report 2964

10.3.4.1 A further essential condition for the assurance of safety is that the safety of the 2965 system, subsystem or equipment has been, and shall continue to be, managed by means of an 2966 effective safety management process. Documentary evidence to demonstrate compliance with 2967 all elements of the safety management process throughout the life-cycle shall be provided in the 2968 Safety Management Report. Large volumes of detailed evidence and supporting documentation 2969 need not be included, provided precise references are given to such documents. However, the 2970 depth of the evidence presented and the extent of the supporting documentation should be 2971 appropriate to the safety targets of the system/sub-system/equipment under scrutiny 2972

10.3.4.2 The Safety Management Report should be arranged under the following headings: 2973

safety life-cycle; 2974

safety organisation; 2975

safety plan; 2976

hazard log. 2977

Requirements/guidance on safety management are set out in section 7.1.2 above as well as in 2978 Annex A.2 in EN 50126-2. 2979

10.3.5 Technical safety report 2980

10.3.5.1 The Technical Safety Report consists of technical evidence for the safety of the design 2981 and shall explain the technical principles which assure the safety of the design, including (or 2982 giving references to) all supporting evidence (for example, design principles and calculations, 2983 test specifications and results, and safety analyses). 2984

10.3.5.2 All safety cases shall include a Technical Safety Report. However, the depth of the 2985 information and the extent of the supporting documentation should be appropriate to the safety 2986 targets of the system/subsystem/ equipment under scrutiny. 2987

10.3.5.3 The Technical Safety Report should be arranged under the following headings: 2988

10.3.5.3.1 Introduction 2989

This section shall provide a summary of the technical safety principles that are relied on for 2990 safety and the extent to which the system/sub-system/equipment is claimed to be safe in 2991 accordance with this standard, together with an overview description of the design if this is not 2992 already sufficiently covered by the system definition (see section 10.3.1 above). 2993

This section shall also indicate the standards (and their issues) used as the basis for the 2994 technical safety of the design. 2995

10.3.5.3.2 Assurance of correct functional operation 2996

This section shall contain all the evidence necessary to demonstrate correct operation of the 2997 system/subsystem/ equipment under fault-free normal conditions (that is, with no faults in 2998 existence), in accordance with the specified operational and safety requirements. 2999

prEN 50126-1 - 78 -

10.3.5.3.3 Effects of faults 3000

This section shall demonstrate that the system/sub-system/equipment continues to meet its 3001 specified safety requirements, including the quantified safety targets, in the event of random 3002 hardware faults. 3003

In addition, a systematic fault could still exist, despite following the quality and safety 3004 management processes defined in this standard. This section shall demonstrate which technical 3005 or operational measures have been taken to reduce the consequent risk to an acceptable level. 3006

This section shall also include demonstration that faults in any system/sub-system/equipment 3007 having a Safety Integrity Level lower than that of the overall system, including Level 0, cannot 3008 reduce the safety of the overall system. 3009

The following headings should be used in this section, for which more detailed requirements are 3010 contained in EN 50126-2: 3011

Effects of single faults; 3012

Independence of items; 3013

Detection of single faults and action following detection (including retention of safe 3014 state); 3015

Effects of multiple faults; 3016

Defence against systematic faults. 3017

10.3.5.3.4 Operation with external influences 3018

This section shall demonstrate that when subjected to the external influences defined in the 3019 System Requirements Specification, the system/sub-system/equipment 3020

continues to fulfil its specified operational requirements; 3021

continues to fulfil its specified safety requirements (including fault conditions). 3022

The safety case is therefore valid only within the specified range of external influences, as 3023 defined in the System Requirements Specification. Safety is not assured outside these limits, 3024 unless additional special measures are provided. 3025

The methods used to withstand the specified external influences shall be fully explained and 3026 justified. 3027

10.3.5.3.5 Application conditions 3028

This section shall specify (or reference) the rules, conditions and constraints which shall be 3029 observed in the application of the system under consideration. 3030

10.3.5.3.6 Safety qualification tests 3031

This section shall contain evidence to demonstrate successful completion, under operational 3032 conditions, of the Safety Qualification Tests. 3033

10.3.6 Related safety cases 3034

This shall contain references to the safety cases of any sub-systems or equipment on which the 3035 main safety case depends. It shall explain how the main safety case depends on the related 3036 safety cases. 3037

It shall also demonstrate that all the safety-related application conditions specified in each of the 3038 related sub-system/equipment safety cases are either fulfilled in the main safety case, or carried 3039 forward into the safety-related application conditions of the main safety case. 3040

10.3.7 Conclusion 3041

This shall summarise the evidence presented in the previous parts of the safety case, and argue 3042 that the relevant system/sub-system/equipment is adequately safe, subject to compliance with 3043 the specified application conditions. 3044

- 79 - prEN 50126-1

10.3.8 References 3045

Large volumes of detailed evidence and supporting documentation need not be included in the 3046 safety case and in its parts, provided this section contains precise references to such 3047 documents and provided the base concepts used and the approaches taken are clearly 3048 specified. 3049

prEN 50126-1 - 80 -

Annex A (informative) RAMS plan 3050

A.1 This annex gives an example of an outline procedure for a basic RAM plan/safety plan describing a 3051 RAMS programme and shows an example of a basic RAMS plan (RAM plan/safety plan). It also lists 3052 some methods and tools for RAMS management and analysis. 3053

A.2 The supplier should establish a RAMS plan which will effectively facilitate meeting the RAMS 3054 requirements of the application under consideration. The RAMS Programmes of similar projects or 3055 system requirements of a supplier may yield a “standard RAMS programme” which establishes the 3056 “RAMS-Baseline” of a company. 3057

A.3 Procedure 3058

An outline example procedure for a basic RAMS plan is given below. 3059

1. Define the appropriate life-cycle phases respectively project phases which are in line 3060 with the company’s business process; 3061

Result: The Company’s life-cycle or project phases are established 3062

2. Assign to each life-cycle or project phase the phase related RAM and safety tasks 3063 which are necessary to confidently meet the project and system specific 3064 requirements; 3065

Result: All necessary RAMS tasks in the life-cycle or project are identified 3066

3. Define the responsibilities in the company to carry out each RAMS task; 3067

Result: The responsible staff and necessary RAMS resources are identified 3068

4. The necessary instructions, tools and reference documents for each RAMS task are 3069 defined; 3070

Result: Documented RAMS management 3071

5. The RAMS activities are implemented in the processes of the company. 3072

Result: Process integrated RAMS management (RAMS-Baseline) 3073

A.4 Basic RAMS plan example 3074

An outline for a basic RAMS plan is given in Table A.1. The outline consists of an example of a 3075 set of tasks which could be applied to a particular project. 3076

- 81 - prEN 50126-1

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

Project-Phase RAMS Tasks Respon-sibility

Reference Document

Pre-Acquisition

- Evaluate RAMS targets of specific application

Feasibility Study

- Evaluate RAMS requirements

- Evaluate past data and experience of RAMS

- Identify influence on Safety imposed by specific application

- Consult customer on RAMS (if necessary)

Invitation for Tenders

- Perform preliminary RAMS analysis (Worst case)

- Apportion system RAMS requirements (Sub-systems/equipment, other relevant systems etc.)

- Perform system hazard & safety risk analysis

- Perform RAM related risk analysis

- Prepare for future RAMS data assessment

- Clause to clause comments concerning RAMS

Contract Negotiations

- Review/update preliminary RAMS analysis and RAMS apportionment

Order Processing:

- Definition of system requirements

- Establish project specific RAMS management

- Specify system RAMS requirements (overall)

- Establish RAMS plan (Standard RAMS plan sufficient?)

- Assign RAMS requirements to sub-contractors, suppliers

- Define RAMS acceptance criteria (overall)

Order Processing: Design and Implementation

- Reliability analysis (FMEA)

- Safety analysis (FMECA), if applicable

- Maintenance/repair analysis; define maintenance/repair policy

- Availability analysis based on the maintenance/repair policy

- RAMS reviews

- Life-cycle Cost estimation

- RAMS demonstration, evidence compilation

- Design/manufacturing FMEA

- Reliability and maintainability testing, if applicable

Procurement - Provide RAMS specification for sub-contractors/suppliers

Manufacturing / Testing

- RAMS related quality assurance/process assurance

prEN 50126-1 - 82 -

Project-Phase RAMS Tasks Respon-sibility

Reference Document

Commissioning / Acceptance

- Perform RAM demonstration

- Prepare specific application safety case

- Initiate RAMS data assessment

- RAM testing during early operation, data screening and evaluation

Operation / Maintenance

- Provisional operation and maintenance (Maintenance/repair policy)

- Operation and maintenance personnel training

- RAMS data assessment

- Life-cycle Cost assessment

- Performance review

A.5 List of tools 3078

Some appropriate methods and tools for conducting and managing a RAMS programme are 3079 listed below. The choice of the relevant tool will depend on the system under consideration and 3080 the criticality, complexity, novelty etc., of the system. 3081

1. An outline form of RAMS specification in order to assure assessment of all relevant 3082 RAMS requirements. 3083

2. Procedures for formal design reviews with emphasis on RAMS, using some general 3084 and application specific check lists as appropriate, e.g. 3085

IEC 61160:2006 Design review

3. Procedures for performing "top down" (deductive methods) and "bottom up" (inductive 3086 methods) preliminary, worst case and in-depth RAM analysis for simple and complex 3087 functional system structures 3088

An overview of commonly used RAM analysis procedures, methods, advantages and 3089 disadvantages, data input and other requirements for the various techniques is given 3090 in: 3091

IEC 60300-3-1 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 3092 these are as follows: 3093

- 83 - prEN 50126-1

IEC 60706 Guide on maintainability of equipment

IEC 60706-1 Part 1 - Sections 1, 2 and 3: Introduction, requirements and maintainability programme

IEC 60706-2 Part 2 - Maintainability requirements and studies during the design and development phase

IEC 60706-3 Part 3 - Verification and collection, analysis and presentation of data

IEC 60706-5 Part 5 - Testability and diagnostic testing

IEC 60706-6 Part 6 - Section 9: Statistical methods in maintainability evaluation

IEC 60812 Analysis techniques for system reliability - Procedures for failure mode and effects analysis (FMEA)

IEC 61025 Fault tree analysis (FTA)

IEC 61078 Analysis techniques for dependability - Reliability block diagram and boolean methods

IEC 61165 Application of Markov techniques

Availability of supportable statistical "RAM" data, for the components used in a 3094 design, (typically: failure rates, repair rates, maintenance data, failure modes, event 3095 rates, distribution of data and random events etc.) is fundamental to RAM analysis, 3096 e.g. 3097

IEC 61709 Electronic components - Reliability - Reference conditions for failure rate and stress models for conversion

MIL-HDBK-217F_2 Reliability Prediction for Electronic Systems

A number of computer programmes for system RAM analysis and statistical data 3098 analysis are also available. 3099

4. Procedures for performing hazard & safety/risk analysis 3100

Some of these are described in: 3101

MIL-STD-882D Standard Practise for System Safety

MIL-HDBK-764 (MI) System Safety Engineering Design Guide For Army Materiel

The same basic techniques and analysis methods listed for RAM (item 3), are also 3102 applicable for safety/risk analysis. 3103

Also see IEC 61508 Parts 1-7 under the general title "Functional safety of 3104 electrical/electronic/programmable electronic safety-related systems", consisting of 3105 the following parts: 3106

IEC 61508-1:2010 Part 1: General requirements

IEC 61508-2:2010 Part 2: Requirements for electrical/electronic/programmable electronic systems

IEC 61508-3:2010 Part 3: Software requirements

IEC 61508-4:2010 Part 4: Definitions and abbreviations

IEC 61508-5:2010 Part 5: Examples of methods for the determination of safety integrity levels

IEC 61508-6:2010 Part 6: Guidelines on the application of Parts 2 and 3

IEC 61508-7:2010 Part 7: Overview of techniques and measures

5. RAMS testing plans and procedures 3107

prEN 50126-1 - 84 -

This step is in order to test the long-term operating behaviour of components, 3108 equipment or systems and to demonstrate compliance with the requirements. 3109 Furthermore RAMS analysis and test results are used to devise RAMS improvement 3110 programmes, e.g. 3111

IEC 60605 Equipment reliability testing

IEC 60605-2 Part 2: Design of test cycles

IEC 60605-3-1 Part 3: Preferred test conditions. Indoor portable equipment - Low degree of simulation

IEC 60605-4 Part 4: Statistical procedures for exponential distribution - Point estimates, confidence intervals, prediction intervals and tolerance intervals

IEC 60605-6 Part 6: Tests for the validity of the constant failure rate or constant failure intensity assumptions

IEC 61014 Programmes for reliability growth

IEC 61070 Compliance test procedure for steady-state availability

IEC 61123 Reliability testing - Compliance test plan for success ratio

Of greater importance is the assessment of RAMS data from the field (RAMS testing 3112 during operation), e.g.: 3113

IEC 60300-3-2 Dependability management - Part 3: Application guide - Section 2: Collection of dependability data from the field

IEC 60319 Presentation of reliability data on electronic components (or parts)

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

Various computer programmes are available for LCC analysis. 3115

- 85 - prEN 50126-1

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

Examples of typical parameters and symbols, suitable for use in railway applications, are 3117 tabulated below: 3118

In general any time-based parameter like MTBF can be converted/ derived from the respective 3119 operated distance or operation cycles as well. 3120

Definition and detailed guidance on mathematical treatment of RAM terms is given in EN 61703. 3121

B.1 Reliability parameters 3122

Table B.1 - Examples of reliability parameters 3123

Parameter Symbol Dimension

Failure Rate (t) 1/time, 1/distance, 1/cycle

Mean Up Time MUT time (distance, cycle)

Mean operating3) Time To Failure (for non-repairable items)

MTTF

time (distance, cycle)

Mean operating3) Time Between Failure (for repairable items)

MTBF

time (distance, cycle)

Mean Repair Time MRT time

Failure Probability F(t) dimensionless

Reliability (Success Probability) R(t) dimensionless

B.2 Maintainability parameters 3124

Table B.2 - Examples of maintainability parameters 3125


Mean Down Time MDT time (distance, cycle)

Mean operating3) Time Between Maintenance

MTBM time (distance, cycles)

MTBM (corrective or preventive) MTBM(c), MTBM(p) time (distance, cycles)

Mean Time To Maintain MTTM time

MTTM (corrective or preventive) MTTM(c), MTTM(p) time

Mean Time To Restore MTTR time

Fault Coverage FC dimensionless

Repair Coverage RC dimensionless

3126

“Operating” signifies the time, distance or cycles where the item under consideration is 3127 effectively in use. 3128

3129

—————————

3) According to EN 61703 and IEC 60050-191-2

prEN 50126-1 - 86 -

B.3 Availability parameters 3130

Table B.3 - Examples of availability parameters 3131


Availability inherent operational

A A i A o

dimensionless

Fleet Availability FA dimensionless

Schedule Adherence SA dimensionless or time

Under certain conditions, for instance constant failure rate and constant repair rate, the steady-3132 state availability may be expressed by 3133

1

MDTMUT

MUTA . 3134

with 0 ≤ A ≤ 1 and generally has a value close to 1. Its complement is called unavailability U. 3135

01

MDTMTBF

MDTAU . 3136

Depending from the type of availability A to be considered, it has to be decided which fractions 3137 of MDT are relevant and therefore, taken into consideration for calculation. These fractions are 3138 to be defined. 3139

Detailed guidance on calculations for systems with different properties and different repair 3140 characteristics is given in EN 61703. 3141

The availability concept is illustrated by Figure B.1 3142

For an item / system which is permanently in operation mode and no planned preventive 3143 maintenance is applied, MUT=MTBF holds. In this case MUT and MTBF can be used 3144 interchangeably for calculating the (steady state) operational availability. It may then be 3145 expressed by 3146

1

MDTMTBF

MTBF

MDTMUT

MUTA 3147

MTBF is typically based on the time the system is in use (operated). 3148

The parties involved should agree on the understanding of all the terms used (e.g. the MTBF 3149 time basis suitable for the specific application under consideration or which type of delay is 3150 taken into account). In case of contractual obligations it is highly recommended to stipulate the 3151 agreements. 3152

- 87 - prEN 50126-1

3153

3154

3155

Figure B.1 – Availability concept and related terms 3156 3157

NOTE 1 Detailed guidance on calculations with different system properties and different repair characteristics is given 3158 in EN 61703. 3159

NOTE 2 Restoration can be achieved by repair, exchange, reset or other means. 3160

3161

The definitions of Fleet Availability (FA) as well as of Schedule Adherence (SA) are normally the 3162 subject of contractual negotiations. Therefore the elaboration of both parameters is not provided 3163 in this standard. 3164

down state

MAD + MLD

MRT

Time to check/test the system

Repair/exchange time

Investigation time

Administrative and logistics delay

up stateup state

FAILURE

CORRECTIVE MAINTENANCE START

READY FOR SERVICE

MTBF ≥ MUT MTBF ≥ MUT MTTR = MDT

MTBF mean (operating) time between failures

MUT mean up time

MDT mean down time

MRT mean repair time

MAD mean administrative delay

MLD mean logistics delay

MTTR mean time to restore (for corrective maintenance)

Definitions can be found in EN 61703.

prEN 50126-1 - 88 -

B.4 Logistic support parameters 3165

Table B.4 - Examples of logistic support parameters 3166


Operation and Maintenance Cost O&MC money

Maintenance Cost MC money

Maintenance Man Hours MMH time (hours)

Logistic and Administrative Delay LAD time

Fault correction time time

Repair time time

Turn Around Time TAT time

Maintenance support performance dimensionless

Employees for Replacement EFR number

Probability that Spare Parts are available (in Stock) when needed

SPS dimensionless

B.5 Safety parameters 3167

Table B.5 - Examples of Safety performance parameters 3168


Hazard rate h(t) 1/time, 1/distance, 1/cycle

Probability of wrong-side failure pWSF dimensionless

Active time to return to safe state - time

3169

- 89 - prEN 50126-1

Annex C (informative) Hazards at railway system level – example structured 3170 list 3171

The objectives of this annex are: 3172

to provide generic guidance on the creation of hazard lists and, 3173

to provide guidance on how hazards lists can be structured and on how hazards at 3174 different levels interface with each other and; 3175

to provide, through example, guidance for the naming or description of hazards and, 3176

to exemplify a structured list of hazards applicable to railway applications. 3177

It does not intend to provide guidance on hazard identification since this is covered in EN 3178 50126-2 (clause 8.2). 3179

The result of hazard identification exercises is often a list of scenarios which have been derived 3180 from failures, both operational and technical, from possible accidents, from brainstorming or 3181 from pre-existing lists of hazards. These scenarios will often need honing into a structured list in 3182 keeping with the system under consideration. 3183

In general, hazards can be derived and structured based on various perspectives (e.g. 3184 functional, physical, organisational etc.) and the choice of perspective or combination of 3185 perspectives needs to consider the requirements of the specific application. Where possible, 3186 hazards should be defined at a sufficiently high level that they remain generic and independent 3187 of specific solutions or implementation issues of railway operation, yet also be detailed enough 3188 to provide a good focus point for safety control. 3189

In defining a hazard it is important to consider that a hazard has a causal domain and 3190 consequence domain. Consequently, the hazards should be defined at level facilitating causal 3191 analysis (identification of and relationship between the underlying causes) and consequence 3192 analysis. With regard to the consequence analysis and in accordance with the definition of the 3193 term hazard, the hazard should not be defined at the accident level. This allows the 3194 consideration of safety barriers and factors which influence the progression of the hazard to 3195 potential consequences, including accidents. 3196

It is best practice to define a hazard at the boundary of the system under consideration, i.e. the 3197 point where the causes of the hazard come from within the system or the operation of the 3198 system, considering human interaction where appropriate. Ideally, the consequence domain of 3199 the hazard would then consider the influences of the environment within which the system under 3200 consideration operates, but not further influences of the system itself. However, this may not 3201 always be possible and there may be cases where the system can also influence the 3202 consequence domain (e.g. consider a hazard “train braking ability impaired or lost” from the 3203 perspective of the train sub-system. This hazard could be caused by failures in the transmission 3204 of the brake command and there may be nothing more that the system can do to avoid this 3205 hazard. However, the use of the onboard train radio could mitigate the consequences by alerting 3206 the signaller and other drivers). 3207

In general, hazards should consider technical and operation as well as circumstantial aspects 3208 where applicable, since typically these can not be easily or meaningfully separated. 3209

When defining a hazard and its scope, consideration of the mechanisms present in the 3210 consequence domain should be taken. For the purpose of analysis, it is sensible to separate 3211 scenarios associated with dissimilar mechanisms and define separate hazards. 3212

It is often beneficial to group hazards together based on hazard characteristics and structure the 3213 hazards in a hierarchy. As mentioned previously the chosen grouping and structure need to 3214 reflect the requirements of the specific application. It is important to note that it is unlikely that 3215 hazards will be mutually exclusive. That is to say that hazard domains (causal and 3216 consequence) will interact with each other and, for example, certain hazards will be the causes 3217 for other hazards. Although a mutually exclusive hazard structure is beneficial and should be 3218 strived for, in reality this will often be difficult to achieve. A simple example of the interaction 3219 between hazards and a hierarchy of hazards can be seen via the systems approach, whereby a 3220 system’s hazards may form the causal events for hazards of the next higher level system. 3221 Furthermore, a system’s hazard may be a causal event in two or more hazards in the next 3222 system level. 3223

prEN 50126-1 - 90 -

C.1 Example list 3224

The list presented below in Table C.1 can be used as a basis for hazard identification and in the 3225 standardisation of hazard naming. However, the list is not exhaustive, and since any hazard 3226 identification depends on the system under consideration and the perspective of the entity 3227 undertaking the identification, the list, as with any predefined hazard list, requires adaptation in 3228 accordance with the specific application. 3229

The list has been derived on the basis of two hazard levels. The 1st hazard level represents 3230 hazards from the perspective of the railway application’s system as a whole. The 2nd level 3231 hazards are those seen at the boundaries of subsystems, in this case the subsystems of the 3232 three application fields (Signalling, Rolling Stock, Fixed Installations) within the scope of this 3233 standard. Dependent on the specific application the 1st or 2nd level of hazards may be sufficient 3234 for analysis. In other cases, the 2nd level hazards may need to be broken down further into 3235 lower level hazards (e.g. to consider hazards at the boundaries of the next level of subordinate 3236 subsystems). 3237

The 2nd level hazards may be assigned to the application fields where the hazards would likely 3238 feature in the risk analysis of the related subsystems. Such an assignment at an early stage of 3239 the analysis helps to identify the stakeholders involved and to optimise the agreement of the 3240 necessary hazard and risk control measures. 3241

The railway system behind this structure is based on the architecture and organisation of some 3242 traditional railway applications. Since hazards are not necessarily confined to the three 3243 application fields within the scope of this standard, a column “other application field(s)” has 3244 been included to indicate where this may be the case. Again, the exact assignment of hazards is 3245 dependent on the specific application. However, the list serves to demonstrate that a hazard 3246 may be influenced by sub-systems under the responsibility of one or several entities and to 3247 highlight the necessity to consider the interfaces between entities in the safety management 3248 process. 3249

This hazard list was primarily derived from the functional perspective of the railway. 3250

Table C.2 provides some example scenarios associated with the listed hazards. The examples 3251 aim to provide an understanding of the scope of the hazard, primarily through, but not limited to 3252 example causal scenarios. 3253

3254

- 91 - prEN 50126-1

Table C.1 - Example for a hazard list 3255

ID Hazards (1st and 2nd level)

Sig

1)

Ro

Sto

2)

Po

we

r3)

Oth

er4

)

H 1 Inadequate separation between trains

H 1.1 Degraded ability to locate train

H 1.2 Insufficient control of train speed

H 1.3 Inappropriate control of train movement

H 1.4 Train braking ability impaired or lost

H 1.5 Unintended loss of train integrity

H 2 Structure clearance impaired or straight line not cleared

H 2.1 Unsound/unsecured structures/components/objects

H 2.2 Train kinematic envelope outside tolerable limit

H 2.3 Object in path of train


H 2.5 Inappropriate separation between train and level crossing user

H 3 Insufficient track guidance

H 3.1 Infrastructure guidance function degraded

H 3.2 Vehicle guidance function degraded

H 3.3 Insufficient control of train speed


H 3.5 Train braking ability impaired or lost

H 4 Safe boarding and alighting impaired

H 4.1 Loss of balance

H 4.2 Inappropriate separation between persons and closing doors


3256

—————————

1) Command Control & Signalling

2) Rolling Stock

3) Traction Power Supply

4) Other Application Field(s)

prEN 50126-1 - 92 -

H 5 Safe stay impaired (trackside/ inside train)

H 5.1 Loss of balance

H 5.2 Unintended loss of train integrity

H 5.3 Inappropriate environment

H 5.4 Unsound/unsecured structures/components/objects

H 5.5 Inappropriate separation between persons and running railway

H 5.6 Exposure to excessive noise levels

H 5.7 Inadequate containment of harmful substances

H 5.8 Inappropriate separation between person and heat source

H 6 Insufficient control of emergency situations

H 6.1 Inadequate crash worthiness

H 6.2 Inadequate emergency exit or entry of train

H 6.3 Insufficient emergency equipment

H 6.4 Inability to reach safe location

H 7 Onset of fire or smoke 5)

H 7.1 Onset of fire or smoke

H 8 Impaired protection against electric shock 5)

H 8.1 Inappropriate separation between live conductor and person

H 8.2 Inappropriate touch voltage

H 9 Inappropriate levels of electro-magnetic Interference (EMI) 6)

H 9.1 Intolerable electromagnetic interference of other systems

H 9.2 Intolerable electromagnetic interference from other systems

H 10 Shock wave (explosion, air, pressure) 6)

H 10.1 Shock wave (explosion, air, pressure)

H 11 Hazardous substances 6)

H 11.1 Inappropriate separation between persons and hazardous substances

—————————

5) hazard not confined to the functional perspective

6) hazard define other than the functional perspective

- 93 - prEN 50126-1

Table C.2 - Example scenarios 3257

Hazard Example scenarios

Degraded ability to locate train faulty signalling equipment (e.g. axle counters), train axle resistance too high for detection by track circuit

Insufficient control of train speed tachometer information incorrect, failure of ATP system to intervene (e.g. through incorrect tacheometry or failure to initiate emergency brake), uncontrolled approach to buffer

Inappropriate control of train movement

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

Train braking ability impaired or lost failure of brake sub system, failure to transmit brake command

Unintended loss of train integrity undesired separation at automatic/manual/fixed coupler during journey Door opens during journey, window smashes

Unsound/unsecured structures/components/objects

infrastructure (e.g. signalling equipment, overhead contact system…) out of gauge Lineside structures (e.g. bridges, signalling structures, overhead contact system) fall

Train kinematic envelope outside tolerable limit

door/door step opens during journey, failure or train suspension or train tilting function

Object in path of train Animals, road vehicles and other objects normally outside the railway system on line or hung/thrown in front of oncoming train

Unsound/unsecured structures/components/objects

Train components become loose and fall (inside train or from train, e.g. onto track), luggage falls from luggage rack, catenary or its parts fall down

Infrastructure guidance function degraded

track condition degraded

Vehicle guidance function degraded Wheel-rail interface impaired as a result of blocked axle / hot axle (including monitoring), suspension / damper failure

Train braking ability impaired or lost failure of brake sub system, failure to transmit brake command

Loss of balance excessive change in acceleration / deceleration, slippery surface, trip hazards in walkways etc.

Inappropriate environment climate too hot, excessive pressure wave

Inappropriate separation between persons and closing doors

lack of train perception, passengers too close to platform edge

prEN 50126-1 - 94 -

Hazard Example scenarios

Exposure to excessive noise levels considers sources of noise levels harmful to humans in the long or short term

Inadequate containment of harmful substances

Leakage or generation of toxic, corrosive substances, asphyxiate etc. which may be detrimental to human health or to the environment.

Inadequate crash worthiness insufficient car strength, inadequate anticlimbing devices

Inadequate emergency exit or entry of train

doors cannot be opened, lack of emergency windows etc., inadequate emergency exits in tunnel

Insufficient emergency equipment lack of fire extinguishers, emergency lighting etc.

Inability to reach safe location running capability in the event of fire

Onset of fire electrical isolation failures, exposure of flammable liquids/gases to ignition source, overheating of components due to friction.

Shock wave (explosion, air, pressure) excessive build up of pressure in components/sealed or pressurised vessels (through fire, electric currents etc.), loss of structural integrity of pressure vessels.

Inappropriate separation between live conductor and person

Touch voltage exceeded, inadequate separation between high voltage equipment and person etc.

Intolerable electromagnetic interference of other systems

EM radiation from equipment interferes and degrades the operation of a safety related function (e.g. pacemakers, axel counters)

Intolerable electromagnetic interference from other systems

EM radiation from external source interferes and degrades the operation of a safety related function of the system under consideration

3258

- 95 - prEN 50126-1

Annex D (informative) Risk matrix calibration and risk acceptance 3259 categories 3260

This annex provides examples of application of a risk matrix and its parameters. 3261

D.1 Frequency of occurrence levels 3262

The following Table D.1 and Table D.2 give examples of frequency levels, adapted to a 3263 particular use. 3264

The use of these particular examples is not mandatory, other classification can be used. More 3265 than one matrix can be used when this method is applied. 3266

Table D.1 - Frequency of occurrence of events with examples for quantification (time 3267 based) 3268

Frequency level

Description

Example of a range of frequency based on

operation of 24h / day

Example of equivalent

occurrence in a 30 year lifetime of

5000 h operation / year

Expected to happen

Frequent Likely to occur frequently. The event will be frequently experienced.

more than once within a period of approximately 6 weeks

more than about 150 times

Probable Will occur several times. The event can be expected to occur often.

approximately once per 6 weeks to once per year

about 15 to 150 times

Occasional

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

approximately once per 1 year to once per 10 years

about 2 to 15 times

Rare

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

approximately once per 10 years to once per 1 000 years

perhaps once at most

Improbable

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

approximately once per 1 000 years to once per 100 000 years

not expected to happen within the lifetime

Highly improbable

Extremely unlikely to occur. It can be assumed that the event may not occur.

once in a period of approximately 100 000 years or more

extremely unlikely to happen within the lifetime

3269

NOTE This table is related to a single item (system/function/component). The examples given depend from the 3270 number of systems and/or the number of e.g. operational hours considered. 3271

The expected mean time between two events is determined by the given reciprocal value of the 3272 frequency. For a frequency level bandwidth this formula has to be applied for its upper as well 3273 as its lower limit. 3274

Example for a rate of 10-4 h-1: 3275

1/ 10-4 h-1 = 10 000 h which means an expected event frequency of approximately: 3276

- 1,2 years in case of 24 h operation 3277

prEN 50126-1 - 96 -

- or 2 years in case of assumed 5 000 h operating time per year. 3278

The expected occurrence or number of events in a time period is determined by the given time 3279 period multiplied by the given rate or frequency of occurrence. The time period has to be 3280 reduced if calendar time is not appropriate. 3281

E.g.: 10-4 h-1 x (30 years x 5 000 h/years) = 15 The event is expected to happen 3282 approximately 15 times within 30 years if 5 000 operational hours per year are assumed. 3283

The considered time is an average and not necessarily a continuous time. 3284

A distance based approach is given in Table D.2. 3285

Table D.2 - Frequency of occurrence of events with examples for quantification (distance 3286 based) 3287

Frequency level Description Example of a range of frequency

F1 Likely to occur often more than once every 5 000 km per train

F2 Will occur several times once every 25 000 km per train

F3 Might occur sometimes Once every 100 000 km per train

3288

D.2 Severity levels 3289

The following tables give examples of severity levels, related to a particular use. 3290

Table D.3 - Severity categories (example related to RAM) 3291

RAM severity level

Description

Significant

(immobilising failure)

A failure that:

prevents train movement or

causes a delay to service greater than a specified time

and/or generates a cost greater than a specified level

Major

(service failure)

A failure that:

must be rectified for the system to achieve its specified performance and

does not cause a delay or cost greater than the minimum threshold specified for a significant failure

Minor A failure that:

does not prevent a system achieving its specified performance and

does not meet criteria for Significant or Major failures

3292

- 97 - prEN 50126-1

Table D.4 - Severity categories (example 1 related to RAMS) 3293

Severity level Consequences to persons or environment Consequences on service/property

Catastrophic Many fatalities and/or extreme damage to the environment.

Critical Severe injuries and/or few fatalities and/or large damage to the environment.

Loss of a major system

Marginal Minor injuries and/or minor damage to the environment

Severe system(s) damage

Insignificant Possible minor injury Minor system damage

3294

Table D.5 - Categories (example 2 related to Safety) 3295

Severity level

Consequences to persons or environment

S1 Many equivalent fatalities (likely more than about 10) or extreme damage to the environment.

S2 Multiple equivalent fatalities (likely less than about 10) or large damage to the environment.

S3 Single fatality or severe injury or significant damage to the environment.

S4 Minor injuries or minor damage to the environment

S5 Possible minor injury

3296

Table D.6 - Financial severity levels (example) 3297

Severity level

Financial consequences

SF1 The incident will incur people suing the company, severe impact to the public image of the company, and/or incur costs higher than 1000 000€.

SF2 The incident may have an impact on the public image of the company and/or incur costs higher than 100 000 €

SF3 The incident will not incur costs higher than 100 000 €

D.3 Risk acceptance categories 3298

Risk acceptance categories allocated to identified risks allow classification for the purpose of 3299 decision making. Examples of risk acceptance categories are shown in Table D.7 and Table D.8 3300 below: 3301

Table D.7 - Risk acceptance categories (example 1 for binary decisions) 3302

Risk Acceptance

Category Actions to be applied

Unacceptable The risk needs further reduction to be accepted

Acceptable The risk is accepted provided adequate control is maintained

3303

prEN 50126-1 - 98 -

Table D.8 - Risk acceptance categories (example 2) 3304

Risk Acceptance

Category Actions to be applied

Intolerable The risk shall be eliminated

Undesirable The risk shall only be accepted if its reduction is impracticable and with the agreement of the railway duty holders or the responsible Safety Regulatory Authority.

Tolerable The risk can be tolerated and accepted with adequate control (e.g. maintenance procedures or rules) and with the agreement of the responsible railway duty holders.

Negligible The risk is acceptable without the agreement of the railway duty holders.

3305

Table D.9 - Risk acceptance categories (example related to safety) 3306

Frequency of occurrence of an

accident (caused by a hazard) Risk Acceptance Levels

Frequent Undesirable Intolerable Intolerable Intolerable

Probable Tolerable Undesirable Intolerable Intolerable

Occasional Tolerable Undesirable Undesirable Intolerable

Rare Negligible Tolerable Undesirable Undesirable

Improbable Negligible Negligible Tolerable Undesirable

Highly improbable Negligible Negligible Negligible Tolerable

I II III IV

Severity of an accident (caused by a hazard)

- 99 - prEN 50126-1

Annex E Bibliography 3307

3308

EN 614 Safety of machinery - Ergonomic design principles

IEC 60300-3-1 Dependability management – Part 3-1: Application guide – Analysis techniques for dependability – Guide on methodology

IEC 60300-3-2 Dependability management – Part 3-2: Application guide – Collection of dependability data from the field

IEC 60319 Presentation and specification of reliability data for electronic components

IEC 60605-2 Equipment reliability testing – Part 2: Design of test cycles

IEC 60605-3-1 Equipment reliability testing. Part 3: Preferred test conditions. Indoor portable equipment - Low degree of simulation

IEC 60605-4 Equipment reliability testing – Part 4: Statistical procedures for exponential distribution – Point estimates, confidence intervals, prediction intervals and tolerance intervals

IEC 60605-6 Equipment reliability testing – Part 6: Tests for the validity and estimation of the constant failure rate and constant failure intensity

IEC 60706-1 Guide on maintainability of equipment – Part 1: Sections 1, 2 and 3: Introduction, requirements and maintainability programme

IEC 60706-2 Maintainability of equipment – Part 2: Maintainability requirements and studies during the design and development phase

IEC 60706-3 Maintainability of equipment – Part 3: Verification and collection, analysis and presentation of data

IEC 60706-5 Maintainability of equipment – Part 5: Testability and diagnostic testing

IEC 60706-6 Guide on maintainability of equipment – Part 6: Section 9: Statistical methods in maintainability evaluation

IEC 60812 Analysis techniques for system reliability – Procedures for failure mode and effects analysis (FMEA)

IEC 61014 Programmes for reliability growth

IEC 61025 Fault tree analysis (FTA)

IEC 61070 Compliance test procedures for steady-state availability

IEC 61078 Analysis techniques for dependability– Reliability block diagram and boolean methods

IEC 61123 Reliability testing; compliance test plans for success ratio

IEC 61160 Design review

IEC 61165 Application of Markov techniques

IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems

IEC 61703 Mathematical expressions for reliability, availability, maintainability and maintenance support terms

IEC 61709 Electronic components – Reliability – Reference conditions for failure rate and stress models for conversion

IEC-TR-62380 Reliability data handbook - Universal model for reliability prediction of electronics components, PCBs and equipment

3309