SIST EN 50128:2011

Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems

1.1   This European Standard specifies the process and technical requirements for the development of software for programmable electronic systems for use in railway control and protection applications. It is aimed at use in any area where there are safety implications. These systems can be implemented using dedicated microprocessors, programmable logic controllers, multiprocessor distributed systems, larger scale central processor systems or other architectures. 1.2   This European Standard is applicable exclusively to software and the interaction between software and the system of which it is part. 1.3   This European Standard is not relevant for software that has been identified as having no impact on safety, i.e. software of which failures cannot affect any identified safety functions. 1.4   This European Standard applies to all safety related software used in railway control and protection systems, including –   application programming, –   operating systems, –   support tools, –   firmware. Application programming comprises high level programming, low level programming and special purpose programming (for example: Programmable logic controller ladder logic). 1.5   This European Standard also addresses the use of pre-existing software and tools. Such software may be used, if the specific requirements in 7.3.4.7 and 6.5.4.16  on pre-existing software and for tools in 6.7 are fulfilled. 1.6   Software developed according to any version of this European Standard will be considered as compliant and not subject to the requirements on pre-existing software. 1.7   This European Standard considers that modern application design often makes use of generic software that is suitable as a basis for various applications. Such generic software is then configured by data, algorithms, or both, for producing the executable software for the application. The general Clauses 1 to 6 and 9 of this European Standard apply to generic software as well as for application data or algorithms. The specific Clause 7 applies only for generic software while Clause 8 provides the specific requirements for application data or algorithms. 1.8   This European Standard is not intended to address commercial issues. These should be addressed as an essential part of any contractual agreement. All the clauses of this European Standard will need careful consideration in any commercial situation. 1.9   This European Standard is not intended to be retrospective. It therefore applies primarily to new developments and only applies in its entirety to existing systems if these are subjected to major modifications. For minor changes, only 9.2 applies. The assessor has to analyse the evidences provided in the software documentation to confirm whether the determination of the nature and scope of software changes is adequate. However, application of this European Standard during upgrades and maintenance of existing software is highly recommended.

Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und Überwachungssysteme

Applications ferroviaires - Systèmes de signalisation, de télécommunication et de traitement - Logiciels pour systèmes de commande et de protection ferroviaire

Železniške naprave - Komunikacijski, signalni in procesni sistemi - Programska oprema za železniške krmilne in zaščitne sisteme

Ta evropski standard določa procesne in tehnične zahteve za razvoj programske opreme programirljivih elektronskih sistemov za uporabo pri železniških krmilnih in zaščitnih aplikacijah. Namenjen je uporabi na vseh področjih glede varnosti. Ti sistemi so lahko izvedeni z namenskimi mikroprocesorji, programirljivimi logičnimi krmilniki, mikroprocesorsko porazdeljenimi sistemi, večjimi centralnimi procesorskimi sistemi ali drugimi arhitekturami. Ta evropski standard velja izključno za programsko opremo in interakcijo med programsko opremo in sistemom, katerega del je. Ta evropski standard ni pomemben za programsko opremo, ki ne učinkuje na varnost, tj. programsko opremo, katere odpovedi ne vplivajo na prepoznane varnostne funkcije. Ta evropski standard velja za vse programske opreme, povezane z varnostjo, ki se uporabljajo v železniških krmilnih in zaščitnih sistemih, vključno z/s – aplikacijskim programiranjem, - operacijskimi sistemi, - podpornim orodjem, - sistemskimi programi. Aplikacijsko programiranje zajema programiranje na visoki ravni, programiranje na nizki ravni in programiranje za posebne namene (na primer: programirljiv logični krmilnik z lestvično logiko). Ta evropski standard obravnava tudi uporabo predobstoječe programske opreme in orodij. Taka programska oprema se lahko uporabi, če so izpolnjene zahteve iz točk 7.3.4.7 in 6.5.4.16 za predobstoječo programsko opremo in iz točke 6.7 za orodja. Programska oprema, razvita v skladu s katero koli različico tega evropskega standarda, velja za skladno in zanjo ne veljajo zahteve za predobstoječo programsko opremo. Ta evropski standard upošteva, da se pri modernem načrtovanju aplikacij pogosto uporablja univerzalna programska oprema, ki je primerna kot osnova za različne aplikacije. Taka univerzalna programska oprema se nato konfigurira s podatki, algoritmi ali obojim, da nastane izvršljiva programska oprema za določeno aplikacijo. Splošne točke 1 do 6 in 9 tega evropskega standard veljajo za univerzalno programsko opremo in za aplikacijske podatke ali algoritme. Specifična točka 7 velja samo za univerzalno programsko opremo, medtem ko točka 8 podaja specifične zahteve za aplikacijske podatke ali algoritme. Ta evropski standard ne obravnava komercialnih vprašanj, ki naj se obravnavajo kot bistveni del kakršnega koli pogodbenega dogovora Vse točke tega evropskega standarda je treba skrbno upoštevati v vseh komercialnih situacijah. Ta evropski standard ni retrospektiven. Velja torej predvsem za nov razvoj in v celoti velja le za obstoječe sisteme, če pri njih pride do večjih sprememb. Pri manjših spremembah velja le točka 9.2. Ocenjevalec mora analizirati dokaze v dokumentaciji programske opreme, s katerimi potrdi, da je ugotavljanje narave in obsega sprememb programske opreme ustrezno. Uporaba tega evropskega standarda se kljub temu močno priporoča med nadgradnjami in vzdrževanjem obstoječe programske opreme.

General Information

• Status: Published In Translation
• Public Enquiry End Date: 30-Dec-2009
• Publication Date: 06-Jul-2011
• ICS: 35.240.60 - IT applications in transport
• ICS: 45.020 - Railway engineering in general
• Technical Committee: ŽEN - Electrical applications for railways
• Current Stage: 6100 - Translation of adopted SIST standards (Adopted Project)
• Start Date: 28-Feb-2012
• Due Date: 26-Feb-2013
• Directive: 2001/16/EC - Directive 2001/16/EC of the European Parliament and of the Council of 19 March 2001 on the interoperability of the trans-European conventional rail system
• Directive: 2016/797/EU - Directive (EU) 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the European Union (Text with EEA relevance)
• Directive: 96/48/EC - Interoperability of the trans-European high-speed rail system
• Mandate: M/483 - Mandate for programming and standardisation addressed to the European standardisation bodies under directive 2008/57/EC in the field of the interoperability of the rail system within the European Union
• Ref Project: EN 50128:2011 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems

Relations

• Replaces: SIST EN 50128:2002 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems
• Effective Date: 01-Sep-2011
• Amended By: SIST EN 50128:2011/A1:2020 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems
• Effective Date: 23-Jul-2019
• Amended By: SIST EN 50128:2011/A2:2020 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems
• Effective Date: 17-Sep-2018
• Corrected By: SIST EN 50128:2011/AC:2014 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems
• Effective Date: 18-Feb-2014
• Revised: SIST EN 50716:2024 - Railway Applications - Requirements for software development
• Effective Date: 01-Mar-2024
• Revised: SIST EN 50128:2002 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems
• Effective Date: 06-May-2014
• Revised: oSIST prEN 50126-5:2012 - Railway applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) - Part 5: Functional Safety - Software
• Effective Date: 29-Mar-2013

