EN50128中文版.docx

1、EN50128中文版EN 50128 : 2001铁路应用通信、信号和处理系统铁路控制和防护系统软件2007.6序言本欧洲标准是SC 9XA,即通信，信号传输和处理系统技术委员会（CENELEC TC 9X）制订，铁路电气和电子应用的标准。草案文本作为EN 50128正式提交投票并于2000-11-01获得CENELEC批准。修改了下列日期-欧盟各国必须通过认可或发布相同的国家标准来执行本欧洲标准的截止日期 2001 -1 1-01-与本欧洲标准冲突的国家标准必须被废止的截止日期 2003-1 1-01本欧洲标准必须与EN50126铁路应用可靠性，可用性，可维护性和安全性（RAMS）；EN50

2、129铁路应用信号领域的安全相关电子系统同时阅读。附件中指定的“规范性的”是本项标准主体的一部分。附件中指定的“参考性的”只用于获得的信息。本项标准中，附件A是规范性的而附件B是参考性的。目录引言1. 范围2. 参考文献3. 定义4. 目标和符合5. 软件安全完整性等级51目标52需求6. 人员及职责61目标62需求7. 生命周期和文档71目标72需求8. 软件需求规格说明81目标82输入文档83输出文档84需求9. 软件体系结构91目标92输入文档93输出文档94需求10. 软件设计和实现101目标102输入文档103输出文档104需求11. 软件验证和测试111目标112输入文档113输出

3、文档114需求12. 软件/硬件集成121目标122输入文档123输出文档124需求13. 软件确认131目标132输入文档133输出文档134需求14. 软件评估141目标142输入文档143输出文档144需求15. 软件质量保障151目标152输入文档153输出文档154需求16. 软件维护161目标162输入文档163输出文档164需求17. 根据应用数据配置的系统171目标172输入文档173输出文档174需求1741数据准备生命周期1742数据准备程序和工具1743软件开发附件A：技术和措施的选择准则附件B：技术参考书目附图图1安全相关系统的完整性等级图2软件安全性路径图图3开发生命

4、周期1图4开发生命周期2图5独立性与软件完整性等级图6通用系统开发和应用开发之间的关系引言本标准是相关标准系列中的一部分。其他标准有EN50126铁路应用可靠性，可用性，可维护性和安全性（RAMS）；EN50129铁路应用信号领域的安全相关电子系统。EN50126适用于大范围的系统问题，而EN50129适用于整个铁路控制和防护系统中某单个系统的批准过程。本标准关注于需要使用的方法，以使软件能满足经全面考虑后所分配到的安全完整性要求。本标准从IEC/TC65第九工作组（WG9）早期工作中得到很多指导。WG9的工作形成了一个安全系统软件通用标准，现在该标准是IEC61508的一部分。WG9工作的特

5、别之处是包含了适用于非安全软件的软件安全完整性0级，以及适用于安全相关和安全苛求软件的软件安全完整性14级。本标准也覆盖了所有五个软件安全完整性等级。国际铁路信号工程师协会（IRSE）的工作也被考虑进来，特别是它关注相同课题的1号技术报告。本欧洲标准的一个关键概念是软件安全完整性等级。软件失效后果的危险性的越大，软件安全完整性等级也就越高。本欧洲标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中14这四个级别涉及安全相关软件，0级涉及非安全相关软件。对0级进行标准化是为了让非安全相关系统软件向安全相关系统软件进行平滑转变。附表给出了各个软件安全完整性等级和非安全相关等级要

6、求的技术和措施。在这个版本中，1级和2级的技术要求相同，3级和4级的要求相同。本欧洲标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。这个结论需要考虑许多因素包括应用的特性、其他系统承担的安全性功能范围和社会以及经济因素。EN 50126 和EN 50129规定了分配给软件的安全性功能。本欧洲标准规定了满足这些需求的必要措施。这个过程在图1作了说明。EN50126和EN50129需采用系统性的方法，以：1） 确定危险、风险和风险准则；2） 为满足风险准则，确定必要的风险降低；3） 为实现必要的风险降低，定义一个全面的系统安全性需求规格说明；4） 选择一个合适的系统体系结构；5）

