ISO 26262 对车载雷达的 ASIL 等级怎么定

更新于 2026-10-23

关键词：ISO 26262,ASIL,车载雷达

摘要：ISO 26262 是道路车辆功能安全标准，ASIL（汽车安全完整性等级）反映的是失效后果的严重度、暴露率与可控性组合。雷达自身的 ASIL 不孤立存在，它从整车安全目标分解下来，随功能而变。本文讲清定级逻辑与文件组织方式。

关键词：ISO 26262、ASIL、车载雷达

一、ASIL 等级到底由什么决定

ASIL 由三个维度组合评定：严重度（S）、暴露率（E）与可控性（C），组合出 QM 到 ASIL D 的等级。对雷达而言，等级不是传感器固有属性，而是「这个雷达失效了，会连带什么功能失效、后果多严重」的函数。同一颗雷达用于不同功能，分解下来的要求可以不同。

二、整车安全目标怎么分解到雷达

安全目标在整车层定义，例如「不得发生非预期的紧急制动」。向下分解为功能安全概念，再分配到传感器、控制器与执行器。雷达这一层拿到的是「探测可用性」「误检约束」一类技术安全要求，以及对应的安全机制与验证目标。分解链要留痕，评审时能逐级追溯。

三、雷达常见的安全机制有哪些

典型机制包括多传感器交叉校验、信号合理性监控、帧计数与新鲜度检查、自检与降级策略。毫米波雷达还会看通道健康状态与校准状态监控。机制不是越多越好，要看它覆盖了什么失效模式、诊断覆盖率多少。文件上通常按「失效模式—安全机制—覆盖率」三列组织。

四、ASIL 等级在 RFQ 里怎么问

RFQ 问 ASIL 不能只问「你们产品是几级」，而要问「在这个功能的这个失效模式下，你们的安全机制与诊断覆盖率是多少、有没有对应证据」。我们的模板把 ASIL 拆成「目标等级 + 适用功能 + 机制清单 + 证据索引」四段，供应商逐段应答，评审时才有的可比。

五、软件工具链与开发流程也纳入要求

功能安全不只管硬件。开发流程、软件工具置信度、配置管理、变更影响分析都在范围内。对标准库来说，这意味着版本记录要能回答「这个结论依据哪一版标准、哪一版流程产出」。版本错配比数字错配更致命，因为评审按版本追溯。

六、常见误读有哪些

「买了 ASIL D 芯片整机就 ASIL D」是第一大误解——芯片能力不等于系统等级。「有证书就等于免论证」也站不住：认证覆盖范围有限，项目级论证仍要重做。还有把 EMC 合格报告当功能安全证据的，两者口径完全不同，不能互相顶替。

七、定级结论怎么落库

定级结论按「功能—失效模式—目标等级—机制—证据」五行落库，并标注所依据的标准版本。新功能接入时先查库，命中已有条目直接引用，未命中走分解流程。这样标准库才随项目增量生长，而不是每次从零开始。

结论： 1. 当雷达参与 ASIL C 及以上功能时，按 ISO 26262 补功能安全论证，机制与证据逐项对应。 2. 当供应商只提供芯片等级声明时，要求补项目级分解链与诊断覆盖率数据。 3. 当标准版本更新时，定级结论随版本刷新，禁止新旧版本结论混用。

标准条款查不到现行版本时怎么办

查不到现行版本时不猜、不套旧：在库里登记待补标记，写清标准号与用途，版本到位后整条刷新并通知引用方。用近似条款顶替，是送检阶段最省不下的返工。

遇到这类情况的顺序是：先按用途登记待补条目，再用当时能查到的最新文本临时标注，版本到位后整条刷新。临时标注必须显眼，避免被当成正式结论引用。

新旧版本结论混用会出什么问题

新旧混用的代价是整条结论作废：评审按版本追溯时拿不出依据，比数字错误更被动。我们按三码坐标反查影响面，换版时整体刷新，旧版归档可追溯。

混用不只发生在换版那一刻，更发生在引用时随手取了一条。版本坐标做成反查入口，换版影响面一跑就有清单，不依赖谁记得用过哪条。

条款里的限值怎么变成设计余量

限值落到工程要翻译成余量：把条款限值拆成每级电路的余量要求，写进评估协议，设计阶段就有明确目标。停在条文层面的合规，推到送测前才暴露代价。

翻译的颗粒度到电路级：哪一级留多少余量、哪一项由哪份报告背书，写进评估协议。硬件团队拿到的是可执行目标，不是法规条文。

不同市场的条款能互相引用吗

不同市场的条款不互换：FCC、ETSI 与国内口径各自独立，引用必须带市场与版本。出口部分单独组织分册，与国内条目物理隔离，避免一个版本号管所有市场。

引用时带市场前缀与版本号，索引层做硬隔离。出口项目的条款从出口分册取，国内条目不出现在出口文件包里，从结构上防混。

标准解读的结论怎么落库

解读结论按「标准号—条款—结论—版本」四行落库，项目复盘的误读案例回填到常见误读节。条目带来源，评审时逐行可核，不靠记忆维持口径。

落库时把常见误读单独成节：每条误读配一句纠正。这些案例是复用时最省时间的部分，也是团队口径最快的对齐方式。

标准差异怎么向团队讲清楚

讲清楚的方式是翻译成设计动作：每条差异落到谁改什么、改多少。停在条文层面的讲解，研发听完还是不知道动哪。

我们习惯把差异说明写成三行：差异是什么、影响哪个设计、验证方式是什么。三行讲不清的差异，通常是自己还没想清。

送检排期怎么与标准版本对齐

排期前先确认送检时有效版本，再倒推材料准备时间。版本悬而未决时，按两个版本分别准备对照表，省得临期翻工。

排期表里版本号是独立字段，与档期绑定。档期变了版本没变，材料照用；版本变了，材料重核。

合规结论怎么回复质疑

回复质疑靠三样：条款出处、版本号、测试条件。三样齐了，质疑回到技术层面讨论，不变成立场之争。

结论库里每条都带这三样的索引，被质疑时直接调档。调不出来的结论，本身就不该发布。

相关阅读

• 车载雷达 76–79GHz 频谱划分与 SRRC 型号核准按什么标准 — 射频核准口径先立住。
• AEB 对雷达探测距离和角分辨的最低要求怎么定 — 功能要求怎么落到指标。
• EMC 与功能安全标准库怎么建 — 两类标准怎么合并成一套库。