21.5 EN50126 Draft pt4 CLCEnq 120629

-1- prEN 50126-4
7000
7001 Project number: prEN 50126-4
7002
7003
7004
7005
Railway Applications - The Specification and Demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)
Part 4: Functional Safety - Electrical / Electronic / Programmable Electronic Systems
Applications ferroviaires – Spécification et démonstration de la fiabilité, de la

disponibilité, de la maintenabilité et de la sécurité (FDMS)
Partie 4: Sécurité fonctionnelle - Systèmes électriques / électroniques / électroniques
programmables
Bahnanwendungen - Spezifikation und Nachweis von Zuverlässigkeit, Verfügbarkeit,

Instandhaltbarkeit und Sicherheit (RAMS)
Teil 4: Funktionale Sicherheit - Elektrische / Elektronische / Programmierbare
elektronische Systeme
7006
prEN 50126-4 -2-
7007
-3- prEN 50126-4
7008
7009 Table of Contents
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 6.1 Lifecycle Issues and Documentation.......................................................................................... 16
7018 6.2 Organisation, Roles and Responsibilities................................................................................... 19
7019 6.3 Personnel Competence ............................................................................................................. 22
7020 7. E/E/PE SYSTEMS ASSURANCE ....................................................................................................... 23
7021 7.1 Analysis .................................................................................................................................... 23
7022 7.2 Testing...................................................................................................................................... 26
7023 7.3 Verification ................................................................................................................................ 28
7024 7.4 Validation .................................................................................................................................. 30
7025 7.5 Independent Assessment .......................................................................................................... 33
7026 7.6 Quality Assurance ..................................................................................................................... 36
7027 7.7 Safety Management .................................................................................................................. 39
7028 7.8 Configuration Management and Modification Control ................................................................. 41
7029 7.9 Support Tools............................................................................................................................ 43
7030 8. E/E/PE SYSTEM DEVELOPMENT: SYSTEM ASPECTS.................................................................... 46
7031 8.1 Additional Requirements for E/E/PE Architecture....................................................................... 46
7032 8.2 Integration and Validation.......................................................................................................... 51
7033 9. E/E/PE DEVELOPMENT: GENERIC HARDWARE ............................................................................. 59
7034 9.1 Hardware Component Specification........................................................................................... 59
7035 9.2 Hardware Component Implementation....................................................................................... 61
7036 9.3 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 11.1 Planning & Organisation............................................................................................................ 64
7041 11.2 System Deployment .................................................................................................................. 65
7042 11.3 Operation and Maintenance including Performance Monitoring.................................................. 67
7043 11.4 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 -4-
7052 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 Table B.28 – Interconnection Assemblies-Connection (soldered, welded, wrapped, crimped, clipped,
7112 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 Table Description for techniques/ measures from E.3 - Placement, Routing and Layout Generation
7145 ............................................................................................................................................. 140
7146 Table H.1- Properties of Techniques.............................................................................................. 168
7147
-7- prEN 50126-4
7148 Foreword
7149 This European Standard was prepared by the Technical Committee CENELEC TC 9X, electrical and
7150 electronic applications in railways.
7151 The text of the draft was submitted to the formal vote and was approved by CENELEC as EN 50126-4
7152 on 20xx-xx-xx.
7153 The following dates were fixed:
7154 latest date by which the EN has to be implemented

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

7158 with the EN have to be withdrawn (dow) 20xx-xx-xx
7159 This document supersedes EN 50129:2003.
7160 The EN 50126 standard includes under the general title "Railway application - The specification and
7161 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 This part 4 of EN 50126 standard covers the functional safety for E/E/PE. It is mainly based on
7167 EN 50129:2003 which is withdrawn. In this standard, annexes D to H are informative.
7168 This European Standard has been prepared under a mandate given to CENELEC by the European
7169 Commission and supports the Directive 2008/57/EC.
7170 Introduction
7171 The standard EN 50126-1:1999 was produced to introduce the application of a systematic RAMS
7172 management process in the railway sector. For safety related electronic systems for signalling the
7173 standards EN 50128:2011 and EN 50129:2003 were produced. Through the application of these
7174 standards and the experiences gained over the last years, the need for revision and restructuring
7175 became apparent with a need to deliver a systematic and coherent approach to RAMS applicable to
7176 all the railway application fields Signalling, Rolling Stock and Electric power supply for Railways
7177 (Fixed Installations).
7178 The revision work improved the coherency and consistency of the standards, the concept of safety
7179 management and the practical usage of the standard EN 50126, and took into consideration the
7180 existing and related Technical Reports as well.
7181 This European Standard provides railway duty holders and the railway suppliers, throughout the
7182 European Union, with a process which will enable the implementation of a consistent approach to the
7183 management of reliability, availability, maintainability and safety, denoted by the acronym RAMS.
7184 Processes for the specification and demonstration of RAMS requirements are cornerstones of this
7185 standard. This European Standard promotes a common understanding and approach to the
7186 management of RAMS.
7187 EN 50126 is the railway sector specific application of IEC 61508. Meeting the requirements in this
7188 European Standard is sufficient to ensure that additional compliance to IEC 61508 does not need to
7189 be evaluated.
prEN 50126-4 -8-
7190 With regard to safety, EN 50126-1 provides a Safety Management Process which is supported by
7191 guidance and methods described in EN 50126-2.
7192 EN 50126-1 and EN 50126-2 are independent from the technology used. EN 50126-4 and
7193 EN 50126-5 provide guidance specific to safety related E/E/PE technology of railway applications.
7194 Their application is determined through the application of the general RAMS process of EN 50126-1
7195 and through the outcome of the safety related methods described in EN 50126-2. As far as safety is
7196 concerned, the EN 50126 standard takes the perspective of functional safety. This does not exclude
7197 other aspects of safety. However, these are not the focus.
7198 The aims set for revision of the EN 50126 standard required a better understanding of the systems
7199 approach and improved methods for applying the safety management process described in
7200 EN 50126-1. EN 50126-2 provides this guidance.
7201 The application of this standard should be adapted to the specific requirements of the system under
7202 consideration.
7203 This European Standard can be applied systematically by the railway duty holders and railway
7204 suppliers, throughout all phases of the life cycle of a railway application, to develop railway specific
7205 RAMS requirements and to achieve compliance with these requirements. The systems-level approach
7206 developed by this European Standard facilitates assessment of the RAMS interactions between
7207 elements of railway applications even if they are of complex nature.
7208 This European Standard promotes co-operation between the stakeholders of Railways in the
7209 achievement of an optimal combination of RAMS and cost for railway applications. Adoption of this
7210 European Standard will support the principles of the European Single Market and facilitate European
7211 railway inter-operability.
7212 The process defined by this European Standard assumes that railway duty holders and railway
7213 suppliers have business-level policies addressing Quality, Performance and Safety. The approach
7214 defined in this standard is consistent with the application of quality management requirements
7215 contained within the ISO 9000 series of International standards.
7216
-9- prEN 50126-4
7217 1. Scope
7218 This part of EN 50126
7219 is intended to apply to all safety-related electronic (E/E/PE) railway systems/sub-
7220 system/hardware. However, the hazard analysis and risk assessment processes defined in EN
7221 50126-1 and in this part are necessary for all railway systems/sub-systems/hardware, in order to
7222 identify any safety requirements. The relevant methods are provided by EN 50126-2. If analysis
7223 reveals that no safety requirements exist (i.e.: that the situation is non-safety-related), and
7224 provided the conclusion is not revised as a consequence of later changes, this part of EN 50126
7225 ceases to be applicable;
7226 is applicable to safety-related electronic systems (including sub-systems and hardware) for
7227 railway applications;
7228 is primarily applicable to systems/sub-systems/hardware which have been specifically designed
7229 and manufactured for railway applications. It should also be applied, as far as reasonably
7230 practicable, to general-purpose or industrial hardware (e.g.: power supplies, modems, etc.),
7231 which is procured for use as part of a safety-related railway system. As a minimum, evidence
7232 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 - to the specification, architecture, design, construction, implementation, integration,
7237 manufacturing, installation, acceptance, operation, maintenance and modification/extension
7238 phases of the system /subsystem and hardware, and also to individual sub-systems and
7239 hardware within the overall system as determined by the process in EN 50126-1 and
7240 supported by the methods in EN 50126-2.
7241 - to generic sub-systems and hardware (both application-independent and those intended for a
7242 particular class of application), and also to systems/sub-systems/hardware for specific
7243 applications;
7244 addresses railway specifics;
7245 does not define
7246 - RAMS targets, quantities, requirements or solutions for specific railway applications
7247 - rules or processes pertaining to the certification of railway products against the requirements
7248 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 to the specification and demonstration of safety for all railway applications and at all levels of
7253 such an application, as appropriate, from complete railway systems to major systems and to
7254 individual and combined sub-systems and hardware components within these major systems,
7255 including those containing software; in particular:
7256 - to new systems
7257 - to new systems integrated into existing systems in operation prior to the creation of this
7258 standard, although it is not generally applicable to other aspects of the existing system;
7259 - for modifications of existing systems in operation prior to the creation of this standard,
7260 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 Application of EN 50126-4 follows from SIL allocation to system/subsystem/hardware through

7264 applying the processes described in EN50126-1 and methods described by EN 50126-2. Given the
7265 relative maturity of most electrical systems, this part of EN 50126 is largely applicable to Electronic
7266 and Programmable Electronic sub-systems, systems and hardware.
7267 NOTE: Guidance on the applicability is given in the requirements of this standard.
7268 Existing systems compliant with any version of former EN 50126, EN 50128 or EN 50129 shall not be
7269 subject of reconsideration and are considered as compliant with this standard.
7270 Railway applications mean Command, Control & Signalling, Rolling Stock and Fixed Installations for
7271 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 For the purposes of this document, the terms and definitions given in EN 50126-1 and the following
7283 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 a hardware component is a constituent part of a sub-system which has well-defined interfaces and
7288 behaviour with respect to the system/sub-system architecture and design and fulfils the following
7289 criteria:
7290 a) an electrical/electronic component or assembly delivering a specific function;

7291 b) it covers a specific subset of sub-system requirements;
7292 c) it is clearly identified and has an independent version inside the configuration management
7293 system or is a part of a collection of components (e. g. subsystems) which have an independent
7294 version
7295 3.3 maintenance manager
7296 an entity responsible for implementation and upkeep of maintenance procedures and standards
7297 ensuring safe and reliable performance of the system.
7298 3.4 release note

7299 a documented record of all application and maintenance conditions for safe operation, across life
7300 cycle phases
7301 3.5 safety manager

7302 an entity that is responsible for the correct accomplishment of the safety management
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 - prEN 50126-4
7346 4.41 MCS: Monte-Carlo Simulation

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
prEN 50126-4 - 14 -
7382 5. Overall Framework of the Part 4

7383 This part of the EN 50126 suite of standards addresses the application of the safety life cycle to
7384 electronic hardware and integrated systems comprising electrical, electronic and programmable
7385 electronic hardware and software. The principal purpose of this suite of standards is to support the
7386 design, development, production and operation of acceptably safe products, systems and processes
7387 aimed at railway applications. In this spirit, the approval, acceptance or certification constitute a
7388 secondary potential benefit arising from compliance with this suite of standards. EN 50126-4 and EN
7389 50126-5 of the standard suite address technology specific safety requirements and are
7390 complementary to the requirements and the framework developed in EN 50126-1 and EN 50126-2
7391 which shall also be complied with. The standard addresses the management, organisation and overall
7392 electronic systems assurance including the safety requirements applicable to generic and
7393 configurable hardware. The system aspects of electronic system development are also addressed
7394 together with the requirements for manufacturing, deployment, operation and maintenance.
7395 The overall scope of this standard includes electrical, electronic and programmable electronic
7396 hardware with fixed embedded logic, configurable hardware, integrated electronic systems comprising
7397 hardware and software and electronic sub-systems with fixed or configurable logic.
7398 A part from hardware, sub-systems and integrated systems, this standard places requirements for
7399 management, organisation and the competency of the people who assume various roles in the safety
7400 life cycle of electronic hardware and systems. This is in recognition of the major impact of the
7401 organisational and competency aspects on the overall reduction of the systematic errors which are
7402 otherwise likely to remain embedded in the design and production of electronic hardware and
7403 systems.
7404 The overall structure of this standard addresses key safety life cycle requirements in the design,
7405 development, deployment and maintenance of electrical, electronic and programmable electronic
7406 systems and hardware. Where appropriate, the structure in this standard is aligned with the software
7407 standard in EN 50126-5 to provide a familiar and systematic approach across the related disciplines.
7408 Chapters 6 and 7 of this standard set out the common requirements for life cycle phases defined in
7409 Chapters 8-11. The chapters are structured to state the objectives, inputs, requirements and the
7410 outputs pertinent to each phase of the life cycle.
7411 Chapter 6 sets out the generic management and organisational requirements pertinent to electronic
7412 systems addressing documentation, roles, requisite competencies, responsibilities of key personnel
7413 and the required independence between the roles.
7414 Chapter 7 sets out the generic system assurance requirements addressing hardware, software and
7415 hardware/software integration aspects including quality management, safety management,
7416 configuration and change management and support tools.
7417 Chapter 8 sets out the system aspects addressing requirements for system architecture,
7418 implementation, integration, manufacturing, installation and commissioning and final acceptance.
7419 Chapter 9 sets out the requirements for the development of generic electronic system hardware
7420 addressing architecture, design, implementation, integration, manufacturing, installation and
7421 commissioning and validation. It additionally provides requirements and guidelines for development of
7422 Safety Cases for generic product, generic application, specific application and cross-acceptance for
7423 systems and hardware.
7424 Chapter 10 sets out the requirements for the development of configurable electronic system hardware
7425 addressing architecture, design, implementation, integration, manufacturing, installation and
7426 commissioning and validation. Many of the requirements of the generic electronic systems and
7427 hardware are equally applicable to configurable variants. This chapter provides new requirements
7428 compared with the EN50129:2003.
7429 Chapter 11 sets out the requirements for a safe deployment, operation and maintenance pertinent to
7430 electronic systems and hardware in railways. It addresses the organisational as well as processes to
7431 ensure a safe system is safely put into use and maintained to operate safely whilst undergoing
- 15 - prEN 50126-4
7432 retrofits and maintenance (This chapter provides new requirements compared with the
7433 EN50129:2003).
7434 The annexes to this standard provide normative and informative requirements and guidance
7435 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 Annex C provides normative requirements on key safety roles and competencies for development of
7439 electronic hardware and systems (This Annex provides new requirements compared with the
7440 EN50129:2003),
7441 Annex D provides informative guidance on attaining physical independence and fault detection for
7442 SIL3 and SIL 4 functions,
7443 Annex E provides informative guidance on firmware development for PLDs (This Annex provides new
7444 requirements compared with the EN50129:2003),
7445 Annex F provides normative requirements on previously developed and commercial off the shelf
7446 hardware/systems (This chapter provides new requirements compared with the EN50129:2003),
7447 Annex G provides informative guidance on the structure of electronic systems & hardware safety
7448 cases (this Annex provide new guidance on cross-acceptance compared with the EN50129:2003)
7449 and
7450 Annex F provides an informative updated generic bibliography of the hardware and system design
7451 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 6.1.1.1 To structure the development of the system/sub-system and hardware components into
7457 defined phases and activities.
7458 6.1.1.2 To record all information pertinent to the system/sub-system and hardware components
7459 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 6.1.4.1 A life cycle model for the development of system/sub-system and hardware components shall
7467 be selected. It shall be detailed in the Quality Assurance Plan in accordance with Clause 7.6.
7468 6.1.4.2 The life cycle model shall take into account the possibility of iterations in and between
7469 phases.
7470 6.1.4.3 Quality Assurance procedures shall run in parallel with life cycle activities and use the same
7471 terminology.
7472 6.1.4.4 All activities to be performed during a phase shall be defined prior to the commencement of
7473 the phase. Each phase of the system/sub-system and/or hardware component life cycle shall be
7474 divided into elementary tasks each of which has a well defined input, output and activity.
7475 6.1.4.5 All documents shall be structured to allow continued expansion in parallel with the
7476 development process.
7477 6.1.4.6 For each document, traceability shall be provided in terms of a unique reference number and
7478 a defined and documented relationship with other documents.
7479 6.1.4.7 Each term, acronym or abbreviation shall have the same meaning in every document. If, for
7480 historical reasons, this is not possible, the different meanings shall be listed and the references given.
7481 6.1.4.8 Except for documents relating to pre-existing systems/sub-systems or hardware components
7482 (see EN 50126-1, sub-clause 7.4.6), each document shall be written according to the following rules:
7483 - it shall contain or implement all applicable conditions and requirements of the preceding
7484 document with which it has a hierarchical relationship;
7485 - it shall not contradict the preceding document.

- 17 - prEN 50126-4
7486 6.1.4.9 The contents of all documents shall be recorded in a form appropriate for manipulation,
7487 processing and storage.
7488 6.1.4.10 When documents which are produced by independent roles are combined into a single
7489 document, the relation to the parts produced by any independent role shall be traced within the
7490 document.
7491 6.1.4.11 In accordance with 6.1.4.10, documents may be combined or divided. Some development
7492 steps may be combined, divided or, when justified, eliminated, at the discretion of the Project
7493 Manager and with the agreement of the Validator and the Assessor (see 7.5.4.8).
7494 6.1.4.12 Where any alternative life cycle or documentation structure is adopted it shall be established
7495 that it meets all the objectives and requirements of this European Standard.
7496 6.1.4.13 During development (and depending upon the size of the system) the documentation may
7497 be sub-divided into a number of child documents and be naturally added to, as the detailed needs of
7498 the development become clearer.
1
Concept
2 10 12
SystemDefinition& Operation, 11
SystemAcceptance Decommissioning
Operational Context Maintenanceand
Performance
Monitoring
3
RiskAnalysis&
Evaluation
Specificationof 4 9
SystemRequirements SystemValidation
5
Architectureand Apportionment
of SystemRequirements
6 8
Designand Integration
Implementation
7
Manufacture
7499
7500
7501
7502 Figure 1 - Illustrative Development Lifecycle
7503
prEN 50126-4 - 18 -
7504
7505 Figure 2 - Illustrative Development and System Integration Lifecycle
7506
- 19 - prEN 50126-4
7507 6.2 Organisation, Roles and Responsibilities

7509 To ensure that all personnel who have responsibilities for the system/sub-system and hardware
7510 component are organised, empowered and capable of fulfilling their responsibilities.
7511 6.2.2 Input
7514 1) Quality Management Report
7516 6.2.4.1 As a minimum, the supplier shall implement EN ISO 9001 chapter 4 and 5 dealing with the
7517 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 6.2.4.3 The personnel assigned to the roles involved in the development or maintenance of the
7520 system/sub-system and hardware component shall be recorded in a Quality Management Report or in
7521 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 6.2.4.5 The assessor may be part or not of the supplier organization, but shall be in any case
7524 independent from the project organizations (Design, Testing, Integration, Safety, Verification and
7525 Validation). National legislation / Safety Authority may ask for additional independence requirements.
7526 NOTE: The independent assessment body may be identified by national legislation.
7527 6.2.4.6 The Assessor shall be given authority to perform the independent assessment of the
7528 system/sub-system and/or hardware component.
7529 6.2.4.7 The Validator shall give agreement/disagreement for the system/sub-system and/or hardware
7530 component release.
7531 6.2.4.8 Throughout the system/sub-system and hardware component life cycle, the parties involved
7532 shall be independent, to the extent required by the safety integrity level, in accordance with Figure 3
7533 and 6.2.4.9 to 6.2.4.14.
7534
7535
prEN 50126-4 - 20 -
7536
7537 Figure 3 - Independence and Combination of Roles versus Safety Integrity Levels
7538
- 21 - prEN 50126-4
7539 6.2.4.9 The preferred organisational structure for SIL 3 and SIL 4 is shown in Figure 3. However, the
7540 following alternatives may apply:
7541 a) The Validator may be the same person as the Verifier, but still maintaining independence from the
7542 Project Manager. In this case the Verifier’s output shall be reviewed by another competent person
7543 with the same level of independence as the Validator. This organisational option shall be subject to
7544 Assessor’s approval.
7545 b) The Verifier may be the same person as Integrator and Tester under the Project Manager, in which
7546 case the role of Validator shall check the adequacy of the documented evidence from integration
7547 and testing with the specified verification objectives, hence maintaining two levels of checking
7548 within the project organisation.
7549
7550 6.2.4.10 The preferred organisational structure for SIL 1 and SIL 2 is shown in Figure 3. However,
7551 the following alternatives may apply:
7552 a) The Verifier may be the same person as the Integrator and the Tester, in which case the role of
7553 Validator shall include reviewing the Verifier’s outputs hence maintaining two levels of checking
7554 within the project organisation.
7555 b) The Validator may be the same person as the Verifier, Integrator and Tester, in which case the
7556 Validator shall be independent from the Project Manager. In this case the Verifier’s output shall be
7557 reviewed by another competent person with the same level of independence as the Validator. This
7558 organisational option shall be subject to Assessor’s approval.
7559
7560 6.2.4.11 The preferred organisational structure for SIL 0 that has a safety impact below SIL 1 is
7561 shown in Figure 3. However, the following alternative may apply:
7562 a) RQM, DES, IMP, INT, TST and VER can be the same person and the Validator shall be
7563 independent.
7564
7565 6.2.4.12 The Verifier, Integrator and Tester can also report to Validator.
7566 6.2.4.13 An entity performing the roles Requirements Manager, Designer, Implementer for one
7567 component can perform the roles Tester and Integrator for a different component.
7568 6.2.4.14 The roles and the assigned persons for the verifier and the validator shall be defined at the
7569 project level. These roles and the assigned persons should ideally remain unchanged throughout the
7570 development project.
prEN 50126-4 - 22 -
7571
7572 6.3 Personnel Competence

7574 To ensure that all personnel who have responsibilities for the system/sub-system and/or hardware
7575 component are competent to discharge those responsibilities by demonstrating the ability to perform
7576 relevant tasks correctly, efficiently and consistently to a high quality and under varying conditions.
7577 6.3.2 Input
7580 1) Quality Assurance Plan (updated)
7582 6.3.4.1 The key competencies required for each role in the development of a system/sub-system
7583 and/or hardware component shall be compliant with the requirements defined in Annex C. If additional
7584 experience, capabilities or qualifications are required for a role in the life cycle of a system/subsystem
7585 and/or hardware component, these shall be defined in the Quality Assurance Plan.
7586 6.3.4.2 Documented evidence of personnel competence, including technical knowledge,

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

7602 7.1.1.1 The objective of system/sub-system or hardware component analysis is to ascertain the
7603 behaviour or performance of a system/sub-system or hardware component through detailed
7604 examination of its architecture and components. In general, system/sub-system or hardware
7605 component analysis involves carefully examining the system/sub-system or hardware component,
7606 and any documentation related to it, with the aim of deducing its correct and safe operation as a
7607 logical consequence of the design decisions. In particular, analysis concerns the ability of the
7608 system/sub-system or hardware component to meet its specified safety requirements in the event of
7609 random hardware failures and, as far as reasonably practicable, systematic failures (see 8.2.4.8).
7610 7.1.1.2 Analysis complements or supports other activities during the whole system life cycle, albeit
7611 not replacing these activities. Analysis is in this context neither a separate assurance activity, nor
7612 restricted to system analysis on the basis of a system definition, but more generally the use of
7613 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 a) Analysis is sometimes an activity following testing, requiring the test cases and their results to be recorded. Accordingly,
7616 testing is complemented by an examination based on the use of analysis techniques suitable for evaluating test results.
7617 b) Verification is typically carried out through a combination of tests, checks and analysis, using both dynamic and static
7618 techniques and models.
7619 c) Validation typically involves the use of analysis techniques suitable for determining whether the product fits the user needs.
7620 Analysis complements testing as a validation activity.
7621 d) independent assessment can be considered a special process of analysis, followed by judgment, involving the use of
7622 analysis techniques suitable for determining whether the product is of the defined safety integrity level and fit for its
7623 intended application.
7624 e) Modification control involves analysing the information collected in problem reports to identify the causes of problems,
7625 followed by change impact analysis to determine the consequences of the change prior to implementation.
7626 f) Support tools are justified by analysing the assurance activities performed, involving the use of analysis techniques suitable
7627 for identifying possible significant failures.
7628 g) In general, development involves analysis of requirements and the derivation of test cases from these requirements,
7629 involving the use of analysis techniques suitable for deducing the properties or behaviour of a system/sub-system or
7630 hardware component on the basis of its requirements, including analysis of hardware/software interactions and different
7631 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).
7635 This sub-clause provides guidance for the contents of output documents from other assurance
7636 activities, and does not directly require any other output documents. The analysis shall however be
7637 documented, either as a separate document or as part of the documentation of the activity it
7638 complements or supports.
prEN 50126-4 - 24 -
7640 7.1.4.1 Analysis shall be performed by the role, defined by the type of activity it complements or
7641 supports, and constrained by the requirements given in this standard to this type of activity, i.e.
7642 analysis complementing testing shall normally be performed by the tester, analysis supporting
7643 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 7.1.4.3 The analysis techniques shall be chosen on basis of the characteristics of the analysis
7650 problem, i.e. the characteristics of the chosen technique or combination of techniques shall match the
7651 characteristics of the problem.
7652 7.1.4.4 If no single analysis technique matches the characteristics of the analysis problem, a
7653 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 7.1.4.7 The level of formality of the analysis techniques shall match the level of formality of the
7657 models used as a basis for the analysis.
7658 NOTE: Analysis techniques can be classified as informal, semiformal and formal, partly based on the level of formality of the
7659 models used.
7660 7.1.4.8 Analysis shall complement testing at least in cases where testing alone does not give
7661 complete coverage.
7662 7.1.4.9 Analysis complementing testing shall be performed in such a way that testing and analysis
7663 together give complete coverage.
7664 7.1.4.10 Analysis shall be based on examining models of the system/sub-system or hardware
7665 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 7.1.4.11 System/sub-system or hardware component analysis shall be documented by an analysis

7668 report, either as a separate document or as part of the documentation of the activity it complements or
7669 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 d) the identity and configuration of all items involved (systems/subsystems or hardware components,
7683 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

7688 The objective of system/sub-system or hardware component testing, as performed by the Tester
7689 and/or Integrator, is to ascertain the behaviour or performance of a system/sub-system or hardware
7690 component against the corresponding test specification to the extent achievable by the selected test
7691 coverage.
7692 7.2.2 Input
7695 This sub-clause does not directly require any output documents. It provides guidance for the contents
7696 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
7705 7.2.4.1 A Test Specification shall be written, under the responsibility of the Tester. Requirements
7706 from 7.2.4.1.1 to 7.2.4.1.3 refer to the Test Specification.
7707 7.2.4.1.1 Measurement equipment used for testing shall be calibrated appropriately. Any tools,
7708 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 7.2.4.1.3 If, for completion of the tests, analyses are needed these analyses shall be carried out in
7720 accordance with clause 7.1.
7721 7.2.4.2 A Test Report shall be written, under the responsibility of the Tester. Requirements from
7722 7.2.4.2.1 to 7.2.4.2.3 refer to the Test Report.
7723 7.2.4.2.1 The Test Reports shall fully state the related baselines for system/sub-system, hardware,
7724 that have been tested.
7725 7.2.4.2.2 A Test Report shall be produced as follows:
7726 a) the Test Report shall state the test results and whether the objectives and criteria of the Test
7727 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 c) test cases and their results shall be recorded, preferably in a machine-readable form for
7730 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 f) the identity and configuration of all items involved (documentation, including the related test
7734 specifications, system/subsystem, hardware components, test equipment, calibration of the test
7735 equipment) shall be documented;
7736 g) an evaluation of the test coverage and test completion shall be provided and any deviations
7737 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 7.2.4.2.3 If, for completion of the tests, analyses are carried out, these analyses shall be
7742 documented in accordance with clause 7.1.
7743
prEN 50126-4 - 28 -
7744
7745 7.3 Verification

7747 The objective of system/sub-system or hardware component verification is to examine and arrive at a
7748 judgment based on evidence that output items (process, documentation, system/sub-system or
7749 hardware components) of a specific development phase fulfil the applicable plans and the
7750 requirements of that phase as specified in this standard, with respect to completeness, correctness
7751 and consistency. These activities are managed by the Verifier.
7752 7.3.2 Input
7755 1) System Verification Plan
7756 This sub-clause does not directly require the system verification reports as output documents, but
7757 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)
7763 7.3.4.1 Verification shall be carried out by one or more persons who are independent as described in
7764 sub-clause 6.2.
7765 7.3.4.2 Verification shall be documented by at least a System Verification Plan and one or more
7766 (process-related) Verification Reports, as defined in the following.
7767 7.3.4.3 A System Verification Plan shall be written, under the responsibility of the Verifier.
7768 Requirements from 7.3.4.3.1 to 7.3.4.3.5 refer to the System Verification Plan.
7769 7.3.4.3.1 The System Verification Plan shall describe the activities to be performed to ensure proper
7770 verification and that particular design or other verification needs are suitably provided for.
7771 7.3.4.3.2 The System Verification Plan shall describe the activities to be performed to ensure
7772 correctness and consistency with respect to the input to that phase. These include testing, integration
7773 and documents reviewing against expected properties, as defined in this standard.
7774 7.3.4.3.3 In each life cycle phase the Verifier shall ensure that all requirements regarding system,
7775 subsystem, hardware or process, related to that phase, are met. This includes (see Annex C):
7776 1. to check the adequacy (completeness, consistency, correctness, relevance and traceability) of the
7777 documented evidence from review, integration and testing with the specified verification
7778 objectives;
7779 2. to identify anomalies, classify these in risk, impact or severity and/or weight as appropriate and
7780 record and communicate these to the relevant change control board for evaluation and decision,
7781 see also sub-clause on role of the verifier;
7782 3. to manage the verification process (review, integration and testing) and ensure independence of
7783 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 7.3.4.3.4 The results of each verification shall be retained in a format defined or referenced in the
7787 System Verification Plan.
7788 7.3.4.3.5 The System Verification Plan shall address the following:
7789 a) the selection of verification strategies, tools and techniques (to avoid undue complexity in the
7790 independent assessment of the verification and testing, preference shall be given to the selection
7791 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 h) the structure and contents of each verification step in a way that facilitates review against the
7799 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. Hardware Design Component Verification Report (see 9.1)
7803 d. Software/Hardware Integration Verification Report (see 8.2.4.8)
7804 7.3.4.4 The System Verification Reports (see 7.3.3) shall be written, under the responsibility of the
7805 Verifier, on the basis of the input documents. Requirement 7.3.4.4.1 refers to the System Verification
7806 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 h) the fulfilment of, or deviation from, the System Verification Plan (in the event of deviation the
7821 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 7.3.4.4.2 Analyses, if any, carried out during the verification shall be documented in accordance with
7825 clause 7.1.
7826 7.4 Validation

7828 7.4.1.1 The objective of validation is to demonstrate that the processes and their outputs are such
7829 that the system/sub-system or hardware component is of the defined safety integrity level, fulfils the
7830 related TFFR and the requirements, and is fit for its intended application.
7831 7.4.1.2 The main validation activities are to demonstrate by analysis and/or testing that all
7832 system/subsystem/hardware component requirements are specified, implemented, tested and fulfilled
7833 as required by the assigned SIL, and to evaluate the safety criticality of all anomalies and non-
7834 conformities based on the results of reviews, analyses and tests.
7835 7.4.1.3 This sub-clause deals with system/sub-system and hardware component validation. These
7836 activities are respectively performed by the Validator.
7837 7.4.1.4 For systems/sub-systems incorporating software, Software Validation as defined in EN

7838 50126-5 clause 7.4 shall be performed.
7839 7.4.2 Input
7840 All documentation for system/sub-system and/or hardware components as specified in this European
7841 Standard.
7843 1) Validation Plan
7844 2) Hardware Validation Plan
7845 3) Validation Report
7846 4) Hardware Validation Report

