继上篇《DoIP了解一下？》与大家分享了DoIP协议的报文格式、负载类型、应用场景等内容，也了解到完整的DoIP诊断会话主要包含：激活线激活——车辆发现——路由激活——诊断交互——关闭TCP_DATA_Socket，共五个步骤，今天主要给大家分享一下在整个DoIP诊断会话中需要重点关注的一些信息。

一、激活线激活

边缘节点（网关）的诊断通信需要通过硬线激活方式来激活，这主要是基于以下两个原因：

• 减少电磁干扰

• 降低DoIP边缘节点的功耗

那么在什么条件下边缘节点诊断通信处于激活/失活状态？

当诊断仪通过OBD口连接边缘节点，并在激活线上提供激活条件所需的电压（ISO 13400规定激活条件为：至少200ms以上5V及以上电压），才可以激活边缘节点诊断功能；当诊断仪断开连接，或在激活线上提供满足失活条件的电压（ISO 13400规定失活条件为：至少200ms以上2v及以下电压），边缘节点进入诊断失活状态而不能进行诊断通信。

ISO 13400提供了两种激活线电路示例， OEM可根据需求选择适用于自己车型的电路。综合来讲电路1对于电路2激活电压较高、抗干扰能力较弱、功耗相对较低，一般会建议在能通过RI、BCI等测试的前提下，选择电路1设计激活线路。

按照ISO 13400要求，当激活条件不满足时，外部诊断仪与边缘节点不能进行以太网通信，同时边缘节点不执行IP地址分配及车辆发现流程。

二、车辆发现

车辆发现过程一般包含两个过程：IP地址分配以及被诊断车辆信息获取。

1、IP地址分配

一般情况下边缘节点作为DHCP的Client，DHCP的Server集成在诊断仪中。在激活线激活之后，应立即执行IP地址分配过程。

2、车辆信息获取

DHCP机制执行完成之后，边缘节点应按照ISO 13400要求以广播方式发送3次（A_DoIP_Announce_Num）车辆声明报文，且第一条声明报文应在A_DoIP_Announce_Wait（0~500ms）时间内发出。

实际应用中并不能排除诊断仪接收不到车辆声明报文的可能，因此诊断仪可自行发出车辆信息请求报文以获取车辆信息，该报文可以组播或单播方式发出，这就要求边缘节点能接收并解析接收到的组播报文。

关于车辆信息获取过程一些关键的小Tips：

• 多次发送车辆声明报文的原因：车辆声明报文以UDP报文传输，无法保证报文正确传输，多次发送报文增加诊断仪至少接收到一条报文的概率，ISO 13400建议发送三次，实际发送次数可以按照OEM需求配置。

• ISO 13400中规定车辆声明报文应以受限广播地址（255.255.255.255）为目的IP地址发送。

• 车辆声明/信息响应报文中“Further action  required”字段意义：该字段值一般默认为0x00，若此字段值为0x10，则诊断仪需要使用0xE0的激活类型发送路由激活请求，即在路由激活过程中需要执行OEM定义的安全认证机制（身份认证、确认）。

三、路由激活

路由激活有三个核心知识点：路由激活、TCP_DATA Socket处理和在线检测。

1、路由激活处理过程

在DoIP通信网络中，通常使用逻辑地址来标识一个DoIP实体（DoIP节点、诊断仪），ISO 13400中定义了ECU及诊断仪的逻辑地址范围，同时规定OEM在设计阶段需要定义ECU支持的诊断仪逻辑地址（一个或多个）。进行诊断报文交互之前，诊断仪需要通过路由激活过程将自己的逻辑地址注册到通信的TCP_DATA Socket中。

ECU在接收到诊断仪发送的路由激活请求后，会按照下图描述路由激活的处理流程进行判别处理，若所有的判别项均满足要求，ECU会回复路由激活成功响应。

• 对于某些路由激活否定响应码（0x00、0x01、0x02、0x03、0x05、0x06），ECU在回复否定响应报文后需要关闭TCP_DATA Socket。

• 上述提到需要使用0xE0激活类型进行路由激活时，需要执行相应身份认证及确认机制，具体以何种方式实现ISO 13400并未详细定义，OEM可根据需求自定义该部分功能。

• 对于诊断仪执行路由激活有两个时间参数需要注意：诊断仪与ECU建立TCP连接后需在T_TCP_Initial_Inactivity（2s）时间内进行路由激活，否则ECU会主动关闭该连接；路由激活成功之后，ECU所能保持TCP_DATA Socket静止（无任何诊断交互）的时间为T_TCP_General_Inactivity（5min），超时后ECU会主动关闭TCP_DATA Socket。

  
  

2、TCP_DATA Socket处理

从上一篇介绍DoIP协议的推文中大家也了解到，由于以太网通信的特殊机制，一个ECU可以同时支持多个诊断仪连接，但在DoIP实体状态响应报文中，可以看出ECU所支持的并发Sockets数目是有限的（0~255），并且同一Socket同时仅可与一个SA绑定，因此在通过源逻辑地址、激活类型检测之后，需要执行Socket处理机制。

若在该流程中检测到当前激活的Socket已使用其他SA进行激活，ECU会立即停止Socket处理流程，并发送路由激活否定响应报文（响应码为0x02）。

3、在线检测

