EN50128铁路应用——通信、信号和处理系统——铁路控制和防护系统软件.pdf

同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 1 EN 50128 : 2001 铁路应用通信、信号和处理系统铁路 控制和防护系统软件 铁路应用通信、信号和处理系统铁路 控制和防护系统软件 2007.6 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 I 序言序言 本欧洲标准是SC 9XA,即通信，信号传输和处理系统技术委员会（CENELEC TC 9X）制订，铁路电气和电子 应用的标准。草案文本作为EN 50128正式提交投票并于2000-11-01获得CENELEC批准。 修改了下列日期 -欧盟各国必须通过认可或发布相同的国家标准来执行本欧洲标准的截止日期 2001 -1 1-01 -与本欧洲标准冲突的国家标准必须被废止的截止日期 2003-1 1-01 本欧洲标准必须与 EN50126 铁路应用可靠性，可用性，可维护性和安全性（RAMS） ；EN50129 铁路应用信号 领域的安全相关电子系统同时阅读。 附件中指定的“规范性的”是本项标准主体的一部分。 附件中指定的“参考性的”只用于获得的信息。 本项标准中，附件 A 是规范性的而附件 B 是参考性的。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 II 目录目录 引言 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 输入文档 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 III 103 输出文档 104 需求 11. 软件验证和测试 111 目标 112 输入文档 113 输出文档 114 需求 12. 软件/硬件集成 121 目标 122 输入文档 123 输出文档 124 需求 13. 软件确认 131 目标 132 输入文档 133 输出文档 134 需求 14. 软件评估 141 目标 142 输入文档 143 输出文档 144 需求 15. 软件质量保障 151 目标 152 输入文档 153 输出文档 154 需求 16. 软件维护 161 目标 162 输入文档 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 IV 163 输出文档 164 需求 17. 根据应用数据配置的系统 171 目标 172 输入文档 173 输出文档 174 需求 1741 数据准备生命周期 1742 数据准备程序和工具 1743 软件开发 附件 A：技术和措施的选择准则 附件 B：技术参考书目 附图 图 1安全相关系统的完整性等级 图 2软件安全性路径图 图 3开发生命周期 1 图 4开发生命周期 2 图 5独立性与软件完整性等级 图 6通用系统开发和应用开发之间的关系 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 1 引言引言 本标准是相关标准系列中的一部分。其他标准有 EN50126 铁路应用可靠性，可用性，可维护性和安全性 （RAMS） ；EN50129 铁路应用信号领域的安全相关电子系统。EN50126 适用于大范围的系统问题，而 EN50129 适用于整个铁路控制和防护系统中某单个系统的批准过程。本标准关注于需要使用的方法，以使软件能满足经全面 考虑后所分配到的安全完整性要求。 本标准从IEC/TC65第九工作组（WG9）早期工作中得到很多指导。WG9的工作形成了一个安全系统软件通用标 准，现在该标准是IEC61508的一部分。WG9工作的特别之处是包含了适用于非安全软件的软件安全完整性0级，以 及适用于安全相关和安全苛求软件的软件安全完整性14级。本标准也覆盖了所有五个软件安全完整性等级。 国际铁路信号工程师协会（IRSE）的工作也被考虑进来，特别是它关注相同课题的1号技术报告。 本欧洲标准的一个关键概念是软件安全完整性等级。软件失效后果的危险性的越大，软件安全完整性等级也就 越高。 本欧洲标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中14这四个级别涉及安全 相关软件，0级涉及非安全相关软件。对0级进行标准化是为了让非安全相关系统软件向安全相关系统软件进行平滑 转变。附表给出了各个软件安全完整性等级和非安全相关等级要求的技术和措施。在这个版本中，1级和2级的技术 要求相同， 3级和4级的要求相同。 本欧洲标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。 这个结论需要考虑许多因素包括应用的特性、其他系统承担的安全性功能范围和社会以及经济因素。 EN 50126 和EN 50129规定了分配给软件的安全性功能。 本欧洲标准规定了满足这些需求的必要措施。这个过程在图1作了说明。 EN50126和EN50129需采用系统性的方法，以： 1） 确定危险、风险和风险准则； 2） 为满足风险准则，确定必要的风险降低； 3） 为实现必要的风险降低，定义一个全面的系统安全性需求规格说明； 4） 选择一个合适的系统体系结构； 5） 规划、监督和控制那些把系统安全性需求规格说明变成安全性能(或安全完整性)已确认的安全相关系统 所必需的技术和管理活动。 在分解需求规格说明形成由安全相关系统和组件组成的设计说明时，需要进一步分配安全完整性等级，并最终 形成所需的软件安全完整性等级。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 2 目前，无论是质量保证法(即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚未发现可以证 明一个较复杂的安全相关软件中不存在错误的方法，特别是规格说明和设计的错误。 以下规则应用于开发高安全完整性等级软件，但也不仅限于开发高安全完整性等级软件： 1） 自顶向下的设计方法； 2） 模块化； 3） 开发生命周期每一阶段的验证； 4） 验证后的模块和模块库； 5） 清晰的文档； 6） 可审计的文档； 7） 确认测试。 这些规则以及相关的其他规则必须正确应用。对于各个软件安全完整性等级，本标准均规定了说明这一点所需 的保证等级。 在得到或形成了系统安全性需求规格说明后，分配给软件的安全性功能和系统安全完整性等级就确定了，图2 给出了应用本欧标的功能步骤，如下所示： 1） 定义软件需求规格说明，同时考虑软件体系结构。软件体系结构是为软件和软件安全完整性等级开发基 本安全策略的架构。(条款5、8和9) 2） 根据软件质量保障计划、软件安全完整性等级和软件生命周期来设计、开发和测试软件。(条款10) 3） 在目标硬件上集成软件。(条款12) 4） 确认软件。(条款13) 5） 如果在运行过程中需要软件维护，那么可再适当运用本欧洲标准进行处理。(条款16) 许多活动都是在软件开发过程中交叉进行的，这其中包括验证(条款11)，评估(条款14)和质量保障(条款15)。 给出了应用数据配置的系统的需求(条款17)。 给出了从事软件开发人员能力的需求。(条款7) 本标准没有硬性要求使用特定的软件开发生命周期，但是给出了一个推荐的生命周期及文档集。(条款7，图3 和图4) 表格针对5个软件安全完整性等级明确罗列了各种技术和措施。表格在附件A中给出。与表格对照的参考书目提 供了更多的信息，给出了每项技术和措施的简明描述。参考书目在附件B中给出。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 3 1 范围范围 1.1 本欧洲标准详细规定了铁路控制和防护设备用的可编程电子系统开发所需的程序和技术要求。 它适用于任何有 隐含安全性的领域。这些应用系统的范围涵盖了安全苛求系统,如安全信号，非安全苛求系统,如管理信息系统。这些 系统可能通过采用专用多处理器，可编程逻辑控制器，分布式多处理器系统，大规模集中处理器系统或者其它架构 来实现。 1.2 本欧洲标准专门应用于软件以及软件和系统之间的相互作用。 1.3 0级以上的软件安全完整性等级用于失效可引起失去生命的后果的系统。然而，从经济或环境因素方面考虑也 能采用高级别的安全完整性等级。 1.4 本欧洲标准适用于铁路控制和防护系统开发和实现的所有软件，包括： 应用程序设计； 操作系统； 支持工具； 固件。 应用程序设计包括高级程序设计，低级程序设计和专用程序设计（如：可编程逻辑控制器梯形逻辑）。 1.5 本欧洲标准还涉及了本标准的使用、商用软件和工具。 1.6 本欧洲标准还对应用数据配置的系统提出了要求。 1.7 本欧洲标准并不涉及商务问题，这些问题应为合同的基本部分被提出。但本欧洲标准中的所有条款在任何商务 活动中都需被仔细考虑。 1.8 本欧洲标准为避免追溯，主要应用于新的开发。对于现有系统，仅当进行主要修改时才进行全面应用，对于次 要修改，只要应用条款 16。 2 规范性参考文献2 规范性参考文献 本欧洲标准需与标注日期或未标注日期的参考文献以及其他出版物中条款相结合。 这些规范性参考文献将在文 中合适的位置被引用，相应的出版物将在下面列出。对于标注日期文献的后续修改或修订，本欧洲标准需通过修改 或修订进行结合来应用。对于未标注日期的文献,则应用最新版本(包括修改)。 EN50126，铁路应用可靠性，可用性，可维持性和安全性（RAMS）的规格和说明； EN50129*，铁路应用信号领域的安全相关电子系统； EN50159-1,铁路应用通信，信号和处理系统 第一部分：封闭传输系统中的安全通信； 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 4 EN50129-1,铁路应用通信，信号和处理系统 第二部分：开放传输系统中的安全通信； EN ISO 9001,质量体系设计/开发，生产，安装和维护的质量保证模型； EN ISO 9001-3,质量管理和质量保证标准第三部分：ISO9001:1994在计算机软件的开发， 供应，安装和维护应用的指导。 3 定义 3 定义 以下定义适用于此欧洲标准.对于未定义的术语,按照优先顺序查阅以下参考文献。 EN ISO 8402，质量管理和质量保证词汇表； IEC 60050-191,国际电工词汇第 191 章：服务可信性和质量； IEEE 610.12, IEEE标准软件工程术语词汇表； ISOIIEC 2382,信息技术词汇表； ISOIIEC 9126,信息技术软件产品评估质量特性以及其使用指导； 3.1 评估（评估（assessment） 用于确定设计主管机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。 3.2 评估员（评估员（assessor） 受委托执行评估的人员或者代理。 3.3 可用性（可用性（availability） 假定所需外部资源均能满足的条件下，产品在规定的条件下，在规定的时刻或在给定的时间间隔内完成要求功 能的能力。 3.4 商用软件（商用软件（COTS software） 市场需求所定义、市场已存在且其目标满足性已得到广大商业用户证明的软件。 3.5 设计主管机构（设计主管机构（design authority） 负责提出实现特定需求的设计方案，并监控后期的开发和系统在特定环境下工作的实体。 3.6 设计者（设计者（designer） 一个或多个由设计主管机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的 设计方案。 3.7 元素（元素（element） 被确认为基本单元和基本部件的某产品的一部分。一个元素可以是简单或者复杂的。 3.8 错误（错误（error） 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 5 与期望的设计相背离，并有可能导致未预料到的系统行为或失效。 3.9 失效（失效（failure） 与规定的系统行为相背离。失效是系统错误或故障的结果。 3.10 故障（故障（fault） 一种能导致系统错误或失效的不正常情形，故障可以是系统性或随机性的。 3.11 避错（避错（fault avoidance） 在系统设计和构造的过程中使用避免引入故障的设计技术。 3.12 容错（容错（fault tolerance） 在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力 3.13 固件（固件（firmware） 指令和存储在一个功能独立主存储器（通常是ROM）中的相关数据的有序集合 3.14 通用软件（通用软件（generic software） 通用软件是只要提供应用相关的数据就可以应用于多种系统装置的软件。 3.15 实现人员（实现人员（implementer） 由设计主管机构委派、具体实现特定设计的一个或更多人员 3.16 产品（产品（product） 为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。本欧洲标准中，产品可被视为完全 由软件或者文档元素构成。 3.17 可编程逻辑控制器可编程逻辑控制器(PLC) 具备面向指令存储的用户可编程存储器、能实现轨定功能的固态控制系统。 3.18 可靠性可靠性(reliability) 设备在规定的条件下，在规定的时间内执行要求功能的能力。 3.19 需求可追溯性（需求可追溯性（requirement traceability） 需求可追溯性的目标是确保所有的需求能被证明已得到满足 3.20 风险（风险（risk） 某特定危险事件的频率或概率和后果的组合。 3.21 安全性（安全性（safety） 无不可接受的风险等级。 3.22 安全主管机构（安全主管机构（safety authority） 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 6 负责证实安全相关系统适于工作并符合法令、规章规定的安全性需求的实体。 3.23 安全相关软件（安全相关软件（safety-related software） 负有安全责任的软件。 3.24 软件（软件（software） 由程序、过程、规则和系统运行相关的文档组成的智力创造。 3.25 软件生命周期（软件生命周期（software life cycle） 从软件构思开始到软件不再可用结束的时期内发生的活动。 典型的软件生命周期包括一个需求阶段， 开发阶段， 测试阶段，集成阶段，安装阶段和一个维护阶段。 3.26 软件可维性（软件可维性（software maintainability） 系统能被修改以纠正故障、改进性能或其它特性，或适应不同环境的能力。 3.27 软件维护（软件维护（software maintenance） 它是指在软件被最终用户接收后所进行的活动或活动集合,它的目的在于改善,增加或纠正软件的功能。 3.28 软件安全完整性等级（软件安全完整性等级（software safety integrity level） 一组分级数字，它确定了为将残留软件故障降低到一个适当水平所必须采用的技术和措施。 3.29 系统安全完整性等级（系统安全完整性等级（system safety integrity level） 表示系统能满足规定安全特性的置信度的数字。 3.30 可追溯性（可追溯性（traceability） 能在开发过程中确定两个或者多个产品之间关系的程度，尤其是那些与其它产品构成前/后代或上/下级关系的。 3.31 确认（确认（validation） 通过测试和分析，表明产品在各个方面符合规定需求的证实行为。 3.32 确认员（确认员（validator） 被委派来做确认工作的人或者代理。 3.33 验证（验证（verification） 通过测试和分析，表明系统生命周期的各阶段的输出符合前一阶段的需求的一种决定性行为。 3.34 验证员（验证员（verifier） 被委派来做验证工作的人或代理。 4 目标和符合 4 目标和符合 4.1 在以下每个条款中，将详细地描述其目标和要求。 4.2 为遵从本欧洲标准， 应表明依据规定的软件安全完整性等级每一项需求都已得到满足， 因而也满足条款的目标。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 7 4.3 如果一个需求附有“在软件安全完整性等级要求的范围内”的词句，则表示可用一定范围内的技术和措施来满足 该需求。 4.4 在上述条款适用的地方， 应使用本欧洲标准详细给出的表格来帮助选择与软件安全完整性等级相适应的技术和 措施。 4.5 如果某一技术或措施在表格中被列为强力推荐， 那么不使用该技术的理由应在软件质量保证计划中或软件质量 保证计划参考的其他文件中作详细说明并作相应的记录。如果使用了相应表格中被认可的技术，这就不一定要作记 录了。 4.6 如果一项不包括在表格中的技术或措施被建议使用， 那么应对其有效性及能满足特殊要求和条款整个目标的适 用性作论证，并在软件质量保证计划中或软件质量保证计划参考的其他文件中作相应的记录。 4.7 应通过检查本标准所要求的文档、其他客观证据、审计和见证测试来评估是否符合特殊条款的要求和表格中详 细列出的各自的技术和措施。 4.8 本欧洲标准需要使用一组技术及它们的正确应用。这些技术是表格中所要求的，并在参考书目中详细列出。 5 软件安全完整性级别 5 软件安全完整性级别 5.1 目标目标 给软件指定软件安全完整性等级。 5.2 要求要求 5.2.1 依据EN50126和EN50129，应形成 - 系统需求规格说明书 - 系统安全性需求规格说明书； - 系统结构描述； - 系统安全性计划； 其中包括： 安全性功能； 系统配置或体系结构； 硬件可靠性需求； 安全完整性需求； 软件安全完整性等级应通过获得EN50126确定的安全完整性等级的一般过程来确定。 5.2.2 应在系统中软件应用的风险水平和系统安全完整性等级的基础上决定需要的软件安全完整性等级。 5.2.3 如没有进一步防范措施，软件安全完整性等级至少等于系统安全完整性等级。然而，如果存在能预防软件模 块失效导致系统进入不安全状态的机制，则可以减低模块的软件安全完整性等级。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 8 5.2.4 应考虑的风险与下列危险后果有关： 失去生命； 使人受伤或生病； 环境的污染； 财产损失或损坏。 5.2.5 风险可被定量化，但不能以同样方式规定软件安全完整性。因此，对于本欧洲标准，软件安全完整性等级被 指定为下列五个等级之一： 软件安全完整性等级 软件安全完整性等级描述 4 非常高 3 高 2 中等 1 低 0 非安全性 5.2.6 在软件需求规格说明书中应指定软件安全完整性等级(条款8)。如果不同的软件组件有不同的软件安全完整性 等级，应在软件架构规格说明书中加以规定(条款9)。 6 人员和职责 6 人员和职责 6.1 目标目标 保证所有对软件负有责任的人员有能力履行那些职责。 6.2 要求要求 6.2.1 供应者和/或开发者以及客户最低限度都应执行 EN ISO 9001 的相关部分，以保持和 EN ISO 90003 一致。 6.2.2 除软件安全完整性等级 0 以外，安全性过程应在一个适当的安全性组织的控制下完成。该组织遵从 EN 50129“安全性管理的证据”条款中“安全性机构”子条款要求。 6.2.3 软件生命周期各阶段（包括管理活动）涉及的所有人员应具有适当的培训、经验和资格。 6.2.4 除软件安全完整性等级 0 以外，对于特定应用，强力推荐对软件生命周期各阶段（包括管理活动）涉及的所 有人员的培训、经验、资格进行证实。 6.2.5 应在软件质量保证计划中记录上述子条款要求的论证，适当的包括能胜任下列领域工作的证据： 适合应用领域的工程； 软件工程； 计算机系统工程； 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 9 安全工程； 法规框架。 6.2.6 指定独立的软件评估员。也可参看 6.2.10 和 14.4.1。 6.2.7 应赋予评估人员足够的权威来实现对软件的评估。 6.2.8 软件整个生命周期各个阶段所涉及的各方的独立性要根据软件安全完整性等级调整，保持和图 5 一致，解释 如下： 在各个软件安全完整性等级，评估员应由安全主管机构认可，除 6.2.10 规定的情况外，都应独立于供应商。 设计者生产者、验证员和确认员可以同属一个公司，但至少要满足以下独立性： ? 在软件安全完整性等级 0：没有限制；设计者/生产者、验证员和确认员可以是同一人。 ? 在软件安全完整性等级 1 和 2：验证员和确认员可以是同一人，但他们不应又是设计者/生产者。设计者/ 生产者、验证者和确认者能向项目经理报告。 ? 在软件安全完整性等级 3 和 4：有两种允许的安排： a) 验证员和确认员可以是同一人，但他们不应又是设计者/生产者。而且他们不应象设计者/生产者一样 向项目经理报告，他们有权力阻止产品的提交。 b) 设计者/生产者、验证员和确认员必须是各不相同的人。设计者/生成者和验证员可以向项目经理报告， 而确认员则不向项目经理报告。确认员有权力阻止产品的提交。 6.2.9 负责各个条款的有关人员如下： 软件需求规格说明书（条款 8） 设计者 软件需求测试规格说明书（条款 8） 确认员 软件体系结构（条款 9） 设计者 软件设计和开发（条款 10） 设计者 软件验证和测试（条款 11） 验证员 软件/硬件集成（条款 12） 设计者 软件确认（条款 13） 确认员 软件评估（条款 14） 评估员 6.2.10 根据安全主管机构的意见，评估员可以是供应商组织或客户组织的一员，在这种情况下，评估员应： ? 由安全主管机构授权； ? 完全独立于项目梯队； ? 直接向安全主管机构报告 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 10 7 生命周期和文档 7 生命周期和文档 7.1 目标目标 7.1.1 将软件开发构造成规定的阶段和活动。 7.1.2 记录贯穿整个软件生命周期的软件所有相关信息。 7.2 要求要求 7.2.1 选择软件开发的生命周期模型，根据本欧洲标准条款 15，它将在软件质量保证计划中加以详细说明。图 3 和 图 4 给出了生命周期模型的例子。 7.2.2 质量保证程序应与生命周期活动一起运行，并且使用相同的术语。 7.2.3 某阶段所有要进行的活动应在该阶段开始之前就被定义好。软件生命周期的每阶段都应划分成带有良好定义 的输入、输出及其活动的基本任务。 7.2.4 软件质量保证计划应当描述需要哪些验证步骤和报告。 7.2.5 所有文档应结构化，以便能随着设计过程不断扩展。 7.2.6 各个文档应有唯一的参考号，与其他文档应有确定的、记录在案的文档关系，以便进行文档追溯。每个文档 对术语、缩写词和简写词应有相同的解释。如果由于历史的原因，这一点达不到，就应给出不同的释义和参考资料。 此外，除商用软件或早期开发的软件外的文档外，各文档应按下列规则书写： a） 应包括或执行所有前期文档的适用条件和需求，使文档具有层次关系； b） 不应与前期文档有抵触； c） 在各个文档中，每个术语，首字母缩略词或缩写应具有相同的意义； d） 在各个文档中，每一条目或概念应用相同的名称或描述来参考。 7.2.7 所有文档内容应以适合于操作、处理和存储的形式来记录。 7.2.8 根据软件安全完整性等级的要求，应形成文档交叉参考表。 7.2.9 根据开发软件的规模，复杂性和生命周期，需要产生的各类文件数目有所不同。对于规模较小的项目，一些 文件可以组合在一起（在这过程中不应丢失需要的细节），而对于大规模项目，必须将所列文档（以层次方式）分 成一些更便于管理的子文档。由独立团队或实体形成的文档不能组合成单一文档。 7.2.10 条款 7 确定的各种文参考文献文档之间的关系可以用文档交叉参考表来定义。 对于表中文档列的各文档， 通 过从包含符号“?”的单元格开始水平和垂直地阅读可以发现与创建文档有关的阶段和条款。通过从标记为符号“” 的单元格开始垂直地阅读可以发现应用文档阶段。条款或文档定义参考的其他参考文献可以在“定义的地方”列中找 到。如给出条款，后继条款应被检查，因为它们可能包含进一步信息。还要注意的是：因软件配置管理计划需要的 参考文献列在括号内，因为该条款只不过参考 EN ISO 9001。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 11 文档对照表文档对照表 8 9 10 11 12 13 14 15 16 条款 标题 SRS SA SDD SVerS/HISValAss Q Ma 阶段 （*）=和其他 阶段平行 ? ? ? 系统需求规格说明书 EN50129 附件 B.2.3 ? ? ? ? ? ? 系统安全需求规格说明书 EN50129 附件 B.2.4 ? ? 系统结构描述 EN50129 附件 B.2.1 系统输入 系统安全性计划 EN50129、 EN50126 ? ? ? ? ? ? ? 软件质量保证计划 15.4.3 ? ? ? 软件配置管理计划 (15.4.2) ? ? ? 软件验证计划 11.4.1 ? ? ? 软件集成测试计划 11.4.5 ? ? ? 软件/硬件集成测试计划 12.4.1 ? ? 软件确认计划 13.4.3 ? ? 软件维护计划 16.4.3 数据准备计划 17.4.2.1 软件计划(*) 数据测试计划 17.4.2.4 ? ? ? ? ? ? ? 软件需求规格说明书 8.4.1 应用需求规格说明书 17.4.1.1 ? ? ? ? ? 软件测试规格说明书 8.4.13 软件需求 ? 软件需求验证报告 11.4.11 ? ? ? ? ? ? 软件结构规格说明书 9.4.1 ? ? ? ? ? 软件设计规格说明书 10.4.3 软件设计 ? 软件结构和设计验证报告 11.4.12 ? ? ? ? ? 软件模块设计规格说明书 10.4.3 ? ? ? ? ? 软件模块测试规格说明书 10.414 软件模块 设计 ? 软件模块验证报告 11.413 ? ? ? ? ? 软件源代码 编码 ? ? ? 软件源代码验证报告 11.4.14 模块测试 ? ? 软件模块测试报告 10.4.14 ? 软件集成测试报告 11.4.15 软件集成 数据测试报告 17.4.2.4 软件/硬件集 成 ? 软件/硬件集成测试报告 12.4.8 确认(*) ? 软件确认报告 13.4.10 评估(*) ? 软件评估报告 14.4.9 ? 软件修改记录 16.4.9 维护 ? 软件维护记录 16.4.8 文档 定义出处 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 12 8 软件需求规格说明软件需求规格说明 8.1 目标 目标 8.1.1 描述一个文档，为满足所有系统需求，该文档根据软件安全完整性等级规定了完整的软件需求。它是对每个 软件工程师均适用的综合性文档，因此他们不必再从其他文档中了解需求。 8.1.2 用于描述软件需求测试说明书。 8.2 输入文档输入文档 1） 系统需求规格说明书。 2） 系统安全性需求规格说明书。 3） 系统体系结构描述。 4） 软件质量保证计划。 8.3 输出文档输出文档 1） 软件需求规格说明书。 2） 软件需求测试规格说明书。 8.4 要求要求 8.4.1 1 软件需求规格说明书应描述待开发软件的需求特性，而不是开发软件的程序。这些特性应包括（除安全性外 均在 ISO/IEC 9126 中定义） ： ? 功能性（包括能力和响应时间性能）； ? 可靠性和可维护性； ? 安全性（包括安全功能及其相关的软件安全完整性等级）； ? 效率； ? 可用性； ? 可移植性。 软件安全完整性等级源至于条款 5，并记录在软件需求规格说明书中。 8.4.2 2 根据软件安全完整性等级的要求，软件需求规格说明书应以如下方式来描述和够造： ? 完整、清楚准确、无二义性、可验证、可测试，可维护和可行的； ? 可以追溯到 8.2 涉及的所有文档。 8.4.3 3 软件需求规格说明书应使用让系统整个生命周期所涉及、负有责任的人员都能理解的表达和描述方法。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 13 8.4.4 4 无论那里存在或规划一个直接互联，软件需求规格说明书都应明确并用文件证实受控设备内部或外部的与任 何其他系统的所有接口，包括和操作员的接口。 8.4.5 5 软件需求规格说明书应详细描述所有相关的操作方式。 8.4.6 6 软件需求规格说明书中应详述可编程电子器所有相关的行为方式，尤其是失效行为。 8.4.7 7 软件需求规格说明书中应明确并用文件证实软硬件之间的任何约束。 8.4.8 8 软件需求规格说明书应指出软件自检的程度以及软件检测硬件的规定程度。软件自检包括软件自身失效和错 误的检测和报告。 8.4.9 9 软件需求规格说明书应根据系统安全性需求规格说明书的要求包括周期性功能检测需求。 8.4.10 10 软件需求规格说明书应根据系统安全性需求规格说明书的要求包括使所有安全功能在整个系统运行期内可 测试的需求 8.4.1111 当要求软件来完成一些功能，特别是完成那些与实现选定系统安全完整性等级有关的功能时，软件需求规 格说明书应对其加以清楚的说明。 8.4.1212 当要求软件完成非安全功能时，软件需求规格说明书应对其加以清楚的说明。 8.4.1313 软件需求测试规格说明书应从软件需求规格说明书开发而来，软件需求测试规格说明书用来验证软件需求 规格说明书中所述的功能要求，同时也作为对已完成软件进行测试的描述。 8.4.1414 软件需求测试规格说明书应为每个所需功能确定测试用例，包括： i) 所需的输入信号及其序列和值； ii) 预期的输出信号及其序列和值； iii) 接受准则，包括性能和各个质量方面。 8.4.15 15 在安全系统的确认过程中，对需求的可追溯性应作为一个重要内容加以考虑。 应提供方法允许在生命周期 所有阶段均能证实这一点。 8.4.16 对于任何不可追溯材料，应表明其对系统的安全性或完整性是没有影响的。 9 软件体系结构 9 软件体系结构 9.1 目标目标 9.1.1 开发一个软件体系结构，该结构按照选定软件安全完整性等级的要求实现软件需求规格说明书的需求。 9.1.2 评审系统结构对软件的需求。 9.1.3 确定和评估硬件/软件交互作用对安全性的重要性。 9.1.4 如果早先没有定义设计方法，那么选择一种设计方法。 9.2 输入文档输入文档 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 14 1) 软件需求规格说明书。 2) 系统安全性需求规格说明书。 3) 系统体系结构描述。 4) 软件质量保证计划。 9.3 输出文档输出文档 软件体系结构规格说明书。 9.4 要求要求 9.4.1 应由软件提供者和/或开发者来建立建议性的软件体系结构，并在软件体系结构规格说明书中作详述。 9.4.2 软件体系结构规格说明书应考虑依据选定软件安全完整性等级的要求实现软件需求规格说明书的可行性。 9.4.3 软件体系结构规格说明书应明确、评估和详述所有硬件/软件交互的重要性。就象 EN50126 和 EN50129 所要 求的，应在系统安全性需求规格说明书中记录硬件和软件交互作用的基础研究。 9.4.4 软件体系结构规格说明书应明确所有软件组件，并为它们明确： i) 这些组件是否是新的，现存的或私有的； ii) 这些组件以前是否已被确认。如果是，它们的确认条件是什么； iii) 各组件的软件安全完整性等级。 9.4.5 使用商用软件应满足以下限制条件： i) 对于软件安全完整性等级 0，不需进一步防范措施即可使用商用软件； ii) 如果商用软件使用于软件完整性等级 1 或 2，则它应被包含在软件确认过程中； iii) 如果商用软件使用于软件完整性等级 3 或 4，则应采取以下防范措施： a) 商用软件应进行确认测试; b) 应进行可能失效的分析； c) 应确定一个策略来检测商用软件的失效并防护系统免受这些失效影响； d) 防保护策略应是确认测试的主题； e) 应有错误日志并对其进行评估； f) 就实用性而言，应仅使用上商用软件的最简单功能。 9.4.6 如果要将以前开发的软件作为设计的一部分使用，那么应有清楚的标识。并用文件证实。软件结构规格说明 书应论证软件在满足软件需求规格说明书和软件安全完整性等级方面的适宜性。必须仔细考虑任何软件的修改对系 统剩余部分的影响，以决定是否需要再审查和再评估。应有证据表明没有进行再检验，再确认和再评估的和其他模 块的接口规格说明书得到遵循。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 15 9.4.7 在设计过程中尽可能使用已有的、验证过的，按本标准开发的软件模块； 9.4.8 软件体系结构应减少应用的安全性部分； 9.4.9 如果软件由不同软件安全完整性等级的组件构成，那么该软件的所有组件都应按最高软件安全完整性等级的 要求处理，除非有表明较高软件安全完整性等级组件和较低软件安全完整性等级组件相互独立的证据。这个证据应 记录在软件结构规格说明书中。 9.4.10 软件体系结构规格说明书应明确按软件安全完整性等级要求进行软件开发的策略。软件体系结构规格说明 书应按下列方式来表达和构造： i) 完整、清楚、精确、无二义，可验证、可测试、可维护以及可行； ii) 可追溯到软件需求规格说明书。 9.4.11 软件体系结构规格说明书应证实在避错和容错软件设计策略的选择中所采取的平衡措施是正确的。 9.4.12 软件体系结构规格说明书应证实所选的技术和措施形成了一个集合，该集合满足了基于选定软件安全完整性 等级要求的软件需求规格说明书。 10 软件设计和实现 10 软件设计和实现 10.1 目标目标 10.1.1 1 设计和实现软件需求规格说明书和软件体系结构规格说明书所确定的软件安全完整性的软件。 10.1.2 2 获得可分析、可测试、可验证和可维护的软件。此阶段还包括模块测试。由于验证和测试在确认过程中起 关键作用，所以在设计和开发的整个过程中应特殊考虑验证和测试要求，以确保从一开始就使结果系统及其软件易 于测试。 10.1.3 3 为选定的软件安全完整性等级选择一套覆盖整个软件生命周期的包括语言和编译器的合适工具，它有助于 验证、确认、评估和维护。 10.1.4 4 实施软件集成。 10.2 输入文档输入文档 1） 软件需求规格说明书。 2） 软件体系结构规格说明书。 3） 软件质量保证计划。 10.3 输出文档输出文档 1） 软件设计规格说明书。 2） 软件模块设计规格说明书。 3） 软件模块测试规格说明书。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 16 4） 软件源代码和支持文档。 5） 软件模块测试报告。 10.4 要求要求 10.4.1 在设计过程开始之前，应能得到软件需求规格说明和软件体系结构规格说明，但不必已最终定稿。 10.4.2 应使待开发软件的规模和复杂性最小。 10.4.3 软件设计规格说明书应描述基于模块分解的软件设计，每一模块都有软件模块设计规格说明书和软件模块 测试规格说明书。 10.4.4 软件设计规格说明书应说明： 1） 追溯到软件体系结构的软件组件和它们的安全完整性等级； 2） 软件组件和环境的接口； 3） 软件组件间的接口； 4） 数据结构； 5） 划分组件需求； 6） 主要算法和顺序； 7） 图表。 10.4.5 软件模块设计规格说明书应说明（每个模块一个软件模块设计规格说明书） 1) 确定追溯到上一层次的所有最底层的组件（现有标准称之为模块）； 2) 它们和环境以及其它带有详细输入和输出要求的模块的细化接口； 3) 它们的安全完整性等级； 4) 细化的算法和数据结构。 5) 每个软件模块规格说明书应是自相容的，允许进行相应模块的编码。 10.4.6 每一软件模块都应是可读的、可理解的和可测试的。 10.4.7 为选定的软件安全完整性等级选择一套包括设计方法、语言和编译器的覆盖整个软件生存周期的合适工具。 10.4.8 只要适用，就应使用自动测试工具和集成开发工具。这里应考虑验证和确认的需求。 10.4.9 根据选定的软件安全完整性等级的要求，所选程序设计语言应具有翻译器/编译器，该翻译器/编译器应具备 下述条件之一： 1) 某公认国家/国际标准的确认证书； 2) 一个详述其适合用途的评估报告； 3) 一个进行翻译错误检测的基于冗余签名控制的过程。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 17 10.4.10 10 所选语言应满足如下要求： 1) 所选语言应具有便于识别编程出错的特性； 2) 所选语言应支持与设计方法相适应的特性。 10.4.11 11 如果不能满足上述条款，那么在软件体系结构规格说明或软件质量保证计划中应记录对更替语言的论证并 详述其适合用途。 10.4.12 12 开发编码标准，并将其应用于所有软件的开发。编码标准应在软件质量保证计划中予以参考。 10.4.13 13 编码标准应明确好的编程习惯，禁止非安全语言特性并描述编写源代码文档的程序。每个程序模块至少应 在源代码中包括如下指定的信息（非穷举的）： 作者； 配置历史； 简要描述。 推荐用这些信息的标准形式。该标准形式应对所有模块相同的。 10.4.14 14 软件模块测试：每个模块应有作为模块测试依据的软件模块测试规格说明书。这些测试应表明每个模块实 现了预定的功能，软件模块测试规格说明书应定义需要的测试覆盖率。 应形成软件模块测试报告，其中应包括以下特性： i) 描述测试结果以及每个模块是否满足它的软件模块设计规格说明书的需求； ii) 描述每个模块的测试覆盖率，以表明所有源代码指令至少执行一次； iii) 应以可审计的形式； iv) 测试用例和它们的结果应以机器可读的形式记录下来，以利后继分析。测试应是可重 复的，而且如果可 行的话，应自动进行。 检查模块已正确地满足了其测试规格说明书是一个验证活动，参见下一条款。 10.4.15 15 为符合所需软件安全完整性等级的要求，选定的设计方法应具有能方便以下活动的特性： i) 摘要、模块化和其他控制复杂度的特性； ii) 清楚且精确地表达： a) 功能； b) 组件间的信息流； c) 顺序和时延信息； d) 并发； e) 数据结构和特性； 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 18 iii) 人的理解； iv) 验证和确认。 10.4.16 16 选定的设计方法应具有方便软件维护的特性。这类特性应包括模块化、信息隐藏和封装。 10.4.17 17 软件模块集成应是逐渐将个体的且以前测试过的软件模块组合成一个合成整体(或一些合成子系统)的过 程。其目的是在系统集成和测试之前能充分地证明模块接口和装配的软件。 10.4.18 18 在本标准的上下文中，为与规定的软件安全完整性等级相适应，应特别强调可追溯性： i) 需求到设计或其他实现需求的对象的可追溯性； ii) 设计对象到实现对象的可追溯性。 可追溯性过程的输出应是形式化配置管理的主题。 11 软件验证和测试11 软件验证和测试 11.1 目标 目标 按照选定的软件安全完整性等级的要求，测试并评价某一给定阶段的产品，以确保产品和作为该阶段输入的标 准的正确性和一致性。 11.2 输入文档 2 输入文档 1） 系统需求规格说明书。 2） 系统安全性需求规格说明书。 3） 软件需求规格说明书。 4） 软件需求测试规格说明书。 5） 软件体系结构规格说明书。 6） 软件设计规格说明书。 7） 软件模块设计规格说明书。 8） 软件模块测试规格说明书。 9） 软件源代码和支持文档。 10） 软件质量保证计划。 11） 软件模块测试报告。 11.3 输出文档3 输出文档 1） 软件验证计划。 2） 软件需求验证报告。 同济大学、铁道科学研究院标准所同济大学、铁道科学研究院标准所 EN50128：2001 19 3） 软件体系结构和设计验证报告。 4） 软件模块验证报告。 5） 软件源代