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

怿星科技

于 2021-10-13 11:32:16 发布

阅读量2.6k

点赞数 3

文章标签：汽车以太网测试刷写测试汽车诊断工程师

本文链接：https://blog.csdn.net/m0_47334080/article/details/120740640

版权

本文探讨了汽车诊断中并行刷写的概念，通过对比诊断CAN口与ETH口（DoIP）刷写车身控制单元（BCM）的时间差异，指出DoIP在速度上的优势并不显著。然后，提出了通过网关实现并行刷写的设想，强调了网关在处理逻辑地址映射和数据包序列方面的关键作用。作者通过CANoe和vTESTstudio的实例展示了并行刷写的可能性，指出这种方法有望大幅减少刷写时间，推动汽车诊断技术的进步。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

图 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所示，总结上述了过程。

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

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