2. 自动驾驶感知与推理基础
自动驾驶系统的“智能”并非凭空产生，它来自一条从物理世界到决策输出的完整链路：传感器采集原始信号，经过时间同步与预处理形成规整张量，再送入深度学习模型完成检测、分割、跟踪等感知任务，最终由规划控制模块消费。异构算力推理调度工程的核心任务，就是让这条链路在有限算力、严格时延和功能安全约束下稳定运行。理解感知与推理的基础，是后续调度策略设计的前提。
一、传感器数据流：从物理信号到规整张量
典型 L2+ 以上自动驾驶车辆会同时搭载摄像头、激光雷达、毫米波雷达、超声波雷达和 IMU/GNSS。不同传感器的数据形态差异极大：摄像头输出 30fps 的 H.264/H.265 压缩流或 RAW Bayer 帧；激光雷达输出每秒数十万到数百万个三维点；毫米波雷达输出稀疏的目标级或点云级数据；IMU 则以 100～1000Hz 输出角速度和加速度。这些数据必须先经过解串、解码、去畸变、坐标变换和时间对齐，才能被模型使用。
数据流的关键难点在于“时间一致性”。摄像头曝光时刻、激光雷达扫描周期、雷达 chirp 时刻各不相同，若直接拼接会产生运动畸变。工程上通常以某一主时钟为基准，通过 PTP 或 gPTP 做硬件时间同步，再在软件层做插值对齐。下图展示了从传感器到推理输入的典型数据流与同步关系。
二、深度学习模型：感知任务与算力特征
自动驾驶感知模型大致分为几类：2D 图像检测与分割（如 YOLO 系列、Mask R-CNN）、3D 点云检测（如 PointPillars、CenterPoint）、BEV 融合模型（如 BEVFormer、BEVFusion）、以及占用栅格与端到端模型。不同模型的算力特征差异显著：卷积网络以密集矩阵乘为主，对 Tensor Core 友好；Transformer 类模型包含大量注意力计算，访存密集；点云模型则常含稀疏卷积和 scatter/gather 操作，对调度器不友好。
从调度视角看，模型可拆解为算子图（DAG），每个算子有明确的输入输出张量、计算量和内存占用。推理框架（TensorRT、ONNX Runtime、PyTorch）会将算子映射到 GPU、NPU 或 DSP 上执行。异构调度的本质，就是决定“哪个算子、在哪个设备、什么时刻、以什么优先级”执行。
# 典型感知模型算子构成（示意）
Backbone: Conv2d x N, BatchNorm, SiLU -> GPU Tensor Core
Neck: FPN, 上采样, 特征拼接 -> GPU / NPU
Head: Decode, NMS, TopK -> CPU / DSP
BEV: GridSample, Attention, Scatter -> GPU 访存密集
Tracker: Kalman, 匈牙利匹配 -> CPU 实时线程
三、实时性要求：时延、抖动与吞吐
自动驾驶对实时性的要求不是“平均快”，而是“最坏情况可预测”。感知链路通常有明确的端到端时延预算，例如高速场景下 100ms、城区场景下 150ms。更关键的是抖动（jitter）：如果某一帧因调度排队延迟了 80ms，即使平均时延只有 40ms，也可能导致控制模块使用过期感知结果，引发危险。
实时性指标通常包括：单帧端到端时延、P99 时延、帧率稳定性、任务释放抖动、以及截止期错过率。异构调度需要为高优先级任务预留算力，避免低优先级任务（如日志、OTA、可视化）抢占关键路径资源。
| 指标 | 含义 | 典型目标 | 调度关注点 |
|---|---|---|---|
| 端到端时延 | 从传感器曝光到感知输出 | ≤ 100ms | 关键路径优先级 |
| P99 时延 | 99% 帧不超过的时延 | ≤ 130ms | 尾延迟抑制 |
| 抖动 | 时延波动范围 | ≤ 20ms | 资源预留与隔离 |
| 帧率稳定性 | 实际帧率与目标帧率偏差 | ±5% | 周期任务节拍 |
| 截止期错过率 | 超时帧占比 | < 0.1% | 降级与抢占策略 |
四、功能安全与预期功能安全概念
功能安全（Functional Safety, FuSa）关注的是“系统故障导致的风险”，例如传感器失效、算力单元死机、通信丢包。ISO 26262 定义了 ASIL 等级（A 到 D），要求对随机硬件故障和系统性故障进行检测与响应。在推理调度中，FuSa 体现为：关键任务冗余执行、看门狗监控、算力单元健康检查、以及故障时的安全降级路径。
预期功能安全（Safety of the Intended Functionality, SOTIF）关注的是“系统没有故障，但功能本身在特定场景下表现不足”导致的风险，例如模型对逆光、雨雾、异形车辆识别失败。ISO 21448 要求通过场景分析、边界测试和运行监控来降低未知不安全场景。对调度工程而言，SOTIF 意味着需要支持模型置信度监控、多模型投票、以及动态切换更保守的推理策略。
FuSa 与 SOTIF 的调度差异：FuSa 偏向“故障可检测、可恢复”，调度上强调冗余、心跳、超时抢占；SOTIF 偏向“性能可监控、可降级”，调度上强调置信度评估、模型切换、算力弹性分配。两者共同决定了异构算力调度的安全边界。
工程提示：在异构平台上，建议将 FuSa 关键任务绑定到独立算力分区，并设置硬件看门狗；SOTIF 相关监控任务可作为低优先级常驻任务，但必须保证其采样周期不被关键推理任务长期饿死。
常见误区：把“平均时延达标”当作实时性达标。实际路测中，P99 时延和抖动往往才是触发接管的直接原因。另一个误区是只关注模型精度，忽略调度引入的排队延迟——同一模型在不同调度策略下，端到端时延可能相差 2 倍以上。
五、案例复盘：一次感知延迟引发的误刹车
某项目在城区测试中出现偶发误刹车。复盘发现：BEV 模型与 2D 检测模型共享 GPU，但 2D 检测任务未设置优先级，导致 BEV 推理被日志上传任务阻塞，单帧时延从 60ms 升至 140ms。控制模块使用了过期 140ms 的感知结果，与当前车辆位置偏差过大，触发误判。修复方案包括：为感知关键任务设置高优先级、限制日志任务算力配额、增加时延监控与超时降级。该案例说明，异构算力调度不是“跑得快”的问题，而是“跑得稳、可预测、可兜底”的系统工程。