Overview - EN 50128:2011 (software for railway control and protection systems)

EN 50128:2011 is a CENELEC European Standard that defines process and technical requirements for the development, verification and maintenance of software used in railway control and protection systems. It applies to safety‑related programmable electronic systems (microprocessors, PLCs, distributed and central processor architectures) and covers application programming, operating systems, support tools and firmware. The standard focuses exclusively on software and its interaction with the wider system, and is intended for any software whose failure can affect identified safety functions.

Key topics and technical requirements

• Scope and applicability: Applies to safety‑related software only; not relevant for software with no impact on safety. Primarily targets new developments; limited retroactive application for major modifications (minor changes handled via clause 9.2).
• Software safety integrity: Defines objectives, conformance and software safety integrity levels (see Clause 4) to guide required rigor in development and assurance activities.
• Lifecycle and documentation: Requires defined lifecycle processes, roles, responsibilities and comprehensive documentation for development, deployment and maintenance (Clauses 1–6, 9).
• Software assurance: Includes testing, verification, validation, assessment and quality assurance activities (Clause 6) with specific emphasis on traceability and evidence of compliance.
• Support tools and pre‑existing software: Addresses use and qualification of tools and pre‑existing software (see Clauses 6.7, 7.3.4.7 and 6.5.4.16), including when prior software can be reused and when requalification is needed.
• Generic software and configuration by data: Distinguishes requirements for generic software (Clause 7) and for systems configured by application data or algorithms (Clause 8); general clauses (1–6, 9) apply to both.
• Techniques and measures: Normative annexes provide criteria for selecting development and assurance techniques (e.g., testing, formal methods, reviews).

Practical applications - who uses EN 50128:2011

• Railway software developers and integrators creating signalling, interlocking, train control and protection software.
• System engineers and project managers responsible for software lifecycle, safety cases and certification evidence.
• Test engineers, assessors and certification bodies evaluating software conformity and safety integrity.
• Suppliers of firmware, operating systems, PLC logic and safety‑critical support tools.

Related standards

EN 50128:2011 is part of the EN 5012x railway safety family and is used alongside other railway lifecycle and safety standards when producing safety‑critical software and documentation.

By following EN 50128:2011, organisations ensure robust software development, verification and maintenance practices for reliable, certifiable railway control and protection systems.

Standards Content (Sample)

SLOVENSKI STANDARD
01-september-2011
1DGRPHãþD
SIST EN 50128:2002
äHOH]QLãNHQDSUDYH.RPXQLNDFLMVNLVLJQDOQLLQSURFHVQLVLVWHPL3URJUDPVND
RSUHPD]DåHOH]QLãNHNUPLOQHLQ]DãþLWQHVLVWHPH
Railway applications - Communication, signalling and processing systems - Software for
railway control and protection systems
Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und
Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und
Überwachungssysteme
Applications ferroviaires - Systèmes de signalisation, de télécommunication et de
traitement - Logiciels pour systèmes de commande et de protection ferroviaire
Ta slovenski standard je istoveten z: EN 50128:2011
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
45.020 Železniška tehnika na Railway engineering in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 50128
NORME EUROPÉENNE
June 2011
EUROPÄISCHE NORM
ICS 35.240.60; 45.020; 93.100 Supersedes EN 50128:2001
English version
Railway applications -
Communication, signalling and processing systems -
Software for railway control and protection systems
Applications ferroviaires -  Bahnanwendungen -
Systèmes de signalisation, de Telekommunikationstechnik,
télécommunication et de traitement - Signaltechnik und
Logiciels pour systèmes de commande et Datenverarbeitungssysteme -
de protection ferroviaire Software für Eisenbahnsteuerungs- und
Überwachungssysteme
This European Standard was approved by CENELEC on 2011-04-25. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and
notified to the Central Secretariat has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia,
Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2011 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 50128:2011 E
Contents
Foreword . 6
Introduction . 7
1 Scope . 10
2 Normative references . 11
3 Terms, definitions and abbreviations . 11
3.1 Terms and definitions . 11
3.2 Abbreviations . 15
4 Objectives, conformance and software safety integrity levels . 16
5 Software management and organisation. 17
5.1 Organisation, roles and responsibilities . 17
5.2 Personnel competence . 20
5.3 Lifecycle issues and documentation . 21
6 Software assurance . 23
6.1 Software testing . 23
6.2 Software verification . 25
6.3 Software validation . 27
6.4 Software assessment . 28
6.5 Software quality assurance. 30
6.6 Modification and change control. 33
6.7 Support tools and languages . 34
7 Generic software development . 37
7.1 Lifecycle and documentation for generic software . 37
7.2 Software requirements . 37
7.3 Architecture and Design . 40
7.4 Component design . 46
7.5 Component implementation and testing . 49
7.6 Integration . 50
7.7 Overall Software Testing / Final Validation . 52
8 Development of application data or algorithms: systems configured by application data or
algorithms . 54

- 3 - EN 50128:2011
8.1 Objectives . 54
8.2 Input documents . 55
8.3 Output documents . 55
8.4 Requirements . 55
9 Software deployment and maintenance . 60
9.1 Software deployment . 60
9.2 Software maintenance . 62
Annex A (normative) Criteria for the Selection of Techniques and Measures . 65
A.1 Clauses tables . 66
A.2 Detailed tables . 73
Annex B (normative) Key software roles and responsibilities . 79
Annex C (informative) Documents Control Summary . 88
Annex D (informative) Bibliography of techniques . 90
D.1 Artificial Intelligence Fault Correction . 90
D.2 Analysable Programs . 90
D.3 Avalanche/Stress Testing . 91
D.4 Boundary Value Analysis . 91
D.5 Backward Recovery . 92
D.6 Cause Consequence Diagrams . 92
D.7 Checklists . 92
D.8 Control Flow Analysis. 93
D.9 Common Cause Failure Analysis . 93
D.10 Data Flow Analysis. 94
D.11 Data Flow Diagrams . 94
D.12 Data Recording and Analysis . 95
D.13 Decision Tables (Truth Tables). 95
D.14 Defensive Programming . 96
D.15 Coding Standards and Style Guide . 96
D.16 Diverse Programming . 97
D.17 Dynamic Reconfiguration . 98
D.18 Equivalence Classes and Input Partition Testing. 98
D.19 Error Detecting and Correcting Codes . 98
D.20 Error Guessing . 99
D.21 Error Seeding . 99
D.22 Event Tree Analysis . 99
D.23 Fagan Inspections. 100
D.24 Failure Assertion Programming . 100
D.25 SEEA – Software Error Effect Analysis . 100
D.26 Fault Detection and Diagnosis . 101
D.27 Finite State Machines/State Transition Diagrams . 102
D.28 Formal Methods . 102
D.29 Formal Proof . 108

