#技术巡猎# #零跑#测试一台辅助驾驶车，遇到一个不太正常的动作，驾驶者接管以后说“刚才这里有问题”，工程师回去到底该先看哪一份记录？道路录像里能看到外面发生了什么，总线上有转向和制动，控制器也有自己的数据，看起来什么都录下来了，但如果几份记录的时间对不上，接下来可能先要花不少工夫，确认大家说的是不是同一刻。

零跑这份数据采集专利考虑的，就是让这些东西从一开始就按同一个时间基准记录。这个事情看着没有新功能那么热闹，但是你真要把测试中发现的问题交回研发，单有一段“不舒服”的视频是不够的，总得能继续找到当时的指令、状态和响应，研发才知道该从哪里查起。

先看几路数据为什么不好直接放在一起。CAN总线上会有制动、转向和其他控制器的信息，以太网可以接入辅助驾驶、座舱等域控制器，视频又有自己的采集和编码过程。它们从车上出来，经过的设备和传输过程都不同，你在电脑上先收到哪个文件或数据包，不一定意味着那件事先发生。如果把到达电脑的先后顺序当成车辆动作的先后，就可能连排查方向都找错。

所以方案把同步控制放到了采集前面。上位机的同步控制模块提供全局统一时间戳，并发出同步触发信号，让总线、网络和视频采集器按共同控制开始或停止记录。原文提到了GNSS时间、PTP精确时间协议等同步方式，各路数据采集时就带上时间信息，后面再怎么传输、解析，都有一个可以回去对照的基准。

这里也不用要求视频帧率和CAN报文频率完全一样。两路数据各自按需要采集，只要它们的时间标记能够在同一条时间轴上解释，回看某一刻，就能找到前后相邻的画面和消息。同步启动解决一起开始的问题，数据自己的时间戳则继续交代后面每一段记录发生在什么时候，这两个安排要一起起作用。

数据进入上位机以后，解析模块把不同格式读出来，保留原有时间关系，存储模块再以统一时间戳为索引，按通道对齐保存。原来分开找录像、翻总线、看网络记录的事情，现在可以围绕一个具体时刻展开。比如想查一次制动，先定位这次事件，再往前看请求何时出现、画面里有什么变化，往后看执行端的反馈，数据的组织方式就跟着工程师查问题的动作走了。

它还专门安排了两台摄像头，一台拍真实道路，一台拍车机屏幕上的虚拟世界。这个安排挺有意思，因为测试者当时看到的显示，也是使用体验的一部分。外面有一辆车，屏幕上怎样呈现，车辆后来做了什么，可以放在同一段时间里对照。假如测试者说自己看到的提示和车辆动作不一致，回去就能把当时的画面调出来，不必只靠记忆描述。

屏幕所呈现的当然只是人能看到的部分，内部感知与控制发生了什么，还要继续联系控制器记录。所以两路视频和车载通信是一起工作的，画面帮助找到具体情境，系统数据则让排查能够继续往里走。比如已经记录到制动请求，却迟迟没有对应反馈，就可以进一步检查请求到执行之间的过程；如果驾驶者的操作在先，也要把人的介入放回这段过程里。先后顺序有了，具体原因再结合信号含义和复测来确认。

测试时还有一个常见的麻烦，开出去很久，真正需要回看的可能只是其中几秒，回来再凭印象翻，未必记得清楚。方案因此提供了语音和界面指令，可以开始、暂停、恢复、停止采集，也可以在发生问题时插入事件标记、切换测试场景。标记同样关联统一时间基准，现场觉得有问题，就先留下位置，回去直接从这里找。车内噪声大、语音不方便时，界面也能完成相应操作。

这部分人的参与我觉得是有必要的。测试者对一次顿挫、一次迟疑的感受，不见得马上就能对应到某个明确故障码，但他可以先留下当时的感受和位置，工程师再沿着记录检查系统状态。现场还说不清原因也没关系，先找到那几秒发生了什么，后面的调查才有具体对象。

车跑了多少测试里程，大家很容易看到数字；跑完以后，发现的问题能不能被研发继续追查，就藏在这些采集和记录的细节里。把同一次经历按时间放回一起，现场的一句“刚才这里不对”，才更有机会变成工程师能够复现、修改，再回到车上验证的具体问题。