7、 规划、监督和控制那些把系统安全性需求规格说明变成安全性能(或安全完整性)已确认的安全相关系统 所必需的技术和管理活动。在分解需求规格说明形成由安全相关系统和组件组成的设计说明时，需要进一步分配安全完整性等级，并最终形成所需的软件安全完整性等级。目前，无论是质量保证法(即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚未发现可以证明一个较复杂的安全相关软件中不存在错误的方法，特别是规格说明和设计的错误。以下规则应用于开发高安全完整性等级软件，但也不仅限于开发高安全完整性等级软件：1） 自顶向下的设计方法；2） 模块化；3） 开发生命周期每一阶段的验证；4） 验证后的模块和模块库；5

8、） 清晰的文档；6） 可审计的文档；7） 确认测试。这些规则以及相关的其他规则必须正确应用。对于各个软件安全完整性等级，本标准均规定了说明这一点所需的保证等级。在得到或形成了系统安全性需求规格说明后，分配给软件的安全性功能和系统安全完整性等级就确定了，图2给出了应用本欧标的功能步骤，如下所示：1） 定义软件需求规格说明，同时考虑软件体系结构。软件体系结构是为软件和软件安全完整性等级开发基本安全策略的架构。(条款5、8和9)2） 根据软件质量保障计划、软件安全完整性等级和软件生命周期来设计、开发和测试软件。(条款10)3） 在目标硬件上集成软件。(条款12) 4） 确认软件。(条款13) 5）

9、如果在运行过程中需要软件维护，那么可再适当运用本欧洲标准进行处理。(条款16)许多活动都是在软件开发过程中交叉进行的，这其中包括验证(条款11)，评估(条款14)和质量保障(条款15)。给出了应用数据配置的系统的需求(条款17)。给出了从事软件开发人员能力的需求。(条款7)本标准没有硬性要求使用特定的软件开发生命周期，但是给出了一个推荐的生命周期及文档集。(条款7，图3和图4)表格针对5个软件安全完整性等级明确罗列了各种技术和措施。表格在附件A中给出。与表格对照的参考书目提供了更多的信息，给出了每项技术和措施的简明描述。参考书目在附件B中给出。1 范围1.1 本欧洲标准详细规定了铁路控制和防护

10、设备用的可编程电子系统开发所需的程序和技术要求。它适用于任何有隐含安全性的领域。这些应用系统的范围涵盖了安全苛求系统,如安全信号，非安全苛求系统,如管理信息系统。这些系统可能通过采用专用多处理器，可编程逻辑控制器，分布式多处理器系统，大规模集中处理器系统或者其它架构来实现。1.2 本欧洲标准专门应用于软件以及软件和系统之间的相互作用。1.3 0级以上的软件安全完整性等级用于失效可引起失去生命的后果的系统。然而，从经济或环境因素方面考虑也能采用高级别的安全完整性等级。1.4 本欧洲标准适用于铁路控制和防护系统开发和实现的所有软件，包括：应用程序设计；操作系统；支持工具；固件。应用程序设计包括高级

11、程序设计，低级程序设计和专用程序设计（如：可编程逻辑控制器梯形逻辑）。1.5 本欧洲标准还涉及了本标准的使用、商用软件和工具。1.6 本欧洲标准还对应用数据配置的系统提出了要求。1.7 本欧洲标准并不涉及商务问题，这些问题应为合同的基本部分被提出。但本欧洲标准中的所有条款在任何商务活动中都需被仔细考虑。1.8 本欧洲标准为避免追溯，主要应用于新的开发。对于现有系统，仅当进行主要修改时才进行全面应用，对于次要修改，只要应用条款16。2 规范性参考文献本欧洲标准需与标注日期或未标注日期的参考文献以及其他出版物中条款相结合。这些规范性参考文献将在文中合适的位置被引用，相应的出版物将在下面列出。对于标

12、注日期文献的后续修改或修订，本欧洲标准需通过修改或修订进行结合来应用。对于未标注日期的文献,则应用最新版本(包括修改)。EN50126，铁路应用可靠性，可用性，可维持性和安全性（RAMS）的规格和说明；EN50129*，铁路应用信号领域的安全相关电子系统；EN50159-1,铁路应用通信，信号和处理系统第一部分：封闭传输系统中的安全通信；EN50129-1,铁路应用通信，信号和处理系统第二部分：开放传输系统中的安全通信；EN ISO 9001,质量体系设计/开发，生产，安装和维护的质量保证模型；EN ISO 9001-3,质量管理和质量保证标准第三部分：ISO9001:1994在计算机软件的开

13、发，供应，安装和维护应用的指导。3 定义以下定义适用于此欧洲标准.对于未定义的术语,按照优先顺序查阅以下参考文献。EN ISO 8402，质量管理和质量保证词汇表；IEC 60050-191,国际电工词汇第191章：服务可信性和质量；IEEE 610.12, IEEE标准软件工程术语词汇表；ISOIIEC 2382,信息技术词汇表；ISOIIEC 9126,信息技术软件产品评估质量特性以及其使用指导；3.1 评估（assessment）用于确定设计主管机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。3.2 评估员（assessor）受委托执行评估的人员或者代理。

14、3.3 可用性（availability）假定所需外部资源均能满足的条件下，产品在规定的条件下，在规定的时刻或在给定的时间间隔内完成要求功能的能力。3.4 商用软件（COTS software）市场需求所定义、市场已存在且其目标满足性已得到广大商业用户证明的软件。3.5 设计主管机构（design authority）负责提出实现特定需求的设计方案，并监控后期的开发和系统在特定环境下工作的实体。3.6 设计者（designer）一个或多个由设计主管机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的设计方案。3.7 元素（element）被确认为基本单元和基本部件的某产

15、品的一部分。一个元素可以是简单或者复杂的。3.8 错误（error）与期望的设计相背离，并有可能导致未预料到的系统行为或失效。3.9 失效（failure）与规定的系统行为相背离。失效是系统错误或故障的结果。3.10 故障（fault）一种能导致系统错误或失效的不正常情形，故障可以是系统性或随机性的。3.11 避错（fault avoidance）在系统设计和构造的过程中使用避免引入故障的设计技术。3.12 容错（fault tolerance）在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力 3.13 固件（firmware）指令和存储在一个功能独立主存储器（通常是

16、ROM）中的相关数据的有序集合3.14 通用软件（generic software）通用软件是只要提供应用相关的数据就可以应用于多种系统装置的软件。3.15 实现人员（implementer）由设计主管机构委派、具体实现特定设计的一个或更多人员3.16 产品（product）为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。本欧洲标准中，产品可被视为完全由软件或者文档元素构成。3.17 可编程逻辑控制器(PLC)具备面向指令存储的用户可编程存储器、能实现轨定功能的固态控制系统。3.18 可靠性(reliability)设备在规定的条件下，在规定的时间内执行要求功能的能力。3.1

17、9 需求可追溯性（requirement traceability）需求可追溯性的目标是确保所有的需求能被证明已得到满足3.20 风险（risk）某特定危险事件的频率或概率和后果的组合。3.21 安全性（safety）无不可接受的风险等级。3.22 安全主管机构（safety authority）负责证实安全相关系统适于工作并符合法令、规章规定的安全性需求的实体。3.23 安全相关软件（safety-related software）负有安全责任的软件。3.24 软件（software）由程序、过程、规则和系统运行相关的文档组成的智力创造。3.25 软件生命周期（software life c

18、ycle）从软件构思开始到软件不再可用结束的时期内发生的活动。典型的软件生命周期包括一个需求阶段，开发阶段，测试阶段，集成阶段，安装阶段和一个维护阶段。3.26 软件可维性（software maintainability）系统能被修改以纠正故障、改进性能或其它特性，或适应不同环境的能力。3.27 软件维护（software maintenance）它是指在软件被最终用户接收后所进行的活动或活动集合,它的目的在于改善,增加或纠正软件的功能。3.28 软件安全完整性等级（software safety integrity level）一组分级数字，它确定了为将残留软件故障降低到一个适当水平所必须

19、采用的技术和措施。3.29 系统安全完整性等级（system safety integrity level）表示系统能满足规定安全特性的置信度的数字。3.30 可追溯性（traceability）能在开发过程中确定两个或者多个产品之间关系的程度，尤其是那些与其它产品构成前/后代或上/下级关系的。 3.31 确认（validation）通过测试和分析，表明产品在各个方面符合规定需求的证实行为。3.32 确认员（validator）被委派来做确认工作的人或者代理。3.33 验证（verification）通过测试和分析，表明系统生命周期的各阶段的输出符合前一阶段的需求的一种决定性行为。3.34 验

20、证员（verifier）被委派来做验证工作的人或代理。4 目标和符合4.1 在以下每个条款中，将详细地描述其目标和要求。4.2 为遵从本欧洲标准，应表明依据规定的软件安全完整性等级每一项需求都已得到满足，因而也满足条款的目标。4.3 如果一个需求附有“在软件安全完整性等级要求的范围内”的词句，则表示可用一定范围内的技术和措施来满足该需求。4.4 在上述条款适用的地方，应使用本欧洲标准详细给出的表格来帮助选择与软件安全完整性等级相适应的技术和措施。4.5 如果某一技术或措施在表格中被列为强力推荐，那么不使用该技术的理由应在软件质量保证计划中或软件质量保证计划参考的其他文件中作详细说明并作相应的记

21、录。如果使用了相应表格中被认可的技术，这就不一定要作记录了。4.6 如果一项不包括在表格中的技术或措施被建议使用，那么应对其有效性及能满足特殊要求和条款整个目标的适用性作论证，并在软件质量保证计划中或软件质量保证计划参考的其他文件中作相应的记录。4.7 应通过检查本标准所要求的文档、其他客观证据、审计和见证测试来评估是否符合特殊条款的要求和表格中详细列出的各自的技术和措施。4.8 本欧洲标准需要使用一组技术及它们的正确应用。这些技术是表格中所要求的，并在参考书目中详细列出。5 软件安全完整性级别5.1 目标给软件指定软件安全完整性等级。5.2 要求5.2.1 依据EN50126和EN50129

22、，应形成- 系统需求规格说明书- 系统安全性需求规格说明书；- 系统结构描述；- 系统安全性计划；其中包括： 安全性功能； 系统配置或体系结构； 硬件可靠性需求； 安全完整性需求；软件安全完整性等级应通过获得EN50126确定的安全完整性等级的一般过程来确定。5.2.2 应在系统中软件应用的风险水平和系统安全完整性等级的基础上决定需要的软件安全完整性等级。5.2.3 如没有进一步防范措施，软件安全完整性等级至少等于系统安全完整性等级。然而，如果存在能预防软件模块失效导致系统进入不安全状态的机制，则可以减低模块的软件安全完整性等级。5.2.4 应考虑的风险与下列危险后果有关： 失去生命； 使人受

23、伤或生病； 环境的污染； 财产损失或损坏。5.2.5 风险可被定量化，但不能以同样方式规定软件安全完整性。因此，对于本欧洲标准，软件安全完整性等级被指定为下列五个等级之一：软件安全完整性等级 软件安全完整性等级描述 4 非常高 3 高 2 中等 1 低 0 非安全性5.2.6 在软件需求规格说明书中应指定软件安全完整性等级(条款8)。如果不同的软件组件有不同的软件安全完整性等级，应在软件架构规格说明书中加以规定(条款9)。6 人员和职责6.1 目标保证所有对软件负有责任的人员有能力履行那些职责。6.2 要求6.2.1 供应者和/或开发者以及客户最低限度都应执行EN ISO 9001的相关部分，

24、以保持和EN ISO 90003一致。6.2.2 除软件安全完整性等级0以外，安全性过程应在一个适当的安全性组织的控制下完成。该组织遵从EN 50129“安全性管理的证据”条款中“安全性机构”子条款要求。6.2.3 软件生命周期各阶段（包括管理活动）涉及的所有人员应具有适当的培训、经验和资格。6.2.4 除软件安全完整性等级0以外，对于特定应用，强力推荐对软件生命周期各阶段（包括管理活动）涉及的所有人员的培训、经验、资格进行证实。6.2.5 应在软件质量保证计划中记录上述子条款要求的论证，适当的包括能胜任下列领域工作的证据： 适合应用领域的工程； 软件工程； 计算机系统工程； 安全工程； 法规

25、框架。6.2.6 指定独立的软件评估员。也可参看6.2.10 和 14.4.1。6.2.7 应赋予评估人员足够的权威来实现对软件的评估。6.2.8 软件整个生命周期各个阶段所涉及的各方的独立性要根据软件安全完整性等级调整，保持和图5一致，解释如下：在各个软件安全完整性等级，评估员应由安全主管机构认可，除6.2.10规定的情况外，都应独立于供应商。设计者生产者、验证员和确认员可以同属一个公司，但至少要满足以下独立性： 在软件安全完整性等级0：没有限制；设计者/生产者、验证员和确认员可以是同一人。 在软件安全完整性等级1和2：验证员和确认员可以是同一人，但他们不应又是设计者/生产者。设计者/生产者

26、、验证者和确认者能向项目经理报告。 在软件安全完整性等级3和4：有两种允许的安排：a) 验证员和确认员可以是同一人，但他们不应又是设计者/生产者。而且他们不应象设计者/生产者一样向项目经理报告，他们有权力阻止产品的提交。b) 设计者/生产者、验证员和确认员必须是各不相同的人。设计者/生成者和验证员可以向项目经理报告，而确认员则不向项目经理报告。确认员有权力阻止产品的提交。6.2.9 负责各个条款的有关人员如下：软件需求规格说明书（条款8） 设计者软件需求测试规格说明书（条款8） 确认员软件体系结构（条款9） 设计者软件设计和开发（条款10） 设计者软件验证和测试（条款11） 验证员软件/硬件集