D.30 Forward Recovery . 108
D.31 Graceful Degradation . 108
D.32 Impact Analysis . 109
D.33 Information Hiding / Encapsulation . 109
D.34 Interface Testing . 110
D.35 Language Subset . 110
D.36 Memorising Executed Cases . 110
D.37 Metrics . 111
D.38 Modular Approach . 111
D.39 Performance Modelling . 112
D.40 Performance Requirements . 112
D.41 Probabilistic Testing . 113
D.42 Process Simulation . 113
D.43 Prototyping / Animation . 114
D.44 Recovery Block . 114
D.45 Response Timing and Memory Constraints . 114
D.46 Re-Try Fault Recovery Mechanisms. 115
D.47 Safety Bag . 115
D.48 Software Configuration Management . 115
D.49 Strongly Typed Programming Languages . 115
D.50 Structure Based Testing . 116
D.51 Structure Diagrams . 116
D.52 Structured Methodology . 117
D.53 Structured Programming . 117
D.54 Suitable Programming languages . 118
D.55 Time Petri Nets . 119
D.56 Walkthroughs / Design Reviews . 119
D.57 Object Oriented Programming . 119
D.58 Traceability . 120
D.59 Metaprogramming . 121
D.60 Procedural programming . 121
D.61 Sequential Function Charts . 121
D.62 Ladder Diagram . 122
D.63 Functional Block Diagram . 122
D.64 State Chart or State Diagram . 122
D.65 Data modelling . 122
D.66 Control Flow Diagram/Control Flow Graph . 123
D.67 Sequence diagram . 124
D.68 Tabular Specification Methods . 124
D.69 Application specific language . 124
D.70 UML (Unified Modeling Language) . 125
D.71 Domain specific languages . 126
Bibliography . 127

- 5 - EN 50128:2011
Figures
Figure 1 – Illustrative Software Route Map . 9
Figure 2 – Illustration of the preferred organisational structure . 18
Figure 3 – Illustrative Development Lifecycle 1 . 22
Figure 4 – Illustrative Development Lifecycle 2 . 23
Tables
Table 1 - Relation between tool class and applicable sub-clauses . 37
Table A.1– Lifecycle Issues and Documentation (5.3) . 66
Table A.2 – Software Requirements Specification (7.2) . 68
Table A.3 – Software Architecture (7.3) . 69
Table A.4– Software Design and Implementation (7.4) . 70
Table A.5 – Verification and Testing (6.2 and 7.3) . 71
Table A.6 – Integration (7.6) . 71
Table A.7 – Overall Software Testing (6.2 and 7.7) . 71
Table A.8 – Software Analysis Techniques (6.3) . 72
Table A.9 – Software Quality Assurance (6.5) . 72
Table A.10 – Software Maintenance (9.2) . 72
Table A.11 – Data Preparation Techniques (8.4) . 73
Table A.12 – Coding Standards . 73
Table A.13 – Dynamic Analysis and Testing . 74
Table A.14 – Functional/Black Box Test . 74
Table A.15 – Textual Programming Languages . 75
Table A.16 – Diagrammatic Languages for Application Algorithms . 75
Table A.17 – Modelling . 76
Table A.18 – Performance Testing . 76
Table A.19 – Static Analysis . 76
Table A.20 – Components . 77
Table A.21 – Test Coverage for Code . 77
Table A.22 – Object Oriented Software Architecture . 78
Table A.23 – Object Oriented Detailed Design . 78
Table B.1 – Requirements Manager Role Specification . 79
Table B.2 – Designer Role Specification . 80
Table B.3 – Implementer Role Specification. 81
Table B.4 – Tester Role Specification . 82
Table B.5 – Verifier Role Specification . 83
Table B.6 – Integrator Role Specification . 84
Table B.7 – Validator Role Specification. 85
Table B.8 – Assessor Role Specification . 86
Table B.9 – Project Manager Role Specification . 87
Table B.10 – Configuration Manager Role Specification . 87
Table C.1 – Documents Control Summary . 88

Foreword
This European Standard was prepared by SC 9XA, Communication, signalling and processing systems, of
Technical Committee CENELEC TC 9X, Electrical and electronic applications for railways. .
It was submitted to the Formal Vote and was approved by CENELEC as EN 50128 on
2011-04-25.
This document supersedes EN 50128:2001.
The main changes with respect to EN 50128:2001 are listed below:
• requirements on software management and organisation, definition of roles and competencies,
deployment and maintenance have been added;
• a new clause on tools has been inserted, based on EN 61508-2:2010;
• tables in Annex A have been updated.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN and CENELEC shall not be held responsible for identifying any or all such patent rights.
The following dates were fixed:
– latest date by which the EN has to be implemented

at national level by publication of an identical

national standard or by endorsement
(dop) 2012-04-25
– latest date by which the national standards conflicting
2014-04-25
with the EN have to be withdrawn
(dow)
This European Standard should be read in conjunction with EN 50126-1:1999 "Railway applications –
The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) – Part 1:
Basic requirements and generic process” and EN 50129:2003 "Railway applications – Communication,
signalling and processing systems – Safety related electronic systems for signalling".
__________
- 7 - EN 50128:2011
Introduction
This European Standard is part of a group of related standards. The others are EN 50126-1:1999 "Railway
applications – The specification and demonstration of Reliability, Availability, Maintainability and Safety
(RAMS) – Part 1: Basic requirements and generic process” and EN 50129:2003 "Railway applications –
Communication, signalling and processing systems – Safety related electronic systems for signalling".
EN 50126-1 addresses system issues on the widest scale, while EN 50129 addresses the approval process
for individual systems which can exist within the overall railway control and protection system. This European
Standard concentrates on the methods which need to be used in order to provide software which meets the
demands for safety integrity which are placed upon it by these wider considerations.
This European Standard provides a set of requirements with which the development, deployment and
maintenance of any safety-related software intended for railway control and protection applications shall
comply. It defines requirements concerning organisational structure, the relationship between organisations
and division of responsibility involved in the development, deployment and maintenance activities. Criteria for
the qualification and expertise of personnel are also provided in this European Standard.
The key concept of this European Standard is that of levels of software safety integrity. This European
Standard addresses five software safety integrity levels where 0 is the lowest and 4 the highest one.
The higher the risk resulting from software failure, the higher the software safety integrity level will be.
This European Standard has identified techniques and measures for the five levels of software safety
integrity. The required techniques and measures for software safety integrity levels 0-4 are shown in the
normative tables of Annex A. In this version, the required techniques for level 1 are the same as for level 2,
and the required techniques for level 3 are the same as for level 4. This European Standard does not give
guidance on which level of software safety integrity is appropriate for a given risk. This decision will depend
upon many factors including the nature of the application, the extent to which other systems carry out safety
functions and social and economic factors.
It is within the scope of EN 50126-1 and EN 50129 to define the process of specifying the safety functions
allocated to software.
This European Standard specifies those measures necessary to achieve these requirements.
EN 50126-1 and EN 50129 require that a systematic approach be taken to
a) identify hazards, assessing risks and arriving at decisions based on risk criteria,
b) identify the necessary risk reduction to meet the risk acceptance criteria,
c) define an overall System Safety Requirements Specification for the safeguards necessary to achieve the
required risk reduction,
d) select a suitable system architecture,
e) plan, monitor and control the technical and managerial activities necessary to translate the System Safety
Requirements Specification into a Safety-Related System of a validated safety integrity.
As decomposition of the specification into a design comprising safety-related systems and components takes
place, further allocation of safety integrity levels is performed. Ultimately this leads to the required software
safety integrity levels.
The current state-of-the-art is such that neither the application of quality assurance methods (so-called fault
avoiding measures and fault detecting measures) nor the application of software fault tolerant approaches
can guarantee the absolute safety of the software. There is no known way to prove the absence of faults in
reasonably complex safety-related software, especially the absence of specification and design faults.

