ISO 26262 功能安全标准

ASIL等级如何规划：从产品功能到HARA与工程分配

技术解读文章｜含专题PPT图示

图 1　ASIL等级规划专题封面图

本文面向汽车电子、电驱、底盘、约束、车身与照明等产品开发团队，解释如何在ISO 26262框架下规划QM与ASIL A、B、C、D。文章的核心结论是：ASIL不是一个产品名称、ECU名称或芯片料号自带的标签，而是特定危险事件经过危害分析与风险评估后形成的安全目标属性。

因此，讨论“某产品对应什么等级”时，正确的工作单位不是整机，而是产品内的安全相关功能、其失效行为、运行场景、危险事件和安全目标。只有把这条链条建立起来，后续的功能安全需求、技术安全需求、软硬件分配、供应商接口和验证证据才具有可审计的共同语言。

摘要

ISO 26262的等级规划应从Item Definition开始。团队首先要定义产品的功能边界、车辆接口、外部依赖、运行状态和合理可预见的使用场景。随后，团队识别可能的失效行为，并将其放入车辆场景中判断是否会形成危险事件。针对每一个危险事件，项目按严重度、暴露度和可控性进行评估，并依据规范风险图得到QM或相应的ASIL。

这一结论随后被写入安全目标，并由功能安全概念和技术安全概念向下分配到系统、硬件、软件、通信接口和外部安全机制。产品中的不同功能可以拥有不同的安全目标和等级。供应商的芯片或器件即使提供SEooC、ASIL capability或安全手册，也只能作为系统论证的输入，不能替代项目HARA或自动形成整车ASIL结论。

1. ASIL不是产品标签，而是危险事件的工程结论

图 2　ASIL不是产品、芯片或宣传标签

把“逆变器是ASIL D”或“BMS是ASIL C”作为项目结论，通常会掩盖关键工程问题。一个电机控制器既可以承担扭矩执行、传感器监测和快速关断等安全相关功能，也可以承担服务记录、非安全遥测和便利功能。这些功能面对的失效行为和人员后果并不相同，因此不应被同一个整机等级概括。

同一功能在不同车辆架构下也可能得出不同结果。例如，失去牵引扭矩的后果会受到车辆速度、道路场景、机械传动关系、驾驶员可控性以及是否存在其他可用执行路径的影响。规划时应把产品名称改写为“功能—失效行为—场景—危险事件—安全目标”的表述。这样才能让等级结论与项目边界一致。

在项目讨论中，先把这条链写清楚，往往比先争论“应该定成几级”更有效。它能够让系统、硬件、软件、测试和供应链团队围绕同一问题展开讨论，也能把后续的分配与验证工作提前到可执行的层面。

2. QM与ASIL A/B/C/D：等级表达的是工程严谨度

图 3　QM与ASIL A/B/C/D的等级阶梯

QM表示相应危险事件的风险评定没有达到ASIL，并不意味着产品不需要质量管理。ASIL A是最低的功能安全等级，ASIL D是最高等级。随着等级提高，项目通常需要采用更严格的安全管理、需求控制、架构分析、独立性、验证和确认活动。具体活动必须按适用标准条款和项目裁剪确定，不能简单地把等级理解为固定数量的测试用例或固定比例的冗余。

ASIL也不等同于故障概率、产品质量分数或跨行业安全等级。它描述的是为满足某个汽车功能安全目标所需的开发严谨度和论证强度。项目应避免把QM视为“低等级ASIL”，也不应把ASIL A与QM混用。

3. 从Item到Safety Goal：等级规划必须沿着完整风险链展开

图 4　Item、HARA、安全目标和需求分配的端到端逻辑

等级规划的第一步是Item Definition。它需要明确产品提供什么功能，连接哪些ECU、传感器和执行器，在什么状态下运行，并依赖哪些外部措施。第二步是识别失效行为，例如错误扭矩、非预期制动、错误转向、误触发或功能丢失。第三步是把失效行为放入具体运行场景，形成对道路使用者有意义的危险事件。

HARA的输出不是一串孤立的等级，而是带有危险事件、判断依据和安全目标的记录。安全目标进一步形成FSR，并由TSR分配到电源、传感器、MCU、栅驱、通信、软件状态机和外部执行机构。只要产品边界、运行场景、安全状态或外部依赖发生变化，项目就需要回查HARA，而不能只修改下游需求标签。

4. S/E/C判断必须以场景为单位，而不是以公式为单位

图 5　HARA中严重度、暴露度与可控性的判断台

严重度描述事故后果。暴露度描述危险运行情景出现的可能性。可控性描述驾驶员或其他道路使用者避免伤害的能力。这三个维度必须围绕同一个危险事件判断。一个孤立的零件故障，如传感器断线或功率器件短路，并不能直接给出ASIL；只有当它被解释为某一场景下的车辆行为并产生人员后果时，HARA才有完整对象。

工程上不应将S、E、C相乘、平均或自定义打分。项目需要采用受控的风险图和统一的场景假设。每一条判断应记录车辆状态、道路环境、速度范围、交通情况、驾驶员接管能力以及外部安全措施。这样，等级结论才可以被复核、变更和追溯。

5. 电机控制器的正确规划方式：同一控制器可以承载多种等级

图 6　电机控制器内的多功能、多场景与多等级规划示意

电机控制器中的扭矩执行、相电流采集、转子位置测量、栅驱保护和通信接口，都可能参与同一个车辆级安全目标。扭矩执行路径需要重点关注非预期推进、反向扭矩和错误扭矩。传感器路径需要考虑漂移、卡滞、失真、断线和短路。栅驱和功率级需要考虑过流、欠压、关断失效与故障传播。通信路径需要考虑命令丢失、延迟、错误值和错误状态。

