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

Clause 13 的 "hardware element" 粒度比直觉宽。它可以是一颗 MCU、一颗运放,也可以是一个由若干分立件组成的子电路(part / component / element 在 Part 1 有严格定义层级)。评估范围必须先框定:被评估的是裸器件,还是「器件 + 其在本系统中的特定使用方式」。后者会牵出 AoU(Assumptions of Use,使用假设)——评估结论只在这些假设成立时有效。

如果器件厂自己按 SEooC(Safety Element out of Context)开发并交付了安全手册 + FMEDA,那么集成方做的是「验证 AoU 是否满足」,不是 Clause 13 评估。Clause 13 专门处理另一种情况:器件厂没给这些证据,集成方必须自己补。两者的分界线就是「有没有可信的现成安全证据」——这也是决策树的根节点。

这条路径适合「样本量不足以做统计、但能拿到器件内部信息或可做测试」的情况,也是大多数新器件的现实选择。它要求:确定器件的失效模式(可参考 IEC/SN 29500、FMD-2016 等失效率手册),给出每种失效模式的分布,评估器件内置诊断对各失效模式的覆盖率,再用应力 / 寿命测试与既有 datasheet 参数验证。产出的是一份针对本器件的 FMEDA 输入(failure rate + failure mode distribution + DC),供系统 FMEDA 引用。

这条路径不打开器件、不做新测试,而是论证「它已经被现场证明可靠」。它要求:同一构型(无变更)的器件、在可比的运行剖面下、累积足够的运行小时、记录全部的 field return 与失效。关键是变更管理——任何掩模、工艺、封装、版本变更都会中断既有使用的连续性,使之前的运行小时不可继承。这也是它最大的卡点:汽车量产周期短、迭代快,「同一构型连续跑很久」往往不成立。

选哪条不是偏好而是硬条件。简单器件(电阻、电容)若分类为 I 类,集成后确认满足系统需求即可,通常不触发独立评估;II / III 类器件才进入 Clause 13。在 II / III 类内部:能拿到内部失效模式信息或可做测试 → 走 13.4.1;拿不到内部信息但有海量同构型现场数据 → 走 13.4.2;两者都没有 → 必须重选器件或要求供应商补开发。

在失效服从泊松过程(恒定失效率、随机失效)的假设下,失效率单边置信上界用卡方分布给出:

其中 $T$ 是累积运行小时(器件数 $\times$ 单器件小时),$r$ 是观测到的失效数,$1-\alpha$ 是置信度(常用 0.60 / 0.70 / 0.90),${\chi }^2$ 取自由度 $2r+2$ 的卡方分位数。零失效($r=0$)是最常见的现场情形,此时 ${\chi }_{1-\alpha ,2}^2=-2\ln \alpha$,公式退化为:

例如要在 60% 置信度下声明 $\lambda \le 10FIT$($10^{-8}/\mathrm{h}$)且零失效,需要 $T=-\ln (0.40)/10^{-8}\approx 9.2\times 10^7$ 器件小时——约 1 万个器件连续跑 1 年。这解释了为什么只有超大装机量的成熟器件走得通这条路。

把上式列成表,工程上就能直接查「现有数据能声明多低的失效率」。下表给出零失效($r=0$)与一次失效($r=1$)在 60% 置信度下,达到目标 FIT 所需的累积器件小时(数量级)。

可以看出两条规律:目标失效率每降一个数量级,所需运行小时上升一个数量级;每多观测到一次失效,门槛大致翻倍。这就是 proven-in-use 的残酷之处——既要海量装机,又一旦有失效记录,门槛立刻抬高。

最常见的误用是把「不同构型、不同版本」的运行小时混算进同一个 $T$,这违反「同一构型」前提,得到的上界没有统计意义。第二个卡点是 field return 数据不全:漏报的失效会让 $r$ 偏低、${\lambda }_{upper}$ 偏乐观,审计时无法证明数据完整性就不被接受。第三是运行剖面不可比——消费级温度剖面的运行小时不能直接搬到车规 Grade 0 环境。

评估结论不能口头继承,必须文档化。对内,评估报告 + AoU 进入系统 FMEDA 的输入登记;对外,如果本器件被当作子系统再交付,这些 AoU 要写进本系统的安全手册,作为下一级集成方的使用约束。AoU 是评估结论的有效边界:超出 AoU 的使用方式,原评估结论一概不成立。

下表按路径列出必须收集的证据。两条路径都需要的「共同项」(器件标识与构型、使用范围 AoU、目标安全特性)放在最上,差异项分列。

判据是「证据够不够」的客观门槛。基于评估走 FMEDA 量化判据(失效模式分布合理、DC 有故障注入支撑);既有使用走 §3.1 的 chi-square 判据(在目标置信度下,${\lambda }_{upper}$ 不超过分配给该器件的失效率预算)。两条路径的统一验收标准是:该器件喂给系统 FMEDA 的 $\lambda$ 与 DC,都有可追溯、可审计的来源,不是工程估值。

无论走哪条路径,最终产出物固定:一份硬件要素评估报告,内容含评估范围与器件标识、所选路径及理由、证据清单与原始数据引用、失效模式分布、失效率(及其置信度/来源)、诊断覆盖率、明确的 AoU、以及供 FMEDA 直接引用的输入数据块。这份报告是系统级安全案例(ISO 26262-9 / Safety Case)的输入证据之一,从评估第一天起就应按可审计标准归档。