Alive Check主要作用是确定已注册并激活的Socket是否仍在被诊断仪使用，当ECU发送Alive Check请求后，若诊断仪还需要使用该Socket，则在其接收到Alive Check请求后，需要按照ISO 13400要求在T_TCP_Alive_Check（500ms）时间内回复相应的Alive Check响应，若超时未回复，ECU会立即关闭该Socket，即Alive Check未通过。

在线检测过程，基本上属于以下两种情况：

• 若路由激活处理流程中检测到当前激活的SA已注册到其他激活的Socket，ECU会在已激活socket执行Alive Check Single流程，若Alive Check未通过，当前路由激活成功；若Alive Check通过，ECU会立即停止Socket处理流程，并发送路由激活否定响应报文（响应码为0x03）。

• 若路由激活处理流程中检测到ECU所支持的Socket全被注册并激活，则ECU会执行Alive Check all流程，若有至少一个socket未通过Alive Check，则当前路由激活成功；若所有Sockets全通过Alive Check，ECU会立即停止Socket处理流程，并发送路由激活否定响应报文（响应码为0x01）。

04 诊断处理过程

路由激活完成之后，诊断仪即可以通过该TCP_DATA Socket与ECU进行诊断通信，同样在ECU接收到诊断请求后会按照下图所示流程进行判别处理，若所有判别均满足要求，ECU会回复诊断肯定响应及诊断响应报文，或者向目标网络转发该诊断请求。

对内部ECU进行诊断时，诊断否定响应相关报文应由谁来发送呢？

其实不难理解，这些否定响应报文皆由网关来发送。网关接收到诊断请求后会按照诊断处理流程图所示依次进行检测，若有检测项不通过，则网关会向诊断仪发送相应诊断否定响应报文，并丢弃该诊断请求。

响应码为0x02的报文过大DoIP首部否定响应与响应码为0x04的诊断报文过大否定响应的区别：报文过大（0x02）是指诊断请求中DoIP报文的负载长度超过网关所支持的DoIP报文大小；而诊断报文过大（0x04）是指诊断报文的长度超过目标网络或者ECU所支持的DoIP报文大小。这也就解答了我们经常被问到的一个问题：为什么经过DoIP首部检测之后还会有诊断报文过大的否定响应报文出现？

网关接收到诊断请求后，需要在A_DoIP_Diagnostic_Message时间内向诊断仪回复诊断肯定响应/否定响应报文，若超时诊断仪未接收到相应报文，应重发诊断请求。

网关一般是分为内外端口的，即外部OBD接口及内部通信接口，诊断仪始终通过OBD口与网关进行通信。在诊断仪对内部ECU进行诊断时，网关接收到该诊断请求并进行解析后，按照自己的诊断路由表通过内部端口将该诊断请求转发至目标ECU。

那么这个机制也带来了经常被问到的三个问题：

Q1：当诊断仪需要对内部ECU进行诊断时，网关何时与内部ECU建立TCP连接，并进行路由激活？

A1：具体何时建立TCP连接，进行路由激活，OEM应该根据自己的实际需求进行设计，不同的OEM在不同通信拓扑、设计方案下会有多种实现方式。

从诊断处理流程图中可以看到，网关需要从诊断请求中获取TA（即目标ECU），且后续有检测目标ECU是否可达/是否可路由到目标ECU的步骤。因此，网关即可在此步骤中与目标ECU建立连接，并进行路由激活，且将路由激活的结果作为此步骤的检测结果。

Q2：按照DoIP通信协议来讲，诊断仪与网关进行路由激活并发送诊断请求报文时使用的源逻辑地址均为诊断仪的逻辑地址，而网关与目标ECU进行路由激活时使用的是网关的逻辑地址，那么当网关将该诊断请求报文转发至目标ECU时，诊断请求中的源逻辑地址（诊断仪逻辑地址）对于目标ECU来说应该是未知的，因此目标ECU会回复相应的诊断否定响应报文。那么此环境下该采取何种路由激活方式呢？

A2：诊断仪在与网关外部端口进行DoIP通信时，网关既然可获取到诊断仪的逻辑地址，便可以在网关上做文章，即网关通过内部端口与目标ECU进行路由激活时使用诊断仪的逻辑地址进行路由激活，这样在后续诊断请求报文转发至目标ECU时，就可进行诊断通信。

Q3：诊断过程中，目标ECU需要发送诊断肯定响应报文吗？

A3：由ISO 13400可知，网关接收到诊断请求并正确解析后，会首先向诊断仪发送一条诊断肯定响应报文，然后再向目标ECU转发该诊断请求报文，假如目标ECU也发送诊断肯定响应报文，那么对诊断仪来讲会重复接收诊断肯定响应报文，不符合DoIP通信。

有以下两种方式可以解决：

1、从目标ECU的角度考量，关闭目标ECU的诊断肯定响应功能，此时由网关回复诊断肯定响应报文，目标ECU需回复诊断响应报文即可；

2、从网关的角度考量，不关闭目标ECU发送诊断肯定响应报文的功能，在网关处做一个诊断肯定响应报文的过滤机制，即网关自动丢弃接收到的诊断肯定响应报文。

目前国际上还没有一套完整、标准的DoIP设计方案，国内各大OEM都会结合自己整车功能需求来定义。DoIP协议涉及的内容还有很多，由于篇幅所限，今天我们就讲到这里啦。