ADAS 测试也是 HIL 测试的一种，我们先来看看 ADAS 系统的构成，然后再分析一下如何制定测试方案。（跳动的代码是我的公众号）

1、摄像头有带处理器的，可以先预处理一下，然后把处理后的信息发给 ADAS 控制器，也有不带处理器的，把采集到的原始信号全部发给 ADAS 控制器。它们的区别，大致就相当于数字传感器和模拟传感器的区别，谁优谁劣不好说，但是总体而言，带处理能力的摄像头，会减轻 ADAS 算法的代码量，因为它会承担一部分处理任务，这就是一个分工的事情（但是，如何分工，分多少，行业内没有标准）。如果摄像头处理得比较少或者几乎不处理，可以采用 LVDS 编码传输信息（传输速度高），如果摄像头处理得多一些，可以采用以太网传输处理后的信息，如果摄像头内部的处理器干了相当大比例的活，甚至可以使用 CAN，把处理后的信息传递给 ADAS 控制器。

2 闭环测试我们用 HIL 测试的基本原理来剖析一下上面那个 “ADAS 系统基本构成图”。ADAS 控制器发出的 “转向、加减速” 等信息，按道理，如果想测得比较逼真，是需要一个场景模型的，这个 “场景模型” 可以通过 “积分” 等算法，知晓车辆在场景里的位置，而我们能够在场景显示界面里看到车的动画效果，栩栩如生，这就叫 “闭环测试”。但是，这种情况下，摄像头、雷达的信息，是不可能再通过 “回放” 的方式去输入给 ADAS 控制器了，因为所谓 “闭环”，它的本质意义就是，“第二类整车模型” 的处理结果，要反馈输入给被测对象，而这个 “处理结果”，当然包括车辆所处的 “场景视野”、“摄像头信息”，此种情况下，摄像头信息只能来自这个闭环的 “场景模型”，这个 “场景模型”，一般就是指 CarMaker、PreScan 一类软件。

场景软件的场景，一般都是怎么送给 ADAS 系统的呢？看一下下面这个图：

这就是一些厂家做的 ADAS 测试方案，叫 “摄像头在环”，其 “虚实结合” 的切割方法如下图所示（→→HIL27 讲，零基础教程，从根本原理上探讨 HIL 的切割方法，师子一号一直搞不懂为什么叫这么名字，不就是形成了一个闭环吗？这样的闭环场景模型，也几乎没有人工控制的接口了）：

他们把 CarMaker 的场景动画播放在了一个屏幕上，然后用摄像头去拍摄这个屏幕，假装自己就在乡野公路上快乐地驰骋，路上根本没有其他车，或者虽然有，但是很少而且都特别规矩。

我们先不去评价这种场景软件（场景软件=场景模型，朋友们后续可以这么理解）生成的场景是否实用、能否足够深度地考察 ADAS 控制器，单就这个投影屏幕而言，它对场景模型生成的场景的还原度，是值得商榷的。比如，它只能使用摄像头，雷达什么的就别想了，你用雷达对着投影幕布，测出来的是到屏幕的距离，而绝非到屏幕中 “前车” 的距离。

受限于显示技术，如果场景软件中，对面会车来了一辆开着远光灯的宝马，那这个屏幕也是几乎不可能仿得出来的。此外，显示器毕竟也是一个物体，即使 “场景” 非常理想，光照适中、没有太亮和太暗的部分、天气晴朗、车况简单，那么，你用摄像头拍出来的，也是像蒙上了一层东西。“这层东西” 当然需要在 ADAS 算法中把它处理掉，然后在实车上，是不存在 “这层东西” 的，理论和实际脱节了一丢丢哦（当然，可能也有那种非常专业的显示设备，人眼根本看不出来是屏幕还是真实世界，师子小分队的成员们都没用见到过，不好评论）……

后来，随着技术的进步，摄像头也变得强大了，内部又可以划分为摄像头和摄像头 ECU 了（前面我们说的带处理能力的摄像头，指的就是这个 “摄像头 ECU” 处理的），如果能跳过这个效果不太好的投影屏拍摄环节，直接把场景软件生成的图像图像数据（雷达数据也类似）发给摄像头 ECU，不是更好吗？

这个是可行的，因为摄像头这个环节，是标准化的，它向摄像头 ECU 发送信息，无论是协议数据格式还是插件接口类型，都是标准化的，所以场景软件完全可以直接造出这种数据格式，直接送给摄像头 ECU，这种情况下的 HIL 测试系统，切割点又变化了。如上图所示，是从摄像头内部的连接线处进行切割，被有些公司成为 “摄像头 ECU 在环”（搞不懂这名字到底是怎么起的）。

