车载以太网DoIP 协议测试的研究与分析

李志涛，耿伟峰

（长城汽车股份有限公司技术中心，河北 保定 071000）

汽车电子技术的飞速发展，促进了车载网络通信技术的广泛应用，同时高性能车载娱乐系统、大数据、车联网、云服务、自动驾驶等新技术使得车载网络对带宽、兼容性的要求越来越高，传统的车载CAN总线通信受限于带宽原因，已越来越不能满足车辆智能化和网联化的要求。车载以太网技术以其高带宽、兼容性强、可靠性高、扩展性良好的特性，逐渐在车辆上普及应用，尤其在软件刷新、远程OTA等通信应用场景需求中，实现基于车载以太网的DoIP协议，已成为车载以太网技术应用的必然。

1 标准概述

DoIP（Diagnostic communication over Internet Protocol），是基于IP网络的汽车诊断协议，全称为基于IP网络的诊断通信，其具备更快的数据传输速率，从而在复杂的数据诊断和软件刷新的场景下节约时间和成本。

DoIP协议用于UDS诊断的传输，该协议由ISO 13400标准定义，ISO 13400规定了DoIP的传输层、网络层、数据链路层和物理层，应用层和会话层部分由ISO 14229实现。应用层的UDS诊断服务，通过传输控制（TCP/UDP）协议和网络（IP）协议，经数据链路层的封装，然后由物理层转换后发送到网络上，完成车内以太网控制器与外部测试设备之间的诊断通信。DoIP通信过程是基于TCP/UDP进行诊断报文的传输，诊断报文中的Payload携带相应诊断服务数据信息，诊断服务数据遵循传统的诊断协议。因此，准确来说DoIP协议是一个扩展的传输层协议，为基于车载以太网的诊断搭建了一个通信桥梁。DoIP协议在OSI 7层模型中的位置及分布见图1。

图1 DoIP标准架构分布

ISO 13400-1处于应用层（层7）之上，是对一些通用信息、应用场景的描述。ISO 13400-2定义了传输层和网络层（层4和层3），ISO 13400-2中规定了DoIP通信在传输层中使用TCP和UDP协议，在网络层中使用IPv4或IPv6协议、专属于DoIP通信的内容等。ISO 13400-3定义了DoIP诊断通信对Ethernet数据链路层和物理层的要求等；ISO 13400-4定义以太网诊断连接器要求。同时在ISO 13400-2中定义了基于DoIP通信的诊断架构模型，架构模型见图2。

图2 车载网络架构示意图

其中，DoIP诊断架构须实现以下特性：①车辆与测试设备具有检测对方并加入到网络的能力；②具备车辆信息声明的能力；③获取车辆基本状态信息，如车辆诊断模式信息查询；④建立与通信连接的保持、维护机制等；⑤实现测试设备与车辆内部ECU节点之间的数据路由；⑥错误状态处理，如物理网络断开等。

2 通信诊断

2.1 DoIP数据结构

DoIP数据是层层向下传递的，直至构成完整的以太网帧，通过物理层的介质发出。DoIP数据封装在以太网帧中，包含报头和有效数据，其中Protocol Version定义了DoIP的协议版本号；Protocol Version为版本号取反；Payload Type定义了数据类型（标识本帧数据的用途）；Payload Length定义数据长度（标识后面的数据长度）；DoIP Payload包含了Payload Type对应的具体数据，Payload数据中又分为源地址、目标地址、应用数据。DoIP数据报文的格式见图3。

图3 DoIP数据报文

DoIP报文类型分为3类：节点管理类、车辆信息类与诊断类。节点管理类报文主要包括DoIP报头否定响应、车辆信息获取、通信路由激活、诊断设备在线检查，如车辆识别请求/响应报文，路由激活请求/响应报文等；车辆信息类主要包括获取DoIP实体状态信息、车辆电源模式信息，如DoIP实体状态请求/响应报文，诊断电源模式信息请求/响应报文。诊断类主要包括诊断报文处理以及UDS数据交互，如诊断报文、诊断请求确认响应报文。

2.2 诊断流程

ISO 13400中定义了DoIP通信的标准流程，该流程中Tester（测试设备）和DoIP网关（边缘节点）通过IP网络连接，DoIP网关连接了子网（非以太网车载网络），Tester在当前网络拓扑中能够实现诊断DoIP网关或者子网络上的非DoIP实体的功能。诊断会话流程见图4。

图4 DoIP诊断会话流程

