2015-10-26 EN 50128 铁路应用-通信、信号和处理系统 铁路控制和防护系统软件 报告人：周夏芳 2015-10-26 1 内容安排 一、范围 二、软件安全完整性等级 三、组织结构、角色和资质 四、生命周期和文档 五、软件保障 六、通用软件开发 七、已有软件 八、根据应用数据/算法配置的系统 九、软件部署和软件维护 2015-10-26 2 一、范围 主要内容 本标准规定了在铁路控制和防护设备中使用的可编程电子 系统软件开发时的过程要求和技术要求。 适用对象 本标准适用于铁路控制和防护系统中的所有安全相关软件 ，包括： 应用软件 操作系统 支持工具 固件 已有软件 2015-10-26 3 二、软件安全完整性等级 什么是软件安全完整性等级？ 软件安全完整性等级是一组分级数字，它确定了软件 必须采用的技术和措施。 软件安全完整性等级分为SIL0SIL4共5个等级。 软件失效导致的风险越高，软件安全完整性等级越高。 2015-10-26 4 二、软件安全完整性等级 如何确定软件安全完整性等级？ 通常来说，软件安全完整性等级至少应等于系统安全 完整性等级。 如果软件是由不同软件安全完整性等级的组件组成， 那么该软件的所有组件都应按最高软件安全完整性等 级的要求处理。 2015-10-26 5 二、软件安全完整性等级 如何达到软件安全完整性等级的要求？ 1.标准正文 2015-10-26 6 目标目标 要求要求 二、软件安全完整性等级 如何达到软件安全完整性等级的要求？ 2.标准附录 Normative：Annex A、Annex B 规范性附录，必须满足 Informative：Annex C、 Annex D 信息性附录，供参考 2015-10-26 7 二、软件安全完整性等级 如何达到软件安全完整性等级的要求？ Annex A：对于技术措施的要求对于技术措施的要求 M：强制 HR：强力推荐 R：推荐 -：不推荐也不反对 NR：不推荐（不应使用） 2015-10-26 8 二、软件安全完整性等级 如何达到软件安全完整性等级的要求？ Annex B：对关键软件角色和职责的要求对关键软件角色和职责的要求 需求经理（REQ） 设计人员（DES） 实现人员（IMP） 测试人员（TST） 验证人员（VER） 集成人员（INT） 确认人员（VAL） 评估人员（ASR） 项目经理（PM） 配置经理（CM） 2015-10-26 9 三、组织结构、角色和资质 目标 确保所有参与软件开发过程的人员都是在组织结构的管理 下，是已授权并且有能力胜任其角色职责的。 角色资质要求 Annex B（TableB.1B.10） 2015-10-26 10 三、组织、角色和资质 组织结构独立性要求 2015-10-26 11 四、生命周期和文档 目标 将软件开发构造成规定的阶段和活动。 记录贯穿整个软件生命周期的所有相关信息。 生命周期模型 标准对生命周期模型无强制要求，但要求各阶段的活动和 内容均能满足本标准的要求。 2015-10-26 12 四、生命周期和文档 2015-10-26 13 四、生命周期和文档 文档要求 Annex A.1 各阶段文档要求 2015-10-26 14 四、生命周期和文档 文档要求 每一个文档都应有一个唯一的文档编号、以及定义好 的与其它文档之间的关系。 每一个文档都应包含并实现其上级（输入）文档的所 有相关要求。 每一个文档的内容都不应与其上级（输入）文档相矛 盾。 2015-10-26 15 追溯前提追溯前提 追溯完整性追溯完整性 追溯一致性追溯一致性 内容安排 一、范围 二、软件安全完整性等级 三、组织结构、角色和资质 四、生命周期和文档 五、软件保障 六、通用软件开发 七、已有软件 八、根据应用数据/算法配置的系统 九、软件部署和软件维护 2015-10-26 16 五、软件保障 软件测试 软件验证 软件确认 软件评估 软件质量保障 变更控制 工具安全保障 2015-10-26 17 五、软件保障软件测试 目标 通过测试案例的输入、输出来检查软件的行为，并且测试 应达到指定覆盖率的要求。 测试分类 软件组件测试 软件集成测试 软硬件集成测试 软件确认测试 2015-10-26 18 五、软件保障软件测试 测试规范要求 测试规范应描述以下内容： 测试目标 测试案例、测试数据、预期结果 测试类型 测试环境、工具、配置和程序 测试通过标准 测试覆盖率要求 测试人员的角色职责 对输入文档的追溯关系 实际选择的测试设备 2015-10-26 19 五、软件保障软件测试 测试报告要求 测试报告应描述以下内容： 测试结论 测试覆盖率及测试完成程度 缺陷记录 每一个测试案例的测试结果记录 测试应可重复，如果可行，最好可以自动执行 测试脚本应被验证 所有测试涉及的项都应被记录（如被测对象、软硬件 配置、测试环境、对应的测试规范版本等） 测试人员姓名 2015-10-26 20 五、软件保障验证和确认 验证和确认 验证是用于判定生命周期各阶段的输出符合该阶段输入要 求的行为（完整性、正确性、一致性）。 确认是用于判定最终软件满足其安全完整性要求、满足软 件需求及预期应用要求的行为。 2015-10-26 21 需求 确认 实现 设设 计计 测测 试试 验证验证 五、软件保障软件质量保障 目标 确定、监控能使软件达到要求的质量所必须采取的所有技 术和管理活动。 要求 计划 基本质量保障系统 软件质量保障计划 软件质量保障验证报告 配置管理 外部供应商管理 2015-10-26 22 五、软件保障软件质量保障 要求 可追溯性要求。 需求-设计-实现 需求-确认测试/分析验证 结构设计-集成测试/分析验证 模块设计-模块测试/分析验证 2015-10-26 23 五、软件保障变更控制 目标 确保软件在变更时仍能满足安全完整性和可靠性的要求。 要求 变更管理过程的相关要求： 问题报告和改正措施相关文档； 原因分析； 报告、追踪、解决问题的相关步骤； 变更影响分析； 再验证、再确认、再评估； 2015-10-26 24 第五部分：软件保障变更控制 要求 所有变更都应发起一个到达适当生命周期阶段的回退。 该阶段之后的所有阶段都应根据本标准的要求重新执 行其指定的程序。 2015-10-26 25 第五部分：软件保障变更控制 变更实施的关键 根据变更的原因找到回退点。 进行变更影响分析后确定后续各阶段的工作范围。 包括需求、设计实现、测试、验证、确认等。 判断变更是否对用户输出文件产生影响，有影响时应 更新输出文件 如SRAC、数据配置、安装手册、应用手册、操作说明书、维护 说明书、工艺文件、测试工装等。 2015-10-26 26 五、软件保障工具安全保障 目标 确保工具的潜在失效不会对软件产生不能通过技术和/或 管理手段检测出的安全相关影响。 工具分类 2015-10-26 27 分类分类 定义定义 举例举例 T1 输出不会对软件可执行代码（含数据）产生 直接或间接影响的工具 文本编辑器、 配置管理工具 T2 支持对设计或可执行代码进行测试或验证的 工具，工具的错误会导致不能发现缺陷，但 不会使可执行代码产生直接的错误 动态测试工具、 静态分析工具 T3 输出会对软件可执行代码（含数据）产生直 接或间接影响的工具 编译器、链接 器、数据准备 工具 五、软件保障工具安全保障 要求 对于T2、T3类工具，应 具有使用说明书，能清晰定义工具的行为及使用限制； 确认选择的工具适合于应用； 识别工具潜在的失效，并提出避免或控制方法。 2015-10-26 28 内容安排 一、范围 二、软件安全完整性等级 三、组织结构、角色和资质 四、生命周期和文档 五、软件保障 六、通用软件开发 七、已有软件 八、根据应用数据/算法配置的系统 九、软件部署和软件维护 2015-10-26 29 六、通用软件开发 软件需求阶段 结构设计阶段 组件设计阶段 组件实现和测试阶段 集成阶段 确认测试/最终确认阶段 2015-10-26 30 六、通用软件开发软件需求 目标 为了使软件能满足所有系统需求和安全需求而对其要求进 行完整描述，并为后续各阶段参考提供的综合性文档。 输入文档 系统需求规范 系统安全需求规范 系统结构设计 外部接口规范（如软/软件接口规范、软/硬件接口规 范） 外部限制条件（SRAC） 2015-10-26 31 六、通用软件开发软件需求 六、通用软件开发软件需求 要求 软件需求规范应对如下软件属性软件属性进行描述： 功能性功能性 包括容量和响应时间 健壮性健壮性 容错能力、恢复能力 可维护性可维护性 如软件调试接口、诊断信息输出 安全性安全性 包括安全功能和安全完整性等级 效率效率 时间占用、空间占用 可用性可用性 人机界面如操作系统移植、平台移植 可移植性可移植性 2015-10-26 32 六、通用软件开发软件需求 要求 对软件需求规范如何描述的要求。软件需求规范的描 述应： 完整完整 清晰清晰 准确准确 无二义无二义 可验证可验证 可测试可测试 可维护可维护 可行性可行性 对输入文档可追溯对输入文档可追溯 2015-10-26 33 六、通用软件开发软件需求 要求 软件需求规范应使用让整个生命周期所涉及的责任人 员都易理解的表达方法； 软件需求规范应明确受控设备与其他系统的所有接口， 包括与操作员的接口； 软件需求规范应明确所有相关的操作方式； 2015-10-26 34 六、通用软件开发软件需求 要求 软件需求规范中应明确或引用可编程电子器件所有相 关的行为模式，尤其是失效行为； 软件需求规范中应明确或引用软硬件之间的约束关系； 软件需求规范中应指出软件自检的程度及软件检测硬 件的程度； 2015-10-26 35 六、通用软件开发软件需求 要求 软件需求规范中应根据系统安全需求规范的要求包括 周期性功能检测需求； 软件需求规范应根据系统安全需求规范的要求包括使 所有安全功能在整个系统运行期内可测试的需求； 2015-10-26 36 六、通用软件开发软件需求 要求 所有分配由软件完成的功能，特别是那些与实现系统 安全完整性等级有关的功能，软件需求规范应对其加 以清楚说明；（明确安全功能） 当要求软件来完成非安全功能时，软件需求规范应对 其加以清楚说明；（明确非安全功能） 2015-10-26 37 六、通用软件开发软件需求 要求 软件需求规范相关的技术和措施要求参见Annex A.2 2015-10-26 38 七、已有软件的使用 已有软件在使用时应遵循以下限制： 应清晰识别并文档化以下内容： 已有软件的功能及预期满足的需求 已有软件的使用限制 已有软件的接口说明 已有软件必须包含在整体软件确认范围内； 2015-10-26 39 七、已有软件的使用 已有软件在使用时应遵循以下限制： 对于SIL3/SIL4级的软件： 应对已有软件进行失效影响分析； 应针对分析出的失效制定检测策略及防护措施； 验证和确认过程应确保： -已有软件能满足被分配的需求； -已有软件的失效能被检测及有效防护； -已有软件的使用限制被满足。 2015-10-26 40 内容安排 一、范围 二、软件安全完整性等级 三、组织结构、角色和资质 四、生命周期和文档 五、软件保障 六、通用软件开发 七、已有软件 八、根据应用数据/算法配置的系统 九、软件部署和软件维护 2015-10-26 41 八、应用数据/算法配置的系统 目标 铁路系统的一个显著特征是需要为满足各特定应用的 需求设计装置。由应用数据/算法配置的系统允许使用 认证过的通用软件，每个装置的特定需求应被定义成 数据/