7847 NOTE: Especially for complex systems/subsystems, all HW-related validation activities can be reported in a separate
7848 document, called Hardware Validation Report, to be referred by the Validation report.
- 31 - prEN 50126-4
7850 7.4.4.1 The Validation activities shall be developed and performed, with their results evaluated, by a
7851 Validator with an appropriate level of independence as defined in clause 6.2.
7852 7.4.4.2 Validation shall be documented with, at least, a Validation Plan and a Validation Report, as
7853 defined in the following.
7854 7.4.4.3 A Validation Plan shall be written, under the responsibility of the Validator, on the basis of the
7855 input documents. Requirements from 7.4.4.3.1 to 7.4.4.3.6 refer to the Validation Plan.
7856 7.4.4.3.1 The Validation Plan shall include the justification of the selection of techniques from
7857 Annex A, Table A.10.
7858 7.4.4.3.2 The Validation Plan shall include a summary justifying the validation strategy chosen. The
7859 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 7.4.4.3.3 The Validation Plan shall identify the steps necessary to demonstrate the adequacy of any
7865 specification of the system/sub-system or hardware component to be validated, in fulfilling the
7866 requirements set out in the System Requirements Specification.
7867 7.4.4.3.4 The Validation Plan shall identify the steps necessary to demonstrate the adequacy of the
7868 System Test Specification as a test against the System Requirements Specification.
7869 7.4.4.3.5 The Validation Plan shall include a summary justifying the validation or testing strategy
7870 chosen for the hardware. The justification shall include consideration, according to the required safety
7871 integrity level.
7872 7.4.4.3.6 If, for completion of the tests, analyses are needed these analyses shall be carried out in
7873 accordance with clause 7.1.
7874 7.4.4.4 A Validation Report shall be written, under the responsibility of the Validator. Requirements
7875 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 7.4.4.4.2 The Validation Report shall fully state the related baselines for system/sub-system and/or
7878 hardware components, that have been validated.
7879 7.4.4.4.3 The Validation Report shall contain the evaluation of the requirements of the validated item
7880 against the intended environment/use.
7881 7.4.4.4.4 The Validation Report shall contain the evaluation of the validated item (system/sub-system
7882 and hardware components) against its requirements to ensure all of these are fulfilled.
7883 7.4.4.4.5 The Validation Report shall contain the evaluation of the conformity of the development
7884 process and of the validated item against the requirements of this European Standard including the
7885 assigned safety integrity level.
7886 7.4.4.4.6 The Validation Report shall contain the evaluation of the correctness, consistency and
7887 adequacy of the analyses and verification activities.
7889 adequacy of test cases and executed tests.
7890 7.4.4.4.8 The Validation Report shall contain the evidence that all Validation Plan activities have
7891 been carried out and shall capture and justify any deviation from the Validation Plan.
7892 7.4.4.4.9 The Validator shall also check whether the normative required Techniques and Measures
7893 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).
7896 adequacy of Hardware Manufacturing Acceptance Test Specification.
7897 7.4.4.4.12 The Validation Report shall contain the evidence of the correctness, consistency and
7898 adequacy of installation, commissioning, maintenance and operation manuals.
7899 7.4.4.4.13 The Validation Report shall contain a collection of results, restrictions and deviations, if
7900 any, from Software Validation Report and Hardware Validation Report, and their evaluation against
7901 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 7.4.4.5 A Hardware Validation Report shall be written, under the responsibility of the Validator, on
7905 the basis of the input documents. Requirement 7.4.4.5.1 refers to the Hardware Validation Report.
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 7.4.4.7 The Validator shall communicate all deviations to the relevant change control board for
7910 evaluation and decision.
7911 7.4.4.8 The system/sub-system or hardware component shall only be released for operation after
7912 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

7917 To arrive at a judgement through evaluation that the life cycle processes and their outputs are such
7918 that the system/sub-system or hardware component is of the defined safety integrity level 1-4 and is
7919 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).
7925 1) System Assessment Plan
7926 2) System Assessment Report
7928 7.5.4.1 The independent assessment of systems/sub-systems or hardware components shall be

7929 carried out by an Assessor who is independent as defined in clause 6.2.
7930 7.5.4.2 For SIL 0 system/sub-system or hardware components, requirements of this standard shall
7931 be fulfilled but where a certificate stating compliance with EN ISO 9001 is available, no independent
7932 assessment will be required.
7933 7.5.4.3 A system/sub-system or hardware component with an Assessment Report from another
7934 Assessor does not have to be an object for a new independent assessment. The independent
7935 assessment shall include the following:
7936 a) that the system/sub-system or hardware component is of the required safety integrity level and that
7937 it is fit for its intended use within the intended environment;
7938 b) a check that all relevant constraints are fulfilled.

7939 NOTE: All constraints in using a system/sub-system or hardware component with an Assessment Report from another
7940 Assessor are documented in a Release Note (see3.7).
7941 7.5.4.4 The Assessor shall have access to the development process and all project related
7942 documentation.
7943 7.5.4.5 A System Assessment Plan shall be written, under the responsibility of the Assessor, on the
7944 basis of the input documents from 7.5.2. Where appropriate, an existing documented generic system
7945 assessment plan or procedure may be used. The requirements from 7.5.4.5.1 to 7.5.4.5.2 refer to the
7946 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 7.5.4.6 The Assessor shall assess that the analysis from 8.1 on failures is complete and the
7955 system/sub-system or hardware component is fit for its intended use and responds correctly to safety
7956 related failures derived from the System Requirements Specification.
7957 NOTE: Related failures are addressed by System Hazard Analysis.
7958 7.5.4.7 The Assessor shall assess if an appropriate development process and an appropriate set of
7959 techniques, which are suitable for the intended development, has been selected in accordance to the
7960 required safety integrity level.
7961 7.5.4.8 Elimination of documents or development phases (see 6.1.4.11) are only allowed when
7962 accepted by the Assessor.
7963 7.5.4.9 The assessor shall consider the extent to which each technique is applied, and also look for
7964 evidence that it is properly applied.
7965 7.5.4.10 The Assessor shall assess the quality management system and the evidences on its use
7966 and application.
7967 7.5.4.11 The Assessor shall review the evidence of the competency of the project staff according to
7968 Annex C and shall assess the organisation for the system development according to clause 6.2 and
7969 6.3.
7970 7.5.4.12 For any system/sub-system or hardware component containing safety-related application
7971 conditions, the Assessor shall check for noted deviations, non-compliances to the system or hardware
7972 requirements and recorded non-conformities if these have an impact on safety, and make a judgment
7973 whether the justification from the project is acceptable. The result shall be stated in the assessment
7974 report.
7975 7.5.4.13 The Assessor shall assess the verification and validation and safety activities carried out in
7976 response to the safety requirements and the supporting evidence.
7977 7.5.4.14 The Assessor shall agree the scope and contents of the Quality Assurance Plan, the Safety
7978 Plan and the Validation Plan. This agreement shall also make a statement concerning the presence of
7979 the Assessor during testing.
7980 7.5.4.15 The Assessor may carry out audits and inspections (e.g. witnessing tests) throughout the
7981 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 7.5.4.16 A System Assessment Report shall be written under the responsibility of the Assessor.
7984 Requirements from 7.5.4.16.1 to 7.5.4.16.5 refer to the System Assessment Report.
- 35 - prEN 50126-4
7985 7.5.4.16.1 The System Assessment Report shall meet the requirements of the System Assessment
7986 Plan and provide a conclusion and recommendations.
7987 7.5.4.16.2 The Assessor shall record his/her activities as a consistent basis for the System
7988 Assessment Report. These have to be summarised in the System Assessment report.
7989 7.5.4.16.3 The Assessor shall identify and evaluate any non-conformities with the requirements of
7990 this European Standard and judge the impact on the final result. These non-conformities and their
7991 judgments shall be listed in the System Assessment Report.
7992 7.5.4.16.4 The System Assessment Report shall fully state the related baselines for system/sub-
7993 system 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 7.5.4.17 The Assessor shall deliver a verified System Assessment Plan (see 7.5.4.5) and System
7996 Assessment Report (see 7.5.4.16). This verification shall address:
7997 a) That the System Assessment Plan meets the specific requirements expressed in the sub-clauses
7998 7.5.4.5.1 to 7.5.4.5.2.
7999 b) That the System Assessment Report meets the specific requirements expressed in the sub-
8000 clauses 7.5.4.16.1 to 7.5.4.16.5.
prEN 50126-4 - 36 -
8001
8002 7.6 Quality Assurance

8004 7.6.1.1 To identify, monitor and control all those activities, both technical and managerial, which are
8005 necessary to ensure that the system/sub-system or hardware component achieves the quality
8006 required. This is necessary to provide the required qualitative defence against systematic failures and
8007 to ensure that an audit trail can be established to allow verification and validation activities to be
8008 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

8014 NOTE: The related report is the System Quality Management Report (see 8.2.4.23 which is part of or referenced by the Safety
8015 Case (see 8.2.4.21).
8016 2) Quality Assurance Verification Report
8018 7.6.4.1 The Quality Assurance Plan shall be issued at the beginning of the project and updated
8019 during the life cycle.
8020 7.6.4.2 The organisations taking part in the development of a system/sub-system or hardware
8021 component shall implement and use a Quality Assurance System compliant with ISO 9000 series, to
8022 support the requirements of this European Standard. EN ISO 9001 accreditation is highly
8023 recommended.
8024 7.6.4.3 A Quality Assurance Plan shall be written under the responsibility of the Quality Manager on
8025 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
8026 Quality Assurance Plan.
8027 7.6.4.3.1 A Quality Assurance Plan shall be written and shall be specific to the project.
8028 7.6.4.3.2 As a minimum, the following items shall be specified or referenced in the Quality Assurance
8029 Plan.
8030 a) Definition of the life cycle model:
8031 1) activities and elementary tasks consistent with the plans, e.g. Safety Plan, that have been
8032 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 - prEN 50126-4
8040 2) scope of distribution;
8041 3) archiving.
8042 d) Tracking and tracing of deviations.
8043 e) Methods, measures and tools for quality assurance according to the allocated safety integrity
8044 levels.
8045 f) Justifications that each combination of techniques or measures selected is appropriate to the
8046 defined safety integrity level.
8047 Some of the Quality Assurance Plan required information may be contained in other documents, such
8048 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 The sub-clause s of the Quality Assurance Plan shall reference the documents in which the
8055 information is contained. In any case the contents of each sub-clause of the Quality Assurance Plan
8056 shall be specified either directly or by reference to another document.
8057 7.6.4.4 A Quality Assurance Verification Report shall be written, under the responsibility of the
8058 Verifier, on the basis of the input documents from 7.6.2. The requirement in 7.6.4.4.1 refers to the
8059 Quality Assurance Verification Report.
8060 7.6.4.4.1 Once the Quality Assurance Plan has been established, verification shall address
8061 a) that the Quality Assurance Plan meets the general requirements for readability and traceability in
8062 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
8063 7.6.4.3.2,
8064 b) the internal consistency of the Quality Assurance Plan.
8065 7.6.4.5 Quality assurance activities, actions, documents, etc. required by all normative clauses of this
8066 European Standard shall be specified or referenced in the Quality Assurance Plan and tailored to the
8067 specific project.
8068 7.6.4.6 All relevant documents shall have a paragraph specifying details about its own updating
8069 throughout the project: frequency, responsibility, method.
8070 7.6.4.7 Each system/sub-system or hardware document and deliverable shall be placed under
8071 configuration control from the time of its first release.
8072 7.6.4.8 A Change Management Process has to be implemented so that it is guaranteed, that
8073 changes to all items under Configuration Management Control are recorded and authorised by a
8074 defined change control board.
8075 This extension, necessary for the reproducibility of the development and for the maintenance
8076 activities, shall include all the tools used in the development of the system/sub-system.
8077 7.6.4.9 The supplier shall establish, document and maintain procedures for control of the External
8078 Suppliers, including:
8079 - methods and relevant records to ensure that the parts of the system/sub-system or hardware
8080 component that are provided by external suppliers adhere to established requirements. Previously
prEN 50126-4 - 38 -
8081 developed systems/sub-systems or hardware components shall be assured to be compliant with

8082 the required safety integrity level and dependability. New systems/sub-systems or hardware
8083 components shall be developed and maintained in conformity with the Quality Assurance Plan of
8084 the Supplier or with a specific Quality Assurance Plan prepared by the external supplier in
8085 accordance with the Quality Assurance Plan of the Supplier;
8086 - methods and relevant records to ensure that the requirements provided to the external supplier
8087 are adequate and complete.
8088 7.6.4.10 Traceability to requirements shall be an important consideration in the validation of a safety-
8089 related system/sub-system or hardware component. Therefore Quality Assurance has to define
8090 measures to demonstrate the traceability throughout all phases of the life cycle.
8091 7.6.4.11 Within the context of this European Standard, and to a degree appropriate to the specified
8092 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 7.6.4.12 In special cases, e.g. pre-existing systems/sub-systems, or hardware components or

8098 prototypes, traceability may be established after manufacture, but prior to verification/validation. In
8099 these cases, it shall be shown that verification/validation is as effective as it would have been with
8100 traceability over all phases.
8101 7.6.4.13 Objects of requirements, design or implementation that can not be adequately traced shall
8102 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

8106 7.7.1.1 To identify, monitor and control all those activities, both technical and managerial, which are
8107 necessary to ensure that the system/sub-system or hardware component achieves the safety
8108 required.
8109 7.7.1.2 To provide evidence that the above safety activities have been carried out. The safety
8110 management is performed by the Safety Manager, a safety expert accompanying a development
8111 project and being responsible for the planning and implementation of the necessary safety activities.
8112 7.7.2 Input
8113 1) All the Specifications and Interface Specifications on system/sub-system component level in
8114 particular the Requirements Specifications and Architecture Specifications
8115 2) All the Test Specifications and Test Reports
8116 3) All the Verification Reports
8118 The following deliverables have to be provided on system and/or sub-system and/or component level
8119 appropriate to the project considered.
8120 1) Safety Plan
8121 2) Hazard Analysis
8122 3) Hazard Log
8123 4) Safety Case
8124 This sub-clause does not directly require the following output document, but provides guidance for its
8125 contents:
8126 5) System Hazard Analysis
8128 7.7.4.1 The System Safety Plan shall be written under the responsibility of the Safety Manager. The
8129 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 7.7.4.1.3 The System Safety Plan shall define the relationship and hierarchy between system safety
8137 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 7.7.4.1.4 The System Safety Plan shall define the interface to the independent assessment,
8141 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 b) independent assessment after finishing the phase “final acceptance” at the end of the
8145 development
8146 7.7.4.1.5 The System Safety Plan should define the interface to the regulatory authority, including
8147 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 7.7.4.1.8 The System Safety Plan shall define the strategy for selection of the measures given in the
8153 Annex A .
8154 a) The System Safety Plan shall define the safety based preconditions for each phase.
8155 7.7.4.1.9 The System Safety Plan shall defined the used model of independence of the roles from
8156 sub-clause 6.2.
8157 7.7.4.1.10 The System Safety Plan shall define the process of handling assumptions and constraints.
8158 7.7.4.1.11 The System Safety Plan shall define how the fulfilment of this standard for the
8159 parts/activities assigned to subcontractors is assured and demonstrated (review, audits, reports)
8160 7.7.4.1.12 The System Safety Plan shall identify the parts of this standard for which the
8161 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 7.7.4.2 A System Hazard Analysis shall be written under the responsibility of the Designer or of the
8165 Safety Manager on the basis of the System Architecture Specification. The requirement 7.7.4.1.1 refer
8166 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 i. a complete set of activities needed to react in way to fulfil the specified quantified safety
8172 target;
8173 ii. a complete set of conditions which shall be fulfilled after detection of the fault to ensure that
8174 the reached state can not cancelled out by any further fault (the system shall change in a
8175 state that a new single failure can not create a “hazardous event”);
8176 iii. procedures, measures and activities processed for cancellation of the reached state
8177 including the definition of the procedures, measures and activities processed during
8178 application of the future life cycle activities.
- 41 - prEN 50126-4
8179 d) for all measures where a fault is detected the detection time sufficiently short to fulfil the specified
8180 quantified safety target shall be calculated;
8181 e) for all measures where a fault is detected the negation time sufficiently short to fulfil the specified
8183 f) for all measures where a fault is detected the repair time sufficiently short to fulfil the specified
8185 g) the measures needed to ensure the avoidance of the fault during application of the future life cycle
8186 activities.
8187 7.8 Configuration Management and Modification Control

8189 The objectives of Configuration Management and Modification Process is to identify the configuration
8190 items and to define procedures for changing the sub-systems and hardware components of the
8191 system, which are already in field.
8192 7.8.2 Input
8194 2) All relevant design, development and analysis documentation
8195 3) Change impact analysis and authorisation
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)
8202 7.8.4.1 The Configuration Management shall clearly identify the configuration items of the
8203 system/sub-system or hardware components and ensure that the sub-systems and hardware
8204 components of the system perform as required, preserving the safety integrity level and dependability
8205 when modifying the sub-systems and hardware components of the system.
8206 7.8.4.2 The Modification Process shall ensure that the procedures for changing the sub-systems and
8207 hardware components of the system, which are already in field are defined (in cases of repair,
8208 replace, deployment).
8209 7.8.4.3 The Configuration Management and Modification Process under the responsibility of the
8210 Configuration Manager shall define at least the following aspects.
8211 a) Each LRU shall be clearly identified and have an independent version inside the configuration
8212 management system or should be a part of a collection of components (e. g. sub-system) which
8213 have an independent version;
8214 b) Full compatibility of LRUs (even if there are changes in its hardware components) shall be visible
8215 through their identifier;
8216 c) The configuration records shall at least identify all sub-systems and hardware-components and
8217 their versions;
prEN 50126-4 - 42 -
8218 d) Define the documentation needed for problem reporting and/or corrective actions, with the aim of
8219 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 g) Define the practices/processes to be followed for reporting, tracking and resolving problems
8223 identified both during the development phase and during maintenance and manufacturing;
8224 h) Define processes for change or repair of sub-systems and hardware components of the system
8225 which are already in the field;
8226 i) Define preventive actions to deal with problems to a level corresponding to the required safety
8227 integrity level;
8228 j) Define the specific organisational responsibilities with regard to development, maintenance and
8229 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 n) Impact analysis of the effect of the changes on the system/sub-systems and hardware
8234 components of the system under development or already delivered;
8235 o) Each change on an item under Configuration Management shall be recorded and authorised
8236 before implementation by a Change Control Board (see 7.6.4.8).
8237 7.8.4.4 All changes shall initiate a return to an appropriate phase of the life cycle. All subsequent
8238 phases shall then be carried out in accordance with the procedures specified for the specific phases
8239 in accordance with the requirements in this European Standard.
- 43 - prEN 50126-4
8240
8241 7.9 Support Tools

8243 7.9.1.1 The objective is to provide evidence that potential failures of tools do not adversely affect the
8244 integrated toolset output in a safety related manner that is undetected by technical and/or
8245 organisational measures outside the tool. To this end, tools are categorised into three classes
8246 namely, T1, T2 & T3 respectively.
8247 7.9.2 Input
8248 1) Tools specification or manual
8250 1) Tools validation report (when needed see 7.9.4.9 or 7.9.4.11)
8252 7.9.4.1 Tools shall be selected as a coherent part of the system/sub-system and hardware
8253 development and manufacturing activities.
8254 7.9.4.2 Appropriate tools to support the development and manufacturing should be used in order to
8255 increase the integrity by reducing the likelihood of introducing or not detecting failures during the
8256 development and manufacturing. Examples of tools relevant to the phases of the system/sub-system
8257 and hardware development life cycle include:
8258 a) transformation tools that convert a system/sub-system or hardware component design

8259 representation (e.g. a diagram) from one abstraction level to another;
8260 b) verification and validation tools, simulators and checkers;
8261 c) diagnostic tools used to maintain and monitor the system/sub-system and/or hardware
8262 components under operating conditions;
8263 d) infrastructure tools such as development support systems;
8264 e) configuration control tools such as version control tools;
8265 f) tools that produce or maintain data which are required to define parameters and to instantiate
8266 system/sub-system functions e.g. transmission rates, clock rates, communication parameters.
8267 7.9.4.3 The selected tools should be able to cooperate. In this context, tools cooperate if the outputs
8268 from one tool have suitable contents and format for automatic input to a subsequent tool, thus
8269 minimizing the possibility of introducing human error in the reworking of intermediate results.
8270 7.9.4.4 Tools should be selected to be compatible with the needs of the function, of the safety related
8271 system/sub-system or hardware component, and of the integrated toolset.
8272 7.9.4.5 The availability of suitable tools to supply the services that are necessary over the whole
8273 lifetime of the system/sub-system or hardware component should be considered.
8274 7.9.4.6 When tools are being used as a replacement for manual operations, the evidence of the
8275 integrity of tools output can be adduced by the same process steps as if the output was done in
8276 manual operation. These process steps might be replaced by alternative methods if an argumentation
8277 on the integrity of tools output is given and the integrity level of the system/sub-system or hardware
8278 component is not decreased by the replacement.
prEN 50126-4 - 44 -
8279 7.9.4.7 The selection of the tools in class T2 and T3 shall be justified (see 8.3.4.12). The justification
8280 shall include the identification of potential failures which can be injected into the tools output and the
8281 measures to avoid or handle such failures.
8282 7.9.4.8 All tools in classes T2 and T3 shall have a specification or manual which clearly defines the
8283 behaviour of the tool and any instructions or constraints on its use.
8284 7.9.4.9 For each tool in class T3 evidence shall be available that the output of the tool conforms to
8285 the specification of the output or failures in the output are detected. Evidence may be based on the
8286 same steps necessary for a manual process as a replacement for the tool and an argument if these
8287 steps are replaced by alternatives (e. g. validation of the tool). Evidence may also be based on:
8288 a) a suitable combination of documented history of successful use (project and applications realized,
8289 list of anomalies, identification of successive versions) in similar environments and for similar
8290 applications;
8291 b) tool validation as specified in 7.9.4.10;
8292 c) compliance with the safety integrity levels derived from the risk analysis of the process and
8293 procedures including the tools;
8294 d) other appropriate methods for avoiding or handling failures introduced by tools.
8295 NOTE 1: A version history may provide assurance of maturity of the tool, and a record of the errors / ambiguities associated
8296 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 e) the results of the validation activity; the documented results of validation shall state either that the
8304 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 7.9.4.11 Where the conformance evidence of 7.9.4.9 is unavailable, there shall be effective
8309 measures to control failures in the system/sub-system or hardware component that result from
8310 failures that are attributable to the tool.
8311 NOTE 1: See (7.9.4.14)
8312 In general for tools in the field of hardware design or manufacturing a tool validation will not be done and therefore the effective
8313 failure control is the standard procedure.
8314 NOTE 2: As an example, the fitness for purpose of a non-trusted transformation tool can be justified as follows:
8315 The output produced by the transformation tool has been subjected to a combination of tests, checks and analyses which are
8316 capable of ensuring the correctness of the output to an extent consistent with the target Safety Integrity Level. In particular, the
8317 following applies to all tests, checks and analyses.
8318 - Checks and analyses have been applied to the output or the hardware and shown to be capable of detecting the types of
8319 errors which might result from a defect in the transformation tool;
8320 - No more transformation with the transformation tool has taken place after testing, checking and analysis;
8321 - If further transformation with the transformation tool is carried out, all tests, checks and analyses will be repeated.
- 45 - prEN 50126-4
8322 In general for hardware design, non-trusted transformation tools are in use and therefore this is the standard procedure for
8323 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 a) have a transformation tool which has been evaluated for fitness for purpose including, where
8327 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 NOTE 1: The evaluation of a transformation tool may be performed for a specific application project, or for a class of
8332 applications. In the latter case all necessary information on the tool regarding the intended and appropriate use of the tool
8333 should be available to the user of the tool. The evaluation of the tool for a specific project may then be reduced to checking
8334 general suitability of the tool for the project and compliance to the “specification or manual” (i.e. proper use of the tool). Proper
8335 use might include additional verification activities within the specific project.
8336 NOTE 2: A validation suite may be used to evaluate the fitness for purpose of a transformation tool according to defined
8337 criteria, which should include functional and non-functional requirements.
8338 NOTE 3: In general the system/sub-system or hardware component design representation has no transformation tool. The
8339 transformation is done by the designer.
8340 7.9.4.14 Where 7.9.4.13 cannot be fully satisfied, the fitness for purpose of the design
8341 representation, and any additional measures which address any identified shortcomings of the design
8342 representation shall be justified and evaluated.
8343 7.9.4.15 Where automatic transformation takes place, the suitability of the automatic transformation
8344 for safety-related development shall be evaluated at the point in the development life cycle where
8345 development support tools are selected.
8346 7.9.4.16 Configuration management shall ensure that for tools in classes T2 and T3 only justified
8347 versions are used.
8348 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
8349 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 NOTE: Evidence that the new version is unlikely to contain significant new unknown failures may be based on a credible
8353 identification of the changes made, and on an analysis of the verification and validation actions performed.
8354 7.9.4.18 The relation between the tool classes and the applicable sub-clauses is defined within Table
8355 1.
Tool Class Applicable paragraphs

T1 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,
T2
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
T3 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
8356 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 This sub-clause defines requirements additional to those indicated in Part 1, Phase 5, specific for
8361 E/E/PE sub-systems or components.
8362 8.1.1 A safety integrity level shall be derived from the THR/TFFR for the hardware components and
8363 software components associated to a safety function.
8364 8.1.2 The System Architecture Specification shall identify all hardware/software interactions and any
8365 constraints between the hardware and the software components.
8366 8.1.3 The allocation of the system requirement to the subsystems and hardware/software
8367 components shall proceed taking into account the possibility of common cause failures.
8368 8.1.4 If common cause failures are identified, then the sub-systems and hardware/software
8369 components of the system shall not be treated as independent for the purposes of the safety integrity
8370 allocation.
8371 8.1.5 When transmission systems are used to transfer safety related information, communication
8372 protocols shall be designed according to EN 50159.
8373 8.1.5.1 If pre-existing sub-systems, software and hardware components are used to fulfil system
8374 requirements the System Architecture Specification shall address the following:
8375 a) identification of the pre-existing sub-systems, software and hardware components;
8376 b) relation between the system requirements and the pre-existing sub-systems, software and
8377 hardware components.
8378 8.1.6 The System Architecture Specification shall identify all hardware and software components
8379 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 8.1.7 During system architecture development a top-down, structured design methodology according
8383 to Annex A, Table A.5 shall be used.
8384 NOTE: For guidance on development of programmable devices see Annex E.
8385 8.1.8 It is necessary to ensure that the system/sub-system meets its TFFR in the event of single
8386 random fault. It is necessary to ensure that SIL 3 and SIL 4 systems remain safe in the event of any
8387 kind of single random hardware fault which is recognised as possible. Faults whose effects have been
8388 demonstrated to be negligible may be ignored. This principle, which is known as fail-safety, can be
8389 achieved in several different ways (see also Figure 4):
8390 1. composite fail safety

8391 This principle implies that each safety-related function is performed by at least two items. Each of
8392 these items shall be independent from all others, to avoid common-cause failures. Non-restrictive
8393 activities are allowed to progress only if the necessary number of items agree. A hazardous fault
8394 in one item shall be detected and negated in sufficient time to avoid a co-incident fault in a
8395 second item.
8396 2. reactive fail safety
8397 This principle allows a safety-related function to be performed by a single item, provided its safe
8398 operation is assured by rapid detection and negation of any hazardous fault (for example, by
8399 encoding, by multiple computation and comparison, or by continual testing). Although only one
- 47 - prEN 50126-4
8400 item performs the actual safety-related function, the checking/testing/detection function shall be
8401 regarded as a second item, which shall be independent to avoid common-cause failures.
8402 3. inherent fail safety
8403 This principle allows a safety-related function to be performed by a single item, provided all the
8404 credible failure modes of the item are non-hazardous. Any failure mode which is claimed to be
8405 incredible (for example, because of inherent physical properties) shall be justified using the
8406 procedure defined in Annex B. Inherent fail-safety may also be used for certain functions within
8407 Composite and Reactive fail-safe systems, for example to ensure independence between items,
8408 or to enforce shut-down if a hazardous fault is detected.
8409 Also a combination of these techniques can be adopted.
8410 8.1.9 After detection of a first fault, the system/sub-system/equipment shall enter, or continue in, a
8411 safe state. The safe state is generally (but not necessarily) more restrictive. The safe state shall be
8412 reached in a time sufficiently short that the combined detection-plus-negation time fulfils the specified
8413 safety target (see Figure 4).
8414 NOTE: The negation time is usually the time taken for the relevant part of the system to be shut down, either automatically or
8415 by human action.
8416 8.1.10 After detection of a first fault, and having entered the safe state, further faults shall not cancel
8417 out the safe state. Cancellation of a restrictive safe state shall occur only in a controlled manner, as
8418 part of a corrective procedure.
8419 8.1.11 The system/sub-system/equipment shall remain in a safe state if further faults occur during
8420 permissible delay-times-to-repair after occurrence of a first fault. Permissible delay-times-to-repair
8421 shall be sufficiently short to fulfil the specified safety target.
8422 8.1.12 During the development of the System Architecture Specification requirements for future life-
8423 cycle tasks can be established, including requirements for:
8424 a) Configuration
8425 NOTE: The requirements for the configuration should include:
8426 1. tools needed for the configuration including the tools manual
8427 2. procedures defining the configuration process
8428 3. verification and validation activities needed to ensure that the configuration is complete
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 For all requirements related to the environment the constraints shall be derived for the integration and
8437 the future life cycle task.
8438
prEN 50126-4 - 48 -
COMPOSITE FAIL-SAFETY
FUNCTION A
FAULT DETECTION
NEGATION
FUNCTION A
& OUTPUT
FUNCTION B
FUNCTION B
FAULT DETECTION
FUNCTION A
The probability of
DETECTION a 1st fault, combined with
the probability of a
FUNCTION B 2nd fault occurring
OUTPUT
during the 1st fault
SAFE
detection-plus-negation
T time T, shall be less than
STATE
the specified probabilistic
target.
FIRST DETECTION NEGATION SECOND
FAULT OF FIRST SWITCHES FAULT
OCCURS FAULT OFF OCCURS
IN A IN A OUTPUT IN B
REACTIVE FAIL-SAFETY
FUNCTION A
FAULT DETECTION
NEGATION
FUNCTION A OUTPUT
FUNCTION A
Detection-plus-negation
DETECTION time T, after a fault in A,
shall not exceed the
specified limit for the
duration of a transient,
OUTPUT potentially - hazardous
output.
SAFE
T
STATE
FAULT DETECTION NEGATION

OCCURS OF FAULT SWITCHES
IN A IN A OFF OUTPUT
8439
8440 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 1) The pre-existing hardware component shall be included in the validation process of the whole
8448 hardware.
8449 2) An analysis of the consequences of the possible failures of the pre-existing hardware
8450 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 1) An analysis of possible failures of the pre-existing hardware component and their
8453 consequences on the whole hardware shall be carried out.
8454 2) A strategy shall be defined to detect failures of the pre-existing hardware component and to
8455 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 2. that failures of the pre-existing hardware component are detected and the system
8459 where the pre-existing hardware component is integrated into is protected from these
8460 failures;
8461 3. that the assumptions about the environment of the pre-existing hardware component
8462 are fulfilled.
8463 d) The pre-existing hardware component shall be accompanied by a sufficiently precise (e.g. limited
8464 to the used functions) and complete description (i.e. functions, constraints and evidence). The
8465 description shall include hardware and/or software constraints and anomalies (and how they
8466 appear and their potential impact) of which the designer shall be aware and take into consideration
8467 during application. In particular it forms the vehicle for informing the designer of what the hardware
8468 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 8.1.14 The System Hazard Analysis shall identify the new hazards arising from the architecture and
8471 requirements to control these hazards shall be derived from that new hazards and allocated to the
8472 related sub-systems and/or hardware/software components. This hazard analysis should include, but
8473 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 8.1.14.1 The System Hazard Analysis shall identify all single random faults and provide for each
8478 single random fault the specification according to 7.7.4.2.
8479 8.1.14.2 The System Hazard Analysis for SIL3 and SIL4 systems/subsystems shall demonstrate that
8480 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 c) additional measures shall be exported to phases other than design. In this case, entities responsible for those activities
8490 should be involved for measures feasibility evaluation. If the additional measures have an impact also on operations after
8491 the commissioning (e.g. maintenance), the Railway authority should be involved for evaluation and acceptance of the
8492 measures.
8493 d) If the hazard is not related to any identified one, i.e. has not been found during risk analysis, this activity should be
8494 repeated, and a THR/TFFR for this new hazard shall be established. Then, all life cycle activities should be updated.
8495 8.1.14.3 For all single faults from 7.1.1.5.3 it shall be taken into account that another different fault
8496 occurs before the random single fault is repaired. These are the multiple random faults. “Hazardous
8497 events” can be caused by a combination of more than two different random single faults, so the
8498 System Hazard Analysis shall taken into account combinations of more than two different random
8499 single faults.
8500 8.1.14.4 The System Hazard Analysis shall identify all single faults from 8.1.14.1 and multiple faults
8501 from 8.1.14.3 which have an effect on more that one independent part at the same time. These are
8502 the common cause faults. For each common cause fault the specification according to 7.7.4.2.1 shall
8503 be provided.
8504 NOTE 1: Single and multiple faults include, but are not limited to:
8505 - random faults
8506 - systematic faults
8507 - unintended misuse (e.g.)
8508 - usage outside the specified environmental conditions (e.g. temperature, overvoltage, humidity, lightning)
8509 - sabotage, vandalism and loss of security (if necessary)
8510 NOTE 2: The following causes can lead to common cause failures:
8511 a) systematic development errors

