汽车诊断工程师的黎明：并行刷写策略与实现

你的名字 2022-09-15 14:57 194阅读 0赞

刷写，对于汽车诊断工程师们来说就像是家常便饭，行业内对刷写的定义是用于ECU的软件更新（APP程序），相信大家也一定在网上扒过不少讲它更新流程的文章，如：34服务、36服务等等，那我们今天就来点不一样的，今日唠嗑话题：并行刷写。

在谈论并行刷写前，小怿先抛出一个问题：通过网关的诊断CAN口与ETH口去刷写CAN样件（如车身控制单元：BCM），刷写所耗费的时间有差别吗？如图1所示。

![图片][df2624fb1ab2773ac8cc9c190c98f888.png]

图 1 刷写模式简图

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

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

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

*  网关接收并解析完诊断仪发送的诊断数据（DoIP数据）后，向诊断仪发送诊断ACK报文；
 *  并以DoCAN/CANFD报文格式向车内目的ECU转发诊断请求数据，此时需遵循ISO 15765 CANTP多帧传输机制首先向ECU发送诊断请求首帧，待接收到ECU回复的流控帧后发送后续诊断请求连续帧；
 *  若诊断请求数据传输时间过长(大于P2Server)，则网关需要在P2Server时间内向诊断仪发送一条NRC为0x78的诊断否定响应；
 *  后续若在P2\*Server时间内诊断请求数据发送仍未结束，则网关仍需按照既定规则向诊断仪发送NRC为0x78的否定响应(一般以1/2 P2\*Server周期发送)，直至诊断请求数据发送完成。

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

![图片][017efedbc295a6399e0dcaa823dd63be.png]

图 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通道上都可同时进行数据包传输的功能，满足并行刷写的基本需求。

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

![图片][33089adf5f3223350402fd439bdf4672.png]

图 3 并行刷写示意图

既然DoIP对于车内ECU一对一的刷写在时间上并没有提升，那么若能用上述的方法针对一对N的前提下岂不是大大节省了刷写时间？此时有些小伙伴会冒出一个想法：既然DoIP能如此实现，那诊断CAN口能实现该类行为吗？

针对此类想法，小怿早就实践过了，若是诊断CAN口也按照这类做法其实并不会减少多少的传输时间，因为诊断CAN进行36服务传输数据的时候有多帧的情况出现，所以并不会减少相应传输的时间。相比较而言，这里体现出的是DoIP一帧传大包的能力。

想法如此美好，诊断仪上位机该如何实现呢？来，跟着小怿，我们一起来实践一下吧~

此处小怿根据两个大家熟悉的软件：CANoe + vTESTstudio，CANoe作为执行软件，vTESTstudio作为代码编辑软件，介绍刷写上位机实现方式。框架如下图4所示。

![图片][2f6e492ec92a16d5abf138e92f08b7ba.png]

图 4 代码执行框架示意图

此处难点有两处：

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

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

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

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

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

![图片][c5d1f963ce3808fafc4381afbb2b1063.png]

图 5 并行刷写Log示意图

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

[df2624fb1ab2773ac8cc9c190c98f888.png]: /images/20220828/896aefaa7398439d9f70fca795f69e9d.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzIwMDgzOTg3Mg==&mid=2247487486&idx=1&sn=71944955d33f153cf854a8ca06bd067c&chksm=96f64851a181c1474c21de534077e0d44d21a816ef6bf614a5a69a4144e65f2fb8ea6540c4f9&scene=21#wechat_redirect
[017efedbc295a6399e0dcaa823dd63be.png]: /images/20220828/1978b3b66f8d4565945ccdb5b0a34056.png
[33089adf5f3223350402fd439bdf4672.png]: /images/20220828/12cd152655cf499a9d33c750bc6e552e.png
[2f6e492ec92a16d5abf138e92f08b7ba.png]: /images/20220828/596d171f10a34134972562e57294afdd.png
[c5d1f963ce3808fafc4381afbb2b1063.png]: /images/20220828/213abcb1d4154fec97a44dd2337426e6.png