ISO 26262-8 §13 硬件要素评估:无 ISO 26262 证据的器件,怎么 qualify 进安全系统

安全相关系统的全部定量论证(FMEDA、SPFM、LFM、PMHF)都建立在「每个器件的失效率 $\lambda$ 和诊断覆盖 DC 是可信的」这一前提上。问题是,绝大多数在售器件是按 QM(质量管理,非功能安全)流程开发的——它们没有安全手册、没有 FMEDA、没有失效模式分布,datasheet 上更不会写 FIT 值。直接把这种器件填进系统 FMEDA,等于用一个无依据的数字撑起整张安全论证,审计第一关就会被打回。

Clause 13 给出的退路是:器件不必生而合规,但进入系统前必须被「评估(evaluate)」到足以提供可信的安全特性。这就是「硬件要素评估」也常被叫作「硬件要素鉴定 / qualification」的原因——它把一个来路不明的器件,转化成 FMEDA 可以安全引用的对象。

Clause 13 提供两条互补的路径,核心区别在于「证据从哪来」。基于评估(13.4.1)从器件的设计与测试里主动生成证据:分析其失效模式、做应力测试、推导失效率与诊断覆盖。基于既有使用(13.4.2,proven-in-use)从历史现场运行数据里反推证据:这颗器件在足够多的场合跑了足够久、失效足够少,统计上就能声明一个失效率上界。

proven-in-use 之所以常常卡住,是因为它本质是一个置信区间问题:用有限的现场观测,声明一个有统计保证的失效率上界。直觉上「跑了很久没坏」不等于「失效率低」——必须把运行小时、观测失效数、目标置信度三者绑在一个公式里,才能得出可写进 FMEDA 的数字。

评估的意义不在于产出一份报告,而在于它喂给 FMEDA 的两个数字($\lambda$ 和 DC)是整张系统安全论证的地基。如果这两个数字没有可信来源,FMEDA 算出的 SPFM / LFM / PMHF 就是建在沙上的精确数字——形式上有小数点后两位,实质上无依据。

具体的污染链是:器件评估缺失 → 该器件的失效率与失效模式分布只能猜 → FMEDA 中该器件行的 SPF / RF 划分不可信 → 系统级 SPFM / LFM 偏差 → PMHF 不能反映真实随机失效风险 → 安全目标的定量证据失效 → 安全案例(Safety Case)无法闭环。反过来,一份扎实的 Clause 13 评估,是让 FMEDA 数字「站得住」的前提,也是评估报告必须显式写出 AoU 的原因——下游 FMEDA 引用这些数字时,必须同时继承这些使用假设。

把前面的约束落地,Clause 13 评估在工程上就是「按路径收齐证据 → 套统计或分析判据 → 产出可被 FMEDA 与安全案例引用的报告」。两条路径的证据清单不同,但都收敛到同一组产出物。

Clause 13 评估的流程通过具体案例最易掌握。本节给出每条路径各一例：13.4.2 统计声明与 13.4.1 FMEDA 评估。

Clause 13 评估的常见陷阱不在于公式本身，而在于边界条件和证据口径被悄悄违反——这些错误往往能通过形式审查，却在 SOTIF 或安全评估时暴露。

G1 把 AEC-Q100 当 ISO 26262 资格证：AEC-Q100 是可靠性筛查（HTOL/HAST/温循/封装），证明"良品率在高温下稳定"，但不产出失效模式分布、不产出 DC、不产出 λ 置信区间。持有 AEC-Q100 Grade 0 与通过 Clause 13 完全正交——后者需要在 AEC-Q100 基础上另做。混淆两者的评审意见通常来自"芯片厂说已经车规认证了"——这话是对的，但与 ISO 26262 无关。

G2 用 SN 29500 / IEC 62380 FIT 值直接填进 FMEDA：失效率手册给的 ${\lambda }_{total}$ 只是起点；Clause 13 还要求失效模式分布（各 FM 占比）和每个 FM 的 DC——手册里没有这两样。直接把手册 FIT 填进 FMEDA 等于默认"所有失效模式等权、DC = 0"，得到的 SPFM/LFM 形式上有数字、实质上无依据。

G3 proven-in-use 混算不同 revision 的运行小时：掩模版本、工艺节点、封装任何变更都中断"同一构型"前提。Rev A 积累了 $2\times 10^9$ h，Rev B 上市后又积累了 $3\times 10^9$ h，不能把两者相加——Rev B 的起点必须清零，Rev A 的数据对 Rev B 无效。这是 proven-in-use 最常被悄悄违反的规则，在跨年度长生命周期项目尤其难追溯。