8512 b) operation outside the required environmental conditions
8513 c) loss of independence among independent units
8514 8.1.14.5 For all calculations the sources of basic failure rate data used in the calculations (e.g.
8515 hardware component failure rates) shall be identified, and the method of quantitative analysis clearly
8516 explained and if possible also their uncertainty.
8517 8.1.14.6 The Sub-system/Component Integration Test Specification shall address the following:
8518 a) it shall be shown that the software runs correctly on the hardware and uses the hardware via the
8519 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 d) the required input data with their sequences, timing and values, specified in the software/hardware
8523 interface specifications, shall be the basis of the analyses and test cases;
- 51 - prEN 50126-4
8524 e) the expected output data with their sequences, timing and values, specified in the
8525 software/hardware interface specifications, shall be the basis of the analyses and test cases.
8526 f) it shall be shown that the hardware components deliver correct responses and functions via the
8527 specified hardware interfaces.
8528 NOTE: The system architecture is an iterative process, so the System Architecture and Design Verification Report can be
8529 prepared iteratively.
8530 8.2 Integration and Validation

8532 8.2.1.1 The objectives of the requirements of this sub-clause are to:
8533 1. Integrate all sub-systems, hardware components and software components, demonstrating their
8534 correct functional operation;
8535 2. demonstrate that the required TFFR and/or safety integrity level have been achieved, taking into
8536 account the apportionment of the requirements to the sub-systems, hardware components and
8537 software components;
8538 3. establish plans containing the requirements for future life cycle tasks with respect to manufacture,
8539 configuration, installation, commissioning, operation and maintenance and specifying the
8540 requirements for those future life cycle tasks.
8541 8.2.2 Input
8542 1) Software/Hardware Integration Test Specification
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
8550 8.2.4.1 The integration of the system shall be the process of testing progressively combined
8551 individual and previously integrated/tested sub-systems and hardware/software components into a
8552 composite whole in order that the components interfaces and the assembled sub-system and
8553 hardware/software components may be adequately proven.
8554 8.2.4.2 During integration any modification or change to the integrated system shall be subject to a
8555 safety impact analysis which shall identify all sub-systems and hardware/software components of the
8556 system impacted and the necessary re-verification activities.
8557 NOTE: This impact study isn’t necessary when:
8558 a) the change does not impact the single [sub-systems/hardware and Software] components, or
8559 b) after the change the integration test specifications be updated according to the change and the integration completed.
8560
8561 8.2.4.3 When the safety impact analysis on the modification or change has been completed, an
8562 analysis shall be undertaken to determine whether any reasonably foreseeable failure of the
8563 modification or change of the system could cause a “hazardous event” or place a demand on the
8564 requirements for the future life cycle tasks (see 8.1.12). If any reasonably foreseeable failure could
8565 have either of these effects, then the first priority shall be to use a change or modification where such
8566 failure modes shall be avoided. If this cannot be done, measures shall be taken to reduce the
prEN 50126-4 - 52 -
8567 likelihood of such failure modes to a level commensurate with the target failure measure. These
8568 measures shall be subject to the requirements of this standard.
8569 8.2.4.4 The integration shall show that all hardware/software components of the sub-system interact
8570 correctly as specified in the related interface specifications (software/software, software/hardware,
8571 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 NOTE: Examples of safety requirements relying on SW-HW integration are: test of the hardware through software; reaction
8578 time of the software to a hardware fault.
8579 8.2.4.7 The software/hardware integration for performance and timing shall be specified according to
8580 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 8.2.4.9 During the integration of the subsystems and hardware/software components of the system
8588 the fulfilment of all constraints defined for that subsystems and hardware/software components shall
8589 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 a) shall state the test results and whether the objectives and criteria of the System Integration Test
8593 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 8.2.4.11 The validation shall show that all of the specified system requirements are correctly met and
8599 the system does not perform unintended functions.
8600 8.2.4.12 When discrepancies occur between expected and actual results, the analysis made, and the
8601 decisions taken on whether to continue the validation or issue a change request and return to an
8602 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 8.2.4.15 During the integration of the system plans shall be established, containing the requirements
8606 for future life-cycle tasks, including plans for:
8607 a) Configuration;
8608 Note: The requirements for the configuration should include:
8609 1. tools needed for the configuration including the tools manual
8610 2. procedures defining the configuration process
8611 3. verification and validation activities needed to ensure that the configuration is complete
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 a) procedures for the safe assembly of the Hardware and the safe connection of the hardware with its
8621 interfaces;
8622 b) tests to verify that the assembling, connection and calibration has been correctly performed.
8623 8.2.4.17 The system installation, commissioning, operation and maintenance procedures shall be
8624 defined and validated based on test and/or analysis. If adequate independence or decoupling
8625 between individual sub-systems and hardware/software components cannot be demonstrated
8626 analytically, the related combinations of functional behaviour shall be tested.
8627 8.2.4.18 When the validation of the system needs results from the future life cycle tasks identified in
8628 8.1.12, the validation can be finished when all restrictions derived from that incomplete validation
8629 have been transferred into conditions and constraints for the related future life cycle tasks from
8630 8.1.12. Otherwise the validation can be finished after the results from the future life cycle tasks
8631 identified in 8.1.12 are present.
8632 8.2.4.19 For the avoidance of failures during the validation an appropriate group of techniques and
8633 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 d) the requirements from the System Requirement Specification and the System Architecture
8639 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 5. non-compliances and any safety constraints arising from the deviations between expected and
8645 actual results of tests and/or analyses;
prEN 50126-4 - 54 -
8646 6. conditions and constraints derived from the deviations between expected and actual results of
8647 tests and/or analyses for the future lifecycle tasks identified in 8.2.4.15 in terms of the impact
8648 to the future life cycle tasks and traceable to the deviations.
8649 e) tools and equipment used, along with calibration data;
8650 f) configuration identification of the item under validation, the procedures applied and the validation
8651 environment;
8652 g) a statement on the completion of the verification process with respect to the System Verification
8653 Plan (see 7.3.4.3) and the Verification Reports (see 7.3.4.3.5 h).
8654 h) a summary statement on the tests results and whether the whole system in its environment fulfils
8655 the requirements set out in the System Requirements Specification and System Architecture
8656 Specification;
8657 i) statement of appropriate identification of technical support tools and equipment;
8658 j) statement of appropriate identification of simulation models used;
8659 k) an evaluation of the test coverage on the requirements in the System Requirements Specification
8660 and System Architecture Specification;
8661 l) the result of the check that the requirements tracing is fully performed and covered;
8662 m) if the Validator produces own test cases not given to the Tester or Integrator the System Validation
8663 Report shall document these.
8664 n) a statement that the project has performed appropriate handling of corrective actions in
8665 accordance with the change management process and procedures and with a clear identification
8666 of any discrepancies found;
8667 o) a statement that the development has been carried out under control of an appropriate
8668 organization as defined in 6.2, using competent personnel assigned to specific roles.
8669 p) a conclusion whether the system is fit for its intended application, taking into account the
8670 application conditions the validation results and constraints.
8671
8672 8.2.4.19.2 The System Validation Report shall contain the confirmation that each combination of
8673 techniques or measures selected according to Annex A, Table A.10 is appropriate to the defined
8674 safety integrity level. It shall contain an evaluation of the overall effectiveness of the combination of
8675 techniques and measures adopted, taking account of the size and complexity of the system produced
8676 and taking into account the actual results of testing, verification and validation activities.
8677 8.2.4.20 The System shall be exercised either by connection to real items of hardware components
8678 or actual systems with which it would interface in operation, or by simulation of input signals and loads
8679 driven by outputs. It shall be exercised under conditions present during normal operation, anticipated
8680 occurrences and undesired conditions requiring system action. Where simulated inputs or loads are
8681 used it shall be shown that these do not differ significantly from the inputs and loads encountered in
8682 operation.
8683
8684 NOTE: Simulated inputs or loads might replace inputs or loads which are only present at system level or in faulty modes.
8685 8.2.4.21 A Release Note shall be produced, that:
8686 - includes a functional description of the system/sub-system.

8687 - Includes all external interfaces provided by the system/sub-system.
8688 - identifies all plans for the future life cycle tasks, identified by 8.1.12.
8689 - includes all constraints in using the system.
8690 Among these constraints, Safety-Related Application Conditions shall be clearly identified or referred.
8691
8692 NOTE: These constraints should be derived from:
- 55 - prEN 50126-4
8693 a) the detected errors,

8694 b) non-compliances with this European Standard,
8695 c) degree of fulfilment of the requirements,
8696 d) degree of fulfilment of specifications and plan.
8697 e) results of the validation.
8698 8.2.4.22 The Generic Product/Application Safety Case shall precisely identify the system/sub-system
8699 and all the documentation of the system/sub-system to which the System Safety Case refers (see
8700 Table A.1 Lifecycle Issues and Documentation).
8701 8.2.4.22.1 The Generic Product/Application Safety Case shall fully state the related baselines for
8702 system/sub-system, hardware components, that have been considered.
8703 8.2.4.22.2 The Generic Product/Application Safety Case Safety Case shall summarise the evidence
8704 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 and argue that the system/sub-system, to which the System Safety Case refers, is adequately safe
8709 under the defined safety-related application conditions and adequate compliance against the
8710 requirements of this standard.
8711 NOTE: Additional national requirements can also be included in the summary.
8712 8.2.4.22.3 The Generic Product/Application Safety Case Safety Case shall demonstrate that
8713 appropriate protection measures have been taken to ensure random, systematic and unintended
8714 misuse based failures on external interfaces do not adversely impact on the safety integrity of the
8715 system.
8716 8.2.4.22.4 The Generic Product/Application Safety Case shall identify the related safety cases,
8717 including their safety-related Application Conditions.
8718 8.2.4.23 The System Quality Management Report shall be written under the responsibility of the
8719 Quality Manager. Requirement 8.2.3.20.1 refers to the System Quality Management Report.
8720 NOTE: Examples of aspects which should be controlled by the quality management system and included in the Quality
8721 Management Report:
8722 - organisational structure;

8723 - documentation and records management;
8724 - quality planning and policy;
8725 - quality audits and follow-up;
8726 - specification of requirements;
8727 - design planning and control;
8728 - design verification and reviews;
8729 - purchasing;
8730 - production and service provision;
8731 - product identification and traceability;
8732 - preservation of the product;
8733 - non-conformance and corrective action management;
8734 - monitoring and measurement;
8735 - personnel competency and training.
8736
8737 8.2.4.23.1 The System Quality Management Report shall summarize the degree of compliance of the
8738 following plans:
8739 1. Quality Assurance Plan (see 7.6.4.3.1) and

8740 2. Configuration Management Plan (see 7.8.4.3).
8741 For any deviation from the plans an argumentation shall be given that the safety and functionality of
8742 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 7. that for all deviations adequate measures are defined and evidence of the reception of the
8751 measures by the stakeholder is given.
8752 8.2.4.24.1 The Safety Management Report shall provide evidence that a change management
8753 process has been established also for change requests raised from the future life cycle task (see
8754 8.1.12 for the future life cycle task). The established change management process shall be compliant
8755 to requirements listed in 7.8.
8756 8.2.4.24.2 The Safety Management Report shall provide evidence that the Hazard Log has been
8757 created and updated according to requirements defined in 8.2.4.26. A statement shall be made about
8758 Hazard Log contents, in terms of the closure of each hazard, by technical measures or through
8759 application conditions correctly exported to successive phases of the life cycle (see 6.1.4).
8760 8.2.4.24.3 The Safety Management Report shall provide evidence that Safety reviews and Safety
8761 audits have been carried out at appropriate stages in the life cycle, as specified in the Safety Plan
8762 (see 7.7.4.1), and their results fully documented. This evidence can be provided trough reference to
8763 the documented safety reviews results.
8764 8.2.4.25 The Technical Safety Report shall include a summary of the technical safety principles (see
8765 8.1.8) and the used standards (e.g. safety and technology specific standards).
8766 8.2.4.25.1 The Technical Safety Report shall argue that all functional constraints resulting from the
8767 results of verification and validation are correctly reflected in application conditions of the sub-
8768 system/component.
8769 8.2.4.25.2 The Technical Safety Report shall identify by references all documentation describing the
8770 system architecture and specify the relation between these documents.
8771 8.2.4.25.3 The Technical Safety Report shall demonstrate that the Man-Machine, Configuration and
8772 Maintenance interfaces are defined completely (with a reference to the documents from 8.1.12). The
8773 Man-Machine interfaces shall be designed and validated by means of well-established methods and
8774 techniques for human factors engineering.
8775 8.2.4.25.4 The Technical Safety Report shall demonstrate that the interfaces of the system at the
8776 boundary of the system (external interfaces) are defined completely (normal operation and dedicated
8777 modes) and that the system meets the interface specification of external systems.
8778 NOTE: All interfaces at the boundary of the system are identified in the System Requirements Specification, see Part 1 –
8779 Clause 8.5.
8780 8.2.4.25.5 The Technical Safety Report shall demonstrate that the interaction between the
8781 components (software and/or hardware) of the system are defined completely (normal operation and
8782 dedicated modes) and is correct implemented according to the related interface specifications.
8783 NOTE: The interface between the components (software and/or hardware) are described and identified in the system
8784 architecture specification, see 8.1.
- 57 - prEN 50126-4
8785 8.2.4.25.6 The Technical Safety Report shall show that the system requirements, including the
8786 system safety requirements, are met and that constraints are derived from the deviations (as a
8787 reference to the “release note”).
8788 8.2.4.25.7 The Technical Safety Report shall identify all system/subsystems/software and hardware
8789 components of the system.
8790 8.2.4.25.8 The Technical Safety Report shall identify the system/subsystems/software and hardware
8791 validation reports of each subsystem or component of the system.
8792 8.2.4.25.9 The Technical Safety Report shall summarise the results of the validation reports of each
8793 subsystem or component of the system with respect to the non-compliances and deviations.
8794 8.2.4.25.10 The Technical Safety Report shall demonstrate that a complete set of constraints is
8795 derived from the non-compliances and deviations documented in the validation reports for each
8796 subsystem or component of the system and included in the “release note” (see 8.2.4.21).
8797 NOTE: If an assessment report or a safety case and a “release note” exist for the subsystems or components these should be
8798 used instead of the validation report.
8799 8.2.4.25.11 The Technical safety report shall show that the independent parts are independent. This
8800 should be done by a reference to the system architecture including the additional requirements for
8801 independence and the results of the validation.
8802 8.2.4.25.12 In addition to the quality and safety management techniques which are used to minimise
8803 systematic failures, technical measures shall be taken such that if a hazardous systematic fault
8804 should exist, it would, as far as reasonably practicable, be prevented from creating an hazardous
8805 event. In the Technical Safety Report shall be shown that the technical measures are in place and
8806 sufficient (as a reference to the system architecture).
8807 8.2.4.25.13 The Technical Safety Report shall show that the requirements of the environmental
8808 conditions (climatic, mechanical, altitude, electrical and electromagnetic) are met. This should be
8809 done by identifying the reports for checking the requirements of the environmental conditions
8810 (climatic, mechanical, altitude, electrical and electromagnetic). This can also be achieved by a
8811 reference to the validation report (see 7.4.4.4.1 to 7.4.4.4.14)
8812 8.2.4.25.14 The Technical Safety Report shall demonstrate that inputs via the external interfaces
8813 (random failures, systematic faults, misuse) cannot bring the system in an hazardous state. This
8814 should be done as a reference to the validation report.
8815 NOTE: For the man-machine interface handling errors should be included.
8816 8.2.4.25.15 The Technical Safety Report shall identify the complete documentation which includes
8817 the safety related requirements for the future life cycle task’s identified by 8.1.12 or the integration of
8818 the system as a sub-system into a system.
8819 8.2.4.25.16 The Technical Safety Report shall demonstrate that the set of safety related
8820 requirements for future life cycle task identified by 8.1.12 or integration of the system as a sub-system
8821 into a system is complete.
8822 8.2.4.25.17 The Technical Safety Report shall demonstrate that all properties, from the view of the
8823 architecture and implementation of the system/sub-system, which shall be included in the safety
8824 qualification tests, are specified. The purpose of these tests is
8825 - to gain increased confidence that the system/sub-system/equipment fulfils its specified
8826 operational requirements,
8827 - to gain increased confidence that the specified reliability and safety targets have been achieved,
8828 - to allow systems/sub-systems/equipment to be put into operational service before final Safety
8829 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 8.2.4.25.18 The Technical Safety Report shall demonstrate that the set of safety related
8833 requirements is referenced by (especially documents from the sub-clause 8.1.12) or included in the
8834 “release note” (see 8.2.4.21).
8835 8.2.4.26 The Hazard Log shall be written under the responsibility of the Safety Manager, on the basis
8836 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 8.2.4.26.3 For all “hazardous event” which are detected and resolved before final acceptance the
8845 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 8.2.4.26.4 For all other “hazardous event”, which have an influence on the future life cycle phases
8851 identified by 8.1.12, the hazard log shall additionally, to the information from 8.2.4.26.3, include for
8852 each “hazardous event”:
8853 1. risk (consequences and rate);

8854
8855 NOTE: In general risk is out of scope for the supplier. But for failures in the system/sub-system, hardware component and
8856 software component a risk based view is really helpful.
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 8.2.4.26.6 For all “hazardous events” for which no solution is planned the measures shall be included
8864 in one of the plans from Table A.1.
8865
- 59 - prEN 50126-4
8866
8867 9. E/E/PE DEVELOPMENT: GENERIC HARDWARE

8868 All the activities described in this chapter can be partially or completely performed once or several
8869 times to prototyping the hardware to be developed, gaining confidence in its development. In any
8870 case, all the activities shall be performed at least once to produce the final version.
8871 9.1 Hardware Component Specification

8873 9.1.1.1 To describe a complete set of requirements for the non-configurable hardware of fixed
8874 functionality meeting all system and safety requirements. It provides a comprehensive set of
8875 documents for each subsequent phase and makes it unnecessary to search for requirements in any
8876 other document.
8877 9.1.1.2 To develop the hardware components, according to the defined architecture, that achieve the
8878 hardware requirements.
8879 9.1.1.3 To identify and evaluate the significance of internal and external interactions for safety
8880 (included hardware/software interactions)
8881 9.1.1.4 To ensure that the resultant hardware will be readily testable from the outset. As verification
8882 and test will be a critical element in the validation, particular consideration shall be given to verification
8883 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
8888 1) Hardware Component Specification
8889 2) Hardware Component Test Specification
8890 3) Hardware Component Verification Report
8891 9.1.4 Activities
8892 9.1.4.1 A Hardware Component Specification shall be written. The requirements from 9.1.3.1.1 to
8893 9.1.3.1.6 refer to the Hardware Component Specification.
8894 NOTE: The Hardware Component Requirements may be an output of the system architecture (see 8.2.4) when the hardware
8895 requirements found during the system architecture are completely described and no need arise for a more detailed hardware
8896 requirements (e.g. this could happen for simple systems, or when no specific hardware shall be designed).
8897 9.1.4.1.1 The Hardware Component Specification shall express the required properties of the
8898 hardware Component being developed. These properties shall include
8899 a) functional description (number of inputs and outputs and response time performance), including
8900 operation modes
8901 b) identification of safety-related functions including their safety integrity levels,
8902 c) reliability, availability and maintainability,
8903 d) operation with external influences (e.g. environmental conditions) (see also EN 50121, EN 50124,
8904 EN 50125 and for rolling stock EN 50155),
prEN 50126-4 - 60 -
8905 e) information exchanged with other components, including sequencing and time related
8906 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 c) redundancy and diversity of input/output information (e.g. two contacts associated to each input, one normally open and the
8916 other normally closed.
8917 9.1.4.1.2 The Hardware Component Specification shall include requirements for the periodic testing
8918 of HW functions and components, to the extent required by the Architecture Specification or by the
8919 Subsystem Hazard Analysis, according to allocated TFFR.
8920 9.1.4.1.3 The Hardware Component Specification shall include requirements for the operator
8921 interactions with the hardware (e.g. LED, test points, hot-swap, electrical safety).
8922 9.1.4.1.4 All relevant modes of behaviour of the hardware, in particular failure behaviour, shall be
8923 documented or referenced (e.g. system level documentation) in the Hardware Components
8924 Specification.
8925 9.1.4.1.5 The Hardware Component Specification shall identify all technology related standards
8926 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 9.1.4.1.6 The Hardware Component Specification shall include constraints derived from the
8929 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 9.1.4.1.8 All software used to perform hardware component testing shall be developed and managed
8939 according to clause 7.9.
8940 9.1.4.1.9 Once the Hardware Component Specification and the Hardware Component Test
8941 Specification have been established, Hardware Component Verification shall address:
8942 a) the adequacy of the Hardware Component Specification in fulfilling the requirements set out in the
8943 Sub-System Architectural Specification;
- 61 - prEN 50126-4
8944 b) that the Hardware Component Specification meets the general requirements for readability and
8945 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
8946 9.1.3.1.1 to 9.1.3.1.6;
8947 c) the internal consistency of the Hardware Component Specification and of the Hardware
8948 Component Test Specification;
8949 d) the adequacy of the Hardware Component Test Specification against the Hardware Component
8950 Specification.
8951 NOTE: If the Hardware Component Specification is an output of the sub-system architecture (see 8.1), then its verification too
8952 is addressed in the sub-system architecture and apportionment phase.
8953
8954 9.2 Hardware Component Implementation

8956 9.2.1.1 To develop a hardware design that achieves the requirements of the Hardware Architecture
8957 Specification to the extent required by the safety integrity level.
8958 9.2.1.2 To develop an Hardware Design Test Specification that achieves the requirements of the
8959 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.
8962 1) Hardware Design Specification
8963 2) Hardware Manufacturing Data
8965 9.2.3.1 The Hardware Design Specification shall be based on the safety principles see 8.1.8..
8966 9.2.3.2 The Hardware Design Specification shall give detailed design information of the hardware
8967 component.
8968 9.2.3.3 The Hardware Design Specification shall address:
8969 a) configuration history, including a precise identification of the current and all previous versions,
8970 specifying date and designer, and a description of the changes made from the previous version;
8971 b) standards to be used for implementation
8972 9.2.3.4 The Hardware Design Specification shall choose the components for inherent fail safe
8973 hardware circuits taking into account the failure modes described into ANNEX B.
8974 9.3 Hardware Component Validation

8976 To analyse and test the Hardware Component to ensure compliance with the Hardware Component
8977 Specification with particular emphasis on the functional and safety aspects, according to the TFFR
8978 and to check whether it is fit for its intended application.
prEN 50126-4 - 62 -
8980 1) Hardware Component Test Report
8981 2) Hardware Component Safety Verification
8982 3) Hardware Component Validation Report
8984 9.3.3.1.1 The Validator shall specify and perform supplementary tests on his discretion or have them
8985 performed by the Tester. While the Hardware Tests are mainly based on the structure of the
8986 Hardware Requirements Specification, the added value the Validator shall contribute, are tests which
8987 stress the system by complex scenarios reflecting the actual needs of the user.
8988 9.3.3.1.2 The results of all tests and analyses shall be recorded in a Hardware Component Test
8989 Report.
8990 9.3.3.1.3 All degraded modes of behaviour of the hardware, in case of failure, shall be documented.
8991 9.3.3.2 The Hardware Safety Verification shall identify the new hazards arising from the design. To
8992 control these hazards, mitigations shall be derived from that new hazards and allocated to the related
8993 hardware components. This hazard analysis fulfils the requirements from 7.1.
8994 9.3.3.3 The Hardware Safety Verification shall be based on the Hardware Design Specification and
8995 on the Hardware Manufacturing data and shall check whether the Hardware Component meets the
8996 safety requirements as established in Architecture Specification, Hardware Component Specification
8997 and Hardware Detailed Design, using appropriate techniques as described in Table A.7 (e.g.
8998 insulation distance measurement, FMECA using elements failure modes, …).
8999 9.3.3.4 For inherent fail-safe hardware, the Hardware Safety Verification shall check the correctness
9000 of each element selection.
9001 9.3.3.5 The Hardware Component Validation shall:
9002 a) state whether the planned objectives and criteria for the HW Component validation have been met.
9003 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

9013 10.1.1.1 To describe a complete set of requirements for the configurable hardware of alterable
9014 functionality meeting all System and Safety Requirements. It provides a comprehensive set of
9015 documents for each subsequent phase and makes it unnecessary to search for requirements in any
9016 other document.
9017 10.1.1.2 All the requirements for the generic hardware apply to configurable hardware. However,
9018 additional requirements are described here.
9019 10.1.2 Input
9020 See 9.1.2
9022 See 9.1.3
9024 10.1.4.1 All the configurable states shall be described and treated as separate generic hardware
9025 designs where distinct functionalities may arise as a consequence of soft or hard configuration.
9026 10.1.4.2 The requirements described in clause 9 of this standard for generic hardware are applicable
9027 to each distinct class of functionality.
9028 10.1.4.3 Where a significant extent of functionality is unaltered through reconfiguration, the common
9029 functionality shall be treated once but each changed functionality shall be treated as a separate
9030 generic hardware.
9031 10.1.4.4 Where a common functionality is identified, the scope of regression testing for every
9032 hardware configuration shall be subject to an impact analysis. The independence of the
9033 hardware/system configuration states shall be considered in the extent and scope of testing.
9034 NOTE: Impact analysis shall also consider the need for environmental, mechanical, electrical and electromagnetic compatibility
9035 tests as appropriate to the nature of new configurations.
prEN 50126-4 - 64 -
9036
9037 11. E/E/PE SYSTEMS OPERATION AND MAINTENANCE

9038 NOTE: The term System Deployment is meant to cover the early operation of the system (post commissioning) as well as the
9039 complete operation, including retrofit, of the system until its decommissioning.
9040 11.1 Planning & Organisation

9042 The objective of this sub-clause is to detail the key organisational responsibilities for assurance of the
9043 safe deployment and maintenance of the electronic system and hardware delivering the safety
9044 functions during the Operation and Maintenance phase.
9045 11.1.2 Input
9046 1) Operation and Maintenance requirements from Designer, Manufacturer, Operations Manager and
9047 Maintenance Manager.
9049 1) Operation and Maintenance Plan
9051 11.1.4.1 During the Operation and Maintenance phase those who are responsible for operating and
9052 maintaining the safety related system/sub-system/hardware shall agree on an Operation and
9053 Maintenance Plan that includes roles and responsibilities of parties responsible for activities specified
9054 below. It is the responsibility of the Safety Manager to manage the safety aspects of this plan.
9055 11.1.4.2 Performance Monitoring including maintaining the Hazard Log / Safety Related Application
9056 Conditions (SRAC’s), Failure Reporting and Corrective Action System (FRACAS), incident and
9057 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 11.1.4.9 The activities specified in 8.12.2.2 of EN 50126-1 shall be implemented in the Operations
9065 and Maintenance plan.
9066 11.1.4.10 The roles and responsibilities defined in the Operation and Maintenance Plan shall define
9067 sufficient level of independence between entities responsible for safety and entities responsible for
9068 the execution of maintenance and operation. Depending on the SIL of the system function (delivered
9069 by the system/subsystem and/or hardware) the following level of independence shall apply:
9070 a) In SIL 3 and 4 applications the entity responsible for safety of the system shall have budgetary and
9071 reporting independence from the entity responsible for operations and maintenance.
9072 b) In SIL 0, 1 and 2 applications the entity responsible for safety may have budgetary and reporting
9073 independence from the entity responsible for operations and maintenance.
9074 NOTE: The availability of safety resources should be carefully evaluated to ensure that the necessary skills are available
9075 according to the needs of the operation and maintenance organisations. After the initial operation and maintenance phase the
9076 safety organisation may need to be reviewed to match the likely reduction in the scope and intensity of work.
- 65 - prEN 50126-4
9077 11.1.4.11 The Operation and Maintenance Plan shall show that the operation and maintenance
9078 organisation is capable of fulfilling all safety requirements outlined in following sub-clause s 11.1.4.12
9079 to 11.1.4.14, assuring sufficient quality (acceptable level of systematic or deterministic errors) related
9080 to the required SIL of the electronic system/ subsystem functions.
9081 11.1.4.12 The Operation and Maintenance Plan shall be reviewed regularly and updated as required.
9082 The process to undertake reviews shall be defined in the Operation and Maintenance Plan.
9083 NOTE: These updates shall include issues raised and addressed during the initial operation and maintenance phase and at
9084 appropriate stages thereafter.
9085 11.1.4.13 The Operation and Maintenance Plan shall define the process of handling hazardous
9086 incidents and accidents. The management of the hazardous incident and accident investigation and
9087 management process and organisation shall be independent of the management of the operation and
9088 maintenance organisations.
9089 11.1.4.14 The Operation and Maintenance Plan shall define for systems undergoing modification, a
9090 process for identifying and implementing mitigation actions proportionate to the identified risk. These
9091 mitigation actions shall ensure the overall integrity of the system whilst the modification is completed
9092 or reported problems are investigated and corrected.
9093
9094 11.2 System Deployment

9096 11.2.1.1 To ensure that the system performs within the required parameters, preserving the required
9097 system safety integrity level, when it is put into service (deployed) in an existing system that is under
9098 operation or as a completely new system (green field).
9099 11.2.1.2 To ensure that the system performance is closely monitored and controlled until confidence
9100 in the system performance, including the performance of the operators and maintainers, is achieved
9101 so that the system can be operated normally.
9102 NOTE: The system that will be put into service can be an extension or the replacement of equipment by an updated version. In
9103 both cases there is an interface with other systems that are under operation and the organisation of operation and
9104 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
9113 8) Operation and Maintenance Manuals
9114 9) SRACs
9115 10) Maintenance procedures
9116 11) Operational procedures
9117 12) Test Logs

prEN 50126-4 - 66 -
9118 13) Operational Manuals
9119 14) Operational Training Certificates
9120 15) Spares Strategy
9121 16) Maintenance Training Certificates
9122 17) Emergency Services Notifications
9123
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
9134 11.2.4.1 An operations and maintenance organisation as required in the Operation and Maintenance
9135 Plan shall be in place prior to the deployment of the system.
9136 11.2.4.2 An Operation and Maintenance Plan as required in 11.3.4.1 shall be available and
9137 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 11.2.4.4 Before delivering a system, the system baseline shall be recorded and kept traceable under
9140 configuration management control.
9141 11.2.4.5 A System Deployment Plan shall be written under the responsibility of the Project Manager.
9142 The activities specified in 8.12.4.4 of EN 50126-1 shall be implemented in the System Deployment
9143 Plan.
9144 11.2.4.5.1 If the system is to be deployed in phases, the System Deployment Plan shall have clear
9145 phases for system deployment identified. For each phase it shall define which
9146 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 11.2.4.5.3 For each phase, tests evidencing the correct operations shall be defined, including pass
9149 fail criteria.
9150 11.2.4.5.4 In case of the system being deployed within the existing railway, a rollback procedure (i.e.,
9151 capability to return to the previous release) shall be available for each phase in the deployment.
9152 11.2.4.5.5 The impact on the operation of other (adjacent) systems shall be addressed. When
9153 needed, specific additional operational instructions or maintenance instructions shall be defined and
9154 issued.
9155 11.2.4.6 The deployment shall be carried out under the responsibility of those responsible for
- 67 - prEN 50126-4
9156 operation and maintenance. These entities shall agree on and accept the System Deployment Plan
9157 before the deployment.
9158 11.2.4.7 During the deployment a System Deployment Record shall be written under the
9159 responsibility of the Project Manager.
9160 11.2.4.7.1 The System Deployment Record shall give evidence prior to commencement of each
9161 phase of the System Deployment Plan that the start conditions are met.
9162 11.2.4.7.2 The System Deployment Record shall give evidence that for each phase of the
9163 deployment the completion conditions are met.
9164 11.2.4.7.3 The System Deployment Record shall give evidence that for each phase of the
9165 deployment the pass conditions of the planned test as defined in the System Deployment Plan are
9166 met.
9167 11.2.4.8 Anomalies or errors observed during the deployment shall be captured within a FRACAS
9168 and evaluated against the required safety function of the system. Part of this evaluation shall be a
9169 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 11.2.4.9 The System Deployment Record should be reviewed by the Operations Manager and
9176 Maintenance Manager as part of the system handover process.
9177 11.2.4.10 The exact configuration of the deployed system shall be traceable to delivered
9178 installations.
9179 NOTE: This is of special importance when critical faults are discovered and need to be corrected in more than one installation.
9180 11.2.4.11 Quality measures shall be included in the System Deployment Plan to prevent or detect
9181 errors occurring during storage and transfer.
9182
9183 11.3 Operation and Maintenance including Performance Monitoring

