定时和通信参数
下表包含了DoIP特定的通信参数，包括超时值和各类型的DoIP消息特定的性能要求，另外，诊断协议会话层时序被映射到DoIP消息上
诊断协议会话层时序被映射到DoIP消息上，这句话要细品，诊断协议是通过DoIP消息实现的，所以它的会话层时序当然会映射到DoIP消息上，这个映射，你可以把它理解成反应，或者说是作用在DoIP消息上
下表中的注释一列，是我自己的进一步解析
| 时间参数 | 描述 | 参数值 | 注释 |
|---|---|---|---|
| A_DoIP_Ctrl | 此超时是指外部测试设备等待对先前发送的UDP 消息的响应的最长时间。这包括等待和收集对先前广播的多个响应的最长时间（仅限UDP） | Timeout:2s | 这指的应该是外部测试设备通过UDP报文向DoIP实体发送车辆信息请求消息（单播或广播），到收到DoIP实体回复的车辆信息响应消息的最大时间 |
| A_DoIP_Announce_Wait | 此时间参数指的是DoIP实体等待响应车辆识别请求的初始时间和DoIP实体在配置有效IP地址后等待发送车辆公告消息的时间。该定时参数的值应在最小值和最大值之间随机确定 | Random time:0…500 ms | 这个时间参数定义了DoIP实体在收到车辆识别请求消息后，到发送车辆识别响应消息的时间，或者是DoIP实体在配置完有效IP地址后，到发送车辆公告消息的时间，反正就是定义了DoIP实体发送自己车辆信息的这个响应能力，这个时间是一个范围值 |
| A_DoIP_Announce_Interval | 此时间参数指的是在配置有效IP地址后，由DoIP实体发送的车辆公告消息之间的时间 | Delay time: 500 ms | 指的是DoIP实体主动发的三次车辆公告消息，这三次消息之间的时间间隔，固定是500ms |
| A_DoIP_Announce_Num | 该参数指的是配置有效IP地址后，DoIP实体发送的车辆公告消息的数量 | Repetition: 3 times | 这个没什么可讲的，DoIP实体发送的车辆公告消息会主动发3次 |
| A_DoIP_Diagnostic_Message | 这是接收到DoIP诊断消息的最后一个字节和传输确认ACK或NACK之间的时间。超时过后，请求或响应将被视为丢失，并且可以重复请求 | Performance time:50 ms Timeout: 2 s | 这个参数指的是DoIP实体接收到DoIP诊断消息的最后一个字节到传输确认ACK或NACK之间的时间，性能时间50ms，超时时间2s，超时未发ACK或NACK，则外部测试设备认为发送的DoIP诊断消息丢失，可以重复发送 |
| T_TCP_General_Inactivity | 此超时指的是TCP_DATA套接字（未接收或发送数据）在被DoIP实体关闭之前不活动的最长时间 | Timeout: 5 min | 指的是DoIP实体要为每个TCP_DATA socket实现一个单独的general inactivity timer计时器，当该socket长时间未接收或发送数据时，处理程序将会强制关闭这个套接字 |
| T_TCP_Initial_Inactivity | 此超时指TCP_DATA套接字建立后直接不活动的最长时间。在未激活路由的指定时间之后，DoIP实体将关闭TCP_DATA套接字 | Timeout: 2 s | 这个超时指的是DoIP实体在与外部测试设备之间建立TCP连接后，到接收到外部测试设备发送来的路由激活请求报文的最大时间。如果超过了这个时间，socket处理程序就会关闭TCP_DAT socket |
| T_TCP_Alive_Check | 此超时是指DoIP实体用TCP_DATA套接字发送Alive Check Request后等待Alive Check Response的最长时间。因此，如果底层TCP协议栈无法传递Alive Check Request消息，则计时器也将结束 | Timeout: 500 ms | 这个超时指的是DoIP实体的某个TCP_DATA socket在发送alive check request后，等待外部测试设备发送的alive check response的最大时间。这里特定强调了如果DoIP实体的TCP协议栈问题造成alive check request消息未发出去，timer仍然是工作的。这里没有说明超时后会怎么样，可以反推一下，如果外部测试设备发送了响应消息，timer就会重置，就说明外部测试设备是活动状态的，那么socket处理程序就不会关闭TCP_DATA socket。那如果超时了，就表示DoIP实体未收到响应，就说明外部测试设备不在线，那么DoIP实体就会关闭这个套接字 |
| A_Processing_Time | 这个超时是指外部测试设备发送不需要响应消息但DoIP实体可能需要一些时间来处理的DoIP消息之间的间隔。因此，在向同一个DoIP实体发送另一个请求之前，外部测试设备必须至少等待A_Processing_Time | Timeout: 2 s | 这里强调了不需要响应消息的DoIP消息间发送时需要时间间隔，目的是为了让DoIP实体有足够的时间处理DoIP消息。而对于有响应消息的DoIP消息，外部测试设备肯定是在接收到响应消息后才会发送下一条DoIP消息。响应消息本身就意味着DoIP实体已经处理好了DoIP消息，所以有响应消息的DoIP消息之间，不需要时间间隔 |
| A_Vehicle_Discovery_Timer | 这是每辆车的车外定时器。此计时器指的是车辆在所有DoIP实体之间执行VIN/GID同步所需的时间 | Timeout: 5 s | 此计时器是从DoIP实体发送车辆公告消息或车辆识别响应消息时启动的 |
逻辑地址
“
本节规定了逻辑地址的结构和用法，例如，用于诊断消息。物理逻辑地址是唯一代表任何DoIP实体内或通过DoIP网关连接的车载网络的任何ECU上的诊断应用层实体。功能逻辑地址用于将消息寻址到车辆内的一组诊断应用层实体或全部诊断应用层实体。对于功能寻址，外部测试设备可能必须发送多个IP数据包才能到达由功能逻辑地址寻址的所有ECU。没有通过单个IP地址寻址多个DoIP实体的机制。对于DoIP网关，接收到功能寻址的诊断消息意味着在连接的车载子网络上进行多播或广播。
”
这里插个话题，看的文档规范越多，发现有几点感触：
-
从英文到中文的翻译，有时候各种翻译工具并不能完美契合，需要我自己先理解这句话要表达的意思，重新组装。在这个过程中，对文档的理解程度和对语言的表达能力，都有很大的帮助
-
英文有很多的长难句，不止考验自己对文档的理解能力，还考验自己对语句的拆解和重组的能力
-
解析文档，不能只是简单的翻译，对于长难句，要拆开分解，并重新用自己能看得懂的语句描述清楚。对于重点部分，需要标注红色记号，并进行二次解读
-
阅读文档不是关键，分析文档也不是目的，阅读并分析，最终让自己理解并掌握，进而能够输出一些对其他人起到帮助的自己的独有的见解，这才是我愿意花费大量时间在这些枯燥的文档上的意义
回归正题，我们解析一下上面那段话：
“
物理逻辑地址是唯一代表任何DoIP实体内或通过DoIP网关连接的车载网络的任何ECU上的诊断应用层实体
也就是说不管你是DoIP实体，还是DoCAN ECU节点，只要你具有诊断功能，物理逻辑地址就是你的诊断应用程序的唯一标识 ”
“
没有通过单个IP地址寻址多个DoIP实体的机制
不同的DoIP实体配置有不同的IP地址。这里主要怕的是有人会想到广播或组播地址，DoIP通信是通过TCP协议传输，TCP协议是没有广播或组播这两种方式的 ”
“
对于DoIP网关，接收到功能寻址的诊断消息意味着在连接的车载子网络上进行多播或广播
网关接收到DoIP消息，根据目的逻辑地址是功能逻辑地址，把消息数据复制多份，发给其他自网络上的节点 ”
下表定义了逻辑地址的寻址方案
不过下表中的寻址方案并未对各个ECU的各个地址进行标准化。因此，如果外部测试设备想要确定ECU的相关功能，则需要通过其他方法来执行，例在应用层。而不是通过获取ECU的地址然后用此表来判断ECU有哪些功能
我比较感兴趣的是表格下方的abcd四段话：
a. 当在路由激活请求中使用这些地址时，车辆中其他正在进行的诊断通信可能会中断，并且其他正常功能可能会受到影响（例如，返回到故障安全行为）
b. 当在路由激活请求和诊断消息中使用这些地址时，路由激活最初可能会由于其他正在进行的诊断通信而延迟，然后可能会被中断并且其他正常功能也可能会受到损害（例如，返回到故障安全行为）
c. 这些地址不应该由不是设计给车辆组成部分使用的外部测试设备使用。这包括通过诊断连接器执行诊断通信的任何插入式设备
d. 这些地址应由安装在车辆中并保留在车辆中的设备使用，以便通过诊断通信进行定期数据检索。DoIP实体可以拒绝/延迟接受来自此类设备的路由激活请求，以完成正在进行的车辆内部通信，从而避免车辆的正常运行受到影响
传输层服务
General information
所有传输层服务都具有相同的一般结构。为了定义服务，指定了三种类型的”服务原语”：
-
服务请求原语，由更高的通信层或应用程序使用，以传递需要传输到网络层的控制信息和数据
-
服务指示原语，由DoIP层使用，用于将状态信息和接收到的数据传递给上层通信层或应用程序
-
服务确认原语，由DoIP层使用，用于将状态信息传递给更高的通信层或应用程序
该服务规范不指定应用程序编程接口，而仅仅是独立于任何实现可能的一组服务原语的设定
也就是这个服务规范只提供了一种方案设定，并没有规定任何实现的应用程序的编程接口必须为怎样怎样
下图是诊断通信的一个示例
可以看出，这是应用程序和DoIP层之间传递控制信息和数据的一种服务，通过调用接口函数，发送服务原语
所有DoIP层服务都具有相同的通用格式。服务原语的写法如下：
其中
-
“service_name”是服务的名称，例如_DoIP_Data -
“type”表示服务原语的类型 -
“参数A，参数B，[参数C，…]”是作为服务原语传递的值列表的DoIP_SDU。括号表示这部分参数列表可能为空
“
SDU，service data unit
”
服务原语定义了服务用户（例如诊断应用程序）如何与服务提供者（例如DoIP层）合作。ISO 13400的这一部分规定了以下服务原语：”请求”、”指示”和”确认”
-
使用服务请求原语（service_name.request），服务用户向服务提供者请求服务
-
使用服务指示原语（service_name.indication），服务提供者将网络层的内部事件或对等协议层实体的服务请求通知服务用户
-
使用服务确认原语（service_name.confirm），服务提供者将服务用户先前发送的服务请求的结果通知服务用户
DoIP层服务原语规范
DoIP_Data.request
服务请求原语将<MessageData>和<Length>字节从发送方传输到由DoIP_SA、DoIP_TA和DoIP_TAtype中的地址信息标识的接收方对等实体
每次调用DoIP_Data.request服务 ，DoIP层应通过调用DoIP_Data.confirm服务向服务用户发出消息传输完成（或失败）的信号
DoIP_Data.confirm
DoIP_Data.confirm服务由DoIP层发布。这个服务原语是为了确认由DoIP_SA、DoIP_TA和DoIP_TAtype中的地址信息标识的DoIP_Data.request服务的完成情况。参数<DoIP_Result>提供服务请求的状态
DoIP_Data.indication
DoIP_Data.indication服务由DoIP层发布。这个服务原语是为了指示<DoIP_Result>事件和传递带有<Length>字节的由DoIP_SA、DoIP_TA和DoIP_TAtype中的地址信息标识的对等协议实体接收的<MessageData>给相邻的上层
参数<MessageData>和<Length>仅在<DoIP_Result>等于DoIP_OK时才有效
DoIP_Data.indication服务调用在收到DoIP诊断消息后发出。如果DoIP层在DoIP诊断消息中检测到任何类型的错误，则该消息将被DoIP层忽略并且不向相邻的上层发出DoIP_Data.indication
服务数据单元规范
这一章节描述服务数据单元规范，了解一下就行
DoIP协议使用
“
此章节给出了一个简单的DoIP会话的标准工作流程示例。目的是为了尽可能对DoIP的新读者有所帮助，所以DoIP会话期间可能发生的异常和错误不在此处介绍。涉及两种可能的网络环境——联网和直接连接
”
连接建立和车辆发现
直连场景
在没有联网的情况下，必须使用两线制以太网线，或外部测试设备和DoIP实体的以太网控制器支持的Auto-MDI(X)，以便将车辆直接连接到外部测试设备
假设在这种情况下不存在DHCP服务器。因此，虽然已启动，但 DHCP过程不会成功。相反，本地有效的IP地址将由自动配置机制确定，然后为涉及的两个接口配置
一旦DoIP实体的接口配置完成获取的IP地址，DoIP实体将通过车辆公告消息广播其VIN、EID、GID和逻辑地址。该消息将使用目标端口UDP_DISCOVERY广播(UDP)三次
外部测试设备如果无法及时配置TCP/IP通信以便接收DoIP实体的初始车辆公告消息，外部测试设备可能必须使用车辆识别请求消息轮询车辆。Auto-IP机制可能会在外部测试设备上延迟，因为某些操作系统仅在DHCP失败后才启动Auto-IP。由于DoIP实体两种机制并行启动，因此其IP配置很可能会很快完成，而外部测试设备将有可能不会收到初始车辆公告消息
下图描述了直连场景中的连接和车辆发现
联网场景
在联网场景中，连接和车辆发现的过程，相比直连有所不同。外部测试设备和DoIP实体分别连接到网络，在时间上不一定能同步，因此，为TCP/IP连接而尝试配置和访问接口的时间点可能会有很大差异
如果外部测试设备没有收到所需的DoIP实体/车辆发送的车辆公告消息（可能有很多车辆通过网络发送车辆通告消息），它会通过发送车辆识别请求消息来轮询它
下图描述了联网场景中的连接和车辆发现
DoIP session
这里着重提一下路由激活成功后，外部测试设备发送DoIP消息，DoIP实体的处理流程：
当接收到任何一种数据时，DoIP实体首先调用DoIP头部处理程序。如果负载包含诊断消息（通过通用DoIP标头中的负载类型0x8001标识），则调用诊断消息处理程序来处理负载
当一个诊断消息到达时，在该消息成功通过诊断消息处理程序（确认应答）后，应立即向调用的外部测试设备发送DoIP确认ACK，例如消息已经通过了相应的内部路由机制（这里假设DoIP实体是一个DoIP网关）但还没有必要发送到目标ECU。在UDS确认诊断消息有效载荷后，目标ECU将诊断响应发送回外部测试设备
下图描述了DoIP会话的例子
车联网整合
车辆识别
“
本条规定了如何发现车辆及其DoIP实体并将其与网络上的IP地址相关联
”
车辆通常由其VIN码识别。在制造或售后环境中，多个DoIP实体可能安装在同一辆车上，但此时车辆特定的VIN码尚未配置。为了将新安装和未配置的DoIP实体与特定车辆相关联，可以使用group ID(GID)代替VIN。它定义了一种用于在一个车辆内识别多个DoIP实体的分散方法
这意味着将有一个VIN/GID master（例如DoIP边缘节点），所有其他DoIP实体在同步过程中从该master接收VIN/GID。由于该同步过程通常需要一些时间（例如，在向车辆添加新的DoIP 实体之后），定义（见下表）无效值以供DoIP实体使用，直到VIN/GID同步完成
从上面两段话中，最起码能了解几个知识点：VIN码的作用，GID的作用，DoIP边缘节点的作用
最后一句话我不理解
“
由于该同步过程通常需要一些时间（例如，在向车辆添加新的DoIP 实体之后），定义（见下表）无效值以供DoIP实体使用，直到VIN/GID同步完成
”
我猜测要么是同步完成前给这些DoIP实体提供无效值，同步完成后刷新成正确值，要么是同步失败给DoIP设置无效值。反正不管哪种情况，同步失败的DoIP实体的VIN/Logic address/EID/GID都是无效值
下图显示了外部测试设备连接到车辆的顺序和IP地址分配过程
下图更详细地描述了识别多个DoIP实体的完整分散方法
车辆识别-外部视角
本节从车辆外部的角度描述了外部测试设备如何识别车辆内所有的DoIP实体的流程
-
当车辆连接到DoIP网络并完成IP地址分配时，DoIP实体在等待A_DoIP_Announce_Wait后发出车辆公告消息
-
如果外部测试设备稍后连接到DoIP网络，则应通过发送广播车辆识别请求来触发车辆公告/识别响应（其实车辆公告消息就是DoIP实体主动发出的车辆识别响应）
-
车辆内的所有DoIP实体在A_DoIP_Ctrl内响应车辆识别请求
-
如果外部测试设备接收到的车辆公告/车辆标识响应包含VIN/GID同步状态不完整消息（0x10），表示VIN或GID未与车辆内所有DoIP实体同步，外部测试设备将为这台车启动车辆发现定时器（由VIN/GID master在其发送车辆公告/车辆识别响应中给出的VIN/GID识别）
-
当某些实体需要更多时间进行VIN/GID同步时，该机制允许 VIN/GID master通知外部测试设备。当车辆发现计时器到期时，将向所有在其初始车辆通知/识别响应中报告VIN/GID无效的 DoIP实体发送另一个车辆识别请求
DoIP实体的功能要求
“
每个DoIP网关应根据诊断消息中包含的地址信息，使用ECU特定的车辆网络传输协议，将通过TCP_DATA套接字接收到的诊断消息中的用户数据路由到车辆网络上的相应ECU节点
”
这段话清晰地阐述了DoIP网关是如何把外部测试设备发来的DoIP诊断消息，路由给不同网络的车内节点
通过TCP_DATA socket接收DoIP诊断消息，根据诊断消息中的目的逻辑地址，使用网关与目标ECU连接的总线协议（比如Eth，CAN），将诊断消息中的UDS数据，路由给目标ECU
“
每个DoIP网关应使用诊断消息和ECU相关地址信息（源地址和目标地址）将来自车辆网络上ECU的传输协议传输的用户数据路由到TCP_DATA套接字
”
这段话阐述了DoIP网关是如何把不同网络上的ECU节点发来的诊断数据路由到TCP_DATA socket上，然后通过调用send()函数发给外部测试设备
这里很清楚地明白，是路由给和外部测试设备建立TCP连接的DoIP网关的TCP_DATA socket，而不是还要网关自己根据逻辑地址，去路由表里找到对方的IP地址，然后再组装TCP报文发送，这样也太麻烦了
应该是根据逻辑地址，找到对应的TCP_DATA socket，而socket的唯一标识，就是那个protocol、ip、port的四元组
在路由激活的时候，已经把源逻辑地址，也就是外部测试设备的逻辑地址注册到了socket上了，所以这样就很容易对应了
或者是不是网关里有一张路由表，里面存放着逻辑地址对应四元组关系的条目，这是我的猜测
“
出于一致性原因，寻址到DoIP网关本身的诊断消息可能会路由到“虚拟”内部网络
”
通信示例消息序列图
最后还举了两个外部测试设备与车辆的DoIP实体通信的最常见通信场景
下图是最常见的车辆公告与车辆识别的序列图
下图我在之前的文章中分析了太多次了
以上，就把ISO 13400-2的文档粗略地浏览了一遍，共计5篇，不能说有多深刻的内容，很多内容我只是翻译成中文而已，最多就是根据自己的理解，让语句更通顺，更易读。因为我觉得翻译过来后，已经能够让我理解这一块的内容，没有必要自己再画蛇添足，解释一通。我只会以一个初学者的角度，把我认为必要且重要的内容，做一个二次解读。至于好或坏，对或错，请大家多批评，多指正！！！
原文始发于微信公众号（汽车网络诊断通信）：详解ISO13400文档-5
