2. NVIDIA DRIVE硬件平台认知
NVIDIA DRIVE不是一块单独的芯片，而是一套围绕车载计算模组构建的硬件平台。理解这套平台，是后续做功能测试、接口验证、环境试验和故障定位的前提。本节从计算模组、安全岛、MCU、传感器接口、电源与散热五个层面拆解硬件构成，并给出硬件测试中真正需要盯住的关注点。
一、计算模组：Orin与Xavier的定位差异
DRIVE平台的核心计算单元以模组形式交付，典型代表是Xavier和Orin两代。Xavier面向早期L2+量产方案，单颗AI算力约30 TOPS，采用12nm工艺，集成GPU、Carmel CPU集群、深度学习加速器和图像处理单元。Orin则面向更高等级自动驾驶，单颗算力约254 TOPS，采用7nm工艺，GPU架构更新，CPU为Hercules核心，并支持多颗Orin通过NVLink或PCIe组成更高算力域控。
从测试角度看，两代模组的差异直接影响测试项设计。Xavier平台功耗和散热余量较小，高温降频更容易触发；Orin算力高、接口丰富，但多芯片协同带来的时钟同步、内存带宽争用和跨芯片通信延迟成为新的验证重点。测试前必须确认被测件是单Orin、双Orin还是Xavier方案，因为算力分配、传感器接入数量和功能安全等级都会不同。
二、安全岛：功能安全的独立执行域
安全岛是DRIVE平台中独立于主AI计算域的安全执行单元，通常由锁步CPU核、独立时钟、独立电源域和专用SRAM组成。它的职责不是跑感知算法，而是在主域失效时接管车辆进入安全状态，例如执行最小风险策略、切断动力输出或维持转向制动的基本控制。
安全岛的关键测试点在于“独立性”。测试时需要验证：主域复位或断电时安全岛是否仍能正常工作；安全岛与主域之间的通信超时是否被正确检测；安全岛自身的看门狗、ECC和锁步比较逻辑是否能在注入故障后触发响应。常见做法是通过调试接口注入单比特翻转或强制主域挂起，观察安全岛是否在预定时间内输出安全动作。
三、MCU：实时控制与车辆接口的桥梁
DRIVE平台通常外挂一颗车规级MCU，负责实时性要求高、安全等级要求明确的任务，如车辆CAN通信、电源管理、上下电时序控制和诊断服务。MCU与Orin之间通过SPI、CAN或以太网交互，形成“AI域决策、MCU域执行”的分工。
硬件测试中，MCU相关关注点包括：上下电时序是否符合整车要求，例如KL30上电后MCU先启动、再释放Orin复位；CAN/FlexRay通信在总线负载高时是否丢帧；MCU与Orin之间的心跳和握手信号在异常时能否被双方正确识别。这些测试往往需要配合电源可编程设备和总线仿真工具完成。
四、传感器接口：多类型、高带宽、强同步
DRIVE平台的传感器接口种类多，典型包括：GMSL2/3用于摄像头，支持同轴供电和高速视频回传；CAN/CAN FD用于雷达和车辆信号；以太网（100BASE-T1/1000BASE-T1）用于激光雷达和高带宽传感器；PPS和gPTP用于多传感器时间同步。
接口测试不能只看“通不通”，而要关注链路质量和同步精度。摄像头链路要测误码率、链路训练状态和温度循环后的稳定性；以太网要测丢包率、延迟和TSN特性；时间同步要测PPS抖动和gPTP主从偏差。一个常见的教学示例是：用示波器同时抓取摄像头PPS和激光雷达PPS，若两者边沿偏差超过1 ms，则说明同步链路存在配置或硬件问题，需要检查gPTP域和线束长度。
五、电源与散热：稳定运行的边界条件
Orin和Xavier对供电质量敏感。典型供电包括12V/24V整车输入、多路DCDC输出（如0.8V核心、1.8V IO、3.3V外设），以及上电时序控制。电源测试要覆盖：输入电压范围（如9V~16V）、冷启动跌落、抛负载、反接保护，以及各路电源的上电顺序和纹波。
散热方面，Orin模组功耗可达数十瓦，必须依赖散热器、导热垫或液冷。测试关注点包括：结温是否超过规格、风扇或液冷失效时降频策略是否生效、高温环境下AI算力是否稳定。实际测试中常用热成像仪和模组内部温度传感器交叉验证，若发现某区域温度明显偏高，需检查导热垫贴合和风道设计。
六、硬件测试关注点的组织方式
把上述五个层面放在一起，硬件测试可以按“供电—启动—通信—感知—算力—安全”的顺序组织。上电后先确认各路电源时序和纹波正常，再检查MCU与Orin的启动握手；随后验证传感器链路是否全部枚举成功、时间同步是否收敛；接着加载典型感知负载，观察算力占用和温度变化；最后注入主域故障，确认安全岛能在规定时间内接管。
一个可参考的测试记录表应至少包含以下字段：测试项、被测对象、输入条件、观察量、判定阈值、实测值、结论。例如“摄像头GMSL链路误码率”一项，输入条件可设为常温25℃、链路长度3米、连续运行2小时，观察量为误码率，判定阈值可设为小于1E-12，实测值记录具体数值，结论为通过或不通过。这样的记录方式能让测试结果可追溯、可复现，也便于后续问题定位。
硬件平台认知的最终目的，是让测试人员看到一块域控板时，能快速判断它的计算能力边界、安全机制、接口类型和热设计约束，从而设计出有针对性的测试方案，而不是停留在“上电、跑通、看结果”的粗放验证层面。