9185 The objective of this sub-clause is to define the safety assurance activities necessary during
9186 operation, maintenance and repair to maintain the features incorporated into the design and the
9187 mitigations and safety requirements contained within the hazard log and SRACs as defined during
9188 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 - 68 -
9195 6) Observations and anomalies
9197 8) Operation and Maintenance Manuals
9198 9) SRACs
9199 10) Maintenance procedures
9200 11) Operational procedures
9201
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
9213 11.3.4.1 An Operations and Maintenance Plan shall be developed. The safety documentation of the
9214 electronic system, subsystem or hardware shall include details of safety controls necessary for
9215 operation and maintenance activities. These controls are documented in the SRAC clause of the
9216 System Safety Case or the release note and the maintenance and operation instructions:
9217 a) All SRAC’s relating to operation and maintenance shall be included in the Operation and
9218 Maintenance Plan;
9219 b) The Operation and Maintenance Plan shall include all other maintenance and operation
9220 instructions;
9221 c) The evidence of correct execution of the Operation and Maintenance Plan shall be documented
9222 and records maintained.
9223 NOTE: The Operation and Maintenance Plan should include the following:
9224 1) An explanation of operational status: The conditions that exist in each electronic system/sub-system/hardware should be
9225 defined to provide operating and maintenance personnel with sufficient understanding during the following situations:
9226 a) start-up: This should describe the start-up conditions of the system, sub-system or hardware when power is initially
9227 applied, or following shut-down due to power interruption or other cause.
9228 b) normal operation: Once the system/sub-system/hardware has successfully completed initialisation, the conditions
9229 during normal operation shall be defined.
9230 c) changeover: If the system/sub-system or hardware in which it is configured, has a facility to change over to either a
9231 cold or hot standby system/sub-system, then the conditions defined in a) and b) should be re-stated for this
9232 changeover routine. The reaction of the system/sub-system or hardware to the changing of failed modules shall also
9233 be clearly defined.
9234 d) shut-down: When an system/sub-system or hardware is shut down intentionally for a configuration change or de-
9235 commissioning, or unintentionally via a power failure, then all relevant conditions shall be defined.
9236 2) maintenance should be defined in respect of:
- 69 - prEN 50126-4
9237 a) that undertaken on the system in-situ or at designated routine maintenance facilities,
9238 b) the repair or refurbishment of systems, subsystems or hardware that are no longer in-situ or that is taking place in
9239 facilities not classed as routine maintenance facilities, e.g. mid-life overhauls. that undertaken by the customer and
9240 the manufacturer.
9241 3) It should include:
9242 a) Preventative maintenance

9243 b) Corrective maintenance
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 11.3.4.2 The activities specified in 8.12.2 of EN 50126 – part 1 shall be implemented in the
9249 Operations and Maintenance Plan.
9250 11.3.4.3 For safety critical electronic systems, sub-systems and hardware, maintenance instructions
9251 shall include procedures to ensure that after regular maintenance, or failure and repair, the intended
9252 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 11.3.4.4 During operation and maintenance, a log of all observations and anomalies shall be
9256 recorded and maintained by the operation and maintenance organisation(s) within a FRACAS.
9257 11.3.4.5 Observations and anomalies shall be included in the records for operation and
9258 maintenance.
9259 NOTE: The operational log book and maintenance records are evidence of safe operation and maintenance, including the
9260 correct application of instructions. This information acts as an input to the performance monitoring process (see earlier sub-
9261 clause on performance monitoring). The various manuals and instructions will need to be kept up to date, with changes being
9262 made following design changes or as a result of operational feedback.
9263 11.3.4.6 All records of relevant safety events regarding operation, repair and maintenance of the
9264 system, subsystem or hardware shall be maintained and shall contain the following information:
9265 a) The results of tests of safety functions;
9266 b) Record of all failures, including safety related failures, found during operation and maintenance
9267 and their corrective actions. These shall be included in the FRACAS;
9268 c) Evidence demonstrating the correct operation and maintenance of the system, subsystem or
9269 hardware;
9270 11.3.4.7 The FRACAS shall be maintained throughout the operation and maintenance life cycle. To
9271 ensure that priority issues are addressed, the failures and defects should be categorised for both
9272 safety and reliability for varying levels of severity / criticality. As a minimum the FRACAS shall be
9273 populated with information about failures and defects identified during operation and maintenance.
9274 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.

prEN 50126-4 - 70 -
9280 11.3.4.8 The FRACAS process is required to continuously provide feedback to the operations safety
9281 manager, the designer, manufacturer, Operations Manager and Maintenance Manager regarding any
9282 failures and defects (and possible causes) found during operational service, Failures will potentially
9283 have a variety of causes including component failures, operational errors, maintenance and other
9284 errors. It is therefore imperative that the reporting process is clear and logical and that there is a
9285 collective forum for all stakeholders to agree the most likely source of failure and hence investigation
9286 and corrective actions.
9287 NOTE: Referencing of accidents, hazards and causes should be consistent within the safety case and other performance
9288 monitoring tools and processes. This will help respective organisations to align issues and identify trends.
9289 11.3.4.9 All accidents and safety related incidents shall be investigated. This shall be coordinated by
9290 the safety manager. The results of the investigation shall be documented in a report which shall
9291 include:
9292 a) Description of the incident;
9293 b) Root Cause analysis;
9294 c) Conclusions and recommendations.
9295 11.3.4.10 The FRACAS, anomalies reports and incident/accident investigation reports shall be
9296 evaluated against the required safety function of the system. Part of this evaluation shall be a review
9297 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 11.3.4.11 In cases where a change of the system, manuals or procedures is required as a
9304 consequence of this review, a formal change request shall be produced. The change request shall
9305 contain the following information:
9306 a) Reason for change;
9307 b) Original system requirement and the changed requirement.
9308
9309 11.4 Modification

9311 The objective of this sub-clause is to define the safety assurance activities necessary to maintain the
9312 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
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

9325 NOTE: During the operational life of a system, change requests may be raised for a variety of reasons, not all of which will be
9326 safety-related.
9327 11.4.4.1 An impact analysis shall be performed on each modification change request. The analysis
9328 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 d) the modification installation work, with consideration given to adjacent system/sub-system and
9333 hardware that maybe affected due to systematic failures.
9334 11.4.4.2 Each change request shall be evaluated for its impact on system safety performance, by
9335 reference to the relevant portion of the safety case.
9336 11.4.4.3 The impact analysis shall result in a decision on which parts of the safety life cycle will be
9337 repeated for the modification, all relevant documentation for the effected life cycle steps shall be
9338 updated, with equal depth and quality as the original documentation that was produced during the
9339 development of the system.
9340 11.4.4.4 All changes and system/sub-system or hardware identified as being at risk shall be tested
9341 for correct operation on completion of the change.
9342 11.4.4.5 The details and results of the modification, risk analysis and testing shall be included in the
9343 safety case.
9344 11.4.4.6 Only the change approved by this process shall be implemented. Any changes not
9345 approved by this process shall not be implemented.
9346 11.4.4.7 An auditable trail of the impact analysis and decision making process shall be documented
9347 and maintained.
9348
9349
prEN 50126-4 - 72 -
9350 Annex A
9351 (normative)
9352 Techniques/Measures
9353 Safety Integrity Levels (SIL) are defined at functional level for the systems/sub-systems implementing
9354 the functionality. This annex relates architectures, techniques and measures to avoid systematic
9355 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 With each technique or measure in these tables there is a recommendation for each Safety Integrity
9358 Level (SIL) 0 to 4.
9359 'M' this symbol means that the use of a technique is mandatory,
9360 "HR" This symbol means that the measure or technique is Highly Recommended for this safety
9361 integrity level. If this technique or measure is not used the rationale behind not using it shall
9362 be detailed.
9363 "R" This symbol means that the measure or technique is Recommended for this safety integrity
9364 level.
9365 "-" This symbol means that the technique or measure has no recommendation for or against
9366 being used.
9367 “NR” this symbol means that the technique or measure is positively Not Recommended for this
9368 safety integrity level. If this technique or measure is used then the rationale behind using it
9369 shall be detailed.
- 73 - prEN 50126-4
9370 Table A.1 – Lifecycle Issues and Documentation
DOCUMENTATION SIL 0 SIL 1 SIL 2 SIL 3 SIL 4

Planning
1. System Quality Assurance Plan HR HR HR HR HR
2. System Quality Assurance Verification Report HR HR HR HR HR
3. System Safety Plan - 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
System Requirements
7. System Requirements Specification HR HR HR HR HR
8. System Requirements Verification Report HR HR HR HR HR
Architecture and Design
9. System Architecture Specification HR HR HR HR HR
10. Hazard Analysis - HR HR HR HR
11. System Integration Test Specification HR HR HR HR HR
12. System Architecture Verification Report HR HR HR HR HR
HW Component Specification
13. Hardware Component Specification R HR HR HR HR
14. Hardware Component Test Specification R HR HR HR HR
15. Hardware Component Verification Report R HR HR HR HR
HW Component Implementation
16. Hardware Detailed Design Specification R HR HR HR HR
17. Hardware Manufacturing Data - R R HR HR
HW Component Validation
18. Hardware Safety Verification - - - HR HR
19. Hardware Component Test Report R HR HR HR HR
20. Hardware Component Validation Report - HR HR HR HR
Integration and Validation
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 - R R 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 R HR HR HR HR
27. System Safety Case - HR HR HR HR
28. Release Note HR HR HR HR HR
9371
prEN 50126-4 - 74 -
9372 Table A.2 – Safety Planning and Quality Assurance Activities
TECHNIQUE/MEASURE Ref SIL 0 SIL 1 SIL 2 SIL 3 SIL 4

1. Checklists H.2.2 R R R HR HR
2. Audit of tasks 9.6.4.5 - R R R R
Table
D.7
3. Inspection of issues of 7.3 R HR HR HR HR
documentation H.2.16
4. Review after change in the safety - R HR HR HR HR
plan
5. Review of the safety plan after - R HR HR HR HR
each safety life cycle phase
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 - prEN 50126-4
9374 Table A.3 – System Requirements Specification

1. Separation of Safety-Related Systems - R R R HR HR
from Non Safety-Related Systems
2. Graphical description including for - R HR HR HR HR
example block diagrams
3. Structured Specification H.2.1 R HR HR HR HR
H.2.20
4. Formal or semiformal methods H.2.1 - R R R R
H.2.2
H.2.4
H.2.12
H.2.35
5. Computer aided specification tools 6.7 - - R R R
6. Checklists H.2.2 R HR HR HR HR
7. Hazard Log 8.7 R HR HR HR HR
8. Inspection of the specification 7.3 R HR HR HR HR
H.2.16
9. Prototyping/Animation H.2.25 - - - R R
10. Domain Specific Languages H.2.6 - - - R R
11. Traceability H.2.33 R 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 - 76 -
9376 Table A.4 – Safety Organisation

1. Training of staff in safety organisation 6.3 R HR HR HR HR
2. Independence of roles 6.3 - HR HR HR HR
See
Note 1
3. Qualification of staff in safety organisation 6.3 HR HR HR HR HR
See
Notes 2
and 3
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 - prEN 50126-4
9378 Table A.5 – Architecture of System/Subsystem/Equipment

1. Separation of safety-related systems from - R HR HR HR HR
non safety-related systems
2. Single electronic structure with self tests and - - R R NR NR
supervision
3. Dual electronic structure - - R R NR NR
4. Dual electronic structure based on - - R R HR HR
composite fail-safety with fail-safe
comparison
5. Single electronic structure based on inherent - - R R HR HR
fail-safety
6. Single electronic structure based on reactive - - R R HR HR
fail-safety
7. Diverse electronic structure with fail-safe - - R R HR HR
comparison
8. Justification of the architecture by a See - HR HR HR HR
quantitative reliability analysis of the Note 3
hardware
9. Dynamic Reconfiguration H.2.7 R - - NR NR
10. Error Detecting Codes H.2.8.1 - R R 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 - 78 -
9379 Table A.6 – Design Features

1. Protection against operating errors H. 2. 30.9 R R R HR HR
See Note 1
2. Protection against sabotage See - R R HR HR
Note 2
3. Protection against single fault for 8.2.4 - R R HR HR
discrete components See
Note 3
4. Basic insulation See R HR HR - -
Note 4
5. Reinforced insulation See - - - M M
Note 4
6. Protection against single fault for 8.2.4 - R R HR HR
integrated circuits for digital B.3
electronic technology
See
Note 5
7. Detection of single faults by 8.2.4 R R - - -
deviation from normal operation H.2.10
8. Detection and negation of a single 8.2.4 - - R HR HR
hazardous fault with time for H.2.10
detection-plus-negation within the
safety target
9. Retention of safe state through 8.2.4 - R R NR NR
indication to not use or rely on the See
safety-related functions associated Note 6
to the faulty item
10. Retention of safe state through 8.2.4 - - - HR HR
shut-down, or blocking of all safety-
related functions
11. Detection of multiple faults by 8.2.4 R R - - -
deviation from normal operation
12. Detection and negation of a single 8.2.4 - - R HR HR
fault involved in hazardous faults See
chains with time for detection-plus- Note 7
negation within the safety target,
through on line dynamic testing
13. Program sequence monitoring See - R HR HR HR
Note 8
14. Fault Isolation Methodology H.2.11 - NR NR NR NR
15. Graceful Degradation H.2.13 - - - - -
See
Note 11
16. Measures against voltage See R HR HR HR HR
breakdown, voltage variations, Note 9
overvoltage, low voltage
17. Measures against temperature See R HR HR HR HR
- 79 - prEN 50126-4

increase Note 10
18. Recovery Block See - - - - -
Note 11
19. Retry Fault Recovery Mechanism See - - - - -
Note 11
20. Safety Bag H.2.29 - R R R R
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 - 80 -
9380 Table A.7 – Failure and Hazard Analysis Methods

1. Preliminary hazard analysis H.2.30.10 HR HR HR HR HR
2. Fault tree analysis H.2.30.7 - R R HR HR
3. Markov diagrams H.2.18 - R R HR HR
4. FMECA H.2.30.4 - R R HR HR
H.2.30.5
H.2.30.6
5. HAZOP H.2.30.8 R R R HR HR
6. Cause-consequence diagrams H. 2.1 - R R HR HR
7. Event tree H. 2.9 - R R R R
8. Reliability block diagram H.2.30.11 - R R R R
9. Zonal analysis - - R R R R
10. Interface hazard analysis H.2.17 R R R HR HR
11. Common cause failure analysis H.2.30.1 - R R HR HR
12. Historical event analysis - - R R R R
13. Design Analysis H.2.5 R R R R R
14. Operating and support Hazard Analysis H.2.30.9 - R R R R
15. Sneak Circuit Analysis H.2.30.15 - R R R R
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 - prEN 50126-4
9382 Table A.8 – Design and Development of System/Sub-system/Item

1. Structured design See Note 1 HR HR HR HR HR
2. Modularisation H.2.20 - R HR HR HR
3. Formal or semiformal methods H.2.1 - - - R R
H.2.2
H.2.4
H.2.12
H.2.35
4. Computer aided design tools 6.7 - - R R R
5. Computer aided design trusted/verified H.2.34.1 - - - R R
tools 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 - - - R R
8. Performance Modelling H.2.23.1 - - - R R
10. Library of Trusted/Verified Components H.2.34.2 - R R R R
11. Configuration management H.2.3 R HR HR HR HR
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

1. Graphical description of sub-systems - R HR HR HR HR
2. Description of interfaces 8.2 HR HR HR HR HR
3. Environment (EMC, vibrations) studies - R R R HR HR
4. Modification procedure 7.7 HR HR HR HR HR
H.2.3
5. Maintenance manual 11.3 R HR HR HR HR
6. Manufacturing documentation 8.8 R HR HR HR HR
9.6
7. Application Documentation - R HR HR HR HR
Requirements/Notes: None
prEN 50126-4 - 82 -
9385 Table A.10 – Verification and Validation of the System and Product Design

1. Checklists H.2.2 R HR HR HR HR
2. Simulation H.2.21 - - R R R
See Note
1
3. Functional testing of the system A.12 HR HR HR HR HR
4. Functional testing under environmental - HR HR HR HR HR
conditions
5. Surge immunity testing See Note R HR HR HR HR
2
6. Inspection of documentation 7.3 HR HR HR HR HR
H.2.16
7. Ensure design assumptions are not 9.6 - R R HR HR
compromised by manufacturing process
8. Test facilities - R R R HR HR
9. Design review H.2.16.2 R HR HR HR HR
10. Ensure design assumptions are not 8.6 R HR HR HR HR
compromised by installation and
maintenance processes
11. High confidence demonstrated by use See Note R R R R R
(optional where some previous evidence is 3
not available)
12. Performance testing A.13 R R R HR HR
13. Interface Testing H.2.17.2 HR HR HR HR HR
14. Fault Injection H.2.31.4 - R R HR HR
14. Impact Analysis / Change Analysis H.2.15 R HR HR HR HR
15. Operational Readiness Review H.2.22 R HR HR HR HR
16. Time Petri Nets H.2.32 - - - R R
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 - prEN 50126-4
9386 Table A.11 – Application, Operation and Maintenance

1. Production of applications operational 11.3 R R R HR HR
and maintenance instructions
2. Training in the execution of - R HR HR HR HR
operational and maintenance
instructions
3. Operator friendliness - HR HR HR HR HR
4. Maintenance friendliness - HR HR HR HR HR
5. Protection against operating errors See R R R HR HR
A. 6
6. Protection against sabotage See - R R HR HR
A. 6
7. Configuration management H.2.3 R HR HR HR HR
9387
9388 Table A.12 – Functional Testing

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

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

1. FMEA/FMECA H.2.30.4 - R R M M
H.2.30.5
See Note 1
2. Bent Pin Analysis / Cable Failure Matrix H.2.14.1 - R R HR HR
Analysis
3. Electromagnetic Compatibility Analysis H.2.14.2 - R R HR HR
4. Energy Trace and Barrier Analysis H.2.14.3 - R R HR HR
5. Materials Compatibility Analysis H.2.31.1 - R R HR HR
6. Fault Tree Analysis H.2.30.7 - R R HR HR
See Note 1
Requirements/Notes:
Note 1: Techniques 1 and 6 should be intended at components level.
9393
- 85 - prEN 50126-4
9394 Annex B
9395 (normative)
9396 Electronic/Electrical Component failure modes
9397 B.1 Introduction

9398 This annex contains procedures and information for identifying the credible failure modes of
9399 electronic/electrical components.
9400 NOTE: The tables of electronic/electrical component failure modes included in this annex have been derived from European
9401 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 Mü8004;
9405 - Reliability Analysis Centre Report FMD-91.
9406 The information in the tables may be modified, as explained in B.2 and B.5, if adequate justification is provided for such
9407 variations.
9408 B.2 General Procedure

9409 For the purpose of analysing the results of single failures, it is necessary to identify the credible failure
9410 modes of each electronic/electrical component.
9411 Table B.1 to Table B.38 contain lists of electronic/electrical component failure modes which shall be
9412 used as the basis for design and analysis, unless justification is provided for any variation. The
9413 general Observations in B.5 shall be observed.
9414 The lists are not necessarily complete, and any additional failure modes which are considered to be
9415 credible shall be added to the analysis. In such cases, the extra failure modes shall be drawn to the
9416 attention of the relevant authority, so that the lists can be extended at a future date, by means of the
9417 normal CENELEC procedure.
9418 B.3 Procedure for Integrated Circuits (including Microprocessors)

9419 Designs which employ integrated circuits require special treatment, since it can be difficult to predict
9420 all the credible failure modes that the device may possess. This is particularly true for programmable
9421 devices, since the failure modes that may be observed at the boundary of the device are application
9422 specific.
9423 It is recommended that the hazardous failure modes be identified in a top-down manner for the
9424 specific application, using a technique such as Fault Tree Analysis. (An alternative would be to use a
9425 bottom-up approach such as Failure Modes and Effects Analysis, but this method is time-consuming
9426 and it is possible that certain hazardous failure modes could be missed).
9427 An assessment and justification shall then be made, to show that for each identified hazardous failure
9428 mode either:
9429 a) the failure mode cannot credibly occur, due to the internal architecture of the hardware, software
9430 or data structure, or
9431 b) the failure mode will be externally detected and a safe state imposed within the required time. In
9432 this case, quantitative analysis shall be performed to justify the design, and a pessimistic view
9433 shall be taken whereby the hazardous failure modes are assumed to take the full electronic
9434 component failure rate.
9435 NOTE: Some items, such as "intelligent" sensors, employ embedded microprocessors. Such items should be assessed using
9436 the same methods as outlined above for integrated circuits.
prEN 50126-4 - 86 -
9437 B.4 Procedure for Electronic/Electrical Components with Inherent Physical

9438 Properties
9439 If the technique of Inherent Fail-Safety is used, full justification shall be provided for any
9440 electronic/electrical component failure mode which is considered to be incredible. This justification
9441 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 - explanation of special mounting arrangements or other precautions for the

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

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

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

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

9461 electromagnetic disturbances, etc.);
9462 - worst case analysis;
9463 - random analysis (Monte-Carlo);
9464 - version of the simulation software;
9465 - complete references of the testing computer (type of operating system and
9466 relevant software version numbers, configuration):
9467 - skills of the operator(s).
9468 - evidence of previous experience of reliance on the electronic/electrical component for

9469 inherent fail-safety.
9470 If satisfactory justification is provided, the relevant electronic/electrical component failure modes may
9471 be excluded from the safety analysis.
9472 It is not necessary to repeat the justification if it has already been provided in the past; it is sufficient to
9473 make reference to the previous justification report. However, if this justification includes particular
9474 conditions (for example, special mounting arrangements or means for prevention of overload), the
9475 fulfilment of these conditions shall be included in the Safety Case.
9476 Previous experience indicates that some particular electronic/electrical component failure modes are
9477 more likely to be capable of justification as incredible; these failure modes are indicated by (*) in Table
- 87 - prEN 50126-4
9478 B.1 to Table B.38, together with relevant guidance Observations in B.6 and B.7. Other
9479 electronic/electrical component failure modes are much less likely to be capable of justification as
9480 incredible. Note that justification shall be provided for all failure modes which are considered to be
9481 incredible, including those which are indicated in the tables.
9482 B.5 General Observations concerning Electronic/Electrical Component Failure

9483 Modes
9484 1) Table B.1 to Table B.38 contain lists of credible failure modes of electronic/electrical components.
9485 2) The failure modes are as manifested at the boundary of the electronic/electrical components, and
9486 not the internal physical causes of the failures.
9487 3) All listed failure modes could be intermittent.
9488 4) Intermittent failures are caused by environmental influences such as temperature variation or
9489 mechanical stress (see relevant environmental standards). Therefore the frequency of intermittent
9490 failures will be in accordance with these reasons.
9491 5) Variations within the tolerances of an electronic/electrical component's published specification are
9492 not considered to be failures.
9493 6) It is assumed that electronic/electrical components are operated within their published
9494 environmental limits.
9495 7) It is assumed that electronic/electrical components are operated within their published electrical
9496 ratings.
9497 8) External short-circuit or leakage between terminals of a electronic/electrical component is not

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

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

9512 Components with Inherent Physical Properties
9513 1) The procedure and conditions for justification of any electronic/electrical component failure mode
9514 as incredible are contained in B.4.
9515 2) Failure modes indicated by (*) in Table B.1 to Table B.38 are those which are more likely to be
9516 capable of being justified as incredible.
9517 3) "Observation xy" following (*) in Table B.1 to Table B.38 refers to guidance Observations in B.7
9518 on some factors that are relevant to possible justification of the failure mode as incredible.
9519 4) The general Observations in B.5 apply also to electronic/electrical components with inherent
9520 physical properties, with the following additions in Observations 5, 6 and 7 below.
9521 5) In addition to Observation 5) in B.5, it is recommended that some allowance be made for
9522 variations which exceed the normal tolerances.
prEN 50126-4 - 88 -
9523 6) In addition to Observation 6) in B.5, it is recommended that some allowance be made for
9524 excursions beyond the normal environmental limits.
9525 7) In addition to Observation 7) in B.5, a margin shall be ensured within the published electrical
9526 ratings, so that the electronic/electrical component is protected from being overloaded.
9527 B.7 Specific Observations concerning Electronic/Electrical Components with

9528 Inherent Physical Properties
9529 The following Observations provide guidance concerning possible justification of the failure modes
9530 identified by (*) in Table B.1 to Table B.38 as incredible.
9531 8) The body shall have no hollows.
9532 a) Clearance and creepage distances between the caps/connection wires at each end of the
9533 electronic/electrical component shall at least fulfil the requirements of EN 50124-1, in
9534 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 d) Short-circuit between turns of a wire-wound resistor shall be avoided by coating of the wire,
9538 and/or by physical separation of the turns.
9539 e) The body shall be constructed of material which is non-conductive, even at the highest
9540 temperature (including fault conditions).
9541 f) The coating shall be non-conductive, even at the highest temperature (including fault
9542 conditions).
9543 g) The resistance shall be limited to the lowest possible value (for example, no greater than
9544 10 k ).
9545 9) The 4-terminal resistor shall be constructed in such a way that, if a fault causing interruption of the
9546 resistance material occurs, this fault would also cause interruption of at least one of the four
9547 connecting terminals.
9548
9549 The circuitry external to the resistor shall disclose the interruption of the terminal(s) in a fail-safe
9550 manner.
9551
9552 Example of a 4-terminal resistor, using a hybrid thick layer technique:
CONNECTION RESISTANCE MATERIAL

A D
POSSIBLE "CRACK"
(Fault)
R
CERAMIC
SUBSTRATE
B C
A B C D
9553
9554 Figure B.1 – Example of a 4-terminal Resistor using a hybrid thick layer technique
9555
- 89 - prEN 50126-4
9556 10) Two terminals shall be connected independently to each side of the electronic/electrical
9557 component.
9558 11) The formula to calculate capacitance of a simple parallel-plate capacitor is

9559
A
9560 C 0 r
d
9561
9562 where
9563
9564 A = common area of plates,
9565 d = distance between plates,
9566 o = permittivity of free space,
9567 r = relative permittivity (dielectric constant).
9568
9569 Justification of the failure mode as incredible requires demonstration that none of these
9570 parameters can significantly change.
9571
9572 Electrolytic capacitors are not suitable for exclusion from this failure mode.
9573 12) The capacitor shall be designed and constructed for high-voltage application in relation to the
9574 maximum possible operating voltage (including fault conditions). It shall have Class-Y
9575 specification, and self-healing properties at the working source impedance and over the working
9576 voltage range.
9577 13) There shall be only one layer of turns, separated by means of grooves in the insulated body, or
9578 the wire shall have reinforced insulation.
9579
9580 The turns shall be securely fastened.
9581 14) Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
9582 EN 50124-1.
9583
9584 All windings and connections shall be securely fastened.
9585
9586 Power dissipation shall be limited sufficiently to prevent internal carbonisation (including fault
9587 conditions).
9588 15) The magnetic core shall be constructed such that no significant change in reluctance of the
9589 magnetic path can occur.
9590 16) The transfer ratio depends upon the number of turns on each winding, and on the integrity of the
9591 magnetic coupling. Therefore it is necessary for Observations 15), 16) and 17) to be fulfilled.
9592 17) The transductance and the DC threshold voltage depend upon the properties of the magnetic
9593 core material. Therefore it is necessary to demonstrate that these magnetic properties cannot
9594 significantly change.
9595
9596 Transductance and DC threshold voltage also depend on the number of turns on each winding,
9597 and on the integrity of the magnetic coupling. Therefore it is also necessary for Observations 15),
9598 16) and 17) to be fulfilled.
9599
9600 The output from a transductor is related to the number of ampere-turns in the control winding. It is
9601 necessary to demonstrate that, in conjunction with the associated drive circuitry, no credible
9602 failure modes of the control winding can cause an increase in the number of ampere-turns.
9603 18) All parts of the relay or switch mechanism shall be robustly constructed and securely fastened,
9604 including
9605 - the operating mechanism,

prEN 50126-4 - 90 -
9606 - the contact system,
9607 - the magnetic circuit (if any),
9608 - the coil(s) (if any).
9609 Clearance and creepage distances shall fulfil at least the requirements for re-inforced
9610 insulation of EN 50124-1.
9611 19) Contact materials shall be chosen which are not capable of being welded.
9612
9613 The risk of welding shall be further reduced by appropriate mechanical design and construction of
9614 the contacts.
9615
9616 The maximum current shall be limited, to ensure that the temperature of the contacts does not
9617 reach a value at which welding could occur.
9618 20) Stability of the relay's characteristics shall be ensured by careful attention to the following factors:
9619 - magnetic characteristics:
9620 choice of magnetic material;
9621 provision of a stop device to avoid permanent magnetisation of the magnetic circuit
9622 (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 provision of adequate return force, using gravity

9633 (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 21) The threshold voltage of a p-n junction, such as a diode or a transistor base-emitter junction, is a
9636 function of
9637 - minority and majority charge-carrier densities,
9638 - boltzmann's constant (k),
9639 - electron charge (e),
9640 - temperature (K).
9641 Therefore the threshold voltage is dependent on non-variable characteristics of the p-n
9642 junction, and should be constant for a given temperature.
- 91 - prEN 50126-4
9643 22) The breakdown voltage is determined by one of two possible mechanisms: Zener breakdown or
9644 avalanche breakdown. Both of these are dependent on non-variable physical characteristics of
9645 the diode, so the breakdown voltage should be constant for a given temperature.
9646
9647
9648 Care shall be taken to avoid electronic components which consist internally of two or more diodes
9649 connected in series.
9650
9651 Note that conduction at voltages above and below the breakdown voltage may be possible, due
9652 to shunt or series resistance, but the differential (slope) resistance in such cases would be higher
9653 than for the case of breakdown conduction.
9654 23) The amplification (or gain, or transconductance) of a transistor, and the optical sensitivity of a
9655 photo-diode or transistor, are dependent on
9656 - doping levels,
9657 - thickness of the junction(s),
9658 - life-time of charge carriers.
9659 These parameters should remain constant, with the exception of the charge carriers' life-time,
9660 which can only decrease with time. Therefore the amplification/sensitivity should remain
9661 constant, or possibly decrease, but not increase (has to be justified for each application).
9662 A small possibility exists of an increase in amplification caused by pollution affecting surface
9663 doping. This can be avoided by high-quality manufacture and packaging of the electronic
9664 component. Also this effect is only significant for very low bias currents, which shall therefore
9665 be avoided when designing circuits.
9666 24) Light emission is a physical property related to recombination of electrons and holes when current
9667 flows in a forward-biased p-n junction.
9668 The rate of recombination is a function of the forward current, and therefore the light emission
9669 should not increase at constant current.
9670 Below the threshold voltage there is no significant current flow and therefore no light
9671 emission.
9672 25) If the p-n junction is reverse biased, there will be no significant current flow below the breakdown
9673 voltage and therefore no light emission.
9674 Above the breakdown voltage, the mechanism that allows current to flow is different to that for
9675 forward bias and should not result in emission of light.
9676 26) For optocouplers and self-contained fibre-optic systems, the failure modes of each element shall
9677 be considered, i.e.
9678 - light-emitting transmitter,
9679 - optical medium,
9680 - photo-sensitive receiver.
9681 27) Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
9682 EN 50124-1.
9683 The construction of the electronic/electrical components shall be robust and stable.
9684 Power dissipation in the electronic/electrical component shall be limited sufficiently to prevent
9685 internal carbonisation (including fault conditions).
prEN 50126-4 - 92 -
9686 28) Clearance and creepage distances shall fulfil at least the requirements for re-inforced insulation of
9687 EN 50124-1.
9688 The input and output drive/coupling elements shall be securely fastened.
9689 29) The electronic/electrical component shall be robustly constructed.
9690 The resonator(s) shall be constructed and mounted so as to prevent change of their effective
9691 dimensions.
9692 The resonator(s) shall be constructed of a material whose dimensions are not significantly
9693 altered by changes of temperature.
9694 The material of the resonator(s) shall be stabilised by temperature cycling and/or pre-
9695 operation for a sufficient time.
9696 The material of the resonator(s) shall not be over-stressed, even under fault conditions. In
9697 particular the limit of elasticity shall not be exceeded.
9698 30) The transfer ratio is a function of the efficiency of the drive/coupling elements and the Q-factor of
9699 the filter.
9700 The drive/coupling elements shall be designed and constructed so as to prevent any significant
9701 increase in their efficiency.
9702 31) The resonator(s) shall be constructed and mounted to obtain the maximum possible Q-factor, so
9703 that no subsequent improvement can occur.
9704 32) The resonator(s) shall be constructed and mounted so as to prevent the occurrence of damping
9705 by any mechanism.
9706 33) The insulating material shall be stable.
9707 Clearance and creepage distances shall fulfil at least the requirements for reinforced insulation of
9708 EN 50124-1.
9709 34) The connector shall be robustly constructed.
9710 All parts of the connector shall be securely fastened.
9711 35) Incorrect orientation of the connector, or insertion into the wrong socket, shall be prevented by
9712 means of, for example, mechanical design or mechanical pin-coding.
9713 Alternatively, the effects of incorrect insertion shall be rendered non-hazardous by means of, for
9714 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 36) The screen shall be robustly constructed and protected from excessive physical damage.
9717 The electrical connection to the screen shall be robust and securely fastened.
9718 37) Sufficiently robust insulation shall be provided.
9719 Clearance and creepage distances shall fulfil at least the requirements for re-inforced insulation of
9720 EN 50124-1.
9721 Protection shall be provided against excessive physical damage.
9722 Protection shall be provided against electrically conductive foreign bodies.
9723 The protection against excessive external physical damage cannot fully negate the potential for
9724 short circuit considerations in trackside environment.
- 93 - prEN 50126-4
9725 38) The fuse and its holder shall be physically constructed and mounted so as to prevent the
9726 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
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
Increase of capacitance (*) Observation 11
Decrease of capacitance (*) Observation 11
Decrease of parallel resistance (*) Observation 12
Increase of series resistance
9734 Table B.3 – Capacitor and adjustable capacitor (excluding 4-terminal capacitor)
9735
9736
9737
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 (*) Observation 14
Short-circuit or decrease of insulation between winding and body (*) Observation 14
Increase of resistance of winding
Increase of inductance (*) Observation 15
Decrease of inductance (*) Observation 15
9740 Table B.5 – Electromagnetic Components-Inductor
9741
Interruption of any winding