DoIP的整个诊断流程大致可以分为5步：车辆连接、车辆声明、TCP通信连接及路由激活、诊断数据交互、TCP连接关闭。

1）车辆连接：Tester和DoIP网关之间要建立正确的物理连接，通过车辆激活线激活DoIP网关的诊断功能，然后分配Tester及DoIP网关的IP地址，分配IP地址一般通过DHCP动态分配或Auto IP分配，主机厂可依据需求确定IP地址的分配方式，一般两种分配方式均要求实现。

2）车辆声明：车辆连接并上电后，车辆将自身的识别信息以广播形式自发3次于所在网络中。Tester若未获取车辆自动上报的识别信息，Tester需进行车辆信息识别请求报文的发送（identification request），如果网络中有车辆的话，车辆对这个车辆识别请求信息进行响应，发送车辆识别请求响应信息（车辆声明），测试设备便发现了被测车辆。车辆声明实现Tester和车内特定的DoIP实体的点对点连接，若网络中包含多个Tester、车辆、DoIP实体，通过车辆识别请求与响应报文的信息交互，即车辆发现过程可以找到特定车辆及DoIP实体。

3）TCP通信连接及路由激活：Tester端和DoIP实体通过TCP三次握手机制建立TCP连接，然后Tester与DoIP实体节点之间进行路由激活，来激活车载以太网诊断通信套接字（Socket），Tester发送路由激活请求报文信息至DoIP实体节点，确认Tester的逻辑地址、激活类型等信息是否合法。通过后，DoIP实体回复路由激活响应报文，实现路由功能的激活。

4）诊断通信：Tester发送诊断请求报文（DoIP Payload Type 0x8001），诊断请求报文中包含目标的逻辑地址，用来区分不同的诊断实体，边缘节点（DoIP网关）收到请求后回复诊断请求确认ACK（DoIP Payload Type 0x8002），告知Tester收到诊断请求，与此同时会发送诊断请求给车内所需诊断通信的DoIP实体节点。车内节点收到请求后回复诊断响应报文（DoIP Payload Type 0x8001），该响应报文经由DoIP网关转发给Tester。若边缘节点判定Tester发送的诊断请求有无效信息时（无效的目标地址，信息超长等），此时边缘节点会回复NACK（DoIP Payload Type 0x8003）。

5）TCP连接关闭，当Tester端退出诊断通信连接时，用于DoIP通信的套接字TCP_DATA Socket被关闭，DoIP诊断通信断开。

由于基于TCP协议传输数据时，数据包可能被其他人截取、篡改，这给数据传输过程中的信息安全带来了极大的挑战，因此最新版ISO 13400-2 2019协议将信息安全因素考虑进去，在整个DoIP诊断通信过程中增加了TLS（Transport Layer Security），即在建立TCP连接后，进行TLS握手流程，实现数据加密，再进行后续的路由激活、诊断数据交互。

2.3 应用场景

在ISO 13400-1中，描述了DoIP诊断典型的通信场景，主要描述了以下4种诊断连接方案。

1）单个测试设备与单个车辆之间的物理介质连接：此应用能够确保在进行IP诊断时，通信连接不会被其他车辆或设备干扰。

2）单个测试设备与单个车辆之间的网络连接：在多个车辆或多个外部测试设备都连接到同一个网络时，外部测试设备和车辆都应该拥有识别能力，能够在网络下识别出需要建立连接的目标，并拒绝接受其他车辆或外部测试设备的诊断请求。

3）单个设备与多辆车之间的网络连接：多辆车与单个外部测试设备网络连接，要求外部测试设备具备一对多连接的能力。

4）多个测试设备与单个车辆之间的网络连接：该应用方案要求车辆具备一对多连接的能力，能够清楚地区分诊断请求和对每个逻辑连接负责的外部测试设备的响应。外部测试设备能够判断当前车辆是否在与其他设备进行通信。

参照如上应用场景，在车辆诊断具体应用时可选取对应的设计方案，满足诊断场景需求，如售后模式车辆的故障检测、产品/工厂模式车辆ECU的软件更新、在工厂模式总装工位的检测、售后车辆远程诊断、OTA升级等。

3 协议测试

遵循目前国际上通用的V模式开发流程，DoIP协议测试分为ECU级与系统级测试，主要测试内容包括车辆诊断激活使能线测试、以太网UDS测试、DoIP数据报文格式、DoIP诊断流程、DoIP时间参数、刷写测试等，同时主机厂会在ISO标准需求的基础上依据系统设计需求及应用场景等，自定义相关测试内容。

