刷写，对于汽车诊断工程师们来说就像是家常便饭，行业内对刷写的定义是用于ECU的软件更新（APP程序），相信大家也一定在网上扒过不少讲它更新流程的文章，如：34服务、36服务等等，那我们今天就来点不一样的，今日唠嗑话题：并行刷写。在谈论并行刷写前，小怿先抛出一个问题：通过网关的诊断CAN口与ETH口去刷写CAN样件（如车身控制单元：BCM），刷写所耗费的时间有差别吗？如图1所示。

“当然有区别啦，毕竟后者是通过DoIP的，DoIP传输的数据较快，所以后者的耗费时间是比较短的。”大家是不是都是这种看法呢？小怿有不同的看法：DoIP传输快，36的数据包一帧就传完，但是网关会通过诊断路由模块转化为CAN报文，完成刷写流程；而诊断CAN口刷写也是网关转化为CAN报文，完成刷写流程，因此对于诊断CAN口刷写车内CAN节点而言，ETH口貌似也没有提升多少速率。

既然通过网关的诊断CAN口与ETH口分别去刷写车内CAN节点的时间一致的话，那么ETH口的优势在哪儿呢？这里，小怿又要提问啦：DoIP传输速率快，那么在DoIP报文传输完成，网关路由诊断CAN报文时，诊断仪与网关需要保持何种通信呢？

学霸们一定知道，答案就在怿星科技的往期推文《汽车以太网诊断路由深度排雷》中，文章在网关如何处理DoIP大包数据步骤中提到：

· 网关接收并解析完诊断仪发送的诊断数据（DoIP数据）后，向诊断仪发送诊断ACK报文；

· 并以DoCAN/CANFD报文格式向车内目的ECU转发诊断请求数据，此时需遵循ISO 15765 CANTP多帧传输机制首先向ECU发送诊断请求首帧，待接收到ECU回复的流控帧后发送后续诊断请求连续帧；

· 若诊断请求数据传输时间过长(大于P2Server)，则网关需要在P2Server时间内向诊断仪发送一条NRC为0x78的诊断否定响应；

· 后续若在P2*Server时间内诊断请求数据发送仍未结束，则网关仍需按照既定规则向诊断仪发送NRC为0x78的否定响应(一般以1/2 P2*Server周期发送)，直至诊断请求数据发送完成。

如图2所示，总结上述了过程。

既然网关在DoIP转CAN报文时，会先给诊断仪一个ACK响应，对车内CAN节点进行多帧数据包信息传输的同时给出NRC0x78，让诊断仪进行等待。那么此时提出个大胆的想法：诊断仪此时能否开启另一个线程去刷写另一通道上的ECU呢？

对于常规的网关而言，诊断路由只是拆包组包及路由转发的功能，若是要实现上述的想法，此时对于网关功能点的需求需进一步完善。

功能点一：网关内部需要处理DoIP中逻辑地址与CAN节点物理寻址的映射速率增快，同时确保地址信息不冲突。网关在传输数据包过程中，必然出现CAN通道1与CAN通道2上ECU的诊断响应报文同时反馈给网关的情况，因此在处理同一时刻的响应报文时，应遵循队列原则，逐一将诊断响应报文组装成数据包的形式封装成DoIP报文转发给诊断仪。

功能点二：网关向车内不同通道上ECU传输数据包信息时不出现序列错误，即在传输CAN通道1上ECU的诊断数据不能传输到CAN通道2上去。网关在实现并行传输数据包时，需要根据DoIP数据包中的逻辑地址，拆分DoIP的数据包封装成对应CAN通道上节点的多帧数据包，从而实现在不同CAN通道上都可同时进行数据包传输的功能，满足并行刷写的基本需求。

若网关的功能需求满足上述两个功能点，且诊断仪的功能开发完善，即可实现在不同通道上同时进行诊断刷写的功能，达到并行刷写的目的，如下图所示。

此处难点有两处：

1. 如何处理在以太网通道上去传输不同CAN通道的DoIP数据包发送且不会造成丢包；

2. 如何处理在以太网通道上去接收不同CAN通道的DoIP数据包且不造成线程的拥塞。

借助vTESTstudio 4.0版本中的函数：testStartParallel实现以太网通道上同时传输DoIP数据包；同时采用环形队列方式执行发包机制，避免丢包问题。

vTESTstudio中调用CANoe自带的DoIP.dll去实现DoIP层与UDS层的函数封装，满足DoIP报文正常收发功能，利用DoIP层逻辑地址唯一性区分各诊断响应。

解决上述两个问题后，通过自身编写好的代码执行并行刷写序列，实现结果如下图5所示。

综上所述，随着DoIP技术越来越成熟，并行刷写这种减少工程师工作量与工作时间的机制会越来越普及，相信汽车诊断工程师的黎明也会越来越近。