Short-circuit of any winding
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
Increase of inductance of any winding (*) Observation 15
Decrease of inductance of any winding (*) Observation 15
Change of transfer ratio (*) Observation 16
9742 Table B.6 – Electromagnetic Components-Transformer
9743
9744
9745
9746
- 95 - prEN 50126-4
Interruption of any winding

Short-circuit of d.c. winding
Short-circuit of a.c. winding
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 (*) Observation 17
9747 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 (*) Observation 20
(transient or continuous)
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 (*) Observation 23
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 Table B.12 – Transistors-Field Effect (FET)
9757
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 Table B.14 – Bidirectional thyristor (triac)
9761
- 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
Increase of breakdown voltage
Decrease of breakdown voltage
9766 Table B.17 – Surge Suppressors-Gas Discharge Arrester
9767
Interruption
Short-circuit
Increase of breakdown voltage
Decrease of breakdown voltage
9768 Table B.18 – Surge Suppressors-Air Gap Arrester
9769
Interruption
Short-circuit
Increase of light sensitivity (*) Observation 23
Decrease of light sensitivity
9770 Table B.19 – Opto-electronic Components-Photo Diode
9771
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 Table B.23 – Filters-Crystal
9779
9780
9781
- 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
Increase of Q-factor (*) Observation 31
Decrease of Q-factor (*) Observations 29
and 32
9782 Table B.24 – Filters-Mechanical Resonator (turning fork/reed/pendulum)
9783
Interruption or increase of resistance in one or more lines

Short-circuit or decrease of insulation between two different lines (*) Observation 33
9784 Table B.25 – Interconnection Assemblies-Printed Circuit Board
9785
Interruption of
- one or more contacts
- shield
- between contact and contact (*) Observations 33
and 34
- between contact and shell
(*) Observations 33
and 34
Wrong mechanical position (*) Observation 35
9786 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 (*) Observation 37
9788 Table B.27 – Interconnection Assemblies-Cable and Wire
Interruption
Increase of resistance
9789 Table B.28 – Interconnection Assemblies-Connection (soldered, welded, wrapped, crimped, clipped,
9790 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 Table B.33 – Lamps
9802
9803
- 103 - prEN 50126-4
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: see B.3

9808 Table B.36 – Integrated Circuits-Analogue Devices
9809

9810 Table B.37 – Integrated Circuits-Digital Devices
9811

9812 Table B.38 – Integrated Circuits-Microprocessors
prEN 50126-4 - 104 -
9813 Annex C
9814 (normative)
9815 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 - prEN 50126-4
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 - 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:

2. shall be competent in the implementation of hardware
3. shall understand all the constraints imposed by the hardware implementation
9823
- 107 - prEN 50126-4
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 - 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 the integration
NOTE:
-for system integration report’s see clause 8.5
- for hardware integration report see clause 9.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 - 110 -
9832 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 - prEN 50126-4
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 - 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:

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
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 .
9847 Table C. 13 – Hardware/System Safety Manager Role Specification
9848
9849
- 117 - prEN 50126-4
9850 Annex D
9851 (informative)
9852 Technical Recommendations for SIL3 and SIL4 functions
9853 D.1 Introduction
9854 This annex provides examples and guidance to supplement the technical requirements contained
9855 in Part 2 §12.2.4 (Physical Independence) and §7.x (Additional requirements for E/E/PE Architecture).
9856 The given recommendations are only valid for SIL 3 or SIL 4 functions.
9857 D.2 Achievement of Physical Internal Independence
9858 As referred to in Part 2 12.2.4
9859 Primary independence

9860 The following measures provide "primary independence" between two items whose simultaneous
9861 malfunction could be hazardous:
9862 1) measures to avoid non-intentional galvanic connections

9863 (protection of internal galvanic insulation)
9864 a) Insulation between lines on the same layer of a printed-circuit board.

9865
9866 Insulation distances (creepage distances and clearances) should be dimensioned at least
9867 according to the requirements for reinforced insulation of EN 50124-1.
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 d) Insulation between insulated windings in the same transformer.

9871
9872 Maximum temperature inside transformers should be limited (including fault conditions), to avoid
9873 carbonisation.
9874 e) Insulation between insulated items inside an opto-coupler.

9875
9876 Maximum temperature inside opto-couplers should be limited (including fault conditions), to
9877 avoid carbonisation.
9878 2) measures to avoid non-intentional effects via intentional connections

9879 (protection of internal interfaces)
9880 a) Interfaces should be protected by means of devices with inherent properties.
9881 3) measures to avoid non-intentional effects via electromagnetic coupling

9882 (protection against internal cross-talk)
9883
9884 Cross-talk between electronic networks should be prevented as follows:
9885 a) if different items are on the same printed-circuit board, they should be supplied by different
9886 power-supply networks. If not, then the impedance of the ground network should be sufficiently
9887 low to avoid cross-talk, even in the event of failures;
9888 b) if different lines on the same board need to be protected against cross-talk occurring between
9889 them, the necessary separation distance depends on the used technology, the coupling length
9890 and the coupling mechanism. This distance should be demonstrated for the normal operational
9891 mode by theoretical calculations and/or by practical measurements;
prEN 50126-4 - 118 -
9892 c) if necessary to avoid coupling in the event of failures, additional measures (for example,
9893 shielding or doubling of distance) should be taken. Effectiveness should be demonstrated by
9894 theoretical calculations and/or by practical measurements.
9895 Secondary independence
9896 The following measures provide "secondary independence" between two items whose simultaneous
9897 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 2) independence of two items whose simultaneous malfunction could be hazardous is achieved as
9900 written in Primary independence. These items will be referred to as "main items". Each main item
9901 can have one or more so called "additional items" checking the main item;
9902 3) the degree of independence between a main item and an additional item may be less than written
9903 in Primary independence and is called "secondary independence";
9904 4) main items are independent from additional items if all possible first-fault-effected influences
9905 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 a) insulation distances (creepage distances and clearances) should be dimensioned at least
9908 according to the requirements for basic insulation of EN 50124-1;
9909 b) protecting devices do not require inherent properties. (Only a second fault may be able to inhibit
9910 the independence between a main item and an additional item);
9911 c) at least the power-supply network for the voltage-monitoring (additional item) should be
9912 separated from the power-supply network for the monitored main item as written in this
9913 paragraph.
9914 D.3 Achievement of Physical External Independence

9915 The following measures provide physical external independence:
9916 1) measures should be taken to avoid non-intentional effects by EMI/ESD disturbing correct
9917 operation, in accordance with EN 50121-4;
9918 2) the specified climatic conditions should normally be complied with. Measures should be taken to
9919 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 a) measures should be taken to ensure reliable correct operation in spite of mechanical stress-
9922 conditions 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 4) measures should be taken to ensure reliable correct operation in spite of chemical stress-
9925 conditions agreed between the railway authority and supplier;
9926 5) measures should be taken to avoid non-intentional operation under non-permitted power-supply
9927 voltages (protection of supply-voltages):
9928 a) non-permitted supply voltages (outside data-sheet values for supplied systems/
9929 equipment/components) should be disclosed by voltage-monitoring triggering a safe state
9930 before hazardous situations are possible;
9931 b) voltage-monitoring should operate correctly for the whole life cycle. Voltage-monitoring
9932 redundancy may be necessary if disclosure of voltage-monitoring failures is not possible.
- 119 - prEN 50126-4
9933 6) measures should be taken to avoid non-intentional hazardous effects caused by external voltages
9934 across input and output ports disturbing the correct operation (protection of external interfaces):
9935 a) worst-case external voltages should be assumed (process-voltages and all possible EMI-
9936 induced voltages on cables and lines);
9937 b) clearances between live parts and exposed conductive parts/earth/circuits whose correct
9938 operation needs to be protected should be dimensioned according to surge voltages specified
9939 in EN 50124-1;
9940 c) creepage distances between live parts and exposed conductive parts/earth/circuits whose
9941 correct operation needs to be protected should be dimensioned according to EN 50124-1 and
9942 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 Single-fault Detection

9945 (As referred to in 8.2 of this standard)
9946 The following measures provide conditions for single-fault detection in composite (2-out-of-n), reactive
9947 and inherent fail-safety.
9948 1) Periodic tests for faults in all items should be implemented. The tests should be representative
9949 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 NOTE: Evidence should be given that faults not covered by periodic tests are not hazardous (i.e. these faults are
9952 demonstrated to be safe, alone or combined with others).
9953 2) For two items whose simultaneous malfunctioning could be hazardous, having same or
9954 comparable failure rates "a", the detection time tsf of single faults should not exceed the value:
TFFR
9955 tsf
a2
9956 NOTE: For reliable items the resulting time can be comparable with the lifetime of E/E/PE system. In these cases the
9957 tests frequency (1/tsf) should be set at least to a value significantly greater than “a” (e.g. 1000-fold value).
9958 3) The failure rates mentioned in paragraph 2) above are to be determined as a function of the
9959 stress profile dependent on the environmental conditions during operation. The stress profile
9960 depends on the application. A simplified stress profile may be taken as a basis if this leads to a
9961 conservative result (higher failure rate).
9962 4) If within a E/E/PE system comprising several items not all combinations of two failed items would
9963 be hazardous, the fault detection time may be determined separately for the various
9964 combinations. If, in this case, different fault detection times result for one item, the shortest time
9965 is decisive.
9966 5) If a fault-free E/E/PE system is disconnected from the power supply, the fault detection may be
9967 interrupted. All the periodic tests implemented should be then executed at start-up (alternatively
9968 the system has to be thoroughly tested off-line in a controlled manner before restoring operation).
9969 6) When the safety-related function is performed by a single item the detection time of a wrong side
9970 failure tsf is the maximum total time to detect and react in a safe way to all single faults affecting
9971 the safe operation. This time shall not exceed the specified limit for the duration of any
9972 hazardous condition.
9973 For example the tsf could assume the following value, in order to avoid any hazardous condition:
9974 tsf < 100 ms, if the controlled equipment is a signalling relay with higher rise time.
prEN 50126-4 - 120 -
9975 7) During the time tsf the first safety related failure must be detected and it must trigger a safety
9976 reaction.
9977 D.5 Multiple-fault Detection

9978 (As referred to in 8.2)
9979 The following measures provide conditions for multiple-fault detection in composite fail-safety (E/E/PE
9980 systems with more than three independent items, i.e. 3-out-of-n and higher tolerances).
9981 1) If the timely detection-plus-negation of a fault in one item is impossible or unsuitable, the chance
9982 occurrence of a further fault in other items should be taken into account.
9983 2) It is necessary that simultaneous faults in two items are non-hazardous. This means that at least
9984 three independent items are necessary.
9985 3) Periodic tests for faults should be implemented. The tests should be representative for all
9986 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 NOTE: Periodic tests could be limited to the dangerous faults identified within the "DC fault model", i.e.: stuck-at faults,
9989 stuck-open, open or high impedance outputs and short circuits between signal lines.
9990 4) For multiple items (> 3) whose simultaneous malfunctioning could be hazardous, having same or
9991 comparable failure rates "a", the periodic tests frequency (1/tsf) should be set to a value
9992 significantly greater than “a” (e.g. 1000-fold value).
9993 5) If within a system, sub-system or equipment comprising several items not all combinations of
9994 three failed items would be hazardous, the fault detection time may be determined separately for
9995 the various combinations. If, in this case, different fault detection times result for two items, the
9996 shortest time is decisive.
9997
- 121 - prEN 50126-4
9998
9999 Figure D.1 –Single-fault and Multiple-fault detection conditions
10000
prEN 50126-4 - 122 -
10001 Table D.1 - Measures to detect faults in integrated circuits

10002 by means of periodic on-line testing
COMPONENT FAILURE MODES MEASURES
CPU
Register, Internal DC fault model for data One of the following diagnostic measures should be
RAM and addresses implemented:
Dynamic cross-over for - Comparator (HW)

memory cells
- Majority Voter (HW)
Change of information
caused by soft-errors - Coded processing (single item)
No, wrong or multiple - Reciprocal comparison by software

addressing
Other measures can be defined, provided evidence of
detection of listed failures modes is demonstrated.
Instruction No definite failure

decoding and assumption
execution
Program DC fault model

counter, stack
pointer Change of addresses
caused by soft-errors
Clock Incorrect frequency
Period jitter
Reset DC fault model
Drift and oscillation
Individual components
do not initialize to reset
state
- 123 - prEN 50126-4
10003 Table D.1 - Measures to detect faults in integrated circuits

10004 by means of periodic on-line testing
10005 (continued)
COMPONENT FAILURE MODES MEASURES
Memory
Invariable All faults that affect data One of the following diagnostic measures should be
in the memory implemented:
- Signature of a double word (16-bit)
- Block replication
Variable DC fault model for data One of the following diagnostic measures should be
and addresses implemented:
Dynamic cross-over for - RAM test Galpat (or transparent Galpat)

memory cells
- RAM test Abraham
Change of information
caused by soft-errors - Double RAM with HW/SW comparison and
read/write test
No, wrong or multiple
addressing Other measures can be defined, provided evidence of
detection of listed failures modes is demonstrated.
Power supply DC fault model drift and If independent power supplies are used for each
(for integrated oscillation computing channel, then a wrong supply voltage in one
circuits) 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 -
10007 Annex E
10008 (informative)
10009
10010 Guidance on Programmable Devices
10011 E.1 Introduction

10012 This annex gives guidance on the use of Programmable Device (PD) in any area application where
10013 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 FPGA (field-programmable gate array),

10017 PLD (programmable logic device),
10018 EPLD (erasable programmable logic device)
10019 CPLD (complex programmable logic device),
10020 PAL (programmable array logic),
10021 PLA (programmable logic array),
10022 LCA (Logic Cell Array).
10023
10024 A Programmable device is composed of at least 2 items:
10025 1) Hardware: It is an integrated circuit which is included within the hardware development process in
10026 compliance with EN 50126-4 chapter 9.
10027 2) Logic: This is the programming of the programmable device hardware. This is the main purpose
10028 of this annex.
10029 Where the programmable device is able to run application software, this application software should
10030 be developed following the requirements of EN 50126-5. This also applies for the use of pre-existing
10031 programmable device, including soft-cores.
10032 In the case where the functions of the programmable device should be developed in using a language
10033 provided by the programmable device the development of these functions should be according to EN
10034 50126-5.
10035 In this annex the non-applicable requirements in developing the functions for a programmable device
10036 from EN 50126-5 are identified and additional requirements are defined.
10037 In using PDs the safety can only be assured together with processes. Designing these processes
10038 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 The following paragraphs from EN 50126-5 are not applicable during the development of functions for
10043 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 E.2.2.1 The following table defines the requirements which are additional to the
10048 requirements in EN 50126-5 for the development of functions for a programmable device.
10049
EN 50126-5 additional requirements
7.1 - 7.9 none

prEN 50126-4 - 126 -
EN 50126-5 additional requirements
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 - E.2.3
8.6 -
8.7 -
10050
10051 E.2.2.2 All Interfaces between the PD Components and the boundary of the overall PD logic
10052 should be documented or referenced (e.g. Hardware level documentation) in the architecture
10053 of the logic for the PD. The description of these interfaces should address:
10054 a) functional aspects: clocks, resets and protocols;
10055 b) implementation aspects: interfaces timings and synchronization.
10056
10057 E.2.2.3 In accordance with the required safety integrity level for the logic of the PD the
10058 design method chosen should possess features that facilitate
10059 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 - prEN 50126-4
10070 E.2.2.4 If not complex PDs are under development, according to criteria defined during the
10071 validation planning, evidence for this criteria should be provided in the architecture and
10072 design of the PD logic. For these PDs, simplified life cycle and techniques against
10073 systematic faults (see E.2.4) can be adopted.
10074
10075 E.2.2.5 The specified tests (requirements and integration) for the PD logic should address
10076 the following:
10077 a) it should be shown that each PD component provides the specified interfaces for the other
10078 components by executing the components together;
10079 b) it should be shown that the PD logic behaves in an appropriate manner when the external
10080 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 E.2.3.1.1 To produce a PD programming file which implements the architecture and design
10087 for the PD.
10088 E.2.3.1.2 To provide means to be able to maintain and regenerate the PD programming file.
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 E.2.3.4.1 The physical implementation should be performed under the responsibility of the
10097 implementer on the basis of the architecture and design for the PD logic. Requirements from
10098 E.2.3.4.2 to E.2.3.4.3 refer to the PD implementation constraints and programming file.
10099 E.2.3.4.2 The PD implementation constraints should instantiate the implementation

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

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

equations
5a For circuit descriptions that use - - HR HR HR HR

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

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

design environment
7 Application of proven in use (V)HDL - HR HR HR HR HR

simulators
8 Functional test on component level E.6 HR HR HR HR HR

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

constructs
10 Design for testability (depending on E.11 - R R R R

the test coverage in percent)
11 Modularisation E.12 R R R HR HR
12 Coverage of the verification E.13 R R R HR HR

scenarios (test benches)
13 Observation of coding guidelines E.14 HR HR HR HR HR
14 Documentation of simulation E.17 R HR HR HR HR

results
15a Code inspection E.18 - R R HR HR
15b Walk-through E.19 - R R HR HR

prEN 50126-4 - 130 -
16a Application of validated soft-cores E.20 R R R HR HR
16b Validation of soft-cores E.21 - R R 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
17 Internal consistency checks E.5 - HR HR HR HR
18a Simulation of the gate netlist, to E.22 R R R R R

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

delay (STA)
19a Verification of the gate netlist E.24 - R R HR HR

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

with the reference model (formal
equivalence check)
20 For PLD/CPLD in complex - R R R HR HR

designs: check of the design by
simulation
21 Check of IC vendor requirements E.26 - HR HR HR HR

and constraints
22 Documentation of synthesis E.27 - HR HR HR HR

constraints, results and tools
23 Application of proven in use E.28 R HR HR HR HR

synthesis tools
24 Application of proven in use E.29 R HR HR HR HR

libraries/CPLD technologies
25 Script based procedure E.30 R R HR HR
10162 Table E.2 - Synthesis

- 131 - prEN 50126-4
10163
26a Justification for proven in use for E.34 - HR HR HR HR

applied hard cores
26b Application of validated hard E.35 R HR HR HR HR

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

simulation
27b Static analysis of the propagation E.23 R HR HR HR HR

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

simulation
28b Comparison of the gate netlist E.25 R HR HR HR HR

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

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

process technologies in use for less
than 3 years
10164 Table E.3 - Placement, Routing
10165
prEN 50126-4 - 132 -
10166 E.2.5 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 Functional description at high abstraction level in hardware

(V)HDL 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 Most of the used tools for designing programmable devices
use design environment 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 - prEN 50126-4
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-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.6 Functional test on Verification of the implemented function - for example by simulation
component level (using for - at component level. The component under test will be instanced
example (V)HDL test in a typical virtual test environment known as ”test bench” and
benches) 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 such as SET and RESET signals derived
asynchronous constructs 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 Design for testability is governed by the avoidance of
(depending on the test
coverage in percent) - 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 - 134 -
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 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).
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 Syntactic coding rules help to create an easily readable code and
guidelines 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:
- 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.
E.17 Documentation of All the data needed for the functional simulation at component-,
chip- or system level should be well documented and archived with
- 135 - prEN 50126-4
simulation results the following aims:
- 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.
E.18 Code inspection Review of circuit description should be carried out by
- Checking the coding style.

- Verification of the described functionality against the
specification.
- Checking for defensive coding, error and exception handling.
E.19 Walk-through 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)HDL-
Simulation 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 If the vendor validates the soft core, following requirements should
soft-cores be fulfilled:
- 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.
E.21 Validation of soft-cores 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.
10168 Table Description for techniques/measures from E.1 – Design

prEN 50126-4 - 136 -
10169
10170
10171
10172
E.5 Internal consistency Application of proven-in-use tools to avoid systematic failure by

checks sufficient long approved practice of the tools in various projects.
E.24 Verification of the gate Simulation of the gate netlist generated by synthesis tool. The
netlist against a reference applied stimuli for the verification of the circuit by simulation
model 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 Comparison of the circuit functionality described by the (V)HDL
netlist with the reference source code with the circuit functionality of the gate netlist
model (formal equivalence generated by synthesis. The tools based on the formal equivalence
check) 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 A careful checking of the vendor requirements and constraints for
requirements and example minimum and maximum fan-in and fan-out, maximum wire
constraints 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 - prEN 50126-4
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 The documentation of all the synthesis constraints and results is
synthesis constraints, indispensable
results and tools
because of the following reasons:
- 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).
E.28 Application of proven in Tool based mapping of the (V)HDL source code of circuit
use synthesis tools 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 The synthesis and simulation target library for the development of
use libraries/CPLD an programmable device are derived from a common database
technologies and, therefore, are not independent. A systematic failure such as:
- 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.
E.29 Script based procedure 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.
10173 Table Description for techniques/ measures from E.2 –Synthesis
10174
prEN 50126-4 - 138 -
10175
ID Technique/measure Description
E.34 Justification for A hard core is generally regarded as a black box representing the
proven in use for desired functionality and is composed of layout data basis in target
applied hard cores 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-in-
use component. The rest of the circuit should then be verified
intensively.
E.35 Application of The core validation should be carried out by vendors, because of the
validated hard cores 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 Verification of correct function and implementation of used hard cores by
hard cores 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.
E.22 Simulation of the Simulation of the gate netlist produced by the synthesis including 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
(STA) generated by the synthesis tool considering the back-annotation, i.e.
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 - prEN 50126-4
c) Gate and interconnection (wire) delay should be considered
E.24 Verification of the Simulation of the gate netlist generated by synthesis tool. The applied
gate netlist against a stimuli for the verification of the circuit by simulation correspond exactly
reference model by to the stimuli applied during the E.6 "Functional test on component level"
simulation 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 Comparison of the circuit functionality described by the (V)HDL source
gate netlist with the code with the circuit functionality of the gate netlist generated by
reference model synthesis. The tools based on the formal equivalence principle are
(formal equivalence capable of verifying the functional equivalence of a different
check) 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 Verification of the generated layout with respect to vendor design rules,
(DRC) 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
environments, designing programmable devices. This implies:
application of proven
in use cell libraries - 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 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 - 140 -
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 The actual circuit behaviour is defined by number of overlapping physical
%) for process effects particularly for small structures (for example below 0,5 m). As a
technologies in use matter of fact, due to the lack of detail knowledge and necessary
for less than 3 years 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 b) For all safety integrity levels the pre-existing programmable device shall be included in the
10185 validation process of the whole hardware.
10186 c) For safety integrity levels SIL 3 or SIL 4, the following precautions shall be taken:
10187 1. an analysis of possible failures of the pre-existing programmable device and their
10188 consequences on the whole system shall be carried out;
10189 2. a strategy shall be defined to detect failures of the pre-existing programmable device and to
10190 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 5. that failures of the pre-existing programmable device are detected and the enclosing system is
10194 protected from these failures;
10195 6. that the assumptions about the environment of the pre-existing programmable device are
10196 fulfilled.
- 141 - prEN 50126-4
10197 Annex F
10198 (normative)
10199
10200 Previously Developed Hardware (PDH) and Commercial Off The Shelf
10201 Hardware (COTSH)
10202 F.1 Introduction
10203 F.1.1 Purpose
10204 This sub-clause specifies the issues associated with the use of previously developed or commercially
10205 procured Hardware. It provides guidance and requirements for the use and embedding processes of
10206 PDH and COTSH.
10207
10208 F.1.2 Modifications to Previously Developed Hardware
10209 Modifications may be needed by different kind of change requests. That means any kind of
10210 requirement change, error detection, changes in HW-technology, procurement problems.
10211 F.1.2.1 An impact analysis shall be carried out. Impacted subsystems and components shall be
10212 involved in the verification and validation process.
10213 F.1.2.2 If the previously developed HW uses a different SW there a re-verification of HW-/SW
10214 interfaces shall be performed.
10215 F.1.2.2 The safety integrity level shall be analysed, reviewed and confirmed upon modification. If
10216 there are differences to the original SIL, the influence shall be considered for interfaces
10217 and on system level.
10218
10219 F.1.3 Influence in System Environment
10220 Previously developed HW may have an impact in the design toolchain and other HW/SW components
10221 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 F.1.4.1 Previously developed HW shall be integrated in the change and configuration
10227 management processes and handled as a discrete component.
10228 F.1.4.2 the traceability from product and life cycle data of the previous application to the new
10229 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 The use of COTSH components shall be verified in the system implementation process, as defined
10234 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 F.2.1.1 quality control procedures shall be established at the component manufacturer
10238 F.2.1.2 quality records of the production line shall be available at the component manufacturer
10239 F.2.1.3 field data representing the components functionality under predefined conditions shall be
10240 maintained
10241 F.2.1.4 the components RAM specification should be available through manufacturer’s testing
10242 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 Due to availability demands some requirements for procurement are provided which have influence in
10247 the hardware design.
10248 The major concerns refer to:
10249 a) Market lifetime availability of COTS components

10250 b) Second source supplier strategy
10251 c) Evolution of COTS components (down grade compatibility of new components)
10252 d) Identification of series production component parameter variations
10253
- 143 - prEN 50126-4
10254 Annex G
10255 (informative)
10256 Structure of Hardware/Systems Safety Cases
10257 This annex defines the contents of Generic Product, Generic Application, Specific Application and
10258 Cross-Acceptance Safety Cases for E/E/PE Systems by defining the hierarchy of the headings and
10259 the names for the headings based on the definition of the safety case from sub-clause 8.2. Also
10260 suggestions on how to develop some topics are given.
10261 G.1 Generic Product Safety Case Guidance for E/E/PE

10262 The Safety Case contains the documented safety evidence for the system/sub-system/equipment,
10263 and, according to Part 1, it is structured as follows:
10264 Part 1 Definition of System (or sub-system/equipment)
10265 This precisely defines or reference the system/sub-system/equipment to which the Safety Case
10266 refers, including version numbers and modification status of all requirements, design and application
10267 documentation.
10268 No specific structure for this chapter.
10269 Part 2 Quality Management Report
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 Safety Management Report
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 Technical Safety Report
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 Related Safety Cases
10279 This contains references to the Safety Cases of any sub-systems or equipment on which the main
10280 Safety Case depends.
10281 This also the demonstrates that all the safety-related application conditions specified in each of the
10282 related sub-system/equipment Safety Cases are:
10283 either fulfilled in the main Safety Case,
10284 or carried forward into the safety-related application conditions of the main Safety Case.
10286 Part 6 Conclusion
10287 This summarises the evidence presented in the previous parts of the Safety Case, and argue that the
10288 relevant system/sub-system/equipment is adequately safe, subject to compliance with the specified
10289 application conditions.

prEN 50126-4 - 144 -
10291 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 Safety Management Report
10296 According to contents defined in clause 8.6 this chapter may be arranged in the following headings:
10297 3.1. Safety life cycle

10298 3.2. Safety organisation
10299 3.3. Safety plan
10300 3.4. Hazard log
10301 3.5. Safety requirements specification
10302 3.6. Design
10303 3.7. Safety reviews
10304 3.8. Generic Product handover
10305 3.9. Operation and maintenance
- 145 - prEN 50126-4
10306 G.1.2 Technical Safety Report
10307 According to contents defined in clause 8.6, this chapter may be arranged as follows:
10308
10309 Figure G.1 – Structure of Technical Safety Report
10310 Section 1 Introduction
10311 This section includes an overview description of the design, including a summary of the technical
10312 safety principles that are relied on for safety and the extent to which the system/sub-
10313 system/equipment is claimed to be safe in accordance with this standard.
10314 Section 2 Assurance of correct functional operation
10315 This section contains all the evidence necessary to demonstrate correct operation of the system/sub-
10316 system/equipment under fault-free normal conditions (that is, with no faults in existence), in
10317 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 This contains a general description of the system/sub-system/equipment design, in sufficient depth to
10321 convey a clear understanding of the principles and techniques which it uses.
10322 NOTE: Some particular topics which should receive attention include
10323 - dependence between hardware and software,

10324 - sequence of interaction,
10325 - response times,
10326 - self test routines,
prEN 50126-4 - 146 -
10327 - health monitoring,

10328 - data acquisition techniques,
10329 - graceful degradation,
10330 - negation methods.
10331 2.2 Definition of interfaces (as detailed below);
10332 2.2.1 Man-machine interfaces
10333 a) Operator
10334 This describes the mechanisms by which the system/sub-system/equipment will be operated by
10335 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 This describes the processes carried out by engineering personnel to configure the system/sub-
10342 system/equipment to a specific railway or application.
10343 EXAMPLE
10344 - software parameterising;
10345 - hard wiring;
10346 - installation techniques;
10347 - procedures.
10348 c) Maintenance
10349 This describes the interface mechanisms, including the use of any ancillary equipment, which
10350 will be used by maintenance personnel in the course of performing the various levels of maintenance.
10351 More detailed information is contained in 5.2.
10352 2.2.2 System interfaces
10353 a) Internal
10354 This defines the functional and physical interfaces between items internal to the system/sub-
10355 system/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.

- 147 - prEN 50126-4
10362 b) External
10363 This defines the functional and physical interfaces between the system/sub-system/equipment
10364 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 This describes the system/sub-system/equipment hardware architecture, and explains how the design
10375 achieves the required integrity, as laid down by the requirements specification and any relevant
10376 standards, in respect of
10377 - reliability,
10378 - availability,
10379 - maintainability,
10380 - safety.
10381 Consideration of safety may be limited to fault-free conditions, because effects of faults are dealt with
10382 elsewhere (see Section 3).
10383 2.6 Assurance of correct software functionality.
10384 All documentation required by EN 50126 Part 5 is included or referenced in this section, particularly
10385 the Software Validation Report and the Software Assessment Report.
10386 Section 3 Effects of faults
10387 This section aims to demonstrate that the system/sub-system/equipment continues to meet its
10388 specified safety requirements, including the quantified safety target, in the event of random hardware
10389 faults.
10390 In addition, a systematic fault could still exist, despite the quality and safety management processes
10391 defined in this standard. This section demonstrates which technical measures have been taken to
10392 reduce the consequent risk to an acceptable level.
10393 This section also includes demonstration that faults in any system/sub-system/equipment having a
10394 Safety Integrity Level lower than that of the overall system, including Level 0, cannot reduce the
10395 safety of the overall system.
10396 The following headings can be used in this section. Guidance is also given in Table A.6 and Table
10397 A.7.
10398 3.1 Effects of single faults;
10399 In this section the safety principles chosen from the ones described in 8.2 is given. Also the results of
10400 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 In this section, evidence of achieved independence is given, according to Part 2 and Annex D,
10403 clauses D.1 and D.2.
10404 3.3 Detection of single faults;
10405 The techniques used to achieve detection and negation of identified faults within the permitted time
10406 are shown, including supporting calculations. The sources of basic failure rate data used in the
10407 calculations (for example, hardware component failure rates) are identified, and the method of
10408 quantitative analysis. An example of an approach to fulfilment of these requirements is contained in
10409 D.3.
10410 3.4 Action following detection (including retention of safe state);
10411 In this section, the description and the evaluation against safety target of the reaction after the
10412 detection of a single fault is given according to requirements described in 8.2
10413 3.5 Effects of multiple faults;
10414 In this section the results of Hazard analysis with regard to Multiple faults and common-cause faults,
10415 according to clauses from 8.2.4.8.4 to 8.2.4.8.6, are provided. Also the techniques used to achieve
10416 detection-plus-negation of multiple faults within the permitted time are shown, including supporting
10417 calculations. An example of an approach to fulfilment of these requirements is contained in D.5.
10418 3.6 Defence against systematic faults
10419 In addition to the quality and safety management techniques which are used to minimise the
10420 probability of human error, technical measures shall be taken such that if a hazardous systematic fault
10421 should exist it would, as far as reasonably practicable, be prevented from creating an unacceptable
10422 risk.
10423 EXAMPLE Any diversity introduced in the development process to avoid a systematic fault to be undetected.
10424 Section 4 Operation with external influences
10425 This section concerns the ability of the system/sub-system/equipment to operate correctly and safely
10426 when subjected to specified external influences. "Correct operation" includes fulfilment of both
10427 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) Definition of access levels
10436 The access level defines who has access, reason for access and how access is achieved, thereby
10437 guarding against unauthorised access. For each of the particular operations below, persons
10438 performing these functions will require to meet certain criteria, defined in respect of
10439 - skill discipline,
10440 - skill level,
10441 - equipment-specific training.

