ASIL 不是 ECU 的属性：ISO 26262 用三个参数定级，QM 甚至不算安全等级
结论先行：在任何一份智能驾驶或底盘电控的技术方案里，「这个控制器是 ASIL D」都是一句不成立的话。ISO 26262 明确规定，ASIL 不是零件的固有属性，而是危害分析与风险评估（HARA）的结果——由严重度（S）、暴露概率（E）、可控性（C）三个参数组合推导得出，且同一个控制器在不同功能中可能对应不同等级。更常被误读的是 QM：当任一参数取 S0、E0 或 C0 时，结果为 QM，而标准在 ASIL 定义的注释中明确写道，QM 不是一种 ASIL，它意味着 ISO 26262 的安全生命周期根本不会被触发，按普通质量管理即可。 把 QM 当作最低安全等级来管理，是功能安全项目里最常见的系统性偏差。
一、定级：S、E、C 三个参数怎么组合
HARA 的输入是「危害事件」，即「功能失效 + 运行场景」的组合，而不是单一零件。三个参数的取值方式如下：
| 参数 | 含义 | 取值 |
|---|---|---|
| S（Severity） | 伤害严重度 | S0 无伤害；S1 轻中度；S2 重伤但存活概率高；S3 危及生命至致命 |
| E（Exposure） | 场景出现频率 | E0 极不可能；E1—E3 逐步升高；E4 高（多数运行工况下发生） |
| C（Controllability） | 驾驶员可控性 | C0 一般人可控制；C1—C2 逐步变难；C3 难以控制或不可控 |
组合结果是：S3 + E4 + C3 得到 ASIL D，最严苛；而任何包含 S0、E0 或 C0 的组合都得到 QM。制动系统的电动助力控制通常属于 ASIL D；信息娱乐系统往往只需 QM 或较低等级。这个分级机制的意义在于「既保障关键功能的安全，又避免过度设计带来的成本浪费」——把娱乐系统按 ASIL D 开发，是纯粹的浪费；把制动助力按 QM 开发，则是灾难。
二、ASIL 到底触发了什么
等级决定的不是「做不做」，而是「做到什么强度」。要求在 ASIL A—D 上都适用，但方法表按等级分级：某些在 ASIL A 上「不做推荐」的方法，在 ASIL D 上实际是强制的。工作分散在标准的不同部分：
| 部分 | 内容 | 关键产出 |
|---|---|---|
| Part 5 | 硬件级产品开发 | 硬件架构度量（SPFM、LFM）、随机硬件失效目标（PMHF 通常要求 < 10 FIT） |
| Part 6 | 软件级产品开发 | 安全需求、架构、单元设计与实现、验证 |
| Part 9 | ASIL 分解与共存准则 | 允许将安全目标分解到多个独立要素 |
| Part 10 | 脱离上下文的安全要素（SEooC） | 无具体整车场景下的组件开发，须文档化使用假设 |
关于 Part 9 的 ASIL 分解，有一句必须记住的前提：分解不影响随机硬件失效的相关要求。 把一个 ASIL D 的功能拆成两个 ASIL B（D）的冗余通道，并不意味着硬件指标可以放宽——SPFM 与 LFM 的计算方法不变。分解降低的是开发流程的严格度，而不是硬件的可靠性门槛。
三、ISO 26262 管故障，SOTIF 管不足
两个标准的分界必须分清。ISO 26262 处理的是 E/E 系统自身故障导致的风险；而因环境感知不足、算法局限性等功能不足引发的风险，属于 ISO 21448（预期功能安全，SOTIF）的范围。现行版 ISO 26262 为 2018 年发布的第二版，第三版已于 2026 年 8 月 4 日登记为国际标准草案（DIS）；标准共 12 个部分，2018 版新增了卡车、客车、挂车与半挂车的要求，并首次设立 Part 12（摩托车）与 Part 11（半导体应用指南）。
把 SOTIF 当成「多加几个测试用例」是软件团队进入汽车行业最常见的错误。SOTIF 本质上是一个关于残余风险的论证，需要在上游定义场景覆盖证据与接受准则，而不是在代码写完之后补一套测试集。与之配套的 ASPICE 也已更新：过程评估模型 4.1 版于 2026 年 8 月 24 日发布，取代 2023 年 11 月的 4.0 版，能力等级从 0（不完整）到 5（创新）共六级，每个过程属性按 N/P/L/F 四档评分。
自动驾驶真正的难点从来不是「让它跑起来」，而是「证明它安全」。业界的一个量化参照是：靠里程数证明安全性，需要的无致死事故里程约 2.75 亿英里——没有任何一家公司付得起这个成本，所以场景化测试与论证取代了随机里程。
四、对供应链协作的实际含义
第一，安全需求必须通过接口协议显式传递。 一辆现代汽车拥有数百个来自不同供应商的 ECU，要让所有子系统遵循统一的安全目标，OEM 与 Tier 1、Tier 2 之间需要明确的安全需求接口与可追溯的安全档案。任何一环的疏漏都会让整车安全目标失效。
第二，SEooC 是供应商的常规作业方式，但必须写清使用假设。 开发一个不知道具体装车场景的模块时，对该模块后续使用方式的假设文档，是判断这个零件能否装进目标车型的唯一锚点。假设缺失，等于把集成风险全部留给整车厂。
第三，成本与进度压力会侵蚀功能安全。 贯彻整套标准意味着在物料、设计、测试与管理上的持续投入，这与价格战和压缩的开发周期直接冲突。有业内人士指出，功能安全在实践中有时不得不妥协甚至流于形式——这恰恰是新版标准与 Euro NCAP 2026 把安全要求进一步量化、把物理控制件重新纳入评分的原因。
判断一个项目的功能安全是否落地，有一个很朴素的检验方法：让团队把每一个安全目标的 ASIL 等级、推导它的 S/E/C 取值、以及对应的硬件度量结果写在同一张表上。如果这张表填不出来，等级大概率是「抄来的」，而不是算出来的。
微信分享
微信扫一扫，或复制链接发送给朋友
版权声明转载请说明出处 —— 本文为 VEXIA新势力 原创整理，版权归 VEXIA新势力 所有，转载请注明来源 blog.vexia.cn