1. 课程导入与工程全景
汽车雷达从“能测距”走到“能上车”，中间隔着的不是算法公式，而是一整套可复现、可追溯、可回归的验证工程。TI Jacinto 系列 SoC（如 TDA4VM / TDA4VH）在雷达与感知域控制器中承担传感器接入、信号处理、融合与通信调度等任务，而 HIL（Hardware-in-the-Loop，硬件在环）与场景验证，正是把“实验室里的雷达”变成“量产车上的雷达”的关键环节。本课程的目标，是让学习者建立一条从需求到证据的完整工程链路认知：知道被测对象是什么、激励从哪来、数据怎么流、结果如何判、问题如何定位。
一、先厘清三个核心概念
被测件（DUT）：在雷达 HIL 中，DUT 通常不是单颗雷达芯片，而是“雷达前端 + Jacinto 域控制器 + 运行其上的雷达信号处理与目标输出软件”的组合体。它对外表现为若干接口：CAN/CAN-FD 或以太网输出目标列表、诊断口、调试串口、时间同步接口等。明确 DUT 的边界，决定了后续激励注入点和观测点在哪里。
HIL 与场景验证的分工：HIL 解决的是“真实硬件在受控电气与信号环境下运行”的问题，强调实时性、接口电气一致性和闭环；场景验证解决的是“在什么交通情境下考核它”的问题，强调场景覆盖度、参数化和可重复。二者不是并列关系，而是“平台 + 用例”的关系：HIL 提供可注入、可采集、可回放的实时底座，场景库在其上运行。
雷达目标模拟：与摄像头 HIL 注入图像不同，雷达 HIL 的核心激励是“回波”。工程上常用毫米波雷达目标模拟器（RTS）在射频端注入带距离、速度、角度、RCS 信息的回波信号；也可在信号处理链的中间层做数字注入。前者更接近真实，后者更易做大规模参数扫描。理解这一区别，是后续选择验证策略的基础。
二、整体框架：从场景到证据的四层结构
把课程内容压缩成一张可长期回看的工程全景图，比记住零散步骤更有价值。下图以“场景层—实时层—被测层—判据层”四层结构，标出关键对象、接口与数据流向，其中实线表示实时信号/数据通路，虚线表示配置与观测通路。
三、典型开发流程：一条可执行的闭环
工程上更常见的做法不是“先搭台再想用例”，而是从需求侧反推。一个可落地的流程通常包含以下环节，且每个环节都有明确的输入与输出物：
- 需求与接口冻结：确定 DUT 版本、软件基线、对外接口定义（报文 ID、信号名、周期、单位、量纲）。例如目标列表经 CAN-FD 以 20 ms 周期发送，字段包含
Obj_ID、DistX（m）、VelX（m/s）、Azimuth（deg）。 - 场景建模与参数化：把“前车切出”这类描述转成可执行参数，如本车 80 km/h、前车 60 km/h、横向偏移从 0 m 线性变化到 3.5 m、持续 4 s。参数化程度决定了回归集能否批量扩展。
- HIL 平台配置：配置实时模型步长（常见 1 ms）、RTS 通道与天线耦合方式、总线数据库（DBC/ARXML）、时间同步源（PTP 或 GPS 秒脉冲）。
- 用例执行与数据采集：同步采集总线目标输出、DUT 内部日志、RTS 注入真值。三者时间戳必须统一到同一时基，否则后续比对无意义。
- 判据比对与归因：按容差判定，例如距离误差 ≤ 0.5 m、速度误差 ≤ 0.3 m/s、角度误差 ≤ 1°；超差则回溯到信号链定位是射频注入、处理算法还是通信输出环节的问题。
- 回归与版本固化：把通过用例纳入回归集，软件每次迭代自动跑一遍，形成可追溯的验证证据链。
四、学习本课程应建立的三种能力
第一是接口思维：任何验证问题最终都要落到“激励从哪个接口进、观测从哪个接口出”。第二是时间思维：雷达是强时序系统，注入、处理、输出之间存在确定或不确定的延迟，验证必须处理时基对齐与延迟补偿。第三是证据思维：一次通过不等于可靠，只有可重复、可追溯、带判据的用例集合，才能支撑功能安全与量产放行。