新闻中心

News

汽车以太网诊断路由深度排雷


随着DoIP协议的广泛应用,现代汽车内部通信会大量存在传统诊断报文(UDSonCAN、UDSonLIN)和基于以太网的诊断报文(UDSonIP)并存的现象,比如UDSonCAN和UDSonIP之间,这些报文会存在信息互转的场景,我们也称之为诊断路由。

继上篇《干货 | DoIP协议深度排雷》按照“激活线激活——车辆发现——路由激活——诊断交互——关闭TCP_DATA_Socket”五个步骤详细讲解了DoIP诊断会话中需要重点关注的信息,今天给大家分享一下在系统或实车诊断通信环境下GW(网关)执行以太网诊断路由的一些关键知识点。小怿会从诊断路由的应用场景、诊断路由转发规则和诊断路由测试三个维度给大家进行介绍。



诊断路由应用场景



在诊断通信应用中,网关承担诊断仪与被诊断节点之间诊断报文的路由功能。诊断仪连接在OBD口,通过网关与内部ECU进行诊断通信。

下图是诊断路由的一个典型应用场景,如图1所示,整个流程概况如下:

  • 诊断仪直接将诊断请求发送给网关

  • 网关接收到诊断请求后执行DoIP Header及诊断报文检测处理

  • 网关检测通过后向诊断仪发送一条诊断ACK报文

  • 网关将该诊断请求转发至目的ECU所在网络/总线

  • 目的ECU接收到诊断请求后回复相应诊断响应报文给网关

  • 网关接收到诊断响应报文后按照DoIP报文格式转发给诊断仪

图 1 诊断路由典型应用场景示意图


诊断路由转发规则


诊断路由最核心的还是路由的概念,这就涉及到车内所有应用诊断协议的总线/网络之间诊断报文的转发,如CAN/CANFD/Ethernet/Flexray/LIN等。今天小怿只介绍两种最常见的应用场景的路由规则:DoIP与DoIP之间的路由、DoIP与DoCAN/DoCANFD之间的路由。


1、DoIP-DoIP路由

诊断仪从外部OBD-Ethernet诊断口对内部DoIP节点进行诊断通信。在DoIP-DoIP通信情况下,网关需要实现诊断报文从外网到内网以及内网到外网的转换。

网关转发诊断请求(物理寻址)

物理寻址诊断报文转发的规则大致如下:

诊断仪通过OBD-Ethernet诊断口发送诊断请求(目的逻辑地址(DoIP TA)为被诊断DoIP节点逻辑地址),目的IP为网关外部IP地址(一般为DHCP分配)

网关接收到诊断请求时需解析至DoIP层信息(逻辑地址),将目的逻辑地址(DoIP TA)映射为被诊断DoIP节点的IP及MAC地址

网关重新封装该诊断请求报文,即将源IP更换为网关内部地址,将目的IP及MAC地址更换为DoIP节点的IP及MAC地址

网关将重新封装的诊断请求报文发送至被诊断DoIP节点对应的网口


图 2 诊断请求转发至内部DoIP节点


功能寻址的过程与物理寻址类似,区别在于:功能寻址诊断请求时,网关需分别映射功能寻址地址对应的所有DoIP节点IP及MAC地址,并分别转发至各DoIP节点。


网关转发诊断响应


诊断响应转发的规则大致如下:

车内DoIP节点向网关发送诊断响应报文,目的IP为网关内部IP地址,目的逻辑地址为诊断仪逻辑地址

网关接收到诊断响应报文时,同样需要解析至DoIP层信息(逻辑地址),将目的逻辑地址(DoIP TA)映射为诊断仪IP及MAC地址

网关重新封装该诊断响应报文,即将源IP更换为网关外部IP地址,目的IP及MAC更换为诊断仪的IP及MAC地址

网关将重新封装的诊断响应报文发送至OBD-Ethernet口


下图总结了以上过程,如图3所示:


图 3 DoIP诊断响应转发至诊断仪

功能寻址的过程与物理寻址类似,区别在于:对于功能寻址诊断请求,各车内DoIP节点进行诊断响应时,源逻辑地址皆更换为各自ECU对应的逻辑地址。


2、DoIP-DoCAN/CANFD诊断路由

诊断仪从外部OBD-Ethernet诊断口对内部CAN/CANFD节点进行诊断通信。在DoIP-DoCAN/CANFD通信情况下,网关需要实现诊断报文从以太网到CAN/CANFD总线以及CAN/CANFD总线到以太网的转换。


网关转发诊断请求


物理寻址诊断报文的转发逻辑如下:

诊断仪通过OBD-Ethernet诊断口发送诊断请求(目的逻辑地址为车内non-DoIP节点),目的IP为网关外部IP地址(一般为DHCP分配),目的逻辑地址(DoIP TA)为车内ECU对应逻辑地址

