车载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，我们会尽快帮您解决~
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