27、成（条款12） 设计者软件确认（条款13） 确认员软件评估（条款14） 评估员6.2.10 根据安全主管机构的意见，评估员可以是供应商组织或客户组织的一员，在这种情况下，评估员应： 由安全主管机构授权； 完全独立于项目梯队； 直接向安全主管机构报告7 生命周期和文档7.1 目标7.1.1 将软件开发构造成规定的阶段和活动。7.1.2 记录贯穿整个软件生命周期的软件所有相关信息。7.2 要求7.2.1 选择软件开发的生命周期模型，根据本欧洲标准条款15，它将在软件质量保证计划中加以详细说明。图3和图4 给出了生命周期模型的例子。7.2.2 质量保证程序应与生命周期活动一起运行，并且使用相同的术语

28、。7.2.3 某阶段所有要进行的活动应在该阶段开始之前就被定义好。软件生命周期的每阶段都应划分成带有良好定义的输入、输出及其活动的基本任务。7.2.4 软件质量保证计划应当描述需要哪些验证步骤和报告。7.2.5 所有文档应结构化，以便能随着设计过程不断扩展。7.2.6 各个文档应有唯一的参考号，与其他文档应有确定的、记录在案的文档关系，以便进行文档追溯。每个文档对术语、缩写词和简写词应有相同的解释。如果由于历史的原因，这一点达不到，就应给出不同的释义和参考资料。此外，除商用软件或早期开发的软件外的文档外，各文档应按下列规则书写：a） 应包括或执行所有前期文档的适用条件和需求，使文档具有层次关系

