本文讨论焦点：
- 什么是队列刷写？
- 为什么需要队列刷写？
- 队列刷写原理？
************************************************************************************
关注微信公众号“开心果 Need Car”，一起讨论Autosar开发中遇到的那些“坑”！
************************************************************************************
什么是队列刷写
队列刷写（Queued Flash）是指刷写过程中，刷写上位机（Tester）可以同时发送多帧诊断请求的刷写方式。
传统的刷写流程中，刷写过程是一个“乒乓”交互过程，即：一问一答式交互，只有当前的诊断请求（Request）给出肯定或者否定响应（Response）以后，Tester才能发送下一帧诊断请求。而队列刷写过程中，Tester可以连续发送多帧诊断请求，也就是说：被刷写的目标ECU具备缓存多帧诊断请求的能力。
传统刷写和队列刷写对比如下所示：
为什么需要队列刷写
OEM为了给顾客更好的驾/乘体验，不断地升级和优化车辆功能，而这些功能的升级和优化也是代码累加的产物。这意味着：相比以往，单件ECU的APP（Application）软件代码量更多了，那么使用传统的App刷写方式时间也就更长了。刷写App程序时间过长会带来哪些问题呢？
第一、在工厂车辆下线时（EOL，End of Line），生产的每辆车都需要刷写App程序，而过长的刷写时长，无疑会成为制约产能的一大因素；
第二、某些高端车具备远程刷写能力(OTA，Over The Air)，如果用户想升级最新的App程序，升级用时10分钟和用时3分钟，这将是完全不同的用户体验。
当然，缩短App刷写时间所带来的好处不止上述两点。对于整车，低端车几十个ECU，高端车上百个ECU。如果每个ECU的App刷写时间都增加，这将是一个不容忽视的问题。如何优化App刷写时间问题呢？队列刷写就是其中的一个选择。注意：队列刷写是针对同一个刷写节点（一个ECU可能包含多个刷写节点）提出的刷写策略。3队列刷写原理
在讨论队列刷写原理之前，先认识一下诊断命令处理的主角：诊断通信管理模块(DCM：Diagnostic Communication Manager)。DCM作用主要有两点：检测车辆故障、更新程序。DCM属于Autosar的重要组成模块，在Autosar软件架构中的位置如下所示：
队列刷写为什么可以减少刷写时间呢？因为队列刷写优化了诊断请求延时。传统的刷写流程中，诊断请求由Tester的a点发起，到ECU的c点处理，如下所示：
相关影片资源迅雷下载推荐
20个顶级设计与开发会议界面，获得灵感，其乐无穷
作者：由 CSSDA 工作人员近年来，无处不在的会议现场的创造力显着增加。曾经诱发睡眠的笨拙，现在是眉毛抬起，揉搓下巴的灵感花园。以下主系列背后的设计师值得一看他们的屏幕截图图像，因为他们已经接受了为设计师 ...
网站建设,20个顶级设计与开发会议界面，获得灵感，其乐无穷
从a点到c点花费的时间（Time_ac）可以分为两部分：
物理线路耗时（a->b）：Tester通过车辆外接的OBD（On-Board Diagnostics，车载自动诊断系统）端口连接待刷写的ECU，所以，诊断命令的传输会有部分时间耗费在物理线束的传输上。
模块接收耗时（b->c）：当诊断指令到达ECU的驱动层，也就是数据链路层，到数据传递给诊断处理模块DCM也需要耗费一定的时间。
如何理解b->c的时间消耗呢？嵌入式开发中，软件会划分不同的模块，不同模块之间的交互就形成了软件层级，也可以理解为数据流的传递路线，以Autosar的诊断处理层级为例，诊断指令从CanDriv接收到DCM处理需要经过的模块如下所示：
所以，ECU的DCM在响应完一帧诊断请求后，就有一段时间(Time_ac)处于空闲状态，如果可以让DCM在Time_ac内处理诊断命令（即：DCM全负荷运行），那就需要DCM无间隙地接收到下一个诊断指令。
DCM怎样才能无间隙地接收到下一个诊断指令呢？让DCM缓存至少另一帧诊断请求。这样也就意味着节省了诊断命令由a点到c点的时间。
既然Tester可以发送多个诊断指令，就涉及到诊断指令的顺序问题。诊断刷写流程需要严格按照诊断指令的先后顺序处理，不能错序发送，也不能错序响应，否则会导致刷写失败。既然刷写序列不能错乱，那最好的处理方式就是使用FIFO，如下所示：
如上图，DCM处于近乎100%的工作状态，提高了App程序的刷写速度。
这里截取一个队列刷写流程的示例，如下所示：
t1时刻，Tester发送36 01诊断请求（首诊，FF：Frist Frame），请求刷写一个App Block，之后ECU给出流控帧（FC:Flow Frame），表明ECU的诊断处理能力。Tester根据ECU反馈流控帧的信息知道目标ECU处理诊断的能力，之后Tester根据该ECU的诊断处理能力发送连续帧(CF:Consecutive Frame)；t2时刻，Tester发送完该Block最后一帧数据以后，没有等ECU响应，而是顺带着发送了下一个诊断请求(37服务)；t3时刻，ECU给出36 01服务的正响应（76 01）；t4时刻，ECU给出37服务的Pending响应，告诉Tester，ECU有能力处理37服务，只是需要多一点时间；t5时刻，ECU给出37服务的正响应。
提示：
- 诊断请求的正响应（Positive response）格式：SID(Service Identifier )+0x40，比如：0x10(DiagnosticSessionControl)服务的正响应，0x50 Xx Xx(Xx时间参数);
- 诊断请求的否定响应（Negative response）格式：0x7F + SID + NRC(Negative Response Code)，比如：0x10(DiagnosticSessionControl)服务的否定响应，0x7F 10 12（0x12表示Sub-Function Not Supported）。
************************************************************************************
关注微信公众号“开心果 Need Car”，一起讨论Autosar开发中遇到的那些“坑”！
************************************************************************************
企业网站建设与开发最低只要299元起，包含域名服务器，需要的联系QQ345424724，电话15516990022,18530226930相关影片资源迅雷下载推荐
拼多多Temu出海项目正式上线，教你如何做好测评补单，分 ...
拼多多跨境出海项目推出，海外版叫“Temu”，第一个站点首选美国站，可见拼多多的野心是非常大的，想在美国本土电商平台中分到一杯羹，相信是有非常周密的安排的，拼多多在国内固有的淘宝，京东，天猫的电商市场里厮 ...
七人拼团,拼多多Temu出海项目正式上线，教你如何做好测评补单，分 ...
标签： 公众号开发 Bootloader开发：队列刷写（Queued Flash）基础