网关接收到诊断请求时需解析至DoIP层信息(逻辑地址),将目的逻辑地址(DoIP TA)映射为目的ECU的诊断请求ID

网关重新封装该诊断请求报文,即将该DoIP诊断请求转换为DoCAN/CANFD格式,CAN报文ID为目的ECU对应的诊断请求ID

网关将重新封装的诊断请求报文发送至目的ECU所在总线

下图总结了以上过程,如图4所示:


图 4 诊断请求转发至内部CAN/CANFD节点

功能寻址的过程与物理寻址类似,区别在于:功能寻址诊断请求时,网关需将DoIP报文中功能寻址地址(DoIP TA)映射为DoCAN/CANFD的功能寻址诊断请求ID,并分别以DoCAN/CANFD报文格式转发至该功能寻址地址所覆盖的CAN/CANFD总线。


网关转发诊断响应


诊断响应转发的规则大致如下:

车内CAN/CANFD节点向网关发送诊断响应报文,响应ID与请求ID对应

网关接收到诊断响应报文时,将响应ID映射为内部ECU的DoIP逻辑地址

网关重新封装该诊断响应报文,即将DoCAN/CANFD诊断响应转换为DoIP报文,目的IP及MAC为诊断仪的IP及MAC地址,源逻辑地址为内部ECU的逻辑地址,目的逻辑地址为诊断仪逻辑地址

网关将重新封装的诊断响应报文发送至OBD-Ethernet口


下图总结了以上过程,如图5所示:


图 5 DoCAN/CANFD诊断响应转发至诊断仪

功能寻址的过程与物理寻址类似,区别在于:对于功能寻址诊断请求,车内CAN/CANFD节点需使用各自诊断响应ID进行诊断响应。

总的来说,我们可以看到DoIP与DoCAN/CANFD之间的路由多了DoIP逻辑地址与内部CAN/CANFD总线诊断ID映射的步骤。


网关如何处理DoIP大包数据


上述诊断请求及响应路由皆是在单帧传输的情况下网关执行DoIP-DoCAN/CANFD路由转发的机制。而众所周知,以太网数据的长度定会出现大于DoCAN/DoCANFD单帧传输的字节长度的情况,那么此时网关是如何执行诊断数据路由的呢?

下面小怿就来解析这个问题,分为如下的步骤:

网关接收并解析完诊断仪发送的诊断数据(DoIP数据)后,先向诊断仪发送诊断ACK报文

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

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

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


下图总结了以上过程,如图6所示:


图 6 多帧诊断请求转发

对于多帧诊断响应,网关与目的ECU同样遵循ISO 15765 CANTP多帧传输机制进行诊断响应数据的传输。但此处对于网关与诊断仪的交互来讲,通常实现方式是网关将接收的诊断响应进行存储,当接收完所有诊断响应帧后,再将数据重新封装后转发给诊断仪。因此在诊断响应数据传输过程中,网关同样需要按照上述规则向诊断仪发送NRC为0x78的诊断否定响应报文,直至诊断响应数据接收完成。

小怿也遇到过网关执行边接收边转发的机制,即在接收CAN/CANFD节点回复的多帧诊断响应时不进行存储,直接将诊断响应帧转换成DoIP报文格式转发给诊断仪,由诊断仪来执行所有诊断响应数据的组包功能。

具体按照哪种方式去实现国际标准中没有硬性标准,OEM或供应商可根据设计需求选择适当的实现方案。


诊断路由测试



可以看到,诊断路由的整个过程和规则还是相当复杂的,也是车载通讯很容易出错的一个环节,可以说诊断路由的测试是汽车通讯测试重中之重。下面小怿就跟大家介绍一下诊断路由的测试环境。

若要搭建一套诊断路由通信环境,需要诊断仪、网关、内部ECU都已具备诊断通信功能,而往往在测试阶段,某些ECU功能尚未集成或缺少某些ECU。因此我们在诊断路由测试时需要模拟内部ECU来实现诊断请求的接收及诊断响应的发起。


图 7 诊断路由测试拓扑


我们使用Vector的CANoe工具搭建测试环境,开发测试工程。基于CAPL编程模拟实现内部ECU的诊断通信功能,测试过程中需要依据诊断路由表实现内部各ECU与网关的诊断数据交互。

诊断路由测试为自定义测试内容,基本上包含以下内容:

  • 诊断报文转发格式测试

  • 物理寻址/功能寻址诊断报文转发测试

  • 单帧/多帧诊断报文转发测试

  • 转发时间测试;

  • 通信异常测试

  • 错误报文测试

  • DUT复位测试

  • 诊断响应超时测试

除了以上较为通用的内容外,我们也会根据OEM诊断路由设计规范,对特定功能定制开发一些测试用例,比如诊断报文重复发送测试,来实现对完整诊断路由功能的测试覆盖。