汽车以太网测试诊断工程师的黎明-金年会金字招牌信誉至上

刷写，对于汽车诊断工程师们来说就像是家常便饭，行业内对刷写的定义是用于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技术越来越成熟，并行刷写这种减少工程师工作量与工作时间的机制会越来越普及，相信汽车诊断工程师的黎明也会越来越近。