EN50128 2001

3 EN50128:2001 Contents Pages Introduction cope 2Normativereferences.wwwwwwwwwwnnwww.7 3 Definitions 4 Objectives and conformance 11 5 Software safety integrity levels 5. 1 objective 5.2 Requirements 12 6 Personnel and responsibilities 13 6. 1 Objective 面面自面面面面面面面 6.2 Requirements 13 7 Lifecycle issues and documentation 14 1 Objectives 7.2 Requirements 14 8 Software requirements specification 17 8.1 Objectives 8.2 Input documents 8.3 Output documents 17 8.4 Requirements 17 9 Software architecture 9.1 Objectives 18 9.2 Input do 19 9.3 Output documents 9.4 Requirements 10 Software design and implementation 10.1 Objectives.... 10.2 Input documents 10.3 Output documents 10.4 Requirements 11 Software verification and testing 24 11.1 Objective..... 11.2 Input documents 24 11.3 Output documents.. 11.4 Requirements 24 12 Software/hardware integration 12.1 Objectives 27 12.2 Input documents 27 12.3 Output documents 28 12.4 Requirements EN50128:2001 4 13 Software validation 29 13. 1 Objective 29 13.2 Input documents 29 13.3 Output documents 29 13.4 Requirements 29 14 Software assessment 14.1 Objective................,,,......31 14.2 Input documents 31 14.3 Output documents 31 14.4 Requirements 31 15 Software quality assurance 15. 1 Objectives 15.2 Input documents 15.3 Output documents............... 15.4 Requirements.......... 16 Software maintenance 34 16.1 Objective 34 16.2 Input documents ∴34 6.3 Output documents 16.4 Requirements 5 17 Systems configured by application data 17.1 Objectives 17.2| nput documents....................36 17.3 Output documents.......... 17.4 Requirements 面面面面面面 37 17.4.1 Data Preparation Lifecycle....... 37 17.4.2 Data Preparation procedures and Tools 37 174.3 Software Development...........38 Annex A(normative) Criteria for the Selection of Techniques and measures 5 Annex b(informative Bibliography of Techniques 60 iqures e 1- Integrity Levels for Safety-Related Systems Figure 2- Software Safety Route Map Figure 3- Development Lifecycle 1 Figure 4-Development Lifecycle 2 2 Figure 5-Independence Versus Software Integrity Level 43 Figure 6- Relationship between Generic System Development and Application Development 5 EN50128:2001 Introduction This Standard is part of a group of related Standards. The others are en 50126"Railway applications The specification and demonstration of Reliability, Availability, Maintainability and Safety(RAMS)and EN 50129"Railway applications- Safety related electronic systems for signalling". EN 50126 addresses system issues on the widest scale, while EN 50129 addresses the approval process for individual systems which may exist within the overall railway control and protection system. This 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 Standard owes much of its direction to earlier work done by Working Group 9 of IEC/TC 65. The ork of wG 9 resulted in a generic standard for software for safety systems which is now part of lEC 61508. A particular aspect of the work by WG 9 is its inclusion of Software Integrity Level 0, which covers non-safety software, as well as Software Integrity Levels 1 to 4, which cover safety-related and safety-critical software. This standard also covers all five Software Integrity Levels Account has also been taken of the work of the Institution of Railway Signal Engineers(the IRSE), in particular its Technical Report Number 1, which addressed the same topic The key concept of this European Norm is that of levels of software safety integrity. The more dangerous the consequences of a software failure the higher the software safety integrity level will be This European Standard has identified techniques and measures for 5 levels of software safety integrity Where 0 is the minimum level and 4 the highest level. Four of these levels, 1 to 4, refer to safety-related software, whilst level 0 refers to non safety-related software. this level has been included as normative in order to allow a smooth transition between software developments for non-safety related systems and those for safety-related systems. The required techniques and measures for each software safety integrity level and for the non safety-related level are shown in the tables. 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 integrity is appropriate for a given risk. This decision will depend upon the 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 the function of EN 50126 and EN 50129 to specify the safety functions allocated to software This European Standard specifies those measures necessary to achieve these requirements. The process is illustrated in Figure 1 EN 50126 and En 50129 require that a systematic approach be taken to identifying hazards, risks and risk criteria identifying the necessary risk reduction to meet the risk criteria defining an overall System Safety Requirements Specification for the safeguards necessary to achieve the required risk reduction iv) selecting a suitable system architecture v) planning, monitoring and controlling the technical and managerial activities necessary to translate the System Safety Requirements Specification into a Safety-Related System of a validated safety performance(or 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) nor the application of software fault tolerant approaches can guarantee the EN50128:2001 6- bsolute safety of the system. 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 modules and module libraries. c| ear documentation auditable documents and validation testing These and related principles must be correctly applied. This standard specifies the level of assurance required to demonstrate this at each software safety integrity leve After the System Safety Requirements Specification, which identifies all safety functions allocated to software and determines the system safety integrity level, has been obtained or produced, the functiona steps in the application of this european standard are shown in Figure 2 and are as follows i) define the Software Requirements Specification and in parallel consider the software architecture the software architecture is where the basic safety strategy is developed for the software and the software safety integrity level (clauses 5, 8 and g) level and the software lifecycle (clause 10 oftware Quality Assurance Plan, software ldesign, develop and test the software according to the so safety integrity integrate the software on the target hardware(clause 12) )validate the software( clause 13) v) if software maintenance is required during operational life then re-activate this european standard as appropriate(clause 16) A number of activities run across the software development. These include verification (clause 11) assessment(clause 14)and quality assurance(clause 15) Requirements are given for systems which are configured by application data( clause 17) Requirements are also given for the competency of staff involved in software development (clause 6) The standard does not mandate the use of a particular software development lifecycle. However a ecommended lifecycle and documentation set are given(clause 7 and Figures 3 and 4) Tables have been formulated ranking various techniques/measures against the 5 software safety integrity levels. 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 is in annex B 7 EN50128:2001 Scope This European Standard specifies procedures and technical requirements for the development of 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 may range from the very critical, such as safety signalling to the non-critical, such as management information systems. These systems may be implemented using dedicated microprocessors, programmable logic controllers, multiprocessor distributed systems, larger scale central processor systems or other architectures This European Standard is applicable exclusively to software and the interaction between software and the system of which it is part 1.3 Software safety integrity levels above zero are for use in systems in which the consequences of failure could include loss of life. Economic or environmental considerations, however, may also justify the use of higher software safety integrity levels This European Standard applies to all software used in development and implementation of 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 The use of standard, commercially available software and tools is also addressed in this European standard This European Standard also addresses the requirements for systems configured by application data 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 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 clause 16 applies 2 Normative references This European Standard incorporates by dated or undated reference, provisions from other publications These normative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this european Standard only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies(including amendments) EN50126 Railway applications- The specification and demonstration of Reliability, Availability Maintainability and safety rams) EN50129 Railway applications- Safety related electronic systems for signalling at draft stage EN50128:2001 EN50159-1 Railway applications-Communication, signalling and processing systems Part 1: Safety-related communication in closed transmission systems EN50159-2 Railway applications -Communication, signalling and processing systems Part 2: Safety-related communication in open transmission systems EN ISo 9001 Quality systems-Model for quality assurance in design/development, production stallation and servicing EN ISo 9000-3 Quality management and quality assurance standards-Part 3: Guidelines for the application of Iso 9001: 1994 to the development, supply, installation and maintenance of computer software Definitions For the purposes of this European Standard, the following definitions apply. For terms not defined here the following references should be consulted in order of priority EN SO 8402 Quality management and quality assurance- Vocabulary lEC 60050-191 Intenational Electrotechnical Vocabulary of Chapter 191: Dependability and quality of service IEEE 610. 12 IEEE standard glossary of software engineering terminology ISO/EC 2382 Information Technology Vocabulary ISo/EC 9126 Information Technology- Software Product Evaluation -Quality characteristics and guidelines for their use 3.1 assessment process of analysis to determine whether the Design Authority and the validator have achieved a product that meets the specified requirements and to form a judgement as to whether the product is fit for its intended purpose 3.2 assessor person or agent appointed to carry out the assessment 3.3 availability ability of a product to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming the required external resources are provided 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.5 design authority body responsible for the formulation of a design solution to fulfil the specified requirements and fo overseeing the subsequent development and setting to work of a system in its intended environment for 3.6 designer one or more persons assigned by the Design authority to analyse and transform specified requirements into acceptable design solutions which have the required safety integrity 9 EN50128:2001 37 element part of a product that has been determined to be a basic unit or building block. An element may be simple or complex 3.8 error deviation from the intended design which could result in unintended system behaviour or failure 3.9 failure deviation from the specified performance of a system. A failure is the consequence of a fault or error in a system 3.10 fault abnormal condition that could lead to an error or a failure in a system. A fault can be random or systematic 3.11 fault avoidance use of design techniques which aim to avoid the introduction of faults during the design and construction of the system 3.12 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.13 firmware ordered set of instructions and associated data stored in a way that is functionally independent of main storage, usually in a ROm 3.14 generic software generic software is software which can be used for a variety of installations purely by the provision of application-specific data 3.15 implementer one or more persons assigned by the Design Authority to transform specified designs into their physica realisation 3.16 product collection of elements, interconnected to form a system, sub-system or item of equipment, in a manner which meets the specified requirements. In this European Standard, a product may be considered to consist entirely of elements of software or documentation 3.17 programmable logic controller (PLC) solid-state control system which has a user programmable memory for storage of instructions to implement specific functions 3.18 reliability ability of an item to perform a required function under given conditions for a given period of time EN50128:2001 10 requirements traceability objective of requirements traceability is to ensure that all requirements can be shown to have been properly met 3.20 risk combination of the frequency, or probability, and the consequence of a specified hazardous event 3.21 safet Freedom from unacceptable levels of risk 3.22 safety authority body responsible for certifying that the safety-related system is fit for service and complies with relevant statutory and regulatory safety requirements 3.23 safety-related software software which carries responsibility for safety 3.24 software intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system Note Software is independent of the media used for trans port 325 software life-cycle activities occurring during a period of time that starts when software is conceived and ends when th software is no longer available for use. The software lifecycle typically includes a requirements phase, development phase, test phase, integration phase, installation phase and a maintenance phase 326 software maintainability capability of a system to be modified to correct faults, improve performance or other attributes, or adapt it to a different environment 3.27 software maintenance Action, or set of actions, carried out on software after its acceptance by the final user. The aim is to improve, increase and/or correct its functionality 3.28 software safety integrity level classification number which determines the techniques and measures that have to be applied in order to reduce residual software faults to an appropriate level system safety integrity level number which indicates the required degree of confidence that a system will meet its specified safety features 3.30 traceability degree to which a relationship can be established between two or more products of a development process, especially those having a predecessor/successor or master/subordinate relationship to one another