📚 课程目录第2章功能安全基础

2. 功能安全基础

在RH850功能安全与故障监控工程中，所有技术决策最终都要回到ISO 26262的术语体系和流程框架。只有先把“什么是危害、什么是安全目标、ASIL如何定级、生命周期如何闭环”这些基础概念对齐，后续的故障监控、安全机制配置和验证活动才有共同语言。本节围绕四个核心问题展开：关键术语如何定义、ASIL等级如何确定、安全生命周期如何运转、安全目标如何落地为可验证的技术要求。

一、关键术语：从危害到安全目标的语义链

ISO 26262的术语不是孤立名词，而是一条从“危险来源”到“可验证要求”的语义链。理解这条链，才能避免在工程中把“故障”和“失效”混用、把“安全目标”写成一句空泛口号。

危害（Hazard）：由车辆行为异常导致的潜在伤害来源，例如“电机意外输出扭矩”。
危害事件（Hazardous Event）：危害与运行场景的组合，例如“车辆低速行驶时电机意外输出扭矩”。
风险（Risk）：危害事件发生的概率与其后果严重度的组合。
安全目标（Safety Goal）：针对危害事件的顶层安全要求，用于将风险降低到可接受水平，例如“避免电机意外输出扭矩”。
功能安全概念（FSC）：把安全目标分解为功能层面的安全要求，并分配到架构元素。
技术安全概念（TSC）：把功能安全要求细化为硬件、软件、接口层面的技术安全要求。
安全机制（Safety Mechanism）：用于检测、控制或缓解故障的技术手段，如看门狗、锁步核、ECC、CRC。
故障（Fault）：可能导致失效的异常状态；失效（Failure）：功能终止或错误执行。
ASIL：汽车安全完整性等级，衡量安全目标所需的风险降低程度。

记忆要点：危害是“可能造成伤害的车辆行为”，安全目标是“要阻止这种行为”，FSC/TSC是“怎么阻止”，安全机制是“用什么手段阻止”，ASIL是“阻止的严格程度”。

二、ASIL等级：风险三要素决定严格程度

ASIL等级由三个维度共同决定：严重度（S）、暴露率（E）和可控性（C）。严重度描述伤害程度，暴露率描述运行场景出现的频繁程度，可控性描述驾驶员或其他人员能否及时避免伤害。三者组合后映射为QM、ASIL A、ASIL B、ASIL C、ASIL D五个等级，其中ASIL D要求最严格，QM表示仅需常规质量管理。

维度	含义	典型分级
S（Severity）	伤害严重程度	S0无伤害 ~ S3致命伤害
E（Exposure）	运行场景暴露概率	E0极低 ~ E4高概率
C（Controllability）	可控性，避免伤害的难易	C0完全可控 ~ C3几乎不可控

例如，制动助力失效在高速行驶场景中通常对应S3、E4、C3，最终可能定为ASIL D；而座椅调节异常在低速静止场景中可能仅为QM或ASIL A。ASIL等级一旦确定，会直接约束开发流程、验证方法、硬件失效率目标和软件测试覆盖率。

ASIL等级与典型要求对照：
ASIL D：单点故障度量≥99%，潜伏故障度量≥90%，软件MC/DC覆盖
ASIL C：单点故障度量≥99%，潜伏故障度量≥90%，软件MC/DC覆盖
ASIL B：单点故障度量≥90%，潜伏故障度量≥60%，软件分支覆盖
ASIL A：单点故障度量≥90%，潜伏故障度量≥60%，软件语句覆盖
QM  ：按常规质量管理流程执行

三、安全生命周期：从概念到报废的闭环

ISO 26262的安全生命周期不是一次性文档流程，而是贯穿概念、开发、生产、运行、服务和报废的闭环。它强调“安全活动必须与开发活动同步”，而不是在项目末期补做安全分析。

在RH850项目中，安全生命周期通常体现为：概念阶段完成危害分析与风险评估，确定安全目标和ASIL；系统阶段把安全目标分解为FSC和TSC；硬件阶段通过FMEDA计算单点故障度量和潜伏故障度量；软件阶段按ASIL选择编码规范、测试覆盖率和安全机制；最后通过安全确认证明安全目标达成。

四、安全目标落地：从一句话到可验证参数

安全目标不能停留在“避免意外扭矩”这种描述，必须转化为可验证的技术参数。以电机控制为例，安全目标“避免电机意外输出扭矩”可分解为：

功能安全要求：在检测到扭矩控制异常后，应在规定时间内进入安全状态。
技术安全要求：RH850的PWM输出模块需具备寄存器锁保护，看门狗需在10ms内复位。
安全机制：锁步核比较、ECC保护、CRC校验、窗口看门狗、PWM输出使能回读。
验证指标：故障检测时间≤10ms，安全状态达到时间≤20ms，单点故障度量≥99%。

安全目标的可验证化，是功能安全从“文档合规”走向“工程可信”的关键一步。没有量化指标的安全目标，无法在RH850的故障监控配置中落地。

五、常见误区与复盘

误区一：把ASIL等级当成软件等级。ASIL是安全目标的属性，会分配到硬件、软件和系统层面，不能简单等同于“软件ASIL”。
误区二：安全目标写成技术方案。安全目标应描述“避免什么”，而不是“用什么芯片、用什么看门狗”。
误区三：忽视可控性。可控性C直接影响ASIL等级，驾驶员能否及时接管是定级的重要输入。
误区四：生命周期只做前半段。生产、运行和服务阶段的安全活动同样需要闭环，否则现场故障无法反馈到设计。

复盘建议：在RH850功能安全项目中，建议建立“安全目标—FSC—TSC—安全机制—验证指标”的追溯矩阵，确保每个安全目标都能追溯到具体的硬件模块、软件配置和测试用例。这样既能满足ISO 26262的追溯要求，也能在故障监控调试时快速定位安全机制的覆盖范围。