摘要：ASIL E 目前不是正式标准。它真正有价值的地方，不是提出了一个更高等级名称，而是把 L4/L5 自动驾驶安全论证里一个长期存在的问题说清楚了：当车里没有人时，安全案例不能继续 credit 一个不存在的人类控制者。对我来说，这份 proposal 更适合被翻译成三类工程资产：一页 L4 无人兜底审查清单、ADSafetyPilot 里的四个证据字段，以及 ROAM / DRIVEResearch / ADSafetyPilot 之间的一条运行阶段证据闭环。

前段时间，我在 LinkedIn 上看到一位功能安全同行发了一个 proposal，题目很直接：

The Case for ASIL E.

本地 PDF 是 79 页，副标题是 A Sixth Integrity Level for L4/L5 Autonomous Systems。它的核心观点是：ISO 26262 的 ASIL D 是当前最高等级，但它背后的 controllability 逻辑，来自一个仍然有驾驶员作为残余控制者的世界。到了 SAE L4/L5，系统设计目标就是不依赖驾驶员接管，这个假设会断掉。

我读完之后，第一反应不是“ASIL E 要来了”。

恰恰相反，我的第一反应是：

这不是一个新等级问题，而是一个老问题终于被说清楚了。

L4 无人兜底安全证据链

先把边界说清楚

截至 2026 年 6 月 3 日，ASIL E 不在已发布的 ISO 26262、ISO 21448 或 UL 4600 中。

这份 guidebook 自己也写得很清楚：proposal, not a standard。

所以，如果有人把它包装成“ISO 26262 已新增 ASIL E”“L4 必须满足 ASIL E”“ASIL E 合规认证”，我会先打一个问号。

安全标准这件事，还是慢一点说比较好。

一个更高的等级名称，不会自动让系统更安全。真正值得讨论的是它背后的问题：

当系统进入 L4，安全案例还能不能继续沿用“人类司机最终兜底”的隐含假设？

这句话，是我认为这份 proposal 最有价值的地方。

ASIL D 没错，但它不回答所有问题

ISO 26262 的 HARA 里，ASIL 来自三个维度：

  • Severity，严重度。
  • Exposure，暴露度。
  • Controllability，可控性。

前两个维度比较容易理解。事故后果多严重，场景出现多频繁。

第三个维度麻烦一些。

Controllability 不是系统自己说“我能不能控制”，而是危险事件发生后，一个典型驾驶员能不能避免伤害。

在 L2、L3 的很多场景里，这个问题还说得过去。驾驶员虽然可能分心，可能接管慢，但他的角色仍然存在。尤其在 L3 里，驾驶员是 fallback-ready user，系统要给出接管请求，驾驶员仍是安全论证中的关键一环。

到了 L4，这句话就变成了一个逻辑问题：

如果车里没有需要接管的人，我们到底在评价谁的可控性？

行业里常见的做法，是把这类场景直接打到 C3，也就是现有 controllability 里的最保守一档。这样做当然有它的合理性。

但它没有真正回答问题。

C3 的意思是“很难控制或不可控”。L4 的问题不是“很难由司机控制”，而是“没有司机控制”。

这两个句子只差一个词，工程含义却差一层楼。

如果这个差别没有被显式写进安全案例，后面所有 HARA、FMEA、FTA、SOTIF 场景分析、仿真测试和安全论证，都可能在一个不稳定的假设上继续往前搭。

这不是替代 SOTIF 和 UL 4600

我不认为 ASIL E 应该被理解成“用一个更高 ASIL 取代 SOTIF 或 UL 4600”。

恰恰相反，它更像一个校准问题。

ISO 26262 主要处理 E/E 系统随机硬件故障和系统性失效带来的功能安全问题。ISO 21448 处理预期功能或实现性能不足导致的不合理风险，也明确覆盖需要 situational awareness 的驾驶自动化功能，并且把 operation phase 的活动纳入 SOTIF 的维持过程。ISO 21448 的公开页面还明确提到：远程用户或后台通信如果会影响车辆决策并可能导致安全危害，也在讨论范围内。

UL 4600 的思路又不一样。它不是靠列一个固定测试清单证明自动驾驶产品“安全”，而是要求建立 safety case，说明系统为什么在预期运行环境中可接受。

所以，L4 无人兜底问题不应该被塞进某一个标准里单独解决。

更合理的工程视角是：

  • ISO 26262 问：如果这个 hazard 来自 E/E 故障，安全目标和完整性目标如何分配？
  • ISO 21448 问：如果系统没有故障，但功能不足、性能局限、合理可预见误用或远程 / 后台因素带来风险，如何识别、验证、监控和更新？
  • UL 4600 问：你的 safety case 是否能把系统、ODD、证据、论证和运行阶段反馈连成一条闭环？
  • ASIL E proposal 问：在这些论证里，你是否暗中借用了一个不存在的人类控制者？