G4 把 pin-compatible 替代料的运行小时继承给新供应商器件：供应商 B 的"同型号"在你的项目里还没有运行小时。无论功能多相似，Clause 13.4.2 评估不可继承——器件级配方（掺杂浓度/氧化层厚度/键合材料）已不同，失效机理分布也可能不同。对 13.4.1 同理：供应商 A 的 FMEDA 报告 AoU 写明是供应商 A 的 silicon，供应商 B 须独立出具。

G5 DC 超额申报——范围检查覆盖了偏移漂移：常见误操作：声明 ADC 范围检查 DC = 95%，但实际能检的是"输出电压超出 ADC 量程"，而输入偏移缓慢漂移导致比较器门限偏移 1%——仍在量程内、ADC 完全看不出来——F3 类的 DC 实际接近 0%。DC 必须与具体失效机理一一对应，不能把一种诊断手段的 DC 套用到与之无关的失效模式。

G6 评估报告不写 AoU，下游集成方直接套用：评估结论（$\lambda$ 和 DC）仅在 AoU 约束条件下成立。若评估时 Tj 上限为 125 °C 而集成方装进 150 °C 场景；或评估时诊断架构为双 ADC 互比而集成方只用单 ADC——原评估结论一律失效。没有显式 AoU 的评估报告实质上是无法安全引用的"黑盒 FIT"，不满足 ISO 26262-8 § 13.5 的文档要求。

G7 证据收集起点比器件入项晚：proven-in-use 要求 field return 的完整记录——而多数项目的 8D/TSB 数据库从 SOP（批量生产）才开始维护，之前的试生产、BV 阶段、DV 样件的现场数据要么分散在工程日志里、要么根本没有。如果事后重建这段时间的"无失效记录"，审计时无法证明数据完整性，统计声明不被接受。解决方案是在 BV/DV 阶段就建立与量产同口径的追溯数据库。

极端条件下的 Clause 13 评估有几种结构性困境，每一种都需要不同的应对策略。

C1 供应商提供"部分 SEooC"——只覆盖部分失效模式：SBC 供应商 A 为其产品提供了安全手册，但仅针对"内部稳压器失效"和"SPI 通信故障"，对"看门狗输出管卡死"没有安全证据。集成方不能以"供应商有安全手册"一笔带过——须识别安全手册的覆盖范围，对未覆盖的失效模式（"看门狗卡死"）独立走 Clause 13.4.1 评估，产出该模式的 $\lambda$ 与 DC，再合并进系统 FMEDA。这也是 ISO 26262-11 半导体指南存在的意义：半导体供应商通常只覆盖自己能测试的失效模式，系统集成方须填补余量。

C2 供应商 IP 保护，拿不到内部失效模式分布：部分 FPGA / 加密芯片 / 定制 ASIC 供应商以 IP 保护为由拒绝公开内部失效模式分布，使 13.4.1 的"分析"环节无法执行。出路：(a) 走 13.4.2 proven-in-use（只需黑盒统计，不需内部信息）；(b) 在 NDA 框架下要求供应商提供 FMEDA 摘要（仅 FM 分布百分比，不含工艺细节）；(c) 保守假设"所有 FM 等权"做最差情形 FMEDA，若结论已满足 ASIL 目标则可接受；(d) 重选有 SEooC 证据的器件。选哪条取决于 ASIL 等级与项目时间：ASIL D 路径通常走不了(c)，必须取(a)、(b)或(d)。

C3 供应链灰市件导致 proven-in-use 数据库失效：一批"来自分销商"的器件被 8D 归因为非正品（静电测试失效）。这些单元的运行小时和"零失效"记录不能纳入 T 的统计：非真品的工艺与目标器件完全不同，统计无效，且掺入会使 ${\lambda }_{upper}$ 虚假乐观。解决方案：proven-in-use 数据库须追溯到一级授权渠道的采购记录，并与供应链管理（VDA 6.3 流程审核）挂钩；非授权渠道批次须从 T 的统计中剔除，对应 field return 需独立分析是否归因为真正的器件失效。

• hw_element_evaluation_report(Clause 13 评估报告:范围 / 路径 / 证据 / λ / DC / AoU)
• assumptions_of_use(AoU:评估结论的有效边界,下游 FMEDA 与安全手册必须继承)
• proven_in_use_record(同构型累积运行小时 + 完整 field return 失效记录)
• chi_square_failure_rate_bound(由 T 与 r 在目标置信度下推出的 λ 上界)