如果我们想更进一步，把摄像头 ECU 也跳过，直接按照摄像头 ECU 和 ADAS 控制器之间的交互协议，通过场景软件把信息发给 ADAS 控制器，可以吗？这个要看情况，如果摄像头 ECU 没有做逻辑算法处理，直接把原始数据编码成 LVDS 或者以太网信号，那是可以的，比如我们用 LVDS 板卡，把场景生成的信息流转换成 ADAS 控制器可以接收的类型，就可以了。但是，如果摄像头 ECU 承担了一定的处理任务，就很难再跳过摄像头 ECU 了，因为多数情况下，你并不知道它承担了多少，干了哪些活，除非摄像头 ECU 也是场景软件商家提供的，或者等有一天，摄像头 ECU 干的活也标准化了，才可能行。当我们把摄像头跳过去之后，“拍摄屏幕” 所导致的弊端，也就不存在了，这个时候，这个方案的优劣，就取决于场景模型的质量了。其实这个也没太多可说的，场景模型的图像，非常理想化，有可能无法检查出潜在的功能缺陷，而且可能难以适应中国复杂的国情和路况，所以，这种测试方法，像有些朋友们说的那样，适合实验室理论研究，以及工程上的粗略初步测试，不能直接上车。

我们发现个问题哈，摄像头被跳过了，但是如果摄像头出问题了咋办？这个也好办，把摄像头拎出来单独测试就好了，很多企业就是这么干的，只测摄像头，环节也少，效果也直观，就像师子一号在之前介绍 BMS 的 HIL 测试那样，有些企业，会单独把采集器拎出来做 HIL 测试。

2.2 开环测试

开环测试并不像它的名字给人的感觉那么低级，相反，在 HIL 测试领域，因为开环测试具有极大的灵活性，并且对设备的要求相对较低，所以它算是一种更高级更高效的做法，对工程师的要求更高。

关于开环测试，我们可以用 VCU 的 HIL 测试来做个比方，如下图所示，这是个闭环的：

车辆模型根据 VCU 发出来的 “扭矩需求值”，通过各种计算公式，得出车速，把车速再反馈给 VCU。VCU 根据车速和踏板深度，查表得出 “扭矩需求值”，又发给车辆模型。其中 “踏板深度” 是个软件控件，由测试员操作，测试员在软件界面上 “踩下” 一定深度，可以非常直观地看到车速的变化，这，就是闭环 HIL 测试。

但是这种 “闭环”，师子一号并不推崇，因为它除了好看、直观之外，对 VCU 测试而言并没有太大帮助，如果要检测 VCU 的功能，我们只需要看 “扭矩需求值=f（踏板深度，车速）” 的对应关系是否准确成立就可以了，开环测试完全可以搞定，而且覆盖率更高。所谓开环测试，我们还用上图为例，车速就不是整车模型反馈回来的了，而是我们人为制造出来的，比如上图中，我们把踏板深度设置为 80%（很深了），把车速设置为 20kmph，这个时候，我们用纸笔算一下，扭矩需求值大概是 150Nm，所以 VCU 输出的期望值，就是 150Nm。这个时候，如果我们不修改车速值和踏板深度，VCU 输出的一直是 150Nm，给人的感觉不够逼真，油门踩了那么深了，车速就是上不去，但是，这没关系，对验证 VCU 的功能而言，已经够了（除非 VCU 具有车速异常侦测功能，比如踩下踏板，车速上不去，会报错，这个时候，你就必须通过模型或者通过自动化测试工具，给它创造一个合情合理的车速哈~）。

开环测试怎么应用到 ADAS 测试里面呢？

首先，场景模型就不要想了，不存在的。

开环测试的设备要求很简单，方法很灵活，一般都是把实车上摄像头、雷达发给 ADAS 信号同步录制下来，它们之间用什么协议传输，你就要用什么协议的设备录制下来，比如用的是 LVDS 协议的话，可以采用德国 GOEPEL 公司的专用设备，然后拿到实验室回放，在同一时间坐标下，比对 ADAS 输出的 “油门”、“刹车”、“转向” 等信号就可以了，当然，也可以比对更多的信号，这样会更详细精确一些。最理想的情况，当然是 ADAS 输出的信号，和一个经验丰富的老司机开出来的信号完全一样咯~

开环测试存在的累积误差，比如我们通过 ADAS 输出的 “油门”、“刹车”、“转向” 等信息，发现积分积出来的轨迹，和车辆的实际轨迹有明显出入，但是这一般是不会有什么问题的，因为 ADAS 系统会根据误差之后的 “场景” 进行微调的，矫正回来，一般不会像轨迹积分展示的那样，开到沟里去的。

在开环测试的实车数据录制中，还有一些企业会把摄像头发给摄像头 ECU 的信号录制下来，这相当于录制的视频，然后回到实验室之后，再把视频回放给摄像头 ECU，验证 “摄像头 ECU+ADAS 控制器” 的整体表现。

03

开环测试和闭环测试对比

闭环测试采用场景软件，拥有更加丰富的场景库，可以信手拈来，很方便，但是这些场景多数都是老外开发的，并不适合中国国情，而且场景软件的路况非常理想，对 ADAS 系统的考验很有限，所以，它们更适合做理论研究，或者企业中进行初步粗测。开环测试采用的是实车数据，可靠性自然不在话下。开环测试的麻烦点在于，1，可能会有有较多的信号需要比对标注，工作量较大，比较灵活；2，录制不易，合适的场景不一定能录得到。关于第一个问题，业内目前普遍在探索自动化核对方法，对于第二个，则借助大数据，有望能获取更多合适的录制场景，比如借助英伟达公司建设的场景数据库，则可以在算法还未开发好的情况下，就准备提前准备好测试 case。

有对车路协调无人驾驶测试感兴趣的可以一起学习探讨，也希望有志同道合的人一起加入