ISO 26262 硬件要素三类分类

功能安全L7别名 硬件要素分类 · hardware element classification · I 类硬件 · II 类硬件 · III 类硬件

本质 ISO 26262 把安全相关硬件按"运行状态数量 + 是否有内部安全机制 + 评估是否需要了解内部细节"分三类——I 类(电阻、电容等)只要集成对就行、II 类(运放、ADC、CAN 收发器等)要做功能性能测试 + 文档分析、III 类(MCU、带安全栅极驱动、PMIC 等)要么直接采用 ASIL 认证芯片、要么自己补 FMEDA + Safety Manual。这条分类是芯片选型与安全架构设计的首要依据——分类错就会做错评估、漏掉系统性失效风险论证或浪费精力评估不需要详评的器件。

学习目标

读完本页后,你应该能够:

  • 区分 I / II / III 类硬件要素的判定依据(状态数量 + 内部安全机制 + 评估深度)
  • 说出每类的典型实例(I 类电阻 / II 类运放 / III 类 MCU)
  • 知道每类对应的评估要求(I 类略过、II 类功能测试、III 类要 FMEDA 或 ASIL 认证)
  • 走通5 步评估流程:类别判定 → 文档收集 → 评估计划 → 测试执行 → 证据归档
  • ASIL C/D 系统设计时正确选用 III 类功能安全芯片

1. 三类硬件要素的判定依据

ISO 26262 的分类沿一条单调递增的复杂度坐标——从无内部安全机制 + 状态有限,到有内部安全机制 + 必须了解实现细节。理解这条坐标决定你做评估时该投多少精力。

Mermaid diagram
类别状态数量内部安全机制评估要求
I极少,可全表征集成对即可,无需独立安全评估
II少数运行模式无(可能有外部诊断)文档分析 + 功能性能测试 + 证据归档
III多种运行模式直接选 ASIL 认证芯片 / 自己补 FMEDA + Safety Manual

2. I 类硬件要素

I 类是最简单的器件——状态数量极少,可以在实验室把所有可能输入组合都测一遍。这种"完全可观测"特性意味着不会有隐藏的系统性失效,所以 ISO 26262 允许跳过单元级安全评估,只要集成后满足系统安全需求即可

特征典型实例评估要求
运行状态极少,无内部安全机制,可完全表征电阻、电容、二极管、晶体管、晶振、NTC/PTC 温度传感器集成后满足系统安全需求即可,无需对单元进行独立安全评估

原因链:状态数量少 → 实验室全组合测试可覆盖 → 完全可观测 → 不涉及系统性故障 → 省去设计文件审查。


3. II 类硬件要素

II 类是中等复杂度 IC——有几种运行模式但没有内部安全机制;不过 datasheet 和 application note 通常足以让外部做安全角度分析。II 类的典型对象是模拟前端、通用接口芯片、简单驱动。

特征典型实例评估要求
少数运行模式,无内部安全机制,但可能提供外部安全诊断电流传感器、运算放大器、ADC/DAC、CAN/LIN 收发器、简单高低边驱动依 datasheet / application note 做安全角度分析;制定评估计划、完成功能性能测试并记录证据

原因链:运行模式有限 + 文档充分 → 在不泄露实现细节前提下评估系统性失效风险 → 通过功能测试验证安全相关性能。


4. III 类硬件要素

III 类是复杂 IC 且自身有内部安全机制——MCU、带 ASC Pin 的栅极驱动、多通道 PMIC、带 SIL 评估的磁编码器都属此类。这类器件必须了解实现细节才能评估系统性失效风险,所以 ISO 26262 推荐直接采用按其流程开发的功能安全芯片(供应商已交付 Safety Manual + FMEDA),否则就要自己补充能证明系统性失效风险已降低的额外措施。

特征典型实例评估要求
多种运行模式,具备内部安全机制,评估须了解实现细节或生产过程MCU、带安全功能的复杂栅极驱动、多通道 PMIC、带安全功能的磁编码器推荐直接采用符合 ISO 26262 开发流程的功能安全芯片;否则需提供系统性失效风险降低的额外措施(FMEDA、Safety Manual 等)

原因链:内部安全机制关联系统安全目标 → 只能通过厂商提供的安全开发文档证明可靠性 → 采用符合 ASIL 要求的元件可大幅降低系统安全论证工作量。


5. 评估流程

任何硬件要素都走同一条 5 步评估流程——只是在第 3 步评估计划里按类别裁剪具体动作。这条流程是 ISO 26262 Part 8(Supporting Processes)推荐做法的简化版。

Mermaid diagram
动作类别裁剪
1 类别判定按运行状态数 / 内部机制 / 评估深度划 I/II/III 类全适用
2 文档收集Datasheet / User Manual / Safety Manual / FMEDA 报告III 类必须有 Safety Manual
3 评估计划制定测试 / 分析方案I 类略;II 类功能测试;III 类决定 ASIL 认证 OR 补论证
4 测试执行基本性能测试 + 安全需求符合性测试(故障注入、冗余路径)II/III 类才需要安全测试
5 证据归档测试报告、分析结果、风险降低措施记入安全案例供后续安全审计

6. 与功能安全的关联

硬件要素分类不是孤立的标签——直接决定后续 3 件事:安全目标分配、ASIL 等级匹配、系统级 FMEDA 怎么算。

维度I 类II 类III 类
安全目标分配通过系统级冗余 + 诊断实现同 I 类自身提供安全功能
ASIL 匹配不直接承担 ASIL可承担,但需文档支撑ASIL C/D 系统必须选 ASIL 认证元件
系统级 FMEDA失效率模型计入失效率 + 功能测试覆盖证据依赖供应商 FMEDA 数据或额外降低措施

关键判断:当系统 ASIL = C/D 且元件为 III 类时,必须选用对应 ASIL 认证的功能安全芯片——否则自证 FMEDA 工作量极大且风险高。


7. 实践案例

下面 3 个案例对应 EPS / 主驱场景的真实选型 —— 把分类原则映射到具体器件,显示 I/II/III 类如何在同一个 ASIL D 系统里协作。

器件类别安全角色评估方式
电流传感器(如 ACS780 系列)II 类多路独立 ADC + 不同供应商冗余 → ASIL D 电流采样文档分析 + 功能性能测试 + 冗余路径验证
数字隔离器 NSI82xxII 类在冗余关断路径中传递安全信号测试验证 + 时序裕量论证
高侧栅极驱动 NSI6911FIII 类直接提供 ASC Pin 关键关断职责必须 ASIL D 认证 + 厂商 Safety Manual

核心要点

  • ISO 26262 硬件要素按状态数 + 内部安全机制分 I/II/III 类——分类错就做错评估
  • I 类(电阻 / 电容 / 二极管):状态可全测,集成对即可,无需独立评估
  • II 类(运放 / ADC / CAN 收发器 / 简单驱动):文档 + 功能性能测试,无内部安全机制但有外部诊断
  • III 类(MCU / 带安全栅极驱动 / 多通道 PMIC):必须 ASIL 认证元件 + Safety Manual + FMEDA,否则自证工作量极大
  • 评估走 5 步流程:类别判定 → 文档收集 → 评估计划(按类裁剪) → 测试执行 → 证据归档
  • ASIL C/D 系统 + III 类元件 → 必须选对应 ASIL 认证芯片,这是芯片选型最重要的硬约束
  • 系统级 FMEDA 时:I/II 类用失效率模型,III 类依赖供应商 FMEDA 数据

Cross-references