核心问题：安全包络都检测哪些项？监控器在做检查过程中，E2E大模型的轨迹是不是处于放行状态？检查延迟是如何处理和解决的？
摘要：安全包络从多个维度（物理/几何/最小风险距离/规则/预测/健康/ODD…）做早期退出式检查，5-15ms 完成。E2E 轨迹不是"等检查再放行"——业内用"双缓冲 + 并行审核 + 预测补偿"架构：控制器永远在执行上一条已批准的轨迹（剩余 3+ 秒余量），监控器并行审核新轨迹，通过则原子切换，不通过则继续旧的或切 MRC。这样既零延迟感知，又始终安全可控。
第一部分：安全包络检查项
A. 自车物理可行性
→ 一次乘法+比较，< 1ms 完成。
B. 时空可达性
C. 道路几何包络（Drivable Area）
- 整条轨迹必须在可行驶区域内（来自高精地图 + 监控器自己的占据栅格）
D. 交通参与者包络
| |
|---|
| 纵向最小距离 | 纵向公式（可参考 Mobileye RSS 公式） |
| 横向最小距离 | 横向公式（可参考 Mobileye RSS 公式） |
| TTC（Time to Collision） | |
| THW（Time Headway）：当前时刻，后车走完"当前与前车的距离"所需要的时间 | |
| PET（Post Encroachment Time）：两个交通参与者先后进入同一冲突点（Conflict Point）的时间差 | |
| 轨迹相交检查 | |
| 最坏情况预测 | 他车假设急刹 + 突然变道 + 突然加速三种最坏情况 |
→ 对每个目标算一次，~5-10ms。
E. 交通规则合规
机器可读规则引擎：
F. 预测不确定性边界
- 其他车辆/行人预测有不确定性（典型 σ = 0.3m/s × T）
G. 系统健康度（Self-Diagnostic Envelope）
H. ODD（运行设计域）包络
判断当前场景是否还在系统设计的运行范围内：
→ 出 ODD 必须触发 MRM/MRC。
检查时序——并不是顺序全跑
实际是“早期退出（Early Exit）”模式：
轨迹到达 ↓A 物理可行性 ─失败→ 拒绝（1ms 内完成） ↓ 通过B 时空可达性 ─失败→ 拒绝 ↓ 通过C 道路几何 ─失败→ 拒绝 ↓ 通过D RSS + TTC ─失败→ 拒绝（最耗时，5-10ms） ↓ 通过E 交通规则 ─失败→ 拒绝 ↓ 通过F 不确定性边界 ─失败→ 降级（次优轨迹） ↓ 通过G + H 系统健康 ─失败→ 触发 MRC ↓ 全通过PASS → 批准放行
监控器整体决策延迟典型 5-15ms。
第二部分：执行延迟问题
事实：延迟无法消除，只能管理
典型 L4 系统端到端延迟拆解：
| |
|---|
| |
| |
| |
| E2E 大模型推理 | 30-100 ms |
| |
| |
| |
| 总端到端 | 100-300 ms |
100km/h ≈ 28m/s，200ms 延迟 = 车移动 5.6 米。
E2E 轨迹是不是"放行状态"？——三种架构对比
架构 1：严格串行
时刻 T: 传感器 ──→ E2E推理 ──→ 监控器审核 ──→ 控制器执行 5ms 100ms 10ms 开始执行 ↑ 总延迟 115ms 后才动
业内不建议这样做，因为延迟和失控风险都不可接受。
架构 2：双缓冲 + 并行审核
核心机制：
┌─────────────────────────────────────────────────────────────┐│ 控制器（永远在执行某条"已批准"的轨迹，从不空档） │└─────────────────────────────────────────────────────────────┘ ↑ ↑ ↑ │ │ │ 批准切换 批准切换 批准切换 │ │ │┌─────────────┴────────┐ ┌──┴────────┐ ┌──┴────────┐│ E2E T_n（已批准） │ │ T_n+1 │ │ T_n+2 ││ 正在被执行 │ │ 审核中 │ │ 待审核 │└──────────────────────┘ └───────────┘ └───────────┘ ↑ 是未来 3-8 秒的轨迹 ↑ 监控器并行审核 即使 E2E 卡死也能滑行 不阻塞控制器
轨迹是未来 3-8 秒的"计划"，不是单点指令
- 即使 E2E 完全卡死 100ms 甚至 1 秒，控制器还能按已批准的旧轨迹滑行
控制器永远执行"上一条已批准轨迹"
- 新轨迹到达 → 监控器审核 → 通过则切换 → 不通过则继续旧的
监控器和控制器完全并行
双缓冲（Double Buffer）
- 内存里始终有两条轨迹：Active（执行中）+ Pending（待审核）
时序图
时间 → 0ms 50ms 100ms 150ms 200ms 250ms ┌────┬────┬────┬────┬────┬────┬────┬────┬────┐传感器 │ S1 │ │ S2 │ │ S3 │ │ S4 │ │ S5 │ └────┴────┴────┴────┴────┴────┴────┴────┴────┘E2E ├──────推理 T1──────┤ ├──────推理 T2──────┤监控器 ├审核┤ ├审核┤ ↓ PASS ↓ PASS控制器 ░░░T0░░░░░░░░░░░░░░░░░░│███T1██████████████│███T2███ ←已批准旧轨迹在执行→ 切换 继续执行新轨迹
- 控制器在 0-100ms 执行 T0（更早批准的轨迹）
如果监控器拒绝了 T_n+1 怎么办？
控制器 ███T_n（已批准）████████████████████████████████ ↑ T_n+1 被拒绝 │ 继续执行 T_n（剩余 3+ 秒可用） │ ↓ 同时启动 MRC 兜底 │ ↓ 若 T_n+2 也被拒 → 切换到 MRC 轨迹
监控器始终维护一条"MRC 轨迹"在后台，随时可切。即使 E2E 持续异常，监控器自己规划的简单兜底轨迹立刻可用。
架构 3：流水线 + 预测补偿
更先进的做法：
- 预测补偿：E2E 输出的轨迹起点不是"当前位置"，而是"100ms 后的预计位置"（参考示例）
传感器 t=0 ──→ E2E 推理（用 t=0 数据预测从 t=100ms 开始的轨迹） ↓ 监控器审核 ↓ t=100ms 时执行（无延迟感知）
业内的高端方案可考虑用这种预测补偿 + 流水线的方案。
第三部分：极端情况的安全保证
最坏情况兜底：刹车系统有独立的硬件冗余通道——即使所有计算单元全部宕机，紧急刹车也能被触发。
针对延迟的核心约束项
WCET 分析（Worst Case Execution Time）
- 每个任务的最坏执行时间都要被静态分析 + 测试验证
- 不允许"通常很快"，必须"最坏也能在 X ms 内"
时间触发架构（Time-Triggered Architecture）
时间戳全链路同步
降级层级（Degradation Hierarchy）
以下为参考示例，具体 MRM 降级策略需依据产品详细制定：
注：流程图、时序图等都是由AI根据文本自动生成。
10个月宝宝每天需要喝多少奶粉？
