2. NVIDIA DRIVE 软硬件栈与验证接口

在 NVIDIA DRIVE 的 SIL/HIL 联合验证中，最容易出错的地方不是算法本身，而是“软件栈的哪一层被替换成了仿真模型、哪一层仍然跑在真实硬件上”。如果这个映射关系不清楚，就会出现 SIL 里通过、HIL 里失败，或者 HIL 里通过、实车表现异常的典型问题。本节把 DRIVE 的软硬件栈拆成可验证的层次，并说明每一层在 SIL 与 HIL 中分别由什么承载、接口在哪里被截断或注入。

一、软硬件栈的分层与验证边界

从下往上，NVIDIA DRIVE 的栈大致分为：硬件平台（Orin/ Xavier SoC、MCU、传感器、车载网络）、DriveOS（含 QNX/Linux 内核、Hypervisor、驱动、NvStreams、NvSci 等中间件）、DriveWorks（感知、标定、地图、DNN 框架封装）、CUDA/TensorRT（计算与推理运行时）、传感器抽象层（SAL，Sensor Abstraction Layer）、以及应用层（规划控制、功能安全监控）。

验证接口的本质，是决定“在哪一层切断真实信号、接入仿真信号”。SIL 通常在 x86 主机上运行，把 DriveOS 驱动以下的部分全部替换为仿真模型；HIL 则保留真实 SoC 与 DriveOS，只把传感器、CAN、以太网、PCIe 等物理接口替换为硬件在环设备。因此，同一份应用代码在 SIL 与 HIL 中的差异，集中体现在 SAL 以下、驱动以上的接口层。

二、DriveOS 与 DriveWorks 在两种环境中的差异

DriveOS 是运行在 SoC 上的实时操作系统集合，包含 Hypervisor、QNX/Linux 内核、NvSci 通信中间件、NvStreams 数据流框架以及各类外设驱动。在 HIL 中，DriveOS 完整运行，验证的是真实调度、真实中断延迟和真实驱动行为；在 SIL 中，DriveOS 通常被替换为一组仿真桩（stub），只保留应用所需的 API 语义，例如 NvSci 的缓冲区同步被替换为共享内存加信号量。

DriveWorks 位于 DriveOS 之上，提供感知、标定、地图和 DNN 推理的封装。它在 SIL 与 HIL 中的差异主要是编译目标：SIL 使用 x86 版本，HIL 使用 ARM 版本。需要注意的是，DriveWorks 内部对 CUDA 和 TensorRT 的调用路径在两种环境下必须保持一致，否则会出现“SIL 精度正常、HIL 精度下降”的问题。常见原因是 SIL 使用了 FP32 推理，而 HIL 的 TensorRT 引擎默认启用了 FP16 或 INT8。

三、CUDA 与 TensorRT 的映射要点

CUDA 在 SIL 中运行于主机 GPU，在 HIL 中运行于 SoC 的 GPU。两者算力不同，因此不能简单用 SIL 的帧率推断 HIL 的实时性。TensorRT 的映射更关键：引擎文件（.plan）与 GPU 架构绑定，SIL 上生成的引擎不能直接部署到 HIL 的 SoC 上，必须在目标平台上重新构建或使用兼容的构建配置。

一个可操作的检查方法是：在 SIL 与 HIL 中分别打印 TensorRT 引擎的绑定信息，包括输入尺寸、精度模式、最大批量（batch size）和 GPU 架构标识。如果 SIL 使用 --fp32 而 HIL 使用 --fp16，则需要在 SIL 中同步切换精度模式，否则感知输出的置信度分布会出现系统性偏移。

# 在 SIL 与 HIL 中分别执行，对比引擎绑定信息
trtexec --loadEngine=perception.plan --dumpProfile --verbose 2>&1 | grep -E "Binding|Precision|Batch"

# 示例输出（SIL，x86 + FP32）
# Binding: input_0, dims: [1,3,640,640], precision: FP32
# Binding: output_0, dims: [1,80,80,85], precision: FP32

# 示例输出（HIL，Orin + FP16）
# Binding: input_0, dims: [1,3,640,640], precision: FP16
# Binding: output_0, dims: [1,80,80,85], precision: FP16

当两者精度模式不一致时，建议在 SIL 中增加一组 FP16 的回归用例，观察 mAP 或检测框坐标的偏差是否超过阈值。若偏差超过 2%，则需要在 HIL 中改用 FP32 引擎，或对 FP16 引擎做量化感知训练后的校准。

四、传感器抽象层 SAL 的接口映射

SAL 是 SIL 与 HIL 之间最关键的“接缝”。它把相机、雷达、激光雷达、IMU、GNSS 等传感器的原始数据统一为带时间戳的缓冲区。在 SIL 中，SAL 的后端是仿真数据源，可以是离线回放（rosbag、ADTF 记录）或实时生成（CARLA、Prescan 等）；在 HIL 中，SAL 的后端是真实驱动，但数据来源被切换为 FPGA 或实时仿真机注入的物理信号。

映射时最容易忽略的是时间戳来源。SIL 中时间戳通常来自仿真时钟，HIL 中来自 SoC 的硬件时钟或 PTP 同步时钟。如果两者不一致，融合算法会出现“数据错位”。建议在 SAL 层统一使用一个可配置的时间源接口，并在 SIL 与 HIL 中分别记录时间戳偏差，偏差超过 5 ms 时触发告警。

五、CAN、以太网、PCIe 的接口映射

CAN 在 SIL 中通常由虚拟 CAN 通道（如 SocketCAN 的 vcan）承载，在 HIL 中由真实 CAN 板卡（如 Vector VN 系列、Kvaser）承载。映射的关键是 DBC 文件必须一致，且信号周期、超时和校验和（checksum）算法要在两种环境中保持相同。如果 SIL 中忽略了 checksum 校验，HIL 中就会因为校验失败而丢弃报文。

以太网在 SIL 中通常使用 UDP 回环或共享内存模拟，在 HIL 中则使用真实 TSN 交换机或直连网口。需要关注的是 VLAN 标签、PTP 时间同步和 QoS 优先级。PCIe 在 SIL 中一般不存在，因为 SIL 不涉及真实板卡；在 HIL 中，PCIe 用于连接 FPGA 加速卡或数据采集卡，映射时需要确认 BAR 空间、DMA 通道和中断号在驱动中正确配置。

六、映射关系的验证闭环

要确认映射正确，不能只看 SIL 或 HIL 单侧结果，而要做“同输入、双环境、比输出”的对照。具体做法是：选取一段固定场景数据（例如 30 秒的城市道路回放），在 SIL 中运行并记录感知输出、CAN 报文和以太网数据；然后在 HIL 中用同一段数据通过注入通道回放，记录相同信号。对比两者的时间戳偏差、检测框坐标偏差和报文内容差异。

判断依据可以量化为：时间戳偏差小于 5 ms、检测框坐标偏差小于 3 像素、CAN 报文内容完全一致。若某项超差，则回到对应的栈层排查：时间戳问题查 SAL 时间源，坐标问题查 TensorRT 精度模式，报文问题查 DBC 和 checksum。通过这种分层定位，才能把 SIL/HIL 联合验证从“跑通”推进到“可信”。