EN50126 Draft pt4 CLCEnq 120629

-1-
7000
7001
7002
7003
7004
7005
Project number:
prEN 50126-4
prEN 50126-4
Railway Applications - The Specification and Demonstration of Reliability, Availability,

Maintainability and Safety (RAMS)
Part 4: Functional Safety - Electrical / Electronic / Programmable Electronic Systems
Applications ferroviaires Spcification et dmonstration de la fiabilit, de la

disponibilit, de la maintenabilit et de la scurit (FDMS)
Partie 4: Scurit fonctionnelle - Systmes lectriques / lectroniques / lectroniques
programmables
Bahnanwendungen - Spezifikation und Nachweis von Zuverlssigkeit, Verfgbarkeit,

Instandhaltbarkeit und Sicherheit (RAMS)
Teil 4: Funktionale Sicherheit - Elektrische / Elektronische / Programmierbare
elektronische Systeme
7006
prEN 50126-4
7007
-2-
-3-
prEN 50126-4
7008
Table of Contents
7009
7010
Introduction ................................................................................................................................................ 7
7011
1.
Scope................................................................................................................................................... 9
7012
2.
Normative references........................................................................................................................ 11
7013
3.
Terms and Definitions....................................................................................................................... 11
7014
4.
Abbreviations.................................................................................................................................... 11
7015
5.
Overall Framework of the Part 4....................................................................................................... 14
7016
6.
E/E/PE SYSTEMS MANAGEMENT AND ORGANISATION................................................................ 16
7017
7018
7019
7020
6.1
6.2
6.3
7.
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
E/E/PE SYSTEMS ASSURANCE ....................................................................................................... 23

7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
8.
Analysis .................................................................................................................................... 23
Testing...................................................................................................................................... 26
Verification ................................................................................................................................ 28
Validation .................................................................................................................................. 30
Independent Assessment .......................................................................................................... 33
Quality Assurance ..................................................................................................................... 36
Safety Management .................................................................................................................. 39
Configuration Management and Modification Control ................................................................. 41
Support Tools............................................................................................................................ 43
E/E/PE SYSTEM DEVELOPMENT: SYSTEM ASPECTS.................................................................... 46

8.1
8.2
9.
Lifecycle Issues and Documentation.......................................................................................... 16

Organisation, Roles and Responsibilities................................................................................... 19
Personnel Competence ............................................................................................................. 22
Additional Requirements for E/E/PE Architecture....................................................................... 46

Integration and Validation.......................................................................................................... 51
E/E/PE DEVELOPMENT: GENERIC HARDWARE ............................................................................. 59

9.1
9.2
9.3
Hardware Component Specification........................................................................................... 59

Hardware Component Implementation....................................................................................... 61
Hardware Component Validation ............................................................................................... 61
7037
10. E/E/PE DEVELOPMENT: CONFIGURABLE HARDWARE ................................................................. 63
7038
10.1 Requirements............................................................................................................................ 63
7039
11. E/E/PE SYSTEMS OPERATION AND MAINTENANCE...................................................................... 64
7040
7041
7042
7043
11.1
11.2
11.3
11.4
Planning & Organisation............................................................................................................ 64

System Deployment .................................................................................................................. 65
Operation and Maintenance including Performance Monitoring.................................................. 67
Modification............................................................................................................................... 70
7044
Annex A (normative) Techniques/Measures............................................................................................. 72
7045
Annex B (normative) Electronic/Electrical Component failure modes .................................................... 85
7046
Annex C (normative) Key Hardware/System Safety Roles and Responsibilities................................. 104
7047
Annex D (informative) Technical Recommendations for SIL3 and SIL4 functions ............................... 117
7048
Annex E (informative) Guidance on Programmable Devices ................................................................ 124
7049
Annex F................................................................................................................................................... 141
7050
Previously Developed Hardware (PDH) and Commercial Off The Shelf Hardware (COTSH) ............. 141
7051
Annex G (informative) Structure of Hardware/Systems Safety Cases................................................... 143
prEN 50126-4
7052
-4-
Annex H (informative) Bibliography of techniques ................................................................................ 157
7053
7054
List of Figures
7055
Figure 1 - Illustrative Development Lifecycle ................................................................................... 17
7056
Figure 2 - Illustrative Development and System Integration Lifecycle............................................... 18
7057
Figure 3 - Independence and Combination of Roles versus Safety Integrity Levels........................... 20
7058
Figure 4 Detection and negation of single faults ............................................................................ 48
7059
7060
Figure B.1 Example of a 4-terminal Resistor using a hybrid thick layer technique .......................... 88
7061
7062
Figure D.1 Single-fault and Multiple-fault detection conditions ...................................................... 121
7063
7064
Figure G.1 Structure of Technical Safety Report ......................................................................... 145
7065
7066
List of Tables
7067
Table 1 - Relation between Tool Class and applicable paragraphs of this section............................. 45
7068
7069
Table A.1 Lifecycle Issues and Documentation ............................................................................. 73
7070
Table A.2 Safety Planning and Quality Assurance Activities.......................................................... 74
7071
Table A.3 System Requirements Specification .............................................................................. 75
7072
Table A.4 Safety Organisation ...................................................................................................... 76
7073
Table A.5 Architecture of System/Subsystem/Equipment .............................................................. 77
7074
Table A.6 Design Features ........................................................................................................... 78
7075
Table A.7 Failure and Hazard Analysis Methods ........................................................................... 80
7076
Table A.8 Design and Development of System/Sub-system/Item .................................................. 81
7077
Table A.9 Design Phase Documentation....................................................................................... 81
7078
Table A.10 Verification and Validation of the System and Product Design ..................................... 82
7079
Table A.11 Application, Operation and Maintenance ..................................................................... 83
7080
Table A.12 Functional Testing....................................................................................................... 83
7081
Table A.13 Performance Testing................................................................................................... 83
7082
Table A.14 Hardware Safety Analysis ........................................................................................... 84
7083
7084
Table B.1 Resistor and adjustable resistor (excluding 4-terminal resistor)...................................... 93
7085
Table B.2 4 Terminal Resistors ..................................................................................................... 93
7086
Table B.3 Capacitor and adjustable capacitor (excluding 4-terminal capacitor).............................. 93
7087
Table B.4 4-Terminal Capacitors................................................................................................... 94
7088
Table B.5 Electromagnetic Components-Inductor.......................................................................... 94
7089
Table B.6 Electromagnetic Components-Transformer ................................................................... 94
7090
Table B.7 Electromagnetic Components-Transductor (saturable reactor or magnetic amplifier) ..... 95
-5-
prEN 50126-4
7091
Table B.8 Electromagnetic Components-Relays............................................................................ 96
7092
Table B.9 Diodes- Normal diode (power, signal, switching) ........................................................... 96
7093
Table B.10 Diodes-Zener Diodes .................................................................................................. 96
7094
Table B.11 Transistors-Bipolar...................................................................................................... 97
7095
Table B.12 Transistors-Field Effect (FET) ..................................................................................... 97
7096
Table B.13 Silicon - controlled rectifier (SCR) (thyristor) ................................................................ 98
7097
Table B.14 Bidirectional thyristor (triac)......................................................................................... 98
7098
Table B.15 Surge Suppressors - Voltage-dependent resistor (VDR) (varistor) ............................... 99
7099
Table B.16 Surge Suppressors-Protective Diode........................................................................... 99
7100
Table B.17 Surge Suppressors-Gas Discharge Arrester................................................................ 99
7101
Table B.18 Surge Suppressors-Air Gap Arrester........................................................................... 99
7102
Table B.19 Opto-electronic Components-Photo Diode .................................................................. 99
7103
Table B.20 Opto-electronic Components-Photo Transistor .......................................................... 100
7104
Table B.21 Opto-electronic Components- Light-emitting diode (LED) .......................................... 100
7105
Table B.22 - Opto-electronic Components- Optocoupler and self-contained fibre-optic system ....... 100
7106
Table B.23 Filters-Crystal ........................................................................................................... 100
7107
Table B.24 Filters-Mechanical Resonator (turning fork/reed/pendulum) ....................................... 101
7108
Table B.25 Interconnection Assemblies-Printed Circuit Board ..................................................... 101
7109
Table B.26 Interconnection Assemblies-Connector ..................................................................... 101
7110
Table B.27 Interconnection Assemblies-Cable and Wire ............................................................. 101
7111
7112
Table B.28 Interconnection Assemblies-Connection (soldered, welded, wrapped, crimped, clipped,

screwed) ............................................................................................................................... 101
7113
Table B.29 Interconnection Assemblies Fibreoptic Cable ......................................................... 102
7114
Table B.30 Interconnection Assemblies-Fibreoptic Connector ..................................................... 102
7115
Table B.31 Fuses ....................................................................................................................... 102
7116
Table B.32 Switches and Push/pull Buttons ............................................................................... 102
7117
Table B.33 Lamps...................................................................................................................... 102
7118
Table B.34 Batteries .................................................................................................................. 103
7119
Table B.35 Transducers/sensors................................................................................................ 103
7120
Table B.36 Integrated Circuits-Analogue Devices........................................................................ 103
7121
Table B.37 Integrated Circuits-Digital Devices............................................................................. 103
7122
Table B.38 Integrated Circuits-Microprocessors .......................................................................... 103
7123
7124
Table C.1 Hardware/System Requirements Manager Role Specification .................................... 104
7125
Table C.2 Hardware/System Designer Role Specification ........................................................... 105
7126
Table C.3 Hardware/System Implementer Role Specification ...................................................... 106
7127
Table C. 4 Hardware/System Tester Role Specification............................................................... 107
7128
Table C. 5 Hardware/System Verifier Role Specification ............................................................. 108
7129
Table C. 6 Hardware/System Integrator Role Specification.......................................................... 109
7130
Table C. 7 Hardware/System Validator Role Specification........................................................... 110
7131
Table C. 8 Hardware/System Assessor Role Specification .......................................................... 111
7132
Table C. 9 Hardware/System Project Manager Role Specification............................................... 112
prEN 50126-4
-6-
7133
Table C. 10 Hardware/System Configuration Manager Role Specification ................................... 113
7134
Table C. 11 Hardware/System Maintenance Manager Role Specification.................................... 114
7135
Table C. 12 Hardware/System Operations Manager Role Specification....................................... 115
7136
Table C. 13 Hardware/System Safety Manager Role Specification.............................................. 116
7137
7138
Table D.1 - Measures to detect faults in integrated circuits by means of periodic on-line testing .... 122
7139
Table E.1 Design (including all activities pre-synthesis)............................................................... 130
7140
Table E.2 - Synthesis..................................................................................................................... 130
7141
Table E.3 - Placement, Routing ..................................................................................................... 131
7142
Table Description for techniques/measures from E.1 Design...................................................... 135
7143
Table Description for techniques/ measures from E.2 Synthesis.................................................. 137
7144
7145
Table Description for techniques/ measures from E.3 - Placement, Routing and Layout Generation
............................................................................................................................................. 140
7146
Table H.1- Properties of Techniques.............................................................................................. 168
7147
-7-
prEN 50126-4
7148
Foreword
7149
7150
This European Standard was prepared by the Technical Committee CENELEC TC 9X, electrical and
electronic applications in railways.
7151
7152
The text of the draft was submitted to the formal vote and was approved by CENELEC as EN 50126-4
on 20xx-xx-xx.
7153
The following dates were fixed:
7154
7155
7156
latest date by which the EN has to be implemented

at national level by publication of an identical
national standard or by endorsement
(dop)
20xx-xx-xx
7157
7158
latest date by which the national standards conflicting

with the EN have to be withdrawn
(dow)
20xx-xx-xx
7159
This document supersedes EN 50129:2003.
7160
7161
The EN 50126 standard includes under the general title "Railway application - The specification and
demonstration of Reliability, Availability, Maintainability and Safety [RAMS]" the following parts:
7162
EN 50126-1: Generic RAMS process
7163
EN 50126-2: Systems Approach to Safety
7164
EN 50126-4: Functional Safety Electrical/Electronic/Programmable Electronic systems
7165
EN 50126-5: Functional Safety Software
7166
7167
This part 4 of EN 50126 standard covers the functional safety for E/E/PE. It is mainly based on
EN 50129:2003 which is withdrawn. In this standard, annexes D to H are informative.
7168
7169
This European Standard has been prepared under a mandate given to CENELEC by the European
Commission and supports the Directive 2008/57/EC.
7170
Introduction
7171
7172
7173
7174
7175
7176
7177
The standard EN 50126-1:1999 was produced to introduce the application of a systematic RAMS
management process in the railway sector. For safety related electronic systems for signalling the
standards EN 50128:2011 and EN 50129:2003 were produced. Through the application of these
standards and the experiences gained over the last years, the need for revision and restructuring
became apparent with a need to deliver a systematic and coherent approach to RAMS applicable to
all the railway application fields Signalling, Rolling Stock and Electric power supply for Railways
(Fixed Installations).
7178
7179
7180
The revision work improved the coherency and consistency of the standards, the concept of safety
management and the practical usage of the standard EN 50126, and took into consideration the
existing and related Technical Reports as well.
7181
7182
7183
This European Standard provides railway duty holders and the railway suppliers, throughout the
European Union, with a process which will enable the implementation of a consistent approach to the
management of reliability, availability, maintainability and safety, denoted by the acronym RAMS.
7184
7185
7186
Processes for the specification and demonstration of RAMS requirements are cornerstones of this
standard. This European Standard promotes a common understanding and approach to the
management of RAMS.
7187
7188
7189
EN 50126 is the railway sector specific application of IEC 61508. Meeting the requirements in this
European Standard is sufficient to ensure that additional compliance to IEC 61508 does not need to
be evaluated.
prEN 50126-4
-8-
7190
7191
With regard to safety, EN 50126-1 provides a Safety Management Process which is supported by
guidance and methods described in EN 50126-2.
7192
7193
7194
7195
7196
7197
EN 50126-1 and EN 50126-2 are independent from the technology used. EN 50126-4 and
EN 50126-5 provide guidance specific to safety related E/E/PE technology of railway applications.
Their application is determined through the application of the general RAMS process of EN 50126-1
and through the outcome of the safety related methods described in EN 50126-2. As far as safety is
concerned, the EN 50126 standard takes the perspective of functional safety. This does not exclude
other aspects of safety. However, these are not the focus.
7198
7199
7200
The aims set for revision of the EN 50126 standard required a better understanding of the systems
approach and improved methods for applying the safety management process described in
EN 50126-1. EN 50126-2 provides this guidance.
7201
7202
The application of this standard should be adapted to the specific requirements of the system under
consideration.
7203
7204
7205
7206
7207
This European Standard can be applied systematically by the railway duty holders and railway
suppliers, throughout all phases of the life cycle of a railway application, to develop railway specific
RAMS requirements and to achieve compliance with these requirements. The systems-level approach
developed by this European Standard facilitates assessment of the RAMS interactions between
elements of railway applications even if they are of complex nature.
7208
7209
7210
7211
This European Standard promotes co-operation between the stakeholders of Railways in the
achievement of an optimal combination of RAMS and cost for railway applications. Adoption of this
European Standard will support the principles of the European Single Market and facilitate European
railway inter-operability.
7212
7213
7214
7215
The process defined by this European Standard assumes that railway duty holders and railway
suppliers have business-level policies addressing Quality, Performance and Safety. The approach
defined in this standard is consistent with the application of quality management requirements
contained within the ISO 9000 series of International standards.
7216
-9-
7217
1. Scope
7218
This part of EN 50126
prEN 50126-4
7219
7220
7221
7222
7223
7224
7225
is intended to apply to all safety-related electronic (E/E/PE) railway systems/subsystem/hardware. However, the hazard analysis and risk assessment processes defined in EN
50126-1 and in this part are necessary for all railway systems/sub-systems/hardware, in order to
identify any safety requirements. The relevant methods are provided by EN 50126-2. If analysis
reveals that no safety requirements exist (i.e.: that the situation is non-safety-related), and
provided the conclusion is not revised as a consequence of later changes, this part of EN 50126
ceases to be applicable;
7226
7227
is applicable to safety-related electronic systems (including sub-systems and hardware) for

railway applications;
7228
7229
7230
7231
7232
is primarily applicable to systems/sub-systems/hardware which have been specifically designed

and manufactured for railway applications. It should also be applied, as far as reasonably
practicable, to general-purpose or industrial hardware (e.g.: power supplies, modems, etc.),
which is procured for use as part of a safety-related railway system. As a minimum, evidence
shall be provided in such cases to demonstrate:
7233
either that the hardware is not relied on for safety,
7234
or that the hardware can be relied on for those functions which relate to safety;
7235
applies
7236
7237
7238
7239
7240
to the specification, architecture, design, construction, implementation, integration,

manufacturing, installation, acceptance, operation, maintenance and modification/extension
phases of the system /subsystem and hardware, and also to individual sub-systems and
hardware within the overall system as determined by the process in EN 50126-1 and
supported by the methods in EN 50126-2.
7241
7242
7243
to generic sub-systems and hardware (both application-independent and those intended for a
particular class of application), and also to systems/sub-systems/hardware for specific
applications;
7244
addresses railway specifics;
7245
does not define
7246
RAMS targets, quantities, requirements or solutions for specific railway applications
7247
7248
rules or processes pertaining to the certification of railway products against the requirements
of this standard
7249
an approval process by the safety authority;
7250
does not specify requirements for ensuring system security.
7251
This part of EN 50126 is applicable
7252
7253
7254
7255
to the specification and demonstration of safety for all railway applications and at all levels of
such an application, as appropriate, from complete railway systems to major systems and to
individual and combined sub-systems and hardware components within these major systems,
including those containing software; in particular:
7256
to new systems
7257
7258
to new systems integrated into existing systems in operation prior to the creation of this
standard, although it is not generally applicable to other aspects of the existing system;
7259
7260
for modifications of existing systems in operation prior to the creation of this standard,
although it is not generally applicable to other aspects of the existing system.
7261
at all relevant phases of the life cycle of an application;
7262
for use by railway duty holders, railway suppliers, assessors and safety authorities.
prEN 50126-4
- 10 -
7263
7264
7265
7266
Application of EN 50126-4 follows from SIL allocation to system/subsystem/hardware through

applying the processes described in EN50126-1 and methods described by EN 50126-2. Given the
relative maturity of most electrical systems, this part of EN 50126 is largely applicable to Electronic
and Programmable Electronic sub-systems, systems and hardware.
7267
NOTE: Guidance on the applicability is given in the requirements of this standard.
7268
7269
Existing systems compliant with any version of former EN 50126, EN 50128 or EN 50129 shall not be
subject of reconsideration and are considered as compliant with this standard.
7270
7271
Railway applications mean Command, Control & Signalling, Rolling Stock and Fixed Installations for
Railways (e.g. Electric Power Supply).
- 11 -
prEN 50126-4
7272
7273
2. Normative references
7274
Normative references are given in EN 50126-1.
7275
Additionally the following apply:
7276
EN 50159
7277
EN 50121
7278
EN 50124
7279
EN 50125
7280
EN 50155
7281
3. Terms and Definitions
7282
7283
For the purposes of this document, the terms and definitions given in EN 50126-1 and the following
apply:
7284
3.1 change control board
7285
an entity that supervises and authorises change throughout the life cycle
7286
3.2 hardware component
7287
7288
7289
a hardware component is a constituent part of a sub-system which has well-defined interfaces and
behaviour with respect to the system/sub-system architecture and design and fulfils the following
criteria:
7290
7291
7292
7293
7294
a)
b)
c)
7295
3.3 maintenance manager
7296
7297
an entity responsible for implementation and upkeep of maintenance procedures and standards
ensuring safe and reliable performance of the system.
7298
3.4 release note
7299
7300
a documented record of all application and maintenance conditions for safe operation, across life
cycle phases
7301
3.5 safety manager
7302
an entity that is responsible for the correct accomplishment of the safety management
an electrical/electronic component or assembly delivering a specific function;

it covers a specific subset of sub-system requirements;
it is clearly identified and has an independent version inside the configuration management
system or is a part of a collection of components (e. g. subsystems) which have an independent
version
7303
7304
4. Abbreviations
7305
For the purposes of this document, the following abbreviations apply.
prEN 50126-4
- 12 -
7306
4.1 ASR:
assessor
7307
4.2 BPA:
Bent Pin Analysis
7308
4.3 CA:
Contingency Analysis
7309
4.4 CCD:
Cause Consequence Diagrams
7310
4.5 CCF:
Common Cause Failures
7311
4.6 CCFA:
Common Cause Failure Analysis
7312
4.7 CFMA:
Cable Failure Matrix Analysis
7313
4.8 ClD:
Class Diagram
7314
4.9 CoD:
Component Diagram
7315
4.10 COTSH Commercial off the Shelf Hardware
7316
4.11 CPLD :
Complex Programmable Logic Device
7317
4.12 CPU:
Central Processing Unit
7318
4.13 CT:
Certified Tool / Certified Translator
7319
4.14 DA:
Design Analysis
7320
4.15 DC:
Direct Current
7321
4.16 DES:
Designer
7322
4.17 DIA:
Design Interface Analysis
7323
4.18 DRC:
Design Rule Check
7324
4.19 DSL:
Domain Specific Language
7325
4.20 EAM:
Error Avoiding Method
7326
4.21 EPLD :
Erasable Programmable Logic Device
7327
4.22 ESD:
Electrostatic Discharge
7328
4.23 ETA:
Event Tree Analysis
7329
4.24 ETBA:
Energy Trace and Barrier Analysis
7330
4.25 FET:
Transistors-Field Effect
7331
4.26 FI:
Fagan Inspection
7332
4.27 FPGA:
Field-programmable Gate Array
7333
4.28 FT:
Fault Tree
7334
4.29 GD:
Graceful Degradation
7335
4.30 HAZOP: Hazard and Operability Study
7336
4.31 HOL:
Higher Order Logic
7337
4.32 HW:
Hardware
7338
4.33 IC:
Integrated Circuit
7339
4.34 ID:
Identifier
7340
4.35 IMP:
implementer
7341
4.36 INT:
integrator
7342
4.37 LCA:
Logic Cell Array
7343
4.38 LED:
Light-emitting Diode
7344
4.39 LRU:
Line Replaceable Unit
7345
4.40 MBT:
Model Based Testing
- 13 -
7346
4.41 MCS:
7347
4.42 O&SHA: Operating and Support Hazard Analysis
7348
4.43 ORR:
Operational Readiness Review
7349
4.44 PAL:
Programmable Array Logic
7350
4.45 PD:
Programmable Device
7351
4.46 PDH
Previously Developed Hardware
7352
4.47 PHA:
Preliminary Hazard Analysis
7353
4.48 PHL:
Preliminary Hazard List
7354
4.49 PJM:
project manager
7355
4.50 PLA:
Programmable Logic Array
7356
4.51 PLD :
Programmable Logic Device
7357
4.52 RBD:
Reliability Block Diagram
7358
4.53 RCA:
Root Cause Analysis
7359
4.54 RPN:
Risk Priority Number
7360
4.55 RQM:
requirements manager
7361
4.56 SB:
Safety Bag
7362
4.57 SCA:
Sneak Circuit Analysis
7363
4.58 SCD:
State Chart Diagram
7364
4.59 SCR:
Silicon-controlled Rectifier
7365
4.60 SeD:
Sequence Diagram
7366
4.61 SoPC:
System on Programmable Chip
7367
4.62 SRAC:
Safety Related Application Conditions
7368
4.63 SSA:
System Safety Analysis
7369
4.64 STA:
Static Timing Analysis
7370
4.65 SW:
Software
7371
4.66 TL:
Temporal Logic
7372
4.67 TO:
Test Oracle
7373
4.68 TPN:
Time Petri Nets
7374
4.69 TST:
tester
7375
4.70 UML:
Unified Modelling Language
7376
4.71 VAL:
validator
7377
4.72 VDR:
Voltage-dependent Resistor
7378
4.73 VER:
verifier
7379
4.74 VHDL:
Verilog Hardware Description Language
7380
4.75 WDR:
Walkthrough / Design Review
7381
Monte-Carlo Simulation
prEN 50126-4
prEN 50126-4
- 14 -
7382
5. Overall Framework of the Part 4
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
This part of the EN 50126 suite of standards addresses the application of the safety life cycle to
electronic hardware and integrated systems comprising electrical, electronic and programmable
electronic hardware and software. The principal purpose of this suite of standards is to support the
design, development, production and operation of acceptably safe products, systems and processes
aimed at railway applications. In this spirit, the approval, acceptance or certification constitute a
secondary potential benefit arising from compliance with this suite of standards. EN 50126-4 and EN
50126-5 of the standard suite address technology specific safety requirements and are
complementary to the requirements and the framework developed in EN 50126-1 and EN 50126-2
which shall also be complied with. The standard addresses the management, organisation and overall
electronic systems assurance including the safety requirements applicable to generic and
configurable hardware. The system aspects of electronic system development are also addressed
together with the requirements for manufacturing, deployment, operation and maintenance.
7395
7396
7397
The overall scope of this standard includes electrical, electronic and programmable electronic
hardware with fixed embedded logic, configurable hardware, integrated electronic systems comprising
hardware and software and electronic sub-systems with fixed or configurable logic.
7398
7399
7400
7401
7402
7403
A part from hardware, sub-systems and integrated systems, this standard places requirements for
management, organisation and the competency of the people who assume various roles in the safety
life cycle of electronic hardware and systems. This is in recognition of the major impact of the
organisational and competency aspects on the overall reduction of the systematic errors which are
otherwise likely to remain embedded in the design and production of electronic hardware and
systems.
7404
7405
7406
7407
The overall structure of this standard addresses key safety life cycle requirements in the design,
development, deployment and maintenance of electrical, electronic and programmable electronic
systems and hardware. Where appropriate, the structure in this standard is aligned with the software
standard in EN 50126-5 to provide a familiar and systematic approach across the related disciplines.
7408
7409
7410
Chapters 6 and 7 of this standard set out the common requirements for life cycle phases defined in
Chapters 8-11. The chapters are structured to state the objectives, inputs, requirements and the
outputs pertinent to each phase of the life cycle.
7411
7412
7413
Chapter 6 sets out the generic management and organisational requirements pertinent to electronic
systems addressing documentation, roles, requisite competencies, responsibilities of key personnel
and the required independence between the roles.
7414
7415
7416
Chapter 7 sets out the generic system assurance requirements addressing hardware, software and
hardware/software integration aspects including quality management, safety management,
configuration and change management and support tools.
7417
7418
Chapter 8 sets out the system aspects addressing requirements for system architecture,
implementation, integration, manufacturing, installation and commissioning and final acceptance.
7419
7420
7421
7422
7423
Chapter 9 sets out the requirements for the development of generic electronic system hardware
addressing architecture, design, implementation, integration, manufacturing, installation and
commissioning and validation. It additionally provides requirements and guidelines for development of
Safety Cases for generic product, generic application, specific application and cross-acceptance for
systems and hardware.
7424
7425
7426
7427
7428
Chapter 10 sets out the requirements for the development of configurable electronic system hardware
addressing architecture, design, implementation, integration, manufacturing, installation and
commissioning and validation. Many of the requirements of the generic electronic systems and
hardware are equally applicable to configurable variants. This chapter provides new requirements
compared with the EN50129:2003.
7429
7430
7431
Chapter 11 sets out the requirements for a safe deployment, operation and maintenance pertinent to
electronic systems and hardware in railways. It addresses the organisational as well as processes to
ensure a safe system is safely put into use and maintained to operate safely whilst undergoing
- 15 -
prEN 50126-4
7432
7433
retrofits and maintenance (This chapter provides new requirements compared with the
EN50129:2003).
7434
7435
The annexes to this standard provide normative and informative requirements and guidance
considered supplementary to the main sections of the standard. These comprise:
7436
Annex A provides normative requirements on hardware techniques and measures,
7437
Annex B provides normative requirements on failure modes of general electronic components,
7438
7439
7440
Annex C provides normative requirements on key safety roles and competencies for development of
electronic hardware and systems (This Annex provides new requirements compared with the
EN50129:2003),
7441
7442
Annex D provides informative guidance on attaining physical independence and fault detection for
SIL3 and SIL 4 functions,
7443
7444
Annex E provides informative guidance on firmware development for PLDs (This Annex provides new
requirements compared with the EN50129:2003),
7445
7446
Annex F provides normative requirements on previously developed and commercial off the shelf
hardware/systems (This chapter provides new requirements compared with the EN50129:2003),
7447
7448
Annex G provides informative guidance on the structure of electronic systems & hardware safety
cases (this Annex provide new guidance on cross-acceptance compared with the EN50129:2003)
7449
and
7450
7451
Annex F provides an informative updated generic bibliography of the hardware and system design
and development techniques.
prEN 50126-4
- 16 -
7452
7453
6. E/E/PE SYSTEMS MANAGEMENT AND ORGANISATION
7454
6.1 Lifecycle Issues and Documentation
7455
6.1.1 Objective
7456
7457
6.1.1.1 To structure the development of the system/sub-system and hardware components into
defined phases and activities.
7458
7459
6.1.1.2 To record all information pertinent to the system/sub-system and hardware components
throughout the life cycle of the system/sub-system and hardware component.
7460
NOTE: All phases of the life cycle can be iterative.
7461
6.1.2 Input
7462
1) Quality Assurance Plan
7463
6.1.3 Deliverables
7464
1) Quality Management Report
7465
6.1.4 Requirements
7466
7467
6.1.4.1 A life cycle model for the development of system/sub-system and hardware components shall
be selected. It shall be detailed in the Quality Assurance Plan in accordance with Clause 7.6.
7468
7469
6.1.4.2 The life cycle model shall take into account the possibility of iterations in and between
phases.
7470
7471
6.1.4.3 Quality Assurance procedures shall run in parallel with life cycle activities and use the same
terminology.
7472
7473
7474
6.1.4.4 All activities to be performed during a phase shall be defined prior to the commencement of
the phase. Each phase of the system/sub-system and/or hardware component life cycle shall be
divided into elementary tasks each of which has a well defined input, output and activity.
7475
7476
6.1.4.5 All documents shall be structured to allow continued expansion in parallel with the
development process.
7477
7478
6.1.4.6 For each document, traceability shall be provided in terms of a unique reference number and
a defined and documented relationship with other documents.
7479
7480
6.1.4.7 Each term, acronym or abbreviation shall have the same meaning in every document. If, for
historical reasons, this is not possible, the different meanings shall be listed and the references given.
7481
7482
6.1.4.8 Except for documents relating to pre-existing systems/sub-systems or hardware components

(see EN 50126-1, sub-clause 7.4.6), each document shall be written according to the following rules:
7483
7484
it shall contain or implement all applicable conditions and requirements of the preceding
document with which it has a hierarchical relationship;
7485
it shall not contradict the preceding document.
- 17 -
prEN 50126-4
7486
7487
6.1.4.9 The contents of all documents shall be recorded in a form appropriate for manipulation,
processing and storage.
7488
7489
7490
6.1.4.10 When documents which are produced by independent roles are combined into a single
document, the relation to the parts produced by any independent role shall be traced within the
document.
7491
7492
7493
6.1.4.11 In accordance with 6.1.4.10, documents may be combined or divided. Some development
steps may be combined, divided or, when justified, eliminated, at the discretion of the Project
Manager and with the agreement of the Validator and the Assessor (see 7.5.4.8).
7494
7495
6.1.4.12 Where any alternative life cycle or documentation structure is adopted it shall be established
that it meets all the objectives and requirements of this European Standard.
7496
7497
7498
6.1.4.13 During development (and depending upon the size of the system) the documentation may
be sub-divided into a number of child documents and be naturally added to, as the detailed needs of
the development become clearer.
1
Concept
SystemDefinition&
Operational Context
RiskAnalysis&
Evaluation
10
SystemAcceptance
Specificationof 4
SystemRequirements
SystemValidation
Architectureand Apportionment
of SystemRequirements
Designand
Implementation
Manufacture
Integration
7499
7500
7501
7502
7503
Figure 1 - Illustrative Development Lifecycle
11
Operation,
Maintenanceand
Performance
Monitoring
12
Decommissioning
prEN 50126-4
- 18 -
7504
7505
7506
Figure 2 - Illustrative Development and System Integration Lifecycle
- 19 -
prEN 50126-4
7507
6.2 Organisation, Roles and Responsibilities
7508
6.2.1 Objective
7509
7510
To ensure that all personnel who have responsibilities for the system/sub-system and hardware
component are organised, empowered and capable of fulfilling their responsibilities.
7511
6.2.2 Input
7512
7513
6.2.3 Deliverables
7514
1) Quality Management Report
7515
6.2.4 Requirements
7516
7517
6.2.4.1 As a minimum, the supplier shall implement EN ISO 9001 chapter 4 and 5 dealing with the
organisation and management of the personnel and responsibilities.
7518
6.2.4.2 Responsibilities shall be compliant with the requirements defined in Annex C and assessed.
7519
7520
7521
6.2.4.3 The personnel assigned to the roles involved in the development or maintenance of the
system/sub-system and hardware component shall be recorded in a Quality Management Report or in
another document referenced by the Quality Assurance Plan.
7522
6.2.4.4 An Assessor shall be appointed by the supplier, the customer or the Safety Authority.
7523
7524
7525
6.2.4.5 The assessor may be part or not of the supplier organization, but shall be in any case
independent from the project organizations (Design, Testing, Integration, Safety, Verification and
Validation). National legislation / Safety Authority may ask for additional independence requirements.
7526
NOTE: The independent assessment body may be identified by national legislation.
7527
7528
6.2.4.6 The Assessor shall be given authority to perform the independent assessment of the
system/sub-system and/or hardware component.
7529
7530
6.2.4.7 The Validator shall give agreement/disagreement for the system/sub-system and/or hardware
component release.
7531
7532
7533
6.2.4.8 Throughout the system/sub-system and hardware component life cycle, the parties involved
shall be independent, to the extent required by the safety integrity level, in accordance with Figure 3
and 6.2.4.9 to 6.2.4.14.
7534
7535
prEN 50126-4
- 20 -
7536
7537
7538
Figure 3 - Independence and Combination of Roles versus Safety Integrity Levels
- 21 -
prEN 50126-4
7539
7540
6.2.4.9 The preferred organisational structure for SIL 3 and SIL 4 is shown in Figure 3. However, the
following alternatives may apply:
7541
7542
7543
7544
7545
7546
7547
7548
7549
a) The Validator may be the same person as the Verifier, but still maintaining independence from the
Project Manager. In this case the Verifiers output shall be reviewed by another competent person
with the same level of independence as the Validator. This organisational option shall be subject to
Assessors approval.
b) The Verifier may be the same person as Integrator and Tester under the Project Manager, in which
case the role of Validator shall check the adequacy of the documented evidence from integration
and testing with the specified verification objectives, hence maintaining two levels of checking
within the project organisation.
7550
7551
6.2.4.10 The preferred organisational structure for SIL 1 and SIL 2 is shown in Figure 3. However,
the following alternatives may apply:
7552
7553
7554
7555
7556
7557
7558
7559
a) The Verifier may be the same person as the Integrator and the Tester, in which case the role of
Validator shall include reviewing the Verifiers outputs hence maintaining two levels of checking
within the project organisation.
b) The Validator may be the same person as the Verifier, Integrator and Tester, in which case the
Validator shall be independent from the Project Manager. In this case the Verifiers output shall be
reviewed by another competent person with the same level of independence as the Validator. This
organisational option shall be subject to Assessors approval.
7560
7561
6.2.4.11 The preferred organisational structure for SIL 0 that has a safety impact below SIL 1 is
shown in Figure 3. However, the following alternative may apply:
7562
7563
7564
a) RQM, DES, IMP, INT, TST and VER can be the same person and the Validator shall be
independent.
7565
6.2.4.12 The Verifier, Integrator and Tester can also report to Validator.
7566
7567
6.2.4.13 An entity performing the roles Requirements Manager, Designer, Implementer for one
component can perform the roles Tester and Integrator for a different component.
7568
7569
7570
6.2.4.14 The roles and the assigned persons for the verifier and the validator shall be defined at the
project level. These roles and the assigned persons should ideally remain unchanged throughout the
development project.
prEN 50126-4
- 22 -
7571
7572
6.3 Personnel Competence
7573
6.3.1 Objective
7574
7575
7576
To ensure that all personnel who have responsibilities for the system/sub-system and/or hardware
component are competent to discharge those responsibilities by demonstrating the ability to perform
relevant tasks correctly, efficiently and consistently to a high quality and under varying conditions.
7577
6.3.2 Input
7578
7579
6.3.3 Deliverables
7580
1) Quality Assurance Plan (updated)
7581
6.3.4 Requirements
7582
7583
7584
7585
6.3.4.1 The key competencies required for each role in the development of a system/sub-system
and/or hardware component shall be compliant with the requirements defined in Annex C. If additional
experience, capabilities or qualifications are required for a role in the life cycle of a system/subsystem
and/or hardware component, these shall be defined in the Quality Assurance Plan.
7586
7587
7588
6.3.4.2 Documented evidence of personnel competence, including technical knowledge,

qualifications, relevant experience and appropriate training, shall be maintained by the suppliers
organisation in order to demonstrate appropriate safety organisation.
7589
7590
6.3.4.3 The organisation shall maintain procedures to manage the competence of personnel to suit
appropriate roles in accordance to existing quality standards.
7591
7592
7593
7594
7595
7596
6.3.4.4 Once it has been proved to the satisfaction of an assessor or by a certification that
competence has been demonstrated for all personnel appointed in various roles, each individual will
need to show continuous maintenance and development of competence. This could be demonstrated
by keeping a logbook showing the activity is being regularly carried out correctly, and that additional
training is being undertaken in accordance with EN ISO 9001 sub-clause 6.2.2, Competence, training
and awareness".
7597
- 23 -
prEN 50126-4
7598
7599
7. E/E/PE SYSTEMS ASSURANCE
7600
7.1 Analysis
7601
7.1.1 Objective
7602
7603
7604
7605
7606
7607
7608
7609
7.1.1.1 The objective of system/sub-system or hardware component analysis is to ascertain the

behaviour or performance of a system/sub-system or hardware component through detailed
examination of its architecture and components. In general, system/sub-system or hardware
component analysis involves carefully examining the system/sub-system or hardware component,
and any documentation related to it, with the aim of deducing its correct and safe operation as a
logical consequence of the design decisions. In particular, analysis concerns the ability of the
system/sub-system or hardware component to meet its specified safety requirements in the event of
random hardware failures and, as far as reasonably practicable, systematic failures (see 8.2.4.8).
7610
7611
7612
7613
7.1.1.2 Analysis complements or supports other activities during the whole system life cycle, albeit
not replacing these activities. Analysis is in this context neither a separate assurance activity, nor
restricted to system analysis on the basis of a system definition, but more generally the use of
analytical means to support the examination needed in other activities.
7614
NOTE: Analysis may complement or support other activities in different ways, as indicated in the following.
7615
7616
a) Analysis is sometimes an activity following testing, requiring the test cases and their results to be recorded. Accordingly,
testing is complemented by an examination based on the use of analysis techniques suitable for evaluating test results.
7617
7618
b) Verification is typically carried out through a combination of tests, checks and analysis, using both dynamic and static
techniques and models.
7619
7620
c) Validation typically involves the use of analysis techniques suitable for determining whether the product fits the user needs.
Analysis complements testing as a validation activity.
7621
7622
7623
d) independent assessment can be considered a special process of analysis, followed by judgment, involving the use of
analysis techniques suitable for determining whether the product is of the defined safety integrity level and fit for its
intended application.
7624
7625
e) Modification control involves analysing the information collected in problem reports to identify the causes of problems,
followed by change impact analysis to determine the consequences of the change prior to implementation.
7626
7627
f)
7628
7629
7630
7631
g) In general, development involves analysis of requirements and the derivation of test cases from these requirements,
involving the use of analysis techniques suitable for deducing the properties or behaviour of a system/sub-system or
hardware component on the basis of its requirements, including analysis of hardware/software interactions and different
levels of system/sub-system integrations.
7632
7.1.2 Input
7633
Not applicable (see clauses 8 and 9 for link between the specific documents).
7634
7.1.3 Deliverables
7635
7636
7637
7638
This sub-clause provides guidance for the contents of output documents from other assurance
activities, and does not directly require any other output documents. The analysis shall however be
documented, either as a separate document or as part of the documentation of the activity it
complements or supports.
Support tools are justified by analysing the assurance activities performed, involving the use of analysis techniques suitable
for identifying possible significant failures.
prEN 50126-4
- 24 -
7639
7.1.4 Requirements
7640
7641
7642
7643
7.1.4.1 Analysis shall be performed by the role, defined by the type of activity it complements or
supports, and constrained by the requirements given in this standard to this type of activity, i.e.
analysis complementing testing shall normally be performed by the tester, analysis supporting
verification shall normally be performed by the verifier, etc.
7644
7.1.4.2 The analysis shall be performed using a technique, or a combination of techniques, that
7645
a) is well documented;
7646
b) has a scientific basis;
7647
c) ensures repeatability;
7648
d) facilitates creativity as well as systematics.
7649
7650
7651
7.1.4.3 The analysis techniques shall be chosen on basis of the characteristics of the analysis
problem, i.e. the characteristics of the chosen technique or combination of techniques shall match the
characteristics of the problem.
7652
7653
7.1.4.4 If no single analysis technique matches the characteristics of the analysis problem, a
combination of analysis techniques shall be chosen.
7654
7.1.4.5 The analysis shall be based on models that are suitable for the analysis problem.
7655
7.1.4.6 The level of formality of the models shall be suitable for the rigidity required of the analysis.
7656
7657
7.1.4.7 The level of formality of the analysis techniques shall match the level of formality of the
models used as a basis for the analysis.
7658
7659
NOTE: Analysis techniques can be classified as informal, semiformal and formal, partly based on the level of formality of the
models used.
7660
7661
7.1.4.8 Analysis shall complement testing at least in cases where testing alone does not give
complete coverage.
7662
7663
7.1.4.9 Analysis complementing testing shall be performed in such a way that testing and analysis
together give complete coverage.
7664
7665
7.1.4.10 Analysis shall be based on examining models of the system/sub-system or hardware

component, in contrast to executing the system/sub-system or hardware component.
7666
NOTE: Analysis generally characterizes classes of executions, while testing characterizes single executions.
7667
7668
7669
7.1.4.11 System/sub-system or hardware component analysis shall be documented by an analysis

report, either as a separate document or as part of the documentation of the activity it complements or
supports. Requirements 7.1.4.11.1 and 7.1.4.11.2 refer to the Analysis Report.
7670
7.1.4.11.1 Each Analysis Report shall document the following:
7671
a) analysis objectives;
7672
b) the scope of the analysis and the results achieved;
7673
c) the activities complemented or supported by the analysis, and in what way;
7674
d) the analysis techniques and models used;
7675
e) analysis environment, tools, configuration and programs;
7676
f) the analysis process;
7677
g) the roles and responsibilities of those involved in the analysis process.
- 25 -
prEN 50126-4
7678
7.1.4.11.2 Each Analysis report shall be produced as follows:
7679
a) the analysis shall be repeatable and, if practicable, be performed by automatic means;
7680
b) the choice of analysis process, techniques, tools and models shall be justified;
7681
c) analysis scripts for automated analysis shall be verified;
7682
7683
d) the identity and configuration of all items involved (systems/subsystems or hardware components,
analysis equipment, equipment calibration) shall be documented;
7684
e) the completeness of the analysis shall be evaluated.
prEN 50126-4
- 26 -
7685
7686
7.2 Testing
7687
7.2.1 Objective
7688
7689
7690
7691
The objective of system/sub-system or hardware component testing, as performed by the Tester

and/or Integrator, is to ascertain the behaviour or performance of a system/sub-system or hardware
component against the corresponding test specification to the extent achievable by the selected test
coverage.
7692
7.2.2 Input
7693
7694
7.2.3 Deliverables
7695
7696
This sub-clause does not directly require any output documents. It provides guidance for the contents
for the following documents:
7697
1) Sub-system Integration Test Specification
7698
2) Sub-system Integration Test Report
7699
3) Software/Hardware Integration Test Specification
7700
4) Software/Hardware Integration Test Report
7701
5) Hardware Component Test Specification
7702
6) Hardware Component Test Report
7703
7704
7.2.4 Requirements
7705
7706
7.2.4.1 A Test Specification shall be written, under the responsibility of the Tester. Requirements
from 7.2.4.1.1 to 7.2.4.1.3 refer to the Test Specification.
7707
7708
7.2.4.1.1 Measurement equipment used for testing shall be calibrated appropriately. Any tools,
hardware or software, used for testing shall be shown to be suitable for the purpose.
7709
7.2.4.1.2 Each Test Specification shall document the following:
7710
a) test objectives;
7711
b) the requirements which are covered by the test specification;
7712
c) test cases, test data and expected result;
7713
d) types of tests to be performed;
7714
e) the selection and utilisation of the test equipment;
7715
f) test environment, tools, configuration and programs;
7716
g) test criteria on which the completion of the test will be judged;
7717
h) the criteria and degree of test coverage to be achieved;
7718
i) the roles and responsibilities of those involved in the test process.
- 27 -
prEN 50126-4
7719
7720
7.2.4.1.3 If, for completion of the tests, analyses are needed these analyses shall be carried out in
accordance with clause 7.1.
7721
7722
7.2.4.2 A Test Report shall be written, under the responsibility of the Tester. Requirements from
7.2.4.2.1 to 7.2.4.2.3 refer to the Test Report.
7723
7724
7.2.4.2.1 The Test Reports shall fully state the related baselines for system/sub-system, hardware,
that have been tested.
7725
7.2.4.2.2 A Test Report shall be produced as follows:
7726
7727
a) the Test Report shall state the test results and whether the objectives and criteria of the Test
Specification have been met. Deviations shall be recorded;
7728
b) if there is a failure, the circumstances for the failure and its correction shall be documented;
7729
7730
c) test cases and their results shall be recorded, preferably in a machine-readable form for
subsequent analysis;
7731
d) tests shall be repeatable and, if practicable, be performed by automatic means;
7732
e) test scripts for automatic test execution shall be verified;
7733
7734
7735
f) the identity and configuration of all items involved (documentation, including the related test
specifications, system/subsystem, hardware components, test equipment, calibration of the test
equipment) shall be documented;
7736
7737
g) an evaluation of the test coverage and test completion shall be provided and any deviations
noted;
7738
h) a recommendation on the necessity for the repetition of parts of the tests or the complete tests;
7739
i) the version of the Test Specification used shall be documented;
7740
j) the test location, date of execution and the name and role of the persons performing the test.
7741
7742
7.2.4.2.3 If, for completion of the tests, analyses are carried out, these analyses shall be
documented in accordance with clause 7.1.
7743
prEN 50126-4
- 28 -
7744
7745
7.3 Verification
7746
7.3.1 Objective
7747
7748
7749
7750
7751
The objective of system/sub-system or hardware component verification is to examine and arrive at a

judgment based on evidence that output items (process, documentation, system/sub-system or
hardware components) of a specific development phase fulfil the applicable plans and the
requirements of that phase as specified in this standard, with respect to completeness, correctness
and consistency. These activities are managed by the Verifier.
7752
7.3.2 Input
7753
7754
7.3.3 Deliverables
7755
1) System Verification Plan
7756
7757
This sub-clause does not directly require the system verification reports as output documents, but
provides guidance for the contents for the following verification documents:
7758
a) System Requirement Verification Report (see Part 1)
7759
b) System Architecture Verification Report (see Part 1 and 8.1)
7760
c) Hardware Design Component Verification Report (see 9.1)
7761
d) Software/Hardware Integration Verification Report (see 8.2.4.8)
7762
7.3.4 Requirements
7763
7764
7.3.4.1 Verification shall be carried out by one or more persons who are independent as described in
sub-clause 6.2.
7765
7766
7.3.4.2 Verification shall be documented by at least a System Verification Plan and one or more
(process-related) Verification Reports, as defined in the following.
7767
7768
7.3.4.3 A System Verification Plan shall be written, under the responsibility of the Verifier.
Requirements from 7.3.4.3.1 to 7.3.4.3.5 refer to the System Verification Plan.
7769
7770
7.3.4.3.1 The System Verification Plan shall describe the activities to be performed to ensure proper
verification and that particular design or other verification needs are suitably provided for.
7771
7772
7773
7.3.4.3.2 The System Verification Plan shall describe the activities to be performed to ensure
correctness and consistency with respect to the input to that phase. These include testing, integration
and documents reviewing against expected properties, as defined in this standard.
7774
7775
7.3.4.3.3 In each life cycle phase the Verifier shall ensure that all requirements regarding system,
subsystem, hardware or process, related to that phase, are met. This includes (see Annex C):
7776
7777
7778
1. to check the adequacy (completeness, consistency, correctness, relevance and traceability) of the
documented evidence from review, integration and testing with the specified verification
objectives;
7779
7780
7781
2. to identify anomalies, classify these in risk, impact or severity and/or weight as appropriate and
record and communicate these to the relevant change control board for evaluation and decision,
see also sub-clause on role of the verifier;
7782
7783
3. to manage the verification process (review, integration and testing) and ensure independence of
activities as required;
- 29 -
prEN 50126-4
7784
4. to develop and maintain records on the verification activities;
7785
5. to develop a verification report for each phase stating the outcome of the verification activities.
7786
7787
7.3.4.3.4 The results of each verification shall be retained in a format defined or referenced in the
System Verification Plan.
7788
7.3.4.3.5 The System Verification Plan shall address the following:
7789
7790
7791
a) the selection of verification strategies, tools and techniques (to avoid undue complexity in the
independent assessment of the verification and testing, preference shall be given to the selection
of techniques which are in themselves readily analysable);
7792
b) the selection and utilisation of the test equipment;
7793
c) the selection and documentation of verification activities;
7794
d) the evaluation of verification results gained;
7795
e) the evaluation of the requirements;
7796
f) the roles and responsibilities of those involved in the test process;
7797
g) the degree of the test coverage required to be achieved;
7798
7799
h) the structure and contents of each verification step in a way that facilitates review against the
System Verification Plan, especially for
7800
a. System Requirement Verification Report (see Part 1)
7801
b. System Architecture Verification Report (see Part 1 and 8.1)
7802
c.
7803
d. Software/Hardware Integration Verification Report (see 8.2.4.8)
Hardware Design Component Verification Report (see 9.1)
7804
7805
7806
7.3.4.4 The System Verification Reports (see 7.3.3) shall be written, under the responsibility of the
Verifier, on the basis of the input documents. Requirement 7.3.4.4.1 refers to the System Verification
Reports.
7807
7.3.4.4.1 Each Verification Report shall document the following:
7808
a) the name of the Verifier
7809
b) reference to the verification task(s) in the verification plan;
7810
c) the identity and configuration of the items verified;
7811
d) the identity and configuration of the items used as basis for the verification;
7812
e) items which do not conform to the specifications;
7813
f) items with significant lacks in terms of one or more of the following criteria:
7814
1. completeness,
7815
2. consistency,
7816
3. correctness,
7817
4. relevance and
7818
5. traceability.
prEN 50126-4
- 30 -
7819
g) detected errors or deficiencies;
7820
7821
h) the fulfilment of, or deviation from, the System Verification Plan (in the event of deviation the
Verification Report shall explain whether the deviation is critical or not);
7822
i) assumptions if any;
7823
j) a summary of the verification results.
7824
7825
7.3.4.4.2 Analyses, if any, carried out during the verification shall be documented in accordance with
clause 7.1.
7826
7.4 Validation
7827
7.4.1 Objective
7828
7829
7830
7.4.1.1 The objective of validation is to demonstrate that the processes and their outputs are such
that the system/sub-system or hardware component is of the defined safety integrity level, fulfils the
related TFFR and the requirements, and is fit for its intended application.
7831
7832
7833
7834
7.4.1.2 The main validation activities are to demonstrate by analysis and/or testing that all
system/subsystem/hardware component requirements are specified, implemented, tested and fulfilled
as required by the assigned SIL, and to evaluate the safety criticality of all anomalies and nonconformities based on the results of reviews, analyses and tests.
7835
7836
7.4.1.3 This sub-clause deals with system/sub-system and hardware component validation. These
activities are respectively performed by the Validator.
7837
7838
7.4.1.4 For systems/sub-systems incorporating software, Software Validation as defined in EN

50126-5 clause 7.4 shall be performed.
7839
7.4.2 Input
7840
7841
All documentation for system/sub-system and/or hardware components as specified in this European
Standard.
7842
7.4.3 Deliverables
7843
1) Validation Plan
7844
2) Hardware Validation Plan
7845
3) Validation Report
7846
4) Hardware Validation Report
7847
7848
NOTE: Especially for complex systems/subsystems, all HW-related validation activities can be reported in a separate
document, called Hardware Validation Report, to be referred by the Validation report.
- 31 -
prEN 50126-4
7849
7.4.4 Requirements
7850
7851
7.4.4.1 The Validation activities shall be developed and performed, with their results evaluated, by a
Validator with an appropriate level of independence as defined in clause 6.2.
7852
7853
7.4.4.2 Validation shall be documented with, at least, a Validation Plan and a Validation Report, as
defined in the following.
7854
7855
7.4.4.3 A Validation Plan shall be written, under the responsibility of the Validator, on the basis of the
input documents. Requirements from 7.4.4.3.1 to 7.4.4.3.6 refer to the Validation Plan.
7856
7857
7.4.4.3.1 The Validation Plan shall include the justification of the selection of techniques from
Annex A, Table A.10.
7858
7859
7.4.4.3.2 The Validation Plan shall include a summary justifying the validation strategy chosen. The
justification shall include consideration, according to the required safety integrity level, of:
7860
a) manual or automated techniques or both;
7861
b) static or dynamic techniques or both;
7862
c) analytical or statistical techniques or both;
7863
d) testing in a real or simulated environment or both.
7864
7865
7866
7.4.4.3.3 The Validation Plan shall identify the steps necessary to demonstrate the adequacy of any
specification of the system/sub-system or hardware component to be validated, in fulfilling the
requirements set out in the System Requirements Specification.
7867
7868
7.4.4.3.4 The Validation Plan shall identify the steps necessary to demonstrate the adequacy of the
System Test Specification as a test against the System Requirements Specification.
7869
7870
7871
7.4.4.3.5 The Validation Plan shall include a summary justifying the validation or testing strategy
chosen for the hardware. The justification shall include consideration, according to the required safety
integrity level.
7872
7873
7.4.4.3.6 If, for completion of the tests, analyses are needed these analyses shall be carried out in
accordance with clause 7.1.
7874
7875
7.4.4.4 A Validation Report shall be written, under the responsibility of the Validator. Requirements
from 7.4.4.4.1 to 7.4.4.4.14 refer to the Validation Report.
prEN 50126-4
- 32 -
7876
7.4.4.4.1 The results of the validation shall be documented in the Validation Report.
7877
7878
7.4.4.4.2 The Validation Report shall fully state the related baselines for system/sub-system and/or
hardware components, that have been validated.
7879
7880
7.4.4.4.3 The Validation Report shall contain the evaluation of the requirements of the validated item
against the intended environment/use.
7881
7882
7.4.4.4.4 The Validation Report shall contain the evaluation of the validated item (system/sub-system
and hardware components) against its requirements to ensure all of these are fulfilled.
7883
7884
7885
7.4.4.4.5 The Validation Report shall contain the evaluation of the conformity of the development
process and of the validated item against the requirements of this European Standard including the
assigned safety integrity level.
7886
7887
7.4.4.4.6 The Validation Report shall contain the evaluation of the correctness, consistency and
adequacy of the analyses and verification activities.
7888
7889
adequacy of test cases and executed tests.
7890
7891
7.4.4.4.8 The Validation Report shall contain the evidence that all Validation Plan activities have
been carried out and shall capture and justify any deviation from the Validation Plan.
7892
7893
7.4.4.4.9 The Validator shall also check whether the normative required Techniques and Measures
have been applied correctly according to the safety integrity level.
7894
7.4.4.4.10 The Validation Report shall identify and classify all deviations in terms of risk (impact).
7895
7896
adequacy of Hardware Manufacturing Acceptance Test Specification.
7897
7898
7.4.4.4.12 The Validation Report shall contain the evidence of the correctness, consistency and
adequacy of installation, commissioning, maintenance and operation manuals.
7899
7900
7901
7.4.4.4.13 The Validation Report shall contain a collection of results, restrictions and deviations, if
any, from Software Validation Report and Hardware Validation Report, and their evaluation against
System Requirements and intended environment/use.
7902
NOTE: Constraints derived from the deviations are documented in the Release Note.
7903
7.4.4.4.14 Analyses shall be documented in accordance with clause 7.1.
7904
7905
7.4.4.5 A Hardware Validation Report shall be written, under the responsibility of the Validator, on
the basis of the input documents. Requirement 7.4.4.5.1 refers to the Hardware Validation Report.
7906
7907
adequacy of qualification according EN 50125 or EN 50155, EN 50121 and EN 50124.
7908
7.4.4.6 The Validator shall be able to require or perform reviews, analyses and tests.
7909
7910
7.4.4.7 The Validator shall communicate all deviations to the relevant change control board for
evaluation and decision.
7911
7912
7.4.4.8 The system/sub-system or hardware component shall only be released for operation after
authorisation by the Validator.
7913
7.4.4.9 Simulation and modelling may be used to supplement the validation process.
- 33 -
prEN 50126-4
7914
7915
7.5 Independent Assessment
7916
7.5.1 Objective
7917
7918
7919
To arrive at a judgement through evaluation that the life cycle processes and their outputs are such
that the system/sub-system or hardware component is of the defined safety integrity level 1-4 and is
fit for its intended application.
7920
7.5.2 Input
7921
1) System Definition
7922
2) System Requirements Specification
7923
3) All other documents necessary to carry out the independent assessment process (see Table A.1).
7924
7.5.3 Deliverables
7925
1)
System Assessment Plan
7926
2)
System Assessment Report
7927
7.5.4 Requirements
7928
7929
7.5.4.1 The independent assessment of systems/sub-systems or hardware components shall be

carried out by an Assessor who is independent as defined in clause 6.2.
7930
7931
7932
7.5.4.2 For SIL 0 system/sub-system or hardware components, requirements of this standard shall
be fulfilled but where a certificate stating compliance with EN ISO 9001 is available, no independent
assessment will be required.
7933
7934
7935
7.5.4.3 A system/sub-system or hardware component with an Assessment Report from another

Assessor does not have to be an object for a new independent assessment. The independent
assessment shall include the following:
7936
7937
a) that the system/sub-system or hardware component is of the required safety integrity level and that
it is fit for its intended use within the intended environment;
7938
b) a check that all relevant constraints are fulfilled.
7939
7940
NOTE: All constraints in using a system/sub-system or hardware component with an Assessment Report from another
Assessor are documented in a Release Note (see3.7).
7941
7942
7.5.4.4 The Assessor shall have access to the development process and all project related
documentation.
7943
7944
7945
7946
7.5.4.5 A System Assessment Plan shall be written, under the responsibility of the Assessor, on the
basis of the input documents from 7.5.2. Where appropriate, an existing documented generic system
assessment plan or procedure may be used. The requirements from 7.5.4.5.1 to 7.5.4.5.2 refer to the
System Assessment Plan.
7947
7.5.4.5.1 The System Assessment Plan shall include the following aspects:
7948
aspects with which the independent assessment deals;
7949
activities throughout the independent assessment process and their link to engineering activities;
7950
documents to be taken into consideration;
7951
statements on pass/fail criteria and the way how to deal with non-conformance cases;
7952
requirements with regard to contents and form of the System Assessment Report.
prEN 50126-4
- 34 -
7953
7.5.4.5.2 Analyses shall be carried out in accordance with clause 7.1.
7954
7955
7956
7.5.4.6 The Assessor shall assess that the analysis from 8.1 on failures is complete and the
system/sub-system or hardware component is fit for its intended use and responds correctly to safety
related failures derived from the System Requirements Specification.
7957
NOTE: Related failures are addressed by System Hazard Analysis.
7958
7959
7960
7.5.4.7 The Assessor shall assess if an appropriate development process and an appropriate set of
techniques, which are suitable for the intended development, has been selected in accordance to the
required safety integrity level.
7961
7962
7.5.4.8 Elimination of documents or development phases (see 6.1.4.11) are only allowed when
accepted by the Assessor.
7963
7964
7.5.4.9 The assessor shall consider the extent to which each technique is applied, and also look for
evidence that it is properly applied.
7965
7966
7.5.4.10 The Assessor shall assess the quality management system and the evidences on its use
and application.
7967
7968
7969
7.5.4.11 The Assessor shall review the evidence of the competency of the project staff according to
Annex C and shall assess the organisation for the system development according to clause 6.2 and
6.3.
7970
7971
7972
7973
7974
7.5.4.12 For any system/sub-system or hardware component containing safety-related application

conditions, the Assessor shall check for noted deviations, non-compliances to the system or hardware
requirements and recorded non-conformities if these have an impact on safety, and make a judgment
whether the justification from the project is acceptable. The result shall be stated in the assessment
report.
7975
7976
7.5.4.13 The Assessor shall assess the verification and validation and safety activities carried out in
response to the safety requirements and the supporting evidence.
7977
7978
7979
7.5.4.14 The Assessor shall agree the scope and contents of the Quality Assurance Plan, the Safety
Plan and the Validation Plan. This agreement shall also make a statement concerning the presence of
the Assessor during testing.
7980
7981
7.5.4.15 The Assessor may carry out audits and inspections (e.g. witnessing tests) throughout the
entire development process. The Assessor may ask for additional verification and validation work.
7982
NOTE: It is advantageous to involve the Assessor early in the project.
7983
7984
7.5.4.16 A System Assessment Report shall be written under the responsibility of the Assessor.
Requirements from 7.5.4.16.1 to 7.5.4.16.5 refer to the System Assessment Report.
- 35 -
prEN 50126-4
7985
7986
7.5.4.16.1 The System Assessment Report shall meet the requirements of the System Assessment
Plan and provide a conclusion and recommendations.
7987
7988
7.5.4.16.2 The Assessor shall record his/her activities as a consistent basis for the System
Assessment Report. These have to be summarised in the System Assessment report.
7989
7990
7991
7.5.4.16.3 The Assessor shall identify and evaluate any non-conformities with the requirements of
this European Standard and judge the impact on the final result. These non-conformities and their
judgments shall be listed in the System Assessment Report.
7992
7993
7.5.4.16.4 The System Assessment Report shall fully state the related baselines for system/subsystem and/or hardware components, that have been assessed.
7994
7.5.4.16.5 Analyses carried out shall be documented in accordance with clause 7.1.
7995
7996
7.5.4.17 The Assessor shall deliver a verified System Assessment Plan (see 7.5.4.5) and System
Assessment Report (see 7.5.4.16). This verification shall address:
7997
7998
a) That the System Assessment Plan meets the specific requirements expressed in the sub-clauses
7.5.4.5.1 to 7.5.4.5.2.
7999
8000
b) That the System Assessment Report meets the specific requirements expressed in the subclauses 7.5.4.16.1 to 7.5.4.16.5.
prEN 50126-4
- 36 -
8001
8002
7.6 Quality Assurance
8003
7.6.1 Objective
8004
8005
8006
8007
8008
7.6.1.1 To identify, monitor and control all those activities, both technical and managerial, which are
necessary to ensure that the system/sub-system or hardware component achieves the quality
required. This is necessary to provide the required qualitative defence against systematic failures and
to ensure that an audit trail can be established to allow verification and validation activities to be
undertaken effectively.
8009
7.6.1.2 To provide evidence that the above activities have been carried out.
8010
7.6.2 Input
8011
All documents available at each stage of the life cycle
8012
7.6.3 Deliverables
8013
1)
8014
8015
NOTE: The related report is the System Quality Management Report (see 8.2.4.23 which is part of or referenced by the Safety
Case (see 8.2.4.21).
8016
2)
8017
7.6.4 Requirements
8018
8019
7.6.4.1 The Quality Assurance Plan shall be issued at the beginning of the project and updated
during the life cycle.
8020
8021
8022
8023
7.6.4.2 The organisations taking part in the development of a system/sub-system or hardware

component shall implement and use a Quality Assurance System compliant with ISO 9000 series, to
support the requirements of this European Standard. EN ISO 9001 accreditation is highly
recommended.
8024
8025
8026
7.6.4.3 A Quality Assurance Plan shall be written under the responsibility of the Quality Manager on
the basis of the input documents from 7.6.2. The requirements from 7.6.4.3.1 to 7.6.4.3.2 refer to the
Quality Assurance Plan.
8027
7.6.4.3.1 A Quality Assurance Plan shall be written and shall be specific to the project.
8028
8029
7.6.4.3.2 As a minimum, the following items shall be specified or referenced in the Quality Assurance
Plan.
8030
a) Definition of the life cycle model:
Quality Assurance Plan
Quality Assurance Verification Report
8031
8032
1) activities and elementary tasks consistent with the plans, e.g. Safety Plan, that have been
established at the System level;
8033
2) entry and exit criteria of each activity;
8034
3) inputs and outputs of each activity;
8035
4) major quality activities;
8036
5) the entity responsible for each activity.
8037
b) Documentation structure.
8038
c) Documentation control:
8039
1) roles involved for writing, checking and approval;
- 37 -
8040
2) scope of distribution;
8041
3) archiving.
prEN 50126-4
8042
d) Tracking and tracing of deviations.
8043
8044
e) Methods, measures and tools for quality assurance according to the allocated safety integrity
levels.
8045
8046
f) Justifications that each combination of techniques or measures selected is appropriate to the

defined safety integrity level.
8047
8048
Some of the Quality Assurance Plan required information may be contained in other documents, such
as:
8049
a) Configuration Management Plan,
8050
b) Maintenance Plan,
8051
c) System Verification plan,
8052
d) System Validation Plan and
8053
e) System Assessment Plan.
8054
8055
8056
The sub-clause s of the Quality Assurance Plan shall reference the documents in which the
information is contained. In any case the contents of each sub-clause of the Quality Assurance Plan
shall be specified either directly or by reference to another document.
8057
8058
8059
7.6.4.4 A Quality Assurance Verification Report shall be written, under the responsibility of the
Verifier, on the basis of the input documents from 7.6.2. The requirement in 7.6.4.4.1 refers to the
Quality Assurance Verification Report.
8060
7.6.4.4.1 Once the Quality Assurance Plan has been established, verification shall address
8061
8062
8063
a) that the Quality Assurance Plan meets the general requirements for readability and traceability in
6.1.4.5 to 6.1.4.10 and in 7.6.4.10 to 7.6.4.13 as well as the specific requirements in 7.6.4.3.1 to
7.6.4.3.2,
8064
b) the internal consistency of the Quality Assurance Plan.
8065
8066
8067
7.6.4.5 Quality assurance activities, actions, documents, etc. required by all normative clauses of this
European Standard shall be specified or referenced in the Quality Assurance Plan and tailored to the
specific project.
8068
8069
7.6.4.6 All relevant documents shall have a paragraph specifying details about its own updating
throughout the project: frequency, responsibility, method.
8070
8071
7.6.4.7 Each system/sub-system or hardware document and deliverable shall be placed under
configuration control from the time of its first release.
8072
8073
8074
7.6.4.8 A Change Management Process has to be implemented so that it is guaranteed, that

changes to all items under Configuration Management Control are recorded and authorised by a
defined change control board.
8075
8076
This extension, necessary for the reproducibility of the development and for the maintenance
activities, shall include all the tools used in the development of the system/sub-system.
8077
8078
7.6.4.9 The supplier shall establish, document and maintain procedures for control of the External
Suppliers, including:
8079
8080
methods and relevant records to ensure that the parts of the system/sub-system or hardware
component that are provided by external suppliers adhere to established requirements. Previously
prEN 50126-4
8081
8082
8083
8084
8085
- 38 -
developed systems/sub-systems or hardware components shall be assured to be compliant with

the required safety integrity level and dependability. New systems/sub-systems or hardware
components shall be developed and maintained in conformity with the Quality Assurance Plan of
the Supplier or with a specific Quality Assurance Plan prepared by the external supplier in
accordance with the Quality Assurance Plan of the Supplier;
8086
8087
methods and relevant records to ensure that the requirements provided to the external supplier
are adequate and complete.
8088
8089
8090
7.6.4.10 Traceability to requirements shall be an important consideration in the validation of a safetyrelated system/sub-system or hardware component. Therefore Quality Assurance has to define
measures to demonstrate the traceability throughout all phases of the life cycle.
8091
8092
7.6.4.11 Within the context of this European Standard, and to a degree appropriate to the specified
safety integrity level, traceability shall particularly address:
8093
a) traceability of requirements to the design or other objects which fulfil them;
8094
b) traceability of design objects to the implementation objects which instantiate them;
8095
c) traceability shall be the subject of configuration management;
8096
d) traceability of requirements and design objects to the tests and analyses that verify them.
8097
8098
8099
8100
7.6.4.12 In special cases, e.g. pre-existing systems/sub-systems, or hardware components or

prototypes, traceability may be established after manufacture, but prior to verification/validation. In
these cases, it shall be shown that verification/validation is as effective as it would have been with
traceability over all phases.
8101
8102
7.6.4.13 Objects of requirements, design or implementation that can not be adequately traced shall
be demonstrated to have no bearing upon the safety or integrity of the system/sub-system.
- 39 -
prEN 50126-4
8103
8104
7.7 Safety Management
8105
7.7.1 Objective
8106
8107
8108
7.7.1.1 To identify, monitor and control all those activities, both technical and managerial, which are
necessary to ensure that the system/sub-system or hardware component achieves the safety
required.
8109
8110
8111
7.7.1.2 To provide evidence that the above safety activities have been carried out. The safety
management is performed by the Safety Manager, a safety expert accompanying a development
project and being responsible for the planning and implementation of the necessary safety activities.
8112
7.7.2 Input
8113
8114
1) All the Specifications and Interface Specifications on system/sub-system component level in

particular the Requirements Specifications and Architecture Specifications
8115
2) All the Test Specifications and Test Reports
8116
3) All the Verification Reports
8117
7.7.3 Deliverables
8118
8119
The following deliverables have to be provided on system and/or sub-system and/or component level
appropriate to the project considered.
8120
1) Safety Plan
8121
2) Hazard Analysis
8122
3) Hazard Log
8123
4) Safety Case
8124
8125
This sub-clause does not directly require the following output document, but provides guidance for its
contents:
8126
5) System Hazard Analysis
8127
7.7.4 Requirements
8128
8129
7.7.4.1 The System Safety Plan shall be written under the responsibility of the Safety Manager. The
requirements from 7.7.4.1.1 to 7.7.4.1.12 refer to the System Safety Plan.
8130
7.7.4.1.1 The System Safety Plan shall specify:
8131
a) in which stages of the life cycle safety audits, safety assessment and Safety Reviews are needed;
8132
b) the minimum attendants list for each Safety Review;
8133
c) criteria to ask for not-planned safety audits and safety reviews;
8134
d) which role can ask for extraordinary safety audits and safety reviews;
8135
7.7.4.1.2 who is responsible to writing the Safety Review Report.
8136
8137
7.7.4.1.3 The System Safety Plan shall define the relationship and hierarchy between system safety
activities and documentation, including but not limited to:
8138
1. identifying the system safety case for each sub-system of the system
8139
2. identifying the system safety cases for each process
prEN 50126-4
- 40 -
8140
8141
7.7.4.1.4 The System Safety Plan shall define the interface to the independent assessment,
including but not limited to:
8142
1. class of independent assessment
8143
a) independent assessment on each development phase during the development of the system
8144
8145
b) independent assessment after finishing the phase final acceptance at the end of the
development
8146
8147
7.7.4.1.5 The System Safety Plan should define the interface to the regulatory authority, including
but not limited to:
8148
1. handover of safety case and assessment report
8149
2. conditions (especially the plans from 8.2.1.1-3)
8150
7.7.4.1.6 The System Safety Plan should include the planning for the approval of the system.
8151
7.7.4.1.7 The System Safety Plan shall define the technical safety principles.
8152
8153
7.7.4.1.8 The System Safety Plan shall define the strategy for selection of the measures given in the
Annex A .
8154
a) The System Safety Plan shall define the safety based preconditions for each phase.
8155
8156
7.7.4.1.9 The System Safety Plan shall defined the used model of independence of the roles from
sub-clause 6.2.
8157
7.7.4.1.10 The System Safety Plan shall define the process of handling assumptions and constraints.
8158
8159
7.7.4.1.11 The System Safety Plan shall define how the fulfilment of this standard for the
parts/activities assigned to subcontractors is assured and demonstrated (review, audits, reports)
8160
8161
7.7.4.1.12 The System Safety Plan shall identify the parts of this standard for which the
subcontractor is responsible and specify how:
8162
1. the evidence of the fulfilment of these parts are given by the subcontractor.
8163
2. deviations to these parts are reported by the subcontractor.
8164
8165
8166
7.7.4.2 A System Hazard Analysis shall be written under the responsibility of the Designer or of the
Safety Manager on the basis of the System Architecture Specification. The requirement 7.7.4.1.1 refer
to the System Hazard Analysis.
8167
7.7.4.2.1 The System Hazard Analysis shall identify all faults and for each fault it shall be specified:
8168
a) the effect of the fault
8169
b) the complete set of measures needed for avoidance or detection
8170
c) the reaction on detection including the definition of, but not limited to:
8171
8172
i. a complete set of activities needed to react in way to fulfil the specified quantified safety
target;
8173
8174
8175
ii. a complete set of conditions which shall be fulfilled after detection of the fault to ensure that
the reached state can not cancelled out by any further fault (the system shall change in a
state that a new single failure can not create a hazardous event);
8176
8177
8178
iii. procedures, measures and activities processed for cancellation of the reached state
including the definition of the procedures, measures and activities processed during
application of the future life cycle activities.
- 41 -
prEN 50126-4
8179
8180
d) for all measures where a fault is detected the detection time sufficiently short to fulfil the specified
quantified safety target shall be calculated;
8181
8182
e) for all measures where a fault is detected the negation time sufficiently short to fulfil the specified
8183
8184
f) for all measures where a fault is detected the repair time sufficiently short to fulfil the specified
8185
8186
g) the measures needed to ensure the avoidance of the fault during application of the future life cycle
activities.
8187
7.8 Configuration Management and Modification Control
8188
7.8.1 Objective
8189
8190
8191
The objectives of Configuration Management and Modification Process is to identify the configuration
items and to define procedures for changing the sub-systems and hardware components of the
system, which are already in field.
8192
7.8.2 Input
8193
8194
2) All relevant design, development and analysis documentation
8195
3) Change impact analysis and authorisation
8196
7.8.3 Deliverables
8197
1) All changed input documents
8198
2) Change records including the configuration history for sub-system and hardware components
8199
3) Configuration records
8200
4) Configuration Management Plan (it could be included in the Quality Assurance Plan)
8201
7.8.4 Requirements
8202
8203
8204
8205
7.8.4.1 The Configuration Management shall clearly identify the configuration items of the
system/sub-system or hardware components and ensure that the sub-systems and hardware
components of the system perform as required, preserving the safety integrity level and dependability
when modifying the sub-systems and hardware components of the system.
8206
8207
8208
7.8.4.2 The Modification Process shall ensure that the procedures for changing the sub-systems and
hardware components of the system, which are already in field are defined (in cases of repair,
replace, deployment).
8209
8210
7.8.4.3 The Configuration Management and Modification Process under the responsibility of the
Configuration Manager shall define at least the following aspects.
8211
8212
8213
a) Each LRU shall be clearly identified and have an independent version inside the configuration
management system or should be a part of a collection of components (e. g. sub-system) which
have an independent version;
8214
8215
b) Full compatibility of LRUs (even if there are changes in its hardware components) shall be visible
through their identifier;
8216
8217
c) The configuration records shall at least identify all sub-systems and hardware-components and
their versions;
prEN 50126-4
- 42 -
8218
8219
d) Define the documentation needed for problem reporting and/or corrective actions, with the aim of
giving feedback to the responsible management;
8220
e) Inclusion of the development environment used during the full life cycle into the configuration;
8221
f) Define analysis of the information collected in the problem reports to identify its causes;
8222
8223
g) Define the practices/processes to be followed for reporting, tracking and resolving problems
identified both during the development phase and during maintenance and manufacturing;
8224
8225
h) Define processes for change or repair of sub-systems and hardware components of the system
which are already in the field;
8226
8227
i) Define preventive actions to deal with problems to a level corresponding to the required safety
integrity level;
8228
8229
j) Define the specific organisational responsibilities with regard to development, maintenance and
manufacturing;
8230
k) Define how to apply controls to ensure that corrective actions are taken and that they are effective;
8231
l) Define the forms to be used;
8232
m) Define the requirements for re-test, re-verification, re-validation and re-assessment;
8233
8234
n) Impact analysis of the effect of the changes on the system/sub-systems and hardware
components of the system under development or already delivered;
8235
8236
o) Each change on an item under Configuration Management shall be recorded and authorised
before implementation by a Change Control Board (see 7.6.4.8).
8237
8238
8239
7.8.4.4 All changes shall initiate a return to an appropriate phase of the life cycle. All subsequent
phases shall then be carried out in accordance with the procedures specified for the specific phases
in accordance with the requirements in this European Standard.
- 43 -
prEN 50126-4
8240
8241
7.9 Support Tools
8242
7.9.1 Objective
8243
8244
8245
8246
7.9.1.1 The objective is to provide evidence that potential failures of tools do not adversely affect the
integrated toolset output in a safety related manner that is undetected by technical and/or
organisational measures outside the tool. To this end, tools are categorised into three classes
namely, T1, T2 & T3 respectively.
8247
7.9.2 Input
8248
1) Tools specification or manual
8249
7.9.3 Deliverables
8250
1) Tools validation report (when needed see 7.9.4.9 or 7.9.4.11)
8251
7.9.4 Requirements
8252
8253
7.9.4.1 Tools shall be selected as a coherent part of the system/sub-system and hardware
development and manufacturing activities.
8254
8255
8256
8257
7.9.4.2 Appropriate tools to support the development and manufacturing should be used in order to
increase the integrity by reducing the likelihood of introducing or not detecting failures during the
development and manufacturing. Examples of tools relevant to the phases of the system/sub-system
and hardware development life cycle include:
8258
8259
a) transformation tools that convert a system/sub-system or hardware component design

representation (e.g. a diagram) from one abstraction level to another;
8260
b) verification and validation tools, simulators and checkers;
8261
8262
c) diagnostic tools used to maintain and monitor the system/sub-system and/or hardware
components under operating conditions;
8263
d) infrastructure tools such as development support systems;
8264
e) configuration control tools such as version control tools;
8265
8266
f) tools that produce or maintain data which are required to define parameters and to instantiate
system/sub-system functions e.g. transmission rates, clock rates, communication parameters.
8267
8268
8269
7.9.4.3 The selected tools should be able to cooperate. In this context, tools cooperate if the outputs
from one tool have suitable contents and format for automatic input to a subsequent tool, thus
minimizing the possibility of introducing human error in the reworking of intermediate results.
8270
8271
7.9.4.4 Tools should be selected to be compatible with the needs of the function, of the safety related
system/sub-system or hardware component, and of the integrated toolset.
8272
8273
7.9.4.5 The availability of suitable tools to supply the services that are necessary over the whole
lifetime of the system/sub-system or hardware component should be considered.
8274
8275
8276
8277
8278
7.9.4.6 When tools are being used as a replacement for manual operations, the evidence of the
integrity of tools output can be adduced by the same process steps as if the output was done in
manual operation. These process steps might be replaced by alternative methods if an argumentation
on the integrity of tools output is given and the integrity level of the system/sub-system or hardware
component is not decreased by the replacement.
prEN 50126-4
- 44 -
8279
8280
8281
7.9.4.7 The selection of the tools in class T2 and T3 shall be justified (see 8.3.4.12). The justification
shall include the identification of potential failures which can be injected into the tools output and the
measures to avoid or handle such failures.
8282
8283
7.9.4.8 All tools in classes T2 and T3 shall have a specification or manual which clearly defines the
behaviour of the tool and any instructions or constraints on its use.
8284
8285
8286
8287
7.9.4.9 For each tool in class T3 evidence shall be available that the output of the tool conforms to
the specification of the output or failures in the output are detected. Evidence may be based on the
same steps necessary for a manual process as a replacement for the tool and an argument if these
steps are replaced by alternatives (e. g. validation of the tool). Evidence may also be based on:
8288
8289
8290
a) a suitable combination of documented history of successful use (project and applications realized,
list of anomalies, identification of successive versions) in similar environments and for similar
applications;
8291
b) tool validation as specified in 7.9.4.10;
8292
8293
c) compliance with the safety integrity levels derived from the risk analysis of the process and
procedures including the tools;
8294
d) other appropriate methods for avoiding or handling failures introduced by tools.
8295
8296
NOTE 1: A version history may provide assurance of maturity of the tool, and a record of the errors / ambiguities associated
with its use in the environment.
8297
NOTE 2: The evidence listed for T3 ) may also be used for T2 tools in judging the correctness of their results.
8298
7.9.4.10 The results of tool validation shall be documented covering the following results:
8299
a) a record of the validation activities;
8300
b) the version of the tool and the manual being used;
8301
c) the tool functions being validated;
8302
d) tools and equipment used;
8303
8304
e) the results of the validation activity; the documented results of validation shall state either that the
tool has passed the validation or the reasons for its failure;
8305
f) test cases and their results for subsequent analysis;
8306
g) discrepancies between expected and actual results;
8307
h) results of the analyses documented in accordance with clause 7.1.
8308
8309
8310
7.9.4.11 Where the conformance evidence of 7.9.4.9 is unavailable, there shall be effective
measures to control failures in the system/sub-system or hardware component that result from
failures that are attributable to the tool.
8311
8312
8313
NOTE 1: See (7.9.4.14)
8314
NOTE 2: As an example, the fitness for purpose of a non-trusted transformation tool can be justified as follows:
8315
8316
8317
The output produced by the transformation tool has been subjected to a combination of tests, checks and analyses which are
capable of ensuring the correctness of the output to an extent consistent with the target Safety Integrity Level. In particular, the
following applies to all tests, checks and analyses.
8318
8319
8320
8321
In general for tools in the field of hardware design or manufacturing a tool validation will not be done and therefore the effective
failure control is the standard procedure.
Checks and analyses have been applied to the output or the hardware and shown to be capable of detecting the types of
errors which might result from a defect in the transformation tool;
No more transformation with the transformation tool has taken place after testing, checking and analysis;
If further transformation with the transformation tool is carried out, all tests, checks and analyses will be repeated.
- 45 -
prEN 50126-4
8322
8323
In general for hardware design, non-trusted transformation tools are in use and therefore this is the standard procedure for
hardware design.
8324
7.9.4.12 The compatibility of the tools of an integrated toolset shall be ensured.
8325
7.9.4.13 The system/sub-system or hardware component design representation selected shall:
8326
8327
a) have a transformation tool which has been evaluated for fitness for purpose including, where
appropriate, evaluated against the international or national standards;
8328
b) match the characteristics of the function;
8329
c) contain features that facilitate the detection of design errors;
8330
d) support features that match the design method.
8331
8332
8333
8334
8335
NOTE 1: The evaluation of a transformation tool may be performed for a specific application project, or for a class of
applications. In the latter case all necessary information on the tool regarding the intended and appropriate use of the tool
should be available to the user of the tool. The evaluation of the tool for a specific project may then be reduced to checking
general suitability of the tool for the project and compliance to the specification or manual (i.e. proper use of the tool). Proper
use might include additional verification activities within the specific project.
8336
8337
NOTE 2: A validation suite may be used to evaluate the fitness for purpose of a transformation tool according to defined
criteria, which should include functional and non-functional requirements.
8338
8339
NOTE 3: In general the system/sub-system or hardware component design representation has no transformation tool. The
transformation is done by the designer.
8340
8341
8342
7.9.4.14 Where 7.9.4.13 cannot be fully satisfied, the fitness for purpose of the design
representation, and any additional measures which address any identified shortcomings of the design
representation shall be justified and evaluated.
8343
8344
8345
7.9.4.15 Where automatic transformation takes place, the suitability of the automatic transformation
for safety-related development shall be evaluated at the point in the development life cycle where
development support tools are selected.
8346
8347
7.9.4.16 Configuration management shall ensure that for tools in classes T2 and T3 only justified
versions are used.
8348
8349
7.9.4.17 Each new version of a tool that is used shall be justified (see 7.9.4.1 to 7.9.4.11). This
justification may rely on evidence provided for an earlier version if sufficient evidence is provided that
8350
a) the functional differences (if any) will not affect tool compatibility with the rest of the toolset;
8351
b) the new version is unlikely to contain significant new, unknown failures.
8352
8353
NOTE: Evidence that the new version is unlikely to contain significant new unknown failures may be based on a credible
identification of the changes made, and on an analysis of the verification and validation actions performed.
8354
8355
7.9.4.18 The relation between the tool classes and the applicable sub-clauses is defined within Table
1.
Tool Class
T1
T2
T3
8356
Applicable paragraphs
7.9.4.1, 7.9.4.2, 7.9.4.3, 7.9.4.4, 7.9.4.5, 7.9.4.6, 7.9.4.12, 7.9.4.17 and 7.9.4.18
7.9.4.1, 7.9.4.6, 7.9.4.3, 7.9.4.8, 7.9.4.5, 7.9.4.6, 7.9.4.7, 7.9.4.12, 7.9.4.16, 7.9.4.16,
7.9.4.17
7.9.4.1, 7.9.4.6, 7.9.4.3, 7.9.4.6, 7.9.4.7, 7.9.4.8, 7.9.4.9, 7.9.4.8, 7.9.4.9 or
7.9.4.10, 7.9.4.11, 7.9.4.14 if needed according to 7.9.4.9, 7.9.4.12, 7.9.4.13, 7.9.4.15,
7.9.4.16, 7.9.4.17 and 7.9.4.18
Table 1 - Relation between Tool Class and applicable paragraphs of this sub-clause
prEN 50126-4
- 46 -
8357
8358
8. E/E/PE SYSTEM DEVELOPMENT: SYSTEM ASPECTS
8359
8.1 Additional Requirements for E/E/PE Architecture
8360
8361
This sub-clause defines requirements additional to those indicated in Part 1, Phase 5, specific for
E/E/PE sub-systems or components.
8362
8363
8.1.1 A safety integrity level shall be derived from the THR/TFFR for the hardware components and
software components associated to a safety function.
8364
8365
8.1.2 The System Architecture Specification shall identify all hardware/software interactions and any
constraints between the hardware and the software components.
8366
8367
8.1.3 The allocation of the system requirement to the subsystems and hardware/software
components shall proceed taking into account the possibility of common cause failures.
8368
8369
8370
8.1.4 If common cause failures are identified, then the sub-systems and hardware/software
components of the system shall not be treated as independent for the purposes of the safety integrity
allocation.
8371
8372
8.1.5 When transmission systems are used to transfer safety related information, communication
protocols shall be designed according to EN 50159.
8373
8374
8.1.5.1 If pre-existing sub-systems, software and hardware components are used to fulfil system
requirements the System Architecture Specification shall address the following:
8375
a) identification of the pre-existing sub-systems, software and hardware components;
8376
8377
b) relation between the system requirements and the pre-existing sub-systems, software and
hardware components.
8378
8379
8.1.6 The System Architecture Specification shall identify all hardware and software components
identifying
8380
a) whether these components have been previously validated and if so their validation conditions;
8381
b) the safety integrity level of the hardware and software components.
8382
8383
8.1.7 During system architecture development a top-down, structured design methodology according
to Annex A, Table A.5 shall be used.
8384
NOTE: For guidance on development of programmable devices see Annex E.
8385
8386
8387
8388
8389
8.1.8 It is necessary to ensure that the system/sub-system meets its TFFR in the event of single
random fault. It is necessary to ensure that SIL 3 and SIL 4 systems remain safe in the event of any
kind of single random hardware fault which is recognised as possible. Faults whose effects have been
demonstrated to be negligible may be ignored. This principle, which is known as fail-safety, can be
achieved in several different ways (see also Figure 4):
8390
8391
8392
8393
8394
8395
1. composite fail safety

This principle implies that each safety-related function is performed by at least two items. Each of
these items shall be independent from all others, to avoid common-cause failures. Non-restrictive
activities are allowed to progress only if the necessary number of items agree. A hazardous fault
in one item shall be detected and negated in sufficient time to avoid a co-incident fault in a
second item.
8396
8397
8398
8399
2. reactive fail safety

This principle allows a safety-related function to be performed by a single item, provided its safe
operation is assured by rapid detection and negation of any hazardous fault (for example, by
encoding, by multiple computation and comparison, or by continual testing). Although only one
- 47 -
prEN 50126-4
8400
8401
item performs the actual safety-related function, the checking/testing/detection function shall be
regarded as a second item, which shall be independent to avoid common-cause failures.
8402
8403
8404
8405
8406
8407
8408
3. inherent fail safety

This principle allows a safety-related function to be performed by a single item, provided all the
credible failure modes of the item are non-hazardous. Any failure mode which is claimed to be
incredible (for example, because of inherent physical properties) shall be justified using the
procedure defined in Annex B. Inherent fail-safety may also be used for certain functions within
Composite and Reactive fail-safe systems, for example to ensure independence between items,
or to enforce shut-down if a hazardous fault is detected.
8409
Also a combination of these techniques can be adopted.
8410
8411
8412
8413
8.1.9 After detection of a first fault, the system/sub-system/equipment shall enter, or continue in, a
safe state. The safe state is generally (but not necessarily) more restrictive. The safe state shall be
reached in a time sufficiently short that the combined detection-plus-negation time fulfils the specified
safety target (see Figure 4).
8414
8415
NOTE: The negation time is usually the time taken for the relevant part of the system to be shut down, either automatically or
by human action.
8416
8417
8418
8.1.10 After detection of a first fault, and having entered the safe state, further faults shall not cancel
out the safe state. Cancellation of a restrictive safe state shall occur only in a controlled manner, as
part of a corrective procedure.
8419
8420
8421
8.1.11 The system/sub-system/equipment shall remain in a safe state if further faults occur during
permissible delay-times-to-repair after occurrence of a first fault. Permissible delay-times-to-repair
shall be sufficiently short to fulfil the specified safety target.
8422
8423
8.1.12 During the development of the System Architecture Specification requirements for future lifecycle tasks can be established, including requirements for:
8424
8425
8426
8427
8428
a) Configuration
8429
b) Installation;
8430
c) Commissioning;
8431
d) Operation and Maintenance, including definition of operation and maintenance procedures;
8432
e) data acquisition and assessment during operation.
8433
f) decommissioning and disposal
8434
g) Safety Qualification Test
8435
h) Hardware Manufacturing
8436
8437
For all requirements related to the environment the constraints shall be derived for the integration and
the future life cycle task.
8438
NOTE: The requirements for the configuration should include:

1.
tools needed for the configuration including the tools manual
2.
procedures defining the configuration process
3.
verification and validation activities needed to ensure that the configuration is complete
prEN 50126-4
- 48 -
COMPOSITE FAIL-SAFETY
FUNCTION A
FAULT DETECTION
NEGATION
FUNCTION A
&
OUTPUT
FUNCTION B
FUNCTION B
FAULT DETECTION
FUNCTION A
DETECTION
FUNCTION B
OUTPUT
SAFE
STATE
FIRST
FAULT
OCCURS
IN A
DETECTION
OF FIRST
FAULT
IN A
NEGATION
SWITCHES
OFF
OUTPUT
The probability of
a 1st fault, combined with
the probability of a
2nd fault occurring
during the 1st fault
detection-plus-negation
time T, shall be less than
the specified probabilistic
target.
SECOND
FAULT
OCCURS
IN B
REACTIVE FAIL-SAFETY
FUNCTION A
FAULT DETECTION
NEGATION
OUTPUT
FUNCTION A
FUNCTION A
Detection-plus-negation
time T, after a fault in A,
shall not exceed the
specified limit for the
duration of a transient,
potentially - hazardous
output.
DETECTION
OUTPUT
FAULT
OCCURS
IN A
8439
8440
DETECTION
OF FAULT
IN A
SAFE
STATE
NEGATION
SWITCHES
OFF OUTPUT
Figure 4 Detection and negation of single faults
- 49 -
prEN 50126-4
8441
8.1.13 The use of pre-existing hardware component shall be subject to the following restrictions.
8442
a) For all safety integrity levels, the following information shall be clearly identified and documented:
8443
1) the requirements that the pre-existing hardware component is intended to fulfil;
8444
2) the assumptions about the environment of the pre-existing hardware component;
8445
3) interfaces with other parts of the hardware component shall be documented.
8446
b) For safety integrity levels SIL 1 or SIL 2:
8447
8448
1) The pre-existing hardware component shall be included in the validation process of the whole
hardware.
8449
8450
2) An analysis of the consequences of the possible failures of the pre-existing hardware

component on the whole hardware shall be carried out.
8451
c) For safety integrity levels SIL 3 or SIL 4, the following precautions shall be taken:
8452
8453
1) An analysis of possible failures of the pre-existing hardware component and their

consequences on the whole hardware shall be carried out.
8454
8455
2) A strategy shall be defined to detect failures of the pre-existing hardware component and to
protect the system from these failures.
8456
3) The verification and validation process shall ensure
8457
1. that the pre-existing hardware component fulfils the allocated requirements;
8458
8459
8460
2. that failures of the pre-existing hardware component are detected and the system
where the pre-existing hardware component is integrated into is protected from these
failures;
8461
8462
3. that the assumptions about the environment of the pre-existing hardware component
are fulfilled.
8463
8464
8465
8466
8467
8468
d) The pre-existing hardware component shall be accompanied by a sufficiently precise (e.g. limited
to the used functions) and complete description (i.e. functions, constraints and evidence). The
description shall include hardware and/or software constraints and anomalies (and how they
appear and their potential impact) of which the designer shall be aware and take into consideration
during application. In particular it forms the vehicle for informing the designer of what the hardware
was designed for, its properties, behaviour and characteristics.
8469
NOTE: Statistical evidence may be used in the validation strategy of the pre-existing hardware component.
8470
8471
8472
8473
8.1.14 The System Hazard Analysis shall identify the new hazards arising from the architecture and
requirements to control these hazards shall be derived from that new hazards and allocated to the
related sub-systems and/or hardware/software components. This hazard analysis should include, but
not limited to:
8474
a) single random faults (see 8.1.14.1, 8.1.14.2)
8475
b) multiple random faults (see 8.1.14.3)
8476
c) common cause faults (see 8.1.14.4)
prEN 50126-4
- 50 -
8477
8478
8.1.14.1 The System Hazard Analysis shall identify all single random faults and provide for each
single random fault the specification according to 7.7.4.2.
8479
8480
8.1.14.2 The System Hazard Analysis for SIL3 and SIL4 systems/subsystems shall demonstrate that
all single faults are not hazardous.
8481
NOTE: If this is not achieved, because some hazardous single fault
8482
a) can not be avoided or detected;
8483
b) can not be detected within a detection time which fulfils the specified quantified safety target;
8484
c) can not be repaired within a repair time which fulfils the specified quantified safety target; or
8485
d) can not be negated within the negation time.
8486
then for any of them, one or a combination of the following actions should be implemented:
8487
a) additional measures for the design shall be identified;
8488
b) system architecture and its description shall be changed. Then, System Hazard Analysis shall be updated;
8489
8490
8491
8492
c) additional measures shall be exported to phases other than design. In this case, entities responsible for those activities
should be involved for measures feasibility evaluation. If the additional measures have an impact also on operations after
the commissioning (e.g. maintenance), the Railway authority should be involved for evaluation and acceptance of the
measures.
8493
8494
d) If the hazard is not related to any identified one, i.e. has not been found during risk analysis, this activity should be
repeated, and a THR/TFFR for this new hazard shall be established. Then, all life cycle activities should be updated.
8495
8496
8497
8498
8499
8.1.14.3 For all single faults from 7.1.1.5.3 it shall be taken into account that another different fault
occurs before the random single fault is repaired. These are the multiple random faults. Hazardous
events can be caused by a combination of more than two different random single faults, so the
System Hazard Analysis shall taken into account combinations of more than two different random
single faults.
8500
8501
8502
8503
8.1.14.4 The System Hazard Analysis shall identify all single faults from 8.1.14.1 and multiple faults
from 8.1.14.3 which have an effect on more that one independent part at the same time. These are
the common cause faults. For each common cause fault the specification according to 7.7.4.2.1 shall
be provided.
8504
8505
8506
8507
8508
8509
8510
NOTE 1: Single and multiple faults include, but are not limited to:
random faults
systematic faults
unintended misuse (e.g.)
usage outside the specified environmental conditions (e.g. temperature, overvoltage, humidity, lightning)
sabotage, vandalism and loss of security (if necessary)
8511
8512
8513
a) systematic development errors

b) operation outside the required environmental conditions
c) loss of independence among independent units
8514
8515
8516
8.1.14.5 For all calculations the sources of basic failure rate data used in the calculations (e.g.
hardware component failure rates) shall be identified, and the method of quantitative analysis clearly
explained and if possible also their uncertainty.
8517
8.1.14.6 The Sub-system/Component Integration Test Specification shall address the following:
8518
8519
a) it shall be shown that the software runs correctly on the hardware and uses the hardware via the
specified software/hardware interfaces;
8520
b) it shall be shown that the software can handle hardware failures as required;
8521
c) the required timing and performance shall be demonstrated;
8522
8523
d) the required input data with their sequences, timing and values, specified in the software/hardware
interface specifications, shall be the basis of the analyses and test cases;
NOTE 2: The following causes can lead to common cause failures:
- 51 -
prEN 50126-4
8524
8525
e) the expected output data with their sequences, timing and values, specified in the
software/hardware interface specifications, shall be the basis of the analyses and test cases.
8526
8527
f) it shall be shown that the hardware components deliver correct responses and functions via the
specified hardware interfaces.
8528
8529
NOTE: The system architecture is an iterative process, so the System Architecture and Design Verification Report can be
prepared iteratively.
8530
8.2 Integration and Validation
8531
8.2.1 Objective
8532
8.2.1.1 The objectives of the requirements of this sub-clause are to:
8533
8534
1. Integrate all sub-systems, hardware components and software components, demonstrating their
correct functional operation;
8535
8536
8537
2. demonstrate that the required TFFR and/or safety integrity level have been achieved, taking into
account the apportionment of the requirements to the sub-systems, hardware components and
software components;
8538
8539
8540
3. establish plans containing the requirements for future life cycle tasks with respect to manufacture,
configuration, installation, commissioning, operation and maintenance and specifying the
requirements for those future life cycle tasks.
8541
8.2.2 Input
8542
1) Software/Hardware Integration Test Specification
8543
8.2.3 Deliverables
8544
1) Software/Hardware Integration Verification Report
8545
2) Software/Hardware Integration Test Report
8546
3) E/E/PE Sub-system Integration Report
8547
4) E/E/PE Sub-system Validation Report
8548
5) Generic Product/Application Safety Case
8549
8.2.4 Requirements
8550
8551
8552
8553
8.2.4.1 The integration of the system shall be the process of testing progressively combined
individual and previously integrated/tested sub-systems and hardware/software components into a
composite whole in order that the components interfaces and the assembled sub-system and
hardware/software components may be adequately proven.
8554
8555
8556
8.2.4.2 During integration any modification or change to the integrated system shall be subject to a
safety impact analysis which shall identify all sub-systems and hardware/software components of the
system impacted and the necessary re-verification activities.
8557
8558
8559
8560
NOTE: This impact study isnt necessary when:

a) the change does not impact the single [sub-systems/hardware and Software] components, or
b) after the change the integration test specifications be updated according to the change and the integration completed.
8561
8562
8563
8564
8565
8566
8.2.4.3 When the safety impact analysis on the modification or change has been completed, an
analysis shall be undertaken to determine whether any reasonably foreseeable failure of the
modification or change of the system could cause a hazardous event or place a demand on the
requirements for the future life cycle tasks (see 8.1.12). If any reasonably foreseeable failure could
have either of these effects, then the first priority shall be to use a change or modification where such
failure modes shall be avoided. If this cannot be done, measures shall be taken to reduce the
prEN 50126-4
- 52 -
8567
8568
likelihood of such failure modes to a level commensurate with the target failure measure. These
measures shall be subject to the requirements of this standard.
8569
8570
8571
8.2.4.4 The integration shall show that all hardware/software components of the sub-system interact
correctly as specified in the related interface specifications (software/software, software/hardware,
hardware/hardware) to perform their intended function and do not perform unintended functions.
8572
8.2.4.5 The sub-system integration shall be specified according to Table A.12 of Annex A.
8573
8.2.4.6 The software/hardware integration has the specific aims to verify:
8574
a) The fulfilment of performance requirements;
8575
b) The fulfilment of timing constraints defined in the Software Architecture;
8576
c) The fulfilment of the safety requirements relying on interaction between hardware and software.
8577
8578
NOTE: Examples of safety requirements relying on SW-HW integration are: test of the hardware through software; reaction
time of the software to a hardware fault.
8579
8580
8.2.4.7 The software/hardware integration for performance and timing shall be specified according to
Table A.13 of Annex A.
8581
8.2.4.8 The Software/Hardware Integration Test Specification shall be verified against:
8582
a) Subsystem Architecture Specification;
8583
b) Hardware Component Specification;
8584
c) Software Requirements Specification;
8585
d) Software Architecture Specification;
8586
e) Software Design Specification.
8587
8588
8589
8.2.4.9 During the integration of the subsystems and hardware/software components of the system
the fulfilment of all constraints defined for that subsystems and hardware/software components shall
be shown.
8590
NOTE: For the constraints for system/subsystems see 8.2.4.21 and EN 50126-5 sub-clause 10.1.4.
8591
8.2.4.10 The sub-system and software/hardware integration:
8592
8593
a) shall state the test results and whether the objectives and criteria of the System Integration Test
Specification have been met;
8594
b) shall be repeatable and, if practicable, be performed by automatic means;
8595
c) If there is a failure, the circumstances for the failure and its correction shall be documented;
8596
d) shall record test cases and their results, preferably in a machine-readable form;
8597
e) shall document the identity and configuration of all items involved.
8598
8599
8.2.4.11 The validation shall show that all of the specified system requirements are correctly met and
the system does not perform unintended functions.
8600
8601
8602
8.2.4.12 When discrepancies occur between expected and actual results, the analysis made, and the
decisions taken on whether to continue the validation or issue a change request and return to an
earlier part of the development, shall be documented.
8603
8.2.4.13 All test equipment shall be verified for correct operation.
8604
8.2.4.14 Tools used during validation shall meet the requirements for support tools in Part 5.
- 53 -
prEN 50126-4
8605
8606
8.2.4.15 During the integration of the system plans shall be established, containing the requirements
for future life-cycle tasks, including plans for:
8607
a) Configuration;
8608
Note: The requirements for the configuration should include:
8609
1.
8610
2.
procedures defining the configuration process
8611
3.
verification and validation activities needed to ensure that the configuration is complete
tools needed for the configuration including the tools manual
8612
b) Installation;
8613
c) Commissioning;
8614
d) Operation and Maintenance, including definition of operation and maintenance procedures;
8615
e) Data acquisition and assessment during operation;
8616
f) Decommissioning and disposal;
8617
g) Safety Qualification Test;
8618
h) Hardware Manufacturing.
8619
8.2.4.16 Installation and commissioning plans shall include:
8620
8621
a) procedures for the safe assembly of the Hardware and the safe connection of the hardware with its
interfaces;
8622
b) tests to verify that the assembling, connection and calibration has been correctly performed.
8623
8624
8625
8626
8.2.4.17 The system installation, commissioning, operation and maintenance procedures shall be
defined and validated based on test and/or analysis. If adequate independence or decoupling
between individual sub-systems and hardware/software components cannot be demonstrated
analytically, the related combinations of functional behaviour shall be tested.
8627
8628
8629
8630
8631
8.2.4.18 When the validation of the system needs results from the future life cycle tasks identified in
8.1.12, the validation can be finished when all restrictions derived from that incomplete validation
have been transferred into conditions and constraints for the related future life cycle tasks from
8.1.12. Otherwise the validation can be finished after the results from the future life cycle tasks
identified in 8.1.12 are present.
8632
8633
8.2.4.19 For the avoidance of failures during the validation an appropriate group of techniques and
measures according to Annex A, Table A.10 shall be used.
8634
8.2.4.19.1 The Sub-system/Component Validation shall ensure:
8635
a) the version of the input documents being used;
8636
b) whether the objectives and criteria of the System Validation Plan have been met;
8637
c) statement about the adequacy of the Sub-system/Component Integration Test Specification;
8638
8639
d) the requirements from the System Requirement Specification and the System Architecture
Specification being validated and for each requirement:
8640
1. the techniques and measures used;
8641
2. test and analyses used;
8642
3. the results of the tests and analyses;
8643
4. deviations between expected and actual results of tests and/or analyses;
8644
8645
5. non-compliances and any safety constraints arising from the deviations between expected and
actual results of tests and/or analyses;
prEN 50126-4
8646
8647
8648
- 54 -
6. conditions and constraints derived from the deviations between expected and actual results of
tests and/or analyses for the future lifecycle tasks identified in 8.2.4.15 in terms of the impact
to the future life cycle tasks and traceable to the deviations.
8649
e) tools and equipment used, along with calibration data;
8650
8651
f) configuration identification of the item under validation, the procedures applied and the validation
environment;
8652
8653
g) a statement on the completion of the verification process with respect to the System Verification
Plan (see 7.3.4.3) and the Verification Reports (see 7.3.4.3.5 h).
8654
8655
8656
h) a summary statement on the tests results and whether the whole system in its environment fulfils
the requirements set out in the System Requirements Specification and System Architecture
Specification;
8657
i) statement of appropriate identification of technical support tools and equipment;
8658
j) statement of appropriate identification of simulation models used;
8659
8660
k) an evaluation of the test coverage on the requirements in the System Requirements Specification
and System Architecture Specification;
8661
l) the result of the check that the requirements tracing is fully performed and covered;
8662
8663
m) if the Validator produces own test cases not given to the Tester or Integrator the System Validation
Report shall document these.
8664
8665
8666
n) a statement that the project has performed appropriate handling of corrective actions in
accordance with the change management process and procedures and with a clear identification
of any discrepancies found;
8667
8668
o) a statement that the development has been carried out under control of an appropriate
organization as defined in 6.2, using competent personnel assigned to specific roles.
8669
8670
8671
p) a conclusion whether the system is fit for its intended application, taking into account the
application conditions the validation results and constraints.
8672
8673
8674
8675
8676
8.2.4.19.2 The System Validation Report shall contain the confirmation that each combination of
techniques or measures selected according to Annex A, Table A.10 is appropriate to the defined
safety integrity level. It shall contain an evaluation of the overall effectiveness of the combination of
techniques and measures adopted, taking account of the size and complexity of the system produced
and taking into account the actual results of testing, verification and validation activities.
8677
8678
8679
8680
8681
8682
8683
8684
8.2.4.20 The System shall be exercised either by connection to real items of hardware components
or actual systems with which it would interface in operation, or by simulation of input signals and loads
driven by outputs. It shall be exercised under conditions present during normal operation, anticipated
occurrences and undesired conditions requiring system action. Where simulated inputs or loads are
used it shall be shown that these do not differ significantly from the inputs and loads encountered in
operation.
8685
8.2.4.21 A Release Note shall be produced, that:
8686
8687
8688
8689
8690
8691
8692
Among these constraints, Safety-Related Application Conditions shall be clearly identified or referred.
NOTE: Simulated inputs or loads might replace inputs or loads which are only present at system level or in faulty modes.
includes a functional description of the system/sub-system.

Includes all external interfaces provided by the system/sub-system.
identifies all plans for the future life cycle tasks, identified by 8.1.12.
includes all constraints in using the system.
NOTE: These constraints should be derived from:
- 55 -
prEN 50126-4
8693
8694
8695
8696
8697
a)
b)
c)
d)
e)
8698
8699
8700
8.2.4.22 The Generic Product/Application Safety Case shall precisely identify the system/sub-system
and all the documentation of the system/sub-system to which the System Safety Case refers (see
Table A.1 Lifecycle Issues and Documentation).
8701
8702
8.2.4.22.1 The Generic Product/Application Safety Case shall fully state the related baselines for
system/sub-system, hardware components, that have been considered.
8703
8704
8.2.4.22.2 The Generic Product/Application Safety Case Safety Case shall summarise the evidence
presented by the:
8705
1) Quality Management Report (see 8.2.4.23),
8706
2) Safety Management Report (see 8.2.4.24) and
8707
3) Technical Safety Report (see 8.2.4.25)
8708
8709
8710
8711
and argue that the system/sub-system, to which the System Safety Case refers, is adequately safe
under the defined safety-related application conditions and adequate compliance against the
requirements of this standard.
8712
8713
8714
8715
8.2.4.22.3 The Generic Product/Application Safety Case Safety Case shall demonstrate that
appropriate protection measures have been taken to ensure random, systematic and unintended
misuse based failures on external interfaces do not adversely impact on the safety integrity of the
system.
8716
8717
8.2.4.22.4 The Generic Product/Application Safety Case shall identify the related safety cases,
including their safety-related Application Conditions.
8718
8719
8.2.4.23 The System Quality Management Report shall be written under the responsibility of the
Quality Manager. Requirement 8.2.3.20.1 refers to the System Quality Management Report.
8720
8721
NOTE: Examples of aspects which should be controlled by the quality management system and included in the Quality
Management Report:
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8.2.4.23.1 The System Quality Management Report shall summarize the degree of compliance of the
following plans:
the detected errors,

non-compliances with this European Standard,
degree of fulfilment of the requirements,
degree of fulfilment of specifications and plan.
results of the validation.
NOTE: Additional national requirements can also be included in the summary.
organisational structure;
documentation and records management;
quality planning and policy;
quality audits and follow-up;
specification of requirements;
design planning and control;
design verification and reviews;
purchasing;
production and service provision;
product identification and traceability;
preservation of the product;
non-conformance and corrective action management;
monitoring and measurement;
personnel competency and training.
8739
1. Quality Assurance Plan (see 7.6.4.3.1) and
8740
2. Configuration Management Plan (see 7.8.4.3).
8741
8742
For any deviation from the plans an argumentation shall be given that the safety and functionality of
the system is still assured (maybe under additional safety related application conditions).
8743
8.2.4.24 The Safety Management Report shall include:
8744
1. a summary of the fulfilment of the system requirements;
prEN 50126-4
- 56 -
8745
2. a statement on the completion of the verification;
8746
3. a summary of the fulfilment of the technology based requirements and standards;
8747
4. a statement on the fitness for the intended application;
8748
5. a statement on the correctness and completeness of the application conditions;
8749
6. fulfilment of this standard;
8750
8751
7. that for all deviations adequate measures are defined and evidence of the reception of the
measures by the stakeholder is given.
8752
8753
8754
8755
8.2.4.24.1 The Safety Management Report shall provide evidence that a change management
process has been established also for change requests raised from the future life cycle task (see
8.1.12 for the future life cycle task). The established change management process shall be compliant
to requirements listed in 7.8.
8756
8757
8758
8759
8.2.4.24.2 The Safety Management Report shall provide evidence that the Hazard Log has been
created and updated according to requirements defined in 8.2.4.26. A statement shall be made about
Hazard Log contents, in terms of the closure of each hazard, by technical measures or through
application conditions correctly exported to successive phases of the life cycle (see 6.1.4).
8760
8761
8762
8763
8.2.4.24.3 The Safety Management Report shall provide evidence that Safety reviews and Safety
audits have been carried out at appropriate stages in the life cycle, as specified in the Safety Plan
(see 7.7.4.1), and their results fully documented. This evidence can be provided trough reference to
the documented safety reviews results.
8764
8765
8.2.4.25 The Technical Safety Report shall include a summary of the technical safety principles (see
8.1.8) and the used standards (e.g. safety and technology specific standards).
8766
8767
8768
8.2.4.25.1 The Technical Safety Report shall argue that all functional constraints resulting from the
results of verification and validation are correctly reflected in application conditions of the subsystem/component.
8769
8770
8.2.4.25.2 The Technical Safety Report shall identify by references all documentation describing the
system architecture and specify the relation between these documents.
8771
8772
8773
8774
8.2.4.25.3 The Technical Safety Report shall demonstrate that the Man-Machine, Configuration and
Maintenance interfaces are defined completely (with a reference to the documents from 8.1.12). The
Man-Machine interfaces shall be designed and validated by means of well-established methods and
techniques for human factors engineering.
8775
8776
8777
8.2.4.25.4 The Technical Safety Report shall demonstrate that the interfaces of the system at the
boundary of the system (external interfaces) are defined completely (normal operation and dedicated
modes) and that the system meets the interface specification of external systems.
8778
8779
NOTE: All interfaces at the boundary of the system are identified in the System Requirements Specification, see Part 1
Clause 8.5.
8780
8781
8782
8.2.4.25.5 The Technical Safety Report shall demonstrate that the interaction between the
components (software and/or hardware) of the system are defined completely (normal operation and
dedicated modes) and is correct implemented according to the related interface specifications.
8783
8784
NOTE: The interface between the components (software and/or hardware) are described and identified in the system
architecture specification, see 8.1.
- 57 -
prEN 50126-4
8785
8786
8787
8.2.4.25.6 The Technical Safety Report shall show that the system requirements, including the
system safety requirements, are met and that constraints are derived from the deviations (as a
reference to the release note).
8788
8789
8.2.4.25.7 The Technical Safety Report shall identify all system/subsystems/software and hardware
components of the system.
8790
8791
8.2.4.25.8 The Technical Safety Report shall identify the system/subsystems/software and hardware
validation reports of each subsystem or component of the system.
8792
8793
8.2.4.25.9 The Technical Safety Report shall summarise the results of the validation reports of each
subsystem or component of the system with respect to the non-compliances and deviations.
8794
8795
8796
8.2.4.25.10 The Technical Safety Report shall demonstrate that a complete set of constraints is
derived from the non-compliances and deviations documented in the validation reports for each
subsystem or component of the system and included in the release note (see 8.2.4.21).
8797
8798
NOTE: If an assessment report or a safety case and a release note exist for the subsystems or components these should be
used instead of the validation report.
8799
8800
8801
8.2.4.25.11 The Technical safety report shall show that the independent parts are independent. This
should be done by a reference to the system architecture including the additional requirements for
independence and the results of the validation.
8802
8803
8804
8805
8806
8.2.4.25.12 In addition to the quality and safety management techniques which are used to minimise
systematic failures, technical measures shall be taken such that if a hazardous systematic fault
should exist, it would, as far as reasonably practicable, be prevented from creating an hazardous
event. In the Technical Safety Report shall be shown that the technical measures are in place and
sufficient (as a reference to the system architecture).
8807
8808
8809
8810
8811
8.2.4.25.13 The Technical Safety Report shall show that the requirements of the environmental
conditions (climatic, mechanical, altitude, electrical and electromagnetic) are met. This should be
done by identifying the reports for checking the requirements of the environmental conditions
(climatic, mechanical, altitude, electrical and electromagnetic). This can also be achieved by a
reference to the validation report (see 7.4.4.4.1 to 7.4.4.4.14)
8812
8813
8814
8.2.4.25.14 The Technical Safety Report shall demonstrate that inputs via the external interfaces
(random failures, systematic faults, misuse) cannot bring the system in an hazardous state. This
should be done as a reference to the validation report.
8815
NOTE: For the man-machine interface handling errors should be included.
8816
8817
8818
8.2.4.25.15 The Technical Safety Report shall identify the complete documentation which includes
the safety related requirements for the future life cycle tasks identified by 8.1.12 or the integration of
the system as a sub-system into a system.
8819
8820
8821
8.2.4.25.16 The Technical Safety Report shall demonstrate that the set of safety related
requirements for future life cycle task identified by 8.1.12 or integration of the system as a sub-system
into a system is complete.
8822
8823
8824
8.2.4.25.17 The Technical Safety Report shall demonstrate that all properties, from the view of the
architecture and implementation of the system/sub-system, which shall be included in the safety
qualification tests, are specified. The purpose of these tests is
8825
8826
to gain increased confidence that the system/sub-system/equipment fulfils its specified

operational requirements,
8827
to gain increased confidence that the specified reliability and safety targets have been achieved,
8828
8829
to allow systems/sub-systems/equipment to be put into operational service before final Safety

Approval, subject to provision of appropriate precautions and monitoring.
8830
NOTE: These tests only provide increased confidence and are not the unique means for demonstration of safety.
prEN 50126-4
- 58 -
8831
8832
8833
8834
8.2.4.25.18 The Technical Safety Report shall demonstrate that the set of safety related
requirements is referenced by (especially documents from the sub-clause 8.1.12) or included in the
release note (see 8.2.4.21).
8835
8836
8.2.4.26 The Hazard Log shall be written under the responsibility of the Safety Manager, on the basis
of the identified hazardous event. The requirements from 8.2.4.26.1 to 8.2.4.26.6 refer to Hazard Log.
8837
8.2.4.26.1 The Hazard Log shall include all hazards throughout the system life cycle.
8838
8.2.4.26.2 During the development of the system the following hazard analyses shall be prepared:
8839
1. hazard on top level (see EN 50126-1, clause 8.3.4);
8840
2. hazard arising from the system architecture (see 8.1);
8841
3. hazard arising from the hardware implementation (see 9.3);
8842
4. hazard arising from the software implementation (see EN 50128-5).
8843
The Hazard Log should identify these hazard analyses by reference.
8844
8845
8.2.4.26.3 For all hazardous event which are detected and resolved before final acceptance the
hazard log shall include for each hazardous event:
8846
1. hazardous event;
8847
2. contributing subsystem, hardware component and/or software component;
8848
3. solution;
8849
4. validation result.
8850
8851
8852
8.2.4.26.4 For all other hazardous event, which have an influence on the future life cycle phases
identified by 8.1.12, the hazard log shall additionally, to the information from 8.2.4.26.3, include for
each hazardous event:
8853
8854
8855
8856
1. risk (consequences and rate);
8857
2. measures taken to reduce the risk and the argumentation that the measures suitable;
8858
3. evidence of the reception of the measures by the stakeholder;
8859
4. scope and extend of any analysis (including clearly identified exclusions from the scope);
8860
5. assumptions made during the analysis;
8861
6. confidence limits applying to data used within the analysis;
8862
8.2.4.26.5 A review for each hazardous event shall take place.
8863
8864
8.2.4.26.6 For all hazardous events for which no solution is planned the measures shall be included
in one of the plans from Table A.1.
8865
NOTE: In general risk is out of scope for the supplier. But for failures in the system/sub-system, hardware component and
software component a risk based view is really helpful.
- 59 -
prEN 50126-4
8866
8867
9. E/E/PE DEVELOPMENT: GENERIC HARDWARE
8868
8869
8870
All the activities described in this chapter can be partially or completely performed once or several
times to prototyping the hardware to be developed, gaining confidence in its development. In any
case, all the activities shall be performed at least once to produce the final version.
8871
9.1 Hardware Component Specification
8872
9.1.1 Objective
8873
8874
8875
8876
9.1.1.1 To describe a complete set of requirements for the non-configurable hardware of fixed
functionality meeting all system and safety requirements. It provides a comprehensive set of
documents for each subsequent phase and makes it unnecessary to search for requirements in any
other document.
8877
8878
9.1.1.2 To develop the hardware components, according to the defined architecture, that achieve the
hardware requirements.
8879
8880
9.1.1.3 To identify and evaluate the significance of internal and external interactions for safety
(included hardware/software interactions)
8881
8882
8883
9.1.1.4 To ensure that the resultant hardware will be readily testable from the outset. As verification
and test will be a critical element in the validation, particular consideration shall be given to verification
and test needs throughout the implementation.
8884
9.1.1.5 To describe the Hardware Component Test Specification.
8885
9.1.2 Input
8886
2) Hardware Requirements Specification
8887
9.1.3 Deliverables
8888
1)
Hardware Component Specification
8889
2)
Hardware Component Test Specification
8890
3)
Hardware Component Verification Report
8891
9.1.4 Activities
8892
8893
9.1.4.1 A Hardware Component Specification shall be written. The requirements from 9.1.3.1.1 to
9.1.3.1.6 refer to the Hardware Component Specification.
8894
8895
8896
NOTE: The Hardware Component Requirements may be an output of the system architecture (see 8.2.4) when the hardware
requirements found during the system architecture are completely described and no need arise for a more detailed hardware
requirements (e.g. this could happen for simple systems, or when no specific hardware shall be designed).
8897
8898
9.1.4.1.1 The Hardware Component Specification shall express the required properties of the
hardware Component being developed. These properties shall include
8899
8900
a) functional description (number of inputs and outputs and response time performance), including
operation modes
8901
b) identification of safety-related functions including their safety integrity levels,
8902
c) reliability, availability and maintainability,
8903
8904
d) operation with external influences (e.g. environmental conditions) (see also EN 50121, EN 50124,
EN 50125 and for rolling stock EN 50155),
prEN 50126-4
- 60 -
8905
8906
e) information exchanged with other components, including sequencing and time related
requirements,
8907
f) external interfaces
8908
g) efficiency,
8909
h) usability,
8910
i) electric characteristics,
8911
j) mechanical characteristics.
8912
NOTE: Examples of safety principles to be used for interfaces design may be:
8913
a) Separation of energy bands between different signal values,
8914
b) dynamic characteristics of the signal, and its coding strategy if relevant,
8915
8916
c) redundancy and diversity of input/output information (e.g. two contacts associated to each input, one normally open and the
other normally closed.
8917
8918
8919
9.1.4.1.2 The Hardware Component Specification shall include requirements for the periodic testing
of HW functions and components, to the extent required by the Architecture Specification or by the
Subsystem Hazard Analysis, according to allocated TFFR.
8920
8921
9.1.4.1.3 The Hardware Component Specification shall include requirements for the operator
interactions with the hardware (e.g. LED, test points, hot-swap, electrical safety).
8922
8923
8924
9.1.4.1.4 All relevant modes of behaviour of the hardware, in particular failure behaviour, shall be
documented or referenced (e.g. system level documentation) in the Hardware Components
Specification.
8925
8926
9.1.4.1.5 The Hardware Component Specification shall identify all technology related standards
which the hardware has to fulfil (e.g. standards for relays and electronic components).
8927
NOTE: For guidance on development of programmable devices see Annex E.
8928
8929
9.1.4.1.6 The Hardware Component Specification shall include constraints derived from the
Software/Hardware Interface Specification, to ensure the adequacy between hardware and software.
8930
9.1.4.1.7 The Hardware Component Test Specification shall identify the test cases including:
8931
a) the required input data/signals with their sequences and values, when applicable,
8932
b) the expected output data/signals with their sequences and values, when applicable,
8933
c) the acceptance criteria, including performance and quality aspects,
8934
d) initial and operational modes,
8935
e) environmental condition requirements,
8936
f) temperature, dissipated heat and energy consumption.
8937
NOTE: Tests should, if practicable, be performed by automatic means.
8938
8939
9.1.4.1.8 All software used to perform hardware component testing shall be developed and managed
according to clause 7.9.
8940
8941
9.1.4.1.9 Once the Hardware Component Specification and the Hardware Component Test
Specification have been established, Hardware Component Verification shall address:
8942
8943
a) the adequacy of the Hardware Component Specification in fulfilling the requirements set out in the
Sub-System Architectural Specification;
- 61 -
prEN 50126-4
8944
8945
8946
b) that the Hardware Component Specification meets the general requirements for readability and
traceability in 6.1.4.5 to 6.1.4.10 and in 7.6.4.10 to 7.6.4.13 as well as the specific requirements in
9.1.3.1.1 to 9.1.3.1.6;
8947
8948
c) the internal consistency of the Hardware Component Specification and of the Hardware
Component Test Specification;
8949
8950
d) the adequacy of the Hardware Component Test Specification against the Hardware Component
Specification.
8951
8952
NOTE: If the Hardware Component Specification is an output of the sub-system architecture (see 8.1), then its verification too
is addressed in the sub-system architecture and apportionment phase.
8953
8954
9.2 Hardware Component Implementation
8955
9.2.1 Objective
8956
8957
9.2.1.1 To develop a hardware design that achieves the requirements of the Hardware Architecture
Specification to the extent required by the safety integrity level.
8958
8959
9.2.1.2 To develop an Hardware Design Test Specification that achieves the requirements of the
Hardware Design Specification to the extent required by the safety integrity level.
8960
9.2.1.3 To choose a design method if one has not been previously defined.
8961
9.2.2 Deliverables
8962
1) Hardware Design Specification
8963
2) Hardware Manufacturing Data
8964
9.2.3 Requirements
8965
9.2.3.1 The Hardware Design Specification shall be based on the safety principles see 8.1.8..
8966
8967
9.2.3.2 The Hardware Design Specification shall give detailed design information of the hardware
component.
8968
9.2.3.3 The Hardware Design Specification shall address:
8969
8970
a) configuration history, including a precise identification of the current and all previous versions,
specifying date and designer, and a description of the changes made from the previous version;
8971
b) standards to be used for implementation
8972
8973
9.2.3.4 The Hardware Design Specification shall choose the components for inherent fail safe
hardware circuits taking into account the failure modes described into ANNEX B.
8974
9.3 Hardware Component Validation
8975
9.3.1 Objective
8976
8977
8978
To analyse and test the Hardware Component to ensure compliance with the Hardware Component
Specification with particular emphasis on the functional and safety aspects, according to the TFFR
and to check whether it is fit for its intended application.
prEN 50126-4
- 62 -
8979
9.3.2 Deliverables
8980
1)
Hardware Component Test Report
8981
2)
Hardware Component Safety Verification
8982
3)
Hardware Component Validation Report
8983
9.3.3 Requirements
8984
8985
8986
8987
9.3.3.1.1 The Validator shall specify and perform supplementary tests on his discretion or have them
performed by the Tester. While the Hardware Tests are mainly based on the structure of the
Hardware Requirements Specification, the added value the Validator shall contribute, are tests which
stress the system by complex scenarios reflecting the actual needs of the user.
8988
8989
9.3.3.1.2 The results of all tests and analyses shall be recorded in a Hardware Component Test
Report.
8990
9.3.3.1.3 All degraded modes of behaviour of the hardware, in case of failure, shall be documented.
8991
8992
8993
9.3.3.2 The Hardware Safety Verification shall identify the new hazards arising from the design. To
control these hazards, mitigations shall be derived from that new hazards and allocated to the related
hardware components. This hazard analysis fulfils the requirements from 7.1.
8994
8995
8996
8997
8998
9.3.3.3 The Hardware Safety Verification shall be based on the Hardware Design Specification and
on the Hardware Manufacturing data and shall check whether the Hardware Component meets the
safety requirements as established in Architecture Specification, Hardware Component Specification
and Hardware Detailed Design, using appropriate techniques as described in Table A.7 (e.g.
insulation distance measurement, FMECA using elements failure modes, ).
8999
9000
9.3.3.4 For inherent fail-safe hardware, the Hardware Safety Verification shall check the correctness
of each element selection.
9001
9.3.3.5 The Hardware Component Validation shall:
9002
9003
a) state whether the planned objectives and criteria for the HW Component validation have been met.
Deviations to the plan shall be recorded and justified;
9004
b) evaluate the test coverage on the Hardware Component Specification;
9005
c) evaluate hardware safety verification activities;
9006
a) identify the configuration of the Hardware Component and related support tools;
9007
b) evaluate the adequacy of the Hardware Test Specification;
9008
c) evaluate the test coverage on the Hardware Component Specification.
- 63 -
prEN 50126-4
9009
9010
10. E/E/PE DEVELOPMENT: CONFIGURABLE HARDWARE
9011
10.1 Requirements
9012
10.1.1 Objective
9013
9014
9015
9016
10.1.1.1 To describe a complete set of requirements for the configurable hardware of alterable
functionality meeting all System and Safety Requirements. It provides a comprehensive set of
documents for each subsequent phase and makes it unnecessary to search for requirements in any
other document.
9017
9018
10.1.1.2 All the requirements for the generic hardware apply to configurable hardware. However,
additional requirements are described here.
9019
10.1.2 Input
9020
See 9.1.2
9021
10.1.3 Deliverables
9022
See 9.1.3
9023
10.1.4 Requirements
9024
9025
10.1.4.1 All the configurable states shall be described and treated as separate generic hardware
designs where distinct functionalities may arise as a consequence of soft or hard configuration.
9026
9027
10.1.4.2 The requirements described in clause 9 of this standard for generic hardware are applicable
to each distinct class of functionality.
9028
9029
9030
10.1.4.3 Where a significant extent of functionality is unaltered through reconfiguration, the common
functionality shall be treated once but each changed functionality shall be treated as a separate
generic hardware.
9031
9032
9033
10.1.4.4 Where a common functionality is identified, the scope of regression testing for every
hardware configuration shall be subject to an impact analysis. The independence of the
hardware/system configuration states shall be considered in the extent and scope of testing.
9034
9035
NOTE: Impact analysis shall also consider the need for environmental, mechanical, electrical and electromagnetic compatibility
tests as appropriate to the nature of new configurations.
prEN 50126-4
- 64 -
9036
9037
11. E/E/PE SYSTEMS OPERATION AND MAINTENANCE
9038
9039
NOTE: The term System Deployment is meant to cover the early operation of the system (post commissioning) as well as the
complete operation, including retrofit, of the system until its decommissioning.
9040
11.1 Planning & Organisation
9041
11.1.1 Objective
9042
9043
9044
The objective of this sub-clause is to detail the key organisational responsibilities for assurance of the
safe deployment and maintenance of the electronic system and hardware delivering the safety
functions during the Operation and Maintenance phase.
9045
11.1.2 Input
9046
9047
1) Operation and Maintenance requirements from Designer, Manufacturer, Operations Manager and
Maintenance Manager.
9048
11.1.3 Deliverables
9049
1) Operation and Maintenance Plan
9050
11.1.4 Requirements
9051
9052
9053
9054
11.1.4.1 During the Operation and Maintenance phase those who are responsible for operating and
maintaining the safety related system/sub-system/hardware shall agree on an Operation and
Maintenance Plan that includes roles and responsibilities of parties responsible for activities specified
below. It is the responsibility of the Safety Manager to manage the safety aspects of this plan.
9055
9056
9057
11.1.4.2 Performance Monitoring including maintaining the Hazard Log / Safety Related Application
Conditions (SRACs), Failure Reporting and Corrective Action System (FRACAS), incident and
accident investigation;
9058
11.1.4.3 Rapid response fault finding and repair;
9059
11.1.4.4 Product introduction, maintenance and spare parts management;
9060
11.1.4.5 Operation;
9061
11.1.4.6 Modification;
9062
11.1.4.7 Putting system/subsystem, hardware back into service after recovery from failures;
9063
11.1.4.8 Competence management for the relevant staff.
9064
9065
11.1.4.9 The activities specified in 8.12.2.2 of EN 50126-1 shall be implemented in the Operations
and Maintenance plan.
9066
9067
9068
9069
11.1.4.10 The roles and responsibilities defined in the Operation and Maintenance Plan shall define
sufficient level of independence between entities responsible for safety and entities responsible for
the execution of maintenance and operation. Depending on the SIL of the system function (delivered
by the system/subsystem and/or hardware) the following level of independence shall apply:
9070
9071
a) In SIL 3 and 4 applications the entity responsible for safety of the system shall have budgetary and
reporting independence from the entity responsible for operations and maintenance.
9072
9073
b) In SIL 0, 1 and 2 applications the entity responsible for safety may have budgetary and reporting
independence from the entity responsible for operations and maintenance.
9074
9075
9076
NOTE: The availability of safety resources should be carefully evaluated to ensure that the necessary skills are available
according to the needs of the operation and maintenance organisations. After the initial operation and maintenance phase the
safety organisation may need to be reviewed to match the likely reduction in the scope and intensity of work.
- 65 -
prEN 50126-4
9077
9078
9079
9080
11.1.4.11 The Operation and Maintenance Plan shall show that the operation and maintenance
organisation is capable of fulfilling all safety requirements outlined in following sub-clause s 11.1.4.12
to 11.1.4.14, assuring sufficient quality (acceptable level of systematic or deterministic errors) related
to the required SIL of the electronic system/ subsystem functions.
9081
9082
11.1.4.12 The Operation and Maintenance Plan shall be reviewed regularly and updated as required.
The process to undertake reviews shall be defined in the Operation and Maintenance Plan.
9083
9084
NOTE: These updates shall include issues raised and addressed during the initial operation and maintenance phase and at
appropriate stages thereafter.
9085
9086
9087
9088
11.1.4.13 The Operation and Maintenance Plan shall define the process of handling hazardous
incidents and accidents. The management of the hazardous incident and accident investigation and
management process and organisation shall be independent of the management of the operation and
maintenance organisations.
9089
9090
9091
9092
11.1.4.14 The Operation and Maintenance Plan shall define for systems undergoing modification, a
process for identifying and implementing mitigation actions proportionate to the identified risk. These
mitigation actions shall ensure the overall integrity of the system whilst the modification is completed
or reported problems are investigated and corrected.
9093
9094
11.2 System Deployment
9095
11.2.1 Objective
9096
9097
9098
11.2.1.1 To ensure that the system performs within the required parameters, preserving the required
system safety integrity level, when it is put into service (deployed) in an existing system that is under
operation or as a completely new system (green field).
9099
9100
9101
11.2.1.2 To ensure that the system performance is closely monitored and controlled until confidence
in the system performance, including the performance of the operators and maintainers, is achieved
so that the system can be operated normally.
9102
9103
9104
NOTE: The system that will be put into service can be an extension or the replacement of equipment by an updated version. In
both cases there is an interface with other systems that are under operation and the organisation of operation and
maintenance.
9105
11.2.2 Input
9106
1) System specification and requirements of the electronic system
9107
2) System Safety Case and/or Release note
9108
3) Hazard Log
9109
4) FRACAS
9110
5) Notifications of hazardous incidents and accidents
9111
6) Observations and anomalies
9112
9113
8) Operation and Maintenance Manuals
9114
9) SRACs
9115
10) Maintenance procedures
9116
11) Operational procedures
9117
12) Test Logs
prEN 50126-4
9118
13) Operational Manuals
9119
14) Operational Training Certificates
9120
15) Spares Strategy
9121
16) Maintenance Training Certificates
9122
17) Emergency Services Notifications
- 66 -
9123
9124
11.2.3 Deliverables
9125
1) System Deployment Plan
9126
2) System Deployment Records
9127
3) Up to date FRACAS
9128
4) Hazardous incidents/accidents reports, including risk assessments
9129
5) Up to date Hazard Log
9130
6) Change Requests
9131
7) Up to date operation and maintenance plans, manuals and procedures
9132
9133
11.2.4 Requirements
9134
9135
11.2.4.1 An operations and maintenance organisation as required in the Operation and Maintenance
Plan shall be in place prior to the deployment of the system.
9136
9137
11.2.4.2 An Operation and Maintenance Plan as required in 11.3.4.1 shall be available and
implemented prior to the deployment of the system.
9138
11.2.4.3 A FRACAS shall be in place as required in 11.3.4.5.
9139
9140
11.2.4.4 Before delivering a system, the system baseline shall be recorded and kept traceable under
configuration management control.
9141
9142
9143
11.2.4.5 A System Deployment Plan shall be written under the responsibility of the Project Manager.
The activities specified in 8.12.4.4 of EN 50126-1 shall be implemented in the System Deployment
Plan.
9144
9145
9146
11.2.4.5.1 If the system is to be deployed in phases, the System Deployment Plan shall have clear
phases for system deployment identified. For each phase it shall define which
system(s)/subsystems(s) are operating in which operational modes.
9147
11.2.4.5.2 For each phase, start conditions shall be defined.
9148
9149
11.2.4.5.3 For each phase, tests evidencing the correct operations shall be defined, including pass
fail criteria.
9150
9151
11.2.4.5.4 In case of the system being deployed within the existing railway, a rollback procedure (i.e.,
capability to return to the previous release) shall be available for each phase in the deployment.
9152
9153
9154
11.2.4.5.5 The impact on the operation of other (adjacent) systems shall be addressed. When
needed, specific additional operational instructions or maintenance instructions shall be defined and
issued.
9155
11.2.4.6 The deployment shall be carried out under the responsibility of those responsible for
- 67 -
prEN 50126-4
9156
9157
operation and maintenance. These entities shall agree on and accept the System Deployment Plan
before the deployment.
9158
9159
11.2.4.7 During the deployment a System Deployment Record shall be written under the
responsibility of the Project Manager.
9160
9161
11.2.4.7.1 The System Deployment Record shall give evidence prior to commencement of each
phase of the System Deployment Plan that the start conditions are met.
9162
9163
11.2.4.7.2 The System Deployment Record shall give evidence that for each phase of the
deployment the completion conditions are met.
9164
9165
9166
11.2.4.7.3 The System Deployment Record shall give evidence that for each phase of the
deployment the pass conditions of the planned test as defined in the System Deployment Plan are
met.
9167
9168
9169
11.2.4.8 Anomalies or errors observed during the deployment shall be captured within a FRACAS
and evaluated against the required safety function of the system. Part of this evaluation shall be a
review of the following:
9170
a) Operation and maintenance procedures and manuals;
9171
b) System training documentation;
9172
c) Hazard Log;
9173
d) System design;
9174
e) Human factors aspects of operation and maintenance.
9175
9176
11.2.4.9 The System Deployment Record should be reviewed by the Operations Manager and
Maintenance Manager as part of the system handover process.
9177
9178
11.2.4.10 The exact configuration of the deployed system shall be traceable to delivered
installations.
9179
NOTE: This is of special importance when critical faults are discovered and need to be corrected in more than one installation.
9180
9181
11.2.4.11 Quality measures shall be included in the System Deployment Plan to prevent or detect
errors occurring during storage and transfer.
9182
9183
11.3 Operation and Maintenance including Performance Monitoring
9184
11.3.1 Objective
9185
9186
9187
9188
The objective of this sub-clause is to define the safety assurance activities necessary during
operation, maintenance and repair to maintain the features incorporated into the design and the
mitigations and safety requirements contained within the hazard log and SRACs as defined during
safety analysis and system acceptance.
9189
11.3.2 Input
9190
1) System specification and requirement of the electronic system
9191
2) System Safety Case and/or Release note
9192
3) Hazard Log
9193
4) FRACAS
9194
5) Notifications of hazardous incidents and accidents
prEN 50126-4
9195
6) Observations and anomalies
9196
9197
8) Operation and Maintenance Manuals
9198
9) SRACs
9199
10) Maintenance procedures
9200
11) Operational procedures
- 68 -
9201
9202
11.3.3 Deliverables
9203
1) Up to date FRACAS
9204
2) Hazardous incidents/accidents reports, including risk evaluation
9205
3) Up to date Hazard Log
9206
4) Change Requests
9207
5) Up to date Operation and Maintenance Plan
9208
6) Up to date Operation and Maintenance manuals
9209
7) Up to date Operational procedures
9210
8) Up to date Maintenance procedures
9211
9212
11.3.4 Requirements
9213
9214
9215
9216
11.3.4.1 An Operations and Maintenance Plan shall be developed. The safety documentation of the
electronic system, subsystem or hardware shall include details of safety controls necessary for
operation and maintenance activities. These controls are documented in the SRAC clause of the
System Safety Case or the release note and the maintenance and operation instructions:
9217
9218
a) All SRACs relating to operation and maintenance shall be included in the Operation and
Maintenance Plan;
9219
9220
b) The Operation and Maintenance Plan shall include all other maintenance and operation
instructions;
9221
9222
c) The evidence of correct execution of the Operation and Maintenance Plan shall be documented
and records maintained.
9223
NOTE: The Operation and Maintenance Plan should include the following:
9224
9225
1)
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
An explanation of operational status: The conditions that exist in each electronic system/sub-system/hardware should be
defined to provide operating and maintenance personnel with sufficient understanding during the following situations:
a)
b)
c)
d)
2)
start-up: This should describe the start-up conditions of the system, sub-system or hardware when power is initially
applied, or following shut-down due to power interruption or other cause.
normal operation: Once the system/sub-system/hardware has successfully completed initialisation, the conditions
during normal operation shall be defined.
changeover: If the system/sub-system or hardware in which it is configured, has a facility to change over to either a
cold or hot standby system/sub-system, then the conditions defined in a) and b) should be re-stated for this
changeover routine. The reaction of the system/sub-system or hardware to the changing of failed modules shall also
be clearly defined.
shut-down: When an system/sub-system or hardware is shut down intentionally for a configuration change or decommissioning, or unintentionally via a power failure, then all relevant conditions shall be defined.
maintenance should be defined in respect of:
- 69 9237
9238
9239
9240
9241
a)
b)
3)
prEN 50126-4
that undertaken on the system in-situ or at designated routine maintenance facilities,

the repair or refurbishment of systems, subsystems or hardware that are no longer in-situ or that is taking place in
facilities not classed as routine maintenance facilities, e.g. mid-life overhauls. that undertaken by the customer and
the manufacturer.
It should include:
9242
9243
9244
4)
Maintenance aids: For each level of maintenance, the maintenance aids available to personnel should be defined.
9245
5)
An analysis of human factors in maintenance that can influence the continued achievement of the defined SIL.
9246
6)
An analysis of human factors in operation that can influence the continued achievement of the defined SIL.
9247
7)
Protection against sabotage.
9248
9249
11.3.4.2 The activities specified in 8.12.2 of EN 50126 part 1 shall be implemented in the
Operations and Maintenance Plan.
9250
9251
9252
11.3.4.3 For safety critical electronic systems, sub-systems and hardware, maintenance instructions
shall include procedures to ensure that after regular maintenance, or failure and repair, the intended
safety function is correctly restored. These procedures shall include:
9253
a) Tests to show the correctness of the (safety) functions of the system, sub-system and hardware;
9254
b) Appropriate independence between the persons repairing or maintaining and testing.
9255
9256
11.3.4.4 During operation and maintenance, a log of all observations and anomalies shall be
recorded and maintained by the operation and maintenance organisation(s) within a FRACAS.
9257
9258
11.3.4.5 Observations and anomalies shall be included in the records for operation and
maintenance.
9259
9260
9261
9262
NOTE: The operational log book and maintenance records are evidence of safe operation and maintenance, including the
correct application of instructions. This information acts as an input to the performance monitoring process (see earlier subclause on performance monitoring). The various manuals and instructions will need to be kept up to date, with changes being
made following design changes or as a result of operational feedback.
9263
9264
11.3.4.6 All records of relevant safety events regarding operation, repair and maintenance of the
system, subsystem or hardware shall be maintained and shall contain the following information:
9265
a) The results of tests of safety functions;
9266
9267
b) Record of all failures, including safety related failures, found during operation and maintenance
and their corrective actions. These shall be included in the FRACAS;
9268
9269
c) Evidence demonstrating the correct operation and maintenance of the system, subsystem or
hardware;
9270
9271
9272
9273
9274
11.3.4.7 The FRACAS shall be maintained throughout the operation and maintenance life cycle. To
ensure that priority issues are addressed, the failures and defects should be categorised for both
safety and reliability for varying levels of severity / criticality. As a minimum the FRACAS shall be
populated with information about failures and defects identified during operation and maintenance.
This information shall include:
9275
a) time of the failure;
9276
b) cause of the failure;
9277
c) detailed description of the failure;
9278
d) corrective action taken;
9279
e) safety ranking for the failure.
a)
b)
Preventative maintenance
Corrective maintenance
prEN 50126-4
- 70 -
9280
9281
9282
9283
9284
9285
9286
11.3.4.8 The FRACAS process is required to continuously provide feedback to the operations safety
manager, the designer, manufacturer, Operations Manager and Maintenance Manager regarding any
failures and defects (and possible causes) found during operational service, Failures will potentially
have a variety of causes including component failures, operational errors, maintenance and other
errors. It is therefore imperative that the reporting process is clear and logical and that there is a
collective forum for all stakeholders to agree the most likely source of failure and hence investigation
and corrective actions.
9287
9288
NOTE: Referencing of accidents, hazards and causes should be consistent within the safety case and other performance
monitoring tools and processes. This will help respective organisations to align issues and identify trends.
9289
9290
9291
11.3.4.9 All accidents and safety related incidents shall be investigated. This shall be coordinated by
the safety manager. The results of the investigation shall be documented in a report which shall
include:
9292
a) Description of the incident;
9293
b) Root Cause analysis;
9294
c) Conclusions and recommendations.
9295
9296
9297
11.3.4.10 The FRACAS, anomalies reports and incident/accident investigation reports shall be
evaluated against the required safety function of the system. Part of this evaluation shall be a review
of the following:
9298
a) Operation and maintenance procedures and manuals;
9299
b) system training documentation;
9300
c) Hazard Log;
9301
d) System design;
9302
e) human factors aspects of operation and maintenance.
9303
9304
9305
11.3.4.11 In cases where a change of the system, manuals or procedures is required as a

consequence of this review, a formal change request shall be produced. The change request shall
contain the following information:
9306
a) Reason for change;
9307
b) Original system requirement and the changed requirement.
9308
9309
11.4 Modification
9310
11.4.1 Objective
9311
9312
The objective of this sub-clause is to define the safety assurance activities necessary to maintain the
required safety performance during modification.
9313
11.4.2 Input
9314
1) System Safety case including Hazard Log; and /or release note
9315
2) System specification and requirements
9316
3) Operation and maintenance plans and manuals
9317
4) Change request
- 71 -
prEN 50126-4
9318
11.4.3 Deliverables
9319
1) Design modification instructions
9320
2) Design specifications and requirements updated as required
9321
3) System Safety case updated as required to include design modification and/or risk analysis
9322
4) Updated deployment and maintenance plans and manuals as required
9323
9324
11.4.4 Requirements
9325
9326
NOTE: During the operational life of a system, change requests may be raised for a variety of reasons, not all of which will be
safety-related.
9327
9328
11.4.4.1 An impact analysis shall be performed on each modification change request. The analysis
shall include reviewing the impact on:
9329
a) the system/sub-system or hardware operational/functional safety performance;
9330
b) the system/subsystem/hardware interfaces;
9331
c) adjacent system/sub-system or hardware operational/functional safety performance;
9332
9333
d) the modification installation work, with consideration given to adjacent system/sub-system and
hardware that maybe affected due to systematic failures.
9334
9335
11.4.4.2 Each change request shall be evaluated for its impact on system safety performance, by
reference to the relevant portion of the safety case.
9336
9337
9338
9339
11.4.4.3 The impact analysis shall result in a decision on which parts of the safety life cycle will be
repeated for the modification, all relevant documentation for the effected life cycle steps shall be
updated, with equal depth and quality as the original documentation that was produced during the
development of the system.
9340
9341
11.4.4.4 All changes and system/sub-system or hardware identified as being at risk shall be tested
for correct operation on completion of the change.
9342
9343
11.4.4.5 The details and results of the modification, risk analysis and testing shall be included in the
safety case.
9344
9345
11.4.4.6 Only the change approved by this process shall be implemented. Any changes not
approved by this process shall not be implemented.
9346
9347
11.4.4.7 An auditable trail of the impact analysis and decision making process shall be documented
and maintained.
9348
9349
prEN 50126-4
- 72 -
Annex A
(normative)
Techniques/Measures
9350
9351
9352
9353
9354
9355
Safety Integrity Levels (SIL) are defined at functional level for the systems/sub-systems implementing
the functionality. This annex relates architectures, techniques and measures to avoid systematic
faults and control random and systematic faults to the different Safety Integrity Levels 0-4.
9356
Therefore the following tables describe the various techniques/measures against the five SILs.
9357
9358
With each technique or measure in these tables there is a recommendation for each Safety Integrity
Level (SIL) 0 to 4.
9359
'M'
this symbol means that the use of a technique is mandatory,
9360
9361
9362
"HR"
This symbol means that the measure or technique is Highly Recommended for this safety
integrity level. If this technique or measure is not used the rationale behind not using it shall
be detailed.
9363
9364
"R"
This symbol means that the measure or technique is Recommended for this safety integrity
level.
9365
9366
"-"
This symbol means that the technique or measure has no recommendation for or against
being used.
9367
9368
9369
NR
this symbol means that the technique or measure is positively Not Recommended for this
safety integrity level. If this technique or measure is used then the rationale behind using it
shall be detailed.
- 73 -
9370
prEN 50126-4
Table A.1 Lifecycle Issues and Documentation

DOCUMENTATION
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1. System Quality Assurance Plan
HR
HR
HR
HR
HR
2. System Quality Assurance Verification Report
HR
HR
HR
HR
HR
HR
HR
HR
HR
4. System Configuration Management Plan
HR
HR
HR
HR
HR
5. System Verification Plan
HR
HR
HR
HR
HR
6. System Validation Plan
HR
HR
HR
HR
HR
7. System Requirements Specification
HR
HR
HR
HR
HR
8. System Requirements Verification Report
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
11. System Integration Test Specification
HR
HR
HR
HR
HR
12. System Architecture Verification Report
HR
HR
HR
HR
HR
13. Hardware Component Specification
HR
HR
HR
HR
14. Hardware Component Test Specification
HR
HR
HR
HR
15. Hardware Component Verification Report
HR
HR
HR
HR
16. Hardware Detailed Design Specification
HR
HR
HR
HR
17. Hardware Manufacturing Data
HR
HR
18. Hardware Safety Verification
HR
HR
19. Hardware Component Test Report
HR
HR
HR
HR
20. Hardware Component Validation Report
HR
HR
HR
HR
21. Software/Hardware Integration Test Specification
HR
HR
HR
HR
22. Software/Hardware Integration Verification Report
HR
HR
HR
HR
23. Software/Hardware Integration Test Report
HR
HR
24. System Integration Test Report
HR
HR
HR
HR
HR
25. System Validation Report
HR
HR
HR
HR
HR
26. Tools Validation Report
HR
HR
HR
HR
27. System Safety Case
HR
HR
HR
HR
HR
HR
HR
HR
HR
Planning
3. System Safety Plan
System Requirements
Architecture and Design

9. System Architecture Specification
10. Hazard Analysis
HW Component Specification
HW Component Implementation
HW Component Validation
Integration and Validation
28. Release Note

9371
prEN 50126-4
9372
- 74 -
Table A.2 Safety Planning and Quality Assurance Activities

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
H.2.2
HR
HR
1.
Checklists
2.
Audit of tasks
9.6.4.5
Table
D.7
3.
Inspection of issues of
documentation
7.3
H.2.16
HR
HR
HR
HR
4.
Review after change in the safety

plan
HR
HR
HR
HR
5.
Review of the safety plan after

each safety life cycle phase
HR
HR
HR
HR
Requirements/Notes:
Note 1. Technique 3 for SIL 0, 1 & 2 shall be applied only to documents agreed between
railway/safety authority and industry. For SILs 3 & 4 it applies to all documentation.
9373
- 75 -
9374
prEN 50126-4
Table A.3 System Requirements Specification

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Separation of Safety-Related Systems

from Non Safety-Related Systems
HR
HR
2.
Graphical description including for

example block diagrams
HR
HR
HR
HR
3.
Structured Specification
H.2.1
H.2.20
HR
HR
HR
HR
4.
Formal or semiformal methods
H.2.1
H.2.2
H.2.4
H.2.12
H.2.35
5.
Computer aided specification tools
6.7
6.
Checklists
H.2.2
HR
HR
HR
HR
7.
Hazard Log
8.7
HR
HR
HR
HR
8.
Inspection of the specification
7.3
H.2.16
HR
HR
HR
HR
9.
Prototyping/Animation
H.2.25
10. Domain Specific Languages
H.2.6
11. Traceability
H.2.33
HR
HR
HR
HR
Requirements/Notes:
Note 1. Technique 1 means that for SILs from to 1 to 4, well definition of the interfaces between
Safety-Related Systems and Non Safety-Related Systems (SRS). For SILs 3 & 4, moreover,
Technique 1 implies also an Interface analysis.
Note 2. Technique 6 implies the preparation of detailed checklists for all safety life cycle phases.
Note 3. Checklists or computer aided specification tools shall be used with another method since they
usually state what to do (in order not to forget something), but cannot guarantee the quality of
what is actually achieved.
9375
prEN 50126-4
9376
- 76 -
Table A.4 Safety Organisation

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Training of staff in safety organisation
6.3
HR
HR
HR
HR
2.
Independence of roles
6.3
See
Note 1
HR
HR
HR
HR
3.
Qualification of staff in safety organisation
6.3
See
Notes 2
and 3
HR
HR
HR
HR
HR
Requirements/Notes:
Note 1. See Clause 6.2 for details on independence requirements for every SIL.
Note 2. Staff involved in safety activities shall be competent to perform those activities (see
Clause 6.3).
Note 3. For SILs from 0 to 2, Technique 3 implies technical education or sufficient experience. For
SILs 3 & 4, it implies higher technical education or extensive experience.
9377
- 77 -
9378
prEN 50126-4
Table A.5 Architecture of System/Subsystem/Equipment

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Separation of safety-related systems from

non safety-related systems
HR
HR
HR
HR
2.
Single electronic structure with self tests and

supervision
NR
NR
3.
Dual electronic structure
NR
NR
4.
Dual electronic structure based on

composite fail-safety with fail-safe
comparison
HR
HR
5.
Single electronic structure based on inherent

fail-safety
HR
HR
6.
Single electronic structure based on reactive

fail-safety
HR
HR
7.
Diverse electronic structure with fail-safe

comparison
HR
HR
8.
Justification of the architecture by a

quantitative reliability analysis of the
hardware
See
Note 3
HR
HR
HR
HR
9.
Dynamic Reconfiguration
H.2.7
NR
NR
10. Error Detecting Codes
H.2.8.1
HR
HR
11. Error Correcting Codes
H.2.8.1
Requirements/Notes:
Note 1: For SILs 1 & 2, Techniques from 2 to 7 are alternatives, i.e. R means that at least one of
these techniques is recommended.
Note 2: For SILs 3 & 4, Techniques from 4 to 7 are alternatives, i.e. HR means that at least one of
these techniques is highly recommended.
Note 3: Technique 8 can be implemented trough FT (Ref. H.2.30.7) or RBD (ref. H.2.30.11) or Markov
Models, for complex systems (ref. H.2.18)
Note 4: Techniques 2 and 3 are NR for SILs 3 & 4, as for these SILs techiniques from 4 to 7 are to be
used.
prEN 50126-4
9379
- 78 -
Table A.6 Design Features

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
H. 2. 30.9
See Note 1
HR
HR
1.
Protection against operating errors
2.
Protection against sabotage
See
Note 2
HR
HR
3.
Protection against single fault for

discrete components
8.2.4
See
Note 3
HR
HR
4.
Basic insulation
See
Note 4
HR
HR
5.
Reinforced insulation
See
Note 4
6.
Protection against single fault for

integrated circuits for digital
electronic technology
8.2.4
B.3
See
Note 5
HR
HR
7.
Detection of single faults by

deviation from normal operation
8.2.4
H.2.10
8.
Detection and negation of a single

hazardous fault with time for
detection-plus-negation within the
safety target
8.2.4
H.2.10
HR
HR
9.
Retention of safe state through

indication to not use or rely on the
safety-related functions associated
to the faulty item
8.2.4
See
Note 6
NR
NR
10. Retention of safe state through

shut-down, or blocking of all safetyrelated functions
8.2.4
HR
HR
11. Detection of multiple faults by

deviation from normal operation
8.2.4
12. Detection and negation of a single

fault involved in hazardous faults
chains with time for detection-plusnegation within the safety target,
through on line dynamic testing
8.2.4
See
Note 7
HR
HR
13. Program sequence monitoring
See
Note 8
HR
HR
HR
14. Fault Isolation Methodology
H.2.11
NR
NR
NR
NR
15. Graceful Degradation
H.2.13
See
Note 11
16. Measures against voltage

breakdown, voltage variations,
overvoltage, low voltage
See
Note 9
HR
HR
HR
HR
17. Measures against temperature
See
HR
HR
HR
HR
- 79 -
TECHNIQUE/MEASURE
increase
Ref
prEN 50126-4
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
Note 10
18. Recovery Block
See
Note 11
19. Retry Fault Recovery Mechanism
See
Note 11
20. Safety Bag
H.2.29
20. Software architecture
See Part 5, Table A.3
Requirements/Notes:
Note 1: For Man-Machine interface, Technique 1 can be implemented as plausibility check for each input
command.
Note 2: For SILs 3 & 4, Technique 2 should be complemented with organisational measures.
Note 3: Technique 3 means all hazardous failure modes to be either detected and negated or
demonstrated to be inherently safe such as a result of inherent physical properties (See
Annex C).
Note 4: Techniques 4 & 5 refer to EN 50124-1.
Note 5: Faults to be considered for Technique 6 are: stuck-at faults at SIL 1; DC-Faults for SIL 2,
permanent and transient malfunctions on item level for SIL 3 & 4.
Note 6: Technique 9 is NR for SILs 3 & 4, as for these SILs Technique 10 applies.
Note 7: Technique 11, for SILs 2, 3 & 4, is Mandatory when used with techniques 4 and 7 of Table A.5. In
combination with techniques 5 and 6 of Table A.5, it is HR.
Note 8: Technique 12 at SILs 3 & 4 implies the usage of temporal and logical monitoring of the program
sequence at many checking points in the program and automatically shut down the faulty item,
sub-system or system from the process or blocking all safety related functions of this faulty item,
sub-system or system.
Note 9: The extent of measures adopted for Technique 15 varies with the SIL.
Note 10: For SILs 3 & 4, it should be investigated the necessity of safety shut down, in case of
temperature increase.
Note 11: Techniques 14, 17 and 18 can be useful to increase availability, provided that their
implementation does not affect chosen M/HR techniques.
prEN 50126-4
9380
- 80 -
Table A.7 Failure and Hazard Analysis Methods

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Preliminary hazard analysis
H.2.30.10
HR
HR
HR
HR
HR
2.
Fault tree analysis
H.2.30.7
HR
HR
3.
Markov diagrams
H.2.18
HR
HR
4.
FMECA
H.2.30.4
H.2.30.5
H.2.30.6
HR
HR
5.
HAZOP
H.2.30.8
HR
HR
6.
Cause-consequence diagrams
H. 2.1
HR
HR
7.
Event tree
H. 2.9
8.
Reliability block diagram
H.2.30.11
9.
Zonal analysis
H.2.17
HR
HR
H.2.30.1
HR
HR
H.2.5
14. Operating and support Hazard Analysis
H.2.30.9
15. Sneak Circuit Analysis
H.2.30.15
10. Interface hazard analysis

11. Common cause failure analysis
12. Historical event analysis
13. Design Analysis
Requirements/Notes:
Note 1: Technique 1, PHA, should only be considered at the early stages of the development. When
precise technical information is available, during the design, the other methods should be
preferred.
Note 2: Techniques 2 and 3 can be considered mutually exclusive.
9381
- 81 -
9382
prEN 50126-4
Table A.8 Design and Development of System/Sub-system/Item

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
See Note 1
HR
HR
HR
HR
HR
1.
Structured design
2.
Modularisation
H.2.20
HR
HR
HR
3.
Formal or semiformal methods
H.2.1
H.2.2
H.2.4
H.2.12
H.2.35
4.
Computer aided design tools
6.7
5.
Computer aided design trusted/verified

tools
H.2.34.1
H.2.34.3
6.
Environmental studies (EMC, vibration etc.)
8.6.4.23.17
HR
HR
HR
HR
HR
7.
DSL
H.2.6
8.
Performance Modelling
H.2.23.1
9.
Traceability
H.2.33
HR
HR
HR
HR
H.2.34.2
H.2.3
HR
HR
HR
HR
10. Library of Trusted/Verified Components

11. Configuration management
Requirements/Notes:
Note 1: Technique 1, for SILs 3 & 4, shall be completed by full traceability between specification,
design, circuit diagrams and application documentation.
9383
9384
Table A.9 Design Phase Documentation

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
HR
HR
HR
HR
8.2
HR
HR
HR
HR
HR
HR
HR
1.
Graphical description of sub-systems
2.
Description of interfaces
3.
Environment (EMC, vibrations) studies
4.
Modification procedure
7.7
H.2.3
HR
HR
HR
HR
HR
5.
Maintenance manual
11.3
HR
HR
HR
HR
6.
Manufacturing documentation
8.8
9.6
HR
HR
HR
HR
7.
Application Documentation
HR
HR
HR
HR
Requirements/Notes: None
prEN 50126-4
9385
- 82 -
Table A.10 Verification and Validation of the System and Product Design
TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Checklists
H.2.2
HR
HR
HR
HR
2.
Simulation
H.2.21
See Note
1
3.
Functional testing of the system
A.12
HR
HR
HR
HR
HR
4.
Functional
conditions
HR
HR
HR
HR
HR
5.
Surge immunity testing
See Note
2
HR
HR
HR
HR
6.
Inspection of documentation
7.3
H.2.16
HR
HR
HR
HR
HR
7.
Ensure design assumptions are not

compromised by manufacturing process
9.6
HR
HR
8.
Test facilities
HR
HR
9.
Design review
H.2.16.2
HR
HR
HR
HR
10. Ensure design assumptions are not

compromised
by
installation
and
maintenance processes
8.6
HR
HR
HR
HR
11. High confidence demonstrated by use

(optional where some previous evidence is
not available)
See Note
3
A.13
HR
HR
13. Interface Testing
H.2.17.2
HR
HR
HR
HR
HR
14. Fault Injection
H.2.31.4
HR
HR
14. Impact Analysis / Change Analysis
H.2.15
HR
HR
HR
HR
15. Operational Readiness Review
H.2.22
HR
HR
HR
HR
16. Time Petri Nets
H.2.32
17. Traceability
H.2.33
HR
HR
HR
HR
testing
under
environmental
12. Performance testing
Requirements/Notes:
Note 1: Technique described in H.2.21 is an example for generic Simulation Technique.
Note 2: Technique 5 shall consider the boundary values of the real operation conditions for SIL 1, and
shall consider levels higher than the boundary values of the real operation conditions for SILs
2, 3 & 4.
Note 3: For SILs 0, 1 & 2, Technique 11 is significant only with 10 000 hours operation time, at least 1
year experience with equipment in operation. For SILs 3 & 4, it is significant only with 1 million
hours operation time, at least 2 years experience with different equipment including safety
analysis, detailed documentation also of minor changes during operation time.
- 83 -
9386
prEN 50126-4
Table A.11 Application, Operation and Maintenance

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
1.
Production of applications operational

and maintenance instructions
11.3
HR
HR
2.
Training in the execution of

operational and maintenance
instructions
HR
HR
HR
HR
3.
Operator friendliness
HR
HR
HR
HR
HR
4.
Maintenance friendliness
HR
HR
HR
HR
HR
5.
Protection against operating errors
See
A. 6
HR
HR
6.
Protection against sabotage
See
A. 6
HR
HR
7.
Configuration management
H.2.3
HR
HR
HR
HR
9387
9388
Table A.12 Functional Testing

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
H.2.4
1.
Test Case Execution from Decision

Tables
2.
Error Guessing
H.2.8.2
HR
HR
3.
Process Simulation
H.2.24
4.
Model Based Testing
H.2.31.1
5.
Test Oracle
H.2.31.3
6.
Black-box testing
HR
HR
HR
HR
9389
9390
Table A.13 Performance Testing

TECHNIQUE/MEASURE
1.
Avalanche/Stress Testing
2.
Response Timing
3.
Performance Requirements
9391
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
H.2.31.2
HR
HR
H.2.27
HR
HR
HR
HR
H.2.23.2
HR
HR
HR
HR
prEN 50126-4
9392
- 84 -
Table A.14 Hardware Safety Analysis

TECHNIQUE/MEASURE
Ref
SIL 0
SIL 1
SIL 2
SIL 3
SIL 4
H.2.30.4
H.2.30.5
See Note 1
1.
FMEA/FMECA
2.
Bent Pin Analysis / Cable Failure Matrix

Analysis
H.2.14.1
HR
HR
3.
Electromagnetic Compatibility Analysis
H.2.14.2
HR
HR
4.
Energy Trace and Barrier Analysis
H.2.14.3
HR
HR
5.
Materials Compatibility Analysis
H.2.31.1
HR
HR
6.
Fault Tree Analysis
H.2.30.7
See Note 1
HR
HR
Requirements/Notes:
Note 1: Techniques 1 and 6 should be intended at components level.
9393
- 85 -
prEN 50126-4
Annex B
(normative)
Electronic/Electrical Component failure modes
9394
9395
9396
9397
B.1
Introduction
9398
9399
This annex contains procedures and information for identifying the credible failure modes of
electronic/electrical components.
9400
9401
NOTE: The tables of electronic/electrical component failure modes included in this annex have been derived from European
experience and also from the following sources listed in Bibliography:
9402
UIC/ORE Report A155/RP12;
9403
MIL-HDBK-338-1A;
9404
German Federal Railways M8004;
9405
Reliability Analysis Centre Report FMD-91.
9406
9407
The information in the tables may be modified, as explained in B.2 and B.5, if adequate justification is provided for such
variations.
9408
B.2
9409
9410
For the purpose of analysing the results of single failures, it is necessary to identify the credible failure
modes of each electronic/electrical component.
9411
9412
9413
Table B.1 to Table B.38 contain lists of electronic/electrical component failure modes which shall be
used as the basis for design and analysis, unless justification is provided for any variation. The
general Observations in B.5 shall be observed.
9414
9415
9416
9417
The lists are not necessarily complete, and any additional failure modes which are considered to be
credible shall be added to the analysis. In such cases, the extra failure modes shall be drawn to the
attention of the relevant authority, so that the lists can be extended at a future date, by means of the
normal CENELEC procedure.
9418
B.3
9419
9420
9421
9422
Designs which employ integrated circuits require special treatment, since it can be difficult to predict
all the credible failure modes that the device may possess. This is particularly true for programmable
devices, since the failure modes that may be observed at the boundary of the device are application
specific.
9423
9424
9425
9426
It is recommended that the hazardous failure modes be identified in a top-down manner for the
specific application, using a technique such as Fault Tree Analysis. (An alternative would be to use a
bottom-up approach such as Failure Modes and Effects Analysis, but this method is time-consuming
and it is possible that certain hazardous failure modes could be missed).
9427
9428
An assessment and justification shall then be made, to show that for each identified hazardous failure
mode either:
9429
9430
a) the failure mode cannot credibly occur, due to the internal architecture of the hardware, software
or data structure, or
9431
9432
9433
9434
b) the failure mode will be externally detected and a safe state imposed within the required time. In
this case, quantitative analysis shall be performed to justify the design, and a pessimistic view
shall be taken whereby the hazardous failure modes are assumed to take the full electronic
component failure rate.
9435
9436
NOTE: Some items, such as "intelligent" sensors, employ embedded microprocessors. Such items should be assessed using
the same methods as outlined above for integrated circuits.
General Procedure
Procedure for Integrated Circuits (including Microprocessors)
prEN 50126-4
- 86 -
9437
9438
B.4
Procedure for Electronic/Electrical Components with Inherent Physical

Properties
9439
9440
9441
If the technique of Inherent Fail-Safety is used, full justification shall be provided for any
electronic/electrical component failure mode which is considered to be incredible. This justification
shall include, but not necessarily be limited to, the following topics:
9442
theoretical explanation of inherent physical properties;
9443
evidence of compliance with recognised quality standards;
9444
explanation of special construction of electronic/electrical components;
9445
9446
explanation of special mounting

electronic/electrical component;
9447
9448
evidence that the failure mode will not occur as a result of electronic/electrical component
ratings being exceeded (for example, because of fault or overload conditions);
9449
9450
results of tests to demonstrate fail-safe behaviour of electronic/electrical component under

adverse conditions by means of physical tests or technical justifications);
9451
9452
9453
9454
9455
results of tests to demonstrate fail-safe behaviour of Electronic/Electrical component under

adverse conditions by means of simulation. The simulation could be done on a computer by
means of particular simulation software packages. The simulation results should be recorded
in a companion report or as an attachment to the main HW safety analysis report. It should
contain the following elements:
arrangements
or
other
precautions
for
the
9456
information for the simulation acceptance;
9457
results of the simulation;
9458
9459
electronic/electrical component models chosen for simulation and their

parameters;
9460
9461
environmental parameter variations (e.g., temperature, power supplies,

electromagnetic disturbances, etc.);
9462
worst case analysis;
9463
random analysis (Monte-Carlo);
9464
version of the simulation software;
9465
9466
complete references of the testing computer (type of operating system and

relevant software version numbers, configuration):
9467
skills of the operator(s).
9468
9469
evidence of previous experience of reliance on the electronic/electrical component for

inherent fail-safety.
9470
9471
If satisfactory justification is provided, the relevant electronic/electrical component failure modes may
be excluded from the safety analysis.
9472
9473
9474
9475
It is not necessary to repeat the justification if it has already been provided in the past; it is sufficient to
make reference to the previous justification report. However, if this justification includes particular
conditions (for example, special mounting arrangements or means for prevention of overload), the
fulfilment of these conditions shall be included in the Safety Case.
9476
9477
Previous experience indicates that some particular electronic/electrical component failure modes are
more likely to be capable of justification as incredible; these failure modes are indicated by (*) in Table
- 87 -
prEN 50126-4
9478
9479
9480
9481
B.1 to Table B.38, together with relevant guidance Observations in B.6 and B.7. Other
electronic/electrical component failure modes are much less likely to be capable of justification as
incredible. Note that justification shall be provided for all failure modes which are considered to be
incredible, including those which are indicated in the tables.
9482
9483
B.5
9484
1) Table B.1 to Table B.38 contain lists of credible failure modes of electronic/electrical components.
9485
9486
2) The failure modes are as manifested at the boundary of the electronic/electrical components, and
not the internal physical causes of the failures.
9487
3) All listed failure modes could be intermittent.
9488
9489
9490
4) Intermittent failures are caused by environmental influences such as temperature variation or

mechanical stress (see relevant environmental standards). Therefore the frequency of intermittent
failures will be in accordance with these reasons.
9491
9492
5) Variations within the tolerances of an electronic/electrical component's published specification are

not considered to be failures.
9493
9494
6) It is assumed that electronic/electrical components are operated within their published

environmental limits.
9495
9496
7) It is assumed that electronic/electrical components are operated within their published electrical
ratings.
9497
9498
9499
8) External short-circuit or leakage between terminals of a electronic/electrical component is not

considered to be a electronic/electrical component failure. For suitable creepage and clearance
distances refer to Observation 10).
9500
9501
9502
9503
9) External short-circuit or leakage between different electronic/electrical components is not

considered to be an electronic/electrical component failure. For suitable creepage and clearance
distances refer to Observation 10). Stable mounting and/or special fastening will be necessary if
environmental conditions could change the position of an electronic/electrical component.
9504
9505
9506
9507
9508
9509
10) Where safety is reliant on clearance and creepage distances, the minimum clearance and
creepage distances shall be defined according to the application requirements (including material,
technology, implementation, environmental and operating conditions, failure conditions and
temporary over-voltages). EN 50124-1 or IEC 60664 shall be used to determine minimum
requirements based on reinforced insulation. These requirements shall be accepted or further
strengthened or complemented by the Railway Authority.
General Observations concerning Electronic/Electrical Component Failure

Modes
9510
9511
9512
B.6
Additional General Observations, concerning Electronic/Electrical

Components with Inherent Physical Properties
9513
9514
1) The procedure and conditions for justification of any electronic/electrical component failure mode
as incredible are contained in B.4.
9515
9516
2) Failure modes indicated by (*) in Table B.1 to Table B.38 are those which are more likely to be
capable of being justified as incredible.
9517
9518
3) "Observation xy" following (*) in Table B.1 to Table B.38 refers to guidance Observations in B.7
on some factors that are relevant to possible justification of the failure mode as incredible.
9519
9520
4) The general Observations in B.5 apply also to electronic/electrical components with inherent
physical properties, with the following additions in Observations 5, 6 and 7 below.
9521
9522
5) In addition to Observation 5) in B.5, it is recommended that some allowance be made for

variations which exceed the normal tolerances.
prEN 50126-4
- 88 -
9523
9524
6) In addition to Observation 6) in B.5, it is recommended that some allowance be made for

excursions beyond the normal environmental limits.
9525
9526
7) In addition to Observation 7) in B.5, a margin shall be ensured within the published electrical
ratings, so that the electronic/electrical component is protected from being overloaded.
9527
9528
B.7
9529
9530
The following Observations provide guidance concerning possible justification of the failure modes
identified by (*) in Table B.1 to Table B.38 as incredible.
9531
8) The body shall have no hollows.
Specific Observations concerning Electronic/Electrical Components with

Inherent Physical Properties
9532
9533
9534
a) Clearance and creepage distances between the caps/connection wires at each end of the
electronic/electrical component shall at least fulfil the requirements of EN 50124-1, in
accordance with its requirements for reinforced insulation.
9535
b) The winding of a wire-wound resistor shall have only one layer.
9536
c) The electronic/electrical component shall be coated with cement or enamel.
9537
9538
d) Short-circuit between turns of a wire-wound resistor shall be avoided by coating of the wire,
and/or by physical separation of the turns.
9539
9540
e) The body shall be constructed of material which is non-conductive, even at the highest
temperature (including fault conditions).
9541
9542
f) The coating shall be non-conductive, even at the highest temperature (including fault
conditions).
9543
9544
g) The resistance shall be limited to the lowest possible value (for example, no greater than
10 k ).
9545
9546
9547
9548
9549
9550
9551
9552
9) The 4-terminal resistor shall be constructed in such a way that, if a fault causing interruption of the
resistance material occurs, this fault would also cause interruption of at least one of the four
connecting
terminals.
The circuitry external to the resistor shall disclose the interruption of the terminal(s) in a fail-safe
manner.
Example of a 4-terminal resistor, using a hybrid thick layer technique:
CONNECTION
RESISTANCE MATERIAL
A
POSSIBLE "CRACK"
(Fault)
R
CERAMIC
SUBSTRATE
B
9553
9554
9555
Figure B.1 Example of a 4-terminal Resistor using a hybrid thick layer technique
- 89 -
prEN 50126-4
9556
9557
10) Two terminals shall be connected independently to each side of the electronic/electrical
component.
9558
9559
11) The formula to calculate capacitance of a simple parallel-plate capacitor is
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
A
d
where
A = common area of plates,
d = distance between plates,
o = permittivity of free space,
r = relative permittivity (dielectric constant).
Justification of the failure mode as incredible requires demonstration that none of these
parameters can significantly change.
Electrolytic capacitors are not suitable for exclusion from this failure mode.
9573
9574
9575
9576
12) The capacitor shall be designed and constructed for high-voltage application in relation to the
maximum possible operating voltage (including fault conditions). It shall have Class-Y
specification, and self-healing properties at the working source impedance and over the working
voltage range.
9577
9578
9579
9580
13) There shall be only one layer of turns, separated by means of grooves in the insulated body, or
the wire shall have reinforced insulation.
9581
9582
9583
9584
9585
9586
9587
14) Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
EN 50124-1.
9588
9589
15) The magnetic core shall be constructed such that no significant change in reluctance of the
magnetic path can occur.
9590
9591
16) The transfer ratio depends upon the number of turns on each winding, and on the integrity of the
magnetic coupling. Therefore it is necessary for Observations 15), 16) and 17) to be fulfilled.
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
17) The transductance and the DC threshold voltage depend upon the properties of the magnetic
core material. Therefore it is necessary to demonstrate that these magnetic properties cannot
significantly change.
9603
9604
18) All parts of the relay or switch mechanism shall be robustly constructed and securely fastened,
including
9605
The turns shall be securely fastened.
All windings and connections shall be securely fastened.

Power dissipation shall be limited sufficiently to prevent internal carbonisation (including fault
conditions).
Transductance and DC threshold voltage also depend on the number of turns on each winding,
and on the integrity of the magnetic coupling. Therefore it is also necessary for Observations 15),
16) and 17) to be fulfilled.
The output from a transductor is related to the number of ampere-turns in the control winding. It is
necessary to demonstrate that, in conjunction with the associated drive circuitry, no credible
failure modes of the control winding can cause an increase in the number of ampere-turns.
the operating mechanism,
prEN 50126-4
- 90 -
9606
the contact system,
9607
the magnetic circuit (if any),
9608
the coil(s) (if any).
9609
9610
Clearance and creepage distances shall fulfil at least the requirements for re-inforced
insulation of EN 50124-1.
9611
9612
9613
9614
9615
9616
9617
19) Contact materials shall be chosen which are not capable of being welded.
9618
20) Stability of the relay's characteristics shall be ensured by careful attention to the following factors:
9619
The risk of welding shall be further reduced by appropriate mechanical design and construction of
the contacts.
The maximum current shall be limited, to ensure that the temperature of the contacts does not
reach a value at which welding could occur.
magnetic characteristics:
9620
choice of magnetic material;
9621
9622
provision of a stop device to avoid permanent magnetisation of the magnetic circuit

(core);
9623
protection against external magnetic fields;
9624
electrical characteristics:
9625
choice and quality of the wire and insulation;
9626
quality of winding of the coil;
9627
quality of terminations;
9628
mechanical characteristics:
9629
choice and quality of materials;
9630
secure fastening of all parts;
9631
secure retention of all safety-related adjustments;
9632
9633
provision of adequate return force, using gravity

(supplemented, if necessary, by springs and/or by elasticity of blades);
9634
design and construction of the operating mechanism such that it cannot become jammed.
9635
9636
21) The threshold voltage of a p-n junction, such as a diode or a transistor base-emitter junction, is a
function of
9637
minority and majority charge-carrier densities,
9638
boltzmann's constant (k),
9639
electron charge (e),
9640
temperature (K).
9641
9642
Therefore the threshold voltage is dependent on non-variable characteristics of the p-n

junction, and should be constant for a given temperature.
- 91 -
prEN 50126-4
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
22) The breakdown voltage is determined by one of two possible mechanisms: Zener breakdown or
avalanche breakdown. Both of these are dependent on non-variable physical characteristics of
the diode, so the breakdown voltage should be constant for a given temperature.
9654
9655
23) The amplification (or gain, or transconductance) of a transistor, and the optical sensitivity of a
photo-diode or transistor, are dependent on
Care shall be taken to avoid electronic components which consist internally of two or more diodes
connected in series.
Note that conduction at voltages above and below the breakdown voltage may be possible, due
to shunt or series resistance, but the differential (slope) resistance in such cases would be higher
than for the case of breakdown conduction.
9656
doping levels,
9657
thickness of the junction(s),
9658
life-time of charge carriers.
9659
9660
9661
These parameters should remain constant, with the exception of the charge carriers' life-time,
which can only decrease with time. Therefore the amplification/sensitivity should remain
constant, or possibly decrease, but not increase (has to be justified for each application).
9662
9663
9664
9665
A small possibility exists of an increase in amplification caused by pollution affecting surface

doping. This can be avoided by high-quality manufacture and packaging of the electronic
component. Also this effect is only significant for very low bias currents, which shall therefore
be avoided when designing circuits.
9666
9667
24) Light emission is a physical property related to recombination of electrons and holes when current
flows in a forward-biased p-n junction.
9668
9669
The rate of recombination is a function of the forward current, and therefore the light emission
should not increase at constant current.
9670
9671
Below the threshold voltage there is no significant current flow and therefore no light
emission.
9672
9673
9674
9675
9676
9677
25) If the p-n junction is reverse biased, there will be no significant current flow below the breakdown
voltage and therefore no light emission.
Above the breakdown voltage, the mechanism that allows current to flow is different to that for
forward bias and should not result in emission of light.
26) For optocouplers and self-contained fibre-optic systems, the failure modes of each element shall
be considered, i.e.
9678
light-emitting transmitter,
9679
optical medium,
9680
photo-sensitive receiver.
9681
9682
27) Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
EN 50124-1.
9683
The construction of the electronic/electrical components shall be robust and stable.
9684
9685
Power dissipation in the electronic/electrical component shall be limited sufficiently to prevent

internal carbonisation (including fault conditions).
prEN 50126-4
9686
9687
9688
9689
- 92 -
28) Clearance and creepage distances shall fulfil at least the requirements for re-inforced insulation of
EN 50124-1.
The input and output drive/coupling elements shall be securely fastened.
29) The electronic/electrical component shall be robustly constructed.
9690
9691
The resonator(s) shall be constructed and mounted so as to prevent change of their effective
dimensions.
9692
9693
The resonator(s) shall be constructed of a material whose dimensions are not significantly
altered by changes of temperature.
9694
9695
The material of the resonator(s) shall be stabilised by temperature cycling and/or preoperation for a sufficient time.
9696
9697
The material of the resonator(s) shall not be over-stressed, even under fault conditions. In
particular the limit of elasticity shall not be exceeded.
9698
9699
9700
9701
30) The transfer ratio is a function of the efficiency of the drive/coupling elements and the Q-factor of
the filter.
The drive/coupling elements shall be designed and constructed so as to prevent any significant
increase in their efficiency.
9702
9703
31) The resonator(s) shall be constructed and mounted to obtain the maximum possible Q-factor, so
that no subsequent improvement can occur.
9704
9705
32) The resonator(s) shall be constructed and mounted so as to prevent the occurrence of damping
by any mechanism.
9706
33) The insulating material shall be stable.
9707
9708
9709
9710
9711
9712
Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
EN 50124-1.
34) The connector shall be robustly constructed.
All parts of the connector shall be securely fastened.
35) Incorrect orientation of the connector, or insertion into the wrong socket, shall be prevented by
means of, for example, mechanical design or mechanical pin-coding.
9713
9714
Alternatively, the effects of incorrect insertion shall be rendered non-hazardous by means of, for
example, electrical coding of connector pins or allocation of unique addresses/identities.
9715
The risk shall be further reduced by means of warning labels and training of personnel.
9716
9717
9718
36) The screen shall be robustly constructed and protected from excessive physical damage.
The electrical connection to the screen shall be robust and securely fastened.
37) Sufficiently robust insulation shall be provided.
9719
9720
Clearance and creepage distances shall fulfil at least the requirements for re-inforced insulation of
EN 50124-1.
9721
Protection shall be provided against excessive physical damage.
9722
Protection shall be provided against electrically conductive foreign bodies.
9723
9724
The protection against excessive external physical damage cannot fully negate the potential for
short circuit considerations in trackside environment.
- 93 -
9725
9726
prEN 50126-4
38) The fuse and its holder shall be physically constructed and mounted so as to prevent the
occurrence of a parallel short-circuit.
9727
Means shall be provided to prevent the use of an incorrectly rated fuse.
9728
Means shall be provided to prevent the use of a fuse with self-resetting or self-healing capability.
9729
Interruption
Short-circuit
(*) Observation 08
Increase of resistance value

Decrease of resistance value
(*) Observation 08
Short-circuit to case
9730
Table B.1 Resistor and adjustable resistor (excluding 4-terminal resistor)
9731
Interruption of each terminal
Interruption of resistance material
(*) Observation 09
Short-circuit
(*) Observation 08
Increase of resistance value of each terminal

Decrease of resistance value
(*) Observation 08
Short-circuit between two terminals of same side
(*) Observation 10
9732
Table B.2 4 Terminal Resistors
9733
Interruption
Short-circuit
(*) Observation 12
Increase of capacitance
(*) Observation 11
Decrease of capacitance
(*) Observation 11
Decrease of parallel resistance
(*) Observation 12
Increase of series resistance

9734
9735
9736
9737
Table B.3 Capacitor and adjustable capacitor (excluding 4-terminal capacitor)
prEN 50126-4
- 94 -
Interruption of each terminal

Short-circuit
Increase of capacitance
(*) Observation 11
Decrease of capacitance
(*) Observation 11
Decrease of parallel resistance
(*) Observation 12
Increase of series resistance

Short-circuit between two terminals of same side
(*) Observation 10
9738
Table B.4 4-Terminal Capacitors
9739
Interruption of winding
Short-circuit of winding
-
between turns
(*) Observation 13
between layers
(*) Observation 14
- whole winding
Short-circuit or decrease of insulation between winding and body
(*) Observation 14
(*) Observation 14
Increase of resistance of winding
9740
Increase of inductance
(*) Observation 15
Decrease of inductance
(*) Observation 15
Table B.5 Electromagnetic Components-Inductor
9741
Interruption of any winding
Short-circuit of any winding
- between turns
(*) Observation 13
- between layers
(*) Observation 14
- whole winding
(*) Observation 14
Short-circuit or decrease of insulation between windings
(*) Observation 14
Short-circuit or decrease of insulation between any winding and body
(*) Observation 14
Increase of resistance of any winding
9742
9743
9744
9745
9746
Increase of inductance of any winding
(*) Observation 15
Decrease of inductance of any winding
(*) Observation 15
Change of transfer ratio
(*) Observation 16
Table B.6 Electromagnetic Components-Transformer
- 95 -
prEN 50126-4
Interruption of any winding

Short-circuit of d.c. winding
Short-circuit of a.c. winding
- between turns
(*) Observation 13
- between layers
(*) Observation 14
- whole winding
(*) Observation 14
Short-circuit or decrease of insulation resistance

- between d.c. and a.c. windings
(*) Observation 14
- between any winding and body
(*) Observation 14
Increase of inductance of a.c. winding
(*) Observation 15
Decrease of inductance of a.c. winding
(*) Observation 15
Increase of transductance
(*) Observation 17
Decrease of transductance
Increase of d.c. threshold voltage
Decrease of d.c. threshold voltage
9747
(*) Observation 17
Table B.7 Electromagnetic Components-Transductor (saturable reactor or magnetic amplifier)
9748
Interruption of any coil
Interruption of any contact
across open contacts
(*) Observation 18
between coil and coil
(*) Observation 14
between coil and contact
(*) Observation 18
between coil and case
(*) Observation 14
between contact and contact
(*) Observation 18
between contact and case
(*) Observation 18
Welding of contacts
(*) Observation 19
Increase of contact resistance

Contact chatter
Increase of pick-up current
Decrease of pick-up current
(*) Observation 20
Increase of drop-away current

Decrease of drop-away current
(*) Observation 20
Change of pick-up to drop-away ratio
(*) Observation 20
Increase of pick-up time

Decrease of pick-up time
(*) Observation 20
Increase of drop-away time
(*) Observation 20
Decrease of drop-away time
(*) Observation 20
Relay does not pick up

Relay does not drop away
(*) Observation 20
prEN 50126-4
- 96 -
Closure of any front contact at the same time as any back contact
(transient or continuous)
(*) Observation 20
Non-correspondence between front contacts

Non-correspondence between back contacts
9749
Table B.8 Electromagnetic Components-Relays
9750
Interruption
Short-circuit
Increase of reverse current
Decrease of reverse breakdown voltage
Increase of conducting-state voltage
Decrease of conducting-state voltage
Increase of threshold voltage
(*) Observation 21
Decrease of threshold voltage
(*) Observation 21
Short-circuit to conductive case

9751
Table B.9 Diodes- Normal diode (power, signal, switching)
9752
Interruption
Short-circuit
Increase of Zener voltage
(*) Observation 22
Decrease of Zener voltage
(*) Observation 22
Change of differential resistance

Increase of reverse current
Increase of forward conducting-state voltage
Decrease of forward conducting-state voltage
Increase of forward threshold voltage
(*) Observation 21
Decrease of forward threshold voltage
(*) Observation 21

9753
Table B.10 Diodes-Zener Diodes
9754
Interruption
- of emitter (E)
- and/or base (B)
- and/or collector (C)
Short circuit
- between E and B
- between B and C
- between E and C
- between E and B and C
- 97 -
prEN 50126-4
Short-circuit between two connections and interruption of the third

connection
Short-circuit between casing and E or B or C
Increase of d.c. and/or a.c. amplification
(*) Observation 23
Decrease of d.c. and/or a.c. amplification

Increase of base-emitter conducting-state voltage
Decrease of base-emitter conducting-state voltage
Increase of threshold voltage VBE
(*) Observation 21
Decrease of threshold voltage VBE
(*) Observation 21
Decrease of break-down voltage VEB or VCB or VCE

Change of rise time, fall time, turn-on time, turn-off time
Increase of leakage current ICB, IEB, ICE
Change of saturation voltage VCE
9755
Table B.11 Transistors-Bipolar

Interruption
- of gate (G)
- and/or source (S)
- and/or drain (D)
Short-circuit
- between S and D
- between G and D
- between S and G
- between S and G and D
connection
Short-circuit between casing and S or G or D
Increase of forward transconductance
Decrease of forward transconductance
Increase of gate threshold voltage
Decrease of gate threshold voltage
Decrease
- of drain-source break-down voltage
- of gate-source and drain-gate maximum rated voltages
Change of turn-on-time and turn-off time
Increase of leakage current IGS, IDS, IGD
Change of static drain to source on-state resistance
9756
9757
Table B.12 Transistors-Field Effect (FET)
(*) Observation 23
prEN 50126-4
- 98 -
9758
Interruption
- of gate (G)
- and/or anode (A)
- and/or cathode (C)
Short-circuit
- between G and C
- between G and A
- between A and C
- between A and G and C
connection
Short-circuit between casing and A or G or C
Change of holding current
Change of gate trigger current and/or of gate trigger voltage
Decrease
- of anode-cathode forward blocking voltage
- of anode-cathode reverse blocking voltage
- of reverse gate maximum rated voltage
Change of turn-on time and turn-off time
Increase of leakage current IAC, IGC, IGA
Change of forward static on-voltage
9759
Table B.13 Silicon - controlled rectifier (SCR) (thyristor)

Interruption
- of gate (G)
- and/or of MT1 (first current-carrying terminal)
- and/or of MT2 (second current-carrying terminal)
Short-circuit
- between G and MT1
- between G and MT2
- between MT1 and MT2
- between MT1 and G and MT2
connection
Short-circuit between casing and MT1 or G or MT2
Change of holding current
Change of gate trigger current and/or of gate trigger voltage
Decrease of MT1-MT2 maximum rated off-state voltage and/or of
gate maximum rated voltage
Increase of leakage current MT1-MT2, G-MT1, G-MT2
Change of static on-voltage
9760
9761
Table B.14 Bidirectional thyristor (triac)
- 99 -
prEN 50126-4
Interruption
Short-circuit
Increase of clamp voltage
Decrease of clamp voltage
Increase of leakage current
9762
Table B.15 Surge Suppressors - Voltage-dependent resistor (VDR) (varistor)
9763
Interruption
Short-circuit
Increase of breakdown voltage
(*) Observation 22
Decrease of breakdown voltage
(*) Observation 22

9764
Table B.16 Surge Suppressors-Protective Diode
9765
Interruption
Short-circuit
9766
Table B.17 Surge Suppressors-Gas Discharge Arrester
9767
Interruption
Short-circuit
9768
Table B.18 Surge Suppressors-Air Gap Arrester
9769
Interruption
Short-circuit
Increase of light sensitivity
Decrease of light sensitivity
9770
9771
Table B.19 Opto-electronic Components-Photo Diode
(*) Observation 23
prEN 50126-4
- 100 -
Interruption
Short-circuit
Increase of light sensitivity
(*) Observation 23
Decrease of light sensitivity

9772
Table B.20 Opto-electronic Components-Photo Transistor
9773
Interruption
Short-circuit
Increase of light emission (at constant current)
(*) Observation 24
Decrease of light emission (at constant current)

Increase of threshold voltage
(*) Observation 21
Decrease of threshold voltage
(*) Observation 21
Light emission below threshold voltage
(*) Observation 24
Light emission with reverse polarity
(*) Observation 25
9774
Table B.21 Opto-electronic Components- Light-emitting diode (LED)
9775
-
between input and output
(*) Observation 27
between adjacent systems in the same case
(*) Observation 27
Short-circuit to casing
Change of switching time
Increase of current transfer ratio
(*) Observations 23
and 24
Decrease of current transfer ratio

9776
Table B.22 - Opto-electronic Components- Optocoupler and self-contained fibre-optic system
9777
Interruption
Short-circuit
Change of resonant frequency
Decrease of Q-factor
9778
9779
9780
9781
Table B.23 Filters-Crystal
- 101 -
prEN 50126-4
Interruption
- between input and output
(*) Observation 28
- between input or output and case
(*) Observation 28
Change of resonant frequency
(*) Observation 29
Increase of transfer ratio
(*) Observations 30
and 31
Decrease of transfer ratio
9782
9783
Increase of Q-factor
(*) Observation 31
Decrease of Q-factor
(*) Observations 29
and 32
Table B.24 Filters-Mechanical Resonator (turning fork/reed/pendulum)
Interruption or increase of resistance in one or more lines

Short-circuit or decrease of insulation between two different lines
9784
(*) Observation 33
Table B.25 Interconnection Assemblies-Printed Circuit Board
9785
Interruption of
- one or more contacts
- shield
- between contact and contact
- between contact and shell
(*) Observations 33
and 34
(*) Observations 33
and 34
Wrong mechanical position

9786
(*) Observation 35
Table B.26 Interconnection Assemblies-Connector
9787
Interruption or increase of resistance in one or more wires
Interruption or increase of resistance of screen
(*) Observation 36

- between wire and wire, or more than one wire
(*) Observation 37
- between wire or wires and screen
(*) Observation 37
- between wire or wires or screen and external conductive parts
(*) Observation 37
Multiple interruptions and short-circuits

9788
(*) Observation 37
Table B.27 Interconnection Assemblies-Cable and Wire

Interruption
Increase of resistance
9789
9790
Table B.28 Interconnection Assemblies-Connection (soldered, welded, wrapped, crimped, clipped,

screwed)
prEN 50126-4
- 102 -
9791
Interruption
Increase of attenuation
9792
Table B.29 Interconnection Assemblies Fibreoptic Cable
9793
Interruption
Increase of attenuation
9794
Table B.30 Interconnection Assemblies-Fibreoptic Connector
9795
Interruption
Parallel short-circuit
(*) Observation 38
Increase of rupture current
(*) Observation 38
Increase of rupture time
(*) Observation 38
Reconnection after rupture
(*) Observation 38
9796
Table B.31 Fuses
9797
9798
Interruption of any contact
- across open contacts
(*) Observation 18
- between contact and contact
(*) Observation 18
- between contact and case
(*) Observation 18
Welding of contacts
(*) Observation 19
Increase of contact resistance

Device jammed in current state
Contact chatter
9799
Table B.32 Switches and Push/pull Buttons
9800
Interruption
Short-circuit
Decrease of light intensity
9801
9802
9803
Table B.33 Lamps
- 103 -
Interruption
Short-circuit
- of individual cell
- of multiple cells
- of whole battery
Decrease of e.m.f.
Increase of internal resistance
9804
Table B.34 Batteries

Interruption
Short-circuit
Output too high
Output too low
Time response too long
9805
Table B.35 Transducers/sensors
9806
(not including those with internal electronic circuitry)
9807
Functional malfunction:
9808
see B.3
Table B.36 Integrated Circuits-Analogue Devices
9809
9810
see B.3
Table B.37 Integrated Circuits-Digital Devices
9811
9812
see B.3
Table B.38 Integrated Circuits-Microprocessors
prEN 50126-4
prEN 50126-4
- 104 -
9813
9814
9815
Annex C
(normative)
Key Hardware/System Safety Roles and Responsibilities
9816
Table C.1 Hardware/System Requirements Manager Role Specification

Role: Hardware/System Requirements Manager
Responsibilities:
1. shall be responsible for the specification of the requirements
2.
shall develop and maintain the requirement specification
3.
shall administer the requirement specification
4. shall ensure consistency and completeness of the requirement specification (with

reference to user requirements and final environment of application)
5. shall ensure the specifications and requirements are under change and configuration
management including state, version and authorisation status
6. shall establish and maintain traceability among the requirements
Key competencies:
1. shall be competent in requirements engineering
2. shall understand the overall role of the system and the environment of application
3. shall understand analytical techniques and outcomes
4. shall understand applicable regulations
5. shall understand the requirements of EN 50126 (Parts 1, 2 and 4)
9817
- 105 -
9818
9819
Table C.2 Hardware/System Designer Role Specification

Role: Hardware/System Designer
Responsibilities:
1. shall transform specified requirements into acceptable solutions
2. shall control the architecture and downstream solutions
3. shall define and select the design methods and supporting tools
4. shall apply safety design principles and standards
5. shall develop component specifications where appropriate
6. shall maintain traceability to and from the specified requirements
NOTE:
-for system design the traceability to the system requirements see 8.1
- for hardware design the traceability to the hardware requirements from clause 9.1
7. shall develop and maintain the design documentation

NOTE:
- for the system aspects the output documents from clause 8.2
- for the hardware the output documents from clause 9.2 and 9.3
8. shall ensure design documents are under change and configuration control
9. shall ensure the completeness and consistence of the design documentation
Key competencies:
1. shall be competent in engineering appropriate to the application area
2. shall be competent in safety design principles
3. shall be competent in design analysis & design test methodologies
4. shall be able to work within design constraints in a given environment
5. shall be competent in understanding the problem domain
6. shall understand all the constraints imposed by the hardware platform and/or
software, the operating system and the interfacing systems
7. shall understand the relevant parts of EN 50126
9820
prEN 50126-4
prEN 50126-4
- 106 -
9821
9822
Table C.3 Hardware/System Implementer Role Specification

Role: Hardware/System Implementer
Responsibilities:
1. shall transform the design solutions into hardware manufacturing data
2. shall apply safety design principles
3. shall carry out analysis to verify the intermediate outcomes
4. shall develop and maintain the hardware manufacturing data comprising the applied
methods, and listings
5. shall maintain traceability to and from design
6. shall maintain the generated or modified hardware manufacturing data under change
and configuration control
7. shall ensure the completeness and consistence of the documentation
Key competencies:
1. shall be competent in engineering appropriate to the application area
2. shall be competent in the implementation of hardware
3. shall understand all the constraints imposed by the hardware implementation
9823
- 107 -
9824
Table C. 4 Hardware/System Tester Role Specification

Role: Hardware/System Tester
Responsibilities:
1. shall ensure that test activities are planned
2. shall develop the test specification (objectives & cases), the test specification might
be related to
-
tests inside one life cycle phase
implementation activities
integration activities
verification activities
validation activities
3. shall execute tests according the test specification and planning

4. shall ensure traceability of test objectives against the specified hardware
requirements and/or software requirements and/or system requirements
5. shall ensure traceability of test cases against the specified test objectives
6. shall ensure the planned tests are implemented and specified tests carried out
7. shall identify deviations from expected results and record them in test reports
8. shall communicate deviations with relevant change management body for evaluation
and decision
9. shall capture outcomes in reports
Key competencies:
1. shall be competent in the domain where testing is carried out e.g. system
requirements, hardware requirements etc.
2. shall be competent in various test and verification approaches/methodologies and be
able to identify the most suitable method in a given context
3. shall be capable of deriving test cases from given specifications
4. shall have analytical thinking ability and good observation skills
9825
prEN 50126-4
prEN 50126-4
- 108 -
9826
9827
Table C. 5 Hardware/System Verifier Role Specification

Role: Hardware/System Verifier
Responsibilities:
1. shall develop a verification plan (which may include quality issues) stating what needs
verification and what type of process (e.g. review, analysis etc.) and test is required
as evidence
2. shall check the adequacy (completeness, consistency, correctness, relevance and
traceability) of the documented evidence from review, integration and testing with the
specified verification objectives
3. shall identify anomalies, classify these in risk (impact) terms, record and
communicate these to relevant change management body for evaluation and decision
4. shall manage the verification process (review, integration and testing) and ensure
independence of activities as required
5. shall develop and maintain records on the verification activities
6. shall develop a verification report stating the outcome of the verification activities
Key competencies:
1. shall be competent in the domain where verification is carried out
2. shall be competent in various verification approaches/methodologies and be able to
identify the most suitable method or combination of methods in a given context
3. shall be capable of deriving the types of verification from given specifications
9828
- 109 -
prEN 50126-4
9829
9830
Table C. 6 Hardware/System Integrator Role Specification

Role: Hardware/System Integrator
Responsibilities:
1. shall manage the integration process using the system baselines and Interface
Requirement Specification
2. shall develop the Integration Test Specification based on the architecture and design
stating what the necessary input, the sequence of integration activities and the result
are
NOTE:
- For integration test specifications see clause 8.2
- For hardware integration test specification see clause 9.2
3. shall develop and maintain records on the integration activities

4. shall integrate
-
software on the sub-system or system
sub-system on the system
system on the railway system
5. shall identify integration anomalies, record and communicate these to relevant change
management body for evaluation and decision
6. shall develop a integration report stating the outcome of
NOTE:
-for
system
integration
- for hardware integration report see clause 9.5
reports
see
the integration
clause
8.5
Key competencies:
1. shall be competent in the domain where integration is carried out
2. shall be competent in various integration approaches/methodologies and be able to
3. shall be competent in understanding the design and functionality required at various
intermediate levels
4. shall be capable of deriving the types of integration test from a set of integrated
functions
5. shall have analytical thinking ability and good observation skills tending towards the
system level perspective
9831
prEN 50126-4
9832
- 110 -
Table C. 7 Hardware/System Validator Role Specification

Role: Hardware/System Validator
Responsibilities:
1. shall develop understanding of the system within the intended environment of
application
2. shall develop a validation plan and specify the essential tasks and activities for the
validation and agree this plan with the assessor
3. shall review the system requirements against the intended environment/use
NOTE:
- for system aspects the requirements are specified in the system requirement specification see clause
8.1.4.1
- for the hardware the requirements are specified in the hardware requirement specification see clause
9.1.4.1
4. shall review the outcome against the system requirements to ensure all of these are
fulfilled
5. shall evaluate the conformity of the process and the outcome against the requirements
of this European Standard including the assigned SIL
6. shall review the correctness, consistency and adequacy of the verification and testing
7. shall check the correctness, consistency and adequacy of test cases and executed
tests.
8. shall ensure all activities planned in the system validation plan are carried out
9. shall review and classify all deviations in terms of risk (impact), records and submits to
the body responsible for Change Management and decision making
10. shall give a recommendation on the suitability of the outcome for intended use and
indicate any application constraints as appropriate
11. shall capture deviations from the system validation plan
12. shall carry out audits, inspections or reviews on the overall project (as instantiations of
the generic development process) as appropriate in various phases of development
13. shall review and analyse the validation reports relating to previous applications as
appropriate
14. shall review developed solutions are traceable to the requirements
15. shall ensure the related hazard logs and remaining non-conformities are reviewed and
all hazards closed out in an appropriate manner through elimination or risks
control/transfer measures
16. shall develop a validation report
17. shall give agreement/disagreement for the release of the outcome
Key competencies:
1. shall be competent in the domain where validation is carried out
2. shall be competent in various validation approaches/methodologies and be able to
3. shall be capable of deriving the types of validation evidence required from given
specifications bearing in mind the intended application
4. shall be capable of combining different sources and types of evidence and synthesise
an overall view about fitness for purpose or constraints and limitations of the
application
6. shall understand the requirements of EN 50126
- 111 -
prEN 50126-4
9833
9834
Table C. 8 Hardware/System Assessor Role Specification

Role: Hardware/System Assessor
Responsibilities:
1. When tasked with independent assessment, the assessor shall not become involved
either directly or as authorised representative in the design, manufacture, construction,
marketing, operation or maintenance of the system under independent assessment.
(This does not exclude the possibility of exchange of technical information)
2. shall develop understanding of the system within the intended environment of
application
3. shall develop an assessment plan and communicate this with the safety authority
and/or the client organisation (contracting body of the assessor)
4. shall evaluate the conformity of the process and the developed outcomes against the
requirements of this European Standard including the assigned SIL
5. shall evaluate the competency of project staff and organisation for the development
6. shall evaluate the verification and validation activities and the supporting evidence
7. shall evaluate the quality management systems adopted for the development
8. shall evaluate the configuration and change management system and the evidence of
its use and application
9. shall identify and evaluate in terms of risk (impact) any deviations from the
requirements in the assessment report
10. shall ensure that the assessment plan is implemented.
11. shall evaluate that safety audits have been carried out and documented in an
appropriate way.
12. shall carry out inspections on the overall development process as appropriate at
various phases of development
13. shall give a professional view on the fitness of the developed outcome for its intended
use detailing any constraints, application conditions and observations for risk control
as appropriate
14. shall develop an assessment report and maintain records on the independent
assessment process
Key competencies:
1. shall be competent in the domain/technologies where independent assessment is
carried out
2. shall have acceptance/licence from a recognised safety authority
3. shall have / strive to continually gain sufficient levels of experience in the safety
principles and the application of the principles within the application domain
4. shall be competent to check that a suitable method or combination of methods in a
given context have been applied
5. shall be competent in understanding the relevant safety, human resource, technical
and quality management processes in fulfilling the requirements of the EN 50126
6. shall be competent in independent assessment approaches/methodologies
8. shall be capable of combining different sources and types of evidence and synthesise
an overall view about fitness for purpose or constraints and limitations on application
9. shall have overall system understanding and perspective including understanding the
application environment
10. shall understand the requirements of EN 50126
prEN 50126-4
- 112 -
9835
9836
Table C. 9 Hardware/System Project Manager Role Specification

Role: Hardware/System Project Manager
Responsibilities:
1. shall ensure that the quality management system and independency of roles according
to Clause 6.2 are in place for the project and progress is checked against the plans
2. shall allocate sufficient number of competent resources in the project to carry out the
essential tasks including safety activities, bearing in mind the requisite independence
of roles
3. shall ensure that a suitable validator has been appointed for the project as defined in
the EN 50126
4. shall be responsible for the delivery and deployment of the system and hardware and
ensure that safety requirements from the stakeholders are also fulfilled and delivered
5. shall allow sufficient time for the proper implementation and fulfilment of safety tasks
6. shall endorse partial and complete safety deliverables from the development process
7. shall ensure sufficient records and traceability is maintained in safety related decision
making
Key competencies:
1. shall understand quality, competencies, organisational and management requirements
of EN 50126 and EN ISO 9001
2. shall understand the requirements of the safety process
3. shall be able to weigh different options and understand the impact on safety
performance of a decision or selected options
4. shall understand the requirements of the development process
5. shall understand the requirements of other relevant standards
9837
- 113 -
prEN 50126-4
9838
9839
Table C. 10 Hardware/System Configuration Manager Role Specification

Role: Hardware/System Configuration Manager
Responsibilities:
1. shall be responsible for the configuration management plan
2. shall control the configuration management system for
-
the hardware configuration and/or
the generic software configuration and/or
the specific software configuration, e.g. parameters, values, data base
3. shall ensure all configuration items are identified and entered in the configuration
management system
4. shall establish that all outcomes are clearly identified and independently versioned
inside the configuration management system
Key competencies:
1. shall be competent in configuration management
2. shall understand the requirements of EN 50126 and EN ISO 9001
9840
prEN 50126-4
- 114 -
9841
9842
Table C. 11 Hardware/System Maintenance Manager Role Specification

Role: Hardware/System Maintenance Manager
Responsibilities:
1.
shall ensure that all relevant electronic system information, maintenance

documentation, pass/fail criteria and configuration data is documented uniquely and
available for all involved in the maintenance process according to the Operations and
Maintenance Plan (see TSI chapter 4)
2.
shall ensure that the relevant documentation is updated to reflect changes in the
configuration status of the electronic system under maintenance
3.
shall define the required level of training and education of all personnel involved in
maintenance
4.
shall keep track of the level of training and education of personnel involved in
maintenance
5.
shall allocate sufficient resources (including finance, tools and numbers of competent
personnel) for performing the maintenance
6.
shall ensure that all relevant maintenance is planned and will be performed as given
in the maintenance documentation
7.
shall report unexpected failures or other abnormal behaviour of the system to the
Safety Manager in accordance with safety management organisation according the
Operations and Maintenance Safety Plan
8.
shall ensure sufficient recording of the maintenance activities in a traceable manner

with regard to safety related decision
Key competencies:
1. shall be a competent practitioner of the maintenance of electronic systems
2. shall have knowledge of the design, functions and application of the electronic
systems under maintenance
3. shall be competent in maintenance processes, including record keeping and
configuration management
5. shall be capable of analysing failure and performance statistics pertinent to the
electronic system being maintained
6. shall understand and be familiar with the relevant parts of EN 50126
9843
- 115 -
9844
9845
Table C. 12 Hardware/System Operations Manager Role Specification

Role: Hardware/System Operations Manager
Responsibilities:
1. shall ensure that all operational constraints and conditions (derived from SRACs) for
the relevant electronic system are documented uniquely and available for all involved
in the operation process in accordance with the Operations and Maintenance Plan
2. shall ensure that all relevant operations documentation is updated to reflect changes
in the configuration status of the electronic system
3. shall define the required level of training and education of all personnel involved in
operation of the electronic system
4. shall keep track of the level of training and education of personnel involved in
operation;
5. shall allocate sufficient resources (including finance, tools and numbers of competent
personnel) for operating the electronic system
6. shall ensure that the electronic system is operated in accordance with the operations
documentation
7. shall report any anomalies of the system to the Safety Manager in accordance with the
Operations and Maintenance Plan and ensure that they are sufficiently recorded
Key competencies:
1. shall have competence in operational practices, rules and standards
2. shall have knowledge of the functions and application of the electronic system
3. shall be capable of analysing operational anomalies and where necessary initiating
incident investigation
prEN 50126-4
prEN 50126-4
- 116 -
9846
Role: Hardware/System Safety manager
Responsibilities:
1. shall ensure implementation (and regular update) of the System Safety Plan, Hazard
Log, Hazard Analysis and System Safety Case throughout the life cycle
2. shall ensure that the relevant documentation is updated with respect to the safety
relevance for changes in the configuration or mode of operation of the system
3. shall ensure that the safety team communicates and interfaces appropriately in the
interest of identifying and mitigating potential safety risks
4. shall ensure that maintainer and operator have the suitable and sufficient information
on safety relevant application conditions.
5. shall ensure that potential safety risk, associated with the operation of the system and
any proposed changes to the system and its deployment, is reduced to acceptable
level
6. shall ensure that safety audits and assessments are planned and carried out
7. shall ensure sufficient records and traceability is maintained in safety related decision
making.
Key competencies:
1.
shall be competent in engineering appropriate to the application area
2.
shall have knowledge of the design, functions and application of the system that is
in operation
4.
in an appropriate way be experienced in:

a. Production of System Safety Case
b. Construction of safety arguments and identification of required safety evidence
(Identification of the necessary documentation and arguments in support of safety
cases development)
c. Delivery of assurance for complex systems
d. independent safety risk assessment ;
e. Analysis of complex systems
f. Implementation and application of safety management processes and standards
g. Implementation and application of systems engineering processes
9847
9848
9849
5.
Assurance of Electronic Systems
6.
Hazard identification
7.
Hazard log management
8.
Quantified Risk Assessment
9.
Use and application of data and configuration management processes and tools .
Table C. 13 Hardware/System Safety Manager Role Specification
- 117 -
prEN 50126-4
Annex D
(informative)
Technical Recommendations for SIL3 and SIL4 functions
9850
9851
9852
9853
D.1
Introduction
9854
9855
9856
This annex provides examples and guidance to supplement the technical requirements contained
in Part 2 12.2.4 (Physical Independence) and 7.x (Additional requirements for E/E/PE Architecture).
The given recommendations are only valid for SIL 3 or SIL 4 functions.
9857
D.2
9858
As referred to in Part 2 12.2.4
9859
Primary independence
9860
9861
The following measures provide "primary independence" between two items whose simultaneous
malfunction could be hazardous:
9862
9863
1) measures to avoid non-intentional galvanic connections

(protection of internal galvanic insulation)
Achievement of Physical Internal Independence
9864
9865
9866
9867
a) Insulation between lines on the same layer of a printed-circuit board.
9868
b) Insulation between lines on different layers of a multilayer printed-circuit board.
9869
c) Insulation between insulated wires in the same cable.
9870
9871
9872
9873
d) Insulation between insulated windings in the same transformer.
9874
9875
9876
9877
e) Insulation between insulated items inside an opto-coupler.
9878
9879
9880
9881
9882
9883
9884
Insulation distances (creepage distances and clearances) should be dimensioned at least

according to the requirements for reinforced insulation of EN 50124-1.
Maximum temperature inside transformers should be limited (including fault conditions), to avoid
carbonisation.
Maximum temperature inside opto-couplers should be limited (including fault conditions), to

avoid carbonisation.
2) measures to avoid non-intentional effects via intentional connections
(protection of internal interfaces)
a) Interfaces should be protected by means of devices with inherent properties.
3) measures to avoid non-intentional effects via electromagnetic coupling
(protection against internal cross-talk)
Cross-talk between electronic networks should be prevented as follows:
9885
9886
9887
a) if different items are on the same printed-circuit board, they should be supplied by different
power-supply networks. If not, then the impedance of the ground network should be sufficiently
low to avoid cross-talk, even in the event of failures;
9888
9889
9890
9891
b) if different lines on the same board need to be protected against cross-talk occurring between
them, the necessary separation distance depends on the used technology, the coupling length
and the coupling mechanism. This distance should be demonstrated for the normal operational
mode by theoretical calculations and/or by practical measurements;
prEN 50126-4
9892
9893
9894
- 118 -
c) if necessary to avoid coupling in the event of failures, additional measures (for example,
shielding or doubling of distance) should be taken. Effectiveness should be demonstrated by
theoretical calculations and/or by practical measurements.
9895
Secondary independence
9896
9897
The following measures provide "secondary independence" between two items whose simultaneous
malfunction could not be hazardous:
9898
1) each item in a n-out-of-m system may consist of a number of independent items;
9899
9900
9901
2) independence of two items whose simultaneous malfunction could be hazardous is achieved as

written in Primary independence. These items will be referred to as "main items". Each main item
can have one or more so called "additional items" checking the main item;
9902
9903
3) the degree of independence between a main item and an additional item may be less than written
in Primary independence and is called "secondary independence";
9904
9905
4) main items are independent from additional items if all possible first-fault-effected influences
between them are detected before they can become hazardous through further failures;
9906
5) the following simplifications to Primary independence are allowed for secondary independence:
9907
9908
a) insulation distances (creepage distances and clearances) should be dimensioned at least

according to the requirements for basic insulation of EN 50124-1;
9909
9910
b) protecting devices do not require inherent properties. (Only a second fault may be able to inhibit
the independence between a main item and an additional item);
9911
9912
9913
c) at least the power-supply network for the voltage-monitoring (additional item) should be
separated from the power-supply network for the monitored main item as written in this
paragraph.
9914
D.3
Achievement of Physical External Independence
9915
The following measures provide physical external independence:
9916
9917
1) measures should be taken to avoid non-intentional effects by EMI/ESD disturbing correct

operation, in accordance with EN 50121-4;
9918
9919
2) the specified climatic conditions should normally be complied with. Measures should be taken to
minimise the risk of the system being operated outside its specified climatic conditions;
9920
3) measures to avoid non-intentional effects by mechanical stresses disturbing the correct operation:
9921
9922
a) measures should be taken to ensure reliable correct operation in spite of mechanical stressconditions agreed between the railway authority and supplier;
9923
b) protection should be compliant with EN 50125-1 and/or EN 50125-3 as appropriate;
9924
9925
4) measures should be taken to ensure reliable correct operation in spite of chemical stressconditions agreed between the railway authority and supplier;
9926
9927
5) measures should be taken to avoid non-intentional operation under non-permitted power-supply

voltages (protection of supply-voltages):
9928
9929
9930
a) non-permitted supply voltages (outside data-sheet values for supplied systems/

equipment/components) should be disclosed by voltage-monitoring triggering a safe state
before hazardous situations are possible;
9931
9932
b) voltage-monitoring should operate correctly for the whole life cycle. Voltage-monitoring
redundancy may be necessary if disclosure of voltage-monitoring failures is not possible.
- 119 -
prEN 50126-4
9933
9934
6) measures should be taken to avoid non-intentional hazardous effects caused by external voltages
across input and output ports disturbing the correct operation (protection of external interfaces):
9935
9936
a) worst-case external voltages should be assumed (process-voltages and all possible EMIinduced voltages on cables and lines);
9937
9938
9939
b) clearances between live parts and exposed conductive parts/earth/circuits whose correct
operation needs to be protected should be dimensioned according to surge voltages specified
in EN 50124-1;
9940
9941
9942
c) creepage distances between live parts and exposed conductive parts/earth/circuits whose
correct operation needs to be protected should be dimensioned according to EN 50124-1 and
according to maximum rated R.M.S. voltages during operation;
9943
d) for dimensioning insulation, the larger distance (clearance or creepage distance) is decisive.
9944
D.4
9945
Single-fault Detection
(As referred to in 8.2 of this standard)
9946
9947
The following measures provide conditions for single-fault detection in composite (2-out-of-n), reactive
and inherent fail-safety.
9948
9949
1)
Periodic tests for faults in all items should be implemented. The tests should be representative
for all credible faults affecting the safe operation, and should be finished within a time < tsf.
9950
Detection of faults in integrated circuits should be compliant with Table D.1.
9951
9952
NOTE: Evidence should be given that faults not covered by periodic tests are not hazardous (i.e. these faults are
demonstrated to be safe, alone or combined with others).
9953
9954
2)
For two items whose simultaneous malfunctioning could be hazardous, having same or
comparable failure rates "a", the detection time tsf of single faults should not exceed the value:
tsf
9955
9956
9957
TFFR
a2
NOTE: For reliable items the resulting time can be comparable with the lifetime of E/E/PE system. In these cases the
tests frequency (1/tsf) should be set at least to a value significantly greater than a (e.g. 1000-fold value).
9958
9959
9960
9961
3)
The failure rates mentioned in paragraph 2) above are to be determined as a function of the
stress profile dependent on the environmental conditions during operation. The stress profile
depends on the application. A simplified stress profile may be taken as a basis if this leads to a
conservative result (higher failure rate).
9962
9963
9964
9965
4)
If within a E/E/PE system comprising several items not all combinations of two failed items would
be hazardous, the fault detection time may be determined separately for the various
combinations. If, in this case, different fault detection times result for one item, the shortest time
is decisive.
9966
9967
9968
5)
If a fault-free E/E/PE system is disconnected from the power supply, the fault detection may be
interrupted. All the periodic tests implemented should be then executed at start-up (alternatively
the system has to be thoroughly tested off-line in a controlled manner before restoring operation).
9969
9970
9971
9972
6)
When the safety-related function is performed by a single item the detection time of a wrong side
failure tsf is the maximum total time to detect and react in a safe way to all single faults affecting
the safe operation. This time shall not exceed the specified limit for the duration of any
hazardous condition.
9973
9974
For example the tsf could assume the following value, in order to avoid any hazardous condition:
tsf < 100 ms, if the controlled equipment is a signalling relay with higher rise time.
prEN 50126-4
9975
9976
7)
9977
D.5
9978
- 120 -
During the time tsf the first safety related failure must be detected and it must trigger a safety
reaction.
Multiple-fault Detection
(As referred to in 8.2)
9979
9980
The following measures provide conditions for multiple-fault detection in composite fail-safety (E/E/PE
systems with more than three independent items, i.e. 3-out-of-n and higher tolerances).
9981
9982
1)
If the timely detection-plus-negation of a fault in one item is impossible or unsuitable, the chance
occurrence of a further fault in other items should be taken into account.
9983
9984
2)
It is necessary that simultaneous faults in two items are non-hazardous. This means that at least
three independent items are necessary.
9985
9986
3)
Periodic tests for faults should be implemented. The tests should be representative for all
credible faults affecting the safe operation, and should be finished within a time < tsf.
9987
Detection of faults in integrated circuits should be compliant with Table D.1.
9988
9989
NOTE: Periodic tests could be limited to the dangerous faults identified within the "DC fault model", i.e.: stuck-at faults,
stuck-open, open or high impedance outputs and short circuits between signal lines.
9990
9991
9992
4)
For multiple items (> 3) whose simultaneous malfunctioning could be hazardous, having same or
comparable failure rates "a", the periodic tests frequency (1/tsf) should be set to a value
significantly greater than a (e.g. 1000-fold value).
9993
9994
9995
9996
5)
If within a system, sub-system or equipment comprising several items not all combinations of
three failed items would be hazardous, the fault detection time may be determined separately for
the various combinations. If, in this case, different fault detection times result for two items, the
shortest time is decisive.
9997
- 121 -
9998
9999
10000
Figure D.1 Single-fault and Multiple-fault detection conditions
prEN 50126-4
prEN 50126-4
10001
10002
- 122 -
Table D.1 - Measures to detect faults in integrated circuits

by means of periodic on-line testing
COMPONENT
FAILURE MODES
MEASURES
DC fault model for data

and addresses
One of the following diagnostic measures should be

implemented:
CPU
Register, Internal
RAM
Dynamic cross-over for

memory cells
- Comparator (HW)
- Majority Voter (HW)
Change of information
caused by soft-errors
No, wrong or multiple
addressing
Instruction
decoding and
execution
No definite failure
assumption
Program
counter, stack
pointer
DC fault model
Clock
Incorrect frequency
Change of addresses
Period jitter
Reset
DC fault model
Drift and oscillation
Individual components
do not initialize to reset
state
- Coded processing (single item)

- Reciprocal comparison by software
Other measures can be defined, provided evidence of
detection of listed failures modes is demonstrated.
- 123 -
10003
10004
10005
prEN 50126-4
Table D.1 - Measures to detect faults in integrated circuits

by means of periodic on-line testing
(continued)
COMPONENT
FAILURE MODES
MEASURES
All faults that affect data

in the memory

implemented:
Memory
Invariable
- Signature of a double word (16-bit)

- Block replication
Variable
DC fault model for data

and addresses
Dynamic cross-over for
memory cells
Change of information
No, wrong or multiple
addressing
Power supply
(for integrated
circuits)
DC fault model drift and

oscillation

implemented:
- RAM test Galpat (or transparent Galpat)
- RAM test Abraham
- Double RAM with HW/SW comparison and
read/write test
Other measures can be defined, provided evidence of
detection of listed failures modes is demonstrated.
If independent power supplies are used for each
computing channel, then a wrong supply voltage in one
channel can be detected by comparison.
In cases of no independence, or multiple faults,
additional voltage monitoring may be necessary.
10006
prEN 50126-4
- 124 -
Annex E
(informative)
10007
10008
10009
10010
Guidance on Programmable Devices
10011
E.1
10012
10013
This annex gives guidance on the use of Programmable Device (PD) in any area application where
there are safety implications.
10014
In addition, this annex includes guidance on the way to insert PDs within a safety architecture.
10015
Programmable devices are commonly defined by the following acronyms:
10016
10017
10018
10019
10020
10021
10022
Introduction
FPGA (field-programmable gate array),

PLD (programmable logic device),
EPLD (erasable programmable logic device)
CPLD (complex programmable logic device),
PAL (programmable array logic),
PLA (programmable logic array),
LCA (Logic Cell Array).
10023
10024
A Programmable device is composed of at least 2 items:
10025
10026
1) Hardware: It is an integrated circuit which is included within the hardware development process in
compliance with EN 50126-4 chapter 9.
10027
10028
2) Logic: This is the programming of the programmable device hardware. This is the main purpose
of this annex.
10029
10030
10031
Where the programmable device is able to run application software, this application software should
be developed following the requirements of EN 50126-5. This also applies for the use of pre-existing
programmable device, including soft-cores.
10032
10033
10034
In the case where the functions of the programmable device should be developed in using a language
provided by the programmable device the development of these functions should be according to EN
50126-5.
10035
10036
In this annex the non-applicable requirements in developing the functions for a programmable device
from EN 50126-5 are identified and additional requirements are defined.
10037
10038
In using PDs the safety can only be assured together with processes. Designing these processes
should be the focus.
- 125 -
prEN 50126-4
10039
10040
E.2
Relation to EN 50126-5
10041
E.2.1
non applicable requirements
10042
10043
The following paragraphs from EN 50126-5 are not applicable during the development of functions for
a programmable device.
10044
EN 50126-5
non applicable requirements
7.1 - 7.9
none
8.1
none
8.2
8.2.4.1.11
8.2.4.3.2 d) and f)
8.3
8.3.4.1.6
8.3.4.1.7
8.3.4.1.12
8.3.4.5
8.3.4.5.1
8.3.4.6.3
8.3.4.10
8.3.4.11.2
8.4
none
8.5
none
8.6
8.6.4.2.3
8.7
8.7.4.3.3
10045
10046
E.2.2
additional requirements
10047
10048
E.2.2.1 The following table defines the requirements which are additional to the
requirements in EN 50126-5 for the development of functions for a programmable device.
10049
EN 50126-5
7.1 - 7.9
none
prEN 50126-4
- 126 -
EN 50126-5
8.1
none
8.2
Any constraints between the software and the functions of the

Programmable device should be documented or referenced (e.g. system or
software level documentation) in the PD Logic Requirements Specification.
8.3
see:
-
E.2.2.2
E.2.2.3
E.2.2.4
E.2.2.5
8.4
none
8.5
8.6
8.7
E.2.3
10050
10051
10052
10053
10054
E.2.2.2 All Interfaces between the PD Components and the boundary of the overall PD logic
should be documented or referenced (e.g. Hardware level documentation) in the architecture
of the logic for the PD. The description of these interfaces should address:
a) functional aspects: clocks, resets and protocols;
10055
b) implementation aspects: interfaces timings and synchronization.
10056
10057
10058
10059
E.2.2.3 In accordance with the required safety integrity level for the logic of the PD the
design method chosen should possess features that facilitate
a) synthesizability,
10060
b)
abstraction, modularity and other features which control complexity,
10061
c)
the clear and precise expression of
10062
1)
functionality,
10063
2)
information flow between PD Logic components,
10064
3)
sequencing,
10065
4)
data structure and properties,
10066
d)
human comprehension,
10067
e)
verification and validation,
10068
f)
maintenance and portability.
10069
- 127 -
10070
10071
10072
10073
prEN 50126-4
E.2.2.4 If not complex PDs are under development, according to criteria defined during the
validation planning, evidence for this criteria should be provided in the architecture and
design of the PD logic. For these PDs, simplified life cycle and techniques against
systematic faults (see E.2.4) can be adopted.
10074
10075
10076
10077
10078
E.2.2.5 The specified tests (requirements and integration) for the PD logic should address
the following:
a) it should be shown that each PD component provides the specified interfaces for the other
components by executing the components together;
10079
10080
b) it should be shown that the PD logic behaves in an appropriate manner when the external
interface is subjected to inputs which are out of nominal range;
10081
c) the required timing and performance should be demonstrated;
10082
d) the required inputs as well as anticipated outputs should be the base of the test cases;
10083
10084
E.2.3
PD Physical Implementation
10085
E.2.3.1 Objectives
10086
10087
E.2.3.1.1 To produce a PD programming file which implements the architecture and design
for the PD.
10088
E.2.3.1.2
10089
E.2.3.2 Input documents
10090
1)
PD Architecture and Design Specification
10091
2)
(V)HDL Code or equivalent
10092
E.2.3.3 Output documents
10093
1)
Net-list and programming files
10094
2)
PD Synthesis Place and Routing Verification Report
10095
E.2.3.4 Requirements
10096
10097
10098
E.2.3.4.1 The physical implementation should be performed under the responsibility of the
implementer on the basis of the architecture and design for the PD logic. Requirements from
E.2.3.4.2 to E.2.3.4.3 refer to the PD implementation constraints and programming file.
10099
10100
10101
E.2.3.4.2 The PD implementation constraints should instantiate the implementation

requirements as defined in architecture and design for the PD (timing, metastability, load,
mapping, pin-out, segregation).
10102
10103
E.2.3.4.3 The PD implementation constraints and programming file should be placed under
configuration control before testing.
10104
10105
10106
E.2.3.4.4 A PD Synthesis Place and Routing Verification Report should be written, under
the responsibility of the Verifier, on the basis of the architecture and design, Net-list and
programming files for the PD.
10107
10108
10109
E.2.3.4.5 The PD Synthesis Place and Routing Verification Report should be written in
accordance with the generic requirements established for a Verification Report (see 7.3.4.4)
and should address:
To provide means to be able to maintain and regenerate the PD programming file.
prEN 50126-4
- 128 -
10110
10111
a) the correct implementation (e.g. segregation, placement, resources allocation) of constraints

defined in the PD Architecture and Design Specification in the PD programming file;
10112
b) The target programmable chip and related correct implementation of supplier constraints;
10113
c) the correct use of the chosen techniques and measures listed in E.2.4.
10114
10115
E.2.4
10116
10117
The clauses of this annex are associated to tables (see Table E.1 and Table E.3) to illustrate the
means of achieving conformance.
10118
10119
10120
10121
With each technique or measure in the tables, there is a requirement for each safety integrity level
(SIL). The requirements for safety integrity levels 1 and 2 are the same for each technique. Similarly,
each technique has the same requirements at software safety integrity levels 3 and 4. These
requirements can be:
10122
'M'
this symbol means that the use of a technique is mandatory;
10123
10124
10125
10126
'HR'
this symbol means that the technique or measure is Highly Recommended for this safety
integrity level. If this technique or measure is not used then the rationale for using alternative
techniques should be detailed in the Quality Assurance Plan or in another document
referenced by the Quality Assurance Plan;
10127
10128
10129
'R'
this symbol means that the technique or measure is Recommended for this safety integrity
level. This is a lower level of recommendation than an 'HR' and such techniques can be
combined to form part of a package;
10130
10131
'-'
this symbol means that the technique or measure has no recommendation for or against
being used;
10132
10133
10134
10135
'NR'
this symbol means that the technique or measure is positively Not Recommended for this
safety integrity level. If this technique or measure is used then the rationale behind using it
should be detailed in the Quality Assurance Plan or in another document referenced by the
Quality Assurance Plan.
10136
10137
10138
10139
10140
10141
10142
10143
The combination of techniques or measures are to be stated in the Quality Assurance Plan or in
another document referenced by the Quality Assurance Plan with one or more techniques or
measures being selected unless the notes attached to the table makes other requirements. These
notes can include reference to approved techniques or approved combinations of techniques. If such
techniques or combinations of techniques, including all respective mandatory techniques, are used,
then the Assessor should accept them as valid and should only be concerned that they have been
correctly applied. If a different set of techniques is used and can be justified, then the Assessor may
find this acceptable.
10144
10145
For not complex PDs, a simplified set of Techniques and Methods is applicable. Criteria for the
evaluation of the complexity should be defined during the validation planning.
10146
Following the guidelines in this annex does not guarantee by itself the required safety integrity.
10147
It is important to consider:
10148
10149
the consistency of the chosen techniques and measures, and how well they will complement each
other;
10150
10151
which techniques and measures are appropriate, for every phase of the development life cycle;
and
10152
10153
which techniques and measures are most appropriate for the specific problems encountered
during the development of each different safety-related system.
10154
Techniques and Measures
- 129 -
10155
10156
10157
10158
prEN 50126-4
In the following tables, a letter following the number (e.g. 5a) indicates a group of equivalent
techniques/measures. Techniques belonging to the same group have the same level of
recommendation. Only one technique per group may be chosen for implementation according to the
prescribed level of recommendation.
10159
TECHNIQUE/MEASURE
Ref
SIL0
SIL1
SIL2
SIL3
SIL4
1 Structured description
E.3
HR
HR
HR
HR
2 Design description in (V)HDL
E.1
HR
HR
HR
HR
3 Schematic entry
E.2
NR
NR
4 Design description using boolean

equations
NR
NR
5a For circuit descriptions that use

boolean equations: manual inspection
in designs with limited (low)
complexity
HR
HR
HR
HR
5b For circuit descriptions that use

boolean equations: simulation of state
transitions in designs with higher
complexity
HR
HR
HR
HR
6 Application of a proven in use

design environment
E.4
HR
HR
HR
HR
HR
7 Application of proven in use (V)HDL

simulators
HR
HR
HR
HR
HR
8 Functional test on component level

(using for example (V)HDL test
benches)
E.6
HR
HR
HR
HR
HR
9 Restricted use of asynchronous

constructs
E.9
HR
HR
HR
HR
HR
10 Design for testability (depending on

the test coverage in percent)
E.11
11 Modularisation
E.12
HR
HR
E.13
HR
HR
13 Observation of coding guidelines
E.14
HR
HR
HR
HR
HR
14 Documentation
results
E.17
HR
HR
HR
HR
15a Code inspection
E.18
HR
HR
15b Walk-through
E.19
HR
HR
12 Coverage of the
scenarios (test benches)
of
verification
simulation
prEN 50126-4
- 130 -
TECHNIQUE/MEASURE
Ref
SIL0
SIL1
SIL2
SIL3
SIL4
16a Application of validated soft-cores
E.20
HR
HR
16b Validation of soft-cores
E.21
HR
HR
Note 1: For not complex PDs, the following techniques and measures are R only for all SILs
12, 16a/b, 19a/b, 20, 23, 24, 26a/b/c, 27a, 28a/b, 30.
Note 2: As an alternative to techniques 16a/b, soft-cores may be integrated and validated according to the
requirements for use of pre-existing components (see EN 50126-5).
10160
Table E.1 Design (including all activities pre-synthesis)
10161
TECHNIQUE/MEASURE
Ref
SIL0
SIL1
SIL2
SIL3
SIL4
17 Internal consistency checks
E.5
HR
HR
HR
HR
18a Simulation of the gate netlist, to

check timing constraints
E.22
18b Static analysis of the propagation

delay (STA)
E.23
19a Verification of the gate netlist

against a reference model by
simulation
E.24
HR
HR
19b Comparison of the gate netlist

with the reference model (formal
equivalence check)
E.25
HR
HR
20 For PLD/CPLD in complex

designs: check of the design by
simulation
HR
HR
21 Check of IC vendor requirements

and constraints
E.26
HR
HR
HR
HR
22 Documentation of synthesis
constraints, results and tools
E.27
HR
HR
HR
HR
23 Application of proven in use

synthesis tools
E.28
HR
HR
HR
HR
24 Application of proven in use

libraries/CPLD technologies
E.29
HR
HR
HR
HR
25 Script based procedure
E.30
HR
HR
10162
Table E.2 - Synthesis
- 131 -
prEN 50126-4
10163
TECHNIQUE/MEASURE
Ref
SIL0
SIL1
SIL2
SIL3
SIL4
26a Justification for proven in use for

applied hard cores
E.34
HR
HR
HR
HR
26b Application of validated hard

cores
E.35
HR
HR
HR
HR
26c On line testing of hard cores
E.36
HR
HR
HR
HR
27a Simulation of the gate net list

simulation
E.22
HR
HR
HR
HR
27b Static analysis of the propagation

delay (STA)
E.23
HR
HR
HR
HR
28a Verification of the gate netlist

simulation
E.24
HR
HR
HR
HR
28b Comparison of the gate netlist

with the reference model (formal
equivalence check)
E.25
HR
HR
HR
HR
29Design rule check (DRC)
E.37
HR
HR
HR
HR
30Application of a proven in use

design environments, application of
proven in use cell libraries
E.4
HR
HR
HR
HR
HR
31Additional slack (>20 %) for

process technologies in use for less
than 3 years
E.39
HR
HR
HR
HR
10164
10165
Table E.3 - Placement, Routing
prEN 50126-4
10166
E.2.5
- 132 -
Description of Techniques and Measures
10167
ID
TECHNIQUE/MEASURE
Description
E.3
Structured description
Description of the circuit functionality with (V)HDL or by schematic

entry. An easily recognisable and modular structure is
recommended. Each component should be implemented likewise
in the same fashion and should be described in such a way that it
is easily readable with clear defined sub functions. A strict
distinction between implemented function and interconnection is
recommended, i.e. the component, which is implemented by
instancing other sub components, contains explicitly
interconnections of the instanced components and should not
contain any circuit logic.
E.1
Design description in
(V)HDL
Functional description at high abstraction level in hardware

description language, for example VHDL or Verilog. The applied
hardware description language should allow functional and/or
application oriented description and should be abstracted from later
implementation details. Data flows, branches, arithmetical and/or
logical operations should be implemented by assignment and
operators of the hardware description language, without manual
conversion in logical gates of the applied library.
E.2
Schematic entry
Description of the circuit functionality by schematic entry of the

circuit plan. The function to be realised should be implemented by
instancing (import) the elementary logical circuit elements such as
AND, OR, NOT along with macros consisting of complex
arithmetical and logical functions, which are then interconnected.
Complex circuits should be partitioned considering the functional
viewpoints and can be distributed on different drawings, which are
hierarchically interconnected. The interconnection signals should
be uniquely defined and have explicit signal names over the entire
hierarchy. The use of global signals (Labels) should be avoided as
far as applicable
E.4
Application of a proven in
use design environment
Most of the used tools for designing programmable devices

comprise of sophisticated software, which cannot be considered to
operate without any faults with respect to its correct functionality
and it is also quite likely that faults might occur due to faulty
operation. Therefore only tools with the attribute "proven-in-use"
should be preferred for designing programmable device. This
implies:
-
Application of tools which have been used (in a comparable

software version) over a long period of time or high number of
users in various projects with equivalent complexity.
Adequate experience of each programmable device designer
with the operation of the tool over a long period of time.
Use of commonly used tools (adequate number of users) so
that information regarding known failures with work around
(version control with "Bug-List") is available. This information
should be readily integrated in design flow and helps to avoid
systematic failures.
The consistency check of the internal tool database and the
- 133 -
ID
TECHNIQUE/MEASURE
prEN 50126-4
Description
plausibility check avoid faulty output data. Standard tools check
the consistency of the internal database, for example the
consistency of database between synthesis- and place-androute-tool, in order to operate with unique data.
NOTE The consistency check is an inherent attribute of the tool

under use and the designer has limited influence
on it. Therefore, if the possibility of manual consistency check is
provided, the designer should use it adequately.
E.6
Functional test on
component level (using for
example (V)HDL test
benches)
Verification of the implemented function - for example by simulation

- at component level. The component under test will be instanced
in a typical virtual test environment known as test bench and
stimulated by the test pattern contained in the code. A sufficient
high coverage of specified function including all special cases if
they exist is at least required.
Automatic verification of output sequence by the code of "test
bench" should be preferred against manual inspection of output
signals.
E.9
Restricted use of
asynchronous constructs
Asynchronous constructs such as SET and RESET signals derived

over combinatorial logic are susceptible during synthesis and
produce circuits with spikes or inverse timing sequence and
therefore should be avoided. Also insufficient modelling may not be
interpreted properly by the synthesis tool, which causes ambiguous
results during simulation. Additionally asynchronous constructs are
poorly testable or not at all testable, so that the test coverage of
production and on-line test is effectively reduced. The
implementation of completely synchronous design with limited
number of clock signals is therefore recommended. In systems with
multiphase clocks, all the clocks should be derived from one
central clock. Clock input of sequential logic should be always
supplied exclusively by the clock signal, which does not contain
any combinatorial logic. Asynchronous SET and RESET inputs of
sequential cells should be always supplied by synchronous signals
that do not contain any combinatorial logic. Master SET and
RESET should be synchronised using two Flip-flops.
E.11
Design for testability

(depending on the test
coverage in percent)
Design for testability is governed by the avoidance of

-
asynchronous constructs
latches and on-chip tri-state signals
wired-and / wired-or logic and redundant logic.
The combinatorial depth of the sub circuits plays an important role

during the testing. The test pattern required for a complete test
increases exponentially with the combinatorial depth of the circuit.
Therefore, circuits with high combinatorial depth are only poorly
testable with adequate means.
A design for testability-orientated approach ensures that the
desired test coverage is achieved. As the actual test coverage can
be determined at a very late stage in the design process,
prEN 50126-4
ID
- 134 -
TECHNIQUE/MEASURE
Description
insufficient consideration of design for testability issues might
dramatically reduce the achievable test coverage, leading to
additional effort.
NOTE The test coverage is usually determined by the percentage
of stuck-at faults detected
E.12
Modularisation
E.13
Coverage of the verification The quality of the verification scenarios that is defined during the
scenarios
functional test, i.e. the applied test pattern (stimuli) to verify
specified function including all special cases, if they exist, should
(test benches)
be qualitatively and/or quantitatively documented. During a
quantitative approach the achieved test coverage and the depth of
the applied functional tests should be documented. The resulting
coverage should meet the levels established for each of the
coverage metrics. Any exception will be documented. In the case
of a qualitative approach, the number of verified code lines,
instructions or paths (Code coverage) of the circuit code to be
verified should be estimated.
E.14
Observation of coding
guidelines
Distinct partitioning of the total functionality in different components

with limited functions. So the transparency of the components with
the precisely defined interface is established. Every subsystem, at
all levels of the design, is clearly defined and is of restricted size
(only a few functions). The interfaces between subsystems are
kept as simple as possible and the cross-section (i.e. shared data,
exchange of information) is minimised. The complexity of individual
subsystems is also restricted. Every component should be
accessible from the external interfaces of the programmable
device, in order to permit an high testability and to allow the
required validation test (and facilitate implementation of built-in
test).
Syntactic coding rules help to create an easily readable code and

allow a better documentation including version control. Typically,
the rules for organising and commenting the instruction blocks can
be mentioned here. Semantic coding rules help avoiding typical
implementation problems by avoidance of constructs that lead to
faulty synthesis with ambiguous implementation of the circuit
function. Typical rules are for example the avoidance of
asynchronous constructs or constructs that produce unpredictable
timing sequence. In general the use of latches or coupling of data
with clock signals lead to such ambiguities. Design guidelines are
recommended to avoid systematic design failures during the
development of the programmable device. A coding style in certain
aspect limits the design efficiency, offers however in turn the
advantage of failure avoidance during the development of the
programmable device. These are in particular:
-
E.17
Documentation of
avoidance of typical coding infirmity or failure;

restrictive usage of problematic constructs that produce
ambiguous synthesis results;
design for testability (e.g. internal gates with tri-state output);
transparent and easy to use code.
All the data needed for the functional simulation at component-,

chip- or system level should be well documented and archived with
- 135 -
ID
TECHNIQUE/MEASURE
simulation results
Description
the following aims:
-
E.18
Code inspection
Walk-through
To repeat the simulation at any later phase in turn key fashion.

To demonstrate the correctness and completeness of all
functions specified.
The following database should be archived for this purpose:
Simulation set-up including complete software of the applied
tools, for example simulator, synthesiser with corresponding
version and the necessary simulation library.
Log file of the simulation with full details regarding the time of
simulation, applied tools with version and complete report of
the work around if it was necessary.
All relevant simulation results inclusive signal flow, especially in
case of manual inspection and documentation of acquired
results.
Review of circuit description should be carried out by

-
E.19
prEN 50126-4
Checking the coding style.

Verification of the described functionality against the
specification.
Checking for defensive coding, error and exception handling.
A code walk-through consists of a walk-through team selecting a

small set of test cases, representative sets of inputs and
corresponding expected outputs for the program. The test data is
then manually traced through the logic of the program.
NOTE As stand-alone measure it should be applied only to the
circuits with very low complexity. In the case of the failing (V)HDLSimulation the completeness of the walk-through and the quality of
the achieved results should have the equivalent quality that will be
achieved by a (V)HDL-simulation.
E.20
Application of validated
soft-cores
If the vendor validates the soft core, following requirements should

be fulfilled:
-
E.21
10168
Validation of soft-cores
The validation of the soft core should be carried out for the
operation of the safety related system, having at least an
equivalent or higher safety integrity level than the system under
plan.
All the assumptions and confinements, which are necessary for
the validation of the soft core, should be complied.
All the necessary documents for the validation of the soft core
should be easily available, see also Technique 14
"Documentation of simulation results".
Each vendor specification should be strictly observed and the
evidence of the compliance should be documented.
If the soft core is not explicitly developed for the operation in a

safety related system, the generated code should be validated
under the same premises that apply for the validation of any source
code. This means that all possible test cases should be defined
and implemented. The functional verification should be then
derived by simulation.
Table Description for techniques/measures from E.1 Design
prEN 50126-4
- 136 -
10169
10170
10171
10172
ID
E.5
TECHNIQUE/MEASURE
Internal consistency
checks
E.24 Verification of the gate

netlist against a reference
model by simulation
Description
Application of proven-in-use tools to avoid systematic failure by
sufficient long approved practice of the tools in various projects.
Simulation of the gate netlist generated by synthesis tool. The
applied stimuli for the verification of the circuit by simulation
correspond exactly to the stimuli applied during the E.6 "Functional
test on component level" and the E.7 "Functional test on top level"
for the verification of the function at component level and top level
respectively. The functional verification should be primarily
performed by observing the outputs of the chip. This can be
automated by comparing the output signals of the circuit with an
adequate reference model or (V)HDL source code of the circuit.
This test is known as a regression test and should be preferred to
a manual check of the output signals.
NOTE By applying this measure the functional behaviour of only
those paths are verified which are actually stimulated during the
simulation. The test coverage can, therefore, only be as good as
during the original functional test at component - or top-level,
respectively. It is possible to complement this measure with a
formal equivalence test. In all cases a functional verification of the
(V)HDL source code should be carried out with the final netlist
generated by the synthesis tool.
E.25 Comparison of the gate

netlist with the reference
model (formal equivalence
check)
Comparison of the circuit functionality described by the (V)HDL

source code with the circuit functionality of the gate netlist
generated by synthesis. The tools based on the formal equivalence
principle are capable of verifying the functional equivalence of a
different representation form of the circuit for example (V)HDL
description or netlist description. By applying this measure a
functional simulation is not necessary and an independent
functional check is feasible. The successful application of this
measure can only be guaranteed, if the applied tool is capable of
proving complete equivalence and all the discrepancies reported
are evaluated either by manual inspection or automatically.
NOTE It is advantageous to combine this measure with E.24
"Verification of the gate netlist against reference model by
simulation". In all cases, a functional verification of (V)HDL source
code should be carried out with the final netlist generated by the
synthesis tool
E.26 Check of IC vendor

requirements and
constraints
A careful checking of the vendor requirements and constraints for

example minimum and maximum fan-in and fan-out, maximum wire
length (line delay), maximum slew rate of the signals, clock skew
and so on by the synthesis tool enhances the reliability of the
product. Besides the importance of the requirements for the
production process, their violation has a great impact on the validity
- 137 -
ID
TECHNIQUE/MEASURE
prEN 50126-4
Description
of the applied models that are used for the simulation. So that any
violation of the vendor requirements and constraints leads to faulty
simulation results producing undesired functionality.
E.27 Documentation of
synthesis constraints,
results and tools
The documentation of all the synthesis constraints and results is

indispensable
because of the following reasons:
-
E.28 Application of proven in

use synthesis tools
Tool based mapping of the (V)HDL source code of circuit

functionality by connection of the suitable gates and circuit
primitives of the target library for the programmable device. The
selected implementation out of a variety of possible
implementations that fulfil the desired functionality depends on the
most optimal result that is derived by the synthesis constraints such
as timing (clock rate) and chip area. During synthesis phase any
automatic optimization done by tools themselves should be
avoided.
E.29 Application of proven in

use libraries/CPLD
technologies
The synthesis and simulation target library for the development of

an programmable device are derived from a common database
and, therefore, are not independent. A systematic failure such as:
-
E.29 Script based procedure
10173
10174
to reproduce the synthesis at any later phase.

to generate an independent synthesis results for verification.
Essential documents are:
Synthesis set-up including the applied tools and synthesis
software with the actual version, the applied synthesis library
and the defined constraints and scripts.
Synthesis log file with the time remark, applied tool with version
and complete documentation of the synthesis.
The generated netlist with estimated time delays (standard
delay format (SDF) File).
ambiguity between real and modelled behaviour of the circuit

elements,
insufficient modelling for example of set-up and hold time, is
one of the typical examples.
Therefore only proven-in-use technologies and target libraries
should be used for the design of programmable devices that
perform safety functions. This means:
- The application of target libraries that have been used over
a significant long time in projects with comparable
complexity and clock rating.
Availability of the technology and corresponding target
library over a sufficient long period, so that enough
modelling accuracy of the library can be expected.
Automatic and script based control of the synthesis cycles including

the definition of the applied constraints. Besides a precise
documentation of a complete synthesis constraint, it helps to
reproduce the netlist after the alteration of the (V)HDL source code
under identical conditions.
Table Description for techniques/ measures from E.2 Synthesis
prEN 50126-4
- 138 -
10175
ID
Technique/measure
Description
E.34 Justification for

proven in use for
applied hard cores
A hard core is generally regarded as a black box representing the

desired functionality and is composed of layout data basis in target
technology that provides the desired circuit component. The possible
functional failure can be treated in analogy to discrete components like,
standard microprocessors, memories etc. The operation of such hard
cores without the verification of correct functionality is possible, if for the
applied target technology the used core can be considered as proven-inuse component. The rest of the circuit should then be verified
intensively.
E.35 Application of
validated hard cores
The core validation should be carried out by vendors, because of the

complex nature of the core and assumed constraints, during the design
phase on the basis of the (V)HDL source code. The validation can be
justified only for the configuration and the target technology of the
applied component.
E.36 On line testing of

hard cores
Verification of correct function and implementation of used hard cores by

application of on-line tests. In applying this measure an efficient test
concept is necessary and the evaluation of the applied concept should
be documented.
Simulation of the gate netlist produced by the synthesis including the

E.22 Simulation of the
gate net list against a back-annotation of line delays and gate delays. The stimuli should be
reference model by derived to stimulate the circuit in such a fashion that it will cover a high
simulation
percentage of the timing constraints and include all the worst case timing
paths.
NOTE By applying this measure, the timing behaviour of only those
paths can be verified which are actually stimulated during the simulation
and, therefore, the bespoke measure cannot provide a complete timing
analysis of the circuit in general.
E.23 Static analysis of the Static Timing Analysis (STA) analyses all the paths of a netlist (circuit)
propagation delay
generated by the synthesis tool considering the back-annotation, i.e.
(STA)
estimated line delays by the synthesis tool, as well as gate delays
without performing the actual simulation. Therefore it allows in general a
complete analysis of the timing constraint of the entire circuit. The circuit
to be tested should be analysed under best- and worst-case condition
operating at maximum specified clock rate and accounting for applicable
clock jitter and duty cycle skew. The number of non-relevant timing paths
can be limited to a certain minimum by adopting a suitable design
technique. It is recommended to investigate, analyse and define the
used technique that allows easily readable results before beginning with
the design.
NOTE It can be assumed that STA covers explicit all the existing timing
paths if
a) The timing constraints are properly specified.
b) The circuit under test contains only such timing paths that can be
analysed by STA tools, i.e. generally the case with full synchronous
circuits.
- 139 -
ID
Technique/measure
prEN 50126-4
Description
c) Gate and interconnection (wire) delay should be considered
E.24 Verification of the

gate netlist against a
reference model by
simulation
Simulation of the gate netlist generated by synthesis tool. The applied

stimuli for the verification of the circuit by simulation correspond exactly
to the stimuli applied during the E.6 "Functional test on component level"
and the E.7 "Functional test on top level" for the verification of the
function at component level and top level respectively. The functional
verification should be primarily performed by observing the outputs of the
chip. This can be automated by comparing the output signals of the
circuit with an adequate reference model or (V)HDL source code of the
circuit. This test is known as a regression test and should be preferred
to a manual check of the output signals.
NOTE By applying this measure the functional behaviour of only those
paths are verified which are actually stimulated during the simulation.
The test coverage can, therefore, only be as good as during the original
functional test at component - or top-level, respectively. It is possible to
complement this measure with a formal equivalence test. In all cases a
functional verification of the (V)HDL source code should be carried out
with the final netlist generated by the synthesis tool.
E.25 Comparison of the

gate netlist with the
reference model
(formal equivalence
check)
Comparison of the circuit functionality described by the (V)HDL source

code with the circuit functionality of the gate netlist generated by
synthesis. The tools based on the formal equivalence principle are
capable of verifying the functional equivalence of a different
representation form of the circuit for example (V)HDL description or
netlist description. By applying this measure a functional simulation is
not necessary and an independent functional check is feasible. The
successful application of this measure can only be guaranteed, if the
applied tool is capable of proving complete equivalence and all the
discrepancies reported are evaluated either by manual inspection or
automatically.
E.37 Design rule check

(DRC)
Verification of the generated layout with respect to vendor design rules,

for example minimum wire lengths, maximum wire lengths and several
rules regarding placement of layout structures. A complete and correct
run of DRC should be documented in detail.
E.4
Application of a
Only tools with the attribute "proven-in-use" should be preferred for
proven in use design
designing programmable devices. This implies:
environments,
application of proven
- Application of tools which have been used (in a comparable software
in use cell libraries
version) over a long period of time or high number of users in
various projects with equivalent complexity.
- Adequate experience of each designer of a programmable device
with the operation of the tool over a long period of time.
- Use of commonly used tools (adequate number of users) so that
information regarding known failures with work around (version
control with "Bug-List") is available. This information should be
readily integrated in design flow and helps to avoid systematic
failures.
- The consistency check of the internal tool database and the
plausibility check avoid faulty output data. Standard tools check the
consistency of the internal database, for example the consistency of
prEN 50126-4
ID
- 140 -
Technique/measure
Description
database between synthesis- and place-and-route-tool, in order to
operate with unique data.
NOTE The consistency check is an inherent attribute of the tool under
use and the designer has limited influence on it. Therefore, if the
possibility of manual consistency check is provided, the designer should
use it adequately
E.39 Additional slack (>20

%) for process
technologies in use
for less than 3 years
The actual circuit behaviour is defined by number of overlapping physical

effects particularly for small structures (for example below 0,5 m). As a
matter of fact, due to the lack of detail knowledge and necessary
simplifications an exact model of circuit elements cannot be derived.
With decreasing geometrical structures line delays play more and more
dominant role. Signal delays along the wire and cross-coupling
capacities between the wires grow over proportional. Signal delays are
no longer negligible compared to gate delays. Estimated line delays
depict increasing risk with decreasing geometrical structures. Therefore
it is recommended to plan an adequate amount of slack (> 20 %) with
respect to minimal and maximal timing constraints for circuits designed
using processes in use for less
than 3 years, in order to guarantee correct operation of the circuit
functionality in presence of strongly fluctuating parameters during the
production or due to lack of precise modelling.
10176
Table Description for techniques/ measures from E.3 - Placement, Routing and Layout Generation
10177
10178
E.3
Pre-existing programmable devices
10179
The use of pre-existing programmable devices (PD) shall be subject to the following restrictions.
10180
a)
For all safety integrity levels the following information shall clearly be identified and documented:
10181
1. the requirements that the pre-existing programmable devices is intended to fulfil;
10182
2. the assumptions about the environment of the pre-existing programmable devices;
10183
3. interfaces with other programmable devices.
10184
10185
b)
For all safety integrity levels the pre-existing programmable device shall be included in the
validation process of the whole hardware.
10186
c)
For safety integrity levels SIL 3 or SIL 4, the following precautions shall be taken:
10187
10188
1. an analysis of possible failures of the pre-existing programmable device and their

consequences on the whole system shall be carried out;
10189
10190
2. a strategy shall be defined to detect failures of the pre-existing programmable device and to
protect the system from these failures;
10191
3. the verification and validation process shall ensure
10192
4. that the pre-existing programmable device fulfils the allocated requirements;
10193
10194
5. that failures of the pre-existing programmable device are detected and the enclosing system is
protected from these failures;
10195
10196
6. that the assumptions about the environment of the pre-existing programmable device are
fulfilled.
- 141 -
prEN 50126-4
10197
Annex F
10198
10199
(normative)
10200
10201
Previously Developed Hardware (PDH) and Commercial Off The Shelf

Hardware (COTSH)
10202
F.1 Introduction
10203
F.1.1 Purpose
10204
10205
10206
This sub-clause specifies the issues associated with the use of previously developed or commercially
procured Hardware. It provides guidance and requirements for the use and embedding processes of
PDH and COTSH.
10207
10208
F.1.2 Modifications to Previously Developed Hardware
10209
10210
Modifications may be needed by different kind of change requests. That means any kind of
requirement change, error detection, changes in HW-technology, procurement problems.
10211
10212
F.1.2.1
An impact analysis shall be carried out. Impacted subsystems and components shall be
involved in the verification and validation process.
10213
10214
F.1.2.2
If the previously developed HW uses a different SW there a re-verification of HW-/SW

interfaces shall be performed.
10215
10216
10217
F.1.2.2
The safety integrity level shall be analysed, reviewed and confirmed upon modification. If
there are differences to the original SIL, the influence shall be considered for interfaces
and on system level.
10218
10219
F.1.3 Influence in System Environment
10220
10221
Previously developed HW may have an impact in the design toolchain and other HW/SW components
and systems.
10222
F.1.3.1
The tool-chain shall demonstrably accomplish the safety requirements.
10223
F.1.3.2
The requirements of F.2 shall be fulfilled.
10224
10225
F.1.4 Integration in Change and Configuration Management
10226
10227
F.1.4.1
Previously developed HW shall be integrated in the change and configuration

management processes and handled as a discrete component.
10228
10229
F.1.4.2
the traceability from product and life cycle data of the previous application to the new
application shall be assured.
10230
10231
F.2 Commercial Off The Shelf Hardware (COTSH) Component Usage
10232
COTSH implies mass market components without technical verifiable datasheets.
10233
10234
The use of COTSH components shall be verified in the system implementation process, as defined
chapter 8.4, 8.5, 8.6 of this document.
prEN 50126-4
- 142 -
10235
10236
F.2.1 Technical Aspects of Quality Management for COTSH
10237
10238
10239
10240
F.2.1.1
F.2.1.2
F.2.1.3
quality control procedures shall be established at the component manufacturer

quality records of the production line shall be available at the component manufacturer
field data representing the components functionality under predefined conditions shall be
maintained
10241
10242
F.2.1.4
the components RAM specification should be available through manufacturers testing

methods and records
10243
F.2.1.5
the selection of components shall be based on technical and RAM requirements.
10244
10245
F.2.2 COTSH Component Procurement
10246
10247
Due to availability demands some requirements for procurement are provided which have influence in
the hardware design.
10248
The major concerns refer to:
10249
10250
10251
10252
a)
b)
c)
d)
10253
Market lifetime availability of COTS components

Second source supplier strategy
Evolution of COTS components (down grade compatibility of new components)
Identification of series production component parameter variations
- 143 -
prEN 50126-4
Annex G
(informative)
Structure of Hardware/Systems Safety Cases
10254
10255
10256
10257
10258
10259
10260
This annex defines the contents of Generic Product, Generic Application, Specific Application and
Cross-Acceptance Safety Cases for E/E/PE Systems by defining the hierarchy of the headings and
the names for the headings based on the definition of the safety case from sub-clause 8.2. Also
suggestions on how to develop some topics are given.
10261
G.1
10262
10263
The Safety Case contains the documented safety evidence for the system/sub-system/equipment,
and, according to Part 1, it is structured as follows:
10264
Part 1
10265
10266
10267
This precisely defines or reference the system/sub-system/equipment to which the Safety Case
refers, including version numbers and modification status of all requirements, design and application
documentation.
10268
No specific structure for this chapter.
10269
Part 2
10270
This contains the evidence of quality management, as specified in 8.6 of this standard.
10271
No specific structure fort this chapter.
10272
Part 3
10273
This contains the evidence of safety management, as specified in 8.6 of this standard.
10274
A list of headings for this chapter is given in G.1.1.
10275
Part 4
10276
This contains the evidence of functional and technical Safety, as specified in 8.6 of this standard.
10277
A structure for this chapter is given in G.1.2.
10278
Part 5
10279
10280
This contains references to the Safety Cases of any sub-systems or equipment on which the main
Safety Case depends.
10281
10282
This also the demonstrates that all the safety-related application conditions specified in each of the
related sub-system/equipment Safety Cases are:
10283
either
10284
or
10285
10286
Part 6
10287
10288
10289
This summarises the evidence presented in the previous parts of the Safety Case, and argue that the
relevant system/sub-system/equipment is adequately safe, subject to compliance with the specified
application conditions.
10290
Generic Product Safety Case Guidance for E/E/PE
Definition of System (or sub-system/equipment)
Quality Management Report
Safety Management Report
Technical Safety Report
Related Safety Cases
fulfilled in the main Safety Case,
carried forward into the safety-related application conditions of the main Safety Case.
Conclusion
prEN 50126-4
10291
- 144 -
The structure of the whole Safety Case is illustrated in Figure 3.

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
10292
10293
Figure G. 1 Structure of Safety Case
10294
10295
G.1.1
10296
According to contents defined in clause 8.6 this chapter may be arranged in the following headings:
10297
10298
10299
10300
10301
10302
10303
10304
10305
3.1. Safety life cycle

3.2. Safety organisation
3.3. Safety plan
3.4. Hazard log
3.5. Safety requirements specification
3.6. Design
3.7. Safety reviews
3.8. Generic Product handover
3.9. Operation and maintenance
- 145 -
10306
G.1.2
10307
According to contents defined in clause 8.6, this chapter may be arranged as follows:
prEN 50126-4
10308
10309
Figure G.1 Structure of Technical Safety Report
10310
Section 1 Introduction
10311
10312
10313
This section includes an overview description of the design, including a summary of the technical
safety principles that are relied on for safety and the extent to which the system/subsystem/equipment is claimed to be safe in accordance with this standard.
10314
Section 2 Assurance of correct functional operation
10315
10316
10317
This section contains all the evidence necessary to demonstrate correct operation of the system/subsystem/equipment under fault-free normal conditions (that is, with no faults in existence), in
accordance with the specified operational and safety requirements.
10318
The following aspects are also included:
10319
2.1 System architecture description (see Table A.5);
10320
10321
This contains a general description of the system/sub-system/equipment design, in sufficient depth to

convey a clear understanding of the principles and techniques which it uses.
10322
NOTE: Some particular topics which should receive attention include
10323
10324
10325
10326
- dependence between hardware and software,

- sequence of interaction,
- response times,
- self test routines,
prEN 50126-4
- 146 -
10327
10328
10329
10330
- health monitoring,
10331
2.2 Definition of interfaces (as detailed below);
10332
2.2.1 Man-machine interfaces
10333
a)
10334
10335
This describes the mechanisms by which the system/sub-system/equipment will be operated by

operating and engineering personnel.
10336
EXAMPLE
10337
under normal conditions;
10338
in response to alarms;
10339
by use of 'help' routines.
10340
b)
Configuration
10341
10342
This describes the processes carried out by engineering personnel to configure the system/subsystem/equipment to a specific railway or application.
10343
EXAMPLE
10344
software parameterising;
10345
hard wiring;
10346
installation techniques;
10347
procedures.
10348
c)
Maintenance
10349
10350
This describes the interface mechanisms, including the use of any ancillary equipment, which
will be used by maintenance personnel in the course of performing the various levels of maintenance.
- data acquisition techniques,

- graceful degradation,
- negation methods.
10351
Operator
More detailed information is contained in 5.2.
10352
2.2.2 System interfaces
10353
a)
10354
10355
This defines the functional and physical interfaces between items internal to the system/subsystem/equipment.
10356
EXAMPLE
10357
electrically clean and dirty areas;
10358
internal bus structures;
10359
communication links;
10360
functional monitoring and correction;
10361
diagnostic and health monitoring.
Internal
- 147 -
prEN 50126-4
10362
b)
External
10363
10364
This defines the functional and physical interfaces between the system/sub-system/equipment
and external items.
10365
EXAMPLE
10366
sensors;
10367
actuators;
10368
communication links;
10369
test and monitoring provisions;
10370
expansion facilities.
10371
2.3 Fulfilment of System Requirements Specification;
10372
2.4 Fulfilment of Safety Requirements Specification
10373
2.5 Assurance of correct hardware functionality;
10374
10375
10376
This describes the system/sub-system/equipment hardware architecture, and explains how the design
achieves the required integrity, as laid down by the requirements specification and any relevant
standards, in respect of
10377
10378
10379
10380
reliability,
availability,
maintainability,
safety.
10381
10382
Consideration of safety may be limited to fault-free conditions, because effects of faults are dealt with
elsewhere (see Section 3).
10383
2.6 Assurance of correct software functionality.
10384
10385
All documentation required by EN 50126 Part 5 is included or referenced in this section, particularly
the Software Validation Report and the Software Assessment Report.
10386
Section 3 Effects of faults
10387
10388
10389
This section aims to demonstrate that the system/sub-system/equipment continues to meet its
specified safety requirements, including the quantified safety target, in the event of random hardware
faults.
10390
10391
10392
In addition, a systematic fault could still exist, despite the quality and safety management processes
defined in this standard. This section demonstrates which technical measures have been taken to
reduce the consequent risk to an acceptable level.
10393
10394
10395
This section also includes demonstration that faults in any system/sub-system/equipment having a
Safety Integrity Level lower than that of the overall system, including Level 0, cannot reduce the
safety of the overall system.
10396
10397
The following headings can be used in this section. Guidance is also given in Table A.6 and Table
A.7.
10398
3.1 Effects of single faults;
10399
10400
In this section the safety principles chosen from the ones described in 8.2 is given. Also the results of
the Hazard analysis, according to clauses from 8.2.4.8.1 to 8.2.4.8.3 are included.
10401
3.2 Independence of items;
prEN 50126-4
- 148 -
10402
10403
In this section, evidence of achieved independence is given, according to Part 2 and Annex D,
clauses D.1 and D.2.
10404
3.3 Detection of single faults;
10405
10406
10407
10408
10409
The techniques used to achieve detection and negation of identified faults within the permitted time
are shown, including supporting calculations. The sources of basic failure rate data used in the
calculations (for example, hardware component failure rates) are identified, and the method of
quantitative analysis. An example of an approach to fulfilment of these requirements is contained in
D.3.
10410
3.4 Action following detection (including retention of safe state);
10411
10412
In this section, the description and the evaluation against safety target of the reaction after the
detection of a single fault is given according to requirements described in 8.2
10413
3.5 Effects of multiple faults;
10414
10415
10416
10417
In this section the results of Hazard analysis with regard to Multiple faults and common-cause faults,
according to clauses from 8.2.4.8.4 to 8.2.4.8.6, are provided. Also the techniques used to achieve
detection-plus-negation of multiple faults within the permitted time are shown, including supporting
calculations. An example of an approach to fulfilment of these requirements is contained in D.5.
10418
3.6 Defence against systematic faults
10419
10420
10421
10422
In addition to the quality and safety management techniques which are used to minimise the
probability of human error, technical measures shall be taken such that if a hazardous systematic fault
should exist it would, as far as reasonably practicable, be prevented from creating an unacceptable
risk.
10423
EXAMPLE
10424
Section 4 Operation with external influences
10425
10426
10427
This section concerns the ability of the system/sub-system/equipment to operate correctly and safely
when subjected to specified external influences. "Correct operation" includes fulfilment of both
operational and safety requirements.
10428
The influences which to be considered are listed in 4.1 to 4.7 below.
10429
Considerations on the effects of storage and transportation are also included.
10430
4.1 Climatic conditions
10431
4.2 Mechanical conditions
10432
4.3 Altitude
10433
4.4 Electrical conditions
10434
4.6 Protection against unauthorised access
10435
1)
10436
10437
10438
The access level defines who has access, reason for access and how access is achieved, thereby
guarding against unauthorised access. For each of the particular operations below, persons
performing these functions will require to meet certain criteria, defined in respect of
10439
skill discipline,
10440
skill level,
10441
equipment-specific training.
Any diversity introduced in the development process to avoid a systematic fault to be undetected.
Definition of access levels
- 149 -
prEN 50126-4
10442
2)
Protection
10443
With respect to the above access levels, this section defines how protection is to be achieved.
10444
The protective measures should guard against access which is
10445
accidental, by authorised persons,
10446
intentional, by unauthorised persons.
10447
3)
External conditions
10448
This describes how protection is achieved by means additional to the equipment itself.
10449
EXAMPLE
10450
housing;
10451
security;
10452
accessibility.
10453
4)
Encapsulation
10454
This describes how protection is achieved by the actual equipment.
10455
EXAMPLE
10456
covers;
10457
mounting;
10458
seals;
10459
coding, electrical;
10460
coding, mechanical;
10461
firmware.
10462
4.7 More severe conditions
10463
10464
Where necessary, provision to deal with additional, more severe, conditions specified by the railway
authority are described here.
10465
10466
10467
10468
NOTE: Examples of more severe conditions are condensation due to rapid variation in ambient
temperatures of equipment; severe pollution of the air by dust, smoke, steam, excessive heating from,
for example, fire or solar radiation; action/entry of plants, insects or animals; accumulation of dirt and
dust (conductive and/or non-conductive).
10469
Section 5 Safety-related application conditions
10470
10471
This section defines the rules, conditions and constraints relevant to functional safety which need to
be observed in the application of the system/sub-system/equipment.
10472
10473
General topics which to be considered include the following (they can be accordingly organized in
headings):
10474
configuration of programmable systems to suit specific applications;
10475
precautions in manufacturing, installation, testing and commissioning;
10476
rules and methods for maintenance and fault-finding;
prEN 50126-4
- 150 -
10477
Instructions for system operation;
10478
safety warnings and precautions;
10479
electromagnetic compatibility (EMC) precautions (susceptibility and emission);
10480
information concerning modifications and eventual de-commissioning;
10481
10482
safety justification of support equipment and tools, such as test equipment, maintenance
equipment and configuration tools.
10483
Some specific topics which that also can be included are listed in 5.1 to 5.4 below.
10484
5.1 Sub-system/equipment configuration and system build
10485
1)
10486
10487
If a sub-system or equipment is such that it has to be configured for each particular application, then
any configuration tools and/or procedures are described.
10488
EXAMPLE
10489
procedural methods;
10490
version control;
10491
hardware requirements of configuration system;
10492
software details of configuration system;
10493
software maintenance;
10494
verification and validation;
10495
simulation.
10496
2)
System build
10497
10498
This documentation details how sub-systems and equipment are built into a particular signalling
system.
10499
EXAMPLE
10500
version control settings;
10501
application control settings;
10502
interface settings;
10503
initialisation settings;
10504
maintenance control settings;
10505
manufacturing and production testing;
10506
system test routines;
10507
installation, testing and commissioning.
10508
3)
Change of functionality
10509
10510
10511
If a sub-system or equipment is of sufficient generic design that it could be employed in systems for
various applications, then how it is configured and set-up to meet these different applications is also
documented. Any limitations or conditions for safe use are fully specified.
Configuration
- 151 -
prEN 50126-4
10512
5.2 Operation and Maintenance
10513
1)
10514
10515
The conditions that exist in each system/sub-system/equipment are described to provide operating
and maintenance personnel with sufficient understanding during the following situations:
10516
a)
10517
10518
This describes the start-up conditions of the system, sub-system or equipment when power is initially
applied, or following shut-down due to power interruption or other cause.
10519
NOTE: This can include, for example,
10520
default conditions,
10521
initialisation period,
10522
self checks performed,
10523
manual intervention required,
10524
condition of outputs,
10525
precautions after an exceptional event, such as fire or unauthorised entry.
10526
b)
normal operation
10527
10528
Once the system/sub-system/equipment has successfully completed initialisation, the conditions

during normal operation are described.
10529
EXAMPLE
10530
cycle times;
10531
non-data routines;
10532
disclosure of faults.
10533
c)
changeover
10534
10535
10536
10537
If the equipment, or the system/sub-system in which it is configured, has a facility to change over to
either a cold or hot standby system/sub-system, then the conditions defined in a) and b) are re-stated
for this changeover routine. The reaction of the equipment to the changing of failed modules is also
be clearly defined.
10538
d)
10539
10540
all relevant conditions when a system, sub-system or item of equipment is shut down intentionally for
a configuration change or de-commissioning, or unintentionally via a power failure are defined
10541
EXAMPLE
10542
default conditions;
10543
conditions for graceful degradation;
10544
safety aspects;
10545
procedures;
10546
influences on other connected systems.
10547
2)
maintenance levels
operational status
start-up
shut-down
prEN 50126-4
- 152 -
10548
These are defined in respect of
10549
first line maintenance,
10550
second line maintenance by customer,
10551
second line maintenance by manufacturer.
10552
10553
10554
NOTE: "First line" is preventative maintenance and fault-finding/repair carried out on site, with
"second line" being preventative maintenance and possible repair in a workshop environment, that is,
off site.
10555
3)
10556
In describing the periodic maintenance required, reference to all relevant areas is included.
10557
EXAMPLE
10558
training;
10559
accessibility;
10560
modularity;
10561
inter-changeability;
10562
spares provisions;
10563
storage of spares.
10564
4)
maintenance aids
10565
For each level of maintenance, the maintenance aids available to personnel are described.
10566
NOTE: These aids can include, for example,
10567
fault diagnostics,
10568
interpretation of fault messages,
10569
fault correction.
10570
5.3 Operational safety monitoring
10571
10572
10573
The methods and techniques for the operational safety monitoring, to ensure that the features
incorporated into the design, and the assumptions made during the initial safety assessment, remain
valid for the actual circumstances encountered during in-service use are described here.
10574
NOTE: This can include, for example,
10575
10576
10577
the monitoring and assessment of failure reports to detect failure trends or possible hazardous
failures which can be corrected, thereby improving safety and reliability,
10578
10579
investigation of incident and accident reports to identify any changes required to improve the
safety performance of the system.
10580
5.4 Decommissioning and disposal
10581
10582
10583
The technical safety precautions and procedures which will be necessary when the system/subsystem/equipment is eventually decommissioned are documented. This includes consideration of
possible phased introduction of replacement systems whilst the railway continues in operation.
periodic maintenance
the monitoring of safety-related performance and comparison with the predicted performance,
- 153 -
prEN 50126-4
10584
10585
Appropriate warnings and instructions concerning final disposal of equipment after decommissioning
are also included.
10586
Section 6 Safety Qualification Tests
10587
10588
An account of the Safety Qualification Tests, including a full description of the tests carried out and
the results obtained, is documented in this section of the Technical Safety Report.
10589
The structure of the Technical Safety Report is illustrated in Figure 7.
10590
G.2
Generic Application Safety Case Guidance for E/E/PE
10591
G.2.1
10592
10593
The contents of this chapter may the structured following the same recommendation for a Generic
Product Safety Case.
10594
G.2.2
10595
10596
10597
Product Safety Case. The Section 3 (Effect of faults) may be not applicable or relevant, for safety
aspects, as treated within related Generic Products Safety Case/s.
10598
G.3
Specific Application Safety Case Guidance for E/E/PE
10599
G.3.1
10600
10601
Product Safety Case.
10602
G.3.2
10603
10604
10605
Product Safety Case. The Section 3 (Effect of faults) may be not applicable or relevant, for safety
aspects, as treated within related Generic Products Safety Case/s.
10606
10607
10608
The evidences provided within the Section 2.3 (Fulfilment of System Requirements Specification)
and Section 2.4 (Fulfilment of Safety Requirements Specification) should be given separately for
the two parts of the Specific Application Safety Case:
10609
10610
10611
10612
10613
Application Design Part: analyses and reports produced as part of the activities carried out
during the Design and Implementation phase of the E/E/PE system.
Physical Implementation Part: analyses and reports produced as part of the activities carried
out during the Manufacturing, System Integration and System Validation of the E/E/PE
system.
10614
G.4
Cross-Acceptance Safety Case Guidance for E/E/PE
10615
G.4.1
Cross-Acceptance Process
10616
10617
10618
10619
A structured and risk based framework for cross-acceptance of product, system or process is
developed in this guidance comprising seven core principles. The principles are universal and are
particularly pertinent to safety critical systems where no systematic and efficient framework for their
adoption and application in new applications or environments exists.
10620
G.4.2
10621
10622
The cross-acceptance of a product, system or process is implicitly founded on a number of key

assumptions and conditions namely
10623
10624
the product, system or process has been specified, designed and developed by a competent,
capable and reputable organisation,
The Basic Premise
prEN 50126-4
- 154 -
10625
10626
10627
the product, system or process has been scrutinised, analysed and assessed through a rigorous
process to assure its relevant safety, environmental and technical performance and this process
has been documented at an appropriate level of detail,
10628
10629
the product, system or process has been evaluated for its compliance with regulatory
requirements and best practice standards and codes of practice,
10630
10631
10632
the assessment has been peer reviewed and the product, system or process approved or
certified by a relevant competent body or authority in its native environment implying tolerability
of its risks subject to specified constraints and controls,
10633
10634
the product, system or process has preferably got a demonstrable record of adequate
verification, validation and testing or trouble free operation in its native environment,
10635
10636
the product, system or process has potential for a wider scope of application beyond its initial
native environment either in its original state, or through small-scale redesign and adaptation,
10637
10638
there is a perceived or real safety or environmental benefit or need in adapting the product,
system or process for use in new (target) environments,
10639
10640
there is an implicit or explicit record of the above conditions and assumptions which can be made
available to relevant third parties as deemed appropriate.
10641
10642
Even though not always stated, these conditions and assumptions are required or perceived to hold
true for the purpose of cross-acceptance.
10643
G.4.3
10644
10645
The framework for systematic cross-acceptance developed and proposed here essentially comprises
7 key principles as detailed below.
Principles of Cross-Acceptance
10646
a)
Establish a credible case for the native (baseline) application
10647
b)
Specify the target environment and application
10648
c)
Identify the key differences between the target and native cases
10649
10650
d)
Specify the technical, operational and procedural adaptations required

to cater for the differences
10651
e)
Assess the risks arising from the differences
10652
10653
f)
Produce a credible case for the adaptations adequately controlling the

risks arising from the differences
10654
g)
Develop a generic or specific cross-acceptance case
10655
a)
Establish a credible case for the native (baseline) application
10656
10657
10658
10659
Cross-acceptance is broadly applicable to generic product/system/process and generic

application cases. In this spirit, specific applications require further scrutiny and justification.
Cross-acceptance is essentially a differential case and requires a credible native (baseline) and a
target environment and associated arguments for safety.
10660
10661
To construct a baseline, the product, system or process shall be specified and

documented in its native environment including (whenever applicable)
10662
10663
a record of technical, operational, environmental, quality and safety performance

requirements including applicable rules and standards,
10664
10665
specification or description of relevant operational environment, scope, boundary

and interfaces,
10666
10667
description of the system architecture and composition including rules &

procedures, people and competence issues and automation aspects,
- 155 -
prEN 50126-4
10668
description of the operational, maintenance and retrofit processes,
10669
10670
description of the operational scenarios under normal, degraded and failed

modes of the system,
10671
description of emergency response arrangements and procedures.
10672
Justification of the baseline case in the native application comprising
10673
10674
evidence based on analysis, simulation, testing, verification and validation of core

safety functions,
10675
evidence of in service performance,
10676
evaluation of hazard log and incident reports,
10677
user and operator interviews,
10678
maintenance records,
10679
integrity and quality metrics and statistics,
10680
reference standards, licences and certificates.
10681
10682
The above evidence should be embodied within the cross-acceptance safety case.
b)
Specify the target environment and application
10683
10684
To construct a systematic view of the target application, the product, system or process shall be
specified and documented in the new environment including
10685
10686
a document addressing technical, operational, environmental, quality and safety

performance requirements,
10687
10688
specification of operational environment, scope, boundary and interfaces in the target

application,
10689
10690
description of the system architecture and composition including applicable rules &
procedures, people and competence issues and automation aspects,
10691
10692
description of the operational, maintenance and retrofit processes in the new

environment,
10693
10694
description of the operational scenarios under; normal, degraded and failed modes of
the
system in the new environment,
10695
specification of the emergency response strategy and processes.
10696
c)
Identify the key differences between the target and native cases
10697
10698
Identification of the differences between the native and target applications including significant
changes in
10699
technical, operational, environmental, quality and safety performance requirements,
10700
scope, boundary, operational environment and interfaces,
10701
10702
system architecture and composition including rules & procedures, people and
competence issues and automation aspects,
10703
operation, maintenance and retrofit processes,
10704
operational scenarios under normal, degraded and failed modes of the system,
10705
emergency arrangements.
prEN 50126-4
10706
d)
- 156 -
Specify the technical, operational and procedural adaptations
10707
10708
Identification of the adaptations required to cater for the differences between the native and
target applications including
10709
10710
identification of the scope and boundary of the invariant aspects of the system
(similarities),
10711
10712
technical, procedural or operational changes to the product, system or process to

address the demands of the target environment,
10713
establishing the feasibility and viability of such adaptations,
10714
communicating the scope and extent of required adaptations with all stakeholders.
10715
e)
Assess the risks arising from the differences
10716
10717
Identify the hazards and assess the risks arising from differences between the native and target
applications including
10718
10719
assessment of risks arising from the differences in technical, operational,

environmental adaptation of the product, system or process for target application,
10720
verification and validation of the assumptions and evidence,
10721
10722
identification of all additional measures which could mitigate and reduce the risks
further including estimates for their potential impact.
10723
10724
f)
Produce a credible case for the adaptations adequately controlling the risks arising from
the differences
10725
10726
Ensure the adaptations have resulted in the reduction and control of the risks to a target level
namely:
10727
justification of the adaptation strategy (technical, procedural, compliance etc.),
10728
evaluation of the impact of the adaptations in risk reduction,
10729
explanation of the rationale and Justification of the efficacy of the adopted measures,
10730
10731
determination of residual risk after adaptations and demonstration of compliance with

best practice standards and legal framework.
10732
g)
Develop a generic or specific cross-acceptance safety case
10733
10734
This involves developing a generic or specific application safety case and an appropriate safety
management system for the implementation/deployment in the target environment.
10735
10736
In the spirit of a risk based systemic framework, the scope and depth of application and
compliance with each principle should be commensurate with the scale of perceived risks.
10737
- 157 -
prEN 50126-4
Annex H
(informative)
Bibliography of techniques
10738
10739
10740
10741
10742
H.1
Introduction
10743
10744
10745
10746
10747
This informative annex provides a set of descriptions of techniques ranked relevant to the scope and
compliance with the other parts of this standard. The descriptions are intended to serve as hints for
readers which are not familiar with particular techniques employed in the safety analysis and
assurance of electronic systems. However, more detailed information should be gathered from other
sources which are given where appropriate.
10748
There is no claim to completeness of this annex.
10749
H.1.1
10750
10751
10752
10753
10754
This introduction provides an overview of the general characteristics of the techniques. The main goal
is to gain a uniform representation of the techniques properties in a tabular form. The conception of
this kind of presentation is based on VDI/VDE 3681:2005 (Classification and evaluation of description
methods in automation and control technology). With the tabular representation of data the following
is achieved:
10755
Classification of techniques in means of description and methods;
10756
Description of the main attributes of a technique;
10757
Assignment of a technique to development phases.
10758
H.1.2
10759
10760
The demand for a well-arranged and traceable concept of the annex arises from the idea to give a
structured overview on existing techniques used in railway applications.
10761
10762
10763
10764
10765
Due to this demand the annex utilises one clearly arranged table to outline the techniques properties.
The lines of this table consist of the entire list of techniques, described in the main part of the annex.
In this structured list some specific techniques are grouped to a generic class of techniques. The
columns are classified in three parts described in the following sub-clause s. The degree of matching
according individual classification criteria is represented by appropriate symbols defined in the table.
10766
H.1.2.1 Technique Means of Description or Method
10767
10768
In the first part of the table it is distinguished whether a technique is a means of description, a method
or both.
10769
10770
10771
10772
10773
10774
A means of description describes determined facts (approaches, task specification, solutions etc.) in a
graphical way for visual perception and storage. Means of description are made up of symbols (e. g.
alphanumeric characters, graphical elements or other representative elements), as well as
conventions concerning their combination (syntax). The individual representative elements, their
combinations and their categorisation are classified in a technical, more or less explicitly and formally
specified context according to certain conditions, concepts or rules for reasoning (semantics).
10775
10776
A method in contrast is a systematic, on a regulating system based, procedure to obtain knowledge or

practical results.
10777
10778
Considering the fact, that some techniques may have elements of both, means of description and
method, in this context the term of an integrated method is applied.
Aim
Structure
prEN 50126-4
- 158 -
10779
10780
To categorise a technique as a means of description, as a method or as both the following questions

can be helpful:
10781
10782
Is the technique used to formulate/describe a problem/system etc.?

Means of Description
10783
10784
Does the technique represent a way to solve a problem according to a plan?

Method
10785
10786
10787
10788
If both these questions can be answered positively, we can assume the regarded techniques have
fractions of a means of description and a method; these techniques can be classified as integrated
methods. The resulting classification is shown in the column MoD/M (Means of Description / Method)
of Table H.1.
10789
H.1.2.2 Technique Main attributes
10790
10791
In the second part the techniques are analysed with respect to a list of fundamental structuring
attributes, which can be checked using the following auxiliary questions based on VDI/VDE 3681:
10792
10793
Formal basis: Does the technique have a mathematical basis and a completely defined syntax as
well as a clear semantic interpretation?
10794
10795
Description of behaviour: Can the technique be used to describe the dynamic behaviour of a
system?
10796
10797
Description of structure: Can the technique be used to describe the systems structure (e. g.
hierarchy, composition/decomposition) and/or structural modifications?
10798
Required expertise: Is a higher degree of expertise required to use this technique?
10799
10800
Level of standardisation: Are there any standards or assured guidelines describing how to use
the technique?
10801
10802
Level of acceptance and customariness: Is the technique commonly accepted and used in the
railway sector?
10803
10804
Explicit time representation: Does the technique empower the user to model quantitative
statements about instants and time periods (e. g. between events)?
10805
10806
Description of process interaction: Can the technique be used to describe synchronous,

asynchronous or concurrent processes?
10807
10808
The column Criteria of Table H.1 gives an overview on the property based classification of the
techniques contained in the describing sub-clause s H.2.1 to H.2.35.
10809
H.1.2.3
10810
10811
10812
The last differentiating factor chosen to categorise the diverse techniques is the development phase
the technique can be used in. To accord the structure of the normative chapters of part 4 the following
phases are differentiated:
10813
Requirements (specification) phase;
10814
Architecture phase;
10815
Design phase;
10816
Implementation and Testing phase;
10817
Integration phase;
10818
Manufacturing phase;
Technique Development phases
- 159 -
prEN 50126-4
10819
Installation and Commissioning phase;
10820
Final acceptance phase.
10821
10822
The resulting classification of the techniques according to development phases is shown in the
column Phase of Table H.1.
prEN 50126-4
- 160 -
10823
Cause Consequence Diagrams
Checklists
Configuration Management
Decision Tables / Truth Tables
Design
Analysis
Design
Constraint
Analysis
Design
Interface
Analysis
Design Logic
Analysis
Domain Specific Languages
+
+
+
+
Final acceptance
Installation and
Commissioning
Manufacturing
Integration
Implementation and
Testing
Requirements
specification
Description of process
interaction
Explicit time
representation
0
+
Level of acceptance
and customariness
Level of
standardisation
Required expertise
Description of
structure
Description of
behaviour
+
Design
c)
Phase
Architecture
b)
Criteria
Formal basis
Technique
a)
Method (M)
(MoD)
MoD/M
prEN 50126-4
Event Tree Analysis
10
11
12
13
Final acceptance
Fault Isolation Methodology
Model Checking
Temporal Logic
Theorem
Proving
Graceful Degradation
+
+
+
0
Installation and
Commissioning
Fault Detection and Diagnosis
Higher Order
Logic
Formal
Proof
Manufacturing
Integration
Error Seeding
Design
Architecture
Requirements
specification
Error Guessing
interaction
Explicit time
representation
Phasec)
Level of acceptance
and customariness
Level of
standardisation
Error Detecting
and Correcting
Codes
Required expertise
Description of
structure
Formal basis
Error
Avoiding
Methods
Method (M)
Technique
b)
Criteria
Description of
behaviour
(MoD)
MoD/Ma)
Implementation and
Testing
- 161 -
- 162 -
14
15
16
17
Energy Trace
and Barrier
Analysis
Materials
Compatibility
Analysis
Impact Analysis / Change Analysis
Final acceptance
Installation and
Commissioning
Manufacturing
Integration
Design
Architecture
Requirements
specification
Electromagnetic
Compatibility
Analysis
interaction
Explicit time
representation
Implementation and
Testing
Phasec)
Level of acceptance
and customariness
Level of
standardisation
Bent Pin
Analysis / Cable
Failure Matrix
Analysis
Description of
structure
Formal basis
Hardware
Safety
Analysis
Method (M)
Technique
b)
Criteria
Description of
behaviour
(MoD)
MoD/Ma)
Required expertise
prEN 50126-4
Fagan
Inspection
Walkthrough /
Design Review
Interface
Inspections
Interface
prEN 50126-4
Final acceptance
Installation and
Commissioning
Design
Architecture
Requirements
specification
interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Required expertise
Description of
structure
Description of
behaviour
Manufacturing
Phasec)
Integration
b)
Criteria
Formal basis
Technique
Method (M)
(MoD)
MoD/Ma)
Implementation and
Testing
- 163 -
Analysis
Methods
2
Interface
Testing
18
Markov Models
19
Metrics
20
Modular Approach
21
Monte-Carlo Simulation
22
Operational Readiness Review
23
+
+
0
+
Performance
Modelling
Performance
Requirements
Performance
Engineering
24
Process Simulation
25
Prototyping / Animation
26
Recovery Block
+
+
- 164 -
27
Response Timing and Memory

Constraints
28
Retry Fault Recovery Mechanisms
29
Safety Bag
30
System
Safety
Analysis
Final acceptance
Installation and
Commissioning
Common
Cause Failure
Analysis
Contingency
Analysis
Critical Incident
Technique
Criticality
Analysis
Failure Modes
and Effects
(and Criticality)
Analysis
Manufacturing
Integration
Implementation and
Testing
Requirements
specification
interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Description of
structure
Description of
behaviour
+
Design
Phasec)
Architecture
b)
Criteria
Formal basis
Technique
Method (M)
(MoD)
MoD/Ma)
Required expertise
prEN 50126-4
Technique
6
Fault Hazard
Analysis
7
Fault Tree
Analysis
8
Hazard and
Operability
Study
9
Operating and
Support Hazard
Analysis
10
Preliminary
Hazard
Analysis
11
Reliability Block
Diagram
12
Repetitive
Failure Analysis
0
0
13
Root Cause
Analysis
0
0
+
+
+
+
Design
Architecture
+
0
+
+
+
+
0
0
+
+
+
+
+
+
+
+
+
+
0
0
+
+
+
+
+
+
+
+
+
+
+
0
+
+
+
+
+
+
+
+
+
+
0
+
0
+
+
+
+
+
+
+
+
Final acceptance
Installation and
Commissioning
Manufacturing
b)
Integration
Criteria
Implementation and
Testing
Requirements
specification
interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
MoD/Ma)
Required expertise
Description of
structure
Description of
behaviour
Formal basis
Method (M)
(MoD)
- 165 prEN 50126-4
Phasec)
- 166 -
31
Testing
Sneak Circuit
Analysis
Model Based
Testing
Stress-Testing
Test Oracle
33
Traceability
0
+
Final acceptance
Installation and
Commissioning
Manufacturing
Integration
Implementation and
Testing
Requirements
specification
interaction
Design
15
Architecture
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Time Petri Nets
Trusted
Components
Description of
structure
32
34
Description of
behaviour
Single Point
Failure Analysis
Phasec)
14
b)
Criteria
Formal basis
Technique
Method (M)
(MoD)
MoD/Ma)
Required expertise
prEN 50126-4
+
+
+
+
Certified Tools
and Certified
Translators
Library of
Trusted/Verified
Components
Tools proven in
H
2
35
Design
0
+
+
0
+
+
+
+
+
+
0
2
Component
Diagram
0
+
+
0
+
+
+
+
+
+
0
3
Sequence
Diagram
0
+
+
0
+
+
+
+
0
+
0
0
4
State Chart
Diagram
0
+
+
0
+
+
+
+
0
+
0
0
Design
Technique
Architecture
Unified
Modelling
Language
Class Diagram
Architecture
use
MoD/Ma)
Criteriab)
Phasec)
Final acceptance
Installation and
Commissioning
Manufacturing
Integration
Final acceptance
Installation and
Commissioning
Manufacturing
Integration
b)
Implementation and
Testing
Requirements
specification
interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Criteria
Implementation and
Testing
Requirements
specification
Description of
process interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Required expertise
Description of
structure
Description of
behaviour
Formal basis
Method (M)
MoD/Ma)
Required expertise
Description of
structure
Description of
behaviour
Formal basis
Method (M)
(MoD)
Technique
(MoD)
- 167 prEN 50126-4
Phasec)
- 168 -
An declares the techniques belonging to the respective column, otherwise is shown.
b)
+: The technique fulfils the respective criteria in full.

0: The technique fulfils the respective criteria partially.
: The technique does not fulfil the respective criteria at all.
c)
+: The technique can be used in this phase.

0: The technique can be used in this phase to some extent.
: The technique cannot be used in this phase.
10824
10825
Table H.1- Properties of techniques
Final acceptance
Installation and
Commissioning
Manufacturing
Design
Architecture
Requirements
specification
interaction
Explicit time
representation
Level of acceptance
and customariness
Level of
standardisation
Description of
structure
Description of
behaviour
a)
Integration
Phasec)
Implementation and
Testing
b)
Criteria
Formal basis
Method (M)
Technique
(MoD)
MoD/Ma)
Required expertise
prEN 50126-4
- 169 -
prEN 50126-4
10826
H.1.3
Description Structure of a Technique
10827
The structure used by describing the techniques in H.2.1 to H.2.35 consists of following items:
10828
Aim: For each technique a brief explanation of the aim is given.
10829
Description: The techniques description covers the following information about the technique:
10830
10831
Syntax / Semantics: For example, when the technique is based on some (graphical)
symbols, these are introduced concisely.
10832
Input / Output: Specification of the input and the output of each technique is provided.
10833
Fundamental properties: Major characteristics of the technique are outlined.
10834
Relations to other techniques: When available, relations to other techniques are outlined.
10835
10836
Typical applications and constraints: Typical applications and when available, constraints of the
techniques application are outlined.
10837
10838
References: References to sources for gathering more detailed information about the technique
are classified in the following way:
10839
Up-to-date references appear unmarked in the list of references.
10840
References to the classics, origins, of the technique are marked with *.
10841
References to other standards are marked with **.
10842
H.1.4
Application Guidelines
10843
10844
There are two types of information that can be gained with respect to a specific technique in this
annex:
10845
Explicit: the description of the technique (H.2.1 - H.2.35);
10846
Implicit: the information about the technique taken from table H.1. That is:
10847
Is the technique a matter of means of description or of a method (MoD/M) or of both?
10848
What are the main attributes (criteria) of the technique?
10849
In which development phase can the technique be applied?
10850
H.1.5
Reference
10851
10852
VDI/VDE 3681:2005: Classification and evaluation of description methods in automation and control
technology
10853
10854
10855
H.2
Techniques
10856
H.2.1
Cause Consequence Diagrams (CCD)
10857
Aim
10858
10859
To model, in a diagrammatic form, the sequence of events resulting from the occurrence of an
initiating event.
prEN 50126-4
- 170 -
10860
Description
10861
10862
Cause Consequence Diagrams combine causes and consequences of initial events, resulting in a
structured model with many different possible outcomes.
10863
CCD are made up of the following main components/symbols:
10864
10865
Initiating event box: Represents an independent event that can initiate a sequence of events
leading to a consequence;
10866
10867
Intermediate event: Represents the functionality of a (sub-)system; the function is either

successful or it fails;
10868
Consequence box: Represents the outcome of a sequence of events;
10869
Time delay box: Represents a time delay that must take place;
10870
10871
OR- and AND-gate: Represent a logical combination of initiating events and/or intermediate
events.
10872
10873
The graph also can contain vertex symbols which describe the conditions for propagation along
different branches from the vertex.
10874
10875
10876
10877
Starting from a critical event (input), a cause consequence graph is traced backwards and forwards.
In the backwards direction it is equivalent to a fault tree with the critical event as the given top event.
In the forward direction the possible consequences arising from an event are identified. The diagrams
can be used to compute the probability of occurrence of certain critical consequences (output).
10878
10879
CCD can be interpreted as a combination of Fault Tree Analysis (H.2.30.7) and Event Tree Analysis
(H.2.9).
10880
Typical applications and constraints
10881
10882
CCD can be applied to a system very early in design development and thereby identify safety issues
early in the design process.
10883
10884
A CCD can only have one initiating event; therefore, multiple Cause Consequence Analysis (CCA) will
be required to evaluate the consequence of multiple initiating events.
10885
References
10886
10887
10888
Andrews, J. D. and Ridley, L. M.: Application of the Cause-Consequence Diagram Method to Static
Systems, Reliability Engineering and System Safety, 75(1), Elsevier, 2002.
ISSN 0951-8320
10889
10890
Andrews, J. D. and Ridley, L. M.: Reliability of Sequential Systems Using the Cause-Consequence
Diagram Method, Proc Instit. Mech. Eng., 215 (Part E): 207-220, 2001.
10891
10892
Ericson, C. A.: Hazard Analysis Techniques for System Safety, John Wiley & Sons, 2005. ISBN 9780-471-72019-5
10893
10894
Leveson, N. G.: Safeware: System Safety and Computers, Addison-Wesley, 1995.

ISBN 978-0-201-11972-5
10895
10896
H.2.2
Checklists
10897
Aim
10898
10899
To provide a stimulus to critical appraisal of all aspects of the system rather than to lay down specific
requirements.
- 171 -
prEN 50126-4
10900
Description
10901
10902
10903
10904
10905
10906
Checklist consists of a set of questions (input) to be completed by the person performing the
checklist. The object in completing a checklist is to be as concise as possible. When extensive
justification is necessary this should be done by reference to additional documentation. Pass, Fail and
Inconclusive, or some similar restricted set of tokens should be used to record the results for each
question (output). This conciseness greatly simplifies the process of reaching an overall conclusion as
to the results of the checklist assessment.
10907
10908
Particularly important classes of checklists are those developed for hazard identification and analysis
techniques like FMEA (H.2.30.5) and HAZOP (see H.2.30.8).
10909
10910
10911
10912
10913
10914
10915
Checklists have a wide scope of application. It should be clear that their use depends critically on the
expertise and judgment of the engineer selecting and applying the checklist. As a result the decisions
taken by the engineer, with regard to the checklist(s) selected, and any additional or superfluous
questions, should be fully documented and justified. The objective is to ensure that the application of
the checklists can be reviewed and that the same results will be achieved unless different criteria are
used.
10916
References
10917
10918
10919
** ISO/IEC 18019: Software and system engineering Guidelines for the design and preparation of
user documentation for application software, Standards Australia & New Zealand, 2007. ISBN 978-07337-7976-3
10920
10921
10922
Selby, R. W.: Software Engineering: Barry W. Boehm's Lifetime Contributions to Software

Development, Management, and Research; John Wiley & Sons, 2007.
ISBN 978-0-470-14873-0
10923
10924
Myers, G. J., Badgett, T. and Sandler, C.: The Art of Software Testing; John Wiley & Sons, 2012.
ISBN 978-1-118-03196-4
10925
Perry, W. E.: Effective Methods for Software Testing, Wiley, 2006. ISBN 978-0-7645-9837-1
10926
10927
H.2.3
10928
Aim
10929
10930
To ensure the group consistency of hardware and software development deliverables as those
deliverables change.
10931
Description
10932
10933
10934
10935
10936
10937
Configuration Management is a technique used throughout development. In essence, it requires the

recording of the production of every version of every "significant" deliverable and of every relationship
between different versions of the different deliverables (input). The resulting records allow the
designer to determine the effect on other deliverables of a change to one deliverable (especially on of
its components) (output). In particular, systems or subsystems can be reliably re-built from consistent
sets of component versions.
10938
10939
10940
References
10941
Babich, W. A.: Software Configuration Management, Addison-Wesley, 1986.
Configuration Management (CM)
prEN 50126-4
- 172 -
10942
10943
Tichy, W. F.: Software Configuration Management, IEEE Computer Society Press, Tutorial notes of
the ICSE, May 1989.
10944
10945
Estublier, J.: Software Configuration Management: A Roadmap, in A. Finkelstein (ed.), The Future of
Software Engineering, ACM Press, 2000.
10946
Ben-Menachem, M.: Software Configuration Management Guidebook, McGraw-Hill, 1995.
10947
Buckley, F. J.: Implementing Configuration Management, IEEE Computer Society Press, 1993.
10948
10949
H.2.4
10950
Aim
10951
10952
To provide a clear and coherent specification and analysis of complex logical combinations and
relationships.
10953
Description
10954
10955
10956
These related methods use project records (input) to form two dimensional tables (output). Truth
Tables concisely describe logical relationships between Boolean program variables. Decision Tables
associate conditions with actions to perform.
10957
10958
10959
The conciseness and tabular nature of both methods make them appropriate as a means of analysing
complex logical combinations expressed in code. Both methods are potentially executable if used as
specifications.
10960
10961
Decision Tables can be used for test case design e. g. based on a Cause Consequence Diagram
(H.2.1).
10962
10963
10964
The technique is typically applied in the testing phase of a system development. Handling of tables is
complex by many conditions in the tables.
10965
References
10966
** DIN: Information interchange; decision table, description medium DIN 66241, 1979.
10967
10968
Hurley, R. B.: Decision Tables in Software Engineering, Van Nostrand Reinhold Co., 1984. ISBN 9780-442-23599-4
10969
10970
Ghezzi, C., Jazayeri, M. and Mandrioli, D.: Fundamentals of Software Engineering, Prentice Hall,
2003. ISBN 978-0-13-305699-0
Decision Tables / Truth Tables
10971
10972
H.2.5
10973
10974
10975
10976
Design Analysis commonly applies to software but also can be used to investigate systems of any
kind. It aims to ensure that is thought to often neglect areas of the system during system development
such as constraints, internal or external interactions, and the logic flow within the system. The
following techniques describe three DAs.
10977
Design Analysis (DA)
- 173 -
prEN 50126-4
10978
H.2.5.1 Design Constraint Analysis
10979
Aim
10980
10981
To evaluate restrictions imposed by requirements, the real world and environmental limitations, as
well as by the design solution.
10982
Description
10983
10984
10985
10986
The design materials (input) should describe all known or anticipated restrictions on a system
component. These restrictions may include those listed below. Design Constraint Analysis gives
constraints description of design documents (output) by evaluating the ability of the system to operate
within the constraints.
10987
Equations and algorithms limitations;
10988
Input and output data limitations (e. g., Range, resolution, accuracy);
10989
Design solution limitations;
10990
Sensor/actuator accuracy and calibration;
10991
Noise, EMI;
10992
Actuator power / energy capability (motors, heaters, pumps, mechanisms, rockets, valves, etc.);
10993
Capability of energy storage devices (e. g., Batteries, propellant supplies);
10994
Human factors, human capabilities and limitations;
10995
Physical time constraints and response times;
10996
Off nominal environments (fail safe response);
10997
Friction, inertia, backlash in mechanical systems;
10998
Validity of models and control laws versus actual system behaviour;
10999
11000
11001
Accommodations for changes of system behaviour over time: wear-in, hardware wear-out, end of
life performance versus beginning of life performance degraded system behaviour and
performance.
11002
Constraints of Application
11003
11004
References
11005
11006
U.S. Department of Transportation, Federal Aviation Administration (ed.): System Safety Handbook,
December 30, 2000: Clause H.5.4
11007
11008
H.2.5.2 Design Interface Analysis (DIA)
11009
Aim
11010
11011
To verify the proper design of a software component's interfaces with other components of the
system.
11012
Description
11013
11014
Design Interface Analysis verifies that control and data linkages between interfacing components
have been properly designed. Interface requirements specifications (input) are the sources against
prEN 50126-4
- 174 -
11015
11016
11017
11018
11019
which the interfaces are evaluated. Interface characteristics to be addressed should include data
encoding, error checking and synchronization. The analysis should consider the validity and
effectiveness of checksums and CRCs. The sophistication of error checking implemented should be
appropriate for the predicted bit error rate of the interface. An overall system error rate should be
defined, and budgeted to each interface.
11020
11021
11022
References
11023
11024
11025
11026
H.2.5.3 Design Logic Analysis (DLA)
11027
Aim
11028
To evaluate the equations, algorithms, and control logic of the system design.
11029
Description
11030
11031
11032
11033
11034
Design Logic Analysis examines the safety-critical areas of a system component. A technique for
identifying safety-critical areas is to examine each function performed by the system component. If it
responds to, or has the potential to violate one of the safety requirements, it should be considered
critical and undergo logic analysis. A technique for performing logic analysis is to analyse design
descriptions (input) and logic flows and note discrepancies.
11035
11036
11037
11038
11039
11040
The ultimate, fully rigorous DLA uses the application of Formal Methods (FM). Where FM is
inappropriate, because of its high cost versus software of low cost or low criticality, simpler DLA can
be used. Less formal DLA involves a human inspector reviewing a relatively small quantity of critical
software artefacts (e. g. PDL, prototype code), and manually tracing the logic. Safety critical logic to
be inspected can include failure detection/diagnosis; redundancy management, variable alarm limits,
and command inhibit logical preconditions.
11041
11042
11043
11044
Commercial automatic software source analysers can be used to augment this activity, but should not
be relied upon absolutely since they may suffer from deficiencies and errors, a common concern of
COTS tools and COTS in general.
11045
References
11046
11047
11048
11049
H.2.6
Domain Specific Languages (DSL)
11050
Aim
11051
To represent software programs and related artefacts in a language tailored to a particular domain.
11052
Description
11053
11054
11055
A Domain Specific Language is a programming, specification or modelling language created

specifically to solve problems in a particular application domain or problem domain. The language is
based on concepts and features relevant to this domain.
- 175 -
prEN 50126-4
11056
11057
11058
11059
11060
11061
11062
One of the important benefits of DSL is the possibility to represent and solve problems within a
particular domain (input) without the need for knowledge about general programming, specification or
modelling (e. g. UML, H.2.35). As a consequence, programs, specifications or models (output) can be
produced at a higher level, possibly by the end-user. By providing constructs tailored to this domain,
and possibly means for automated code generation, a DSL generally also increases the productivity
of the programmer and the quality of the resulting product. The code generation is typically
implemented as an application generator using the DSL as input.
11063
11064
11065
11066
DSLs are applied where domain experts should understand, validate, modify, and often even develop
DSL programs. The disadvantages of the use of DSL are the costs of designing, implementing and
maintaining a DSL, as well as the difficulty of finding the proper scope for a DSL.
11067
References
11068
11069
Kelly, S. and Tolvanen, J.-P.: Domain-Specific Modeling: Enabling Full Code Generation, John Wiley
& Sons, 2008. ISBN 978-0-470-03666-2
11070
11071
van Deursen, A., Klint, P. and Visser, J.: Domain-Specific Languages: An Annotated Bibliography,
ACM SIGPLAN Not., Vol. 35, No. 6, 2000. ISSN 0362-1340
11072
11073
H.2.7
11074
Aim
11075
To maintain system functionality despite an internal fault.
11076
Description
11077
11078
11079
11080
To apply dynamic reconfiguration the logical architecture of the system has to be such that it can be
mapped onto a subset of the available resources of the system. The architecture needs to be capable
of detecting a failure in a physical resource and then remapping the logical architecture back onto the
restricted resources left functioning.
11081
11082
11083
11084
11085
11086
A reconfigurable architecture consists of a large number of system elements connected by a

reconfigurable communication medium. In order to keep the system operational during a partial
failure, it is necessary to redistribute the system functions to the remaining system resources (output).
So, first, the failure has to be detected (input). Then the system must know the function of the failed
sub-component (input) and find a possible replacement component. The replacement component
must have the same communication connections as the failed one in order to undertake the task.
11087
11088
11089
Although traditionally applied to hardware, this technique is being developed for application also to
software and, thus, the total system. It must be considered at the first system design stage.
11090
References
11091
11092
Vaidyanathan, R. and Trahan, J. L.: Dynamic Reconfiguration Architectures and Algorithms; Kluwer
Academic, 2004. ISBN 0-306-48428-5
11093
11094
H.2.8
11095
11096
11097
Error Avoiding Methods are used to detect and remove or correct errors during the system
development. In addition, techniques exist which are able to verify a test case testing EAMs. Three
techniques are listed below.
11098
Error Avoiding Methods (EAM)
prEN 50126-4
- 176 -
11099
H.2.8.1 Error Detecting and Correcting Codes
11100
Aim
11101
To detect and correct errors during transmission of sensitive information.
11102
Description
11103
11104
For an information of n bits, a coded block of k bits is generated which enables errors to be detected
and corrected. There are included hamming, cyclic, and polynomial codes.
11105
11106
The input to the technique is the error rate and output is the improvement of transmission quality of
sensitive information.
11107
11108
11109
References
11110
11111
11112
H.2.8.2 Error Guessing
11113
Aim
11114
To remove common development errors.
11115
Description
11116
11117
Error Guessing uses the requirement specification or design documents (input) to revaluate system
errors (output).
11118
11119
11120
11121
11122
11123
11124
Testing experience and intuition combined with knowledge and curiosity about the system under test
may add some uncategorised test cases to the designed test case set. Special values or
combinations of values may be error-prone. Some interesting test cases may be derived from
inspection checklists. It may also be considered whether the system is robust enough. Can the
buttons be pushed on the front-panel too fast or too often? What happens if two buttons are pushed
simultaneously? This means, the experience of the tester is used to anticipate what defects might be
present in the component or system under test.
11125
11126
11127
References
11128
11129
11130
H.2.8.3 Error Seeding
11131
Aim
11132
To ascertain whether a set of test cases is adequate.
11133
Description
11134
11135
Some known error types are inserted in the program (input), and the program is executed with the test
cases (input) under test conditions. If only some of the seeded errors are found, the test case set is
- 177 -
prEN 50126-4
11136
11137
11138
not adequate. The ratio of found seeded errors to the total number of seeded errors is an estimate of
the ratio of found real errors to total number errors. This gives a possibility of estimating the number of
remaining errors and thereby the remaining test effort.
11139
11140
The detection of all the seeded errors may indicate either that the test case set is adequate, or that
the seeded errors were too easy to find (output).
11141
11142
11143
The limitations of the method are that in order, to obtain any usable results, the error types as well as
the seeding positions must reflect the statistical distribution of real errors.
11144
References
11145
11146
11147
H.2.9
11148
Aim
11149
11150
To model, in a diagrammatic form, the sequence of events that can develop in a system after an
initiating event, and thereby indicate how serious consequences can be.
11151
Description
11152
11153
11154
11155
11156
Event Tree Analysis is based on a diagram where an initiating event is connected with all possible
pivotal events that may arise out of the initiating event. Normally every event has one success (yes)
branch and one failure (no) branch afflicted with probability of occurrence leading to another event.
There can be also more branches coming out of an event. The connected events build up paths each
leading in the final step of the ETA to an accident scenario.
11157
11158
11159
11160
Assigning a probability of occurrence to the branches, allows multiplying these for each path and
making a statement regarding the accident scenarios probability for the particular path (output). But
therefore the design of the system and the accident histories on similar equipment must be known
(input).
11161
11162
11163
11164
A disadvantage of ETA is that they tend to get quite large, but they can be reduced by eliminating
sequences. By ETA it is difficult to distinguish the essential events from those to which functional and
operational relationships are illogical or meaningless.
11165
References
11166
11167
Ericson, C. A.: Hazard Analysis Techniques for System Safety; John Wiley & Sons, 2005. ISBN 9780-471-72019-5
11168
11169

ISBN 978-0-201-11972-5
11170
11171
** IEC 62502;
VDE 0050-3:2008-08:
Ereignisbaumanalyse; Beuth 2008.
11172
Event Tree Analysis (ETA)
Verfahren
zur
Analyse
der
Zuverlssigkeit
prEN 50126-4
- 178 -
11173
H.2.10
Fault Detection and Diagnosis
11174
Aim
11175
11176
11177
To detect faults in a system, which might lead to a failure, thus providing the basis for
countermeasures in order to minimise the consequences of failures and to detect the causes that
explain the detected faults.
11178
Description
11179
11180
11181
11182
Fault detection is the process of checking a system (input) for erroneous states (which are caused by
a fault within the (sub)system to be checked). The primary goal of fault detection is to inhibit the effect
of wrong results. A system which delivers either correct results, or no results at all, is called "selfchecking".
11183
11184
11185
11186
11187
Fault detection is based on the principles of redundancy (mainly to detect hardware faults output)
and diversity (software faults output). Some sort of voting is needed to decide on the correctness of
results. Special methods applicable are assertion programming, N-version programming and the
safety bag technique and on hardware level by introducing sensors, control loops, error checking
codes, etc.
11188
11189
11190
11191
Fault detection may be achieved by checks in the value domain or in the time domain on different
levels, especially on the physical (temperature, voltage etc.), logical (error detecting codes), functional
(assertions) or external level (plausibility checks). The results of these checks may be stored and
associated with the data affected to allow failure tracking.
11192
11193
11194
Complex systems are composed of subsystems. The efficiency of fault detection, diagnosis and fault
compensation depends on the complexity of the interactions among the subsystems, which influences
the propagation of faults.
11195
11196
Fault diagnosis bases on the fault detection. After a fault (input) has been detected, the corresponding
fault causes (output) are to be diagnosed. The effects of causes are the faults that are detected.
11197
11198
11199
References
11200
11201
Dependability of Critical Computer Systems Vol. 1; F. H. Redmill, Elsevier Applied Science, 1988.
ISBN 1-85166-203-0
11202
11203
H.2.11
Fault Isolation Methodology
11204
Aim
11205
To locate faults in large-scale systems.
11206
Description
11207
11208
Having a system or a system description (input) the technique detects causes that lead to faults
(output).
11209
11210
11211
There are various examples of specific methods: Half-Step Search, Sequential

Removal/Replacement, Mass Replacement, and Lambda Search, and Point of Maximum Signal
Concentration.
11212
11213
- 179 -
prEN 50126-4
11214
References
11215
11216
Stephans, R. A. and Talso, W. W.: System Safety Analysis Handbook A Source Book for Safety
Practitioners. Unionville/Virginia, U.S.A.: System Safety Society, 2nd Edition, 1997.
11217
11218
December 30, 2000: Chapter 9, Table 9-1
11219
11220
H.2.12
Formal Proof
11221
11222
11223
11224
11225
11226
11227
11228
Formal methods employ techniques from mathematical logic and discrete mathematics for
description, specification and construction of systems. Commonly based on mathematical logic,
formal methods allow to write down the behaviour of the system under consideration and to express
properties about the system. This requires addressing all assumptions explicitly and allows to raw all
conclusions within the logic framework. The ability to prove certain properties of the system is central
to any operation regarding formal methods. Examples for such proof tasks are to prove liveliness or
safety properties or to show that the formal parameters of a procedure match with the actual given
ones. Several techniques related to formal proof are described in the following sub-clauses.
11229
11230
H.2.12.1
Higher Order Logic (HOL)
11231
Aim
11232
To express system requirements used for specification or verification.
11233
Description
11234
11235
11236
11237
11238
Higher Order Logic refers to a particular logic notation and its machine support system. The logic
notation is mostly taken from Church's Simple Theory of types and the machine support system is
based upon the LCF (Logic of Computable Functions) system. In HOL the standard predicate calculus
is extended by allowing variables to range over functions. The arguments of functions can themselves
be functions.
11239
11240
Having a precise knowledge of the system (input) a formal specification of the system (output) can be
expressed using HOL.
11241
11242
11243
References
11244
11245
Nesi M.: A Formalization of the Process Algebra CCS in High Order Logic. Technical Report, no. 278,
University of Cambridge.
11246
11247
H.2.12.2
Model Checking
11248
Aim
11249
To verify a behavioural property of a finite state concurrent system.
11250
Description
11251
11252
The result of applying model checking to a system (input) and a desired property (input) is the answer
to the question whether the property is satisfied in the system or not (output).
11253
Applying model checking consists of following tasks:
prEN 50126-4
- 180 -
11254
11255
Modelling: The first task is to represent the system into a formalism (system model) accepted by
a model checker;
11256
Specification: Before verification, it is necessary to state the given property as a logic formula;
11257
11258
11259
11260
11261
Verification: Checking whether the model satisfies the formula is completely automatic. In case of
negative result, the user is provided with an error trace. This can be used as a counterexample
for the checked property and can help the user in tracking down where the error occurred.
Analysing the error trace may require the modification of the model and reapplication of the
model checking algorithm.
11262
11263
11264
By model checking the desired property is common expressed in a Temporal Logic (H.2.12.3). The
model of the system corresponds to a finite state machine (see State Chart Diagram in H.2.35.4).
Compared to model checking, Theorem Proving (H.2.12.4) can be used for verifying infinite systems.
11265
11266
11267
11268
11269
Model checking is a verification technique. Its main disadvantage is the state explosion. This problem
occurs by systems with many components that can interact with each other or systems that have data
structures that can assume many different values. In such cases the number of global states can be
enormous.
11270
References
11271
11272
Baier, C. and Katoen, J.-P.: Principles of Model Checking, MIT Press, 2008.
ISBN 978-0-262-02649-9
11273
11274
Clarke, E. M., Grumberg, O. and Peled, D. A.: Model Checking, MIT Press, 1999.
ISBN 978-0-262-03270-4
11275
11276
* McMillan, K.: Symbolic Model Checking, Kluwer Academic Publishers, 1993.

ISBN 978-0-7923-9380-1
11277
11278
H.2.12.3
Temporal Logic (TL)
11279
Aim
11280
To express safety and operational system requirements.
11281
Description
11282
11283
Comparing to propositional or predicate logic Temporal Logic contains temporal operators like next
time, eventually (in the future), always (globally), until, and so on.
11284
By means of TL system properties (input) can be expressed as logic formulas (output).
11285
11286
11287
The idea of temporal logic is that a formula is not statically true or false in a model, as it is in
propositional or predicate logic. Instead, temporal formulas are interpreted on sequences of states
(behaviours) and a formula can be true in some states of the model and false in others.
11288
11289
Temporal logic is used by model checking (H.2.12.2) to state the property to be proven as a logic
formula.
11290
11291
11292
11293
Typical application of temporal logic is the expression of properties proved by a verification method.
Quantified time intervals and constraints are not handled explicitly in temporal logic. Absolute timing
has to be handled by creating additional time states as part of the state definition.
11294
References
- 181 -
prEN 50126-4
11295
11296
Baier, C. and Katoen, J.-P.: Principles of Model Checking, MIT Press, 2008.
ISBN 978-0-262-02649-9
11297
11298
Clarke, E. M., Grumberg, O. and Peled, D. A.: Model Checking, MIT Press, 1999.
ISBN 978-0-262-03270-4
11299
11300
Huth, M. and Ryan, M.: Logic in Computer Science: Modelling and Reasoning about Systems,
Cambridge University Press, 2004. ISBN 978-0-521-54310-1
11301
11302
Krger, F. and Merz, S.: Temporal Logic and State Systems, Springer, 2008.
ISBN 978-3-540-67401-6
11303
11304
H.2.12.4
Theorem Proving
11305
Aim
11306
To verify systems properties.
11307
Description
11308
11309
11310
A formal system consists of a formal language, statements of that language which are taken as given
(axioms) and a set of inference rules or other means of deriving further statements (called theorems).
A proof is a series of transformations according to the inference rules.
11311
11312
11313
11314
Theorem Proving is applied to a system (input) and a property (input) to give the answer to the
question whether the property is satisfied in the system or not (output). To do that, a formal system of
the considered system and representation of a property as a formula are to be provided. Then, the
theorem prover attempts to find a proof by repeatedly applying the inference rules.
11315
Typical Application and Constraints
11316
11317
11318
11319
11320
11321
Typical application of theorem proving is systems verification. In contrast to model checking, theorem
proving can be applied to infinite systems. On the other hand, in a case of a negative result, the user
is not provided with a counterexample, that can help in tracking down where the error occurred. The
complex theoretical background of theorem proving, demands a high expertise level of the user.
Another disadvantage of the method is that in contrast to fully automated process of model checking,
an interaction between the user and the theorem prover is required.
11322
References
11323
11324
Ait Mohamed, O., Munoz, C. and Tahar, S.: Theorem Proving in Higher Order Logic: 21 International
Conference, Springer, 2008. ISBN 978-3-540-71065-3
11325
11326
Schumann, J. M.: Automated Theorem Proving in Software Engineering, Springer, 2001. ISBN 978-3540-67989-9
11327
11328
Nipkow, T., Wenzel, M. and Paulson, L. C.: Isabelle/HOL: A Proof Assistant for Higher-Order Logic,
Springer, 2002. ISBN 978-3-540-43376-7
11329
11330
Bertot, Y. and Castran, P.: Interactive Theorem Proving and Program Development: CoqArt: The
Calculus of Inductive Constructions, Springer, 2004. ISBN 978-3-540-20854-9
st
11331
11332
H.2.13
Graceful Degradation (GD)
11333
Aim
11334
11335
To maintain the more critical functions during a partial failure of the system by dropping the less
critical functions.
prEN 50126-4
- 182 -
11336
Description
11337
11338
11339
11340
11341
The effect of the Graceful Degradation is similar to the effects caused by redundancy systems, but
without needing replications. This is achieved by removing the system part damaged by the error
(input) and allowing the unaffected part to continue execution. The execution is possible as long as no
basic function is interrupted. That means that the system structure had to be constructed in a way
which allows redistribution of encumbrances within the system.
11342
11343
11344
GD is implemented in a variety of domains of image processing and telecommunications to shared

memory multiprocessors and multi-modular memory systems.
11345
References
11346
11347
11348
H.2.14
Hardware Safety Analysis
11349
11350
11351
The following four techniques deal with the analysis of hardware safety which may cause in
manufacturing defects, carelessness during installation, or unforeseen interactions to other hardware
elements.
11352
11353
H.2.14.1
11354
Aim
11355
11356
To evaluate the risks associated with any failure condition related to cable design, cable connectors,
cable routing, cable protection, and cable securing.
11357
Description
11358
11359
11360
11361
11362
The Bent Pin Analysis or Cable Failure Matrix Analysis reveals the consequences of bended pins by
examining all possible bent pin combinations and the system effect to specific short or open circuits
resulting from bent pins. By the sole consideration of bent pin combinations resulting in a hazard, the
system risk can be calculated. To get a well-structured documentation a worksheet including pin data,
circuit state, effect, hazard, and mishap risk index (MRI) assessing the risk (output) is used.
11363
11364
There is a need of design knowledge including the connector diagram, the wire list, and the circuit
diagrams (input) to perform BPA / CFMA.
11365
11366
11367
References
11368
11369
11370
11371
Raheja D. G., Allocco M.: Assurance Technologies Principles and Practices; John Wiley & Sons,
2006. ISBN 978-0-471-74491-7
11372
Bent Pin Analysis (BPA) / Cable Failure Matrix Analysis (CFMA)
- 183 -
prEN 50126-4
11373
H.2.14.2
Electromagnetic Compatibility Analysis
11374
Aim
11375
To minimize/prevent accidental or unauthorized operation of safety critical functions within a system.
11376
Description
11377
11378
Electromagnetic Compatibility Analysis investigates whether a system is electromagnetically

compatible (EMC) or not (output). A system is EMC with its environment if it satisfies three criteria:
11379
1) It does not cause interference with other systems;
11380
2) It is not susceptible to emissions from other systems;
11381
3) It does not cause interference with itself.
11382
11383
EMC analysis can be used throughout the planning, design, and construction phases of an electrical
system to ensure that the original EMC design (input) is being implemented correctly.
11384
11385
11386
The technique can be applied in a system where adverse electromagnetic environmental effects can
occur.
11387
References
11388
11389
Paul, C. R.: Introduction to Electromagnetic Compatibility, John Wiley & Sons, 2006.
ISBN 978-0-471-75500-5
11390
11391
11392
11393
Tesche, F. M., Ianoz, M. V. and Karlsson, T.: EMC Analysis Methods and Computational Models,
John Wiley & Sons, 1997. ISBN 978-0-471-15573-7
11394
11395
2000.
11396
11397
H.2.14.3
Energy Trace and Barrier Analysis (ETBA)
11398
Aim
11399
To discover hazards associated with energy sources.
11400
Description
11401
11402
11403
11404
11405
Energy trace and barrier analysis is based on the theory that when hazardous energy sources exist
within a system they pose a hazardous threat to certain targets. Placing barriers between the energy
source and the target can mitigate the threat to targets. ETBA process begins with the identification of
energy sources (input) within the design. As a result energy source hazards and required safety
barriers are determined (output).
11406
11407
Some hazards identified through this technique may require more detailed analysis by other
techniques, e. g. FTA (H.2.30.7).
11408
11409
11410
ETBA is to be applied to identify the system hazards associated with energy sources. The technique
is limited by the ability of the analysis to identify all hazardous energy sources.
prEN 50126-4
- 184 -
11411
References
11412
11413
11414
11415
11416
11417
2000.
11418
11419
H.2.14.4
Materials Compatibility Analysis
11420
Aim
11421
To analyse materials utilized within a design.
11422
Description
11423
11424
11425
Materials Compatibility Analysis provides an assessment (output) of materials (input) utilized within a
particular design. All materials shall be compatible with those with which they can come into contact.
Any potential degradation that can occur due to material incompatibility is evaluated.
11426
11427
11428
References
11429
11430
11431
11432
2000.
11433
11434
H.2.15
Impact Analysis / Change Analysis
11435
Aim
11436
11437
To identify the effect that a change or an enhancement of a system can have to other modules in that
system.
11438
Description
11439
11440
11441
Prior to a modification or enhancement being performed on the system an analysis shall be

undertaken to identify the impact of the modification or enhancement on the system and to also
identify the affected system components.
11442
11443
11444
After the analysis has been completed a decision is required concerning the re-verification of the
system (input). This depends on the number of modules affected, the criticality of the affected
components and the nature of the change. The possible decisions (output) are:
11445
Only the changed components are to be re-verified;
11446
All identified affected components are to be re-verified; or
11447
The complete system is to be re-verified.
- 185 -
prEN 50126-4
11448
11449
11450
References
11451
11452
11453
11454
2000.
11455
11456
H.2.16
Inspections
11457
11458
11459
11460
11461
An inspection, which is a preventive maintenance, is an evaluation technique in which systems are

examined by a person or a group other than the system creator to detect faults, violations of
development standards, and other problems. An inspection should be performed in each product
phase. Only in this way, system failures are detected early. Two useful inspection techniques are
described below.
11462
11463
H.2.16.1
Fagan Inspection (FI)
11464
Aim
11465
To find bugs, which might otherwise go undetected for some time.
11466
Description
11467
11468
A Fagan Inspection is very similar to a normal inspection or a Walkthrough / Design Review (WDR).
The difference between a WDR and a FI is that measures are carried out with a checklist during FIs.
11469
11470
11471
The basis of a FI is a number of checkpoints defined during system development for the following
points: the system itself, the test plans, the publication material, and so on. Throughout the FI an
independent moderator leads through four phases:
11472
11473
1) Each responsible person of the development team provides an overview of his work and distribute
relevant information to other FI-team members;
11474
11475
2) Each team member identifies those areas of the system that have led to errors in previous similar
systems or where he believes they are particularly error prone;
11476
11477
11478
3) A nominated reader walks detailed through the system in front of the team. Every possibility shall
be scrutinized. If an error is detected, it is recorded by the leader and provided with a severity
ranking;
11479
11480
4) Finally, the moderator produces an inspection report, which is given back to the responsible
developer to resolve all problems reported.
11481
11482
11483
The input of a FI is a detailed documentation of the development process which includes a detailed
description of the system including the system behaviours, functions, and so on. Output of a FI is a
To-Do-list created by experts with problems to be solved.
11484
11485
11486
The FI can only be as good as the team that carries them out. Especially, it is difficult to understand
the system, if the responsible developer could not explain detailed enough.
prEN 50126-4
- 186 -
11487
References
11488
11489
Clapp, J. A., Cerino, D. A. and Peng, W. W.: Software Quality Control, Error Analysis, and Testing;
Noyes Data Corporation, 1995. ISBN 0-8155-1363-1
11490
11491
Bell, D.: Software Engineering for Students: A Programming Approach; Pearson Education Limited,
2005. ISBN 978-0-321-26127-4
11492
11493
Birrell, N. D. and Ould, M. A.: A Practical Handbook for Software Development; Cambridge University
Press, 1985. ISBN 978-0-521-25462-5
11494
11495
H.2.16.2
Walkthrough / Design Review (WDR)
11496
Aim
11497
11498
To detect errors in some product of the development process as soon and as economically as
possible.
11499
Description
11500
11501
11502
11503
11504
During a Walkthrough or Design Review the developer of the studied system explains the functions
and the design of the system some other experts, if possible independent of the system (input). To
reveal system errors, the independent person asks questions critically. There is also the possibility to
nominate an expert to be a user trying the system or to let costumers test the system. All problems
are documented (output) and must subsequently be resolved by the developer.
11505
11506
11507
11508
11509
WDR shall be conducted for all new products/processes, new applications, and revisions to existing
products and manufacturing processes which affect the function, performance, safety, reliability,
ability to inspect maintainability, availability, ability to cost, and other characteristics affecting the end
product/process, users or bystanders.
11510
References
11511
11512
Frhauf, K., Ludewig, J. and Sandmayr, H.: Software-Prfung: Eine Anleitung zum Test und zur
Inspektion; vdf. ISBN 978-3-7281-3059-4
11513
11514
Bell, D.: Software Engineering for Students: A Programming Approach; Pearson Education Limited,
2005. ISBN 978-0-321-26127-4
11515
11516
Birrell, N. D. and Ould, M. A.: A Practical Handbook for Software Development; Cambridge University
Press, 1985. ISBN 978-0-521-25462-5
11517
11518
H.2.17
Interface Methods
11519
11520
11521
11522
Interface Methods test and analyse interfaces within a system because system failures can occur
since the interfaces of subsystems are incompatible to each other or information getting stuck in a
subsystem caused in unsuitable interfaces. The two techniques below are useful to preserve a
system from failures by interfaces.
11523
11524
H.2.17.1 Interface Analysis
11525
Aim
11526
To identify hazards (output) due to interface (input) incompatibilities.
- 187 -
prEN 50126-4
11527
Description
11528
11529
11530
The methodology entails seeking those physical and functional incompatibilities between adjacent,
interconnected, or interacting elements of a system which, if allowed to persist under all conditions of
operation, would generate risks.
11531
11532
11533
References
11534
11535
11536
11537
11538
11539
H.2.17.2 Interface Testing
11540
Aim
11541
11542
To demonstrate that interfaces of subsystems do not contain any errors or any errors that lead to
failures in a particular application of the system or to detect all errors that may be relevant.
11543
Description
11544
11545
11546
These kind of tests are particularly important if the system interfaces (input) do not contain assertions
that detect incorrect parameter values. They are also important after new configurations of preexisting subsystems have been generated.
11547
11548
11549
References
11550
11551
11552
H.2.18
Markov Models
11553
Aim
11554
To evaluate the reliability, safety or availability of a system.
11555
Description
11556
11557
11558
11559
11560
11561
11562
Similar to a Time Petri Nets (H.2.32) a Markov Models consist of circles, called places, each
describing a global system state. These are connected due to arrows with other system states
representing the state transitions. An arrow is based on the component failure or repair rate which
means the frequency of occurrence of failure or repair over time. One place can comprise many
components which can be depicted due to a Reliability Block Diagram (H.2.30.11) applied to the
whole system. In this case there must be as much out-coming failure arrows as there are components
included in the respective place.
11563
11564
Utilizing Markov state equations the probability of the occurrence of a special state can be calculated
(output).
prEN 50126-4
- 188 -
11565
11566
To construct a Markov model a good knowledge of the system, the failure, and repair rate of the
components is required (input).
11567
11568
11569
Markov models quickly become complex; thus it is limited to small systems or a high-level system
abstraction. Moreover it does not identify hazards; just evaluates identified hazards in more detail.
11570
References
11571
11572
11573
11574
Andrews, J. D. and Ericson, C. A.: Fault Tree and Markov Analysis Applied to Various Design
Complexities, Proceedings of the 18th International System Safety Conference, 2000.
11575
** IEC 61165:2006; Application of Markov Techniques; Beuth 2008.
11576
11577
H.2.19
Metrics
11578
Aim
11579
11580
To predict the attributes of programs from properties of the software itself rather than from its
development or test history.
11581
Description
11582
11583
11584
Metrics are techniques used to evaluate some structural properties of software (input) and relate
these to a desired attribute (output) such as complexity. Software tools are required to evaluate most
of the measures.
11585
Software metrics are used to:
11586
Describe the characteristics of the product such as size, complexity and design features;
11587
Improve the process of software development and maintenance;
11588
Describe project characteristics, such as the number of software developers, cost and schedule.
11589
11590
11591
11592
An example of the metrics is cyclomatic complexity the number of linearly independent paths that
comprise the program. As such it can be used to indicate the effort required to test a program (see
Testing, H.2.31). To determine the paths, the program procedure is represented as a strongly
connected graph.
11593
11594
11595
11596
Metrics are applied to measure system quality and to improve system development process. The user
should carefully choose metrics and be aware, that too much emphasis on any one of the aspects of
performance can lead to a dysfunctional project.
11597
References
11598
11599
Fenton, N. E. and Pfleeger, S. L.: Software Metrics: A Rigorous and Practical Approach, Course
Technology, 1997. ISBN 978-0-534-95425-3
11600
11601
Kan, S. H.: Metrics and Models in Software Quality Engineering, Addison-Wesley, 2003.
ISBN 978-0-201-72915-3
11602
11603
Oman, P. and Pfleeger, S. L.: Applying Software Metrics, Wiley-IEEE Computer Society Press, 1997.
ISBN 978-0-8186-7645-1
- 189 -
11604
prEN 50126-4
** ISO/IEC 9126: Software engineering Product quality
11605
11606
H.2.20
Modular Approach
11607
Aim
11608
11609
To separate concerns by dealing with smaller parts of a system in isolation, while allowing for
the integration of these parts into a coherent system
11610
Description
11611
11612
11613
11614
11615
11616
By applying Modular Approach (modularization), a complex system (input) is divided into simpler
pieces called modules. A system that is composed of modules is called modular system (output). The
main benefit of modularity is that it allows the principle of separation of concerns to be applied in two
phases: when dealing with the details of each module in isolation (and ignoring details of other
modules) and when dealing with the overall characteristics of all modules and their relationships in
order to integrate them into a coherent system.
11617
Some example rules of modularization methods are:
11618
A module shall have a single well defined task or function to fulfil;
11619
11620
Connections between modules shall be limited strictly defined, coherence in one module shall be
strong.
11621
11622
11623
Modularity is an important property of most engineering processes and products. There are three
goals that modularity tries to achieve in practice: capability of decomposing a complex system, of
composing it from existing system, and of understanding the system in pieces.
11624
11625
11626
References
11627
11628
Ghezzi, C., Jazayeri, M. and Mandrioli, D.: Fundamentals of Software Engineering, Prentice Hall,
2003. ISBN 978-0-13-305699-0
11629
11630
Yourdon, E. and Constantine, L. L.: Structured Design: Fundamentals of a Discipline of Computer

Program and Systems Design, Prentice Hall, 1979. ISBN 978-0-13-854471-3
11631
11632
H.2.21
Monte-Carlo Simulation (MCS)
11633
Aim
11634
To simulate real world conditions or phenomenon in software systems.
11635
Description
11636
11637
11638
11639
11640
11641
11642
The principle behind Monte-Carlo Simulation is to evaluate a model iteratively by injecting sets of
random numbers (input) to simulate noise on a signal or to add random biases or tolerances. This is
to create an artificial world, or pseudo-population, which resembles the real world in all relevant
respects. This pseudo-population consists of mathematical procedures for generating sets of numbers
that resemble samples of data drawn from the true population. This pseudo-population is used to
conduct multiple trials of the statistical procedures of interest to investigate how that procedure
behaves across samples (output) statistically.
11643
11644
Monte-Carlo simulation can be used in almost every phase of application to solve problems, which
can be classified as followed.
prEN 50126-4
- 190 -
11645
11646
Probabilistic problems, where random numbers are used to generate a real world stochastic
phenomenon; and
11647
11648
Deterministic problems, which are mathematically translated into an equivalent probabilistic

problem.
11649
11650
Because MCS is based on an iterative process, the following techniques utilising cyclic graphs can be
applied gainfully: Markov-Models (H.2.18), Time Petri Nets (H.2.32).
11651
11652
11653
MCS is often used to evaluate a model when it is complex, nonlinear, or involves more than just a
couple of uncertain values.
11654
11655
When using Monte-Carlo simulations care must be taken to ensure that the biases, tolerances or
noise are reasonable values.
11656
References
11657
Mooney, C. Z.: Monte Carlo Simulation, SAGE, 1997. ISBN 978-0-8039-5943-9
11658
11659
Andrews, J. D. and Moss, T. R.: Reliability and Risk Assessment, Professional Engineering
Publishing, 2002. ISBN 978-1-860-58290-5
11660
11661
Rubinstein, R. Y. and Kroese, D. P.: Simulation and the Monte Carlo Method, Wiley-Interscience,
2008. ISBN 978-0-470-17794-5
11662
11663
H.2.22
Operational Readiness Review (ORR)
11664
Aim
11665
To ensure a system will be successfully operable during deployment.
11666
Description
11667
11668
The Operational Readiness Review is held after successful completion of all product testing,
acceptance testing, and just prior to the system (input) becoming operational.
11669
11670
11671
References
11672
11673
11674
11675
H.2.23
11676
11677
11678
Performance engineering includes a set of techniques applied in every phase of system development
which ensures that a system will be designed and implemented to meet the performance
requirements specification. The following two techniques belong to performance engineering.
11679
Performance Engineering
- 191 -
prEN 50126-4
11680
H.2.23.1
Performance Modelling
11681
Aim
11682
To establish that the performance requirements of a software system have been satisfied.
11683
Description
11684
11685
11686
The requirements specification (input) includes throughput and response requirements for specific
functions, perhaps combined with constraints on the use of total system resources. The proposed
system design (output) is compared against the stated requirements by
11687
Defining a model of the system processes, and their interactions;
11688
11689
Identifying the use of resources by each process, for example, processor time, communications
bandwidth, storage devices etc.;
11690
11691
Identifying the distribution of demands placed upon the system under average and worst-case
conditions;
11692
11693
Computing the average and worst-case throughput and response times for the individual system
functions.
11694
11695
For simple systems, an analytic solution may be possible whilst for more complex systems; some
form of simulation is required to obtain accurate results.
11696
11697
11698
11699
11700
11701
Before detailed modelling, a simpler 'resource budget' check can be used which sums the resources
requirements of all the processes. If the requirements exceed designed system capacity, the design is
infeasible. Even if the design passes this check, performance modelling may show that excessive
delays and response times occur due to resource wasting. To avoid this situation engineers often
design systems to use some fraction of the total resources so that the probability of resource wasting
is reduced.
11702
11703
Some of the Performances Modelling techniques are Markov Models (H.2.18), Monte-Carlo
Simulation (H.2.21), Petri Nets (H.2.32) and UML diagrams (H.2.35).
11704
11705
This technique is typically applied by modelling tasks.
11706
References
11707
11708
Hillston, J.: A Compositional Approach to Performance Modelling, Cambridge University Press, 2005.
ISBN 978-0-521-67353-2
11709
11710
Dumke, R., Rautenstrauch, C., Schmietendorf, A. and Scholz, A.: Performance Engineering: State of
the Art and Current Trends, Springer, 2001. ISBN 978-3-540-42145-0
11711
11712
H.2.23.2 Performance Requirements
11713
Aim
11714
To establish that the performance requirements of a software system have been satisfied.
11715
Description
11716
11717
An analysis is performed of both the system and the software requirements specifications (input) to
identify all general and specific, explicit and implicit performance requirements (output).
11718
Each Performance Requirement is examined in turn to determine
prEN 50126-4
- 192 -
11719
the success criteria to be obtained;
11720
whether a measure against the success criteria can be obtained;
11721
the potential accuracy of such measurements;
11722
the project stages at which the measurements can be estimated; and
11723
the project stages at which the measurements can be made.
11724
11725
The practicability of each performance requirement is analysed in order to obtain a list of performance
requirements, success criteria and potential measurements. The main objectives are:
11726
Each performance requirement is associated with at least one measurement;
11727
11728
Where possible, accurate and efficient measurements are selected which can be used as early in
the development process as possible;
11729
Essential and optional performance requirements and success criteria are identified; and
11730
11731
Where possible, advantage shall be taken of the possibility of using a single measurement for
more than one performance requirement.
11732
11733
This technique is typically applied by requirements specification.
11734
References
11735
11736
Kan, S. H.: Metrics and Models in Software Quality Engineering, Addison-Wesley, 2003.
ISBN 978-0-201-72915-3
11737
11738
Leffingwell, D. and Widrig, D. : Managing Software Requirements: A Use Case Approach, AddisonWesley, 2003. ISBN 978-0-321-12247-6
11739
Sommerville, I. : Software Engineering, Addison-Wesley, 2010. ISBN 978-0-13-703515-1
11740
11741
H.2.24
Process Simulation
11742
Aim
11743
11744
To test the function of a system, together with its interfaces to the outside world, without allowing it to
modify the real world in any way.
11745
Description
11746
11747
Simulation is used for testing purposes only to create a system (output), which mimics the behaviour
of the system to be controlled (input) by the system under test.
11748
The simulation may be software only or a combination of software and hardware. It must:
11749
Provide all the inputs of the system under test which will exist when the system is installed;
11750
11751
Respond to outputs from the system in a way which faithfully represents the controlled
equipment; and
11752
11753
Have provision for operator inputs to provide any perturbations with which the system under test
is required to cope.
11754
11755
When software is being tested the simulation may be a simulation of the target hardware with its
inputs and outputs.
- 193 -
prEN 50126-4
11756
One simulation technique described in this standard is Monte-Carlo Simulation (H.2.21)
11757
11758
11759
Process simulation is a planning and analysis technique, not a scheduling technique. It is primarily
used for measuring process efficiency and not effectiveness or adaptability.
11760
References
11761
11762
Harrington, H. J. and Tumay, K.: Simulation Modeling Methods, McGraw-Hill Professional, 2000.
ISBN 978-0-07-027136-4
11763
11764
Shull, F., Singer, J. and Sjberg, D. I. K.: Guide to Advanced Empirical Software Engineering,
Springer, 2007. ISBN 978-1-84800-043-8
11765
11766
11767
Zeigler, B. P., Praehofer, H. and Kim, T. G.: Theory of Modeling and Simulation: Integrating Discrete
Event and Continuous Complex Dynamic Systems, Academic Press, 2000.
ISBN 978-0-12-778455-7
11768
11769
H.2.25
Prototyping / Animation
11770
Aim
11771
11772
To check the feasibility of implementing the system against the given constraints and to communicate
the specifier's interpretation of the system to the customer, in order to locate misunderstandings.
11773
Description
11774
11775
11776
11777
11778
A sub-set of system functions, constraints, and performance requirements (input) are selected. A
prototype (output) is built using high level tools. At this stage, constraints such as the target computer,
implementation language, program size, maintainability, reliability and availability need not be
considered. The prototype is evaluated against the customer's criteria and the system requirements
may be modified in the light of this evaluation.
11779
11780
11781
References
11782
11783
Gordon, V. S. and Bieman, J. M., Rapid Prototyping: Lessons Learned, IEEE Software, 12(1):85-94,
1994.
11784
11785
Verner, J. M. and Cerpa, N.: Prototyping: Does your view of its advantages depend on your job?
Journal of Systems and Software, 36(1):3-16, 1997.
11786
11787
Rudd. J. and Isensee, S: Twenty-two tips for a happier, healthier prototype, ACM Interactions, 1(1),
1994.
11788
11789
H.2.26
Recovery Block
11790
Aim
11791
To increase the likelihood of the program performing its intended function.
11792
Description
11793
11794
Several different program sections are written, often independently, each of which is intended to
perform the same desired function. The final program is constructed from these sections. The first
prEN 50126-4
- 194 -
11795
11796
11797
11798
11799
section, called the primary, is executed first. This is followed by an acceptance test of the result it
calculates. If the test is passed then the result is accepted and passed on to subsequent parts of the
system. If it fails, any side effects of the first are reset and the second section, called the first
alternative, is executed. This too is followed by an acceptance test and is treated as in the first case.
A second, third or even more alternatives can be provided if desired.
11800
11801
The difference to Retry Fault Recovery Mechanisms and Safety Bag is that a Recovery Block
operates with several (maybe different) implementations of a function.
11802
11803
Using this technique a design specification (output) can be gained on the basis of requirements
specification (input).
11804
11805
11806
References
11807
11808
11809
H.2.27
Response Timing and Memory Constraints
11810
Aim
11811
To ensure that the system will meet its temporal and memory requirements.
11812
Description
11813
11814
11815
11816
11817
11818
11819
The requirements specification for the system (input) and the software includes memory and
response requirements for specific functions, perhaps combined with constraints on the use of total
system resources. An analysis is performed which will identify the distribution demands under
average and worst case conditions (output). This analysis requires estimates of the resource usage
and elapsed time of each system function. These estimates can be obtained in several ways, for
example, comparison with an existing system or the prototyping and bench-marking of time critical
systems.
11820
11821
11822
References
11823
11824
11825
H.2.28
Retry Fault Recovery Mechanisms
11826
Aim
11827
To attempt functional recovery from a detected fault condition by retry mechanisms.
11828
Description
11829
11830
11831
11832
11833
11834
In the event of a detected fault or error condition (input), attempts are made to recover the situation by
re-executing the same code. Recovery by retry can be as complete as a re-boot and a re-start
procedure or a small re-scheduling and re-starting task, after a software time-out or a task watchdog
action. Retry techniques are commonly used in communication fault or error recovery and retry
conditions could be flagged from a communication protocol error (check sum etc.) or from a
communication acknowledgement response time-out.
- 195 -
11835
11836
11837
References
11838
prEN 50126-4
11839
11840
H.2.29
Safety Bag (SB)
11841
Aim
11842
11843
To protect against residual specification and implementation faults in systems which adversely affect
safety.
11844
Description
11845
11846
11847
11848
11849
11850
A Safety Bag is an external monitor, implemented on an independent computer to a different

specification. This safety bag is solely concerned with ensuring the main computer performs safe, not
necessarily correct, actions. The SB continuously monitors the main computer. The SB prevents the
system from entering an unsafe state. In addition if it detects that the main computer is entering a
potentially hazardous state, the system has to be brought back to a safe state either by the SB or the
main computer.
11851
11852
By applying SB a safety of a system in focus and in addition an independent system (input) can be
improved by early fault detection and recovery strategies (output).
11853
11854
11855
References
11856
11857
11858
H.2.30
System Safety Analysis (SSA)
11859
11860
11861
11862
System Safety Analysis (including hazard analysis) are performed to identify hazards, hazard effects
and hazard causal factors. They are used to determine system risk and thereby ascertain the
significance of hazards so that safety design measures can be established to eliminate or mitigate the
hazard.
11863
11864
11865
11866
11867
Nowadays there are many different safety analysis techniques in use. One of the greatest problems in
performing such analysis may be in selecting an appropriate technique that match the projects goal.
Because the techniques have different coverage and validity, several may be required during the
safety life cycle of a system. No one method is superior to all others for every objective or even
applicable to all types of systems.
11868
Several techniques related to system safety analysis are described in the following sub-clauses.
11869
11870
H.2.30.1
Common Cause Failure Analysis (CCFA)
11871
Aim
11872
11873
11874
To identify potential failures in redundant systems or redundant subsystems which would undermine
the benefits of redundancy because of the appearance of the same failures in the redundant parts at
the same time.
prEN 50126-4
- 196 -
11875
Description
11876
11877
11878
11879
11880
11881
The system redundancy prevents system failures in case that at least one of the redundant systems is
still running. But system failures may have common causes. To identify these causes the common
cause failure analysis is used. Redundant systems are either independent or dependent to each
other. There can be different reasons for CCFs, such as using the same hardware (e. g. transistors
fabricated in the same factory), using same resources (e. g. power supply) or installing the systems in
the same building (CCFs originated by effects of heat or vibration).
11882
11883
11884
11885
11886
The basis for a structured approach to CCFA mostly is the development of a fault tree. After adding
the CCF events, the fault tree is recomputed to revaluate the criticality, sensitivity, and probability of
CCFs. The next step involves the review of system design and operating historical experience to
identify CCF vulnerabilities. These results are utilized to develop a fault tree simply using CCF events,
which includes the risk of every single system.
11887
11888
Thus, the fault tree constitutes the basis for a CCFA it is a need to know the system design (input).
Hence the technique only identifies system hazards associated with CCF (output).
11889
11890
The CCFA requires a high level of expertise and practice analysing the CCF events in a system.
11891
References
11892
11893
11894
11895
Fussell, H. B. and Burdick, G. R.: Nuclear Systems Reliability Engineering and Risk Assessment;
Society for Industrial & Applied Mathematics 1977. ISBN 0-898-71041-3
11896
11897
H.2.30.2
11898
Aim
11899
To minimize risk in the event of an emergency.
11900
Description
11901
11902
With Contingency Analysis potential accidents (input) are identified and the adequacies of emergency
measures (output) are evaluated.
11903
11904
11905
CA could be conducted for any system, procedure, task or operation where there is the potential for
harm.
11906
References
11907
11908
11909
11910
2000.
11911
Contingency Analysis (CA)
- 197 -
prEN 50126-4
11912
H.2.30.3
Critical Incident Technique
11913
Aim
11914
11915
To collect direct observations of human behaviour that have critical significance and meet
methodically defined criteria.
11916
Description
11917
11918
11919
11920
This is a qualitative interview method of investigation significant occurrences (errors and unsafe
conditions of the system input) that contribute to both potential and actual accidents or incidents
within a given population. The objective is to gain understanding (output) of the incident from the
perspective of the individual, taking into account cognitive, affective, and behavioural elements.
11921
11922
11923
References
11924
11925
11926
11927
11928
11929
Gremler D. D.: The Critical Incident Technique in Service Research. In: Journal of Service Research,
August 2004.
11930
11931
H.2.30.4 Criticality Analysis
11932
Aim
11933
11934
To rank each failure mode identified in a Failure Modes and Effect Analysis (FMEA, see H.2.30.5).
The FMEA then gets the Failure Mode, Effects and Criticality Analysis (FMECA, see H.2.30.5).
11935
Description
11936
11937
11938
The Criticality Analysis is used to chart the probability of failure modes against the severity of their
consequences. The result highlights failure modes with relatively high probability and severity of
consequences, allowing remedial effort to be directed where it will produce the greatest value.
11939
The analysis team must:
11940
11941
Define the reliability/unreliability for each item and use it to estimate the expected number of
failures at a given operating time;
11942
Identify the portion of the items unreliability that can be attributed to each potential failure mode;
11943
Rate the probability of loss (or severity) that will result from each failure mode that may occur;
11944
Calculate the criticality for each potential failure;
11945
11946
Calculate the criticality for each item by obtaining the sum of the criticalities for each failure mode
that has been identified for the item.
11947
11948
prEN 50126-4
- 198 -
11949
References
11950
11951
11952
11953
11954
11955
11956
H.2.30.5 Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and
Criticality Analysis (FMECA)
11957
Aim
11958
11959
11960
To evaluate the effects of potential failure modes and establish the overall probability that the system
will operate without failure for a specific length of time or, alternatively, that the product will operate a
certain length of time between failures.
11961
Description
11962
11963
11964
The FMEA is a qualitative analysis method that can be extended by a criticality analysis which can
also deliver quality results (FMECA). To perform FMEA the following things have to be known and
done:
11965
System design, boundaries and mission (input);
11966
Criteria for failure and success (input);
11967
Answering questions like: What can fail?, How does it fail?, What are the effects of the failure?;
11968
Search for failure causes.
11969
In order to expand the FMEA to the FMECA the following steps are processed:
11970
11971
Investigate the failure rate and failure effects, severity of a failure effect, as well as detection rate
of each subsystem (input);
11972
11973
Calculate the risk priority number (RPN) by multiplying the probability of occurrence with the
severity ranking and the detection ranking;
11974
Find measures against the cause of failure.
11975
11976
11977
11978
Similar to the HAZOP the FME(C)A is performed by a team of engineers and a trained specialist in
hazard analysis (team leader). During several meetings the leader asks questions and the team
answers. For this the system is split in its subsystems which are split in their items. The FME(C)A
needs to be done for each of these. FMEA output information is:
11979
Failure modes and their consequences;
11980
Reliability prediction;
11981
Critical item list.
11982
In addition, the FMECA provides information about the risk priority number (RPN).
11983
11984
11985
A disadvantage is that the FME(C)A only considers single failures, but no failure combination. The
technique is mostly applicable to systems for which, component failure modes are well known.
- 199 -
prEN 50126-4
11986
References
11987
11988
11989
11990

ISBN 978-0-201-11972-5
11991
11992
** IEC 60812; Analysis techniques for system reliability Procedure for failure mode and effects
analysis (FMEA); Beuth 2006.
11993
11994
H.2.30.6
Fault Hazard Analysis
11995
Aim
11996
11997
To identify what can fail and how and how frequent it can fail. In addition, the effects of failures are
examined.
11998
Description
11999
12000
12001
12002
12003
12004
The Fault Hazard Analysis is a deductive method of analysis of a system (input) that can be used
exclusively as a qualitative analysis or, if desired, expanded to a quantitative one. The fault hazard
analysis requires a detailed investigation of the subsystems to determine component hazard modes,
causes of these hazards, and resultant effects to the subsystem and its operation (output). This type
of analysis is a form of a family of reliability analyses called Failure Modes and Effect Analysis
(FMEA, see H.2.30.5) and Failure Mode, Effects and Criticality Analysis (FMECA, see H.2.30.5).
12005
12006
12007
References
12008
12009
12010
12011
U.S. Department of Transportation, Federal Aviation Administration (ed.):

System Safety Handbook, December 30, 2000: Clause 9.2
12012
Ericson, C. F.: Hazard Analysis Techniques for System Safety, Wiley, 2005.
12013
12014
H.2.30.7
Fault Tree Analysis (FTA)
12015
Aim
12016
12017
To identify all events (failure modes, human error, and normal conditions), and its logical relations,
that can lead to the occurrence of a specified undesired event.
12018
Description
12019
12020
12021
Fault trees (FT) are graphical models using logical gates (e. g. AND, OR) and fault events to model
the cause-effect relationships (input) involved in causing the undesired event. Thus FTA is deductive
in that it transverses from the general problem to the specific causes.
12022
12023
12024
The completed FT structure can be translated into a mathematical model to determine the
significance of fault events (output) and their probability of occurrence (output) by the application of
certain rules of Boolean algebra and probability theory.
prEN 50126-4
- 200 -
12025
12026
12027
In general FTA can be applied during any life cycle phase of a system from concept to usage.
Nevertheless to be most effective, FTA requires a completed system design and a thorough
understanding of the system and its behaviour in all operating modes.
12028
12029
12030
To identify the undesired top events to be considered often a failure mode and effects analysis
(FMEA) (H.2.30.5) is practised. Moreover to simplify the FTA process functional block diagrams can
be utilized.
12031
12032
12033
12034
12035
There are two basically applications of FTA. The most commonly used application is the proactive
FTA, performed during system development to influence design by predicting and preventing future
problems. The other application is the reactive FTA, performed after an accident or mishap has
occurred.
12036
12037
12038
12039
FTA is a method for analysing causes of hazards, not for identifying hazards. The top event in the tree
must have been foreseen and thus identified by other techniques (e. g. FMEA). Moreover modelling of
temporal behaviour with FTA is more difficult than with other means of description (e. g. Markov
modelling (H.2.18)).
12040
References
12041
12042
12043
12044
Fault Tree Handbook. W. E. Vesely et al, NUREG-0492, Division of System Safety Office of Nuclear
Reactor Regulation, US Nuclear Regulatory Commission Washington, 1981.
12045
** IEC 61025:1990, Fault tree analysis (FTA).
12046
12047

ISBN 978-0-201-11972-5
12048
12049
H.2.30.8
Hazard and Operability Study (HAZOP)
12050
Aim
12051
To detect and analyse hazards and operational concerns.
12052
Description
12053
12054
12055
12056
12057
The analysis is carried out by a team of engineers (covering computer, instrument, electrical, process,
safety and operational disciplines) led by a trained specialist in hazard analysis techniques in a series
of scheduled meetings. During the analysis the leader asks leading questions based on the
considered system and the engineers answer them as detailed as possible using guided words. The
following elements (input) are always observed:
12058
1) Name of the item under analysis;
12059
2) Description of the function and purpose of the item;
12060
3) Guide word such as no, more, less, reverse, early, faster, where else, and so on;
12061
4) System effect if guide word occurs;
12062
5) Resulting hazard or deviation;
12063
6) Risk assessment (performed by a statement about the expected severity and probability); and
12064
7) Safety requirements for eliminating or mitigating the hazards.
- 201 -
prEN 50126-4
12065
12066
Using the collected data Fault Trees (H.2.30.7) can be created to support the purely written
documentation.
12067
12068
12069
Through this type of analysis not only information about errors (which already have occurred) and
risks can be gained, but also potential scenarios and possible alternatives (output) can be
constructed.
12070
12071
12072
Although HAZOP is a very organized, structured and methodical analysis, it is only focused on single
events rather than on combinations of possible events.
12073
References
12074
12075
12076
** IEC 61882:2002 Hazard and operability studies (HAZOP studies) - Application guide.
12077
12078
H.2.30.9
12079
Aim
12080
12081
12082
To evaluate the effectiveness of procedures in controlling those hazards which were identified as
being controlled by procedures, instead of by design, and to ensure that procedures do not introduce
new hazards.
12083
Description
12084
12085
12086
12087
The Operating and Support Hazard Analysis identifies hazards/risks occurring during use of the
system (input). It encompasses operating the system (primarily procedural aspects) and the support
functions (e. g., maintenance, servicing, overhaul, facilities, equipment, and training) that go along
with operating the system.
12088
12089
12090
12091
12092
12093
12094
The sooner the analysis begins the better. Even before the system is designed, an O&SHA can be
started to identify hazards (output) with the anticipated operation of the system. Ideally, the O&SHA
should begin with the formulation of the system and not be completed until sometime after initial test
of the system (which may identify additional hazards). This is critical because design and construction
of support facilities must begin far before the system is ready for fielding, and all special safety
features (e. g., fire suppression systems) must be identified early or the costs to modify the facilities
may force program managers and users to accept unnecessary risks.
12095
12096
12097
References
12098
12099
12100
12101
12102
Ericson, C. F.: Hazard Analysis Techniques for System Safety, Wiley, 2005.
12103
Operating and Support Hazard Analysis (O&SHA)
prEN 50126-4
- 202 -
12104
H.2.30.10
Preliminary Hazard Analysis (PHA)
12105
Aim
12106
To identify and mitigate previously unrecognized hazards early in the system development process.
12107
Description
12108
12109
12110
12111
The Preliminary Hazard Analysis method also referred to as Gross Hazard Analysis or Potential
Hazard Analysis is a safety analysis method, using tabular worksheets for identifying hazards, their
associated causal factors, effects, level of risk, and safety recommendations for mitigating risk
(output) when only preliminary or baseline design concepts (input) are available.
12112
12113
The PHA is generally applicable to analyse all types of systems, facilities, operations and functions. It
can be performed on a particular unit, a subsystem, a system or an integrated set of systems.
12114
12115
To simplify the PHA process and for the sake of maximum accessible completeness of the identified
hazards following techniques can be utilised:
12116
Reliability Block Diagram (H.2.30.11) for structuring the PHA;
12117
Preliminary Hazard List (PHL) for providing an initial set of hazards.
12118
12119
12120
12121
Generally the PHA is, as its name implies, generated early in the system design development phase
in order to influence the design when the cost impact is minimal. Therefore PHA is often used as a
starting point for further hazard analysis (e. g. Fault Tree Analysis, H.2.30.7) and safety tasks.
12122
12123
12124
12125
Because PHA starts at the concept formation stage of a project, little detail is available, and
assessments of hazard and risk levels are necessarily only qualitative and limited. While there are no
other real constraints/disadvantages in the PHA method, it is sometimes improperly used, even if
other techniques can be utilized more gainful to analyse and upgrade systems safety properties.
12126
References
12127
12128
12129
12130

ISBN 978-0-201-11972-5
12131
12132
Stephans, R. A., Talso, W. W. and System Safety Society (U.S.).: System Safety Analysis Handbook,
New Mexico Chapter, System Safety Society, 1993.
12133
12134
H.2.30.11
Reliability Block Diagram (RBD)
12135
Aim
12136
To depict the relationship between the functioning of a system and the functioning of its components.
12137
Description
12138
12139
12140
12141
12142
12143
A Reliability Block Diagram is a graph showing the signal flow through a system represented as
rectangles by combining the components of the system in the correct sequence. There are three
basic types of arrangement in which each system structure can be described: series, parallel, or
regeneration structure. From this structure (input), the reliability for the entire system (output) can be
determined using simple rules of calculation, if the failure probabilities of the components (input) are
known.
- 203 -
prEN 50126-4
12144
12145
12146
References
12147
12148
Kuo, W. and Zuo, M. H.: Optimal Reliability Modeling; John Wiley & Sons, 2003.
ISBN 978-0-471-39761-8
12149
12150
Roush, M. and Webb, W.: Applied Reliability Engineering Volume I; University of Maryland, 2006.
ISBN 978-0-9652669-8-2
12151
12152
H.2.30.12
Repetitive Failure Analysis
12153
Aim
12154
To identify repetitive failures of a system.
12155
Description
12156
Repetitive failure analysis is used to analyse causes (output) of repetitive failures (input) of a system.
12157
The repetitive failure problem is often discussed in terms of Root Cause Analysis (F30.13).
12158
12159
12160
References
12161
12162
12163
12164
H.2.30.13
Root Cause Analysis (RCA)
12165
Aim
12166
12167
To investigate what, how, and why something happened and to figure out how to prevent the same
thing from happening again.
12168
Description
12169
12170
12171
12172
Root Cause Analysis is a collective term used to describe a wide range of techniques to uncover
causes of problems. This type of techniques is used to identify causal factors (output) to accidents or
near-miss incidents. Therefore it goes beyond the directly related causes to identify fundamental
reasons, so called root causes, for faults or failures (input).
12173
12174
Following excerpted techniques can be used to identify root causes: Ishikawa diagram (fishbone
diagram), Barrier Analysis or Failure Mode and Effects Analysis (H.2.30.5).
12175
12176
12177
12178
12179
Primarily RCA have been utilised to detect root causes after an undesired event has occurred
(reactive RCA). Nowadays the different techniques are sometimes also used to forecast the possibility
of an event even before it could occur (proactive RCA). If so, the proactive RCA should be generated
early in the design phase in order to influence the design when the cost impact is minimal.
prEN 50126-4
- 204 -
12180
References
12181
12182
Andersen, B. and Fagerhaug, T.: Root Cause Analysis: Simplified Tools and Techniques. Milwaukee,
Wis: ASQ Quality Press, 2006. ISBN 978-0-87389-692-4
12183
12184
Latino, R. J. and Latino, K. C.: Root Cause Analysis: Improving Performance for Bottom-Line Results.
CRC Press, 2006. ISBN 978-0-8493-5340-6
12185
12186
Robitaille, D.: Root Cause Analysis: Basic Tools and Techniques. Paton Professional, 2004.
ISBN 978-1-932828-02-3
12187
12188
Stephans, R. A., Talso, W. W. and System Safety Society (U.S.).: System Safety Analysis Handbook,
New Mexico Chapter, System Safety Society, 1993.
12189
12190
H.2.30.14
Single Point Failure Analysis
12191
Aim
12192
12193
To identify single points of failure. A single point of failure is a part of a system which, if it fails, will
stop the entire system from working.
12194
Description
12195
Single points of failure and their probability can be evaluated by Reliability Block Diagram (H.2.30.11).
12196
12197
12198
References
12199
12200
12201
12202
U.S. Department of Transportation, Federal Aviation Administration (ed.):System Safety Handbook,

12203
12204
H.2.30.15
Sneak Circuit Analysis (SCA)
12205
Aim
12206
12207
To detect an unexpected path or logic flow within a software, hardware, operator actions or a
combination of these.
12208
Description
12209
12210
12211
12212
12213
12214
The Sneak Circuit Analysis identifies special hazards called sneak circuit. These are paths in a
system which leads to an unexpected behaviour of the system initiating an undesired function, a
desired function but at inappropriate time or inhibiting a desired function. The presence of sneak
circuits is often caused by a lack of design oversight, because of the complicity of the system; by
changes or fixes, because they are rarely submitted to the rigorous testing that the original design
undergoes; or by human errors when tasks are performed improperly, out of sequence, etc..
12215
12216
Sneak circuits can be searched by an analyst or by commercial software packages. By both of them
the following steps are applied:
12217
1)
Collect detailed manufacturing and installation schematics (input);
12218
2)
Convert the schematics in a consistent code which consists of nodes and paths;
- 205 -
prEN 50126-4
12219
12220
3)
Simplify the set of schematics by eliminating all inactive nodes (nodes which have no influence to
the change of system state);
12221
4)
Produce network trees;
12222
5)
Examine each node and identify the pattern containing that particular node;
12223
12224
6)
Detect sneak circuit conditions for each node using a large set of clues given to every pattern;
and
12225
12226
12227
7)
Generate a SCA report which includes sneak paths, timings, labels (e. g. a lack of precise
nomenclature), indications (indicator that causes an incorrect operator display) and procedures
(e. g. ambiguous wording, lack of notes, etc.) (output).
12228
12229
12230
SCA requires special computer programs driving up the costs. Furthermore, entering the data is a
time-consuming process.
12231
References
12232
12233
12234
12235
H.2.31
Testing
12236
12237
12238
Testing is the activity of executing a system in order to detect failures. One of the key challenges of
testing is how to select the tests that are most likely to expose failure in the system. There are many
kinds of testing. Each of them has a particular strategy for the test selection algorithm.
12239
12240
H.2.31.1
Model Based Testing (MBT)
12241
Aim
12242
To generate test input data based on the model of a system, or specification.
12243
Description
12244
12245
12246
12247
12248
The idea of Model Based Testing is to have a model of the system (input), or specification, and use
this model to generate sequences of input and expected output (output). Roughly speaking, the input
is applied to the system under test, and systems output is compared to the models output, as given
by the generated trace. This implies that the model must be valid, i.e., that it faithfully represents the
requirements.
12249
12250
12251
There are many relations of MBT to other techniques described in this document. One important way
to create a model is by using Domain Specific Languages (H.2.6). For the test case generation Model
Checking (H.2.12.2) or Theorem Proving (H.2.12.4) can be applied.
12252
12253
12254
References
12255
12256
Broy, M., Jonsson, B., Katoen, J.-P., Leucker, M. and Pretschner, A.: Model-Based Testing of
Reactive Systems: Advanced Lectures; Springer, 2008. ISBN 978-3-540-26278-7
12257
12258
Utting, M. and Legeard, B.: Practical Model-Based Testing. A Tools Approach; Morgan Kaufmann,
2007. ISBN 978-0-12-372501-1
prEN 50126-4
- 206 -
12259
12260
H.2.31.2
Stress-Testing
12261
Aim
12262
12263
To burden the test object with an exceptionally high workload in order to show that the test object
would stand normal workloads easily.
12264
Description
12265
12266
There are a variety of test conditions which can be applied for avalanche/stress testing. Some of
these test conditions are listed below:
12267
12268
If working in a polling mode then the test object gets much more input changes per time unit as
under normal conditions;
12269
12270
If working on demands then the number of demands per time unit to the test object is increased
beyond normal conditions;
12271
If the size of a database plays an important role then it is increased beyond normal conditions;
12272
Influential devices are tuned to their maximum speed or lowest speed respectively;
12273
12274
For the extreme cases, all influential factors, as far as is possible, are put to the boundary
conditions at the same time.
12275
12276
12277
Under these test conditions the time behaviour of the test object can be evaluated. The influence of
load changes can be observed. The correct dimension of internal buffers or dynamic variables, stacks
etc. can be checked.
12278
12279
12280
References
12281
Beizer. B. (ed.): Software System Testing and Quality Assurance, Van Nostrand Reinhold, 1984.
12282
Beizer, B.: Software Testing Techniques, Van Nostrand Reinhold, 2nd Edition, 1990.
12283
12284
H.2.31.3
Test Oracle (TO)
12285
Aim
12286
To determine whether or not a program produces correct outputs during testing.
12287
Description
12288
12289
12290
12291
12292
A Test Oracle is a mechanism (human or machine) which can be used to check the correctness of the
output (output) of the system for a large number of test cases (input). Therefore test cases are given
to the TO and the system under testing. The output of the two is then compared to determine if the
program behaved correctly for the test cases. The output of the TO must be verified to make a
statement about the accuracy of the system. That increases the costs of a TO mechanism.
12293
12294
12295
TOs are often used when an old system is going to be replaced by a newer one. In this case the old
system works as a TO and the results of the new and old system are compared.
- 207 -
prEN 50126-4
12296
12297
TO is not very common in the industry, since so far human testers took the role of the oracle; but this
is changing increasingly.
12298
References
12299
12300
Cofer, D.D. and Fantechi, A.: Formal Methods for Industrial Critical Systems 13th International
Workshop, FMICS 2008; Springer, 2009. ISBN 978-3-642-03239-4
12301
Bharat Bhushan Agarwal and Sumit Prakash Tayal: Software Engineering; Laxmi Publications, 2007
12302
12303
Prasad, K. V. K. K.: ISTQB Certification Study Guide; Dreamtech Press, 2008.

ISBN 978-81-7722-711-6
12304
12305
Thomas, D.: ECOOP 2006 Object-Oriented Programming 20th European Conference; Springer,
2006. ISBN 978-3-540-35726-1
12306
12307
12308
Yang, L. T., Zhou, X., Zhao, W., Wu, Z., Zhu, Y. and Lin, M.: Embedded Software and Systems 2nd
International Conference, ICESS 2005; Springer, 2005.
ISBN 978-3-540-30881-2
12309
H.2.31.4 Fault Injection
12310
Aim
12311
12312
To extend the scope or coverage of testing by injecting faults into the hardware or software and
examining the effects.
12313
Description
12314
12315
12316
Fault injection is a testing technique that originally was performed on hardware, but later also
developed into a technique for software testing, in particular in terms of so-called mutation testing.
Some functions, particularly error handling functions, can only be tested by injecting faults.
12317
12318
12319
The first applications of testing by means of fault injection dates back to the 1970s when it was used
to induce faults at a hardware level, the purpose being to examine the system level effects of
hardware failures and thereby assess the dependability of the electronic system.
12320
12321
12322
Hardware fault injection in VLSI circuits is typically performed at the transistor level, where the
transistors are given various types of faults, and the results examined in the operation of the
circuit. Fault injection is done in simulated circuits as well as in physical realisations of circuits.
12323
12324
12325
12326
When done in a simulated circuit, the purpose of the fault injection testing is typically to detect the
response to manufacturing defects. By repeatedly introducing new faults, evaluating the response of
the circuit, and modifying the circuit, the use of fault injection testing contribute to the circuit design.
The system is simulated to evaluate the response of the circuit to that particular fault.
12327
12328
12329
12330
Fault injection in a physical realisation of a circuit is typically done after fabrication but prior to the
production of the circuit, to examine the effects of transient faults. The fault is produced by subjecting
the circuit to some kind of interference, and then examining the resulting behaviour of the circuit by
means of the testing equipment.
12331
12332
Fault injection at a hardware level is known as Hardware Implemented Fault Injection. Analogously,
fault injection in software is known as Software Implemented Fault Injection.
12333
12334
12335
12336
12337
12338
Hardware Implemented Fault Injection is used in early design as well as after fabrication, to improve
circuit design as well as to evaluate the dependability of the overall electronic system. Fault injection
is generally more economical to perform for easily configurable hardware, such as FPGAs. Software
Implemented Fault Injection is used to improve the coverage of software testing, in particular to check
the effectiveness of the testing to detect errors or to check the effectiveness of error handling.
12339
prEN 50126-4
- 208 -
12340
H.2.32
Time Petri Nets
12341
Aim
12342
12343
To model relevant aspects of the system behaviour and to assess and possibly improve safety and
operational requirements through analysis and re-design.
12344
Description
12345
12346
12347
Petri nets belong to a class of graph theoretic models which are suitable for representing information
and control flow in systems exhibiting concurrency and asynchronous behaviour. Petri nets extended
by timing features are called Time Petri Nets (TPN). They are based on four graphical symbols:
12348
Circles, called places, describing a possible system state;
12349
Tokens describing the current system state due to marking places;
12350
Transitions, displayed as rectangles, changing the system state; and
12351
Arcs connecting places and transitions.
12352
12353
12354
12355
12356
The places may be 'marked' or 'unmarked'. A transition is 'enabled' when all the input places to it are
marked by tokens. When enabled, it is permitted (but not obliged) to 'fire'. A firing transition removes
one token form all its input places and add one token in each its output places. Some transitions fire
in no time, some stochastically, and some even deterministically which quickly comes up against its
limits, because of the mathematical complexity.
12357
12358
12359
To model a system by TPN (output) the primitive state of the system, the transition characteristics and
all conceivable system states are needed (input). A detailed input allows identifying a special class of
hazards, such as those dealing witch timing, state transition, and repair (output).
12360
12361
12362
References
12363
12364
12365
T. Agerwala: Putting Petri Nets to Work, IEEE Computer, Dec., 85-94 (1979).
12366
12367
Malhotra, M. and Trevedi, K.S.: Dependability Modeling Using Petri Nets, IEEE Trans. Reliability,
44:428-440 (1995).
12368
12369
Schneeweiss, W. G.: Petri Nets for Reliability Modeling, LiLoLe, 1999.

ISBN 978-3-934447-00-7
12370
12371
Schneeweiss, W. G.: Petri Nets as a Graphical Description Medium for Many Reliability Scenarios,
IEEE Trans. Reliability, 50(2):June, 159-164 (2001).
12372
** VDI 4008 Blatt 4: Methoden der Zuverlssigkeit Petri-Netze; Beuth, 2008.
12373
12374
** IEC 62551; VDE 0050-4:2008-10: Analysemethoden der Zuverlssigkeit Petrinetz-Modellierung;

Beuth, 2008
12375
12376
H.2.33
Traceability
12377
Aim
12378
To check that the system meets all requirements.
- 209 -
prEN 50126-4
12379
Description
12380
12381
The objective of Traceability is to ensure that all requirements can be shown to have been properly
met and that no untraceable material has been introduced.
12382
12383
Traceability to requirements (input) shall be an important consideration in the validation of a system

and means shall be provided to allow this to be demonstrated throughout all phases of the life cycle.
12384
12385
Traceability shall be considered applicable to both functional and non-functional requirements and
shall particularly address:
12386
Traceability of requirements to the design or other objects which fulfil them;
12387
Traceability of design objects to the implementation objects which instantiate them;
12388
12389
Traceability of requirements and design objects to the operational and maintenance objects
required to be applied in the safe and proper use of the system;
12390
12391
Traceability of requirements, design, implementation, operation and maintenance objects, to the

verification and test plans and specifications which will determine their acceptability;
12392
12393
Traceability of verification and test plans and specifications to the test or other reports which
record the results of their application.
12394
12395
Where requirements, design or other objects are instantiated as a number of separate documents,
traceability shall be maintained within the document structures and in a hierarchical manner.
12396
12397
The output of the Traceability process shall be the subject of formal Configuration Management
(H.2.3).
12398
12399
12400
12401
References
12402
12403
Grady, J. O.: System Requirements Analysis; Elsevier Inc., 2006.

ISBN 978-0-12-088514-5
12404
12405
H.2.34
Trusted Components
12406
12407
12408
The advantages of using Trusted Components are saving time, especially during product
development and minimizing the risk of default. In the following are described three techniques which
help to use these advantages.
12409
12410
H.2.34.1
Certified Tools and Certified Translators (CT)
12411
Aim
12412
To reach some level of confidence regarding the correctness of the output.
12413
Description
12414
12415
12416
12417
A certified tool is one which has been determined to be of a particular quality. Certification is often
carried out by a state-approved institution, which verifies whether national or international standards
were met. CTs should be used in all phases of product development, because otherwise it is difficult
to prove that the product meets applicable safety standards.
prEN 50126-4
- 210 -
12418
12419
12420
12421
To work with CTs, it must be demonstrated that the specifications of the CTs fit to the requirements of
the product development (input). If this condition is met, much time can be saved during the product
development by the use of CTs. In addition, fewer errors occur, since it can be used on an already
existing knowledge.
12422
12423
CTs are found in a great set of applications and they are becoming increasingly important.
12424
References
12425
12426
McKay, C.: How to Succeed as a Freelance Translator; Corinne McKay, 2006.

ISBN 978-1-4116-9520-7
12427
12428
Berghofer, S., Nipkow, T., Urban, C. and Wenzel, M.: Theorem Proving in Higher Order Logic: 22nd
International Conference, Springer, 2008. ISBN 978-3-642-03358-2
12429
12430
H.2.34.2
Library of Trusted/Verified Components
12431
Aim
12432
12433
To avoid the need for component designs to be extensively revalidated or redesigned for each new
application.
12434
Description
12435
To designate a component as verified, mainly four things must be fulfilled (input):
12436
12437
1) Formal specification of the component and its subcomponents which defines user visible
structure;
12438
2) Formal specification of the model in which the component is implemented;
12439
3) Implementation of the component; and
12440
4) Formal proof that the construction meets the specification.
12441
12442
12443
There are two great advantages using verified components (output). Firstly, it saves time because it
relies on components that do not have to be examined. Secondly, fewer errors occur in the risk
analysis because it is based on already proven work.
12444
12445
12446
References
12447
12448
Yorav, K.: Hardware and Software: Verification and Testing; Third International Haifa Verification
Conference, Springer, 1998. ISBN 978-3-540-77964-3
12449
12450
H.2.34.3
Tools proven in use
12451
Aim
12452
12453
To avoid any difficulties due to translator failures which can arise during development, verification and
maintenance of a software package.
- 211 -
prEN 50126-4
12454
Description
12455
12456
A translator is used, whose correct performance has been demonstrated in many projects already.
Translators without operating experience or with any serious known errors are prohibited.
12457
12458
If the translator has shown small deficiencies the related language constructs are noted down and
carefully avoided during a safety related project.
12459
12460
Another version to this way of working is to restrict the usage of the language to only its commonly
used features.
12461
12462
12463
This recommendation is based on the experience from many projects. It has been shown that
immature translators are a serious handicap to any software development. They make a safetyrelated software development generally infeasible.
12464
It is also known, presently, that no method exits to prove the correctness for all compiler parts.
12465
12466
12467
References
12468
12469
12470
H.2.35
Unified Modelling Language (UML)
12471
12472
Unified Modelling Language is a graphical modelling object-oriented language. In this scope the
following four types of diagrams are considered.
12473
12474
H.2.35.1
Class Diagram (ClD)
12475
Aim
12476
To depict the static aspect of a system.
12477
Description
12478
12479
12480
12481
12482
A Class Diagram consists of classes, their attributes, and the relationships between the classes. A
class includes a set of objects with the same properties. Classes comprised the name of the class,
the number of attributes of the class (these are the properties of the class), the number of methods or
operations the class can take or undertake. Classes can be connected through links, called
relationships with other classes. The main relationship types are:
12483
Associations define simple relationships;
12484
Generalizations are used to show parent and child classes; and
12485
Dependencies indicate that one class depends on another of using it at some point of time.
12486
12487
Relationships are marked with multiplicities which show if one class use or consists of zero or more
instances of the related class.
12488
12489
To model the whole system structure in a clear way (output), all connections of the components must
be known (input).
12490
12491
ClDs are very common. They are used especially in the beginning and end of system development.
prEN 50126-4
- 212 -
12492
References
12493
Marrer, G.: Fundamentals of Programming: With Object Orientated Programming.
12494
12495
12496
George, C. and Miao, H.: Formal Methods and Software Engineering: 4th International Conference on
Formal Engineering Methods, ICFEM 2002 Shanghai, China, October 2002 Proceedings; Springer,
1998. ISBN 978-3-540-00029-1
12497
12498
Holt, J.: UML for Systems Engineering: Watching the Wheels; Institution of Engineering and
Technology, 2007. ISBN 978-0-86341-354-4
12499
12500
H.2.35.2
Component Diagram (CoD)
12501
Aim
12502
To depict how components are wired together to form larger components.
12503
Description
12504
12505
To model a static implementation view of a system a Component Diagram is useful. As Class

Diagrams (ClD) the CoDs also consist of the following relationships:
12506
Associations define simple relationships;
12507
Generalizations are used to show parent and child classes;
12508
12509
Dependencies indicate that one class depends on another because of using it at some point of
time.
12510
12511
12512
The difference between ClDs and CoDs is, that CoDs typically maps to more classes. They are not as
detailed as ClDs. Thus likened to a ClD a CoD is a blunt representation of a system structure (output).
To achieve this, all connections of the components must be known (input).
12513
12514
CoDs are very common. They are used especially in the beginning and end of system development.
12515
References
12516
12517
Swain, G.: Object-Oriented Analysis and Design through Unified Modelling Language; University
Science Press, 2010.
12518
12519
Cade, M. and Roberts, S.: Sun Certified Enterprise Architect for J2EE Technology Study Guide; Sun
Microsystems Press, 2002. ISBN 978-0-13-044916-0
12520
12521
H.2.35.3
Sequence Diagram (SeD)
12522
Aim
12523
To describe the interactions among objects during the execution of a use case.
12524
Description
12525
12526
12527
Sequence Diagrams are very similar to Component Diagrams (CoD). In contrast to the CoDs, which
can represent all possible process paths of a system, the SeDs are applied only on a specific process
path in a system.
12528
12529
SeDs consist of objects, relations, and lifelines. The objects are placed on the top of the diagram. A
timeline is drawn downwards which symbolizes the duration for which the object is valid. Linking two
- 213 -
prEN 50126-4
12530
12531
timelines using a relationship line, means that information flow takes place at a readable time
between these two objects.
12532
12533
12534
SeDs represents the possibility of a detail or a bluntly representation (output) of the use case
structure. Because only a certain sequence state of the system can be considered, the input is limited
to the structure and behaviour of this certain use case.
12535
12536
12537
References
12538
12539
12540
Anglin, S. and Welsh, T.: Pro Java EE Spring Patterns: Best Practices and Design Strategies
Implementing Java EE Patterns with the Spring Framework; Dhrubojyoti Kayal, 2008. ISBN 978-14302-1010-8
12541
Saleh, K. A.: Software Engineering; H. Ross Publishing, 2009. ISBN 978-1-932159-94-3
12542
12543
H.2.35.4
12544
Aim
12545
To depict the dynamic behaviour of a system.
12546
Description
12547
12548
12549
12550
12551
12552
A State Chart Diagram consists of states, transitions, events, and activities also called actions. States
indicate a set of conditions at which a system can be during its execution. The system state can be
changed due to a transition between them. Most of these transitions have a trigger event which
activates the transition. Only activated transitions can change the system state. Three activities can
be assigned to one state: One activity which will be executed if the state occurs, one as during the
state is true, and one if the state is left.
12553
12554
SCDs show all possible states in which a system can be located (output). Therefore a good system
structure knowledge is needed (input).
12555
12556
12557
References
12558
12559
Cade, M. and Roberts, S.: Sun Certified Enterprise Architect for J2EE Technology Study Guide; Sun
Microsystems Press, 2002. ISBN 978-0-13-044916-0
12560
Saleh, K. A.: Software Engineering; H. Ross Publishing, 2009. ISBN 978-1-932159-94-3
12561
12562
12563
12564
END
State Chart Diagram (SCD)

EN50126 Draft pt4 CLCEnq 120629

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EN50126 Draft pt4 CLCEnq 120629

Uploaded by

Copyright:

Available Formats

-1-

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

Applications ferroviaires Spcification et dmonstration de la fiabilit, de la

Bahnanwendungen - Spezifikation und Nachweis von Zuverlssigkeit, Verfgbarkeit,

Terms and Definitions....................................................................................................................... 11

Overall Framework of the Part 4....................................................................................................... 14

E/E/PE SYSTEMS MANAGEMENT AND ORGANISATION................................................................ 16

E/E/PE SYSTEMS ASSURANCE ....................................................................................................... 23

E/E/PE SYSTEM DEVELOPMENT: SYSTEM ASPECTS.................................................................... 46

Lifecycle Issues and Documentation.......................................................................................... 16

Additional Requirements for E/E/PE Architecture....................................................................... 46

E/E/PE DEVELOPMENT: GENERIC HARDWARE ............................................................................. 59

Hardware Component Specification........................................................................................... 59

10. E/E/PE DEVELOPMENT: CONFIGURABLE HARDWARE ................................................................. 63

11. E/E/PE SYSTEMS OPERATION AND MAINTENANCE...................................................................... 64

Planning & Organisation............................................................................................................ 64

Annex A (normative) Techniques/Measures............................................................................................. 72

Annex B (normative) Electronic/Electrical Component failure modes .................................................... 85

Annex C (normative) Key Hardware/System Safety Roles and Responsibilities................................. 104

Annex E (informative) Guidance on Programmable Devices ................................................................ 124

Annex F................................................................................................................................................... 141

Annex G (informative) Structure of Hardware/Systems Safety Cases................................................... 143

Annex H (informative) Bibliography of techniques ................................................................................ 157

Figure 1 - Illustrative Development Lifecycle ................................................................................... 17

Figure 2 - Illustrative Development and System Integration Lifecycle............................................... 18

Figure 3 - Independence and Combination of Roles versus Safety Integrity Levels........................... 20

Figure 4 Detection and negation of single faults ............................................................................ 48

Figure D.1 Single-fault and Multiple-fault detection conditions ...................................................... 121

Figure G.1 Structure of Technical Safety Report ......................................................................... 145

Table A.1 Lifecycle Issues and Documentation ............................................................................. 73

Table A.2 Safety Planning and Quality Assurance Activities.......................................................... 74

Table A.3 System Requirements Specification .............................................................................. 75

Table A.4 Safety Organisation ...................................................................................................... 76

Table A.5 Architecture of System/Subsystem/Equipment .............................................................. 77

Table A.6 Design Features ........................................................................................................... 78

Table A.7 Failure and Hazard Analysis Methods ........................................................................... 80

Table A.8 Design and Development of System/Sub-system/Item .................................................. 81

Table A.9 Design Phase Documentation....................................................................................... 81

Table A.11 Application, Operation and Maintenance ..................................................................... 83

Table A.12 Functional Testing....................................................................................................... 83

Table A.13 Performance Testing................................................................................................... 83

Table A.14 Hardware Safety Analysis ........................................................................................... 84

Table B.1 Resistor and adjustable resistor (excluding 4-terminal resistor)...................................... 93

Table B.2 4 Terminal Resistors ..................................................................................................... 93

Table B.3 Capacitor and adjustable capacitor (excluding 4-terminal capacitor).............................. 93

Table B.4 4-Terminal Capacitors................................................................................................... 94

Table B.5 Electromagnetic Components-Inductor.......................................................................... 94

Table B.6 Electromagnetic Components-Transformer ................................................................... 94

Table B.7 Electromagnetic Components-Transductor (saturable reactor or magnetic amplifier) ..... 95

Table B.8 Electromagnetic Components-Relays............................................................................ 96

Table B.9 Diodes- Normal diode (power, signal, switching) ........................................................... 96

Table B.10 Diodes-Zener Diodes .................................................................................................. 96

Table B.11 Transistors-Bipolar...................................................................................................... 97

Table B.12 Transistors-Field Effect (FET) ..................................................................................... 97

Table B.13 Silicon - controlled rectifier (SCR) (thyristor) ................................................................ 98

Table B.14 Bidirectional thyristor (triac)......................................................................................... 98

Table B.15 Surge Suppressors - Voltage-dependent resistor (VDR) (varistor) ............................... 99

Table B.16 Surge Suppressors-Protective Diode........................................................................... 99

Table B.17 Surge Suppressors-Gas Discharge Arrester................................................................ 99

Table B.18 Surge Suppressors-Air Gap Arrester........................................................................... 99

Table B.19 Opto-electronic Components-Photo Diode .................................................................. 99

Table B.20 Opto-electronic Components-Photo Transistor .......................................................... 100

Table B.21 Opto-electronic Components- Light-emitting diode (LED) .......................................... 100