The principles applied in developing high integrity software include, but are not restricted to
– top-down design methods,
– modularity,
– verification of each phase of the development lifecycle,
– verified components and component libraries,
– clear documentation and traceability,
– auditable documents,
– validation,
– assessment,
– configuration management and change control and
– appropriate consideration of organisation and personnel competency issues.
The System Safety Requirements Specification identifies all safety functions allocated to software and
determines their system safety integrity level. The successive functional steps in the application of this
European Standard are shown in Figure 1 and are as follows:
a) define the Software Requirements Specification and in parallel consider the software architecture.
The software architecture is where the safety strategy is developed for the software and the software
safety integrity level (7.2 and 7.3);
b) design, develop and test the software according to the Software Quality Assurance Plan, software safety
integrity level and the software lifecycle (7.4 and 7.5);
c) integrate the software on the target hardware and verify functionality (7.6);
d) accept and deploy the software (7.7 and 9.1);
e) if software maintenance is required during operational life then re-activate this European Standard as
appropriate (9.2).
A number of activities run across the software development. These include testing (6.1), verification (6.2),
validation (6.3), assessment (6.4), quality assurance (6.5) and modification and change control (6.6).
Requirements are given for support tools (6.7) and for systems which are configured by application data or
algorithms (Clause 8).
Requirements are also given for the independence of roles and the competence of staff involved in software
development (5.1, 5.2 and Annex B).
This European Standard does not mandate the use of a particular software development lifecycle. However,
illustrative lifecycle and documentation sets are given in 5.3, Figure 3 and Figure 4 and in 7.1.
Tables have been formulated ranking various techniques/measures against the software safety integrity
levels 0-4. The tables are in Annex A. Cross-referenced to the tables is a bibliography giving a brief
description of each technique/measure with references to further sources of information. The bibliography of
techniques is in Annex D.
- 9 - EN 50128:2011
Obtain System Requirements Specification,
System Safety Requirements Specification
System Architecture Description and System
Safety Plan for the system
Identify all the safety functions allocated to the
software
Review all safety functions allocated to the
software and determine the Software Safety
Integrity Level
Produce the Software Requirements
Specification and the Software Architecture
Specification
Design, develop and verify/test the software
according to the Software Quality Assurance
Plan, Software Safety Integrity Level and the
Software Lifecycle
Perform the Software Validation and hand
over to system engineers
Operational life of the system
Software Maintenance
Figure 1 – Illustrative Software Route Map

1 Scope
1.1 This European Standard specifies the process and technical requirements for the development of
software for programmable electronic systems for use in railway control and protection applications. It is
aimed at use in any area where there are safety implications. These systems can be implemented using
dedicated microprocessors, programmable logic controllers, multiprocessor distributed systems, larger scale
central processor systems or other architectures.
1.2 This European Standard is applicable exclusively to software and the interaction between software and
the system of which it is part.
1.3 This European Standard is not relevant for software that has been identified as having no impact on
safety, i.e. software of which failures cannot affect any identified safety functions.
1.4 This European Standard applies to all safety related software used in railway control and protection
systems, including
– application programming,
– operating systems,
– support tools,
– firmware.
Application programming comprises high level programming, low level programming and special purpose
programming (for example: Programmable logic controller ladder logic).
1.5 This European Standard also addresses the use of pre-existing software and tools. Such software may
be used, if the specific requirements in 7.3.4.7 and 6.5.4.16 on pre-existing software and for tools in 6.7 are
fulfilled.
1.6 Software developed according to any version of this European Standard will be considered as compliant
and not subject to the requirements on pre-existing software.
1.7 This European Standard considers that modern application design often makes use of generic software
that is suitable as a basis for various applications. Such generic software is then configured by data,
algorithms, or both, for producing the executable software for the application. The general Clauses 1 to 6 and
9 of this European Standard apply to generic software as well as for application data or algorithms. The
specific Clause 7 applies only for generic software while Clause 8 provides the specific requirements for
application data or algorithms.
1.8 This European Standard is not intended to address commercial issues. These should be addressed as
an essential part of any contractual agreement. All the clauses of this European Standard will need careful
consideration in any commercial situation.
1.9 This European Standard is not intended to be retrospective. It therefore applies primarily to new
developments and only applies in its entirety to existing systems if these are subjected to major modifications.
For minor changes, only 9.2 applies. The assessor has to analyse the evidences provided in the software
documentation to confirm whether the determination of the nature and scope of software changes is
adequate. However, application of this European Standard during upgrades and maintenance of existing
software is highly recommended.

- 11 - EN 50128:2011
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
EN 50126-1:1999 Railway applications – The specification and demonstration of Reliability, Availability,
Maintainability and Safety (RAMS) – Part 1: Basic requirements and generic process
EN 50129:2003 Railway applications – Communication, signalling and processing systems –
Safety related electronic systems for signalling
EN ISO 9000 Quality management systems – Fundamentals and vocabulary (ISO 9000:2005)
EN ISO 9001 Quality management systems – Requirements (ISO 9001:2008)
ISO/IEC 90003:2004 Software engineering – Guidelines for the application of ISO 9001:2000 to computer
software
ISO/IEC 9126 series Software engineering – Product quality
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
assessment
process of analysis to determine whether software, which may include process, documentation, system,
subsystem hardware and/or software components, meets the specified requirements and to form a
judgement as to whether the software is fit for its intended purpose. Safety assessment is focused on but not
limited to the safety properties of a system
3.1.2
assessor
entity that carries out an assessment
3.1.3
commercial off-the-shelf (COTS) software
software defined by market-driven need, commercially available and whose fitness for purpose has been
demonstrated by a broad spectrum of commercial users
3.1.4
component
a constituent part of software which has well-defined interfaces and behaviour with respect to the software
architecture and design and fulfils the following criteria:
– it is designed according to “Components” (see Table A.20);
– it covers a specific subset of software requirements;
– it is clearly identified and has an independent version inside the configuration management system or is
a part of a collection of components (e. g. subsystems) which have an independent version

3.1.5
configuration manager
entity that is responsible for implementing and carrying out the processes for the configuration management
of documents, software and related tools including change management
3.1.6
customer
entity which purchases a railway control and protection system including the software
3.1.7
designer
entity that analyses and transforms specified requirements into acceptable design solutions which have the
required safety integrity level
3.1.8
entity
person, group or organisation who fulfils a role as defined in this European Standard
3.1.9
error, fault
defect, mistake or inaccuracy which could result in failure or in a deviation from the intended performance or
behaviour
3.1.10
failure
unacceptable difference between required and observed performance
3.1.11
fault tolerance
built-in capability of a system to provide continued correct provision of service as specified, in the presence of
a limited number of hardware or software faults
3.1.12
firmware
software stored in read-only memory or in semi-permanent storage such as flash memory, in a way that is
functionally independent of applicative software
3.1.13
generic software
software which can be used for a variety of installations purely by the provision of application-specific data
and/or algorithms
3.1.14
implementer
entity that transforms specified designs into their physical realisation
3.1.15
integration
process of assembling software and/or hardware items, according to the architectural and design
specification, and testing the integrated unit
3.1.16
integrator
entity that carries out software integration
3.1.17
pre-existing software
software developed prior to the application currently in question, including COTS (commercial off-the shelf)
and open source software
3.1.18
open source software
source code available to the general public with relaxed or non-existent copyright restrictions