这些功能的ASIL不应被“电机控制器”这一名称覆盖。项目应定义安全目标，再将相应的FSR和TSR分配给控制、监测、保护和接口路径。与车辆危险行为没有直接关联的服务记录、非安全遥测和便利功能可能处于QM范围，但仍需通过Item边界和HARA确认。

6. 动力与能源产品：将等级规划嵌入安全功能与运行状态

图 7　动力与能源产品的功能化ASIL规划地图

牵引逆变器和电机控制器的规划重点是扭矩命令完整性、传感器合理性、PWM禁止和功率级故障反应。BMS的规划重点包括单体过压和欠压、温度、绝缘、接触器、过流以及功率限制。OBC和EVCC需要覆盖插枪确认、充电功率请求、HV状态机、绝缘、温度和停止充电。HV-LV DC/DC则需要从其供电对象出发，分析隔离、过欠压、关键低压负载可用性和失电传播。

同一个动力产品在停车、行驶、充电、故障中断、碰撞后和维修状态下可能具有不同的危险事件。安全状态也不能只写成“断开”或“关机”。例如，高速行驶中的不当断开可能引入新的风险。项目必须将安全状态、故障反应时间和车辆级后果一并纳入安全概念。

7. 底盘、约束、车身与灯光：从产品域进入功能与场景

图 8　制动、转向、约束、车身和灯光的ASIL规划地图

制动和转向通常涉及车辆运动控制，因此应优先开展高后果失效分析。制动系统需要关注无制动、非预期制动和左右不对称。转向系统需要关注错误方向、非预期转向、卡滞和助力丢失。约束系统需要关注误触发、漏触发和触发时序。车身和灯光功能则需要判断其是否会影响车辆运动、逃生、道路可见性或其他道路使用者的判断。

即使同属一个产品域，功能等级也可能不同。普通便利功能可能是QM，关键互锁、车辆状态判断或外部信号功能则可能形成安全目标。项目应将“产品域”作为分析入口，而不是将其视为ASIL结论。

8. 从安全目标到架构：ASIL应随需求分配到MCU、接口和执行器

图 9　安全目标向MCU、接口和功率执行路径的分配示意

安全目标需要被转化为可实现、可验证的技术要求。以非预期牵引扭矩为例，项目可能需要定义输入命令合理性、传感器交叉校验、控制状态机、诊断策略、看门狗、快速PWM禁止、栅驱故障反馈和功率级受控等机制。每一项机制都需要说明触发条件、周期、反应时间、外部依赖、失效动作和验收方法。

同一ECU可以同时承载QM功能与不同ASIL功能，但必须处理资源共享、软件干扰、配置错误、共因失效和变更影响。接口不是简单的信号线，而是需要定义数据语义、状态、周期、超时、保护、故障反应和验证证据的工程契约。

9. 芯片和器件的安全能力：以集成契约而非宣传标签使用

图 10　SEooC、项目集成与系统安全目标之间的边界

MCU、传感器、栅极驱动器和通信接口可能提供锁步核、ECC、看门狗、自检、诊断、故障脚或物理层监控等安全贡献。供应商通常通过安全手册、Assumptions of Use、失效模式、诊断覆盖、配置限制和版本信息描述这些能力。它们是项目架构和验证的重要输入。

但是，项目仍需核对使用假设是否满足。例如，时钟、电源、启动顺序、看门狗配置、诊断周期、外部监控、温度边界、通信保护和故障反应是否都落在供应商声明范围内。若假设不成立，项目必须补充安全机制、调整设计或重新进行影响分析。芯片能力不能替代系统HARA，也不能自动证明产品ASIL。

10. ASIL分解：只有独立性和DFA成立时才是有效架构手段

图 11　ASIL分解的逻辑边界与独立性要求

ASIL分解用于将一个安全需求以受约束的方式分配到冗余通道。分解不能针对Safety Goal本身进行，也不能把两个低等级组件简单相加后宣称得到高等级结果。项目必须依据适用标准组合、原始ASIL上下文和架构条件开展分解。

分解成立的核心是独立性。项目需要证明通道之间不存在未受控的共同电源、共同时钟、共同输入、共同软件缺陷或故障级联路径，并通过Dependent Failure Analysis检查共因与相关失效。即使需求经过分解，顶层安全目标、车辆级验证和安全评估仍保留原始风险上下文。

11. 八步法：把“产品等级”问题转化为可评审的项目工作包

图 12　ASIL规划八步法与项目评审红旗项

项目可以采用八步法推进：定义Item；枚举功能与失效行为；建立场景和危险事件；评定S、E、C；定义安全目标和QM/ASIL；形成FSR与功能安全概念；分配TSR与技术架构；完成验证、确认和安全论证。该顺序使每个等级结论都能够回溯到项目事实。

首次评审应至少具备Item边界、状态和接口清单，产品功能清单，代表性场景库，故障假设，以及供应商安全资料。任何缺少HARA、缺少场景依据、只引用芯片宣传、等级无法追溯、无法说明安全状态或无法给出验证路径的结论，都不应作为正式放行依据。

结语

ISO 26262的等级规划不是对产品贴标签，而是把车辆风险转化为工程约束的过程。产品团队只有从功能、场景和危险事件出发，才能说明为何需要某个安全目标、为何该安全目标具有相应的QM或ASIL、其要求如何被分配、以及证据如何闭环。

当讨论“不同产品对应什么等级”时，最有价值的答案不是给出一个固定的行业标签，而是建立一张能够持续维护的功能安全等级规划表。该表应连接产品功能、失效行为、运行场景、S/E/C依据、安全目标、FSR、TSR、架构元素、供应商假设、测试证据和变更影响。这样，ASIL才会成为项目管理、设计评审和供应链协同的共同语言。