- 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 Where necessary, provision to deal with additional, more severe, conditions specified by the railway
10464 authority are described here.
10465 NOTE: Examples of more severe conditions are condensation due to rapid variation in ambient
10466 temperatures of equipment; severe pollution of the air by dust, smoke, steam, excessive heating from,
10467 for example, fire or solar radiation; action/entry of plants, insects or animals; accumulation of dirt and
10468 dust (conductive and/or non-conductive).
10469 Section 5 Safety-related application conditions
10470 This section defines the rules, conditions and constraints relevant to functional safety which need to
10471 be observed in the application of the system/sub-system/equipment.
10472 General topics which to be considered include the following (they can be accordingly organized in
10473 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 - safety justification of support equipment and tools, such as test equipment, maintenance
10482 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) Configuration
10486 If a sub-system or equipment is such that it has to be configured for each particular application, then
10487 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 This documentation details how sub-systems and equipment are built into a particular signalling
10498 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 If a sub-system or equipment is of sufficient generic design that it could be employed in systems for
10510 various applications, then how it is configured and set-up to meet these different applications is also
10511 documented. Any limitations or conditions for safe use are fully specified.
- 151 - prEN 50126-4
10512 5.2 Operation and Maintenance
10513 1) operational status
10514 The conditions that exist in each system/sub-system/equipment are described to provide operating
10515 and maintenance personnel with sufficient understanding during the following situations:
10516 a) start-up
10517 This describes the start-up conditions of the system, sub-system or equipment when power is initially
10518 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 Once the system/sub-system/equipment has successfully completed initialisation, the conditions
10528 during normal operation are described.
10529 EXAMPLE
10530 - cycle times;
10531 - non-data routines;
10532 - disclosure of faults.
10533 c) changeover
10534 If the equipment, or the system/sub-system in which it is configured, has a facility to change over to
10535 either a cold or hot standby system/sub-system, then the conditions defined in a) and b) are re-stated
10536 for this changeover routine. The reaction of the equipment to the changing of failed modules is also
10537 be clearly defined.
10538 d) shut-down
10539 all relevant conditions when a system, sub-system or item of equipment is shut down intentionally for
10540 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

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 NOTE: "First line" is preventative maintenance and fault-finding/repair carried out on site, with
10553 "second line" being preventative maintenance and possible repair in a workshop environment, that is,
10554 off site.
10555 3) periodic maintenance
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 The methods and techniques for the operational safety monitoring, to ensure that the features
10572 incorporated into the design, and the assumptions made during the initial safety assessment, remain
10573 valid for the actual circumstances encountered during in-service use are described here.
10574 NOTE: This can include, for example,
10575 - the monitoring of safety-related performance and comparison with the predicted performance,
10576 - the monitoring and assessment of failure reports to detect failure trends or possible hazardous
10577 failures which can be corrected, thereby improving safety and reliability,
10578 - investigation of incident and accident reports to identify any changes required to improve the
10579 safety performance of the system.
10580 5.4 Decommissioning and disposal
10581 The technical safety precautions and procedures which will be necessary when the system/sub-
10582 system/equipment is eventually decommissioned are documented. This includes consideration of
10583 possible phased introduction of replacement systems whilst the railway continues in operation.
- 153 - prEN 50126-4
10584 Appropriate warnings and instructions concerning final disposal of equipment after decommissioning
10585 are also included.
10586 Section 6 Safety Qualification Tests
10587 An account of the Safety Qualification Tests, including a full description of the tests carried out and
10588 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

10592 The contents of this chapter may the structured following the same recommendation for a Generic
10593 Product Safety Case.
10596 Product Safety Case. The Section 3 (“Effect of faults”) may be not applicable or relevant, for safety
10597 aspects, as treated within related Generic Products Safety Case/s.
10598 G.3 Specific Application Safety Case Guidance for E/E/PE

10601 Product Safety Case.
10604 Product Safety Case. The Section 3 (“Effect of faults”) may be not applicable or relevant, for safety
10605 aspects, as treated within related Generic Products Safety Case/s.
10606 The evidences provided within the Section 2.3 (“Fulfilment of System Requirements Specification”)
10607 and Section 2.4 (“Fulfilment of Safety Requirements Specification”) should be given separately for
10608 the two parts of the Specific Application Safety Case:
10609 Application Design Part: analyses and reports produced as part of the activities carried out
10610 during the Design and Implementation phase of the E/E/PE system.
10611 Physical Implementation Part: analyses and reports produced as part of the activities carried
10612 out during the Manufacturing, System Integration and System Validation of the E/E/PE
10613 system.
10614 G.4 Cross-Acceptance Safety Case Guidance for E/E/PE

10615 G.4.1 Cross-Acceptance Process
10616 A structured and risk based framework for cross-acceptance of product, system or process is
10617 developed in this guidance comprising seven core principles. The principles are universal and are
10618 particularly pertinent to safety critical systems where no systematic and efficient framework for their
10619 adoption and application in new applications or environments exists.
10620 G.4.2 The Basic Premise
10621 The cross-acceptance of a product, system or process is implicitly founded on a number of key
10622 assumptions and conditions namely
10623 the product, system or process has been specified, designed and developed by a competent,
10624 capable and reputable organisation,
prEN 50126-4 - 154 -
10625 the product, system or process has been scrutinised, analysed and assessed through a rigorous
10626 process to assure its relevant safety, environmental and technical performance and this process
10627 has been documented at an appropriate level of detail,
10628 the product, system or process has been evaluated for its compliance with regulatory
10629 requirements and best practice standards and codes of practice,
10630 the assessment has been peer reviewed and the product, system or process approved or
10631 certified by a relevant competent body or authority in its native environment implying tolerability
10632 of its risks subject to specified constraints and controls,
10633 the product, system or process has preferably got a demonstrable record of adequate
10634 verification, validation and testing or trouble free operation in its native environment,
10635 the product, system or process has potential for a wider scope of application beyond its initial
10636 native environment either in its original state, or through small-scale redesign and adaptation,
10637 there is a perceived or real safety or environmental benefit or need in adapting the product,
10638 system or process for use in new (target) environments,
10639 there is an implicit or explicit record of the above conditions and assumptions which can be made
10640 available to relevant third parties as deemed appropriate.
10641 Even though not always stated, these conditions and assumptions are required or perceived to hold
10642 true for the purpose of cross-acceptance.
10643 G.4.3 Principles of Cross-Acceptance
10644 The framework for systematic cross-acceptance developed and proposed here essentially comprises
10645 7 key principles as detailed below.
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 d) Specify the technical, operational and procedural adaptations required
10650 to cater for the differences
10651 e) Assess the risks arising from the differences
10652 f) Produce a credible case for the adaptations adequately controlling the
10653 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 Cross-acceptance is broadly applicable to generic product/system/process and generic

10657 application cases. In this spirit, specific applications require further scrutiny and justification.
10658 Cross-acceptance is essentially a differential case and requires a credible native (baseline) and a
10659 target environment and associated arguments for safety.
10660 To construct a baseline, the product, system or process shall be specified and
10661 documented in its native environment including (whenever applicable)
10662 – a record of technical, operational, environmental, quality and safety performance
10663 requirements including applicable rules and standards,
10664 – specification or description of relevant operational environment, scope, boundary
10665 and interfaces,
10666 – description of the system architecture and composition including rules &
10667 procedures, people and competence issues and automation aspects,
- 155 - prEN 50126-4
10668 – description of the operational, maintenance and retrofit processes,

10669 – description of the operational scenarios under normal, degraded and failed
10670 modes of the system,
10671 – description of emergency response arrangements and procedures.
10672 Justification of the baseline case in the native application comprising
10673 – evidence based on analysis, simulation, testing, verification and validation of core
10674 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 The above evidence should be embodied within the cross-acceptance safety case.
10682 b) Specify the target environment and application
10683 To construct a systematic view of the target application, the product, system or process shall be
10684 specified and documented in the new environment including
10685 – a document addressing technical, operational, environmental, quality and safety

10686 performance requirements,
10687 – specification of operational environment, scope, boundary and interfaces in the target
10688 application,
10689 – description of the system architecture and composition including applicable rules &
10690 procedures, people and competence issues and automation aspects,
10691 – description of the operational, maintenance and retrofit processes in the new
10692 environment,
10693 – description of the operational scenarios under; normal, degraded and failed modes of
10694 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 Identification of the differences between the native and target applications including significant
10698 changes in
10699 – technical, operational, environmental, quality and safety performance requirements,

10700 – scope, boundary, operational environment and interfaces,
10701 – system architecture and composition including rules & procedures, people and
10702 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 - 156 -
10706 d) Specify the technical, operational and procedural adaptations
10707 Identification of the adaptations required to cater for the differences between the native and
10708 target applications including
10709 – identification of the scope and boundary of the invariant aspects of the system
10710 (similarities),
10711 – technical, procedural or operational changes to the product, system or process to
10712 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 Identify the hazards and assess the risks arising from differences between the native and target
10717 applications including
10718 – assessment of risks arising from the differences in technical, operational,

10719 environmental adaptation of the product, system or process for target application,
10720 – verification and validation of the assumptions and evidence,
10721 – identification of all additional measures which could mitigate and reduce the risks
10722 further including estimates for their potential impact.
10723 f) Produce a credible case for the adaptations adequately controlling the risks arising from
10724 the differences
10725 Ensure the adaptations have resulted in the reduction and control of the risks to a target level
10726 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 – determination of residual risk after adaptations and demonstration of compliance with
10731 best practice standards and legal framework.
10732 g) Develop a generic or specific cross-acceptance safety case
10733 This involves developing a generic or specific application safety case and an appropriate safety
10734 management system for the implementation/deployment in the target environment.
10735 In the spirit of a risk based systemic framework, the scope and depth of application and
10736 compliance with each principle should be commensurate with the scale of perceived risks.
10737
- 157 - prEN 50126-4
10738 Annex H
10739 (informative)
10740 Bibliography of techniques
10741
10742 H.1 Introduction

10743 This informative annex provides a set of descriptions of techniques ranked relevant to the scope and
10744 compliance with the other parts of this standard. The descriptions are intended to serve as hints for
10745 readers which are not familiar with particular techniques employed in the safety analysis and
10746 assurance of electronic systems. However, more detailed information should be gathered from other
10747 sources which are given where appropriate.
10748 There is no claim to completeness of this annex.
10749 H.1.1 Aim
10750 This introduction provides an overview of the general characteristics of the techniques. The main goal
10751 is to gain a uniform representation of the techniques’ properties in a tabular form. The conception of
10752 this kind of presentation is based on VDI/VDE 3681:2005 (Classification and evaluation of description
10753 methods in automation and control technology). With the tabular representation of data the following
10754 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 Structure
10759 The demand for a well-arranged and traceable concept of the annex arises from the idea to give a
10760 structured overview on existing techniques used in railway applications.
10761 Due to this demand the annex utilises one clearly arranged table to outline the techniques’ properties.
10762 The lines of this table consist of the entire list of techniques, described in the main part of the annex.
10763 In this structured list some specific techniques are grouped to a generic class of techniques. The
10764 columns are classified in three parts described in the following sub-clause s. The degree of matching
10765 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 In the first part of the table it is distinguished whether a technique is a means of description, a method
10768 or both.
10769 A means of description describes determined facts (approaches, task specification, solutions etc.) in a
10770 graphical way for visual perception and storage. Means of description are made up of symbols (e. g.
10771 alphanumeric characters, graphical elements or other representative elements), as well as
10772 conventions concerning their combination (syntax). The individual representative elements, their
10773 combinations and their categorisation are classified in a technical, more or less explicitly and formally
10774 specified context according to certain conditions, concepts or rules for reasoning (semantics).
10775 A method in contrast is a systematic, on a regulating system based, procedure to obtain knowledge or
10776 practical results.
10777 Considering the fact, that some techniques may have elements of both, means of description and
10778 method, in this context the term of an integrated method is applied.
prEN 50126-4 - 158 -
10779 To categorise a technique as a means of description, as a method or as both the following questions
10780 can be helpful:
10781 - Is the technique used to formulate/describe a problem/system etc.?

10782 Means of Description
10783 - Does the technique represent a way to solve a problem according to a plan?
10784 Method
10785 If both these questions can be answered positively, we can assume the regarded techniques have
10786 fractions of a means of description and a method; these techniques can be classified as integrated
10787 methods. The resulting classification is shown in the column MoD/M (Means of Description / Method)
10788 of Table H.1.
10789 H.1.2.2 Technique – Main attributes
10790 In the second part the techniques are analysed with respect to a list of fundamental structuring
10791 attributes, which can be checked using the following auxiliary questions based on VDI/VDE 3681:
10792 - Formal basis: Does the technique have a mathematical basis and a completely defined syntax as
10793 well as a clear semantic interpretation?
10794 - Description of behaviour: Can the technique be used to describe the dynamic behaviour of a
10795 system?
10796 - Description of structure: Can the technique be used to describe the system’s structure (e. g.
10797 hierarchy, composition/decomposition) and/or structural modifications?
10798 - Required expertise: Is a higher degree of expertise required to use this technique?
10799 - Level of standardisation: Are there any standards or assured guidelines describing how to use
10800 the technique?
10801 - Level of acceptance and customariness: Is the technique commonly accepted and used in the
10802 railway sector?
10803 - Explicit time representation: Does the technique empower the user to model quantitative
10804 statements about instants and time periods (e. g. between events)?
10805 - Description of process interaction: Can the technique be used to describe synchronous,
10806 asynchronous or concurrent processes?
10807 The column Criteria of Table H.1 gives an overview on the property based classification of the
10808 techniques contained in the describing sub-clause s H.2.1 to H.2.35.
10809 H.1.2.3 Technique – Development phases
10810 The last differentiating factor chosen to categorise the diverse techniques is the development phase
10811 the technique can be used in. To accord the structure of the normative chapters of part 4 the following
10812 phases are differentiated:
10813 - Requirements (specification) phase;
10814 - Architecture phase;
10815 - Design phase;
10816 - Implementation and Testing phase;
10817 - Integration phase;
10818 - Manufacturing phase;

- 159 - prEN 50126-4
10819 - Installation and Commissioning phase;
10820 - Final acceptance phase.
10821 The resulting classification of the techniques according to development phases is shown in the
10822 column Phase of Table H.1.
prEN 50126-4 - 160 -
10823
a) b) c)
MoD/M Criteria Phase
Description of process
Means of Description
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
H 2 1 Cause Consequence Diagrams × + + 0 + + + 0 + +
H 2 2 Checklists × + + + + + + + +
H 2 3 Configuration Management × 0 + + + + + + + + +
H 2 4 Decision Tables / Truth Tables × × + + 0 + + + + + +
Design
1 Constraint × + + + + + +
Analysis
Design Design
H 2 5
Analysis 2 Interface × + + + + +
Analysis
Design Logic
3 × + + +
Analysis
H 2 6 Domain Specific Languages × + + + + + + + + + +
H 2 7 Dynamic Reconfiguration × + 0 0 + + + +
- 161 - prEN 50126-4
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
Error Detecting
1 and Correcting × + + + + +
Error Codes
H 2 8 Avoiding
Methods 2 Error Guessing × + + + + 0 0
3 Error Seeding × + 0 + 0
H 2 9 Event Tree Analysis × × + + + 0 + + 0 + 0 +
H 2 10 Fault Detection and Diagnosis × 0 + + + + + + + + + +
H 2 11 Fault Isolation Methodology × 0 + + + + + + + + + +
Higher Order
1 × + + + + + + + + 0
Logic
Formal 2 Model Checking × + + + + + + + + + 0

H 2 12
Proof
3 Temporal Logic × + + + + + + 0
Theorem
4 × + + + + + + + + 0
Proving
H 2 13 Graceful Degradation × + 0 + + + +
prEN 50126-4 - 162 -
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
Bent Pin
Analysis / Cable
1 × 0 0 0 + + 0
Failure Matrix
Analysis
Electromagnetic
Hardware 2 Compatibility × + + + + + + +
Analysis
H 2 14 Safety
Analysis
Energy Trace
3 and Barrier × 0 0 + + + + +
Analysis
Materials
4 Compatibility × 0 0 + + + + +
Analysis
H 2 15 Impact Analysis / Change Analysis × + + + + + + + +
Fagan
1 × + 0 + + + 0 0
Inspection
H 2 16 Inspections
Walkthrough /
2 × + 0 + + + 0 0
Design Review
H 2 17 Interface
1 Interface × 0 + + + +
- 163 - prEN 50126-4
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
Analysis
Methods
Interface
2 × + + +
Testing
H 2 18 Markov Models × × + + + + + + + + 0 + + + + +
H 2 19 Metrics × + + + + + 0 + +
H 2 20 Modular Approach × 0 + + + + + + 0
H 2 21 Monte-Carlo Simulation × + + + + + + + + + 0
H 2 22 Operational Readiness Review × + + +
Performance
1 × + + + 0 0 0 + + + + +
Modelling
Performance
H 2 23
Engineering
Performance
2 × + + + 0 0 0 + + + + + 0 0
Requirements
H 2 24 Process Simulation × + + + + + + + +
H 2 25 Prototyping / Animation × + + + + + + + + 0 0
H 2 26 Recovery Block × + + + + + + +
prEN 50126-4 - 164 -
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
Response Timing and Memory
H 2 27 × + + 0 + + 0 0 + + + + 0 +
Constraints
H 2 28 Retry Fault Recovery Mechanisms × + + + + + + +
H 2 29 Safety Bag × 0 + + + + + +
System Common
H 2 30 Safety 1 Cause Failure × 0 0 + + + + +
Analysis Analysis
Contingency
2 × 0 + + +
Analysis
Critical Incident
3 × + 0 + + +
Technique
Criticality
4 × × 0 0 0 + + + 0 + + + 0
Analysis
Failure Modes
and Effects
5 × 0 + + 0 + + + +
(and Criticality)
Analysis
9
8
7
6
Technique
13
12
11
10
Study
Hazard
Analysis
Analysis
Analysis
Analysis
Analysis
Diagram
Repetitive
Fault Tree
Operability
Preliminary
Hazard and
Root Cause
Fault Hazard
Operating and
Support Hazard
Reliability Block
Failure Analysis
×
×
×
(MoD)
- 165 -
Method (M)
×
×
×
×
×
×
×
×
MoD/Ma)
Formal basis
+
+
Description of
+
+
behaviour
Description of
+
+
+
structure
Required expertise
0
0
0
0
0
+
+
Level of
0
+
+
+
+
Criteria
standardisation
b)
Level of acceptance
0
0
+
+
+
+
+
+
and customariness
Explicit time
+
representation
prEN 50126-4
interaction
Requirements
+
+
+
+
+
specification
Architecture
0
0
+
+
+
+
+
Design
0
+
+
+
+
+
Implementation and
0
+
+
+
+
+
+
Testing
Integration
+
+
+
+
+
Phasec)
Manufacturing
0
+
Installation and
+
+
Commissioning
Final acceptance
+
+
+
+
prEN 50126-4 - 166 -
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
Single Point
14 × + + + +
Failure Analysis
Sneak Circuit
15 × 0 0 0 + + +
Analysis
Model Based
1 × + 0 + +
Testing
H 2 31 Testing
2 Stress-Testing × + + + +
3 Test Oracle × 0 0 + + + +
H 2 32 Time Petri Nets × × + + 0 0 + 0 + + 0 0 + 0 +
H 2 33 Traceability × + + + + + + + + +
Certified Tools
1 and Certified × 0 + + + + + + + + +
Translators
Trusted
H 2 34 Library of
Components
2 Trusted/Verified × 0 + 0 + +
Components
3 × +
Tools proven in
H
2
35
Unified
Modelling
Language
4
3
2
1
Technique
Technique
use
Diagram
Diagram
Diagram
Sequence
State Chart
Component
Class Diagram
Means of Description Means of Description
×
×
×
×
(MoD) (MoD)
- 167 -
Method (M) Method (M)

MoD/Ma)
MoD/Ma)
Formal basis Formal basis
0
0
0
0
Description of Description of
+
+
+
+
behaviour behaviour
Description of Description of
+
+
+
+
structure structure
Required expertise Required expertise

0
0
0
0
Level of Level of
+
+
+
+
Criteria
standardisation standardisation
Criteriab)
b)
Level of acceptance Level of acceptance

+
+
+
+
and customariness and customariness

Explicit time Explicit time
+
+
representation representation
Description of Description of process
prEN 50126-4
+
+
+
+
process interaction interaction

Requirements Requirements
+
+
specification specification
Architecture Architecture
0
0
+
+
Design Design
+
+
+
+
Implementation and Implementation and

0
0
Testing Testing
Integration Integration
Phasec)
Phasec)
Manufacturing Manufacturing
Installation and Installation and
Commissioning Commissioning
Final acceptance Final acceptance

0
0
0
0
prEN 50126-4 - 168 -
MoD/Ma) Criteria
b)
Phasec)
Level of acceptance
Implementation and
and customariness
Required expertise
Final acceptance
Technique
Commissioning
standardisation
Installation and
representation
Manufacturing
Requirements
Description of
Description of
Formal basis
specification
Explicit time
Architecture
Method (M)
Integration
interaction
behaviour
structure
Level of
Testing
Design
(MoD)
a) 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 Table H.1- Properties of techniques
10825
- 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 o Syntax / Semantics: For example, when the technique is based on some (graphical)
10831 symbols, these are introduced concisely.
10832 o Input / Output: Specification of the input and the output of each technique is provided.
10833 o Fundamental properties: Major characteristics of the technique are outlined.
10834 o Relations to other techniques: When available, relations to other techniques are outlined.
10835 - Typical applications and constraints: Typical applications and when available, constraints of the
10836 technique’s application are outlined.
10837 - References: References to sources for gathering more detailed information about the technique
10838 are classified in the following way:
10839 o Up-to-date references appear unmarked in the list of references.
10840 o References to the classics, origins, of the technique are marked with *.
10841 o References to other standards are marked with **.
10842 H.1.4 Application Guidelines
10843 There are two types of information that can be gained with respect to a specific technique in this
10844 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 o Is the technique a matter of means of description or of a method (MoD/M) or of both?
10848 o What are the main attributes (criteria) of the technique?
10849 o In which development phase can the technique be applied?
10850 H.1.5 Reference
10851 VDI/VDE 3681:2005: Classification and evaluation of description methods in automation and control
10852 technology
10853
10854
10855 H.2 Techniques

10856 H.2.1 Cause Consequence Diagrams (CCD)
10857 Aim
10858 To model, in a diagrammatic form, the sequence of events resulting from the occurrence of an
10859 initiating event.
prEN 50126-4 - 170 -
10860 Description
10861 Cause Consequence Diagrams combine causes and consequences of initial events, resulting in a
10862 structured model with many different possible outcomes.
10863 CCD are made up of the following main components/symbols:
10864 - Initiating event box: Represents an independent event that can initiate a sequence of events
10865 leading to a consequence;
10866 - Intermediate event: Represents the functionality of a (sub-)system; the function is either
10867 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 - OR- and AND-gate: Represent a logical combination of initiating events and/or intermediate
10871 events.
10872 The graph also can contain vertex symbols which describe the conditions for propagation along
10873 different branches from the vertex.
10874 Starting from a critical event (input), a cause consequence graph is traced backwards and forwards.
10875 In the backwards direction it is equivalent to a fault tree with the critical event as the given top event.
10876 In the forward direction the possible consequences arising from an event are identified. The diagrams
10877 can be used to compute the probability of occurrence of certain critical consequences (output).
10878 CCD can be interpreted as a combination of Fault Tree Analysis (H.2.30.7) and Event Tree Analysis
10879 (H.2.9).
10880 Typical applications and constraints
10881 CCD can be applied to a system very early in design development and thereby identify safety issues
10882 early in the design process.
10883 A CCD can only have one initiating event; therefore, multiple Cause Consequence Analysis (CCA) will
10884 be required to evaluate the consequence of multiple initiating events.
10885 References
10886 Andrews, J. D. and Ridley, L. M.: Application of the Cause-Consequence Diagram Method to Static
10887 Systems, Reliability Engineering and System Safety, 75(1), Elsevier, 2002.
10888 ISSN 0951-8320
10889 Andrews, J. D. and Ridley, L. M.: Reliability of Sequential Systems Using the Cause-Consequence
10890 Diagram Method, Proc Instit. Mech. Eng., 215 (Part E): 207-220, 2001.
10891 Ericson, C. A.: Hazard Analysis Techniques for System Safety, John Wiley & Sons, 2005. ISBN 978-
10892 0-471-72019-5
10893 Leveson, N. G.: Safeware: System Safety and Computers, Addison-Wesley, 1995.
10894 ISBN 978-0-201-11972-5
10895
10896 H.2.2 Checklists
10897 Aim
10898 To provide a stimulus to critical appraisal of all aspects of the system rather than to lay down specific
10899 requirements.
- 171 - prEN 50126-4
10900 Description
10901 Checklist consists of a set of questions (input) to be completed by the person performing the
10902 checklist. The object in completing a checklist is to be as concise as possible. When extensive
10903 justification is necessary this should be done by reference to additional documentation. Pass, Fail and
10904 Inconclusive, or some similar restricted set of tokens should be used to record the results for each
10905 question (output). This conciseness greatly simplifies the process of reaching an overall conclusion as
10906 to the results of the checklist assessment.
10907 Particularly important classes of checklists are those developed for hazard identification and analysis
10908 techniques like FMEA (H.2.30.5) and HAZOP (see H.2.30.8).
10910 Checklists have a wide scope of application. It should be clear that their use depends critically on the
10911 expertise and judgment of the engineer selecting and applying the checklist. As a result the decisions
10912 taken by the engineer, with regard to the checklist(s) selected, and any additional or superfluous
10913 questions, should be fully documented and justified. The objective is to ensure that the application of
10914 the checklists can be reviewed and that the same results will be achieved unless different criteria are
10915 used.
10916 References
10917 ** ISO/IEC 18019: Software and system engineering Guidelines for the design and preparation of
10918 user documentation for application software, Standards Australia & New Zealand, 2007. ISBN 978-0-
10919 7337-7976-3
10920 Selby, R. W.: Software Engineering: Barry W. Boehm's Lifetime Contributions to Software
10921 Development, Management, and Research; John Wiley & Sons, 2007.
10922 ISBN 978-0-470-14873-0
10923 Myers, G. J., Badgett, T. and Sandler, C.: The Art of Software Testing; John Wiley & Sons, 2012.
10924 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 Configuration Management (CM)
10928 Aim
10929 To ensure the group consistency of hardware and software development deliverables as those
10930 deliverables change.
10931 Description
10932 Configuration Management is a technique used throughout development. In essence, it requires the
10933 recording of the production of every version of every "significant" deliverable and of every relationship
10934 between different versions of the different deliverables (input). The resulting records allow the
10935 designer to determine the effect on other deliverables of a change to one deliverable (especially on of
10936 its components) (output). In particular, systems or subsystems can be reliably re-built from consistent
10937 sets of component versions.
10939 –
10940 References
10941 Babich, W. A.: Software Configuration Management, Addison-Wesley, 1986.

prEN 50126-4 - 172 -
10942 Tichy, W. F.: Software Configuration Management, IEEE Computer Society Press, Tutorial notes of
10943 the ICSE, May 1989.
10944 Estublier, J.: Software Configuration Management: A Roadmap, in A. Finkelstein (ed.), The Future of
10945 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 Decision Tables / Truth Tables
10950 Aim
10951 To provide a clear and coherent specification and analysis of complex logical combinations and
10952 relationships.
10953 Description
10954 These related methods use project records (input) to form two dimensional tables (output). Truth
10955 Tables concisely describe logical relationships between Boolean program variables. Decision Tables
10956 associate conditions with actions to perform.
10957 The conciseness and tabular nature of both methods make them appropriate as a means of analysing
10958 complex logical combinations expressed in code. Both methods are potentially executable if used as
10959 specifications.
10960 Decision Tables can be used for test case design e. g. based on a Cause Consequence Diagram
10961 (H.2.1).
10963 The technique is typically applied in the testing phase of a system development. Handling of tables is
10964 complex by many conditions in the tables.
10965 References
10966 ** DIN: Information interchange; decision table, description medium – DIN 66241, 1979.
10967 Hurley, R. B.: Decision Tables in Software Engineering, Van Nostrand Reinhold Co., 1984. ISBN 978-
10968 0-442-23599-4
10969 Ghezzi, C., Jazayeri, M. and Mandrioli, D.: Fundamentals of Software Engineering, Prentice Hall,
10970 2003. ISBN 978-0-13-305699-0
10971
10972 H.2.5 Design Analysis (DA)
10973 Design Analysis commonly applies to software but also can be used to investigate systems of any
10974 kind. It aims to ensure that is thought to often neglect areas of the system during system development
10975 such as constraints, internal or external interactions, and the logic flow within the system. The
10976 following techniques describe three DAs.
10977
- 173 - prEN 50126-4
10978 H.2.5.1 Design Constraint Analysis
10979 Aim
10980 To evaluate restrictions imposed by requirements, the real world and environmental limitations, as
10981 well as by the design solution.
10982 Description
10983 The design materials (input) should describe all known or anticipated restrictions on a system
10984 component. These restrictions may include those listed below. Design Constraint Analysis gives
10985 constraints description of design documents (output) by evaluating the ability of the system to operate
10986 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 - Accommodations for changes of system behaviour over time: wear-in, hardware wear-out, end of
11000 life performance versus beginning of life performance degraded system behaviour and
11001 performance.
11002 Constraints of Application
11003 –
11004 References
11005 U.S. Department of Transportation, Federal Aviation Administration (ed.): System Safety Handbook,
11006 December 30, 2000: Clause H.5.4
11007
11008 H.2.5.2 Design Interface Analysis (DIA)
11009 Aim
11010 To verify the proper design of a software component's interfaces with other components of the
11011 system.
11012 Description
11013 Design Interface Analysis verifies that control and data linkages between interfacing components
11014 have been properly designed. Interface requirements specifications (input) are the sources against
prEN 50126-4 - 174 -
11015 which the interfaces are evaluated. Interface characteristics to be addressed should include data
11016 encoding, error checking and synchronization. The analysis should consider the validity and
11017 effectiveness of checksums and CRCs. The sophistication of error checking implemented should be
11018 appropriate for the predicted bit error rate of the interface. An overall system error rate should be
11019 defined, and budgeted to each interface.
11021 –
11022 References
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 Design Logic Analysis examines the safety-critical areas of a system component. A technique for
11031 identifying safety-critical areas is to examine each function performed by the system component. If it
11032 responds to, or has the potential to violate one of the safety requirements, it should be considered
11033 critical and undergo logic analysis. A technique for performing logic analysis is to analyse design
11034 descriptions (input) and logic flows and note discrepancies.
11035 The ultimate, fully rigorous DLA uses the application of Formal Methods (FM). Where FM is
11036 inappropriate, because of its high cost versus software of low cost or low criticality, simpler DLA can
11037 be used. Less formal DLA involves a human inspector reviewing a relatively small quantity of critical
11038 software artefacts (e. g. PDL, prototype code), and manually tracing the logic. Safety critical logic to
11039 be inspected can include failure detection/diagnosis; redundancy management, variable alarm limits,
11040 and command inhibit logical preconditions.
11042 Commercial automatic software source analysers can be used to augment this activity, but should not
11043 be relied upon absolutely since they may suffer from deficiencies and errors, a common concern of
11044 COTS tools and COTS in general.
11045 References
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 A Domain Specific Language is a programming, specification or modelling language created

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

