CANoe刷写利器：掌握队列刷写的关键步骤

车载ECU是汽车中负责控制的核心组件，随着汽车技术的不断发展，ECU功能日渐复杂，为了确保稳定可靠的运行，ECU的软件升级至关重要。相较于传统刷写，队列刷写有什么区别和优点，这篇文章将对此展开详细介绍，另外也将介绍如何在CANoe软件中实现仿真测试。

什么是队列刷写

随着汽车行业智能化、个性化的发展，车载ECU要实现的功能及代码量持续增加，这意味着Application的数据量更加庞大，如果使用传统的刷写方式，刷写时间也就更长，这些原因促使我们寻找新的解决办法，也进一步推动了OTA无感刷写、队列刷写等技术的发展。

我们知道，车载ECU的软件更新，也就是刷写，是通过UDS诊断请求实现的，而诊断是采用问答的形式请求-响应，即诊断仪发送请求后需要等待ECU响应，判断响应内容后再次发送下一请求，这种情况保证了数据传输的可靠，但相对应的也降低了通信效率。队列刷写则是在诊断仪发送请求后，不等待ECU响应继续发送下一请求，保证ECU一直有待处理的诊断请求，从而提高ECU使用效率，大幅缩短刷写时间。

 传统刷写和队列刷写

    队列刷写，顾名思义就是将所有待发送的请求排成一个队列，采取先进先出的形式。我们为这个队列设置两个参数：List和REQ_Tx。

• List为诊断仪队列列表中待发送请求的数量；
• REQ_Tx为控制器待处理的请求数量，每当诊断仪从队列中取出一条诊断请求发送给控制器则REQ_Tx+1；若收到ECU响应则REQ_Tx-1。

每当List>0且REQ_Tx<2时，应立即从队列中发送一条请求，保证控制器一直有一条待处理的请求，避免控制器资源空闲，需要注意的是，队列刷写针对的是单个控制器的刷写。

如何实现队列

以太网的诊断刷写是通过TCP/IP协议报文传输，控制器需要对每帧TCP报文响应ACK应答，根据Nagle算法，最多只允许存在一个未被ACK确认的包，从以太网控制器实现角度来说，若要做到队列发送就需要在控制器响应ACK未响应诊断的情况下发送下一帧请求，但ACK及诊断的响应相差时间较短，对诊断仪来说可操作的空间很小，既然如此我们换一种方式思考是否能够连续发送两条请求而不需要考虑ACK应答呢，下面我们来学习两个算法。

Nagle算法

假如某个应用程序不断地提交小单位1字节的数据，而这小数据在传输过程中需要添加40字节的头部信息（TCP与IPv4各占20字节），这导致了41字节大小的数据包只有1字节的可用信息，造成庞大的浪费，而Nagle算法正是为了解决这个问题提出的，通过合并一定数量的发送数据后一次提交，来减少数据包发送量来增进TCP/IP的性能，TCP/IP默认开启此算法。

延迟ACK

RFC 1122定义了Delayed Acknowledgment，简称延迟ACK，目的也是减少网络中传输大量的小报文数量，但该报文数是针对ACK报文的。一个来自发送端的报文到达接收端，TCP会延迟ACK的发送，希望应用程序对刚刚收到的数据进行应答，用新数据将ACK捎带过去或等下一条来自发送端的报文到达后一同发送ACK，TCP/IP也默认开启此算法。

两个算法都是为了减少数据包存在，但当两个算法同时启动就会导致冲突，假设发送端连续发送两段小数据，接收端接收到第一段数据后因TCP延迟确认而等待第二段数据后一同发送ACK，发送端则因第二段数据长度小于MSS而等待第一段数据的ACK，最终导致两对端都进入等待直到ACK延迟超时，为了避免这个问题，我们就需要禁用Nagle算法，这样，发送端就不需要等待上一段数据的ACK即可发送下一请求，也就能够实现队列。

仿真测试

    队列刷写与常规刷写的流程相同，主要包括3个阶段（预编程、主编程、后编程），通过UDS协议来实现，如下图所示：

刷写流程

环境搭建

我们采用Vector的CANoe软件作为搭建测试环境的工具，通过加载option.Ethernet实现以太网网络的仿真与测试，基于CAPL编程语言模拟实现诊断仪的诊断功能。硬件选用Vector的VN5650，通过线缆连接控制器的T1/TX口，如图所示：

连接示意图

软件仿真

使用CANoe创建以太网工程BT_Queued，配置软硬件通道、TCP/IPStack等相关参数后，在Test模块增加XML测试节点。

测试环境示意图

工程通过脚本代码的形式模拟诊断仪的通信，实现诊断仪和控制器件的通信，完善的CAPL文件可以帮助用户快速搭建测试环境，配置运行工程。如下图所示：

CAPL文件示例

首先使用CAPL提供的封装函数完成TCP连接，如下图所示：

TCP连接示例

根据控制器要求进行通信准备工作，包含常见的车辆识别请求、路由激活等，如下图所示：

通信准备示例

刷写时需要获取刷写文件内容，根据不同文件格式使用不同的封装函数，目前东信创智支持Hex、S19、Bin、Zip、VBF、CBF等格式的刷写文件的测试，其中Hex、S19使用fileGetString函数，Bin、zip等使用fileGetBinaryBlock函数。

获取文件函数

将需要发送的数据以数组的形式通过封装函数TCPsend发送至控制器，完成测试数据发送和接收，如下图所示：

报文发送处理示例

队列刷写的关键在于诊断仪端需要连续发送两条诊断请求，即待ACK确认的TCP报文数量是2，上文提到因Nagle算法限制了发送端只能存在一个待确认ACK的TCP报文，所以需要关闭Nagle算法，才能保证在第一条请求未响应ACK的情况下再次发送第二条请求。CANoe也提供了函数用来设置Nagle的开启关闭，建议在TCP连接时设置。

ipSetSocketOption(TCPsocket, "IPPROTO_TCP", "TCP_NODELAY", 1);

TCP Socket option函数示例

除上文提到的函数，脚本中还大量使用CAPL提供的封装函数，有兴趣的可以查看CANoe的帮助文件。

案例分析

下图为实现队列刷写的数据，以刷写过程中的$36服务为例，分析一下队列刷写过程。

1.  诊断仪tester向控制器ECU发送诊断请求Req1（0x3601）；

2.  Tester将Req1传输完成以后，无需等待Req1响应，即可发送Req2（0x3602）；

3.  等待ECU发送Req1响应Resp1（0x7601），发送Req3（0x3603）；

4.  等待ECU发送Req2响应Resp2（0x7602），发送Req4（0x3604）；

5.  ...

循环往复，直到所有数据传输完成。需要注意的是虽然不需要判断当前请求的响应是否正确，但如果过程中出现非预期响应，也是要中断刷写流程的，这一点和常规刷写一致。

测试数据

真实的环境中，受限于诊断仪端请求的时间间隔及控制器的响应时间，4G大小的刷写文件，使用常规刷写用时约4500秒，而使用队列刷写用时约1200秒，节省约75%的刷写时间。可能从单个ECU来看节省的时间体量不大，但对于拥有几十至上百个ECU的整车来说，这是个不容忽视的时间，在工厂车辆下线时，提高产能，在售后阶段缩短的升级时间也会影响用户体验，进而提升品牌口碑。

以上就是有关基于CANoe的队列刷写的所有内容，希望能对大家使用CANoe进行测试仿真有所帮助。

如果在后续使用过程中出现其他问题，欢迎随时发送至沈阳东信创智科技有限公司的市场邮箱market@dotrustech.com，我们会尽快帮您解决~