硬件要素评估方法论

本质:硬件要素评估 = 用测试 + 文档证据,把 II/III 类元件的"失效模式 + 诊断覆盖"对接到系统安全目标,实现 ISO 26262 合规闭环。

学习目标
  • (LLM 自动生成,待人工补充 2-3 条学习目标)

因果链说明

功能安全开发必须对所有进入安全相关系统的硬件要素进行符合性论证。评估的核心因果链为：

  1. 硬件要素分类（I/II/III）决定评估深度；
  2. 评估计划基于分类制定测试与分析任务；
  3. 测试证据（功能性能、失效诊断）支撑安全需求分配；
  4. 安全案例把证据映射到安全目标，实现合规闭环。

评估流程概览
阶段关键活动交付物
分类根据 ISO 26262‑8 将要素划分为 I、II、III 类分类表（见 ISO 26262 硬件分类）
计划为 II、III 类要素编写 硬件要素评估计划（HEAP）HEAP 文档
实施– 基本功能性能测试 / – 安全需求验证测试（故障注入、诊断覆盖）测试规范、测试报告
证据管理收集 datasheet、供应商安全手册、内部测试数据证据清单（Evidence Register）
安全案例编制将证据映射至安全目标，填充 FMEDA/PMHF 分析安全案例章节（ISO 26262‑9）

关键测试类型

基本功能性能测试

  • 电源电压范围、温度范围、静态/动态精度（对传感器、ADC）
  • 输出时序、上电/断电行为（对驱动、PMIC）
  • 参数漂移、噪声、互扰

安全需求验证测试

  • 诊断功能：故障注入 → 检测覆盖率；
  • 安全状态触发：ASC、Watchdog、隔离器的安全输出逻辑验证；
  • 冗余交叉检查：Level 1 与 Level 2 采样路径的一致性。

评估示例（摘要）
类别示例要素主要评估活动
I电阻、电容、二极管仅需确认集成后满足系统安全需求，无需独立评估
II电流传感器、运算放大器、CAN/LIN 收发器、低压驱动编写 HEAP → 功能性能 + 诊断覆盖 → 记录 datasheet 与实验数据
IIIMCU、带安全机制的栅极驱动、复杂 PMIC建议使用符合 ISO 26262 开发流程的器件；如使用 QM 器件需提供完整 FMEDA 与系统级安全分析

核心要点
  • 评估 5 阶段:分类 → HEAP 计划 → 实施测试 → 证据登记 → 安全案例编制,缺一环都过不了审计
  • 测试两条线并行:基本功能性能(电压/温度/精度/时序) + 安全需求验证(故障注入 + 诊断覆盖 + 冗余交叉)
  • I 类元件无须独立评估,II 类靠 datasheet + 应用笔记,III 类必须 FMEDA + 系统级失效分析
  • 证据登记(Evidence Register)是 ISO 26262-9 安全案例的输入,要从评估第一天就规范归档
  • HEAP 模板可复用 — 同一元件类(如 ADC)可以共享一份 HEAP,差异部分按型号增量;别每个芯片都从零写

Cross-references

Cross-references