功能安全 ISO 26262：ASIL、FMEA/FMEDA、安全机制与诊断覆盖率
更新时间：2026-09-24。上一篇 硬件安全：Root of Trust、安全启动与密钥保管 讨论的是「人在恶意攻击芯片」，本篇换一个方向：芯片自己坏了怎么办？汽车在高速公路上以 120 公里时速行驶，油门、刹车、转向全部由电子系统控制，一颗 MCU 内部任何一个触发器翻转、任何一根信号线固定为 0，都可能变成伤亡事故。车规芯片因此要按功能安全 ISO 26262 做设计和签核——它不要求硬件永不坏（物理上不可能），而要求硬件在随机失效发生时仍能被及时检测、控制，让整车进入可接受的安全状态。这是一套独立于一般可靠性和良率的完整工程体系。
本文要回答的问题
- ASIL A 到 ASIL D 是怎么评出来的？严重度、暴露率、可控性三个维度各是什么意思？
- 单点故障、潜伏故障、残余故障有什么区别，为什么潜伏故障在车检或维修前一直无人知晓？
- 双核锁步（lockstep）、ECC、窗口看门狗、BIST、安全岛这些安全机制各自检测什么故障，诊断覆盖率能做到多少？
- 诊断覆盖率（DC）、SPFM、LFM、PMHF 四个量化指标怎么算，FIT 是什么单位，ASIL D 的门限是多少？
- FMEA 和 FMEDA 表到底长什么样？芯片团队、工具链（TCL）、DIA 和安全计划在其中各承担什么责任？
一、功能安全不等于可靠性：失效不可怕，失控才可怕
先纠正一个常见误解：功能安全 ISO 26262 不是追求「零失效」的可靠性标准。可靠性工程关心的是 MTBF（平均无故障时间），希望器件尽量晚坏；功能安全关心的是器件坏了以后系统的行为——故障是否在造成危害前被检测到，车辆是否能进入降级运行或安全停车。一个典型对照是雨刷电机和电子转向：雨刷坏了只是淋雨时看不清，功能安全等级很低；电子助力转向的 MCU 输出一个错误的转矩指令，可能直接把车拽向护栏，即使失效率相同，安全要求也是天壤之别。
ISO 26262 把失效分两大类。第一类是系统性失效（systematic failure），来自设计错误、流程缺陷、工具 bug，比如 RTL 逻辑写错、约束漏设，这类失效只能靠流程（评审、验证、工具置信度评估）消除，换再多冗余硬件也没用。第二类是随机硬件失效（random hardware failure），来自硅片物理机理：电迁移、栅氧 TDDB、热载流子老化、封装键合断裂、宇宙射线导致的软翻转等，这类失效在统计意义上不可避免，只能靠安全机制检测和控制。本篇重点是第二类，也是 FMEDA 的主战场。
| 对比维度 | 一般可靠性（如 AEC-Q100） | 功能安全 ISO 26262 |
|---|---|---|
| 核心目标 | 降低失效率，延长寿命 | 故障发生后避免不合理危害 |
| 主要手段 | 降额、老化筛选、工艺认证 | 安全机制、诊断、故障响应、安全案例 |
| 量化指标 | FIT、MTBF | SPFM、LFM、PMHF、诊断覆盖率 |
| 关注的失效 | 全部失效 | 可能违反安全目标的失效 |
| 与设计的关系 | 更多依赖器件选型与工艺 | 必须在架构和 RTL 中插入机制 |
随机硬件失效的物理来源值得点名，因为 FMEDA 里的每个 FIT 数字最终都对应这些机理。永久失效随老化缓慢累积：电迁移（金属原子被电子流逐步推走，连线最终开路或短路）、栅氧 TDDB（氧化层在长期电场下击穿）、热载流子注入（高能电子损伤晶体管阈值）、负偏压温度不稳定性（NBTI，PMOS 阈值漂移）、焊点热疲劳（冷热循环让键合开裂）。瞬态失效则不留下永久损伤，主要是单粒子翻转（SEU）：封装材料和宇宙射线中的中子、α 粒子穿过硅片时产生电荷，让一个存储单元状态翻转；在先进工艺节点，组合逻辑中的瞬态脉冲（SET）也可能被触发器采样。海拔越高中子通量越大，车规场景还要考虑高原行驶。针对这些机理，设计上的对应关系非常直接：存储靠 ECC 和加固触发器（冗余互锁单元 DICE），逻辑靠锁步和重执行，老化类故障靠周期 BIST 和余量监控。
车规器件通常两者都要：先过 可靠性与 AEC-Q100：车规认证与老化 的环境与寿命考核，再按 ISO 26262 做安全分析。前者证明「不容易坏」，后者证明「坏了也安全」。还要注意，功能安全只覆盖电子电气系统的失效（E/E 系统），机械磨损、燃料泄漏这类非电气风险不在 ISO 26262 范围内，整车层面另有其他标准兜底。
二、HARA 与 ASIL：用严重度、暴露率、可控性给危害定级
功能安全 ISO 26262 的起点是 HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）。团队对整车每个功能设想各种工况下的故障（比如「刹车踏板传感器信号卡住，且一直指示全力制动」），从三个维度打分：
- S（Severity，严重度）：伤害有多重。S1 轻伤，S2 重伤，S3 危及生命或致命。
- E（Exposure，暴露率）：这种工况出现的概率。E1 极低（如车辆被拖运），E4 高（普通公路日常行驶）。
- C（Controllability，可控性）：驾驶员或其他交通参与者能否自行避险。C1 通常可控，C3 几乎无法控制。
三个维度查表合成 ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）：QM（只需常规质量管理）、A、B、C、D，D 最严。下面这张矩阵就是标准评定逻辑的浓缩，以最严的 C3 列为例：S1+E4 只到 A，而 S3+E4 直接到 D。
读图的关键是：ASIL 不是对「芯片有多复杂」的评价，而是对「这个功能一旦失效，危害场景有多危险」的评价。同一个 CPU 核，用在车窗控制里可能只需要 QM，用在电子助力转向里就要按 ASIL D 开发。等级一旦定下，它就是后续一切工作的总开关：ASIL 越高，要求的硬件度量门限越严，要求的安全机制越多，对开发流程、验证独立性、工具置信度的要求也越高。比如 ASIL D 要求硬件设计的验证有独立团队评审，而 QM 没有这类强制要求。
看一个完整的 HARA 打分例子。功能：电子助力转向（EPS）。故障：助力电机输出卡在最大转矩、持续向右。工况：高速公路直行超车。伤害 S3（可能撞击护栏或邻车，致命）；暴露 E4（高速公路日常行驶，暴露率高）；可控性 C3（120 公里时速下方向盘被拽动，驾驶员几乎无法扳回）——合成 ASIL D。换一个故障：助力完全丢失。驾驶员仍能机械转向，只是方向变沉，S2、C2，等级显著下降。同一个系统、同一颗 MCU，不同故障的 ASIL 可以不同，安全需求只保护被识别为高危的失效路径，这也是安全分析必须逐个故障场景做、不能按部件拍等级的原因。QM 则意味着该功能失效后不会造成需要安全措施的伤害，按 ISO 9001 常规质量管理开发即可，不强制任何安全机制——但 QM 结论本身必须由 HARA 分析支撑，不能默认。
实际项目中还有「ASIL 分解」（ASIL decomposition）：把一个 ASIL D 的安全需求拆成两个 ASIL B(D) 的冗余通道，只要两条通道充分独立（无共因失效），冗余后整体仍满足 D。这是成本与安全的重要折中，但独立性论证（共因失效分析）本身就是审查重点。
三、故障分类：单点、残余、潜伏与多点
要理解后面的度量，先分清一颗芯片内故障的不同处境。假设芯片里有一个寄存器可能发生固定型故障：
- 如果它没有任何安全机制保护，故障直接导致安全目标被违反，这叫单点故障（single-point fault）。
- 如果有安全机制但机制本身检测不到全部失效模式，漏掉的那部分叫残余故障（residual fault）。
- 如果故障被某个机制覆盖，但这个机制的报错信号只在车辆上电自检时才检查，于是故障在芯片里静静躺了几个月，直到第二个故障发生、两个故障组合违反安全目标——这第一个就叫潜伏故障（latent fault）。
- 需要两个或更多独立故障组合才违反安全目标的，统称多点故障（multiple-point fault），按第二个故障发生前第一个是否会被发现来评估。
潜伏故障是车规场景特有的麻烦：车不像手机每天重启，很多故障指示灯或降级机制要等维修才被读取。ISO 26262 因此要求安全机制对潜伏故障也有足够覆盖率，典型手段是周期性自检（开机 LBIST、运行中定期触发 ECC 巡检）和让故障状态可被维修设备读出。
四、安全机制：锁步核、ECC、看门狗与安全岛
针对上面每类故障，芯片要在架构阶段就插入对应的安全机制。功能安全 ISO 26262 里最核心的几种如下。
| 安全机制 | 检测对象 | 典型诊断覆盖率 | 故障响应 |
|---|---|---|---|
| 双核锁步 lockstep | CPU 核内瞬态/永久逻辑故障 | 高（>90%） | 报错、复位、切冗余核 |
| ECC（SEC-DED） | SRAM/Flash 位翻转、单/双位错误 | 单比特接近全覆盖 | 纠错/报错、双位报错 |
| 奇偶校验 + 冗余总线 | 总线、寄存器堆数据损坏 | 中高 | 重传/报错/安全状态 |
| 窗口看门狗 | 软件跑飞、死循环、时钟停振 | 中 | 复位、中断安全管理器 |
| LBIST/MBIST 上电与周期自检 | 逻辑和存储的永久故障 | 取决于测试向量 | 禁止启动、点亮故障灯 |
| 时钟/电压/温度监控 | 时钟漂移、欠压、过热 | 中 | 降频、复位、关断 |
| 冗余传感器/三取二表决 | 外部输入错误 | 高 | 多数表决、剔除异常通道 |
下图把「故障发生 → 机制检测 → 进入安全状态」的时间线画出来，注意故障响应时间（FHTI，Fault Handling Time Interval）必须小于故障容忍时间——这是安全概念落地为时序预算的关键接口。
双核锁步值得展开。做法是两颗相同的 CPU 执行完全相同的指令流，一颗延迟一到两个周期，比较器在输出端逐拍比对：一旦结果不一致就报错。延迟设计是为了抵抗共因失效——如果两核同时钟沿、同电源纹波，同一个干扰可能同时打坏两核，锁步就形同虚设；错开一拍、物理上分散布局、有时还加多样化的后端实现，正是为了避免这种共因。更激进的方案用两颗不同微架构的核做核对（diverse redundancy），成本高但抗系统性共因能力更强。锁步核性能等于单核，面积接近翻倍，这是 ASIL D MCU（如刹车、转向控制器）普遍采用双核而不追求多核跑分的原因。
机制清单之外还要区分硬件机制与软件机制。硬件机制（上述锁步、ECC、监控）反应快、不依赖软件正确性；软件机制包括 ASIL 认证实时操作系统的任务分区与时间保护、MPU 内存隔离、输入信号的合理性检查与冗余比较、程序流签名检查等，覆盖面广但自身运行在可能故障的 CPU 上，所以高等级安全目标不允许只靠软件机制兜底，必须与硬件机制组合。三取二表决（2oo3）是比锁步更强的配置：三路独立通道中坏一路仍能多数表决输出正确结果，可用度更高，但成本是三套完整系统，主要用于线控转向、线控制动这类失效后无法回退到机械备份的系统；锁步加一个安全核的 1oo2 方案则是成本和安全性的折中主流。
ECC 是存储类故障的主力。车规 MCU 的 SRAM 普遍配 SEC-DED（单错纠正、双错上报）码；大容量 Flash 同样带 ECC。但 ECC 解决不了「同一个字里翻两位以上」和地址译码错误，所以高等级设计还会加入地址奇偶、周期性的 ECC 巡检（scrubbing，主动读一遍所有行让潜伏位错误在变成双比特前被纠正）。看门狗则必须是「窗口」看门狗：普通看门狗只检测「太久没喂狗」，软件跑飞但仍在喂狗时完全无感；窗口看门狗要求喂狗发生在规定的时间窗口内，太早太晚都复位，能同时识别跑飞和节拍异常。安全岛（safety island）指把安全管理逻辑、时钟、电源、比较器集中成一个独立性受保护的小域，即使主系统损坏也能独立完成报错和关断。
五、诊断覆盖率与硬件度量：SPFM、LFM、PMHF
安全机制的效果不靠定性描述，全部折算成数字。核心概念是诊断覆盖率 DC（Diagnostic Coverage）：某类危险失效中能被机制检测到的比例。某寄存器失效模式的原始失效率是 λ，机制覆盖了 90%，则安全失效率是 0.9λ，残余 0.1λ。
把全芯片的失效模式按 FMEDA 汇总，得到三个硬件安全度量：
- SPFM（Single-Point Fault Metric，单点故障度量）：与单点和残余故障相关的比例。直觉上是「危险故障中，不致直接违反安全目标的占比」。ASIL D 门限 ≥ 99%，ASIL B ≥ 97%（ISO 26262-5:2018 口径）。
- LFM（Latent Fault Metric，潜伏故障度量）：反映潜伏故障被检测的程度。ASIL D 门限 ≥ 90%，ASIL B ≥ 80%。
- PMHF（Probabilistic Metric for random Hardware Failures）：单位时间内单点+残余+可导致多点违规的综合平均失效概率，门限 ASIL D 为 10 FIT 量级（10⁻⁸ h⁻¹），ASIL B 为 100 FIT 量级。
FIT（Failure In Time）是失效率单位：1 FIT = 每 10 亿器件小时发生 1 次失效。一颗工作 10 年（约 8.76 万小时）的芯片若总失效率 100 FIT，整寿命失效概率约 0.876%。失效率数据来自工艺厂提供的可靠性手册（按 SRAM 位、触发器、门、模拟模块分类给出基础 FIT），或 IEC 61709/SN 29500 等行业手册。
| 指标 | 含义 | ASIL B | ASIL D |
|---|---|---|---|
| SPFM | 单点/残余故障度量 | ≥ 97% | ≥ 99% |
| LFM | 潜伏故障度量 | ≥ 80% | ≥ 90% |
| PMHF | 随机硬件失效概率 | ≤ 100 FIT | ≤ 10 FIT |
这三个数字解释了为什么安全机制不是「加了就行」：SPFM 差一两个百分点，可能就要把某个中等覆盖率的奇偶校验升级成 ECC，或给一片本来裸露的寄存器堆加冗余，成本和面积直接受 FMEDA 数字驱动。这也是为什么功能安全必须在架构阶段介入——等 RTL 冻结再发现 SPFM 只有 96%，要补的是全芯片的保护结构。
用一个简化算例把 SPFM 的计算走一遍。假设某安全相关模块各失效模式的原始失效率如下，安全机制覆盖后残余部分计入单点/残余：
| 失效模式 | 原始 λ(FIT) | DC | 残余 λ(FIT) |
|---|---|---|---|
| CPU 逻辑固定故障 | 10 | 95%（锁步） | 0.5 |
| SRAM 翻转 | 20 | 99%（ECC） | 0.2 |
| 中断控制器故障 | 5 | 0%（无机制） | 5.0 |
| 时钟停振 | 3 | 90%（监控） | 0.3 |
合计原始危险失效率 38 FIT，残余合计 6 FIT，则 SPFM = 1 − 6/38 ≈ 84%——离 ASIL D 的 99% 差得远，瓶颈一眼可见：中断控制器完全没有保护，它一个就贡献了 5 FIT 残余。给中断控制器加锁步或冗余表决（DC 90%，残余降到 0.5）后，残余合计 1.5 FIT，SPFM 升到约 96%；再把时钟监控提到 99%，才逼近 99%。这个算例说明三件事：SPFM 的算法本身只是加权平均，真正的工程动作是按 FMEDA 找到最薄弱的裸露模块；任何一个零覆盖的小块都会拖垮整体；度量计算结果直接决定下一版架构要保护哪里。LFM 的算法类似，分母里换成潜伏故障相关项，靠周期自检和可维修标志把数字抬上去。
PMHF 则不只是简单比例，它要把各失效模式按「在多点失效链中导致安全目标违反的概率」加权，考虑检测周期、维修间隔和故障暴露时长，标准第 11 部分给出了评估方法（可用简化公式或更精细的马尔可夫/割集分析）。签核口径上，除了满足量化门限，还要评估没有充分数据可量化的特殊情况（如某些模拟失效），用定性的安全论证补充。
六、FMEA 与 FMEDA：逐失效模式列出影响与诊断
数字的来源是 FMEDA（Failure Modes, Effects and Diagnostic Analysis），它是 FMEA（Failure Mode and Effects Analysis，失效模式与影响分析）在硬件安全方向的扩展。FMEA 自底向上：逐个元器件/模块列出「可能怎么坏」（失效模式）、「坏了会影响什么」（局部影响、整车影响）、「后果多严重」；FMEDA 再加三列关键信息：该失效模式的失效率、用什么安全机制检测、诊断覆盖率是多少，最后自动汇总成 SPFM/LFM/PMHF。
一张真实 FMEDA 表的典型行如下（数字为示意）：
| 模块 | 失效模式 | 影响 | λ(FIT) | 安全机制 | DC | 分类 |
|---|---|---|---|---|---|---|
| CPU 寄存器 | 固定 0/1 | 错误运算结果 | 3.2 | 双核锁步 | 95% | 残余 5% |
| SRAM 阵列 | 单比特翻转 | 数据错误 | 8.0 | ECC SEC-DED | 99% | 多点 |
| 时钟树 | 停振 | 系统挂死 | 1.5 | 时钟监控+看门狗 | 90% | 残余 |
| ADC | 输出漂移 | 采样偏差 | 2.0 | 双通道比较 | 90% | 多点 |
| 电源管理 | 欠压 | 时序违规 | 1.0 | 电压监控复位 | 95% | 安全故障 |
做 FMEDA 有几个实践要点。其一，颗粒度决定可信度：只按模块填「CPU，失效模式：坏了」无法支撑 ASIL D 签核，通常要展开到主要功能块和失效模式类别（永久固定、瞬态翻转、开路短路、漂移）。其二，DC 必须有证据：不能拍脑袋写 99%，要么引用 ISO 26262-5 附录里给出的机制典型覆盖率区间，要么用故障注入（fault injection）仿真或实物实验证明。其三，FMEDA 是活文档：架构每改一次、每加一个模块就要更新，末期补表必然导致度量无法闭环。
故障注入是 DC 论证的硬手段：在 RTL 仿真或 FPGA/硅片上主动翻转指定触发器、强制信号线固定，观察安全机制是否在 FHTI 内检出并响应。它与 DFT 扫描压缩与 MBIST/LBIST 的测试结构有大量复用——扫描链、BIST 控制器既服务制造测试，也可作为运行中自检的安全机制，但两拨人对「覆盖率」的定义不同：DFT 看 stuck-at 故障覆盖率，功能安全看危险失效的诊断覆盖率，数据不能直接互用。
七、流程、工具置信度 TCL 与安全案例
功能安全 ISO 26262 对「怎么做出这个结果」的约束与对结果本身同样严格。项目启动要写安全计划（Safety Plan）：谁做安全经理、用什么流程、哪些工作产物（work product）、如何评审与追溯。整车厂和芯片供应商之间签 DIA（Development Interface Agreement，开发接口协议），明确双方各负责哪些安全活动——比如整车厂提供安全目标，芯片厂负责芯片级安全概念和 FMEDA，边界不清是供应商扯皮的高发区。
工具按出错风险分级，这就是 TCL（Tool Confidence Level，工具置信度，TCL1 最低、TCL3 最高）。工具分两类：TI 类工具（如编译器、代码生成器）其输出直接成为产品，bug 会直接注入产品；TD 类工具（如仿真器、STA）其错误可能让缺陷漏检。工具越关键、越容易出问题，TCL 越高，要求的工具鉴定（tool qualification）越严——要么做工具评估、用独立手段交叉验证，要么按工具鉴定套件验证。EDA 厂商会给主流工具出具安全手册（Safety Manual）和工具置信度评估报告，芯片团队据此把工具纳入自己的工具置信度论证。TCL 与硬件安全等级无关：它是对「你信不信这个工具」的管理。
安全需求在 V 模型上层层分解、层层验证。整车安全目标（safety goal，如「防止非预期加速」）分解为功能安全需求（整车/系统级，如「扭矩请求必须双路采集并表决」），再分解为技术安全需求（TSR，落到 ECU 接口和通信），最后到硬件/软件安全需求（HSR/SSR，如「该寄存器必须被锁步比对覆盖、报错后 10ms 内切断驱动级」）。分解的每一级都带 ASIL 标注，且必须可追溯：从安全目标到 FMEDA 行、到 RTL 模块、到验证用例，双向追溯链是审计必查项。
| 层级 | 需求形态 | 对应验证 |
|---|---|---|
| 整车 | 安全目标 + ASIL | HARA 评审 |
| 系统 | 功能/技术安全需求 | 系统安全测试、故障注入台架 |
| 芯片 | 硬件安全需求 | FMEDA、仿真故障注入、形式验证 |
| 硅片 | 机制运行确认 | LBIST/BIST、器件级故障注入 |
独立性（independence）是 V 模型之外另一条贯穿性要求，分 I1（同作者评审即可）、I2（同团队不同人）、I3（不同团队）三档，ASIL 越高要求的独立等级越高，最高等级的安全活动（如 ASIL D 安全需求评审）要求 I3。独立性针对两类对象：一是人的独立（做设计的人不能单独给自己签核），二是架构上的独立（冗余通道之间不能共享会一起坏的资源，共因失效分析 CCA 包含共因失效 CCF 和级联失效）。前面提到的 ASIL 分解能否成立，完全取决于冗余要素的独立性论证是否过关。
FTTI（Fault Tolerant Time Interval，故障容忍时间间隔）是安全需求中少数带硬时序约束的指标：从故障发生到必须进入安全状态的最长时间。整车厂按危害场景给出 FTTI（转向、制动场景往往只有几十毫秒），芯片厂把它反向切成三段预算：故障潜伏到被检测出的诊断时间、上报与软件裁决时间、执行关断动作的时间，三者之和必须小于 FTTI。这个预算直接决定 LBIST 能不能放在运行中做（耗时太长就只能上电做）、看门狗周期设多长、安全管理器跑在多快的核上。功能安全因此不是纯数字游戏，它最终落到具体的时序和面积权衡上。
所有证据最后汇成 Safety Case（安全案例）：安全目标定义、HARA、安全概念、架构与机制说明、FMEDA 与度量计算、验证与故障注入报告、工具与流程置信度、安全手册（Safety Manual，教整车厂如何正确使用这颗芯片，包括假设的外部措施和使用约束）。安全案例不是一篇文档，而是一套可审计的证据链，用来支撑「这颗芯片在声明的 ASIL 等级下，随机硬件失效风险可接受」的结论。
安全手册是芯片交付给系统厂时最关键的假设性文件：芯片的安全论证建立在一系列「假设使用方式」之上，系统厂必须照做，否则签核自动失效。典型内容如下。
| 安全手册内容 | 系统厂需要做的事 |
|---|---|
| 声明的 ASIL 等级与适用安全机制 | 只在声明范围内使用，未覆盖功能另行加机制 |
| 上电/周期自检的触发要求 | 保证每次启动运行 LBIST，按周期触发巡检 |
| 故障响应时间与 FTTI 假设 | 系统软件在预算内完成裁决和关断 |
| 故障码与诊断接口 | 接入整车诊断，维修时读取清除潜伏故障 |
| 假设的外部措施 | 如外置看门狗、独立电源监控、冗余传感器 |
| 已知使用限制 | 温度/频率降额边界、禁用的配置组合 |
整车厂如果忽略其中一条——比如为了缩短启动时间跳过 LBIST——芯片的硬件度量在整车层面就不再成立，事故责任也会回到集成方。因此安全手册和 DIA 一样，本质是把安全责任沿供应链切清楚的合同性文件。芯片发布后的任何 errata（勘误）也要评估是否影响安全机制，并通过勘误通知触达所有客户。
八、常见坑：共因、不可观测与末期补表
- 共因失效击穿冗余：锁步两核共用一路电源、同一时钟沿、同一块宏单元，一个干扰同时打坏两个，比较器永远一致。对策是延迟错开、物理分散、独立供电域，并在共因分析中逐项论证。
- 安全机制不可观测：机制在 RTL 里存在，但报错信号接进了一个测试模式才能读的寄存器，运行中没人能看到；或故障响应路径本身没有验证。机制必须同时有「检测路径」和「响应路径」，且两条路径都要验证。
- FMEDA 末期补做：流片前才填 FMEDA，发现 SPFM 差两个百分点，只能改架构或降等级声明。安全分析必须与架构设计同步迭代。
- DC 无证据：FMEDA 里写 99%，评审时拿不出附录依据或故障注入结果，审计直接驳回。
- 潜伏故障无出口：ECC 双错标志没有连到任何可读寄存器，维修工永远不知道。潜伏故障标志要进故障存储并能被诊断设备读出。
- 误用 QM IP：从第三方买的 IP 没有安全手册、无 FMEDA 数据，无法纳入 ASIL 分析。IP 采购阶段就要确认安全交付物。
这一篇在知识体系里的位置
- 上一篇：硬件安全：Root of Trust、安全启动与密钥保管——一个防外部攻击者，一个防内部随机故障，安全与功能安全在车规芯片上并行实施；
- 下一篇：低功耗验证：UPF 仿真与 RTL 毛刺——隔离、保持、电源开关同样会影响故障检测路径，低功耗与功能安全交叉验证；
- 想了解车规器件的寿命与环境考核基础：可靠性与 AEC-Q100：车规认证与老化；
- 想了解 BIST/扫描如何同时服务安全自检：DFT 扫描压缩 与 MBIST/LBIST 存储器自检；
- 想看安全机制之外的复位与时钟架构基础：时钟与复位架构、异步设计。
总结
功能安全 ISO 26262 的逻辑闭环是「危害定级—机制检测—度量化签核」：由严重度 S、暴露率 E、可控性 C 评出 ASIL A-D，用双核锁步、ECC、窗口看门狗、BIST、时钟电压监控和安全岛把单点故障变成可检测故障、把潜伏故障变成可维修故障，再以 FIT 失效率和诊断覆盖率为输入，经 FMEDA 逐失效模式汇总出 SPFM（ASIL D ≥99%）、LFM（≥90%）、PMHF（≤10 FIT），配合安全计划、DIA、工具置信度 TCL 和 Safety Case 证明芯片「坏了也安全」；机制必须在架构阶段插入、故障响应快于 FTTI、覆盖率有故障注入证据，任何末期补表、共因失效或不可观测的安全机制都会让整个签核归零。