- 13 - EN 50128:2011
3.1.19
programmable logic controller
solid-state control system which has a user programmable memory for storage of instructions to implement
specific functions
3.1.20
project management
administrative and/or technical conduct of a project, including safety aspects
3.1.21
project manager
entity that carries out project management
3.1.22
reliability
ability of an item to perform a required function under given conditions for a given period of time
3.1.23
robustness
ability of an item to detect and handle abnormal situations
3.1.24
requirements manager
entity that carries out requirements management
3.1.25
requirements management
the process of eliciting, documenting, analysing, prioritising and agreeing on requirements and then
controlling change and communicating to relevant stakeholders. It is a continuous process throughout a
project
3.1.26
risk
combination of the rate of occurrence of accidents and incidents resulting in harm (caused by a hazard) and
the degree of severity of that harm
3.1.27
safety
freedom from unacceptable levels of risk of harm to people
3.1.28
safety authority
body responsible for certifying that safety related software or services comply with relevant statutory safety
requirements
3.1.29
safety function
a function that implements a part or whole of a safety requirement
3.1.30
safety-related software
software which performs safety functions
3.1.31
software
intellectual creation comprising the programs, procedures, rules, data and any associated documentation
pertaining to the operation of a system
3.1.32
software baseline
complete and consistent set of source code, executable files, configuration files, installation scripts and
documentation that are needed for a software release. Information about compilers, operating systems, pre-
existing software and dep
...

SLOVENSKI STANDARD
01-september-2011
Nadomešča:
SIST EN 50128:2002
Železniške naprave - Komunikacijski, signalni in procesni sistemi - Programska
oprema za železniške krmilne in zaščitne sisteme
Railway applications - Communication, signalling and processing systems - Software for
railway control and protection systems
Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und
Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und
Überwachungssysteme
Applications ferroviaires - Systèmes de signalisation, de télécommunication et de
traitement - Logiciels pour systèmes de commande et de protection ferroviaire
Ta slovenski standard je istoveten z: EN 50128:2011
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
45.020 Železniška tehnika na Railway engineering in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

NORME EUROPÉENNE
EN 50128
EUROPÄISCHE NORM
Juin 2011
EUROPEAN STANDARD
ICS 35.240.60; 45.020; 93.100 Remplace EN 50128:2001

Version française
Applications ferroviaires -
Systèmes de signalisation, de télécommunication et de traitement -
Logiciels pour systèmes de commande et de protection ferroviaire

Bahnanwendungen -  Railway applications -
Telekommunikationstechnik, Communication, signalling and processing
Signaltechnik und systems -
Datenverarbeitungssysteme - Software for railway control and protection
Software für Eisenbahnsteuerungs- und systems
Überwachungssysteme
La présente Norme Européenne a été adoptée par le CENELEC le 2011-04-25. Les membres du CENELEC
sont tenus de se soumettre au Règlement Intérieur du CEN/CENELEC qui définit les conditions dans lesquelles
doit être attribué, sans modification, le statut de norme nationale à la Norme Européenne.

Les listes mises à jour et les références bibliographiques relatives à ces normes nationales peuvent être
obtenues auprès du Secrétariat Central ou auprès des membres du CENELEC.

La présente Norme Européenne existe en trois versions officielles (allemand, anglais, français). Une version
dans une autre langue faite par traduction sous la responsabilité d'un membre du CENELEC dans sa langue
nationale, et notifiée au Secrétariat Central, a le même statut que les versions officielles.

Les membres du CENELEC sont les comités électrotechniques nationaux des pays suivants: Allemagne,
Autriche, Belgique, Bulgarie, Chypre, Croatie, Danemark, Espagne, Estonie, Finlande, France, Grèce, Hongrie,
Irlande, Islande, Italie, Lettonie, Lituanie, Luxembourg, Malte, Norvège, Pays-Bas, Pologne, Portugal,
République Tchèque, Roumanie, Royaume-Uni, Slovaquie, Slovénie, Suède et Suisse.

CENELEC
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
European Committee for Electrotechnical Standardization

Management Centre: Avenue Marnix 17, B - 1000 Bruxelles

© 2011 CENELEC - Tous droits d'exploitation sous quelque forme et de quelque manière que ce soit réservés dans le monde entier aux
membres du CENELEC.
Ref. n° EN 50128:2011 F
Sommaire
Foreword . 5
Introduction . 7
1 Domaine d'application . 10
2 Références normatives. 11
3 Termes, définitions et abréviations . 11
3.1 Termes et définitions . 11
3.2 Abréviations . 15
4 Objectifs, conformité et niveaux d'intégrité de sécurité du logiciel . 16
5 Organisation et gestion du développement logiciel . 17
5.1 Organisation, rôles et responsabilités . 17
5.2 Compétence du personnel . 21
5.3 Questions relatives au cycle de vie et à la documentation . 21
6 Assurance du logiciel . 24
6.1 Test du logiciel . 24
6.2 Vérification du logiciel . 26
6.3 Validation du logiciel . 28
6.4 Évaluation du logiciel . 29
6.5 Assurance Qualité du Logiciel . 31
6.6 Contrôle des modifications et des évolutions . 34
6.7 Outils et langages . 35
7 Développement de logiciel générique . 39
7.1 Cycle de vie et documentation pour logiciel générique. 39
7.2 Exigences relatives au logiciel . 39
7.3 Architecture et Conception . 42
7.4 Conception du Composant . 48
7.5 Réalisation et Test des composants . 51
7.6 Intégration . 52
7.7 Tests d'Ensemble du Logiciel / Validation Finale . 54
8 Développement de données d'application ou d'algorithmes d'application : systèmes
configurés par des données d'application ou par des algorithmes d'application . 56
8.1 Objectifs . 56
8.2 Documents en entrée. 57

- 3 - EN 50128:2011
8.3 Documents en sortie. 57
8.4 Exigences . 57
9 Déploiement et maintenance du logiciel . 62
9.1 Déploiement du logiciel . 62
9.2 Maintenance du logiciel . 64
Annexe A (normative) Critères de sélection des techniques et mesures . 67
A.1 Tableaux d'articles . 68
A.2 Tableaux détaillés . 76
Annexe B (normative) Principaux rôles et responsabilités relatifs au logiciel . 82
Annexe C (informative) Résumé du contrôle des documents . 91
Annexe D (informative) Bibliographie des techniques . 93
D.1 Intelligence artificielle - Correction des défauts . 93
D.2 Programmes analysables . 93
D.3 Tests en avalanche/en surcharge . 94
D.4 Analyse des valeurs aux limites . 94
D.5 Rattrapage par régression . 95
D.6 Schémas de cause et de conséquence . 95
D.7 Listes de contrôle . 95
D.8 Analyse de Flux de Contrôle . 96
D.9 Analyse des défaillances de mode commun . 96
D.10 Analyse du flux de données . 97
D.11 Organigrammes des données . 97
D.12 Enregistrement et analyse des données. 98
D.13 Tables de décision (Tables de vérité) . 99
D.14 Programmation défensive . 99
D.15 Normes de codage et Guide de style. 100
D.16 Programmation diversifiée . 100
D.17 Reconfiguration dynamique . 101
D.18 Tests de classes d'équivalence et de partition d'entrée . 101
D.19 Codes de détection et de correction d'erreurs . 102
D.20 Supposition d'erreurs . 102
D.21 Insertion d'erreurs . 102
D.22 Analyse par arbre des événements . 103
D.23 Inspection de Fagan . 103
D.24 Programmation par assertion des défaillances . 103
D.25 AEEL – Analyse des Effets des Erreurs du Logiciel . 104
D.26 Détection des défauts et diagnostic . 105
D.27 Automates à états finis/Schémas de transitions d'état . 105
D.28 Méthodes formelles . 106
D.28.1 CSP - Processus Séquentiels de Communication . 107
D.28.2 CCS - Algèbre des Systèmes de Transmission . 107
D.28.3 HOL - Logique d'Ordre Supérieur . 107
D.28.4 LOTOS . 108
D.28.5 OBJ . 108
D.28.6 Logique temporelle . 109