我更愿意把它称为 no-human-controller review lens。

它不是一套新宗教。

它是一副检查隐含假设的眼镜。

L4 真正缺的是共同语言

这几年我参与和观察的 L3/L4 项目里，大家其实都知道这个问题存在。

只是说法不同。

有人叫 fail-operational。

有人叫 MRM。

有人叫远程运营。

有人叫安全冗余。

有人在 UL 4600 的 safety case 里写一组 argument。

有人在 SOTIF 里把它拆成触发条件、未知不安全场景和运行阶段监控。

这些都对。

但我自己越来越觉得，我们缺一个行业共享的、足够短的句子，把风险说出来：

这个系统出事时，不能 credit 一个不存在的人。

这就是我为什么觉得 ASIL E proposal 有意思。

它未必是最终答案，但它把问题命名了。

很多工程方法的第一步，不是立刻解决问题，而是让大家终于承认在讨论同一个问题。

我把它翻译成了四个产品字段

说来惭愧，我现在看一份技术 proposal 的方式，越来越不像纯学者。

如果只是读完点个赞，这 79 页很快就会被信息流冲走。

我现在更倾向于问三个问题：

  • 能不能变成一页内部 memo？
  • 能不能变成产品里的字段？
  • 能不能变成一个能继续沉淀的研究问题？

这也是我现在在英国期间被迫形成的工作方法。上午到下午的有效工作窗口很短，过了时间就要切回带娃模式。屏幕时间也要控制，眼睛不允许我无限“深度研究”。

所以我越来越接受一个原则：

70% 够用，先把洞察变成可复用资产。

这次我先做了一件很小的事：把 ASIL E proposal 翻译成 ADSafetyPilot 里的四个字段。

第一个字段是 no_human_controller。

意思很直白：这个危险事件里，安全案例是否不再 credit 人类驾驶员。

第二个字段是 fallback_credit。

它要求把 fallback 说清楚。到底 credit 的是谁？车内驾驶员、远程操作员、远程协助员、现场人员、基础设施，还是没有人？

第三个字段是 policy_coverage_gap。

这是我认为 L4 最容易被低估的部分。很多事故不是“车没看见”，而是“车看见了，但不知道该怎么做”。

比如：

  • 应急车辆从后方接近。
  • 施工区临时改道。
  • 人工交警指挥和地图不一致。
  • 乘客、远程客服、现场人员同时给出不同信号。

这些都不是单纯的感知问题，而是策略覆盖问题。

第四个字段是 field_monitoring_evidence。

L4 的 safety case 不能只在 SOP 前写完。真正上路之后，运行阶段事件、异常处置、远程运营记录和软件更新，都应该回到安全证据链里。

这四个字段很朴素，甚至有点笨。

但它们能帮我在看一个 L4 safety case 时少漏一个问题：

这个项目到底有没有把“车里没人”这件事写进安全论证？

ROAM 是同一个问题的运行阶段版本

过去一段时间，我一直在推进 ROAM。

它现在的定位是 Remote Operations & Anomaly Management，不再只局限于 Robotaxi，而是面向更广义的 L4 自动驾驶远程运营与异常管理。

它最初看起来像一个“事件库”。

但越做越清楚，它真正想解决的不是记录八卦式事故，而是把运行阶段异常变成安全证据。

比如一批车辆在某个区域异常停车。

比如远程协助响应滞后。

比如应急车辆、施工、基础设施扰动让车队进入异常状态。

这些事件不完全是传统 ISO 26262 的随机硬件故障，也不完全是单一感知算法失效。

它们更像是 L4 系统进入真实运营后暴露出的运行阶段安全管理对象。

ISO 21448 里本来就强调 operation phase 的监控、触发条件识别和问题解决。远程用户、后台通信如果会影响车辆决策，也不能简单放到安全分析之外。

我希望 ROAM 做的，就是把这些事件结构化：

  • 发生了什么。
  • 在哪个 ODD。
  • 影响了多少车。
  • 是否涉及远程运营。
  • 处置层级是什么。
  • 形成了哪个新的触发条件。
  • 需要更新哪个测试用例。

这样一来，运行阶段就不只是“出事之后写报告”，而是持续更新 safety case 的证据源。

这和 ASIL E proposal 背后的问题，是同一件事的两个侧面。

一个从开发阶段问：

没有司机兜底时，完整性目标怎么表达？

另一个从运行阶段问：

系统已经上路之后，异常如何回到安全证据链？

我在上一篇关于 ROAM 的文章《无人车出了事，谁来兜底？》里讨论的是第二个问题。这篇文章补的是第一个问题。

DRIVEResearch 提供统计基准

