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

刷写，对于汽车诊断工程师们来说就像是家常便饭，行业内对刷写的定义是用于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通道上都可同时进行数据包传输的功能，满足并行刷写的基本需求。

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

图 3 并行刷写示意图

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

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

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

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

图 4 代码执行框架示意图

此处难点有两处：

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

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

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

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

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

图 5 并行刷写Log示意图

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

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

谈谈汽车诊断之KWP2000/ISO14229/ISO15765/SAEJ1939
最近在研究汽车诊断规范,其中涉及到好几个类似的国际规范,比如KWP2000.ISO-14229.ISO-15765.SAE-J1939等等.有的规范彼此之间相互引用,有的规范却又各自独立,简直就是一团 ...
【图解UDS】UDS汽车诊断开发流程及Vector解决方案工具链介绍
[图解UDS]UDS诊断开发流程及Vector解决方案工具链介绍目录为了便于学习ISO 14229 UDS诊断协议,提供三个资源链接: ...
测试开发实践系列：为满足OTA及”大数据”更新的并行刷写和队列刷写分析
随着车载以太网总线技术在车内广泛地应用,车辆网络架构也在逐渐发生变化,传统的分布式架构正在逐渐被域/区域控制器架构所取代.主干网通信带宽的大幅度提升,为新的软件更新方式提供了基础条件.车辆智能化.个性 ...
【图解UDS】UDS汽车诊断标准协议（ISO 14229）带你入门到精通
[图解UDS]UDS汽车诊断标准协议(ISO 14229)带你入门到精通目录为了便于学习ISO 14229 UDS诊断协议,提供 ...
基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)
上个月一个同事Z跳槽去了德赛西威,Z之前是完全不懂诊断的MCU工程师,去德赛后做诊断开发,让我感觉到,汽车嵌入式行业,CAN和诊断工程师还是比较稀缺的.之前我和Z共同负责一个项目,我负责CAN网络和诊 ...
成为诊断工程师，如何入门？
汽车诊断开发诊断就像医生对待病人一样,对每一个车身单元进行问诊,检测出问题的根源.常用到的工具有CAN oe.Vehicle spy.CAN ape.CAN stress.CAN diva(自动化测 ...
听说你想做一个汽车软件工程师？（下）
在这个系列的第一篇文章木城:听说你想做一个汽车软件工程师?(上)里,我们讨论了汽车软件工程师都有哪些职位.但是,就算是同样一个职位,比如"诊断工程师"吧!你给ADAS系统做诊断, ...
汽车诊断之UDS入门-UDS概述
最近工作中涉及ECU刷写部分,作为一个没有接触过汽车诊断的小白,开始了边学边做的历程,对UDS做一个学习总结和复盘,希望可以帮助到各位小伙伴们. 应用层协议 UDS (Unified Diagnost ...
虹科智能汽车诊断及智能汽车测试联合实验室成立
智能汽车测试联合实验室智能汽车诊断联合实验室为进一步加强校企合作,促进产学研究深度融合,加快科研成果转化,广州虹科电子科技有限公司在广师大白云校区全资赞助建立了"智能汽车诊断联合实验室& ...
UDS汽车诊断入门01 - 简介
前言一直想写一个关于UDS学习的系列文章,却一直没有动笔,一来是由于觉得自己学得还不够透彻,二来想一开始就把文章写得很完美,然而事实上真正要做到对协议非常透彻得话,又谈何容易,协议是死的,人是活 ...

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

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

最新文章

热门文章