D.28.7 VDM - Méthode de Développement de Vienne . 109
D.28.8 Méthode Z . 109
D.28.9 Méthode B . 110
D.28.10Vérification du modèle . 111
D.29 Preuve formelle . 111
D.30 Rattrapage par progression . 112
D.31 Dégradation contrôlée . 112
D.32 Analyse d'impact . 112
D.33 Masquage d'informations/Encapsulation . 113
D.34 Tests d'interface. 113
D.35 Sous-ensemble de langage . 114
D.36 Mémorisation des cas exécutés . 114
D.37 Métriques . 114
D.38 Approche modulaire . 115
D.39 Modélisation des performances . 115
D.40 Exigences en matière de performance . 116
D.41 Tests probabilistes . 116
D.42 Simulation de processus . 117
D.43 Prototypage/Anim ation . 118
D.44 Bloc de rattrapage . 118
D.45 Temps de réponse et contraintes de place mémoire . 118
D.46 Rattrapage par ré-exécution . 118
D.47 Sécurité Contrôlée . 119
D.48 Gestion de la configuration du logiciel . 119
D.49 Langages de programmation à fort typage . 119
D.50 Tests structurels . 120
D.51 Schémas de structure . 120
D.52 Méthodologie structurée . 121
D.53 Programmation structurée . 121
D.54 Langages de programmation adaptés . 122
D.55 Réseaux de Pétri temporels . 123
D.56 Révisions structurées/ Revues de la conception . 123
D.57 Programmation orientée objet . 124
D.58 Traçabilité . 124
D.59 Métaprogrammation . 125
D.60 Programmation procédurale . 125
D.61 Graphes séquentiels de fonction . 126
D.62 Schéma à contact . 126
D.63 Diagramme fonctionnel . 126
D.64 Graphe d'états ou Diagramme d'états . 126
D.65 Modélisation de données . 127
D.66 Diagramme de flux de commande/Graphe de flux de commande . 127
D.67 Diagramme de séquence . 128
D.68 Méthodes de spécification en tableaux . 129
D.69 Langage spécifique à l'application . 129
D.70 UML (Unified Modeling Language, langage de modélisation unifié). 129
D.71 Langages spécifiques à un domaine . 130
Bibliographie . 132

- 5 - EN 50128:2011
Avant-propos
La présente Norme Européenne a été préparée par le SC 9XA, Systèmes de signalisation, de
télécommunications et de traitement, du comité technique CENELEC TC 9X, Applications électriques et
électroniques dans le domaine ferroviaire.
Le texte du projet a été soumis au vote formel et a été approuvé par le CENELEC comme EN 50128 le
2011-04-25.
Ce document remplace l'EN 50128:2001.
Les principales modifications par rapport à l'EN 50128:2001 sont énumérées ci-après :
• des exigences relatives à la gestion et à l'organisation, à la définition des rôles et des compétences, au
déploiement et à la maintenance des logiciels ont été ajoutées;
• un nouvel article concernant les outils a été ajouté, fondé sur l'EN 61508-2:2010;
• les Tableaux dans l'Annexe A ont été mis à jour.
L'attention du lecteur est attiré sur la possibilité que certains éléments de ce document peuvent être couverts
par des brevets. Le CEN et le CENELEC ne sauraient être tenus pour responsable de l'identification de tels
brevets.
Les dates suivantes ont été fixées:
– date limite à laquelle l'EN doit être mise en application au

niveau national par publication d'une norme nationale

identique ou par entérinement
(dop) 2012-04-25
– date limite à laquelle les normes nationales conflictuelles
2014-04-25
doivent être annulées
(dow)
Il convient de lire la présente Norme Européenne conjointement à l'EN 50126-1:1999 «Applications
ferroviaires - Spécification et démonstration de la fiabilité, de la disponibilité, de la maintenabilité et de la
sécurité (FDMS) - Partie 1 : Exigences de base et procédés génériques» et à l'EN 50129:2003 «Applications
ferroviaires - Systèmes de signalisation, de télécommunications et de traitement - Systèmes électroniques de
sécurité pour la signalisation».
__________
Figures
Figure 1 – Démarche illustrative relative au logiciel. 9
Figure 2 – Illustration de la structure organisationnelle préférentielle . 18
Figure 3 – Cycle de vie de développement 1 . 23
Figure 4 – Illustration d'un cycle de vie de développement 2 . 24
Tableaux
Tableau 1 - Relation entre les classe d'outils et les paragraphes applicables . 38
Tableau A.1– Problèmes liés au cycle de vie et Documentation (5.3) . 68
Tableau A.2 – Spécification des Exigences du Logiciel (7.2) . 70
Tableau A.3 – Architecture du Logiciel (7.3) . 71
Tableau A.4– Conception et mise en œuvre du logiciel (7.4) . 72
Tableau A.5 – Vérification et Tests (6.2 et 7.3) . 73
Tableau A.6 – Intégration (7.6) . 73
Tableau A.7– Tests d'Ensemble du Logiciel (6.2et 7.7) . 73
Tableau A.8 – Techniques d'analyse logicielle (6.3) . 74
Tableau A.9 – Assurance Qualité du logiciel (6.5) . 74
Tableau A.10 – Maintenance du Logiciel (9.2) . 74
Tableau A.11 – Techniques de préparation des données (8.4). 75
Tableau A.12 – Normes de codage . 76
Tableau A.13 – Analyse et Tests dynamiques. 76
Tableau A.14 – Test fonctionnel/boîte noire . 77
Tableau A.15 – Langages de programmation textuels . 77
Tableau A.16 – Langages diagrammatiques pour algorithmes d'application . 78
Tableau A.17 – Modélisation . 78
Tableau A.18 – Tests de Performance . 78
Tableau A.19 – Analyse statique . 79
Tableau A.20 – Composants . 79
Tableau A.21 – Couverture des tests pour le code . 80
Tableau A.22 – Architecture de logiciel orienté objet . 81
Tableau A.23 – Conception détaillée orientée objet . 81
Tableau B.1 — Spécification du Rôle du Gestionnaire des Exigences . 82
Tableau B.2 — Spécification du Rôle du Concepteur . 83
Tableau B.3 — Spécification du Rôle du Réalisateur . 84
Tableau B.4 — Spécification du Rôle du Chargé des tests . 85
Tableau B.5 — Spécification du Rôle du Chargé de vérification . 86
Tableau B.6 — Spécification du Rôle du Chargé d'intégration . 87
Tableau B.7 — Spécification du Rôle du Chargé de Chargé de validation . 88
Tableau B.8 — Spécification du Rôle du Chargé d'évaluation . 89
Tableau B.9 — Spécification du Rôle du Chef de projet . 90
Tableau B.10 — Spécification du Rôle du Gestionnaire de la Configuration . 90
Tableau C.1 — Résumé du Contrôle des Documents . 91