11082 reconfigurable communication medium. In order to keep the system operational during a partial
11083 failure, it is necessary to redistribute the system functions to the remaining system resources (output).
11084 So, first, the failure has to be detected (input). Then the system must know the function of the failed
11085 sub-component (input) and find a possible replacement component. The replacement component
11086 must have the same communication connections as the failed one in order to undertake the task.
11088 Although traditionally applied to hardware, this technique is being developed for application also to
11089 software and, thus, the total system. It must be considered at the first system design stage.
11090 References
11091 Vaidyanathan, R. and Trahan, J. L.: Dynamic Reconfiguration – Architectures and Algorithms; Kluwer
11092 Academic, 2004. ISBN 0-306-48428-5
11093
11094 H.2.8 Error Avoiding Methods (EAM)
11095 Error Avoiding Methods are used to detect and remove or correct errors during the system
11096 development. In addition, techniques exist which are able to verify a test case testing EAMs. Three
11097 techniques are listed below.
11098
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 For an information of n bits, a coded block of k bits is generated which enables errors to be detected
11104 and corrected. There are included hamming, cyclic, and polynomial codes.
11105 The input to the technique is the error rate and output is the improvement of transmission quality of
11106 sensitive information.
11108 –
11109 References
11110 –
11111
11112 H.2.8.2 Error Guessing
11113 Aim
11114 To remove common development errors.
11115 Description
11116 Error Guessing uses the requirement specification or design documents (input) to revaluate system
11117 errors (output).
11118 Testing experience and intuition combined with knowledge and curiosity about the system under test
11119 may add some uncategorised test cases to the designed test case set. Special values or
11120 combinations of values may be error-prone. Some interesting test cases may be derived from
11121 inspection checklists. It may also be considered whether the system is robust enough. Can the
11122 buttons be pushed on the front-panel too fast or too often? What happens if two buttons are pushed
11123 simultaneously? This means, the experience of the tester is used to anticipate what defects might be
11124 present in the component or system under test.
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 Some known error types are inserted in the program (input), and the program is executed with the test
11135 cases (input) under test conditions. If only some of the seeded errors are found, the test case set is
- 177 - prEN 50126-4
11136 not adequate. The ratio of found seeded errors to the total number of seeded errors is an estimate of
11137 the ratio of found real errors to total number errors. This gives a possibility of estimating the number of
11138 remaining errors and thereby the remaining test effort.
11139 The detection of all the seeded errors may indicate either that the test case set is adequate, or that
11140 the seeded errors were too easy to find (output).
11142 The limitations of the method are that in order, to obtain any usable results, the error types as well as
11143 the seeding positions must reflect the statistical distribution of real errors.
11144 References
11145 –
11146
11147 H.2.9 Event Tree Analysis (ETA)
11148 Aim
11149 To model, in a diagrammatic form, the sequence of events that can develop in a system after an
11150 initiating event, and thereby indicate how serious consequences can be.
11151 Description
11152 Event Tree Analysis is based on a diagram where an initiating event is connected with all possible
11153 pivotal events that may arise out of the initiating event. Normally every event has one success (“yes”)
11154 branch and one failure (“no”) branch afflicted with probability of occurrence leading to another event.
11155 There can be also more branches coming out of an event. The connected events build up paths each
11156 leading in the final step of the ETA to an accident scenario.
11157 Assigning a probability of occurrence to the branches, allows multiplying these for each path and
11158 making a statement regarding the accident scenarios probability for the particular path (output). But
11159 therefore the design of the system and the accident histories on similar equipment must be known
11160 (input).
11162 A disadvantage of ETA is that they tend to get quite large, but they can be reduced by eliminating
11163 sequences. By ETA it is difficult to distinguish the essential events from those to which functional and
11164 operational relationships are illogical or meaningless.
11165 References
11166 Ericson, C. A.: Hazard Analysis Techniques for System Safety; John Wiley & Sons, 2005. ISBN 978-
11167 0-471-72019-5
11169 ISBN 978-0-201-11972-5
11170 ** IEC 62502; VDE 0050-3:2008-08: Verfahren zur Analyse der Zuverlässigkeit –
11171 Ereignisbaumanalyse; Beuth 2008.
11172
prEN 50126-4 - 178 -
11173 H.2.10 Fault Detection and Diagnosis
11174 Aim
11175 To detect faults in a system, which might lead to a failure, thus providing the basis for
11176 countermeasures in order to minimise the consequences of failures and to detect the causes that
11177 explain the detected faults.
11178 Description
11179 Fault detection is the process of checking a system (input) for erroneous states (which are caused by
11180 a fault within the (sub)system to be checked). The primary goal of fault detection is to inhibit the effect
11181 of wrong results. A system which delivers either correct results, or no results at all, is called "self-
11182 checking".
11183 Fault detection is based on the principles of redundancy (mainly to detect hardware faults – output)
11184 and diversity (software faults – output). Some sort of voting is needed to decide on the correctness of
11185 results. Special methods applicable are assertion programming, N-version programming and the
11186 safety bag technique and on hardware level by introducing sensors, control loops, error checking
11187 codes, etc.
11188 Fault detection may be achieved by checks in the value domain or in the time domain on different
11189 levels, especially on the physical (temperature, voltage etc.), logical (error detecting codes), functional
11190 (assertions) or external level (plausibility checks). The results of these checks may be stored and
11191 associated with the data affected to allow failure tracking.
11192 Complex systems are composed of subsystems. The efficiency of fault detection, diagnosis and fault
11193 compensation depends on the complexity of the interactions among the subsystems, which influences
11194 the propagation of faults.
11195 Fault diagnosis bases on the fault detection. After a fault (input) has been detected, the corresponding
11196 fault causes (output) are to be diagnosed. The effects of causes are the faults that are detected.
11198 –
11199 References
11200 Dependability of Critical Computer Systems Vol. 1; F. H. Redmill, Elsevier Applied Science, 1988.
11201 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 Having a system or a system description (input) the technique detects causes that lead to faults
11208 (output).
11209 There are various examples of specific methods: Half-Step Search, Sequential
11210 Removal/Replacement, Mass Replacement, and Lambda Search, and Point of Maximum Signal
11211 Concentration.
11213 –
- 179 - prEN 50126-4
11214 References
11215 Stephans, R. A. and Talso, W. W.: System Safety Analysis Handbook – A Source Book for Safety
11216 Practitioners. Unionville/Virginia, U.S.A.: System Safety Society, 2nd Edition, 1997.
11218 December 30, 2000: Chapter 9, Table 9-1
11219
11220 H.2.12 Formal Proof
11221 Formal methods employ techniques from mathematical logic and discrete mathematics for
11222 description, specification and construction of systems. Commonly based on mathematical logic,
11223 formal methods allow to write down the behaviour of the system under consideration and to express
11224 properties about the system. This requires addressing all assumptions explicitly and allows to raw all
11225 conclusions within the logic framework. The ability to prove certain properties of the system is central
11226 to any operation regarding formal methods. Examples for such proof tasks are to prove liveliness or
11227 safety properties or to show that the formal parameters of a procedure match with the actual given
11228 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 Higher Order Logic refers to a particular logic notation and its machine support system. The logic
11235 notation is mostly taken from Church's Simple Theory of types and the machine support system is
11236 based upon the LCF (Logic of Computable Functions) system. In HOL the standard predicate calculus
11237 is extended by allowing variables to range over functions. The arguments of functions can themselves
11238 be functions.
11239 Having a precise knowledge of the system (input) a formal specification of the system (output) can be
11240 expressed using HOL.
11242 –
11243 References
11244 Nesi M.: A Formalization of the Process Algebra CCS in High Order Logic. Technical Report, no. 278,
11245 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 The result of applying model checking to a system (input) and a desired property (input) is the answer
11252 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 - Modelling: The first task is to represent the system into a formalism (system model) accepted by
11255 a model checker;
11256 - Specification: Before verification, it is necessary to state the given property as a logic formula;
11257 - Verification: Checking whether the model satisfies the formula is completely automatic. In case of
11258 negative result, the user is provided with an error trace. This can be used as a counterexample
11259 for the checked property and can help the user in tracking down where the error occurred.
11260 Analysing the error trace may require the modification of the model and reapplication of the
11261 model checking algorithm.
11262 By model checking the desired property is common expressed in a Temporal Logic (H.2.12.3). The
11263 model of the system corresponds to a finite state machine (see State Chart Diagram in H.2.35.4).
11264 Compared to model checking, Theorem Proving (H.2.12.4) can be used for verifying infinite systems.
11266 Model checking is a verification technique. Its main disadvantage is the state explosion. This problem
11267 occurs by systems with many components that can interact with each other or systems that have data
11268 structures that can assume many different values. In such cases the number of global states can be
11269 enormous.
11270 References
11271 Baier, C. and Katoen, J.-P.: Principles of Model Checking, MIT Press, 2008.
11272 ISBN 978-0-262-02649-9
11273 Clarke, E. M., Grumberg, O. and Peled, D. A.: Model Checking, MIT Press, 1999.
11274 ISBN 978-0-262-03270-4
11275 * McMillan, K.: Symbolic Model Checking, Kluwer Academic Publishers, 1993.
11276 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 Comparing to propositional or predicate logic Temporal Logic contains temporal operators like next
11283 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 The idea of temporal logic is that a formula is not statically true or false in a model, as it is in
11286 propositional or predicate logic. Instead, temporal formulas are interpreted on sequences of states
11287 (behaviours) and a formula can be true in some states of the model and false in others.
11288 Temporal logic is used by model checking (H.2.12.2) to state the property to be proven as a logic
11289 formula.
11291 Typical application of temporal logic is the expression of properties proved by a verification method.
11292 Quantified time intervals and constraints are not handled explicitly in temporal logic. Absolute timing
11293 has to be handled by creating additional time states as part of the state definition.
11294 References
- 181 - prEN 50126-4
11295 Baier, C. and Katoen, J.-P.: Principles of Model Checking, MIT Press, 2008.
11296 ISBN 978-0-262-02649-9
11297 Clarke, E. M., Grumberg, O. and Peled, D. A.: Model Checking, MIT Press, 1999.
11298 ISBN 978-0-262-03270-4
11299 Huth, M. and Ryan, M.: Logic in Computer Science: Modelling and Reasoning about Systems,
11300 Cambridge University Press, 2004. ISBN 978-0-521-54310-1
11301 Kröger, F. and Merz, S.: Temporal Logic and State Systems, Springer, 2008.
11302 ISBN 978-3-540-67401-6
11303
11304 H.2.12.4 Theorem Proving
11305 Aim
11306 To verify system’s properties.
11307 Description
11308 A formal system consists of a formal language, statements of that language which are taken as given
11309 (axioms) and a set of inference rules or other means of deriving further statements (called theorems).
11310 A proof is a series of transformations according to the inference rules.
11311 Theorem Proving is applied to a system (input) and a property (input) to give the answer to the
11312 question whether the property is satisfied in the system or not (output). To do that, a formal system of
11313 the considered system and representation of a property as a formula are to be provided. Then, the
11314 theorem prover attempts to find a proof by repeatedly applying the inference rules.
11315 Typical Application and Constraints
11316 Typical application of theorem proving is system’s verification. In contrast to model checking, theorem
11317 proving can be applied to infinite systems. On the other hand, in a case of a negative result, the user
11318 is not provided with a counterexample, that can help in tracking down where the error occurred. The
11319 complex theoretical background of theorem proving, demands a high expertise level of the user.
11320 Another disadvantage of the method is that in contrast to fully automated process of model checking,
11321 an interaction between the user and the theorem prover is required.
11322 References
st
11323 Ait Mohamed, O., Munoz, C. and Tahar, S.: Theorem Proving in Higher Order Logic: 21 International
11324 Conference, Springer, 2008. ISBN 978-3-540-71065-3
11325 Schumann, J. M.: Automated Theorem Proving in Software Engineering, Springer, 2001. ISBN 978-3-
11326 540-67989-9
11327 Nipkow, T., Wenzel, M. and Paulson, L. C.: Isabelle/HOL: A Proof Assistant for Higher-Order Logic,
11328 Springer, 2002. ISBN 978-3-540-43376-7
11329 Bertot, Y. and Castéran, P.: Interactive Theorem Proving and Program Development: Coq’Art: The
11330 Calculus of Inductive Constructions, Springer, 2004. ISBN 978-3-540-20854-9
11331
11332 H.2.13 Graceful Degradation (GD)
11333 Aim
11334 To maintain the more critical functions during a partial failure of the system by dropping the less
11335 critical functions.
prEN 50126-4 - 182 -
11336 Description
11337 The effect of the Graceful Degradation is similar to the effects caused by redundancy systems, but
11338 without needing replications. This is achieved by removing the system part damaged by the error
11339 (input) and allowing the unaffected part to continue execution. The execution is possible as long as no
11340 basic function is interrupted. That means that the system structure had to be constructed in a way
11341 which allows redistribution of encumbrances within the system.
11343 GD is implemented in a variety of domains of image processing and telecommunications to shared

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

11378 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 EMC analysis can be used throughout the planning, design, and construction phases of an electrical
11383 system to ensure that the original EMC design (input) is being implemented correctly.
11385 The technique can be applied in a system where adverse electromagnetic environmental effects can
11386 occur.
11387 References
11388 Paul, C. R.: Introduction to Electromagnetic Compatibility, John Wiley & Sons, 2006.
11389 ISBN 978-0-471-75500-5
11392 Tesche, F. M., Ianoz, M. V. and Karlsson, T.: EMC Analysis Methods and Computational Models,
11393 John Wiley & Sons, 1997. ISBN 978-0-471-15573-7
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 Energy trace and barrier analysis is based on the theory that when hazardous energy sources exist
11402 within a system they pose a hazardous threat to certain targets. Placing barriers between the energy
11403 source and the target can mitigate the threat to targets. ETBA process begins with the identification of
11404 energy sources (input) within the design. As a result energy source hazards and required safety
11405 barriers are determined (output).
11406 Some hazards identified through this technique may require more detailed analysis by other
11407 techniques, e. g. FTA (H.2.30.7).
11409 ETBA is to be applied to identify the system hazards associated with energy sources. The technique
11410 is limited by the ability of the analysis to identify all hazardous energy sources.
prEN 50126-4 - 184 -
11411 References
11413 0-471-72019-5
11417 2000.
11418
11419 H.2.14.4 Materials Compatibility Analysis
11420 Aim
11421 To analyse materials utilized within a design.
11422 Description
11423 Materials Compatibility Analysis provides an assessment (output) of materials (input) utilized within a
11424 particular design. All materials shall be compatible with those with which they can come into contact.
11425 Any potential degradation that can occur due to material incompatibility is evaluated.
11427 –
11428 References
11432 2000.
11433
11434 H.2.15 Impact Analysis / Change Analysis
11435 Aim
11436 To identify the effect that a change or an enhancement of a system can have to other modules in that
11437 system.
11438 Description
11439 Prior to a modification or enhancement being performed on the system an analysis shall be
11440 undertaken to identify the impact of the modification or enhancement on the system and to also
11441 identify the affected system components.
11442 After the analysis has been completed a decision is required concerning the re-verification of the
11443 system (input). This depends on the number of modules affected, the criticality of the affected
11444 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
11449 –
11450 References
11454 2000.
11455
11456 H.2.16 Inspections
11457 An inspection, which is a preventive maintenance, is an evaluation technique in which systems are
11458 examined by a person or a group other than the system creator to detect faults, violations of
11459 development standards, and other problems. An inspection should be performed in each product
11460 phase. Only in this way, system failures are detected early. Two useful inspection techniques are
11461 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 A Fagan Inspection is very similar to a “normal” inspection or a Walkthrough / Design Review (WDR).
11468 The difference between a WDR and a FI is that measures are carried out with a checklist during FIs.
11469 The basis of a FI is a number of checkpoints defined during system development for the following
11470 points: the system itself, the test plans, the publication material, and so on. Throughout the FI an
11471 independent moderator leads through four phases:
11472 1) Each responsible person of the development team provides an overview of his work and distribute
11473 relevant information to other FI-team members;
11474 2) Each team member identifies those areas of the system that have led to errors in previous similar
11475 systems or where he believes they are particularly error prone;
11476 3) A nominated reader walks detailed through the system in front of the team. Every possibility shall
11477 be scrutinized. If an error is detected, it is recorded by the leader and provided with a severity
11478 ranking;
11479 4) Finally, the moderator produces an inspection report, which is given back to the responsible
11480 developer to resolve all problems reported.
11481 The input of a FI is a detailed documentation of the development process which includes a detailed
11482 description of the system including the system behaviours, functions, and so on. Output of a FI is a
11483 To-Do-list created by experts with problems to be solved.
11485 The FI can only be as good as the team that carries them out. Especially, it is difficult to understand
11486 the system, if the responsible developer could not explain detailed enough.
prEN 50126-4 - 186 -
11487 References
11488 Clapp, J. A., Cerino, D. A. and Peng, W. W.: Software Quality Control, Error Analysis, and Testing;
11489 Noyes Data Corporation, 1995. ISBN 0-8155-1363-1
11490 Bell, D.: Software Engineering for Students: A Programming Approach; Pearson Education Limited,
11491 2005. ISBN 978-0-321-26127-4
11492 Birrell, N. D. and Ould, M. A.: A Practical Handbook for Software Development; Cambridge University
11493 Press, 1985. ISBN 978-0-521-25462-5
11494
11495 H.2.16.2 Walkthrough / Design Review (WDR)
11496 Aim
11497 To detect errors in some product of the development process as soon and as economically as
11498 possible.
11499 Description
11500 During a Walkthrough or Design Review the developer of the studied system explains the functions
11501 and the design of the system some other experts, if possible independent of the system (input). To
11502 reveal system errors, the independent person asks questions critically. There is also the possibility to
11503 nominate an expert to be a user trying the system or to let costumers test the system. All problems
11504 are documented (output) and must subsequently be resolved by the developer.
11506 WDR shall be conducted for all new products/processes, new applications, and revisions to existing
11507 products and manufacturing processes which affect the function, performance, safety, reliability,
11508 ability to inspect maintainability, availability, ability to cost, and other characteristics affecting the end
11509 product/process, users or bystanders.
11510 References
11511 Frühauf, K., Ludewig, J. and Sandmayr, H.: Software-Prüfung: Eine Anleitung zum Test und zur
11512 Inspektion; vdf. ISBN 978-3-7281-3059-4
11513 Bell, D.: Software Engineering for Students: A Programming Approach; Pearson Education Limited,
11514 2005. ISBN 978-0-321-26127-4
11515 Birrell, N. D. and Ould, M. A.: A Practical Handbook for Software Development; Cambridge University
11516 Press, 1985. ISBN 978-0-521-25462-5
11517
11518 H.2.17 Interface Methods
11519 Interface Methods test and analyse interfaces within a system because system failures can occur
11520 since the interfaces of subsystems are incompatible to each other or information getting stuck in a
11521 subsystem caused in unsuitable interfaces. The two techniques below are useful to preserve a
11522 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 The methodology entails seeking those physical and functional incompatibilities between adjacent,
11529 interconnected, or interacting elements of a system which, if allowed to persist under all conditions of
11530 operation, would generate risks.
11532 –
11533 References
11538
11539 H.2.17.2 Interface Testing
11540 Aim
11541 To demonstrate that interfaces of subsystems do not contain any errors or any errors that lead to
11542 failures in a particular application of the system or to detect all errors that may be relevant.
11543 Description
11544 These kind of tests are particularly important if the system interfaces (input) do not contain assertions
11545 that detect incorrect parameter values. They are also important after new configurations of pre-
11546 existing subsystems have been generated.
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 Similar to a Time Petri Nets (H.2.32) a Markov Models consist of circles, called places, each
11557 describing a global system state. These are connected due to arrows with other system states
11558 representing the state transitions. An arrow is based on the component failure or repair rate which
11559 means the frequency of occurrence of failure or repair over time. One place can comprise many
11560 components which can be depicted due to a Reliability Block Diagram (H.2.30.11) applied to the
11561 whole system. In this case there must be as much out-coming failure arrows as there are components
11562 included in the respective place.
11563 Utilizing Markov state equations the probability of the occurrence of a special state can be calculated
11564 (output).
prEN 50126-4 - 188 -
11565 To construct a Markov model a good knowledge of the system, the failure, and repair rate of the
11566 components is required (input).
11568 Markov models quickly become complex; thus it is limited to small systems or a high-level system
11569 abstraction. Moreover it does not identify hazards; just evaluates identified hazards in more detail.
11570 References
11572 0-471-72019-5
11573 Andrews, J. D. and Ericson, C. A.: Fault Tree and Markov Analysis Applied to Various Design
11574 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 To predict the attributes of programs from properties of the software itself rather than from its
11580 development or test history.
11581 Description
11582 Metrics are techniques used to evaluate some structural properties of software (input) and relate
11583 these to a desired attribute (output) such as complexity. Software tools are required to evaluate most
11584 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 An example of the metrics is cyclomatic complexity – the number of linearly independent paths that
11590 comprise the program. As such it can be used to indicate the effort required to test a program (see
11591 Testing, H.2.31). To determine the paths, the program procedure is represented as a strongly
11592 connected graph.
11594 Metrics are applied to measure system quality and to improve system development process. The user
11595 should carefully choose metrics and be aware, that too much emphasis on any one of the aspects of
11596 performance can lead to a dysfunctional project.
11597 References
11598 Fenton, N. E. and Pfleeger, S. L.: Software Metrics: A Rigorous and Practical Approach, Course
11599 Technology, 1997. ISBN 978-0-534-95425-3
11600 Kan, S. H.: Metrics and Models in Software Quality Engineering, Addison-Wesley, 2003.
11601 ISBN 978-0-201-72915-3
11602 Oman, P. and Pfleeger, S. L.: Applying Software Metrics, Wiley-IEEE Computer Society Press, 1997.
11603 ISBN 978-0-8186-7645-1
- 189 - prEN 50126-4
11604 ** ISO/IEC 9126: Software engineering – Product quality
11605
11606 H.2.20 Modular Approach
11607 Aim
11608 To separate concerns by dealing with smaller parts of a system in isolation, while allowing for
11609 the integration of these parts into a coherent system
11610 Description
11611 By applying Modular Approach (modularization), a complex system (input) is divided into simpler
11612 pieces called modules. A system that is composed of modules is called modular system (output). The
11613 main benefit of modularity is that it allows the principle of separation of concerns to be applied in two
11614 phases: when dealing with the details of each module in isolation (and ignoring details of other
11615 modules) and when dealing with the overall characteristics of all modules and their relationships in
11616 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 - Connections between modules shall be limited strictly defined, coherence in one module shall be
11620 strong.
11621 Modularity is an important property of most engineering processes and products. There are three
11622 goals that modularity tries to achieve in practice: capability of decomposing a complex system, of
11623 composing it from existing system, and of understanding the system in pieces.
11625 –
11626 References
11627 Ghezzi, C., Jazayeri, M. and Mandrioli, D.: Fundamentals of Software Engineering, Prentice Hall,
11628 2003. ISBN 978-0-13-305699-0
11629 Yourdon, E. and Constantine, L. L.: Structured Design: Fundamentals of a Discipline of Computer
11630 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 The principle behind Monte-Carlo Simulation is to evaluate a model iteratively by injecting sets of
11637 random numbers (input) to simulate noise on a signal or to add random biases or tolerances. This is
11638 to create an artificial world, or pseudo-population, which resembles the real world in all relevant
11639 respects. This pseudo-population consists of mathematical procedures for generating sets of numbers
11640 that resemble samples of data drawn from the true population. This pseudo-population is used to
11641 conduct multiple trials of the statistical procedures of interest to investigate how that procedure
11642 behaves across samples (output) statistically.
11643 Monte-Carlo simulation can be used in almost every phase of application to solve problems, which
11644 can be classified as followed.
prEN 50126-4 - 190 -
11645 - Probabilistic problems, where random numbers are used to generate a real world stochastic
11646 phenomenon; and
11647 - Deterministic problems, which are mathematically translated into an equivalent probabilistic
11648 problem.
11649 Because MCS is based on an iterative process, the following techniques utilising cyclic graphs can be
11650 applied gainfully: Markov-Models (H.2.18), Time Petri Nets (H.2.32).
11652 MCS is often used to evaluate a model when it is complex, nonlinear, or involves more than just a
11653 couple of uncertain values.
11654 When using Monte-Carlo simulations care must be taken to ensure that the biases, tolerances or
11655 noise are reasonable values.
11656 References
11657 Mooney, C. Z.: Monte Carlo Simulation, SAGE, 1997. ISBN 978-0-8039-5943-9
11658 Andrews, J. D. and Moss, T. R.: Reliability and Risk Assessment, Professional Engineering
11659 Publishing, 2002. ISBN 978-1-860-58290-5
11660 Rubinstein, R. Y. and Kroese, D. P.: Simulation and the Monte Carlo Method, Wiley-Interscience,
11661 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 The Operational Readiness Review is held after successful completion of all product testing,
11668 acceptance testing, and just prior to the system (input) becoming operational.
11670 –
11671 References
11674
11675 H.2.23 Performance Engineering
11676 Performance engineering includes a set of techniques applied in every phase of system development
11677 which ensures that a system will be designed and implemented to meet the performance
11678 requirements specification. The following two techniques belong to performance engineering.
11679
- 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 The requirements specification (input) includes throughput and response requirements for specific
11685 functions, perhaps combined with constraints on the use of total system resources. The proposed
11686 system design (output) is compared against the stated requirements by
11687 - Defining a model of the system processes, and their interactions;
11688 - Identifying the use of resources by each process, for example, processor time, communications
11689 bandwidth, storage devices etc.;
11690 - Identifying the distribution of demands placed upon the system under average and worst-case
11691 conditions;
11692 - Computing the average and worst-case throughput and response times for the individual system
11693 functions.
11694 For simple systems, an analytic solution may be possible whilst for more complex systems; some
11695 form of simulation is required to obtain accurate results.
11696 Before detailed modelling, a simpler 'resource budget' check can be used which sums the resources
11697 requirements of all the processes. If the requirements exceed designed system capacity, the design is
11698 infeasible. Even if the design passes this check, performance modelling may show that excessive
11699 delays and response times occur due to resource wasting. To avoid this situation engineers often
11700 design systems to use some fraction of the total resources so that the probability of resource wasting
11701 is reduced.
11702 Some of the Performances Modelling techniques are Markov Models (H.2.18), Monte-Carlo
11703 Simulation (H.2.21), Petri Nets (H.2.32) and UML diagrams (H.2.35).
11705 This technique is typically applied by modelling tasks.
11706 References
11707 Hillston, J.: A Compositional Approach to Performance Modelling, Cambridge University Press, 2005.
11708 ISBN 978-0-521-67353-2
11709 Dumke, R., Rautenstrauch, C., Schmietendorf, A. and Scholz, A.: Performance Engineering: State of
11710 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 An analysis is performed of both the system and the software requirements specifications (input) to
11717 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 The practicability of each performance requirement is analysed in order to obtain a list of performance
11725 requirements, success criteria and potential measurements. The main objectives are:
11726 - Each performance requirement is associated with at least one measurement;
11727 - Where possible, accurate and efficient measurements are selected which can be used as early in
11728 the development process as possible;
11729 - Essential and optional performance requirements and success criteria are identified; and
11730 - Where possible, advantage shall be taken of the possibility of using a single measurement for
11731 more than one performance requirement.
11733 This technique is typically applied by requirements specification.
11734 References
11735 Kan, S. H.: Metrics and Models in Software Quality Engineering, Addison-Wesley, 2003.
11736 ISBN 978-0-201-72915-3
11737 Leffingwell, D. and Widrig, D. : Managing Software Requirements: A Use Case Approach, Addison-
11738 Wesley, 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 To test the function of a system, together with its interfaces to the outside world, without allowing it to
11744 modify the real world in any way.
11745 Description
11746 Simulation is used for testing purposes only to create a system (output), which mimics the behaviour
11747 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 - Respond to outputs from the system in a way which faithfully represents the controlled
11751 equipment; and
11752 - Have provision for operator inputs to provide any perturbations with which the system under test
11753 is required to cope.
11754 When software is being tested the simulation may be a simulation of the target hardware with its
11755 inputs and outputs.
- 193 - prEN 50126-4
11756 One simulation technique described in this standard is Monte-Carlo Simulation (H.2.21)
11758 Process simulation is a planning and analysis technique, not a scheduling technique. It is primarily
11759 used for measuring process efficiency and not effectiveness or adaptability.
11760 References
11761 Harrington, H. J. and Tumay, K.: Simulation Modeling Methods, McGraw-Hill Professional, 2000.
11762 ISBN 978-0-07-027136-4
11763 Shull, F., Singer, J. and Sjøberg, D. I. K.: Guide to Advanced Empirical Software Engineering,
11764 Springer, 2007. ISBN 978-1-84800-043-8
11765 Zeigler, B. P., Praehofer, H. and Kim, T. G.: Theory of Modeling and Simulation: Integrating Discrete
11766 Event and Continuous Complex Dynamic Systems, Academic Press, 2000.
11767 ISBN 978-0-12-778455-7
11768
11769 H.2.25 Prototyping / Animation
11770 Aim
11771 To check the feasibility of implementing the system against the given constraints and to communicate
11772 the specifier's interpretation of the system to the customer, in order to locate misunderstandings.
11773 Description
11774 A sub-set of system functions, constraints, and performance requirements (input) are selected. A
11775 prototype (output) is built using high level tools. At this stage, constraints such as the target computer,
11776 implementation language, program size, maintainability, reliability and availability need not be
11777 considered. The prototype is evaluated against the customer's criteria and the system requirements
11778 may be modified in the light of this evaluation.
11780 –
11781 References
11782 Gordon, V. S. and Bieman, J. M., Rapid Prototyping: Lessons Learned, IEEE Software, 12(1):85-94,
11783 1994.
11784 Verner, J. M. and Cerpa, N.: Prototyping: Does your view of its advantages depend on your job?
11785 Journal of Systems and Software, 36(1):3-16, 1997.
11786 Rudd. J. and Isensee, S: Twenty-two tips for a happier, healthier prototype, ACM Interactions, 1(1),
11787 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 Several different program sections are written, often independently, each of which is intended to
11794 perform the same desired function. The final program is constructed from these sections. The first
prEN 50126-4 - 194 -
11795 section, called the primary, is executed first. This is followed by an acceptance test of the result it
11796 calculates. If the test is passed then the result is accepted and passed on to subsequent parts of the
11797 system. If it fails, any side effects of the first are reset and the second section, called the first
11798 alternative, is executed. This too is followed by an acceptance test and is treated as in the first case.
11799 A second, third or even more alternatives can be provided if desired.
11800 The difference to “Retry Fault Recovery Mechanisms” and “Safety Bag” is that a Recovery Block
11801 operates with several (maybe different) implementations of a function.
11802 Using this technique a design specification (output) can be gained on the basis of requirements
11803 specification (input).
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 The requirements specification for the system (input) and the software includes memory and
11814 response requirements for specific functions, perhaps combined with constraints on the use of total
11815 system resources. An analysis is performed which will identify the distribution demands under
11816 average and worst case conditions (output). This analysis requires estimates of the resource usage
11817 and elapsed time of each system function. These estimates can be obtained in several ways, for
11818 example, comparison with an existing system or the prototyping and bench-marking of time critical
11819 systems.
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 In the event of a detected fault or error condition (input), attempts are made to recover the situation by
11830 re-executing the same code. Recovery by retry can be as complete as a re-boot and a re-start
11831 procedure or a small re-scheduling and re-starting task, after a software time-out or a task watchdog
11832 action. Retry techniques are commonly used in communication fault or error recovery and retry
11833 conditions could be flagged from a communication protocol error (check sum etc.) or from a
11834 communication acknowledgement response time-out.
- 195 - prEN 50126-4
11836 –
11837 References
11838 –
11839
11840 H.2.29 Safety Bag (SB)
11841 Aim
11842 To protect against residual specification and implementation faults in systems which adversely affect
11843 safety.
11844 Description
11845 A Safety Bag is an external monitor, implemented on an independent computer to a different