29、；b） 不应与前期文档有抵触；c） 在各个文档中，每个术语，首字母缩略词或缩写应具有相同的意义；d） 在各个文档中，每一条目或概念应用相同的名称或描述来参考。7.2.7 所有文档内容应以适合于操作、处理和存储的形式来记录。7.2.8 根据软件安全完整性等级的要求，应形成文档交叉参考表。7.2.9 根据开发软件的规模，复杂性和生命周期，需要产生的各类文件数目有所不同。对于规模较小的项目，一些文件可以组合在一起（在这过程中不应丢失需要的细节），而对于大规模项目，必须将所列文档（以层次方式）分成一些更便于管理的子文档。由独立团队或实体形成的文档不能组合成单一文档。7.2.10 条款7确定的各种文参考

30、文献文档之间的关系可以用文档交叉参考表来定义。对于表中文档列的各文档，通过从包含符号“”的单元格开始水平和垂直地阅读可以发现与创建文档有关的阶段和条款。通过从标记为符号“”的单元格开始垂直地阅读可以发现应用文档阶段。条款或文档定义参考的其他参考文献可以在“定义的地方”列中找到。如给出条款，后继条款应被检查，因为它们可能包含进一步信息。还要注意的是：因软件配置管理计划需要的参考文献列在括号内，因为该条款只不过参考EN ISO 9001。文档对照表条款标题8910111213141516SRSSASDDSVerS/HISValAssQMa 阶段（*）=和其他阶段平行定义出处文档系统输入系统需求规格说明书EN50129附件B.2.3系统安全需求规格说明书EN