- 7 - EN 50128:2011
Introduction
La présente Norme Européenne fait partie intégrante d'un groupe de normes connexes. Les autres
documents de ce groupe sont les EN 50126-1:1999 «Applications ferroviaires - Spécification et
démonstration de la fiabilité, de la disponibilité, de la maintenabilité et de la sécurité (FDMS) –
Partie 1 : Exigences de base et procédés génériques» et EN 50129:2003 «Applications ferroviaires -
Systèmes de signalisation, de télécommunications et de traitement - Systèmes électroniques de sécurité
pour la signalisation».
L'EN 50126-1 traite des systèmes au niveau le plus général, tandis que l'EN 50129 traite des processus
d'approbation des systèmes individuels qui peuvent exister dans le cadre du système ferroviaire global de
contrôle-commande et de protection. La présente Norme Européenne traite en particulier des méthodes qu'il
est nécessaire d'utiliser pour fournir des logiciels répondant aux exigences d'intégrité de la sécurité imposées
par ces considérations plus larges.
La présente Norme Européenne fournit un ensemble d'exigences que le développement, le déploiement et la
maintenance de tout logiciel de sécurité destiné aux applications ferroviaires de contrôle-commande et de
protection doivent respecter. Elle définit les exigences concernant la structure organisationnelle, la relation
entre organisations et la répartition des responsabilités impliquées dans les activités de développement, de
déploiement et de maintenance. Des critères de qualification et d'expertise du personnel sont également
fournis dans la présente Norme Européenne.
Le concept clé de la présente Norme Européenne est celui des niveaux d'intégrité de la sécurité logicielle. La
présente Norme Européenne traite de cinq niveaux d'intégrité de sécurité logicielle dans lesquels 0
correspond au niveau le plus bas et 4 au niveau le plus élevé. Plus le risque résultant d'une défaillance
logicielle est élevé, plus le niveau d'intégrité de la sécurité logicielle est élevé.
La présente Norme Européenne a identifié des techniques et mesures applicables aux cinq niveaux
d'intégrité de la sécurité logicielle. Les techniques et mesures requises pour les niveaux 0 à 4 d'intégrité de la
sécurité logicielle sont indiquées dans les tableaux de l'Annexe A (normative). Dans la présente version, les
techniques requises pour le niveau 1 sont identiques à celles du niveau 2, et les techniques requises pour le
niveau 3 sont identiques à celles du niveau 4. La présente Norme Européenne ne fournit aucune ligne
directrice sur le niveau d'intégrité logicielle approprié pour un risque donné. Cette décision sera tributaire de
nombreux facteurs, notamment de la nature de l'application, de la limite dans laquelle les autres systèmes
assurent des fonctions de sécurité, ainsi que de facteurs socio-économiques.
Le processus de spécification des fonctions de sécurité allouées au logiciel fait partie du domaine
d'application des normes EN 50126-1 et EN 50129.
La présente Norme Européenne spécifie les mesures nécessaires au respect de ces exigences.
Les EN 50126-1 et EN 50129 exigent qu'une approche systématique soit adoptée en ce qui concerne :
a) l'identification des situations dangereuses, l'évaluation des risques et la prise de décisions en fonction de
critères de risque,
b) l'identification de la réduction des risques nécessaire au respect des critères d'acceptation de risque;
c) la définition d'une Spécification des Exigences de Sécurité du Système, globale, qui décrit les protections
indispensables en vue d'atteindre la réduction des risques requise,
d) le choix d'une architecture système adaptée,
e) la planification, le contrôle et la maîtrise des activités techniques et de management nécessaires pour
transformer la Spécification des exigences de sécurité du système en un Système de sécurité dont
l'intégrité de la sécurité est validée.
Au fur et à mesure que la spécification se décompose en une conception comprenant des composants et
des systèmes de sécurité, l'allocation des niveaux d'intégrité de la sécurité est effectuée. Finalement ceci
conduit aux niveaux d'intégrité de la sécurité logicielle requis.

L'état actuel de la technique est tel que ni l'application des méthodes d'assurance qualité (mesures
d'évitement des défauts et mesures de détection des défauts), ni l'application d'approches logicielles à
tolérance aux pannes ne peuvent garantir la sécurité absolue du logiciel. Il n'existe aucun moyen connu de
prouver l'absence de défauts dans un logiciel de sécurité même raisonnablement complexe, en particulier
l'absence de défauts de spécification et de conception.
Les principes appliqués dans le développement de logiciels à haute intégrité incluent, sans s'y limiter :
– des méthodes de conception descendante,
– la modularité,
– la vérification de chaque phase du cycle de vie du développement,
– des composants vérifiés et des bibliothèques de composants,
– une documentation claire et la traçabilité,
– des documents aptes à être audités,
– la validation,
– l'évaluation,
– la gestion de configuration et le contrôle des modifications, et
– l'étude appropriée des questions de compétence de l'organisation et du personnel.
La Spécification des exigences de sécurité du système identifie toutes les fonctions de sécurité allouées au
logiciel et détermine leur niveau d'intégrité de la sécurité du système. Les étapes fonctionnelles successives
de l'application de la présente Norme Européenne sont montrées à la Figure 1 et consistent à :
a) définir la Spécification des Exigences du Logiciel et, en parallèle, considérer l'architecture du logiciel. La
stratégie de sécurité pour le logiciel et le niveau d'intégrité de la sécurité logicielle (7.2 et 7.3) sont
développés dans l'architecturedu logiciel;
b) concevoir, développer et tester le logiciel selon le Plan d'Assurance Qualité du Logiciel, le niveau
d'intégrité de la sécurité logicielle et le cycle de vie du logiciel (7.4 et 7.5);
c) intégrer le logiciel sur le matériel cible et vérifier la fonctionnalité (7.6);
d) accepter et déployer le logiciel (7.7 et 9.1);
e) si la maintenance du logiciel est requise pendant la vie opérationnelle, réactiver le cas échéant la présente
Norme Européenne (9.2).
Un certain nombre d'activités se déroulent pendant le développement du logiciel, parmi lesquelles les tests
(6.1), la vérification (6.2), la validation (6.3), l'évaluation (6.4), l'assurance qualité (6.5) et le contrôle des
modifications et des évolutions (6.6).
Des exigences sont données en ce qui concerne les outils (6.7) et les systèmes qui sont configurés par des
données d'application ou par des algorithmes d'application (8).
Des exigences sont également fournies en ce qui concerne l'indépendance des rôles et la compétence du
personnel impliqué dans le développement du logiciel (5.1, 5.2 et Annexe B).
La présente Norme n'impose pas l'utilisation d'un cycle de vie spécifique de développement du logiciel.
Cependant des ensembles illustratifs de cycle de vie et de documentation sont fournis en 5.3, Figure 3,
Figure 4 et en 7.1.
Des tableaux ont été établis pour classer diverses techniques/mesures par rapport aux niveaux 0 à 4
d'intégrité de la sécurité logicielle. Les tableaux sont dans l'Annexe A. En référence croisée avec les
tableaux, la bibliographie fournit une brève description de chaque technique/mesure avec des références à
des sources complémentaires d'informations. La Bibliographie de techniques est dans l'Annexe D.

