1. 基本介绍

1.1 适用范围

• 1.1.1 产品安全

• 1.1.1.1 功能安全

• 1.1.1.2 非功能安全

• 1.1.1.3 SOTIF

• 1.1.1.4 误用

• 1.1.1.5 属于多个安全类别的危害

• 1.1.2 安全生命周期

1.2 适用性

1.3 受众目标

1.4 关键概念

• 1.4.1 故障 vs. 失效 vs. 非预期事件

• 1.4.2 故障规避 vs. 故障容错

• 1.4.3 非预期事件的5个级别

• 1.4.4 安全需求 vs. 安全概念

• 1.4.5 可追溯性

• 1.4.6 验证测试vs. 认可测试

1.5 功能安全总体流程介绍

1.6 功能安全相关角色

1.7 与其他工程活动的接口

• 1.7.1 与软件开发过程的接口

• 1.7.2 与硬件开发流程接口

• 1.7.3 与可靠性活动接口

• 1.7.4 与生产的接口

• 1.7.5 与机械零件的接口

1.8 DFMEA vs. PFMEA vs. Safety FMEA

1.9 参考及适用文件

2. 系统级功能安全开发流程

2.1 过程流程图

2.2 活动指南

• 2.2.1 初始危害分析

• 2.2.2 影响分析

• 2.2.3 复用性分析

• 2.2.4 开发接口协议

• 2.2.5 安全开发计划

• 2.2.6 安全审核

• 2.2.7 功能安全概念

• 2.2.8 安全分析

• 2.2.9 在模型或模型上注入故障

• 2.2.10 安全测试策略

• 2.2.11 安全验证报告

• 2.2.12 安全用例

2.3 平台项目中，系统级功能安全实践指南

• 2.3.1 项目立项的前置安全活动

• 2.3.2 需求冻结的前置安全活动

• 2.3.3 设计冻结的前置安全活动

• 2.3.4 工具运行的前置安全活动

• 2.3.5 SOP准备的前置安全活动

2.4 应用项目中，系统级功能安全实践指南

• 2.4.1 阶段1：目标定义

• 2.4.2 阶段2：可行性确认

• 2.4.3 阶段3：设计验证

• 2.4.4 阶段4：流程验证

• 2.4.5 阶段5：流程启动和稳定性确认

3 组件级功能安全流程

3.1 过程流程图

3.2 活动说明

• 3.2.1 初始危害分析

• 3.2.2 影响分析

• 3.2.3 复用性分析

• 3.2.4 开发接口协议

• 3.2.5 安全开发计划

• 3.2.6 安全审核

• 3.2.7 功能安全概念

• 3.2.8 安全分析

• 3.2.9 在模型或模型上注入故障

• 3.2.10 安全测试策略

• 3.2.11 安全验证报告

• 3.2.12 安全用例

3.3 平台项目中，组件级功能安全实践指南

• 3.3.1 项目立项的前置安全活动

• 3.3.2 需求冻结的前置安全活动

• 3.3.3 设计冻结的前置安全活动

• 3.3.4 工具运行的前置安全活动

• 3.3.5 SOP准备的前置安全活动

3.4 应用项目中，组件级功能安全实践指南

• 3.4.1 阶段1：目标定义

• 3.4.2 阶段2：可行性确认

• 3.4.3 阶段3：设计验证

• 3.4.4 阶段4：流程验证

• 3.4.5 阶段5：流程启动和稳定性确认

(点击文末"阅读原文"了解)

1. 基本介绍

1.1 适用范围

本文属于「SysPro | 汽车功能安全最佳实践体系」16个版块中版块一<功能安全方法论>内容。本文目的：概述功能安全流程，其中包含所有要求ISO26262所述需求，并解释了不同功能安全活动的目标、它们之间的相互关系以及它们与其他开发活动的关系。

图片来源：SysPro系统工程智库

