功能安全（Functional Safety）

功能安全做事的总骨架是"沿过程从概念走到运营、每个过程都产出 标准 / 方法 / 输出 三层物料"。把这张图刻在脑子里，所有 ISO 26262 子页、机制页、案例页就能各回各位——左侧（概念 + 风险）决定要做什么、中段（HW + SW）决定怎么做、右侧（验证 + 持续）决定证据齐不齐。

三个独立标准要并存：ISO 26262 管 E/E 故障（本页主线）、ISO 21448 SOTIF 管"功能本身性能不足"（没坏但表现不及预期，如 ADAS 雨天误检）、ISO 21434 Cybersecurity 管"网络攻击导致功能失效"。三者各自有方法和产出物，任何一个缺失都不能算"安全完备"——L3+ ADAS 三者同时必做。

下面再钻进 ISO 26262 这条主线 — IEC 61508 母标准在汽车域的剪裁逻辑、SIL 与 ASIL 的对应关系。

功能安全标准的根基是 IEC 61508（1998 年通用母标准），它定义了 SIL 等级、V 模型、Safety Lifecycle 这套共通骨架；然后航空（DO-178C）、汽车（ISO 26262）、铁路（EN 50128）、机械（IEC 62061）、过程工业（IEC 61511）等各自做行业剪裁。理解 IEC 61508 = 同时理解所有功能安全标准的骨架——只是各行业的"等级"名字和评级维度不同。

下表把功能安全里的核心 concept 全部映射到 atomic 子页——这是 hub 的"下钻入口"，按主题进入即可，不必通读本 hub。

ASIL 不是工程师拍脑袋定的——是 HARA 评估出来的，S × E × C 三维查表得 ASIL 等级。下面这张表说的是"行业经验下这类功能通常落到哪个 ASIL"，作为快速参照，真实项目还是要走 HARA 流程。

QM 的含义：不是"不重要"，而是"失效不会造成安全事故"，所以不需要功能安全流程——普通的质量管理（QM = Quality Management）足够。

EPS 失效场景的完整 ASIL 推导示例：高速公路行驶中 EPS（电动转向）突然失效。S：方向盘助力失效 → 驾驶员力量不足以控制 → 车辆偏离车道 → 可能致命 → S3；E：高速公路是日常驾驶常用场景 → E4；C：100 km/h 时瞬间失去转向助力，即使驾驶员经验丰富也非常困难 → C3。查表 S3 × E4 × C3 = ASIL D。这意味着控制器需要双核锁步 MCU、独立 Checker、冗余电源、ISO 26262 Part 3 完整 HARA + FSC、Part 4/5/6 完整 V&V、第三方独立评估和 Safety Case 归档——开发成本是普通控制器的 5–10 倍。

完整 S / E / C 等级定义与查表见 topic-iso26262-part3-concept。

HARA（Hazard Analysis and Risk Assessment） 是 ISO 26262 Part 3 的核心，把抽象的"安全"要求具体化为可操作的安全目标。关键发现：ASIL 是工况相关而不是部件固有——同一个电机控制器在不同工况下可以从 A 到 D 跨多个等级。HARA 必须穷举工况，不能只考虑"标称工况"。

Safety Goal → FSR → TSR → HSR/SSR 是从顶层目标一路细化到硬件/软件需求的标准链路。FTTI（Fault Tolerant Time Interval） 是这条链最容易被忽视的数字——它决定了诊断 + 反应整链的实时预算，必须在 Part 3 就定下来。

ISO 26262 Part 5 用三个独立指标量化硬件安全度量，三者从不同维度评价同一件事：SPFM 看"诊断能不能在单点故障发生时及时发现"、LFM 看"诊断能不能在潜伏故障变成第二点故障前发现它"、PMHF 看"整体危险失效率是否够低"。三者必须同时达标才算硬件 ASIL 合格——任一指标卡线就要返工诊断。详见 topic-iso26262-part5-hardware。

双核锁步是实现 ASIL D 的主流硬件架构——两个 core 跑同一段代码，每个时钟周期比较输出。Infineon AURIX 2G、NXP MPC57xx、Renesas RH850 都把 lockstep + ECC + MBIST + Safety Manager Unit 集成到芯片里，并发布 Safety Manual + SEooC 评估证据。

锁步硬件在每个时钟周期把两路 core 的输出送进比较器,正常工作时序如下:

而潜伏故障(LFM 关注对象)的演化路径与单点故障不同 — 它先静默存在,等第二次失效才显现:

FMEDA 是把元件 $\lambda$（来自 SN 29500 / IEC 62380 / FIDES）+ DC（来自 Safety Manual / 故障注入 / formal）逐元件累加得到 SPFM / LFM / PMHF 的工程载体——所有 ASIL ≥ B 的硬件都要做。

ASIL 分解 允许把一个高 ASIL 安全目标分解给两个独立的子系统，每个负担更低 ASIL，从而把开发成本压下来。ISO 26262-9:2018 Clause 5 对 ASIL D 只列三种合法组合（D = D + QM、D = C + A、D = B + B）——分解无顺序之分，D = A + C 与 D = C + A 完全等价、同样合法；真正非法的是等级和不足的 D = B + A 或单侧不足的 D = C + QM；分解后两路必须独立——不共享电源 / 时钟 / 软件库 / 通信总线 / 算法，并且 DFA 必须证明所有可能共因都被分析过。

