DoIP从入门到精通，从理论到测试
DoIP属于比较前沿的知识，我们今天就来彻底撸一撸它，使劲一撸到底~DoIP优势
首先，我们要了解一下，啥叫车载以太网？它是怎么来的？哪门哪派，师承谁谁？在一个行业中，当一种新技术被开发和启用时，影响该技术成功的因素有很多。其中最重要的是该技术带来的益处以及自身成本。2004年宝马决定从2008年起在其开始量产（SOP）的汽车中引入车载以太网，引入以太网，会带来的应用场景变化如图：1、可有线也可无线
2、可通过网络使Tester端连接车辆端：
3、通过网络，一个Tester可以连接多辆车
4、通过网络，使多个Tester连接一辆车
DoIP协议框架
DoIP协议（DiagnosticOn IP---ISO 13400）定义将IP技术运用到车载网络诊断范畴的通信规则。其中包括两层含义：1、将IP技术应用到车载网络中，需满足车规需求；2、在诊断范畴，DoIP协议定义了从物理层（PhysicalLayer）到应用层（ApplicationLayer）搭建“通信桥梁”的规则（此处可类似CAN总线的TP层协议ISO15765-2）；将上述概念映射到OSI计算机七层模型：
DoIP所在的位置位于七层模型中第三层和第四层，如上图所示。其中运用到的IP协议：TCP/IP协议、UDP协议。整个ISO13400-2协议中定义的内容是规定了搭建“通信渠道”（Tester与ECU之间的通信渠道）的规则。TLS是2020版DoIP协议新增添的内容，主要目的是为了保证通信数据的安全性。本文将对整个“通信桥梁”的搭建过程做一个概述性的描述，具体步骤如下：1) 物理连接（Physically connection）；2) 车辆声明（Vehicle Discovery）；3) 通信建立（Connection Establishment）；4) 诊断通信（Diagnostic Communication）；DoIP物理连接
DoIP车辆声明
先解释几个新名词：1、DoIPEntityDoIP实体是能够实施DoIP协议功能的车载网络节点（i.e.DoIP节点或DoIP网关）2、DoIPGatewayDoIP网关是既实现了DoIP协议功能，并提供对其自身及其连接的车辆子网络的ECU访问权。3、DoIPNodeDoIP节点是实现DoIP协议功能并提供基于车载以太网对自身进行访问的权限，但不会将DoIP协议数据路由到车辆子网络的网络节点。4、DoIPEdge NodeDoIP边缘节点是ISO13400-3中定义的以太网激活线所连接的节点。以上是由于以太网引入至车载网络后，产生的专属名词，清楚后方便对整个DoIP协议以及整车E/E电子电气架构的理解。物理连接后，车辆进行自属信息声明过程做一个完整描述。一、基础信息DoIP协议标准由一个或多个DoIP实体实施，具体取决于车辆的网络架构。如下图是车辆网络架构示意图（功能视图），Client1（外部客户端）连接到DoIP边缘节点，并且可以连接到车辆内部网络中的Client2（内部客户端）。注意如果没有另外特殊说明，则假定DoIP客户端实体行为相同，无论他们连接到那个网络。注：在DoIP协议中（ISO13400）定义，ActivationLine（激活线）有且只能连接车内边缘节点。
在车辆声明中，有几个关于车辆自属信息的定义：v vehicle identification number (VIN)；VIN码在车辆中相当于人的身份证号一样，都具备唯一识别功能。ventity identification (EID)；EID是DoIP实体的唯一ID识别号，可以用于回复vehicleidentification request信息。比如该ID识别号可以由该网络接口的MAC地址充当。v group identification (GID);GID组标识号是一种去中心化方法，用于标识一个车辆内的多个DoIP实体。这意味着存在一个VIN/GID主设备（例如DoIP边缘节点），其他所有的DoIP实体在同步过程中都从该设备接受VIN/GID。由于此同步过程中通常需要一些时间（例如在将新的DoIP实体添加到车辆之后），因此会定义无效值，以供DoIP实体使用，直到VIN/GID完成同步。在ISO 13400协议中有规定：如果车辆中存在多个DoIP实体，并且不能始终保证为每个DoIP实体配置有效VIN的可用性，则每个DoIP实体均应支持车辆的GID同步。注：确保全局唯一GID的一种可能方法是使用GID主设备MAC地址。
v Logical address是分配给响应的DoIP实体的逻辑地址，逻辑地址用于诊断消息。物理逻辑地址唯一的表示通过DoIP网关连接的任何车内DoIP实体或车载网络的任何服务器上的诊断应用实体。在车辆声明过程中允许客户端DoIP实体将物理逻辑地址映射到IP地址。如下图是ISO13400协议中关于上述内容（VIN/GID/EID/Logicaladdress）参数值的范围
以及逻辑地址具体参数值划分：
在CANdelaStudio工具中（基于诊断需求规范编辑诊断数据库CDD或导出ODX的工具），基于车载以太网的DoIP接口关于Logicaladdress定义如下图：
应用场景：Tester连接车辆中边缘节点（网关），基于某个车内节点的逻辑地址发送诊断请求。因为这个地址是逻辑地址而不是车内节点的真实地址，这个时候需要网关在其中充当解析逻辑地址—真实地址Map关系的角色。Tester发送请求（基于逻辑地址），网关将逻辑地址转换成真实地址。由于将以太网引入到车载网络中，对于后续的远程通信（无线）带来了可能。因此这样设置逻辑地址也初步起到了保护信息安全的目的。二、车辆声明车辆连接到网络后，会自动发送三次车辆信息声明，若加入网络的测试设备（外部Tester）没有接受到待测车辆的声明信息，也可以主动发送请求，来获取要测试车辆的识别信息。如下是DoIP帧格式（DoIPheader structure）：
第0个Byte:介绍该帧使用的DoIP协议版本；第1个Byte：对协议版本按位取反值，该值与DoIP协议版本一起用作协议验证模式，以确保接受到格式正确的DoIP信息；第2-3 Bytes：包含有关解释通用DoIPHeader数据的信息（例如：网关命令、诊断信息等）。解释后续Payload数据的类型和作用；第4-7 Bytes：说明Payload数据帧长度。关于车辆信息对应的PayloadType如下表所示：
如下，是车辆声明和外部Tester主动请求获取车辆信息的示意图。需要注意的是车辆加入到网络后主动发送三次车辆信息声明（在配置好IP地址等信息后）的间隔时间。
而关于车辆声明过程中，有一个注意事项：GID同步。应用场景是当激活车载网络中一个新的DoIP实体功能后，需要将新的DoIP信息与车载GID同步。整个同步过程需要一定时间。如下图是GID同步以及车辆声明示意图：
关于PayloadType为车辆声明或车辆信息识别响应帧格式如下：
图中详细信息解释如下：
其中有两个点需要特别注意：1、Furtheraction required；2、VIN/GIDsync. Status。关于第一条，有无进一步要求在协议中做了详细定义（如下图）：
不同值对应不同的定义，预留位也保证了整个协议的灵活性。对于第二条，VIN/GID同步状态协议同样做了详细定义(如下图):
DoIP通信建立
一、通信模式通信建立区分：1、UnsecuredDoIP session;2、Secured(TLS) DoIP sessionA、UnsecuredDoIP session;此DoIP会话模式为没有经过安全认证。如下图所示，为了启动客户端DoIP实体与车辆中的DoIP实体之间的连接，第一步就是打开套接字（Socket）。这一步是在任何报文交换前必须完成的。因此DoIP实体需要提供处理传入通信请求的资源（Socket资源）。
为了激活初始化连接，Client需要发送路由激活请求报文（routingactivation request message）到DoIP实体。让Socket状态跳转到“路由激活”（routingactive相当于将此链路激活打通，可以进行诊断通信）。当诊断客户端不在需要此连接，需要将此Socket断开，就可以保证该Socket被其他新的请求使用。B、Secured(TLS) DoIP session关于经过安全认证后DoIP会话模式，其过程是增加了一步TLS安全认证（TLS源于互联网，稍后会专门有文章说明此内容）。当一个Socket连接建立后，TLS协议特定的握手初始化步骤由客户端DoIP实体和DoIP实体执行。TLS握手成功完成后，所有后续消息都通过此TLSTCP_DATA套接字交换。
同样道理，当DoIP客户端不需要安全的TCP连接，需要将该Socket连接释放，以便其他新的请求使用。其中Socket套接字，一端是IP地址，一端是Port口。二、路由激活（Routingactivation）格式首先需要清楚DoIP报文头框架结构：
如上图，是截取ISO13400协议关于DoIP报文头框架，其中最需要注意的地方就是Payloadtype。它决定了该帧报文的具体功能类型。回归到本文话题，关于路由激活的Payloadtype：
截取Demo中Trace数据如下：
在协议中，定义路由激活报文格式如下：
其中关于Routingactivation request activation types定义如下：
其中对于激活报文的作用类型分了好多种，也预留了相应位置，保证协议的灵活性；也预留给OEM自定义使用的权限。将路由激活请求发送至DoIP实体，DoIP实体处理机制如下：
根据处理机制，DoIP响应其请求响应格式如下
其中Routingactivationresponse code值详细定义如下表：
路由激活响应码值由不同的触发条件触发：当DoIP实体收到的路由激活报文请求中，源地址（sourceaddress）未知时，发送路由激活响应并标注路由激活响应码0x 00；当DoIP实体收到的路由激活报文请求时，如果sockethandler判断TCP_DATAsocket不可用时，发送路由激活响应并标注路由激活响应码0x 01；当DoIP实体收到的路由激活报文请求中，源地址与已收到的TCP_DATAsocket套接字中表连接入口不一致，发送路由激活响应并标注路由激活响应码0x 02；当DoIP实体收到的路由激活报文请求中，源地址已经在TCP_DATAsocket中注册并激活，发送路由激活响应并标注路由激活响应码0x 03；当DoIP实体收到的路由激活报文请求中，在路由激活请求之前，需要其他身份认证，发送路由激活响应并标注路由激活响应码0x 04；当DoIP实体收到的路由激活报文请求中，需要车辆内的确认，但此确认同时被拒绝，发送路由激活响应并标注路由激活响应码0x 05；当DoIP实体收到的路由激活报文请求中，DoIP实体不支持此路由激活类型（routingactivation type），发送路由激活响应并标注路由激活响应码0x 06；当DoIP实体收到的路由激活报文请求中，出现以下条件时，发送路由激活响应并标注路由激活响应码 0x 10（1）、路由激活请求报文中，逻辑源地址对于DoIP实体是可知的（2）、按照sockethandler要求，TCP_DATAsocket是可用的（3）、没有额外的认证步骤需要完成（4）、没有要求车辆确认当DoIP实体收到的路由激活报文请求中，出现以下条件时，发送路 由激活响应并标注路由激活响应码0x 11： （1）、路由激活请求报文中，逻辑源地址对于DoIP实体是可知的（2）、按照sockethandler要求，TCP_DATAsocket是可用的（3）、没有额外的认证步骤需要完成（4）、需要车辆内部的其他确认（e.g.需要确认组合仪表显示屏中的信息报文）DoIP车载网络拓扑
因特网协议（IP-Internetprotocol）是互联网规范中的基本协议，它仅是支持互联网正常运转“TCP/IP”协议簇之一。UDP协议也是TCP/IP协议体系中的内容（因为名称中只含有TCP/IP名称，往往会忽略UDP）。以太网引入到车载网络后，汽车也会慢慢进入车联网时代（或者物联网，万物互联），也必须将该协议簇运用起来。原因：1、在将以太网引入到车载网络前，这些协议已经经过时间验证（1980年就开始应用啦），故这些都是成熟的协议，不用浪费社会资源重新开发；2、带宽和速率可以满足要求；3、有良好的网络延展性。一般来讲，TCP/IP协议在汽车网络中的使用并不需要做特定的适配或修改，这也是选择基于以太网技术的通信网络为车内通信网络的主要原因。不过，在应用这些协议的时候必须考虑软件的占用空间（在汽车行业，成本永远是第一位）。IP的主要功能是寻址，既识别和定位节点地址（在IP中称为hosts），以及路由数据，将其从一个小小的网咯路由至可能横跨全世界的网络。在公共互联网中，IP地址必须是全球唯一的，还有可用于封闭/专用网络的IP地址范围，只要不进入全球网络，任何人都可以使用这些地址。这也是IP地址灵活的原因。静态地址和动态地址现在IT整个网络系统非常灵活，IT网络中节点数量和路由均在不断变化。支持这一点的关键之一是IP地址的动态分配，动态主机配置协议（DHCP）和域名系统（DNS）服务器应运而生并完美的满足了人们的需求。但是汽车车载以太网则完全不同，车载网络是一个几乎封闭的系统（由于引入以太网会有少许控制器，考量到网关的交通堵塞，可以跟外界设备直接连接，不过前提是需要安全认证），即使在车内网络中活动节点的数量也可能不同，但车内节点数量的上限可以预计并十分明确。静态地址分配：IP地址是在开发的过程中进行分配的。同一级别的ECU始终设定为相同的地址，而不受不同汽车的影响。显然，若在汽车中重复使用相同的IP地址，则可以从特定的地址范围中对其进行选择。伪动态地址分配：在这种情况下，ECU是在没有IP地址的情况下交付的，但是在组装时会收到一个静态IP地址，在分配了地址后，就没办法修改此IP地址。同意零件在汽车内多次组装时，将会遇到这情况（类似于ISO13400 中Auto IP）。动态地址分配：当车辆或者车辆的部件与外部部件/车外部的网络，如诊断测试以或互联网进行通信时，将用到此方法。直接将汽车连接到外部世界的ECU将使用位于外部的DHCP服务器分配给他们IP地址，这些连接车内其他ECU的“端口ECU”可以请求外部DHCP服务器分配更多的临时IP地址。多重地址分配：在这种情况下，一个ECU使用多个IP地址。当ECU需要使用不同的地址时，就需要采取此方法。如诊断用例，在这种情况下，汽车内部网络使用静态IP地址。外部测试仪不知知道汽车内部地址结构，内部网络也不能参与与外部通信。在测试时，ECU附加的IP地址由测试以所属外部网络的DHCP分配，以完成与外部诊断设备的通信。在适当的情况下，可以通过分配给第三层上通信节点多个IP地址实现流量分离（不仅仅是在第二层使用VLAN）。在如下图示例中，诊断仪仅使用了动态IP地址B和C，因此只有在诊断系统连接并且想要直接与内部组件通信时才会分配给他们。
如上图，整个系统可供参考内容如下：1、车载DoIP节点可有多个IP地址，不同IP地址适用于不同范畴:比如此例中动态IP地址用于诊断，静态IP地址可用于车内节点互相通信。此处也可以使用VLAN，将不同目的分不同的VLAN。2、关于DHCP server存在方式：A. 对于车身网络，边缘节点可以充当DHCPServer角色，可由它给车内DoIP实体动态分配IP地址；B. 对于车身外网络，此时诊断仪若采取动态IP地址方式，此时DHCPServer由外部第三方充当。DoIP网络安全措施
在车载以太网络中，影响网络安全的因素主要有：1、广播通信：在广播消息、组播消息以及目的地址不明确的消息传播时会使用广播的传递方式，主要处于这个网络就可以接受到对应的广播报文；2、缺乏相应措施控制车载节点在车载网络中发送过多流量，工程师在设计ECU时应考虑限制自身发送过多流量，而除了设计错误和设备故障，安全策略主要用于抵抗网络攻击产生的较大流量。仅是一个节点发送的大量广播和过量消息就可以引起车载网络控制器中MAC层服务的瘫痪和故障，此外，随处可侦听的广播也是安全隐患（无法区分广播报文接受者用意是好还是坏）。因此交换机的安全保障主要分为以下两点：1、禁止接受过多流量；2、禁止发送过多流量。对应上述需求，有以下措施可以借鉴：一、VLAN在构建车载网络数据信息时，可以根据娱乐、控制和尽力而为流量的区别来对信息进行分类。也可以通过VLAN技术做出了详尽描述，该技术的核心是在以太网中虚拟分割出许多子网，属于同一个子网的节点拥有形同的VLANID。使用VLAN技术后，即使是广播信息，或是物理连接于统一交换机的不同节点，也可以通过VLANID进行消息的隔离从安全的层面考虑，VLAN技术不仅可以隔绝虚拟网络之间的消息，还可以减少广播范围（避免广播风暴）。此外，VLAN隐藏了过滤/丢弃数据包的功能：携带有交换机不支持的VLAN标签的数据包，将被抛弃（这个功能一般没有被提起）。如果交换机接受的数据不含有VLAN信息，交换机可以直接将其丢弃或根据端口、协议、报头等赋予该数据VLAN标签。
如下图：不同应用场景设置不同VLANVLAN技术不仅有助于网络安全的提升，还可以简化不少问题：数据记录和测试：由于VLAN的划分与设备的物理位置无关，它为ECU的网段分配提供了极大的灵活性，有助于日益增长的汽车以太网络中的数据记录和分析。2. 性能：可以将特定的通信分配至特定VLAN，并在交换机中进行优先处理。如上图中对汽车以太网的流量隔离做出了诠释。在此例中，“汽车交换机”作为对流量进行隔离的ECU。此ECU可以放置在汽车部位任意位置，每个端口均配置了VLAN过滤策略。在交换机接受到诊断流量时，会根据诊断流量的VLAN将此流量转发至相应节点。如此操作简单有效，如同建立了一个防火墙，对车载信息安全提供了更大的可能性。对于汽车上其他为外部接口而言，VLAN同样能够发挥作用。进出汽车的流量可以在同一个接口处分别打上或去除VLAN标签。在ECU内部，只有特定区域才有权对标记的数据进行处理，此方法有效隔离了数据。汽车制造商应在开发过程中重视VLAN的开发。二、 其他交换机配置交换机的主要任务是读取接受数据的目的地址，找到目的转发端口后，将数据发送出去。因此，交换机内部存在一个转发表，该表记录了接收到数据的源端口和MAC地址。当接受到的数据需要转发到转发表中存储的目的MAC地址时，交换机只要根据转发表进行转发即可。另外，当转发到未知目的地址的情况时。这时，交换机会向所有端口发送数据（广播）。上述也是交换机的工作原理。许多黑客利用交换机工作原理，不断向交换机发送未知目的地址的数据包，使得交换机不断广播，导致网络瘫痪。当然可以采取一些措施避免黑客进行上述攻击，如：1、设置交换机仅在启动阶段只进行一次地址学习，或者完全关闭交换机的地址学习功能，改用静态IP地址的映射。同样可以使用用这些方法建立ARP地址表，完成MAC地址和IP地址的映射。对于汽车这样一个静态网络，完全可以采用这些方法建立地址表，还可以根据地址条目数量、地址范围和变化频率对地址学习进行限制。2、还可以建立组播消息的过滤策略。交换机会将组播消息转发至满足组播要求的端口，因此只有同组内成员可以接受都组播消息。但是，同样需要对非组内成员接受到组播消息的行为进行会话，可以将其抛弃或者转发至特定地址。3、交换机现在还可以使用强制认证策略，使得端口处于禁用状态，直到成功认证后方可启用。网络节点的认证需要由交换机固件或直连到交换机的微控制器完成，这样可以保证快速启动。密钥管理密码学的基本原理要求：不能将同一密码用于不同功能或者设备，且同一密码的使用时间不宜过长。
不同的过程，如数据认证、密钥交换和数据加密应分别使用各自的密码。这样，在某一密码收到损害时，如数据加密，仍可以正常地通过密钥交换更改数据加密的密码。保证密钥安全的方式有：宣布照顾密钥的使用时间，保证它仅用于有限的数据；跟还有不同地汽车功能和适用范围进行分类，各类通信分别使用不同地密钥。汽车不同ECU的密钥分配是一项十分复杂的工作，在IT网络中，密钥分配有相关规范。由于这些密钥管理办法消耗大量资源且需要一个线上的授权服务器，无法对实时和速度保证，因此不适用于汽车网络。在汽车网络中，可以由一个专用于ECU作为密钥master，给网络内的其他ECU分配密码。实现上述想法的基本思路为：密钥交换是通过对称加密实现的，由诊断请求、定期或者外部的服务后端服务器触发。密钥master是唯一与后端服务器进行密钥相关通信的ECU，当然也可以使用非对称密码学方法来完成密钥管理。上述内容，是将传统以太网中应用到信息安全策略移植到车载以太网应用中，多方面、分层级保护信息安全措施。DoIP诊断通信
DoIP协议在搭建通信桥梁过程中，使用到的就是经典互联网通信协议—UDP/TCP/IP等（涉涉及到信息安全，最新版DoIP协议添加了TLS-TransportLayer Security内容），通过一定的规则，保证通信过程畅通无阻的进行诊断通信即可。当通信桥梁搭建成功后，接下来就是进行其应用——诊断通信。首先GenericDoIP header structure格式如下：
获取信息：Payload type长度为2Bytes；Payload length中用于标识长度的位数是4Bytes，最长长度是4294967 295 Bytes心细的同行们会发现，一帧以太网报文最大长度1500Bytes，DoIP帧长度为何与之不一致？
其实由上图可知，以太网帧由TCP/IP协议簇传输后，对于一帧DoIP帧可以由多帧以太网组成。而关于诊断通信Payloadtype为: 0x 8001 / 8002 / 8003：
其中Payloadtype 8001标识Tester发送诊断请求；Payload type 8002 标识DoIP实体（边缘节点）收到诊断请求（Positiveresponse）；Payload type 8003 标识DoIP实体（边缘节点）经过DoIPdiagnostic message handler处理，未达到要求返回的否定响应（Negativeresponse）；1、diagnosticmessage——PayloadType 8001报文格式如下：
通过CANoe诊断真实ECU报文格式截图如下：
其中：Payload type 0x 8001Source address 0x 0E00Target address 0x 0201Diagnostic request 10 01响应报文截图：
其中：Payload type 0x 8001Source address 0x 0201Target address 0x 0E00Diagnostic response 50 01注意点：不管是诊断请求还是诊断响应，对应的Payloadtype都是0x 80012、diagnosticmessage positive acknowledgment——PayloadType 8002报文格式如下：
其实是告知Tester，边缘节点已经收到发送的诊断请求。
3、diagnosticmessage negative acknowledgment——PayloadType 8003报文格式如下：
其中重点是NACKcode，告知Tester为什么给与diagnosticmessage negative acknowledgment，不同Code值对应不同的含义：
有相应的处理机制来判断给与什么NACKCode：
1、当边缘节点接受到诊断报文中包含的源地址不是TCP_DATAsocket中激活使用的源地址时，发送NACK(code 02) 并关闭当前TCP_DATAsocket；2、当边缘节点接收到诊断报文中包含的Targetaddress未知时（e.g.该DoIP实体没有连接到DoIP网关），发送NACK(code 03)；3、当诊断报文中包含的数据超过了目标网络或者目标DoIP实体所支持的最大长度： 当目标网络是CAN网络，一帧报文长度超过4095 bytes，而对于功能寻址方式，对应的数据长度更加苛刻，不能超过7 bytes，去掉PCI，一帧经典CAN数据域是7 bytes目标DoIP实体基于自身芯片能力定义的所能支持的最大数据长度；当超过上述描述的长度，会发送NACK(code 04)；4、当诊断报文中包含的诊断信息长度太大，没办法将其复制到目标缓存区（e.g.传输协议拒绝提供必要缓冲区的请求），会发送NACK(code 05)；5、当诊断报文中指向当前无法访问的设备时（可以是临时网络重组或物理故障），会发送NACK(code 06)；6、当诊断报文中包含的targetaddress是未知网络或传输协议出现error，并且先前NACKcode没有覆盖该错误，会发送NACK（code 07/08）。对于整个通信，过程如下：
1、外部诊断设备发送诊断请求至边缘节点（网关），这个时候DoIP网关根据实际情况，给与ACK/NACK。（1）、若DoIP网关给与ACK（Payloadtype 8002），DoIP网关同时将该诊断请求发送至由逻辑地址映射的实际车内节点；（2）、若DoIP网关给与NACK（Payloadtype 8003），此时通信停止，DoIP网关不会将诊断请求发送至车内节点。2、若车内节点收到了DoIP网关发送的诊断请求，基于请求给与相应。注意此时Payloadtype 为 8001。具体Trace数据显示如下图：
如何用CANoe基础功能测试DoIP
伴随着以太网引入到车载网络，通过相应工作实现DoIP通信和测试的必要性就越发重要。本文简单介绍下在CANoe中进行DoIP通信的相关设置。一、协议基础在DoIP过程中都是基于TCP/UDP进行诊断报文传输，DoIP中Payload诊断服务数据遵循传统的诊断协议如UDS ，因此DoIP 并非是一个诊断协议，准确来说是一个扩充的传输层协议，相当于基于车载以太网关于诊断搭建一个通信的桥梁。ISO 13400 中定义帧格式如下：
ISO 13400 中定义了 DoIP 通信的标准流程，该流程保证了基于车载以太网进行诊断通信的稳定性：
该示例中 Tester 和 DoIP 网关（边缘节点）通过 IP 网络连接，DoIP 网关还连接了子网（非以太网车载网络），Tester 在当前网络拓扑中能够实现诊断DoIP 网关或者从子网络上的非DoIP实体的功能，通信过程描述以诊断子网上 非DoIP实体为例。1) 物理连接(Connection)：Tester 和DoIP 网关之间要建立正确的物理连接，然后通过Activation Line激活DoIP网关的诊断功能，并根据需要分配 Tester 及 DoIP 网关的 IP 地址：A：静态IP地址；B：DHCP动态分配；C：Auto-IP.2) 车辆声明(Vehicle Discovery)：诊断网络的范围:A：Tester 和车内单独某个 DoIP 实体的点对点连接；B：在一个复杂的分布式网络中，包含多台测试设备、多个车辆、多个 DoIP 实体的情况。通过车辆发现过程可以找到特定车辆及 DoIP 实体。3) TCP 通信连接( TCP Socket)以及路由激活：Client端（Tester） 和Server端（DoIP 实体）建立 TCP 连接。Tester 发送路由激活请求，DoIP 实体确认 Tester 的逻辑地址、激活类型等信息是否合法，若没有Specific use case（信息安全）Tester 就可以进一步发送诊断请求报文。4) 诊断通信请求：Tester 发送 DoIP 诊断请求报文，诊断请求报文中包含目标的逻辑地址，逻辑地址用来区分不同的诊断实体。出于对车内节点信息安全考虑，只有边缘节点有能力解析逻辑地址和车内节点实际地址的之间的Map关系。5) 诊断报文通信ACK/NACK：DoIP 网关在诊断请求报文被处理并复制到目标网络传输缓冲区之后立刻发送诊断确认信息。6) 诊断报文通信响应：Server端接收到诊断请求之后会回复诊断报文响应，该响应经由 DoIP 网关转发给 Tester。二、物理连接DoIP 物理层协议采用：IEEE 802.3 100BASE-TX ；IEEE 802.3 10BASE-T。因此原则上可以直接使用 PC 的网卡进行通信。但是因为使用CANoe作为测试上位机，建议使用 Vector 硬件接口卡 VN56 系列， 或是配合 VT 系统使用的板卡VT6306，原因如下： 1) ISO13400 协议本身只提及使用传统以太网物理层，但现在越来越多的车内以太网节点本身集成了DoIP 功能，而其物理层形式一般只支持100/1000BASE-T1，这种情况无法使用传统以太网接口设备与之建立通信。 2) 避免出现因为 PC 的防火墙配置（无法进行 TCP 连接，端口或 IP 地址被阻止）造成无法通信的的问题。3) 避免 OS 或任何 Windows 应用程序通过 DoIP 接口发送干扰消息。 4) 报文时间戳精度更高（8ns）。 5) VN5610A 或或 VN5640 还提供了两路高速 CAN/CAN-FD，可以同时进行 CAN 和 Ethernet 通信，方便实现诸如（UDS）CAN/Eth 网关功能。 6) 为了确保与其他 Vector 硬件设备接口的同步（软件同步精度 50us，硬件同步精度 1us），这一点对于网关测试非常重要。 7) VN5610A 或 VN5640 还提供了数字/模拟 IO 通道，可用做 DoIP 激活线使能或者禁用 ECU 的 DoIP功能。 三、网络设置在CANoe中，正确的网络配置是实现DoIP 通信的前提，如下图界面设置网络节点用于通信的TCP/IP Stack，如 MAC 地址、VLAN Tag、网络层协议类型 IPV4/IPV6、IP 地址、子网掩码等信息。
在配置前确认：1) DoIP 实体通信网络是否使用 VLAN Tag？ 2) DoIP 实体通信网络是静态 IP 地址还是 DHCP 服务器获取的 IP 地址？如下在CANoe中配置几种常见的使用场景：没有VLAN，采用静态IP地址：
采用VLAN（ID=2）,采用静态IP地址
不采用VLAN，动态分配IP地址（DHCP）
采用VLAN，动态分配IP地址（DHCP）
以上是在CANoe中物理连接需要设置的内容。四、上位机诊断参数配置DoIP 的诊断相关配置也在 “Diagnostic/ISO TP Configuration“ 窗口完成。在Ethernet 网络上添加诊断描述文件（e.g.CDD）即可进行诊断参数进行相关设置。“DoIP/HSFZ Settings“ 处可设置 DoIP 通信的基本参数：
1、CANoe Tester 的逻辑地址、激活类型、ECU 的物理逻辑地址和功能逻辑地址；2、指定CANoe Tester 使用的网络接口和IP 地址；3、如果没有设置， Tester 会正常发送车辆识别请求(Vehicle Identification Request)，如果正确指定 DoIP 实体 IP，则 Tester 将跳过 Vehicle Discovery 过程。 当然除了上述可设置的属性，CANoe还可以设置很多。五、DoIP 通信过程示例 完成上述配置工作之后，打开诊断控制台 (Diagnostic Console) 窗口 ，发送一条诊断请求如 ”DefaultSessionStart“ ，在 Trace 窗口中就能看到 DoIP 的通信报文数据了。
trace 显示了静态 IP 地址的情况下，Tester 与 ECU 进行 DoIP 通信的过程。 1) CANoe Tester 发送车辆识别请求。ECU 在建立 TCP 连接和路由激活之前，使用车辆声明报文 (Vehicle Announcement Payload type=0x 0004) 来响应此车辆标识请求；2) 建立 TCP 连接(TCP Connection)，由 CANoe Tester 发起请求并与 ECU 建立 TCP 连接；3) 路由激活(Routing Activation)，由 CANoe Tester 发起请求，ECU 检查逻辑源地址、激活类型等信息是否正确；4) Tester 发送 DoIP 诊断请求；5) ECU 发送诊断请求接收确认信息ACK；6) ECU 回复诊断响应（若网关回复NACK，便没有诊断响应）。如何通过CAPL测试DoIP
1、首先在CANoe新建Ethernet工程：
在CANoe “Simulation Setup”中新建CAPL Test Module：
在此例中采用CANoe自带的DoIP.dll文件中内嵌DoIP的函数，添加步骤如下：
其添加路径：C:\Program Files\Vector CANoe14.0.83\Exec32
2、在CANoe中设置通信参数（TCP/IP Stack）在上文中通过诊断控制台发送DoIP诊断请求时，设置Tester相关通信参数
在这里决定用Individual TCP/IP stack，VLAN ID为2，IP地址192.168.1.100
3、在CAPL Browser中编辑编辑相应脚本首先获知待测ECU以及Tester的逻辑地址（从诊断需求规范或者CDD &ODX数据库中）：
并在CAPL工程中定义：const dword TesterLogicalAddress = 0x0E00; const dword vehicleLogicAdd = 0x0201;在测试工程启动时，因为该测试模块加载了DoIP.dll文件，为使用该dll文件充当Tester角色，使用“on preStart”，定义如下函数：on preStart{ DoIP_InitAsTester();}确保DoIP.dll文件不会被充当车辆并尝试链接已配置的ECU：void MainTest (){ ConnectVehicle(); }testfunction ConnectVehicle(){ DoIP_ConnectToVehicle();}连接到车辆后，接下来就可以进行诊断通信：variables{const dword TesterLogicalAddress = 0x0E00;const dword vehicleLogicAdd = 0x0201;}on preStart{ DoIP_InitAsTester(); DoIP_SetTesterLogicalAddress(TesterLogicalAddress);}void MainTest (){byte buffer[2]={0x10,0x01};ConnectVehicle(); testWaitForTimeout(5000); DoIP_DataReq( buffer, 2, vehicleLogicAdd, TesterLogicalAddress); testWaitForTimeout(2000);}testfunction ConnectVehicle(){ DoIP_ConnectToVehicle();}就可以进行诊断通信：这里发现一个有趣的现象，Tester是以广播的形式向外发送Vehicle Identification request，
ECU回复响应
这里会存在一个较为特殊的情况，待测ECU有可能出于安全考虑吧，不支持广播类型报文，在DoIP.dll文件中有一个函数：DoIP_SetVehicleAddress：该函数作用：This function is intended mainly for tester nodes in orderto set the target vehicle address.具体含义可查阅CANoe中Help：
on preStart{ DoIP_InitAsTester();DoIP_SetVehicleAddress('192.168.1.2');DoIP_SetTesterLogicalAddress(TesterLogicalAddress);}运行后如下图，Tester就不会再以广播形式发送Vehicle Identification request，会直接发送Payload Type为0005/0006Routine Activation Request/Response
整个Demo 工程如下：includes{}variables{const dword TesterLogicalAddress = 0x0E00;const dword vehicleLogicAdd = 0x0201;}on preStart{ DoIP_InitAsTester(); DoIP_SetVehicleAddress('192.168.1.2'); DoIP_SetTesterLogicalAddress(TesterLogicalAddress);}void MainTest (){byte buffer[2]={0x10,0x01};ConnectVehicle(); testWaitForTimeout(5000); DoIP_DataReq( buffer, 2, vehicleLogicAdd, TesterLogicalAddress); testWaitForTimeout(2000);}testfunction ConnectVehicle(){ DoIP_ConnectToVehicle();}对于DoIP测试，在协议中有相应的测试点：在发送发送DoIP诊断帧请求时，不同的触发条件触发不同的NACK Code值，以下是对DoIP Payload整体的判断：
而关于Payload Type 8001的诊断请求，同样也有相应的判断：
如上对应的测试点都可以作为DoIP功能的测试点进行测试。总结
DoIP的理论需要学习，DoIP的测试工作需要加强，如有相关需求的朋友们，可以后台联系我们，我们有专业级的讲师，可以为您提供相关的理论和测试方面的培训指导。【推荐】