ISO26262道路车辆功能安全标准-（4）系统级产品开发

目录

引言

系统级产品开发启动

技术安全需求制定

系统设计

项目集成和测试

安全确认

功能安全评估

产品发布

---

引言

系统级产品开发活动主要包括：启动、需求制定、设计、集成测试、安全确认、安全评估、产品发布。下面分别讲述不同阶段活动的目的和实质内容。

系统级产品开发启动

1. 目标：确定和规划在系统开发各个子阶段的功能安全活动。
2. 图一是系统级产品开发流程图。

图一 系统级产品开发流程示意图

技术安全需求制定

1. 目标：（1）规范技术安全需求，主要是功能安全需求的细化；（2）通过分析技术安全需要进而验证符合功能安全需求。
2. 技术安全需求应指明安全相关的依赖关系，系统之间、项目之间、项目与其他系统之间。
3. 技术安全需求应指定系统或要素达到安全目标的影响因素。
4. 技术安全需求规定的必须的安全机制包括：
   1. 系统本身的检测。
   2. 与系统交互的外部设备的故障控制措施的检测与指示。
   3. 使系统达到或维护安全状态的措施。
   4. 细化和实现警告和降级的措施。
   5. 防止故障被隐藏的措施。
5. 在上述规定的安全机制中，使系统达到或维持安全状态的措施应规定：
   1. 安全状态的切换。
   2. 容错的时间间隔。
   3. 应急操作的时间间隔。
   4. 维持安全状态的措施。
6. 潜在故障，一般只有在多点故障有可能包含它。
7. 适用于ASILs的技术安全需求应避免多点故障失效，确定多点故障检测间隔，应考虑以下因素：
   1. 根据硬件可靠性，考虑硬件在体系中的角色。
   2. 相应的危险事件曝光概率。
   3. 由违反安全目标的硬件随机失效概率规定量化目标值。
   4. 安全目标的ASIL等级。

系统设计

1. 目标：进行系统设计、开发符合项目技术安全需求规范的功能要求。
2. 关于技术安全的实现，在系统设计中应考虑如下问题：
   1. 系统设计的可验证性。
   2. 软件硬件的技术实现性。
   3. 系统集成中的执行测试能力。
3. 系统架构设计约束：系统和子系统应该满足各自ASIL等级的技术安全需求。
4. 安全相关的内部和外部接口应该被定义，避免其他因素影响安全相关的接口。
5. 在系统设计安F全分析，根据因果分析和预测分析找出系统故障的原因和影响。
   1. 因果分析措施：故障树、可靠性方框图、石川图。
   2. 预测分析措施：FMEA、事件树、马尔科夫模型。
6. 模块化系统设计属性：
   1. 分层设计。
   2. 清晰定义的接口。
   3. 避免不必要的复杂软硬件组件。
   4. 避免不必要的复杂接口。
   5. 后期服务的可维护性。
   6. 开发运行过程中的可测试性。
7. 软硬件接口规范（HSI）应包括下面属性：
   1. 硬件设备的工作模式和相关的配置参数。
   2. 确保单元之间的独立性和支持软件分区的硬件特性。
   3. 共享和专用硬件资源。
   4. 硬件设备的获取机制。
   5. 每个涉及技术安全概念的时序约束。
8. 硬件和其使用的软件相关诊断功能，在HSI中应规定
   1. 硬件诊断功能定义，如过热、过流、短路。
   2. 在软件中实现的硬件诊断功能。
9. 软硬件接口规范在系统设计中定义，在硬件开发和软件开发时被进一步细化。
10. 产品运行、维护和关闭要求应包括如下功能：
    1. 安装说明要求。
    2. 安全相关的特殊说明。
    3. 确保系统或元件正确识别的要求，如标签。
    4. 产品的核查方法和措施。
    5. 诊断数据和售后服务要求。
    6. 关闭要求。
11. 系统设计应遵守和具备安全概念，相关验证方法如下：
    1. 系统设计审查。
    2. 系统设计走查。
    3. 仿真。
    4. 系统原型和车辆测试。
    5. 系统设计分析

项目集成和测试

1. 项目集成和测试的三个阶段：
   1. 集成每个项目包含的元件的硬件和软件。
   2. 将一个项目所有元件集成一个完整的系统。
   3. 项目与车辆周围系统的集成。
2. 集成和测试的两个目标：
   1. 根据ASIL等级和安全需求规范测试各项安全要求。
   2. 验证系统设计覆盖的安全要求正确的由整个项目实施。
3. 集成测试用例生成方法：
   1. 需求分析。
   2. 外部和内部接口分析。
   3. 软硬件集成等价类分析。
   4. 边界值分析。
   5. 功能依赖分析。
   6. 公共限制条件、时间序列和故障源分析。
   7. 环境条件和操作运行分析。
   8. 现场经验分析。
4. 项目各阶段所用测试方法对比。

	软硬件级	系统级	整车级
技术安全需求	基于需求的测试。 故障注入测试。 背靠背测试。	基于需求分析。 故障注入。 背靠背测试。	基于需求分析。 故障注入。 长期测试。 用户真实测试。
功能性能、精度、安全机制的时序正确性	背靠背测试。 性能测试。	背靠背测试。 性能测试。	性能测试。 长期测试。 用户真实测试。
内外部接口一致性和正确性	外部接口测试。 内部接口测试。 接口一致性检查。	外部接口测试。 内部接口测试。 接口一致性检查。 交互/通信测试。	外部接口测试。 交互/通信测试。
安全机制诊断覆盖率的有效性	故障注入测试。 错误猜测测试。	故障注入。 错误猜测。 根据现场经验测试。	故障注入。 错误猜测。 根据现场经验测试。
鲁棒性	资源使用率测试。 负荷测试。	资源使用率测试。 压力测试。 在一定条件下的抗干扰性和鲁棒性测试。	资源使用率测试。 压力测试。 在一定条件下的抗干扰性和鲁棒性测试。 长期测试。

安全确认

1. 目标：（1）提供符合安全目标和适用于该项目的功能安全概念的功能安全性证据。（2）提供的证据是正确的、完整的，在车辆级别可以实现的。
2. 一个项目的集成元素包括系统、软件、硬件、其他技术元素、外部措施。
3. 项目的安全目标应包括以下目标：
   1. 可控性。
   2. 控制随机和系统故障的安全措施的有效性。
   3. 外部措施的有效性。
   4. 其他技术中元素的有效性。
4. 安全目标确认的方法有：
   1. 使用指定的测试程序、测试案例、通过/失败的标准进行重复的测试。
   2. 分析，例如FMEA、FTA、ETA、仿真。
   3. 长期测试，如车辆行驶时间和测试车队。
   4. 用户测试、盲目测试、专家测试。
   5. 复审。

功能安全评估

1. 目的：评估已通过实现的项目功能安全。
2. 功能安全责任的组织（车辆、制造商、供应商）启动功能安全的评估。

产品发布

1. 目的：发布产品的标准，确认项目在车辆级符合功能安全要求。
2. 产品功能安全发布文档应包含下列信息：
   1. 负责发布的人的名称和签名。
   2. 项目发布的版本。
   3. 项目发布的配置。
   4. 相关的参考文档。
   5. 发布日期。