冗余 ≠ 分解：冗余只是分解的充分条件之一，还要求两侧独立和 DFA 通过；软件拷贝两份不算分解，因为同一 bug 在两份拷贝里同时出现是共因失效。

ASIL 等级和"故障后系统去哪"这件事是两个独立维度——很多人以为 ASIL D 必须 fail-op，但其实是 Hazard 决定策略,不是 ASIL 决定。EPS 是 ASIL D 但 fail-safe（车在路边停下来司机机械接管），而 L4 自动驾驶哪怕 ASIL B 也必须 fail-operational（司机注意力已转移、没法接管）。先问"系统是否存在安全态",再决定单通道 / 双通道 / 三冗余。

判断口诀:故障检出后系统进入的状态 → 是否还在 Safety Goal 容忍范围内 → 在 → fail-safe / fail-degraded;不在 → 必须 fail-op。Fail-op 的成本是单通道的 2-3 倍,所以不要无脑做 fail-op——先 HARA 证明必须。

四把尺回答不同问题，不是替代关系：

四件套的协同顺序：FTA 从 Safety Goal 顶向下拆 → FMEDA 在基事件层给定量数字 → DFA 横向检查 FTA"与门"两侧是否真独立 → FSA 最后做组织独立的确认。

AIAG-VDA 2019 把传统 FMEA 的 RPN（S × O × D 相乘）改成 AP（Action Priority 查表），新增 FMEA-MSR（Monitoring and System Response），把诊断覆盖率与 ISO 26262 直接挂钩——是把 FMEA 与 FMEDA 拼接的关键创新。

ISO 26262 Part 6 的核心不是"多写几条测试用例"，而是把软件开发流程约束到可分析、可验证、可追溯。ASIL D 三件套：MISRA C 编码规范落地 §5 Table 1 + 必须 MC/DC 结构覆盖 + Inspection / 故障注入 / 需求追溯齐全。详见 topic-software-safety 与 topic-iso26262-part6-software。

实施层 atomic 页按"应用案例 / 系统集成 / 交付物"三层组织——案例落到具体产品，集成讲架构选型，交付物（Safety Case + Manual）是评估通关的最终物料。

• topic-asil-d-case-studies — 主驱 Torque Safety + No Thermal Incident 端到端 ASIL D 实现
• topic-hv-inverter-iso26262-concept — HV 逆变器三种安全态（HSS / LSS / 3PO）按车速切换
• topic-mcu-sbc-asil-d-integration — MPC5643L + MC33907/08 SoR 9 模块复制 + FCCU 硬件通道
• topic-torque-safety — ASIL D 扭矩安全设计
• topic-bms-safety — BMS 功能安全
• topic-functional-safety-chip-selection — Tier-1 选 ASIL 芯片决策框架
• topic-safety-case — Argument + Evidence 结构化集合，living document
• topic-safety-manual — IC supplier 给客户的合规交付物

实战阶段最常被翻开的是"失效模式 → 缓解手段"两张速查表——按失效模式找诊断、或按诊断目录找适用机制，反向都行。

• topic-failure-mode-summary — V 模型阶段分组的失效模式 + 缓解措施总表
• topic-safety-mechanism-catalog — MCU / 电源 / 驱动 / 传感 / 通信 5 维 SM 大全
• topic-current-sensing-safety · topic-voltage-sensing-safety · topic-position-sensing-safety · topic-temperature-sensing-safety — 采样链的功能安全诊断
• topic-gate-driver-safety — 栅极驱动的功能安全诊断
• topic-thermal-safety · topic-hv-safety — 热与高压安全

功能安全标准强调 V 模型左侧前置分析，但工程师最容易跳过"从 HARA 到 SPFM/LFM/PMHF"的完整推导链。本节以一台 400 V/100 kW EV 主驱逆变器 为对象，展示 ISO 26262 Part 3→5 的端到端计算——每个数字都从上一步导出、每个门都有数值验收依据、SPFM/LFM 可用下表逐行复核。数字为教学用分配示意值（实际 λD/DC 取自各器件 Safety Manual 的 FIT 与诊断覆盖率声明），量级贴合真实 ASIL D 主驱项目。

功能安全项目最高频的失效不是技术计算错，而是 概念边界错误与流程断链。以下 7 条均来自真实评审 / 认证教训，按危害性排序。

G1（最高危）—— FTTI 语义错层：SG-01 的 FTTI = 200 ms 是系统对外承诺的"最坏情形故障-安全响应总时间"，绝不是每个子模块的超时配置值。常见误用是把 FTTI = 200 ms 直接填入 SW WDT 计时器阈值，忘记其中还要扣除故障传播延迟（总线 + 软件 FSM）和执行响应时间。正确做法：FTTI 先在 Part 3 做"检测 + 反应 + 余量"三段预算切分，每段分配给对应的 HSR/SSR，阈值只允许 ≤ 分配值。