功能安全的范围：功能安全是产品安全的子集（参见第1.1.1节），涵盖了安全生命周期的概念阶段和产品开发阶段（参见第1.1.2节）。

功能安全的适用性：「SysPro | 汽车功能安全最佳实践体系」中所涉及安全活动会针对平台项目、应用项目有所区分。对于新平台的项目，安全活动需要与PM里程碑同步（参见第2.3节、第3.3节）；对于基于平台的应用项目，在平台安全活动基础上进行裁剪（参见第2.4节、第3.4节）。

功能安全的层级性：对于如汽车动力系统的复杂系统而言，「SysPro | 汽车功能安全最佳实践体系」对安全活动进行了层级划分，分为：系统功能安全开发和组件级功能安全开发，这部分内容会在后续详细展开。

• 功能安全
• 非功能安全
• 误用
• 预期功能安全(SOTIF)

-> 功能安全

功能安全活动需要符合ISO26262范围要求。

功能安全主要为了解决由E/E系统故障行为引起的潜在危害(Hazards)。这一类功能安全危害(Hazards)是由HW或SW故障引起的，这些故障通过SW和HW中实现的功能进行传播，导致系统故障，从而产生危险。举例说明下，功能安全范围内的危害（或非预期事件）：

• 由于车身控制器中的硬件故障，意外关闭低压网络

• 由于电动转向系统的软件错误导致过度转向

• 由于高压热管理系统的错误调节而发生火灾

图片来源：网络

• 在湿气和化学污染的情况下，由低压印刷电路板上的绝缘缺陷引起的火灾

• 高压产品上的绝缘缺陷引起的电击现象

-> 预期功能安全（SOTIF）

• 由于饮料金属在汽车前方道路上的滚动，使用雷达对自动紧急制动系统进行意外制动

• 由于障碍物被吸光材料覆盖，自动泊车系统没有在障碍物前刹车

图片来源：LHP Inc.(电子书已上传知识星球)

-> 误用

误用是指用户在使用产品时，以制造商或服务提供商不期望的方式使用产品，这可能导致产品失效或产生潜在危险。误用可能来源于对系统性能的过度信心、用户操作不当或缺乏必要的操作知识。有三种不同的误用类别：

• 误用本身导致的危害，或

• 与系统性故障融合导致的危害（ISO26262）或

• 与非预期的系统行为融合导致的危害（SOTIF）

注：如果是因误用导致危害与功能安全范畴内的失效相关，则本文档适用于。

• 自动紧急制动系统
• 故障：导致前车意外制动
• 误用：驾驶员的尾部车辆未满足最小安全距离
• 自动泊车系统
• 故障：导致无法检测到行人
• 误用：驾驶员未监控驾驶环境

举例说明下，由于SOTIF意外行为和误用组合而产生的危险(SOTIF)：

• 车道保持辅助

• 意外行为：错误检测到车道标记，导致意外的自动转向操作

• 误用：驾驶员未将手握在方向盘上

• 概念阶段，
• 开发阶段，但不包括
• 软件功能安全方法涵盖的软件开发
• 硬件功能安全方法涵盖的硬件开发
• 生产经营计划阶段

• 对于EE相关的系统级项目：如果有任何具有ASIL属性的非预期事件被PHA识别，则参考本指南第2章所述的系统级安全活动指南。
• 对于EE相关的组件级项目：如果有任何具有ASIL属性的安全要求被识别，则参考本指南第3章所述的组件级安全活动指南。
• 对于EE不相关的的项目：本指南不适用。

| SysPro备注：一些OEM将具有ASIL属性的安全需求分配给纯机械组件，即使在这种情况下，ISO 26262要求也不适用，因此本说明不适用。一般而言，会将分配给机械的安全要求转化为可靠性要求或SPPC要求

1.4 关键概念

| SysPro备注：为保证本指南与ISO 26262原始内容统一，这里概念名词不做翻译，保持英文。

(故障 vs. 失效 vs. 非预期事件)

