《BS EN 50128-2001 铁路应用 通信、信号传输和处理系统 铁路控制和保护系统软件.pdf》由会员分享，可在线阅读，更多相关《BS EN 50128-2001 铁路应用 通信、信号传输和处理系统 铁路控制和保护系统软件.pdf（108页珍藏版）》请在三一文库上搜索。
1、BRITISH STANDARD BS EN 50128:2001 Railway applications Communications, signalling and processing systems Software for railway control and protection systems The European Standard EN 50128:2001 has the status of a British Standard ICS 35.240.60; 45.020 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERM
2、ITTED BY COPYRIGHT LAW Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI BS EN 50128:2001 This British Standard, having been prepared under the direction of the Electrotechnical Sector Committee, was published und
3、er the authority of the Standards Committee and comes into effect on 15 May 2001 BSI 05-2001 ISBN 0 580 37584 6 National foreword This British Standard is the official English language version of EN 50128:2001. The UK participation in its preparation was entrusted by Technical Committee GEL/9, Railw
4、ay electrotechnical applications, to Subcommittee GEL/9/1, Signalling and communications, which has the responsibility to: A list of organizations represented on this subcommittee can be obtained on request to its secretary. Cross-references The British Standards which implement international or Eur
5、opean publications referred to in this document may be found in the BSI Standards Catalogue under the section entitled “ International Standards Correspondence Index” , or by using the “ Find” facility of the BSI Standards Electronic Catalogue. A British Standard does not purport to include all the
6、necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations. aid enquirers to understand the text; present to the responsible European committee any enquirie
7、s on the interpretation, or proposals for change, and keep the UK interests informed; monitor related international and European developments and promulgate them in the UK. Summary of pages This document comprises a front cover, an inside front cover, the EN title page, pages 2 to 105 and a back cov
8、er. The BSI copyright date displayed in this document indicates when the document was last issued. Amendments issued since publication Amd. No. DateComments Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI EUROPE
9、AN STANDARDEN 50128 NORME EUROPENNE EUROPISCHE NORMMarch 2001 CENELEC European Committee for Electrotechnical Standardization Comit Europen de Normalisation Electrotechnique Europisches Komitee fr Elektrotechnische Normung Central Secretariat: rue de Stassart 35, B - 1050 Brussels 2001 CENELEC -All
10、rights of exploitation in any form and by any means reserved worldwide for CENELEC members. Ref. No. EN 50128:2001 E ICS 29.280; 45.060.10 English version Railway applications Communications, signalling and processing systems Software for railway control and protection systems Applications ferroviai
11、res Systmes de signalisation, de tlcommunication et de traitement Logiciels pour systmes de commande et de protection ferroviaire Bahnanwendungen Telekommunikationstechnik, Signal- technik und Datenverarbeitungssysteme Software fr Eisenbahnsteuerungs- und berwachungssysteme This European Standard wa
12、s approved by CENELEC on 2000-11-01. 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 suc
13、h 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 l
14、anguage and notified to the Central Secretariat has the same status as the official versions. CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portuga
15、l, Spain, Sweden, Switzerland and United Kingdom. Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI Page 2 EN 50128:2001 BSI 05-2001 Foreword This European Standard was prepared by SC 9XA, Communication, signallin
16、g and processing systems, of Technical Committee CENELEC TC 9X, Electrical and electronic applications for railways. The text of the draft was submitted to the formal vote and was approved by CENELEC as EN 50128 on 2000- 11-01. The following dates were fixed: latest date by which the EN has to be im
17、plemented at national level by publication of an identical national standard or by endorsement(dop)2001-11-01 latest date by which the national standards conflicting with the EN have to be withdrawn(dow)2003-11-01 This European Standard should be read in conjunction with EN 50126, Railway applicatio
18、ns The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) and EN 50129, Railway applications Safety related electronic systems for signalling. Annexes designated “ normative” are part of the body of the standard. Annexes designated “ informative” are give
19、n for information only. In this standard, annex A is normative and annex B is informative. _ Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI ? Page 3 EN 50128:2001 BSI 05-2001 Contents Pages Introduction 5 1Scop
20、e 7 2Normative references . 7 3Definitions. 8 4Objectives and conformance 11 5Software safety integrity levels 12 5.1Objective. 12 5.2Requirements . 12 6Personnel and responsibilities 13 6.1Objective. 13 6.2Requirements . 13 7Life cycle issues and documentation 15 7.1Objectives. 15 7.2Requirements .
21、 15 8Software Requirements Specification. 18 8.1Objectives. 18 8.2Input documents. 18 8.3Output documents 18 8.4Requirements . 18 9Software architecture 20 9.1Objectives. 20 9.2Input documents. 20 9.3Output documents 20 9.4Requirements . 20 10Software design and implementation 21 10.1Objectives. 21
22、10.2Input documents. 22 10.3Output documents 22 10.4Requirements . 22 11Software verification and testing. 25 11.1Objective. 25 11.2Input documents. 25 11.3Output documents 25 11.4Requirements . 25 12Software/hardware integration 28 12.1Objectives. 28 12.2Input documents. 28 12.3Output documents 29
23、12.4Requirements . 29 Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI ? Page 4 EN 50128:2001 BSI 05-2001 13Software validation 30 13.1Objective. 30 13.2Input documents. 30 13.3Output documents 30 13.4Requirement
24、s . 30 14Software assessment . 32 14.1Objective. 32 14.2Input documents. 32 14.3Output documents 32 14.4Requirements . 32 15Software quality assurance. 33 15.1Objectives. 33 15.2Input documents. 33 15.3Output documents 33 15.4Requirements . 33 16Software maintenance 35 16.1Objective. 35 16.2Input do
25、cuments. 35 16.3Output documents 36 16.4Requirements . 36 17Systems configured by application data . 37 17.1Objectives. 37 17.2Input documents. 37 17.3Output documents 37 17.4Requirements . 38 17.4.1Data preparation life cycle 38 17.4.2Data preparation procedures and tools 38 17.4.3 Software develop
26、ment 39 Annex A (normative) Criteria for the selection of techniques and measures 46 Annex B (informative) Bibliography of techniques 61 Figures Figure 1 Integrity levels for safety-related systems . 40 Figure 2 Software safety route map 41 Figure 3 Development life cycle 1 . 42 Figure 4 Development
27、 life cycle 2 . 43 Figure 5 Independence versus Software Integrity Level 44 Figure 6 Relationship between generic system development and application development 45 Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI
28、 ? Page 5 EN 50128:2001 BSI 05-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
29、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 o
30、rder 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 work of WG 9 resulted in a generic standard for software for safety systems
31、 which is now part of IEC 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
32、 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 Standard is that of levels of software safety integrity. The more danger
33、ous 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 saf
34、ety-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
35、 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
36、 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
37、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: i) identifying hazards, risks and risk criteria; ii) iden
38、tifying the necessary risk reduction to meet the risk criteria; iii) 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 a
39、nd 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
40、 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 tolera
41、nt approaches can guarantee the absolute 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. Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat
42、May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI ? Page 6 EN 50128:2001 BSI 05-2001 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 life cycle; verified modul
43、es and module libraries; clear 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 level. After the System Safety Requirements
44、 Specification, which identifies all safety functions allocated to software and determines the system safety integrity level, has been obtained or produced, the functional steps in the application of this European Standard are shown in Figure 2 and are as follows: i) define the Software Requirements
45、 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 9); ii) design, develop and test the software according to the Software Quality As
46、surance Plan, software safety integrity level and the software life cycle (clause 10); iii) integrate the software on the target hardware (clause 12); iv) validate the software (clause 13); v) if software maintenance is required during operational life then re-activate this European Standard as appr
47、opriate (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
48、the competency of staff involved in software development (clause 6). The standard does not mandate the use of a particular software development life cycle. However, a recommended life cycle and documentation set are given (clause 7 and Figures 3 and 4). Tables have been formulated ranking various te
49、chniques/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. Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSI ? Page 7 EN 50128:2001 BSI 05-