台架测试搞了这么多年，说实话，最烦的不是测试用例设计，而是那堆线束。尤其新能源整车台架，BMS、VCU、MCU、OBC一大圈控制器围着你转，CAN报文要监控、要记录、还要模拟节点发报文，传统做法就是拉一根USB转CAN线到电脑边上，人坐在台架旁边盯着，线缆绕来绕去，调试设备移动一点都不自由。之前有个项目，为了采集一段恶劣工况下的BMS数据，人得蹲在台架边上好几个小时，连口水都不敢多喝，就怕错过关键报文。
后来我们引入了CAN转WiFi无线模块，对整个台架测试环境做了改造，把原来有线CAN的束缚彻底解掉了，这套方案在多个新能源整车台架模拟测试项目里跑了一年多，稳定性和实用性都经过了验证。今天把整个改造过程、选型思路、踩过的坑、还有实测数据全部整理出来，给正在琢磨怎么把台架测试无线化的同行一个参考。
1. 为什么台架测试要动CAN转WiFi的念头
1.1 传统有线测试方案的三个别扭之处
先说痛点。新能源整车台架测试和传统燃油车台架有个巨大区别——高压系统和低压通讯系统交织在一起，控制器数量多、分布散，而且测试过程中台架是要动的。虽然不像道路试验那样满世界跑，但台架上的转向、油门、负载模拟器都会有物理位移。
之前用有线CAN方案，遇到三个实际麻烦：
- 布线痛苦：整车级别的台架，控制器分布在机舱、地板、仪表台各个位置，CAN线要跟着线束走，一根线断掉排查起来能折腾半天。有次BMS报文突然丢失，排查到最后发现是CAN线被台架运动机构压破皮了，对地短路。
- 调试距离受限：USB转CAN线的线长本身就有限制，超过5米信号质量就下降得厉害。但台架上的高压配电柜、负载模拟器一开，测试人员最好离远点，这个矛盾一直存在。
- 多节点同时监控不方便：如果两个人同时要看数据，一个看VCU报文，一个看BMS报文，有线的方案只能一台电脑接总线，要么轮流看，要么再拉一台电脑并联进总线。每次并接都要重新剥线、压端子，麻烦不说，接多了总线负载也上来。
1.2 无线化改造的出发点
所以当时我们定的改造目标很明确：把CAN报文采集端做成无线的，测试人员拿着平板或者笔记本，在台架附近任意位置都能实时看数据、记录数据、甚至发送模拟报文。
这里要说明一下，我们不是要把整个CAN总线替换成WiFi，那也不可能，CAN总线在车规级可靠性上仍然是不可替代的。我们做的只是把“人-CAN设备交互”这一段变成无线，让测试人员从线束里解放出来。相当于给台架装了一个无线探针，探针一头挂在CAN总线上，另一头通过WiFi和上位机通信。
为什么选WiFi而不是蓝牙或者别的无线方案？主要看三点：
- 带宽：整车台架测试的CAN报文流量不低，尤其CAN FD总线，单通道速率能到5Mbps，蓝牙的带宽根本扛不住长时间大数据量记录。
- 距离和穿透性：台架现场有台架本身、高压线束、金属屏蔽网，蓝牙的穿墙能力弱，WiFi在空旷环境下的覆盖能力更好。
- 上位机生态：现有的CAN分析软件、标定工具大部分都支持TCP/IP或者UDP协议，WiFi模块可以很容易地对接这些现有工具，不需要重写上位机软件。
1.3 改造的边界和风险评估
做这个改造之前，我们也仔细评估过风险，先说结论：在台架模拟测试这个场景下，CAN转WiFi方案的风险是可控的。
最大的担忧是无线通信的实时性和丢包率。整车台架和道路测试不一样，它是个相对封闭的环境，WiFi信号干扰源可控，不像在实验室里一堆无线路由器互相打架。而且我们测试的应用场景分两类：
- 监控和记录类：这类场景允许少量延迟和偶发丢包，关键是长时间不中断。
- 模拟节点发送类：这类场景对实时性有一定要求，需要评估延迟是否在可控范围。
我个人的原则是：如果台架在做的是安全相关的极限工况测试，比如电池热失控保护、碰撞断电这类，无线方案只做数据监控，不做控制指令下发，控制类操作仍然保留有线CAN通道。这是底线，不能破。
2. CAN转WiFi模块的核心工作原理
2.1 模块的基本架构
CAN转WiFi模块这个东西，本质上就是一个嵌入式网关，它内部做的事情分三层：
- CAN接口层：负责和整车CAN总线物理连接，收发CAN报文。这层核心器件是CAN收发器，负责把CAN总线的差分信号转换成芯片能处理的电平信号。我们用的模块CAN收发器是TJA1044，支持CAN FD，最高速率跑过8Mbps的数据段没出过问题。
- 协议转换层：这是核心，MCU把收到的CAN报文转换成自定义的UDP/TCP数据包格式，通过WiFi发送给上位机。反过来，上位机下发的控制指令，也是在这一层解析后封装成CAN报文发到总线上。
- WiFi通信层：负责和上位机建立无线连接。大部分模块工作在AP模式（模块自己开热点）或者STA模式（模块连接已有的路由器）。
2.2 数据帧格式设计
说实话，市面上很多CAN转WiFi模块自带的协议挺难用的，帧格式封闭，上位机对接费劲。后来我们自己基于模块做了一层协议封装，自定义了一套轻量级数据帧格式，效果比原厂协议好很多。
我们的帧格式大概是这样的：
| 帧头 | 功能码 | 通道号 | 报文ID | 数据长度 | 数据域 | 时间戳 | 校验 | | 2字节 | 1字节 | 1字节 | 4字节 | 1字节 | 最多64字节 | 8字节 | 2字节 |帧头固定为0xAA 0x55，用来做字节对齐和帧同步。时间戳用模块内部RTC，单位微秒，用来做报文到达顺序的精确还原。校验用CRC16，低层WiFi传输虽然本身有校验，但加上一层应用层校验心里更踏实，防止WiFi传输过程中出现坏帧被误解析。
2.3 为什么要关心CAN时钟误差和重同步
这里想多说一句，因为看到很多人在搜CAN时钟误差、CAN重同步这种词，这和CAN转WiFi模块的搭配使用有直接关系。
CAN总线的通信质量，很大程度上取决于总线节点的时钟精度。CAN协议本身有强大的错误检测机制，但CAN收发器和控制器里的时钟如果偏差太大，通信就会出错。CAN协议规范允许的最大位时间误差是±0.5%（采样点设在80%位置时），如果超过这个值，节点就会不断报错，严重时直接进Bus Off状态。
WiFi模块挂在CAN总线上，等于在总线上增加了一个节点。如果这个节点的主控芯片用的是劣质晶振，时钟漂移大，它就会拖累整个总线的通信质量。我们遇到过的情况是：模块不接的时候总线一切正常，挂上模块之后总线偶发错误帧，查了半天发现是模块用的晶振精度太差，常温下就偏差了0.8%以上，远远超出CAN协议允许范围。
后来我们统一要求模块厂商换成了温补晶振（TCXO），问题就消失了。所以选CAN转WiFi模块，一定要问清楚晶振规格，车载级至少要有±30ppm以内的精度，不然上了车台架分分钟出问题。
2.4 和WiFi握手协议的配合
CAN重同步机制也值得说一下。CAN总线的重同步是硬件层面的，当节点检测到总线上的边沿和本地时间基准有偏差时，会通过同步段调整采样点位置，这个过程对软件是透明的。但WiFi链路的延迟和抖动会叠加到这个交互过程里。
举个例子，模拟节点模式下，上位机通过WiFi下发一条报文，这条报文到达模块再转发到CAN总线上，经过的路径是：上位机 -> WiFi AP -> 模块WiFi芯片 -> MCU解析 -> CAN控制器 -> CAN收发器 -> 总线。每个环节都有延迟，WiFi环境波动时，延迟抖动可能从几毫秒跳到几十毫秒。
如果测试场景需要模拟周期性报文，比如每10ms发送一条发动机转速报文，WiFi延迟抖动会导致实际报文的发送间隔变成8ms、12ms、15ms这样不稳定。对于台架测试来说，这种抖动对一般监控来说无所谓，但如果你要做的是闭环标定或者HIL测试，就要特别注意，这类场景我还是建议走有线CAN。
3. 台架改造的完整实操步骤
3.1 硬件选型和装配要点
先说我们最终选用的硬件配置，给大家一个参考：
| 部件 | 选型 | 说明 |
|---|---|---|
| CAN转WiFi模块 | 某国产工业级模块，支持CAN FD | 双通道CAN，内置TCXO晶振，供电9-36V |
| 天线 | 5dBi外置胶棒天线 | 吸盘底座，可固定在台架金属框架上 |
| 供电 | 从台架12V直流取电 | 加了自恢复保险丝和TVS管防护 |
| 上位机 | 笔记本+平板 | 平板用于移动监控，笔记本用于数据记录分析 |
| 无线路由器 | 工业级双频路由器 | 5GHz频段用于数据，2.4GHz用于配置调试 |
这里有个细节，模块的天线尽量别贴着CAN总线线束走，WiFi天线对干扰敏感，CAN线在通信时会辐射一定的电磁能量，虽然不是特别强，但贴着放会让WiFi的信噪比变差。我们现场把天线吸在台架立柱上，离CAN线束差不多30厘米以上，实测信号质量稳定在-45dBm左右。
3.2 CAN总线接入的电气细节
接入CAN总线不是拿个线鼻子随便一搭就行。台架上的CAN总线网络，尤其是BMS内部CAN（动力CAN）和整车CAN，拓扑结构不同、终端电阻配置不同，接入方式也有讲究。
我们把整个接入过程固化成了一个标准流程：
- 确认接入点的物理层类型，是高速CAN（ISO 11898-2，速率500kbps）还是CAN FD（速率可到2Mbps/5Mbps），确定模块对应通道的收发器模式。
- 测量目标CAN总线在接入点的静态电压，CAN_H和CAN_L之间应该是2.5V对2.5V，差分电压为0。万用表测出来如果CAN_H是3.5V、CAN_L是1.5V，说明总线处在显性状态，可能有节点一直在发报文，这时候接入模块要小心电压冲击。
- 确认总线两端有没有60欧姆终端电阻。如果总线上只有两个终端电阻，那模块接入点相当于在总线中间，模块内部的CAN收发器不需要额外加终端电阻。如果接入点恰好是总线末端，而且原有终端电阻被拆掉了，那模块的终端电阻开关就要打开。
- 接线要采用菊链方式，从现有节点的CAN_H、CAN_L、CAN_GND并接出来，不要在线束中间破皮绞接。CAN总线对线缆阻抗有要求（120欧姆），破皮绞接容易造成阻抗不连续，产生反射，影响信号质量。
- 模块的CAN_GND一定要接，不接的话，模块的CAN收发器参考地电位和总线不一致，会导致共模电压过高，轻则收发器发烫，重则直接烧毁。
3.3 WiFi网络参数的工程配置
WiFi网络这块看着简单，实际上有不少工程细节。我们用的是独立工业路由器，而不是让模块直接开热点。为什么？因为独立路由器的天线增益更高、覆盖范围更大、带机量更多，而且可以同时接入平板、笔记本、手机多个设备，测试团队几个人同时看数据都方便。
网络参数的配置要点：
- SSID：不要用默认的，改成项目代号加日期，比如
HIL-BMS-20240115。方便测试人员在现场多套台架之间快速识别，避免连错设备。 - 频段：强制使用5GHz频段。2.4GHz在台架现场干扰太厉害，电机控制器、变频器、开关电源一堆电磁干扰源都在这个频段附近，实测5GHz下丢包率从2.4GHz的0.8%降到了0.02%以下。
- 加密方式：WPA2-PSK（AES），不用WEP也不用WPA（TKIP），这两种老协议安全性差，而且AES加密对吞吐量的影响比TKIP小。
- 静态IP分配：给每个CAN转WiFi模块绑定静态IP，方便上位机软件直接通过IP连接。我们用的模块支持DHCP，但测试现场如果路由器重启，DHCP分配的IP可能会变，而上位机软件里配置的IP就失效了。所以统一改成了静态IP，模块IP按顺序编排，比如192.168.1.101到192.168.1.110。
- 防火墙和流量隔离：如果路由器支持，把AP隔离打开，让WiFi终端之间不能互相访问，降低误操作风险。
3.4 上位机对接的两种方式
上位机对接我们用了两种方式，覆盖不同工具链的同事：
第一种是模块厂商自带的CAN分析软件，界面类似周立功CANTest那种，可以配置通道参数、启动记录、报文回放。这个软件直接支持通过WiFi连接模块，打开之后选择网络协议、填IP地址就能开始监控，上手成本最低，适合测试工程师现场快速看数据。
第二种是通用CANoe/CANalyzer对接，通过模块厂商提供的虚拟CAN驱动，把无线模块在电脑上虚拟成一个Vector的CAN通道。这样CANoe里原有的工程、面板、自动化脚本全部可以复用，不用改任何代码。我们是这么配的：
- 安装厂商的虚拟CAN驱动，安装完成后在设备管理器里会多出一个虚拟CAN设备。
- 打开CANoe，在Hardware配置里选择这个虚拟CAN通道。
- 配置网络参数（模块IP、端口号），CANoe就能正常收发报文了。
实测下来，用CANoe通过WiFi连接模块做报文记录和基本分析，性能和有线连接基本没有差别。但需要注意，如果用CANoe做总线干扰注入、错误帧注入这类高精度时序操作，无线链路的不确定性会影响注入时序精度，这类操作还是回到有线方式去做。
4. 台架支持CAN FD的关键改造点
4.1 为什么要特别关注CAN FD
现在很多新能源车型的BMS、VCU内部CAN总线已经升级到CAN FD了，原因很简单——数据量越来越大，电池单体电压、温度、绝缘电阻、SOC估算中间量，传统CAN 8字节的负载已经不够用。CAN FD单帧最多能带64字节数据，速率也快好几倍。
所以如果你做台架测试，大概率会碰到CAN FD总线。我们这次改造选模块的时候，特意确认了硬件的CAN FD支持能力。需要注意的一个大坑是：有些模块标称支持CAN FD，但实际上是FD控制器+普通CAN收发器的组合，收发器不支持快速速率切换，只能把FD报文当标准CAN跑，一帧8字节数据收下来，其他内容直接丢掉，你的FD报文分析和故障诊断就全瞎了。
真正支持CAN FD的模块，CAN收发器必须是CAN FD级别的，典型芯片型号有TJA1044、TJA1057等，它们支持高达5Mbps的数据段速率。模块的资料里一般会写“支持CAN FD，数据段最高5Mbps”或者“CAN FD ready”，看这个参数就行。
4.2 CAN FD配置参数测试记录
我们把模块挂在一条BMS内部CAN FD总线上做过一轮完整测试，记录结果如下：
| 测试项 | 参数 | 实测结果 |
|---|---|---|
| 仲裁段速率 | 500kbps | 正常通信 |
| 数据段速率 | 2Mbps | 正常通信，误码率低于0.001% |
| 数据段速率 | 5Mbps | 正常通信，但偶尔出现延迟抖动 |
| 长帧负载 | 64字节/帧 | 正常收发，无丢帧 |
| 连续压力测试 | 总线负载率70%，持续2小时 | 丢包率0.03%，无总线错误帧 |
一个有意思的现象是：5Mbps数据段速率下，WiFi链路稍微有点拥塞就可能出现延迟抖动。分析下来原因是，CAN FD的高速率让单位时间内产生的报文量大幅增加，模块内部的MCU处理CAN报文的速度赶不上WiFi发送的速度，造成缓冲区堆积。解决方法是把模块的WiFi发送缓冲区调大，然后在上位机软件里把记录线程的优先级调高。
4.3 CAN FD报文的时间戳精度问题
CAN FD报文对时间戳精度的要求比标准CAN高得多。标准CAN一帧最快0.1ms就发完了，而CAN FD的数据段速率加快，帧间间隔更短，对时间戳分辨率的要求自然更高。我们用的模块时间戳是微秒级的，但实测有两个影响因素：
一是模块内部RTC的晶振精度。之前用的模块内置RTC晶振精度是±20ppm，常温下误差不大，但台架环境温度变化大的时候，半小时可能偏差个几十毫秒。后来换了温补晶振，问题解决。
二是WiFi传输的抖动。假设模块在T0时刻收到一条CAN报文，加上微秒级时间戳，然后通过WiFi发送，上位机在T1时刻收到，T1-T0可能是5ms也可能是30ms。时间戳记录的是T0（CAN报文到达模块的时刻），和WiFi传输时延无关，上位机解析报文后用这个时间戳做时序分析，结果才是准确的。
这点非常重要，很多刚开始用无线CAN模块的工程师没有搞清楚，直接用上位机的接收时间去做时序分析，结果被WiFi抖动坑得怀疑人生。
5. 改造前后效果对比和验收实测
5.1 数据对比表
改造完成之后，我们做了一轮完整的对比验收，同一套台架测试工装，分别用有线和无线两种方式采集数据：
| 对比项 | 有线CAN（USB转CAN） | CAN转WiFi无线方案 |
|---|---|---|
| 布线时间 | 40分钟（穿管、固定、剥线） | 10分钟（挂模块、接天线） |
| 测试人员活动半径 | 受限于线缆长度，约2-3米 | 整个台架车间，约30米 |
| 多设备同时监控 | 需要另拉线并联 | 平板+笔记本同时接入，无额外布线 |
| 报文丢包率（500kbps） | 0% | 0%（持续工作8小时实测） |
| 报文丢包率（CAN FD 2Mbps） | 0% | 0.003% |
| 总线错误帧影响 | 无 | 无（正确配置终端电阻和晶振后） |
| 设备调试灵活性 | 低 | 高，模块随台架灵活安装 |
5.2 长时间运行稳定性验证
光看短时间测试数据不说明问题，我们最担心的是长时间运行的稳定性。WiFi模块在台架这种金属结构环境下，长时间高温、震动、电磁干扰并存，到底扛不扛得住？
我们做了两个长时间专项验证：
- 持续记录测试：模块连续工作12小时，采集BMS和VCU的CAN FD报文，上位机自动记录文件。结果12小时共采集报文约420万帧，应用层丢包率0.0015%，而且丢包集中在WiFi信号被临时遮挡的个别时刻（有人从天线前面走过）。这个数据对台架测试来说完全可以接受，420万帧里丢个几十帧，做数据分析时基本不影响统计结果。
- 高温环境测试：夏天台架车间温度到38°C，模块机壳表面温度实测54°C，仍然稳定工作，没有出现死机和断连。工业级模块的宽温设计这时候就看出来了，如果是消费级路由器改装的方案，这种温度下大概率会重启或者掉线。
5.3 实际测试过程中遇到的WiFi连接坑
再分享两个现场实际遇到的WiFi连接问题。
第一个是模块连上路由器但上位机收不到数据。排查了半天，最后发现是路由器的AP隔离默认开启了。AP隔离模式下WiFi终端之间不能互相通信，上位机和模块虽然都连着同一个WiFi，但它们之间的数据包被路由器隔离了。到路由器管理界面关掉AP隔离就好了。
第二个是平板在台架附近走动时偶发掉线。分析下来是因为台架上高压线束、电机控制器产生的电磁干扰导致WiFi信号在某个位置衰减严重。解决方案是换了一根增益更高的天线，然后把路由器的发射功率从50%调到100%。这里顺便提一句，如果你用的是工业路由器，发射功率可以手动调，不要一直用默认档。
6. 关于无线化改造的几点心得和后续扩展想法
项目做完一年多了，整体用下来，我觉得有几个心得值得展开说说。
第一，无线化改造不能追求一步到位。最稳妥的路径是先在非核心的监控通道上跑起来，验证稳定性和数据质量，然后再逐步扩展到更多的测试场景。我们项目里最先无线化的是BMS电压温度采集的监控通道，跑了一个月没问题，才把VCU、MCU的调试通道也切过来的。
第二，模块的选型不能只看价格。市面上百来块的消费级CAN转WiFi模块看起来性价比很高，但上了车台架大概率会出问题。工业级和消费级的差距主要体现在温度范围、晶振精度、WiFi射频稳定性、防护等级这几个方面。台架测试耽误一天的人工成本和测试资源成本，远远超过模块之间的价差，选贵一点但靠谱的模块，综合成本是更低的。
第三，无线链路和有线CAN始终是互补关系，不是替代关系。我现在在台架上的标配是：控制通道走有线，监控通道走无线；安全关键测试走有线，常规性能测试走无线。无线解决的是灵活性问题，有线解决的是确定性问题，两者结合才最稳。
后续有几个扩展方向我觉得值得尝试。一个是把无线模块和自动化测试脚本结合起来，做一个自动巡检工具，每天早上到台架边上只需要打开平板，系统自动检查所有CAN节点的在线状态、报文频率、错误帧计数，不用像以前那样手动一个个节点去触发验证。另一个方向是尝试把5G无线方案引入到整车转毂试验台架上，那种台架转速高、振动大、移动范围更广，5G的超低时延和大带宽潜力可能比WiFi更适合。
项目做完之后，最大的感受是：台架测试这块，很多时候瓶颈不在测试设备和软件，而是被那些不起眼的物理连接件、线缆、通信链路限制住了。把CAN总线无线化这一步迈出去，整个台架测试的效率和灵活性提升是实实在在的，谁用谁知道。