• Failure：指元件或系统无法按要求执行功能。
• Fault：指元件或系统的异常，可能导致元件或系统发生的故障，因此，Fault是产生Failure的原因。
• Undesirable Event(UE)：是系统或部件的失效模式，属于非预期的顶事件，例如非预期加减速等。

| SysPro 注释：Failure也可能是上一级系统的Fault。举例说明下：DC/DC的内阻短路，这是一个Fault，可能导致DC/DC转换器输出电压降为0的Failure；进一步可能导致所嵌入DC/DC的ECU故障（Failure）

Fault avoidance：在项目开发中，有一些安全活动（例如，设计审查），专注于规避一些可能导致非预期事件的潜在的root causes事件，例如需求规范的定义错误、或概念设计的错误等。

Fault tolerance：在项目开发中，还有一些安全活动（例如，安全分析、安全概念的定义），旨在控制故障的影响，以避免其传播导致关键非预期事件。为了控制故障的影响，我们需要定义和实施专用的安全机制，例如自检和切换机制，以便在检测到关键内部故障时将系统置于安全备份的模式。

功能相关的UE 根据其关键性，分为5个关键性等级（critical level)：QM、ASILA 、ASILB、ASILC、ASILD。安全等级的定义主要从以下三个维度考虑:

• 影响的严重性(Severity)
• UE可能导致事故的可能性(Exposure)
• 面临危险情况的人员避免事故的可能性(Controllability)

图片来源：网络

• 功能安全里特指的UE是功能性的，对于非功能性 UE 根据其影响的严重性进行评级，针对特定客户采用不同策略，如DFMEA中10
• 我们上面提的Hazard就是具有 ASIL性质的系统级非预期事件
• 关于UE评级方法的详细解释会在后续PHA指南中说明

Safety Requirements：定义了我们想要的安全属性，包括功能要求、性能要求、故障处理要求等，以确保所设计和实现的系统能够满足安全目标。系统的顶级安全要求是安全目标，每个具有ASIL的系统UE都有其相应的安全目标。

Safety Concepts：定义了对系统安全性的整体规划和设计，在ISO 26262标准中，安全概念通常包括功能安全概念（Functional Safety Concept）和技术安全概念（Technical Safety Concept），以确保系统在发生故障时仍能够提供达到预期安全水平的功能。

• V模型"上下"的可追溯性：ISO26262 需要确保从SG到HW和SW架构的安全需求在两个方向上的可追溯性
• V模型"左右"的可追溯性：还需要确保不同等级安全需求与相应测试用例之间的可追溯性。

Verification&Validation的目标：确保系统或组件在预期的使用环境中满足预期用途。

Verification和Validation，两活动基于测试、评审、分析、模拟等手段开展的，具体说明下两者的区别：

Verification 目的：在ISO26262中有定义，Verification 是确定需求规范的完整性和合理性，或者说满足上一个阶段的设计实施需求。通俗点说，就是要确保系统或组件满足其设计需求，即确认我们的产品，是否是按正确的要求设计的？

Validation 目的：在ISO26262中有定义， Validation是确保系统需求对于在预期环境中的预期用途是正确的，即确认我们的产品，是否是我们需要的东西？

因此，Verification活动适用于所有级别（车辆级、系统级、组件级、HW、SW），而Validation 仅适用于车辆级别的验证，因此，Validation 也仅适用于系统项目。

以上是关于「SysPro | 汽车功能安全最佳实践体系」16个版块中<版块一：功能安全方法论>内容(节选)，关于<功能安全方法论>完整版内容会在知识星球「SysPro | 汽车功能安全」 专栏发布（持续建设中），欢迎阅读学习。对这方面感兴趣的伙伴，也可以结合6月更新的<功能安全方法论培训视频>系列课程一并查阅。

「SysPro系统工程智库」让我们未来会更好，

感谢新老朋友们的关注和支持，共同成长！

感谢你的阅读，共同成长！

2024年10月9日 晚