- 9 - EN 50128:2011
Obtenir la Spécification des Exigences du
Système, la Spécification des Exigences de
Sécurité du Système, la Description de
l'Architecture du Système et le Plan de Sécurité
du Système pour le Système
Identifier toutes les fonctions de sécurité
allouées au logiciel
Examiner toutes les fonctions de sécurité
allouées au logiciel et déterminer le niveau
d'intégrité de la sécurité logicielle
Produire les Spécifications des Exigences du
Logiciel et la Spécification de l'Architecture du
Logiciel
Concevoir, développer et vérifier/tester le
logiciel conformément au Plan d’Assurance
Qualité du Logiciel, au niveau d'intégrité de la
sécurité logicielle et au cycle de vie du logiciel
Effectuer la validation du logiciel et la
transmettre aux ingénieurs système
Système en service
Maintenance du logiciel
Figure 1 – Démarche illustrative relative au logiciel

1 Domaine d'application
1.1 La présente Norme Européenne spécifie les exigences de processus et les techniques applicables au
développement de logiciel pour des systèmes électroniques programmables utilisés dans les applications
ferroviaires de contrôle-commande et de protection. Elle est destinée à être utilisée dans tout domaine
comportant des implications de sécurité. Ces systèmes peuvent être mis en œuvre à l'aide de
microprocesseurs dédiés, de contrôleurs logiques programmables, de systèmes multiprocesseurs distribués,
de grands systèmes dotés d'un calculateur central ou à l'aide d'autres architectures.
1.2 La présente Norme Européenne est exclusivement applicable au logiciel et à l'interaction entre le logiciel
et le système auquel il appartient.
1.3 La présente Norme Européenne n'est pas pertinente pour les logiciels qui ont été identifiés comme
n'ayant aucun impact sur la sécurité, c'est-à-dire pour les logiciels dont les défaillances ne peuvent pas
affecter de fonctions de sécurité identifiées.
1.4 La présente Norme Européenne s'applique à tous les logiciels de sécurité utilisés dans des systèmes de
contrôle-commande et de protection du ferroviaire, y compris :
– la programmation d'applications,
– les systèmes d'exploitation,
– les outils,
– les microprogrammes.
La programmation d'applications inclut la programmation de haut niveau, la programmation de bas niveau et
la programmation spécifique personnalisée (par exemple : la logique à contacts d'un contrôleur logique
programmable).
1.5 La présente Norme Européenne traite également de l'utilisation de logiciels et d'outils préexistants. Ces
logiciels peuvent être utilisés si les exigences spécifiques en 7.3.4.7 et 6.5.4.16 relatives aux logiciels
préexistants et aux outils 6.7 sont satisfaites.
1.6 Un logiciel développé selon une version quelconque de la présente Norme Européenne sera considéré
conforme et non soumis aux exigences relatives aux logiciels préexistants.
1.7 La présente Norme Européenne considère que la conception moderne d'applications utilise
fréquemment des logiciels génériques qui conviennent comme base pour diverses applications. Ces logiciels
génériques sont ensuite configurés par des données et/ou des algorithmes, afin de produire le logiciel
exécutable pour l'application. Les Articles généraux 1 à 6 et 9 de la présente Norme Européenne s'appliquent
aux logiciels génériques ainsi qu'aux données d'application et algorithmes d'application. L'Article spécifique 7
s'applique uniquement pour les logiciels génériques alors que l'Article 8 fournit les exigences spécifiques
pour les données d'application et algorithmes d'application.
1.8 La présente Norme Européenne ne vise pas les problèmes commerciaux. Il convient toutefois de les
traiter comme une partie essentielle de tout accord contractuel. Il conviendra également que tous les articles
de la présente Norme Européenne soient considérés soigneusement dans toute situation commerciale.
1.9 La présente Norme Européenne n'est pas destinée à être rétroactive. Elle s'applique donc
principalement aux nouveaux développements et n'est applicable dans son intégralité aux systèmes existants
que s'ils font l'objet de modifications importantes. Pour les modifications mineures, seul le paragraphe 9.2
s'applique. Le Chargé d'évaluation doit analyser les preuves fournies dans la documentation du logiciel pour
confirmer si, oui ou non, la détermination de la nature et de l'étendue des modifications du logiciel sont
adéquates. Cependant, il est hautement recommandé d'appliquer la présente Norme Européenne pendant
les mises à niveau et la maintenance des logiciels existants.

- 11 - EN 50128:2011
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).

EN 50126-1:1999 Applications ferroviaires - Spécification et démonstration de la fiabilité, de la
disponibilité, de la maintenabilité et de la sécurité (FDMS) - Partie 1 : Exigences de
base et procédés génériques
EN 50129:2003 Applications ferroviaires - Systèmes de signalisation, de télécommunications et de
traitement - Systèmes électroniques de sécurité pour la signalisation
EN ISO 9000 Systèmes de management de la qualité - Principes essentiels et vocabulaire
(ISO 9000:2005)
EN ISO 9001 Systèmes de management de la qualité - Exigences (ISO 9001:2008)
ISO/CEI 90003:2004 Ingénierie du logiciel – Lignes directrices pour l'application de l'ISO 9001:2000 aux
logiciels informatiques
Série ISO/CEI 9126 Génie du logiciel -- Qualité des produits
3 Termes, définitions et abréviations
3.1 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1.1
évaluation
processus d'analyse afin de déterminer si un logiciel, qui peut inclure des processus, de la documentation,
des composants logiciels et/ou matériels de systèmes et sous-systèmes, satisfait aux exigences spécifiées
et afin de formuler un jugement sur le fait que le logiciel répond à l'objectif attendu. L'évaluation de la sécurité
est une évaluation axée sur les propriétés de sécurité d'un système, mais sans s'y limiter
3.1.2
chargé d'évaluation
entité qui mène à bien une évaluation
3.1.3
logiciel standard disponible dans le commerce (COTS, en anglais commercial off-the-shelf software)
logiciel défini par les besoins du marché, disponible dans le commerce et dont l'adéquation aux besoins a été
démontrée par un large éventail d'utilisateurs
3.1.4
composant
partie constitutive de logiciel qui a des interfaces et un comportement bien définis par rapport à la conception
et à l'architecture du logiciel et satisfait aux critères suivants :
– elle est conçue conformément à “Composants” (voir Tableau A.20);
– elle couvre un sous-ensemble spécifique des exigences relatives au logiciel;
– elle est clairement identifiée et a une version indépendante au sein du système de gestion de
configuration ou est une partie d'un ensemble de composants (par exemple : sous-systèmes) qui ont
une version indépendante
3.1.5
gestionnaire de la configuration
entité qui est chargée de mettre en œuvre et d'exécuter les processus pour la gestion de configuration des
documents, logiciels et outils connexes, y compris la gestion des modifications et des évolutions
3.1.6
client
entité qui achète un système de contrôle-commande et de protection du ferroviaire comprenant le logiciel
3.1.7
concepteur
entité qui analyse et transforme des exigences spécifiées en solutions de conception acceptables qui ont le
niveau prescrit d'intégrité de la sécurité
3.1.8
...