还有一块拼图，是自然驾驶数据。

如果只说“L4 要更安全”，这句话没有工程含义。

更安全多少？

在哪些场景更安全？

哪些场景是主流行为，哪些是边界行为？

这时 DRIVEResearch 的价值就出来了。

我们目前积累了 800h+ 航测自然驾驶数据，10.5M+ 轨迹片段。它不是为了证明“数据很多”，而是为了回答更具体的问题：

  • 正常人类驾驶员在这个场景里通常怎么做？
  • cut-in 的横向速度、纵向间距、TTC、THW 分布是什么？
  • 某个测试点是 P50 的主流行为，还是 P95 的边界行为？
  • 新增数据之后，百分位是否已经收敛？

这些问题，刚好可以进入 SOTIF 和测试证据链。

L4 无人兜底，不意味着每个场景都要用最极端的参数压系统。

它意味着我们要知道，哪些场景是合理可预见，哪些是已知不安全，哪些是未知不安全，哪些只是样本还不够。

没有真实分布，安全目标很容易变成口号。

有了真实分布，安全论证才开始有了地面。

这也是我为什么把 ASIL E proposal 和 OpenODC 放在同一条内容链上看。

OpenODC 问的是：

一个系统的运行边界，到底有没有被公开、可查、可比、可追溯地描述出来？

ASIL E proposal 问的是：

当系统在这个边界内运行且没有人类司机兜底时，安全完整性论证有没有把这个事实写清楚？

DRIVEResearch 问的是：

这些边界和场景参数，能不能从真实交通行为分布里找到统计支撑？

这三个问题合在一起，才像一条完整的 L4 安全证据链。

一张我会用的复盘清单

如果把这份 proposal 放回我最近在做的项目里，它首先不是一个立场，而是一张复盘清单。

放到 HARA 里，我会先问：

  • 这个 hazard 是不是无人兜底？
  • MRM 是否真的能完成？
  • 远程运营是否被错误地当成实时控制者？
  • 文档里写的“驾驶员可干预”，在 L4 ODD 内是否真实存在？

放到策略覆盖里，我会问：

  • policy coverage 是否单独分析？
  • 感知正确但策略不知道怎么做的场景，有没有被列出来？
  • 应急车辆、施工区、人工指挥、地图冲突、乘客行为和现场人员指令是否进入策略空间？

放到运行阶段，我会问：

  • field monitoring 是否会更新 safety case？
  • 每次异常是否记录触发条件、系统状态、策略响应、人工介入、恢复动作和后续变更？
  • 运行阶段事件能否反向生成测试用例？

放到标准和论文选题里，我会把“ASIL E 是否合理”往后放半步，先看几个更能落地的问题：

  • 无人兜底场景如何分类？
  • 远程运营介入的时间预算如何建模？
  • policy coverage 怎么量化？
  • 运行阶段事件如何反向生成测试用例？
  • 自然驾驶分布如何给 L4 safety case 提供统计基准？

这些问题离工程更近，也更容易沉淀成论文、工具和标准素材。

我自己的下一步

这次我不会把它停在阅读笔记。

我已经先写了一页内部 memo，把它翻译成“L4 无人兜底审查清单”。

然后在 ADSafetyPilot 的证据链设计里加了四个字段：

  • no_human_controller
  • fallback_credit
  • policy_coverage_gap
  • field_monitoring_evidence

下一步，我会选一个 L4 应急车辆交互场景，把它做成完整 evidence gap report。

我会选这个场景，不是因为它最炫，而是因为它足够麻烦。

它同时包含感知、策略、远程运营、交通规则、现场处置和运行阶段监控。

它比单纯讨论 AEB 行人夜间检测更能暴露 L4 的系统性问题。

也更适合把 ROAM、DRIVEResearch 和 ADSafetyPilot 串起来：

  • ROAM 记录运行阶段异常。
  • DRIVEResearch 提供真实行为分布。
  • ADSafetyPilot 把场景、风险、测试和证据链串起来。

这也是我理解的内容复利。

不是写一篇文章就结束，而是每一篇文章都推动一个工具、一个数据集、一个标准问题或一个研究方向往前走一步。

最后

ASIL E 这个名字最终会不会进入标准，我不知道。

而且坦率说，这不是我最关心的问题。

我更关心的是，L4 自动驾驶行业能不能形成一种共同语言，把“没有人类司机兜底”这件事讲清楚。

因为只要这个问题讲不清楚，ASIL D、SOTIF、UL 4600、安全案例、仿真测试、运行监控，就会各说各话。

看起来每个文件都完整。

但最危险的那个假设，可能藏在文件和文件之间。

标准不会替系统兜底。

真正兜底的，是你能不能把“没有人接管”这件事，变成一条可审查、可测试、可追溯的证据链。

References