3.1 ECU级测试

ECU级别测试，主要进行应用层诊断协议测试验证，针对上层协议ISO 14229协议，测试内容包含诊断服务和传输协议参数测试两部分。诊断服务测试，根据相关协议发送正确格式的诊断请求报文，验证ECU是否有相应的肯定诊断响应并判断其是否满足协议要求；错误协议处理机制测试，测试发送错误格式的诊断请求报文，验证ECU是否有诊断响应并判断其否定响应是否满足协议要求。诊断传输协议参数测试，测试诊断服务及故障处理机制中时间参数正确性。

采用Vector公司的工具链，搭建测试环境，把诊断数据库文件（CDD）导入至CANoe.Diva，添加封装好的安全算法dll（Dynamic Link Library）文件，设置数据流时间参数的判断标准等，单击Generate就生成了可供CANoe调用的自动化测试的工程文件，然后在CANoe中载入生成的Diva工程文件并运行测试工程即可进行诊断的自动化测试。测试完成后，CANoe自动生成测试报告。该方案执行DoIP的UDS测试，技术成熟可靠，测试充分、高效，本文不再赘述。

3.2 系统级测试

系统级别测试基于Vector测试工具链，通过CANoe软件开发测试脚本和测试工程，集成Vector硬件设备，完成系统测试环境的搭建。本系统VN5640实现以太网数据交互、采集，VT系统用于以太网链路的自动化故障注入，如以太网线断路、短路等。测试环境示意如图5所示。

图5 系统测试示意图

系统级测试，依据系统设计规范要求，对各系统基本需求实现的正确性、准确性、合理性进行测试，并结合不同的车辆运行场景，对系统在不同场景下的运行状态进行检测，考虑用户应用角度进行应用场景的测试验证、误用和滥用方面的测试，同时考虑主机厂自定义及一些特殊的需求开展相应测试。主要涉及的相关测试内容为：控制器软硬件版本读取检测，车辆发现请求、响应、车辆声明报文；车辆路由激活、诊断报文格式测试，预编程条件测试（电源模式、电池电量、车速、发动机状态、发动机转速、手刹等）；控制器正向刷写流程、控制器异常刷写、高负载及故障注入等应用场景测试验证等。

DoIP系统级测试是协议测试流程中的关键阶段，不仅需考虑协议基本需求的实现，在此阶段，需基于系统维度，结合功能需求的应用、车辆使用场景、非预期操作等开展相应的测试，验证系统正确性与稳定性。系统级测试主要是在集成所有相关ECU的情况下，对系统或子系统进行验证，查看是否满足设计时的规格要求。对于较为复杂的系统，为保障测试的覆盖率并节省测试时间，测试自动化工具选择和环境搭建十分重要。

4 测试示例

本示例为车辆识别响应报文格式及数据正确性的测试验证，测试车辆DoIP节点所发送的车辆识别响应报文的Protocol Version、Payload Type、Payload Length、DoIP Payload等是否满足设计需求。测试前，参照图5搭建测试环境，连接测试设备，完成CANoe软硬件配置。

系统上电，车辆激活线进行激活，使能网关DoIP诊断功能，系统处于正常运行模式中。采用CANoe工具，发送不携带DoIP Payload参数的车辆识别请求报文至网关节点，其中Protocol Version=0x02，Payload Type=0x0001，Payload Length=0。在CANoe软件中查看采集到的车辆识别响应报文，查看此响应报文中的各字段数值是否符合预期要求，见图6。

图6 车辆识别响应报文示例

CANoe采集网关节点发送的DoIP响应报文，查看并分析所采集的车辆识别响应报文，其中Protocol Version=0x02、Payload Type=0x0004、Payload Length=0x00000020、VIN、Logical Address、EID、GID、Further Action Required等字段数值，经分析符合预期要求。参照以上测试要求及步骤进行各DoIP节点ECU车辆识别响应报文数据格式及正确性的测试验证。

5 结束语

伴随着车辆电器功能的增加及对车辆个性化、科技化的需求，推动着车载以太网技术的迅速推广，随着技术的不断成熟，将成为整车下一代骨干网络应用的必然趋势。同时远程刷写、远程诊断等新技术的不断出现，基于车载以太网技术的DoIP协议必然应用到车辆诊断系统中，因此，DoIP通信和测试的必要性就越发重要。本文对车载以太网的DoIP诊断通信技术与测试进行了研究分析，为进一步深入开展相关测试工作奠定了基础。