G2 —— ASIL 标签是"芯片 vs 函数"歧义："TC397 是 ASIL D MCU"不意味着用了 TC397 就自动满足 ASIL D。芯片的 ASIL D 标签是 SEooC 在其 Safety Manual 声明的 Assumptions of Use（AoU）下论证的；若本设计的工况（FTTI / 温度 / VCC 纹波 / 接口时序）超出 AoU，芯片的 ASIL 论证对本系统无效，需补充工作。AoU 不匹配 = ASIL D 标签作废。

G3 —— DC(SPF) ≠ DC(LFM)，同机制两个数：典型误填是把 Lockstep 的单个 DC 值同时填进 DC(SPF) 和 DC(LFM) 两列。Lockstep CPU 的 DC(SPF) = 99%（任意单 bit 错在一个时钟周期内被比较器看见），但其 DC(LFM) 取决于 LBIST 周期（每次上电一次）——潜伏在 SRAM 里的软错误要等 LBIST 才能发现，DC(LFM) 一般 < DC(SPF)，因为潜伏故障的探测机会比单点故障少。

G4 —— ASIL 分解必须先过 DFA：D = B(D) + B(D) 的合法性前提是两路 真独立（分解规则本身见 ISO 26262-9 Clause 5）。ISO 26262-9 Clause 7（Dependent Failure Analysis）列了共因失效类型：共供电 / 共时钟 / 共算法 / 共通信总线 / 共 PCB 区域。DFA 必须逐类论证每条共因已被缓解（β-factor 法量化耦合强度），否则独立性论证不成立、分解违规。DFA 先行，分解结论后，不能颠倒。

G5 —— 三个 HW 指标必须同时达标：SPFM / LFM / PMHF 是三个独立维度，彼此不替代。实践中 LFM 最难——潜伏故障诊断机会受 Tlatent 限制（ASIL D 要求 Tlatent ≤ 多点故障探测间隔），且许多工程师优先做 SPFM 而忽略 LFM。SPFM 99.3% 通过 + LFM 88% 不通过 = 整个硬件 ASIL D 不通过，必须返工诊断路径。

G6 —— QM ≠ 不安全、不分析：QM 的定义是"失效不直接引发安全事故"，不是"可以忽略"。若 QM 部件通过因果链触发 ASIL D 部件失效（如 QM EEPROM 配置错误影响 ASIL D 扭矩限制），该传播路径必须在 DFA 中分析和缓解。遗漏此类"QM 触发 ASIL D"路径是评估 NC（不符合项）的高频点。

G7 —— Safety Case 生命周期断链：ISO 26262-2（Management）要求 Safety Case 是活文档——软件 OTA 升级 / 替代器件 / 生产批变更均可能触发影响域重评（δ-Assessment）。"首次 TÜV 认证通过 = 永久有效"是错误理解。OEM 在车辆整个生命周期内有义务维护 Safety Case，并在变更时重评影响域。未维护的 Safety Case 在 SOTIF / Cybersecurity 扩展评估中尤其脆弱。

Corner 分析处理的是"规则边界上互相打架"的场景——正常流程走得通、但两条安全要求或两种工况相撞时才暴露。以下三条是主驱 ASIL D 项目里最常见的裁决点。

C1 —— SG 冲突裁决（同时触发 SG-01 与 SG-02）：热事故与 STO 命令同时到达时 Safe State 可能冲突——SG-01 要求零扭矩（三相下臂短接维持阻尼），SG-02 要求断开 HV 继电器（消除高压暴露）。裁决原则：HV 人身安全 > 运动安全，优先级 SG-02 > SG-01。时序上先断 HV 继电器（≤ 500 ms），电机因无驱动自然减速，无需三相短接维持——两个 SG 在时间轴上串行不互斥。此裁决依据须写入 FSC，否则实现层各自解读造成竞争状态。

C2 —— L4 场景 C 参数升级：同一台控制器在有驾驶员（L2：C 可能为 C2/C3，失效后驾驶员能接管）与 L4 无人在座（C3，失效后无人接管、不可控）场景下，ASIL 与冗余架构需求不同——L4 往往要求 fail-operational（架构从 1oo1D 升至 1oo2D）。若通过 OTA 开启 L4 功能，必须在系统阶段重跑 HARA、更新 ASIL、重评 Safety Goal 与 FSR——沿用 L2 认证结论直接违反 ISO 26262 变更管理条款。

C3 —— -40°C 低温 BIST 延迟：TC397 的 LBIST 在低温下执行时间延长（物理原因：CMOS 晶体管 Vth 升高、传播延迟增加，量级约 10–20%，精确值查器件 SM 低温特性曲线）。若系统 FTTI 紧迫（如制动控制 FTTI < 100 ms），冷启动期间 LBIST 未完成前 FSM 可能进入降级安全模式，导致功能降级比 FTTI 预算提前发生。缓解策略：在 FTTI 切分阶段就纳入 BIST 最坏时间（含温度角落），或设计二阶启动（先完成 BIST 再切至全功能）。