BS EN 50128-2001 铁路应用　通信、信号传输和处理系统　铁路控制和保护系统软件.pdf

《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) BSIBS EN 50128:2001 This British Standard, having been prepared under the direction of the Electrotechnical Sector Committee, was published unde

3、r 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, Railwa

4、y 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 Euro

5、pean 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 nece

6、ssary 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 enquiries on

7、 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 cover.

8、The BSI copyright date displayed in this document indicates when the document was last issued. Amendments issued since publication Amd. No. Date Comments Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSIEUROPEAN S

9、TANDARD EN 50128 NORME EUROPENNE EUROPISCHE NORM March 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 r

10、ights 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 ferroviair

11、es 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 was

12、 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 such

13、 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 la

14、nguage 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, Portugal

15、, 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) BSIPage 2 EN 50128:2001 BSI 05-2001 Foreword This European Standard was prepared by SC 9XA, Communication, signalling

16、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 impl

17、emented 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 applicat

18、ions 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) BSIPage 3 EN 50128:2001 BSI 05-2001 Contents Pages Introduction 5 1 Scope

20、7 2 Normative references . 7 3 Definitions . 8 4 Objectives and conformance 11 5 Software safety integrity levels 12 5.1 Objective. 12 5.2 Requirements . 12 6 Personnel and responsibilities 13 6.1 Objective. 13 6.2 Requirements . 13 7 Life cycle issues and documentation 15 7.1 Objectives . 15 7.2 Re

21、quirements . 15 8 Software Requirements Specification. 18 8.1 Objectives . 18 8.2 Input documents . 18 8.3 Output documents 18 8.4 Requirements . 18 9 Software architecture 20 9.1 Objectives . 20 9.2 Input documents . 20 9.3 Output documents 20 9.4 Requirements . 20 10 Software design and implementa

22、tion 21 10.1 Objectives . 21 10.2 Input documents . 22 10.3 Output documents 22 10.4 Requirements . 22 11 Software verification and testing. 25 11.1 Objective. 25 11.2 Input documents . 25 11.3 Output documents 25 11.4 Requirements . 25 12 Software/hardware integration 28 12.1 Objectives . 28 12.2 I

23、nput documents . 28 12.3 Output documents 29 12.4 Requirements . 29 Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSIPage 4 EN 50128:2001 BSI 05-2001 13 Software validation 30 13.1 Objective. 30 13.2 Input documen

24、ts . 30 13.3 Output documents 30 13.4 Requirements . 30 14 Software assessment . 32 14.1 Objective. 32 14.2 Input documents . 32 14.3 Output documents 32 14.4 Requirements . 32 15 Software quality assurance. 33 15.1 Objectives . 33 15.2 Input documents . 33 15.3 Output documents 33 15.4 Requirements

25、 . 33 16 Software maintenance 35 16.1 Objective. 35 16.2 Input documents . 35 16.3 Output documents 36 16.4 Requirements . 36 17 Systems configured by application data . 37 17.1 Objectives . 37 17.2 Input documents . 37 17.3 Output documents 37 17.4 Requirements . 38 17.4.1 Data preparation life cyc

26、le 38 17.4.2 Data preparation procedures and tools 38 17.4.3 Software development 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 sa

27、fety route map 41 Figure 3 Development life cycle 1 . 42 Figure 4 Development 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

28、of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSIPage 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, Maintainab

29、ility 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 sy

30、stem. 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 w

31、ork of WG 9 resulted in a generic standard for software for safety systems 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

32、 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 Europea

33、n Standard 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

34、 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

35、 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 s

36、ame 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

37、 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 appro

38、ach be taken to: i) identifying hazards, risks and risk criteria; ii) identifying 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 sy

39、stem 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 de

40、sign 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-ca

41、lled fault avoiding measures) nor the application of software fault tolerant 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. Lice

42、nsed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSIPage 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; v

43、erification of each phase of the development life cycle; verified modules 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 eac

44、h software safety integrity level. 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 functional steps in the application of this European Standard are sh

45、own 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 9); ii) des

46、ign, develop and test the software according to the Software Quality Assurance 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

47、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 confi

48、gured 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 life cycle. However, a recommended life cycle and documentation set are given (clause

49、 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. Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Sat May 12 17:25:56 GMT+00:00 2007, Uncontrolled Copy, (c) BSIPage 7 EN 50128:2001