11846 specification. This safety bag is solely concerned with ensuring the main computer performs safe, not
11847 necessarily correct, actions. The SB continuously monitors the main computer. The SB prevents the
11848 system from entering an unsafe state. In addition if it detects that the main computer is entering a
11849 potentially hazardous state, the system has to be brought back to a safe state either by the SB or the
11850 main computer.
11851 By applying SB a safety of a system in focus and in addition an independent system (input) can be
11852 improved by early fault detection and recovery strategies (output).
11854 -
11855 References
11856 –
11857
11858 H.2.30 System Safety Analysis (SSA)
11859 System Safety Analysis (including hazard analysis) are performed to identify hazards, hazard effects
11860 and hazard causal factors. They are used to determine system risk and thereby ascertain the
11861 significance of hazards so that safety design measures can be established to eliminate or mitigate the
11862 hazard.
11863 Nowadays there are many different safety analysis techniques in use. One of the greatest problems in
11864 performing such analysis may be in selecting an appropriate technique that match the project’s goal.
11865 Because the techniques have different coverage and validity, several may be required during the
11866 safety life cycle of a system. No one method is superior to all others for every objective or even
11867 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 To identify potential failures in redundant systems or redundant subsystems which would undermine
11873 the benefits of redundancy because of the appearance of the same failures in the redundant parts at
11874 the same time.
prEN 50126-4 - 196 -
11875 Description
11876 The system redundancy prevents system failures in case that at least one of the redundant systems is
11877 still running. But system failures may have common causes. To identify these causes the common
11878 cause failure analysis is used. Redundant systems are either independent or dependent to each
11879 other. There can be different reasons for CCFs, such as using the same hardware (e. g. transistors
11880 fabricated in the same factory), using same resources (e. g. power supply) or installing the systems in
11881 the same building (CCFs originated by effects of heat or vibration).
11882 The basis for a structured approach to CCFA mostly is the development of a fault tree. After adding
11883 the CCF events, the fault tree is recomputed to revaluate the criticality, sensitivity, and probability of
11884 CCFs. The next step involves the review of system design and operating historical experience to
11885 identify CCF vulnerabilities. These results are utilized to develop a fault tree simply using CCF events,
11886 which includes the risk of every single system.
11887 Thus, the fault tree constitutes the basis for a CCFA it is a need to know the system design (input).
11888 Hence the technique only identifies system hazards associated with CCF (output).
11890 The CCFA requires a high level of expertise and practice analysing the CCF events in a system.
11891 References
11893 0-471-72019-5
11894 Fussell, H. B. and Burdick, G. R.: Nuclear Systems Reliability Engineering and Risk Assessment;
11895 Society for Industrial & Applied Mathematics 1977. ISBN 0-898-71041-3
11896
11897 H.2.30.2 Contingency Analysis (CA)
11898 Aim
11899 To minimize risk in the event of an emergency.
11900 Description
11901 With Contingency Analysis potential accidents (input) are identified and the adequacies of emergency
11902 measures (output) are evaluated.
11904 CA could be conducted for any system, procedure, task or operation where there is the potential for
11905 harm.
11906 References
11910 2000.
11911
- 197 - prEN 50126-4
11912 H.2.30.3 Critical Incident Technique
11913 Aim
11914 To collect direct observations of human behaviour that have critical significance and meet
11915 methodically defined criteria.
11916 Description
11917 This is a qualitative interview method of investigation significant occurrences (errors and unsafe
11918 conditions of the system – input) that contribute to both potential and actual accidents or incidents
11919 within a given population. The objective is to gain understanding (output) of the incident from the
11920 perspective of the individual, taking into account cognitive, affective, and behavioural elements.
11922 –
11923 References
11928 Gremler D. D.: The Critical Incident Technique in Service Research. In: Journal of Service Research,
11929 August 2004.
11930
11931 H.2.30.4 Criticality Analysis
11932 Aim
11933 To rank each failure mode identified in a Failure Modes and Effect Analysis (FMEA, see H.2.30.5).
11934 The FMEA then gets the Failure Mode, Effects and Criticality Analysis (FMECA, see H.2.30.5).
11935 Description
11936 The Criticality Analysis is used to chart the probability of failure modes against the severity of their
11937 consequences. The result highlights failure modes with relatively high probability and severity of
11938 consequences, allowing remedial effort to be directed where it will produce the greatest value.
11939 The analysis team must:
11940 - Define the reliability/unreliability for each item and use it to estimate the expected number of
11941 failures at a given operating time;
11942 - Identify the portion of the item’s 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 - Calculate the criticality for each item by obtaining the sum of the criticalities for each failure mode
11946 that has been identified for the item.
11948 –
prEN 50126-4 - 198 -
11949 References
11954
11955 H.2.30.5 Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and
11956 Criticality Analysis (FMECA)
11957 Aim
11958 To evaluate the effects of potential failure modes and establish the overall probability that the system
11959 will operate without failure for a specific length of time or, alternatively, that the product will operate a
11960 certain length of time between failures.
11961 Description
11962 The FMEA is a qualitative analysis method that can be extended by a criticality analysis which can
11963 also deliver quality results (FMECA). To perform FMEA the following things have to be known and
11964 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 - Investigate the failure rate and failure effects, severity of a failure effect, as well as detection rate
11971 of each subsystem (input);
11972 - Calculate the risk priority number (RPN) by multiplying the probability of occurrence with the
11973 severity ranking and the detection ranking;
11974 - Find measures against the cause of failure.
11975 Similar to the HAZOP the FME(C)A is performed by a team of engineers and a trained specialist in
11976 hazard analysis (team leader). During several meetings the leader asks questions and the team
11977 answers. For this the system is split in its subsystems which are split in their items. The FME(C)A
11978 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).
11984 A disadvantage is that the FME(C)A only considers single failures, but no failure combination. The
11985 technique is mostly applicable to systems for which, component failure modes are well known.
- 199 - prEN 50126-4
11986 References
11988 0-471-72019-5
11990 ISBN 978-0-201-11972-5
11991 ** IEC 60812; Analysis techniques for system reliability – Procedure for failure mode and effects
11992 analysis (FMEA); Beuth 2006.
11993
11994 H.2.30.6 Fault Hazard Analysis
11995 Aim
11996 To identify what can fail and how and how frequent it can fail. In addition, the effects of failures are
11997 examined.
11998 Description
11999 The Fault Hazard Analysis is a deductive method of analysis of a system (input) that can be used
12000 exclusively as a qualitative analysis or, if desired, expanded to a quantitative one. The fault hazard
12001 analysis requires a detailed investigation of the subsystems to determine component hazard modes,
12002 causes of these hazards, and resultant effects to the subsystem and its operation (output). This type
12003 of analysis is a form of a family of reliability analyses called Failure Modes and Effect Analysis
12004 (FMEA, see H.2.30.5) and Failure Mode, Effects and Criticality Analysis (FMECA, see H.2.30.5).
12006 –
12007 References
12010 U.S. Department of Transportation, Federal Aviation Administration (ed.):

12011 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 To identify all events (failure modes, human error, and normal conditions), and its logical relations,
12017 that can lead to the occurrence of a specified undesired event.
12018 Description
12019 Fault trees (FT) are graphical models using logical gates (e. g. AND, OR) and fault events to model
12020 the cause-effect relationships (input) involved in causing the undesired event. Thus FTA is deductive
12021 in that it transverses from the general problem to the specific causes.
12022 The completed FT structure can be translated into a mathematical model to determine the
12023 significance of fault events (output) and their probability of occurrence (output) by the application of
12024 certain rules of Boolean algebra and probability theory.
prEN 50126-4 - 200 -
12025 In general FTA can be applied during any life cycle phase of a system – from concept to usage.
12026 Nevertheless to be most effective, FTA requires a completed system design and a thorough
12027 understanding of the system and its behaviour in all operating modes.
12028 To identify the undesired top events to be considered often a failure mode and effects analysis
12029 (FMEA) (H.2.30.5) is practised. Moreover to simplify the FTA process functional block diagrams can
12030 be utilized.
12032 There are two basically applications of FTA. The most commonly used application is the proactive
12033 FTA, performed during system development to influence design by predicting and preventing future
12034 problems. The other application is the reactive FTA, performed after an accident or mishap has
12035 occurred.
12036 FTA is a method for analysing causes of hazards, not for identifying hazards. The top event in the tree
12037 must have been foreseen and thus identified by other techniques (e. g. FMEA). Moreover modelling of
12038 temporal behaviour with FTA is more difficult than with other means of description (e. g. Markov
12039 modelling (H.2.18)).
12040 References
12042 0-471-72019-5
12043 Fault Tree Handbook. W. E. Vesely et al, NUREG-0492, Division of System Safety Office of Nuclear
12044 Reactor Regulation, US Nuclear Regulatory Commission Washington, 1981.
12045 ** IEC 61025:1990, Fault tree analysis (FTA).
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 The analysis is carried out by a team of engineers (covering computer, instrument, electrical, process,
12054 safety and operational disciplines) led by a trained specialist in hazard analysis techniques in a series
12055 of scheduled meetings. During the analysis the leader asks leading questions based on the
12056 considered system and the engineers answer them as detailed as possible using guided words. The
12057 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 Using the collected data Fault Trees (H.2.30.7) can be created to support the purely written
12066 documentation.
12067 Through this type of analysis not only information about errors (which already have occurred) and
12068 risks can be gained, but also potential scenarios and possible alternatives (output) can be
12069 constructed.
12071 Although HAZOP is a very organized, structured and methodical analysis, it is only focused on single
12072 events rather than on combinations of possible events.
12073 References
12075 0-471-72019-5
12076 ** IEC 61882:2002 Hazard and operability studies (HAZOP studies) - Application guide.
12077
12078 H.2.30.9 Operating and Support Hazard Analysis (O&SHA)
12079 Aim
12080 To evaluate the effectiveness of procedures in controlling those hazards which were identified as
12081 being controlled by procedures, instead of by design, and to ensure that procedures do not introduce
12082 new hazards.
12083 Description
12084 The Operating and Support Hazard Analysis identifies hazards/risks occurring during use of the
12085 system (input). It encompasses operating the system (primarily procedural aspects) and the support
12086 functions (e. g., maintenance, servicing, overhaul, facilities, equipment, and training) that go along
12087 with operating the system.
12088 The sooner the analysis begins the better. Even before the system is designed, an O&SHA can be
12089 started to identify hazards (output) with the anticipated operation of the system. Ideally, the O&SHA
12090 should begin with the formulation of the system and not be completed until sometime after initial test
12091 of the system (which may identify additional hazards). This is critical because design and construction
12092 of support facilities must begin far before the system is ready for fielding, and all special safety
12093 features (e. g., fire suppression systems) must be identified early or the costs to modify the facilities
12094 may force program managers and users to accept unnecessary risks.
12096 –
12097 References
12102 Ericson, C. F.: Hazard Analysis Techniques for System Safety, Wiley, 2005.
12103
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 The Preliminary Hazard Analysis method – also referred to as Gross Hazard Analysis or Potential
12109 Hazard Analysis – is a safety analysis method, using tabular worksheets for identifying hazards, their
12110 associated causal factors, effects, level of risk, and safety recommendations for mitigating risk
12111 (output) when only preliminary or baseline design concepts (input) are available.
12112 The PHA is generally applicable to analyse all types of systems, facilities, operations and functions. It
12113 can be performed on a particular unit, a subsystem, a system or an integrated set of systems.
12114 To simplify the PHA process and for the sake of maximum accessible completeness of the identified
12115 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.
12119 Generally the PHA is, as its name implies, generated early in the system design development phase
12120 in order to influence the design when the cost impact is minimal. Therefore PHA is often used as a
12121 starting point for further hazard analysis (e. g. Fault Tree Analysis, H.2.30.7) and safety tasks.
12122 Because PHA starts at the concept formation stage of a project, little detail is available, and
12123 assessments of hazard and risk levels are necessarily only qualitative and limited. While there are no
12124 other real constraints/disadvantages in the PHA method, it is sometimes improperly used, even if
12125 other techniques can be utilized more gainful to analyse and upgrade systems’ safety properties.
12126 References
12128 0-471-72019-5
12130 ISBN 978-0-201-11972-5
12131 Stephans, R. A., Talso, W. W. and System Safety Society (U.S.).: System Safety Analysis Handbook,
12132 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 A Reliability Block Diagram is a graph showing the signal flow through a system represented as
12139 rectangles by combining the components of the system in the correct sequence. There are three
12140 basic types of arrangement in which each system structure can be described: series, parallel, or
12141 regeneration structure. From this structure (input), the reliability for the entire system (output) can be
12142 determined using simple rules of calculation, if the failure probabilities of the components (input) are
12143 known.
- 203 - prEN 50126-4
12145 –
12146 References
12147 Kuo, W. and Zuo, M. H.: Optimal Reliability Modeling; John Wiley & Sons, 2003.
12148 ISBN 978-0-471-39761-8
12149 Roush, M. and Webb, W.: Applied Reliability Engineering – Volume I; University of Maryland, 2006.
12150 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).
12159 –
12160 References
12163
12164 H.2.30.13 Root Cause Analysis (RCA)
12165 Aim
12166 To investigate what, how, and why something happened and to figure out how to prevent the same
12167 thing from happening again.
12168 Description
12169 Root Cause Analysis is a collective term used to describe a wide range of techniques to uncover
12170 causes of problems. This type of techniques is used to identify causal factors (output) to accidents or
12171 near-miss incidents. Therefore it goes beyond the directly related causes to identify fundamental
12172 reasons, so called root causes, for faults or failures (input).
12173 Following excerpted techniques can be used to identify root causes: Ishikawa diagram (fishbone
12174 diagram), Barrier Analysis or Failure Mode and Effects Analysis (H.2.30.5).
12176 Primarily RCA have been utilised to detect root causes after an undesired event has occurred
12177 (reactive RCA). Nowadays the different techniques are sometimes also used to forecast the possibility
12178 of an event even before it could occur (proactive RCA). If so, the proactive RCA should be generated
12179 early in the design phase in order to influence the design when the cost impact is minimal.
prEN 50126-4 - 204 -
12180 References
12181 Andersen, B. and Fagerhaug, T.: Root Cause Analysis: Simplified Tools and Techniques. Milwaukee,
12182 Wis: ASQ Quality Press, 2006. ISBN 978-0-87389-692-4
12183 Latino, R. J. and Latino, K. C.: Root Cause Analysis: Improving Performance for Bottom-Line Results.
12184 CRC Press, 2006. ISBN 978-0-8493-5340-6
12185 Robitaille, D.: Root Cause Analysis: Basic Tools and Techniques. Paton Professional, 2004.
12186 ISBN 978-1-932828-02-3
12187 Stephans, R. A., Talso, W. W. and System Safety Society (U.S.).: System Safety Analysis Handbook,
12188 New Mexico Chapter, System Safety Society, 1993.
12189
12190 H.2.30.14 Single Point Failure Analysis
12191 Aim
12192 To identify single points of failure. A single point of failure is a part of a system which, if it fails, will
12193 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).
12197 –
12198 References
12201 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 To detect an unexpected path or logic flow within a software, hardware, operator actions or a
12207 combination of these.
12208 Description
12209 The Sneak Circuit Analysis identifies special hazards called sneak circuit. These are paths in a
12210 system which leads to an unexpected behaviour of the system initiating an undesired function, a
12211 desired function but at inappropriate time or inhibiting a desired function. The presence of sneak
12212 circuits is often caused by a lack of design oversight, because of the complicity of the system; by
12213 changes or fixes, because they are rarely submitted to the rigorous testing that the original design
12214 undergoes; or by human errors when tasks are performed improperly, out of sequence, etc..
12215 Sneak circuits can be searched by an analyst or by commercial software packages. By both of them
12216 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 3) Simplify the set of schematics by eliminating all inactive nodes (nodes which have no influence to
12220 the change of system state);
12221 4) Produce network trees;
12222 5) Examine each node and identify the pattern containing that particular node;
12223 6) Detect sneak circuit conditions for each node using a large set of clues given to every pattern;
12224 and
12225 7) Generate a SCA report which includes sneak paths, timings, labels (e. g. a lack of precise
12226 nomenclature), indications (indicator that causes an incorrect operator display) and procedures
12227 (e. g. ambiguous wording, lack of notes, etc.) (output).
12229 SCA requires special computer programs driving up the costs. Furthermore, entering the data is a
12230 time-consuming process.
12231 References
12233 0-471-72019-5
12234
12235 H.2.31 Testing
12236 Testing is the activity of executing a system in order to detect failures. One of the key challenges of
12237 testing is how to select the tests that are most likely to expose failure in the system. There are many
12238 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 The idea of Model Based Testing is to have a model of the system (input), or specification, and use
12245 this model to generate sequences of input and expected output (output). Roughly speaking, the input
12246 is applied to the system under test, and system’s output is compared to the model’s output, as given
12247 by the generated trace. This implies that the model must be valid, i.e., that it faithfully represents the
12248 requirements.
12249 There are many relations of MBT to other techniques described in this document. One important way
12250 to create a model is by using Domain Specific Languages (H.2.6). For the test case generation Model
12251 Checking (H.2.12.2) or Theorem Proving (H.2.12.4) can be applied.
12253 –
12254 References
12255 Broy, M., Jonsson, B., Katoen, J.-P., Leucker, M. and Pretschner, A.: Model-Based Testing of
12256 Reactive Systems: Advanced Lectures; Springer, 2008. ISBN 978-3-540-26278-7
12257 Utting, M. and Legeard, B.: Practical Model-Based Testing. A Tools Approach; Morgan Kaufmann,
12258 2007. ISBN 978-0-12-372501-1
prEN 50126-4 - 206 -
12259
12260 H.2.31.2 Stress-Testing
12261 Aim
12262 To burden the test object with an exceptionally high workload in order to show that the test object
12263 would stand normal workloads easily.
12264 Description
12265 There are a variety of test conditions which can be applied for avalanche/stress testing. Some of
12266 these test conditions are listed below:
12267 - If working in a polling mode then the test object gets much more input changes per time unit as
12268 under normal conditions;
12269 - If working on demands then the number of demands per time unit to the test object is increased
12270 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 - For the extreme cases, all influential factors, as far as is possible, are put to the boundary
12274 conditions at the same time.
12275 Under these test conditions the time behaviour of the test object can be evaluated. The influence of
12276 load changes can be observed. The correct dimension of internal buffers or dynamic variables, stacks
12277 etc. can be checked.
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 A Test Oracle is a mechanism (human or machine) which can be used to check the correctness of the
12289 output (output) of the system for a large number of test cases (input). Therefore test cases are given
12290 to the TO and the system under testing. The output of the two is then compared to determine if the
12291 program behaved correctly for the test cases. The output of the TO must be verified to make a
12292 statement about the accuracy of the system. That increases the costs of a TO mechanism.
12294 TOs are often used when an old system is going to be replaced by a newer one. In this case the old
12295 system works as a TO and the results of the new and old system are compared.
- 207 - prEN 50126-4
12296 TO is not very common in the industry, since so far human testers took the role of the oracle; but this
12297 is changing increasingly.
12298 References
12299 Cofer, D.D. and Fantechi, A.: Formal Methods for Industrial Critical Systems – 13th International
12300 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 Prasad, K. V. K. K.: ISTQB – Certification Study Guide; Dreamtech Press, 2008.
12303 ISBN 978-81-7722-711-6
12304 Thomas, D.: ECOOP 2006 – Object-Oriented Programming – 20th European Conference; Springer,
12305 2006. ISBN 978-3-540-35726-1
12306 Yang, L. T., Zhou, X., Zhao, W., Wu, Z., Zhu, Y. and Lin, M.: Embedded Software and Systems – 2nd
12307 International Conference, ICESS 2005; Springer, 2005.
12308 ISBN 978-3-540-30881-2
12309 H.2.31.4 Fault Injection
12310 Aim
12311 To extend the scope or coverage of testing by injecting faults into the hardware or software and
12312 examining the effects.
12313 Description
12314 Fault injection is a testing technique that originally was performed on hardware, but later also
12315 developed into a technique for software testing, in particular in terms of so-called mutation testing.
12316 Some functions, particularly error handling functions, can only be tested by injecting faults.
12317 The first applications of testing by means of fault injection dates back to the 1970s when it was used
12318 to induce faults at a hardware level, the purpose being to examine the system level effects of
12319 hardware failures and thereby assess the dependability of the electronic system.
12320 Hardware fault injection in VLSI circuits is typically performed at the transistor level, where the
12321 transistors are given various types of faults, and the results examined in the operation of the
12322 circuit. Fault injection is done in simulated circuits as well as in physical realisations of circuits.
12323 When done in a simulated circuit, the purpose of the fault injection testing is typically to detect the
12324 response to manufacturing defects. By repeatedly introducing new faults, evaluating the response of
12325 the circuit, and modifying the circuit, the use of fault injection testing contribute to the circuit design.
12326 The system is simulated to evaluate the response of the circuit to that particular fault.
12327 Fault injection in a physical realisation of a circuit is typically done after fabrication but prior to the
12328 production of the circuit, to examine the effects of transient faults. The fault is produced by subjecting
12329 the circuit to some kind of interference, and then examining the resulting behaviour of the circuit by
12330 means of the testing equipment.
12331 Fault injection at a hardware level is known as Hardware Implemented Fault Injection. Analogously,
12332 fault injection in software is known as Software Implemented Fault Injection.
12334 Hardware Implemented Fault Injection is used in early design as well as after fabrication, to improve
12335 circuit design as well as to evaluate the dependability of the overall electronic system. Fault injection
12336 is generally more economical to perform for easily configurable hardware, such as FPGAs. Software
12337 Implemented Fault Injection is used to improve the coverage of software testing, in particular to check
12338 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 To model relevant aspects of the system behaviour and to assess and possibly improve safety and
12343 operational requirements through analysis and re-design.
12344 Description
12345 Petri nets belong to a class of graph theoretic models which are suitable for representing information
12346 and control flow in systems exhibiting concurrency and asynchronous behaviour. Petri nets extended
12347 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 The places may be 'marked' or 'unmarked'. A transition is 'enabled' when all the input places to it are
12353 marked by tokens. When enabled, it is permitted (but not obliged) to 'fire'. A firing transition removes
12354 one token form all its input places and add one token in each its output places. Some transitions fire
12355 in no time, some stochastically, and some even deterministically which quickly comes up against its
12356 limits, because of the mathematical complexity.
12357 To model a system by TPN (output) the primitive state of the system, the transition characteristics and
12358 all conceivable system states are needed (input). A detailed input allows identifying a special class of
12359 hazards, such as those dealing witch timing, state transition, and repair (output).
12361 –
12362 References
12364 0-471-72019-5
12365 T. Agerwala: Putting Petri Nets to Work, IEEE Computer, Dec., 85-94 (1979).
12366 Malhotra, M. and Trevedi, K.S.: Dependability Modeling Using Petri Nets, IEEE Trans. Reliability,
12367 44:428-440 (1995).
12368 Schneeweiss, W. G.: Petri Nets for Reliability Modeling, LiLoLe, 1999.
12369 ISBN 978-3-934447-00-7
12370 Schneeweiss, W. G.: Petri Nets as a Graphical Description Medium for Many Reliability Scenarios,
12371 IEEE Trans. Reliability, 50(2):June, 159-164 (2001).
12372 ** VDI 4008 Blatt 4: Methoden der Zuverlässigkeit – Petri-Netze; Beuth, 2008.
12373 ** IEC 62551; VDE 0050-4:2008-10: Analysemethoden der Zuverlässigkeit – Petrinetz-Modellierung;

12374 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 The objective of Traceability is to ensure that all requirements can be shown to have been properly
12381 met and that no untraceable material has been introduced.
12382 Traceability to requirements (input) shall be an important consideration in the validation of a system
12383 and means shall be provided to allow this to be demonstrated throughout all phases of the life cycle.
12384 Traceability shall be considered applicable to both functional and non-functional requirements and
12385 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 - Traceability of requirements and design objects to the operational and maintenance objects
12389 required to be applied in the safe and proper use of the system;
12390 - Traceability of requirements, design, implementation, operation and maintenance objects, to the
12391 verification and test plans and specifications which will determine their acceptability;
12392 - Traceability of verification and test plans and specifications to the test or other reports which
12393 record the results of their application.
12394 Where requirements, design or other objects are instantiated as a number of separate documents,
12395 traceability shall be maintained within the document structures and in a hierarchical manner.
12396 The output of the Traceability process shall be the subject of formal Configuration Management
12397 (H.2.3).
12398
12400 –
12401 References
12402 Grady, J. O.: System Requirements Analysis; Elsevier Inc., 2006.

12403 ISBN 978-0-12-088514-5
12404
12405 H.2.34 Trusted Components
12406 The advantages of using Trusted Components are saving time, especially during product
12407 development and minimizing the risk of default. In the following are described three techniques which
12408 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 A certified tool is one which has been determined to be of a particular quality. Certification is often
12415 carried out by a state-approved institution, which verifies whether national or international standards
12416 were met. CTs should be used in all phases of product development, because otherwise it is difficult
12417 to prove that the product meets applicable safety standards.
prEN 50126-4 - 210 -
12418 To work with CTs, it must be demonstrated that the specifications of the CTs fit to the requirements of
12419 the product development (input). If this condition is met, much time can be saved during the product
12420 development by the use of CTs. In addition, fewer errors occur, since it can be used on an already
12421 existing knowledge.
12423 CTs are found in a great set of applications and they are becoming increasingly important.
12424 References
12425 McKay, C.: How to Succeed as a Freelance Translator; Corinne McKay, 2006.
12426 ISBN 978-1-4116-9520-7
12427 Berghofer, S., Nipkow, T., Urban, C. and Wenzel, M.: Theorem Proving in Higher Order Logic: 22nd
12428 International Conference, Springer, 2008. ISBN 978-3-642-03358-2
12429
12430 H.2.34.2 Library of Trusted/Verified Components
12431 Aim
12432 To avoid the need for component designs to be extensively revalidated or redesigned for each new
12433 application.
12434 Description
12435 To designate a component as verified, mainly four things must be fulfilled (input):
12436 1) Formal specification of the component and its subcomponents which defines user visible
12437 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 There are two great advantages using verified components (output). Firstly, it saves time because it
12442 relies on components that do not have to be examined. Secondly, fewer errors occur in the risk
12443 analysis because it is based on already proven work.
12445 –
12446 References
12447 Yorav, K.: Hardware and Software: Verification and Testing; Third International Haifa Verification
12448 Conference, Springer, 1998. ISBN 978-3-540-77964-3
12449
12450 H.2.34.3 Tools proven in use
12451 Aim
12452 To avoid any difficulties due to translator failures which can arise during development, verification and
12453 maintenance of a software package.
- 211 - prEN 50126-4
12454 Description
12455 A translator is used, whose correct performance has been demonstrated in many projects already.
12456 Translators without operating experience or with any serious known errors are prohibited.
12457 If the translator has shown small deficiencies the related language constructs are noted down and
12458 carefully avoided during a safety related project.
12459 Another version to this way of working is to restrict the usage of the language to only its commonly
12460 used features.
12461 This recommendation is based on the experience from many projects. It has been shown that
12462 immature translators are a serious handicap to any software development. They make a safety-
12463 related software development generally infeasible.
12464 It is also known, presently, that no method exits to prove the correctness for all compiler parts.
12466 –
12467 References
12468 –
12469
12470 H.2.35 Unified Modelling Language (UML)
12471 Unified Modelling Language is a graphical modelling object-oriented language. In this scope the
12472 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 A Class Diagram consists of classes, their attributes, and the relationships between the classes. A
12479 class includes a set of objects with the same properties. Classes comprised the name of the class,
12480 the number of attributes of the class (these are the properties of the class), the number of methods or
12481 operations the class can take or undertake. Classes can be connected through links, called
12482 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 Relationships are marked with multiplicities which show if one class use or consists of zero or more
12487 instances of the related class.
12488 To model the whole system structure in a clear way (output), all connections of the components must
12489 be known (input).
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 George, C. and Miao, H.: Formal Methods and Software Engineering: 4th International Conference on
12495 Formal Engineering Methods, ICFEM 2002 Shanghai, China, October 2002 Proceedings; Springer,
12496 1998. ISBN 978-3-540-00029-1
12497 Holt, J.: UML for Systems Engineering: Watching the Wheels; Institution of Engineering and
12498 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 To model a static implementation view of a system a Component Diagram is useful. As Class
12505 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 - Dependencies indicate that one class depends on another because of using it at some point of
12509 time.
12510 The difference between ClDs and CoDs is, that CoDs typically maps to more classes. They are not as
12511 detailed as ClDs. Thus likened to a ClD a CoD is a blunt representation of a system structure (output).
12512 To achieve this, all connections of the components must be known (input).
12514 CoDs are very common. They are used especially in the beginning and end of system development.
12515 References
12516 Swain, G.: Object-Oriented Analysis and Design through Unified Modelling Language; University
12517 Science Press, 2010.
12518 Cade, M. and Roberts, S.: Sun Certified Enterprise Architect for J2EE Technology Study Guide; Sun
12519 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 Sequence Diagrams are very similar to Component Diagrams (CoD). In contrast to the CoDs, which
12526 can represent all possible process paths of a system, the SeDs are applied only on a specific process
12527 path in a system.
12528 SeDs consist of objects, relations, and lifelines. The objects are placed on the top of the diagram. A
12529 timeline is drawn downwards which symbolizes the duration for which the object is valid. Linking two
- 213 - prEN 50126-4
12530 timelines using a relationship line, means that information flow takes place at a readable time
12531 between these two objects.
12532 SeDs represents the possibility of a detail or a bluntly representation (output) of the use case
12533 structure. Because only a certain sequence state of the system can be considered, the input is limited
12534 to the structure and behaviour of this certain use case.
12536 –
12537 References
12538 Anglin, S. and Welsh, T.: Pro Java EE Spring Patterns: Best Practices and Design Strategies
12539 Implementing Java EE Patterns with the Spring Framework; Dhrubojyoti Kayal, 2008. ISBN 978-1-
12540 4302-1010-8
12541 Saleh, K. A.: Software Engineering; H. Ross Publishing, 2009. ISBN 978-1-932159-94-3
12542
12543 H.2.35.4 State Chart Diagram (SCD)
12544 Aim
12545 To depict the dynamic behaviour of a system.
12546 Description
12547 A State Chart Diagram consists of states, transitions, events, and activities also called actions. States
12548 indicate a set of conditions at which a system can be during its execution. The system state can be
12549 changed due to a transition between them. Most of these transitions have a trigger event which
12550 activates the transition. Only activated transitions can change the system state. Three activities can
12551 be assigned to one state: One activity which will be executed if the state occurs, one as during the
12552 state is true, and one if the state is left.
12553 SCDs show all possible states in which a system can be located (output). Therefore a good system
12554 structure knowledge is needed (input).
12556 –
12557 References
12558 Cade, M. and Roberts, S.: Sun Certified Enterprise Architect for J2EE Technology Study Guide; Sun
12559 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

21.5 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

21.5 EN50126 Draft pt4 CLCEnq 120629

Uploaded by

Copyright:

Available Formats

-1- prEN 50126-4

Applications ferroviaires – Spécification et démonstration de la fiabilité, de la

Bahnanwendungen - Spezifikation und Nachweis von Zuverlässigkeit, Verfügbarkeit,

7009 Table of Contents

7010 Introduction ................................................................................................................................................ 7

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

7054 List of Figures

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

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

7066 List of Tables

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

7133 Table C. 10 – Hardware/System Configuration Manager Role Specification ................................... 113

7153 The following dates were fixed:

7154 latest date by which the EN has to be implemented

7157 latest date by which the national standards conflicting

7159 This document supersedes EN 50129:2003.

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

7263 Application of EN 50126-4 follows from SIL allocation to system/subsystem/hardware through

7273 2. Normative references

7275 Additionally the following apply:

7281 3. Terms and Definitions

7284 3.1 change control board

7286 3.2 hardware component

7290 a) an electrical/electronic component or assembly delivering a specific function;

7298 3.4 release note

7301 3.5 safety manager

7306 4.1 ASR: assessor

7346 4.41 MCS: Monte-Carlo Simulation

7382 5. Overall Framework of the Part 4

7436 Annex A provides normative requirements on hardware techniques and measures,

7453 6. E/E/PE SYSTEMS MANAGEMENT AND ORGANISATION

7454 6.1 Lifecycle Issues and Documentation

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

7485 - it shall not contradict the preceding document.

7502 Figure 1 - Illustrative Development Lifecycle

7507 6.2 Organisation, Roles and Responsibilities

7511 6.2.2 Input

7512 1) Quality Assurance Plan

7513 6.2.3 Deliverables

7514 1) Quality Management Report

7515 6.2.4 Requirements

7572 6.3 Personnel Competence

7577 6.3.2 Input

7578 1) Quality Assurance Plan

7579 6.3.3 Deliverables

7580 1) Quality Assurance Plan (updated)

7581 6.3.4 Requirements

7586 6.3.4.2 Documented evidence of personnel competence, including technical knowledge,

7599 7. E/E/PE SYSTEMS ASSURANCE

7600 7.1 Analysis

7632 7.1.2 Input

7634 7.1.3 Deliverables

7639 7.1.4 Requirements

7645 a) is well documented;

7646 b) has a scientific basis;

7647 c) ensures repeatability;