SOME/IP协议详解[6 SOME/IP-TP]

我们知道CAN-TP是用来对当总线CAN数据过大时，就需要对CAN整包数据进行分割拆包进行发送，这个时候发送方的TP层就起作用，同理对于接收方而言，也需要将分割的数据包进行组包完成整包数据的重组还原。

因此，举一反三，我们便可以知道SOME/IP-TP模块的主体功能就是为了实现对应用层发送数据过大时进行的必要拆包与组包的工作，进而完成大量数据包的发送与接收。

SOME/IP作为一种应用层协议，既可以运行在TCP之上，也可以运行在UDP之上，由于TCP协议本身支持发送大量数据同时还支持流控等特点因此无需用到SOME/IP-TP，该协议仅针对运行在UDP协议基础上的SOME/IP协议。

如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP-TP。

SOME/IP-TP是基于UDP协议的，而不是基于TCP协议的。SOME/IP-TP是SOME/IP协议的扩展，它在SOME/IP协议的基础上提供了可靠传输机制，以保证消息的可靠性和完整性。在SOME/IP-TP中，UDP协议被用作传输层协议，而不是TCP协议。这种选择是因为在车载领域，网络通信需要满足低时延和高带宽的要求，而UDP协议的无连接特性能够提供更低的通信延迟和更好的网络吞吐量。

该模块作为AUTOSAR中定义的标准模块，在AUTOSAR中与各个模块的交互关系又是如何的呢？

如下图21所示，则较为清晰的表明了SOME/IP-TP在CP AUTOSAR的具体位置以及与其他模块的交互关系：

图21 SOME/IP-TP在AUTOSAR的位置及交互关系

从图中可以直接看出SOME/IP-TP直接与PDUR层进行交互，当上层应用模块发送大量数据时，会通过PDUR发送数据给到SOME/IP-TP模块进行拆包，拆分的包将按照协议格式再通过PDUR模块依次发送。

对于接收方而言，则是接收来自PDUR的报文，通过SOME/IP-TP模块进行组包，组包后的结果给到PDUR，然后由PDUR再传输至上层应用模块。

6.1 SOME/IP-TP协议解析 

了解了SOME/IP-TP的主体功能以及大概的工作过程，接下来我们一起解析下SOME/IP-TP协议。

SOME/IP-TP作为SOME/IP报文的一种，因此前面的SOME/IP Header则保持一致，只是SOME/IP-TP存在自身的协议头，让我们一起来学习一下。

6.1.1 SOME/IP-TP协议头

如下图22为SOME/IP-TP层的协议头字段内容：

图22 SOME/IP-TP 协议头字段内容

针对上图中每个字段内容地详细解释请参考上篇链接《一网打尽车载以太网之SOME/IP(上)》

其中Message Type更为细节地定义如下图23所示：

图23 Message Type 字段内容

1. 当且仅当TP-Flag==1时，OffsetField，Reserved Field以及More Segement Flag才会存在；
2. 当TP-Flag == 1时，表示当前SOME/IP报文为被分割的报文，即Segement报文；

其中Offset Field 表示当前已发送或者接收的数据量，其基本单位为16Byte，如该值等于92，表示截至目前为止已发送了92X16=1472字节长度的Payload。同时该长度并不包含SOME/IP header的长度。

其中Reserved Field为未来预留，目前默认为0即可。

其中More Segments Flag用来表示是否还有Segement报文，当其值为1时表示还有剩余的Segement，当其值为0时则表示没有剩余的Segement，当前Segement就是最后一条。

6.2 SOME/IP-TP知识总结

1. 使用SOME/IP-TP的SOME/IP消息应激活Session ID处理；
2. 原始信息必须具有唯一的Session ID；
3. 所有SOME/IP-TP分段应携带原始消息的Session ID，因此，它们都具有相同的Session ID；
4. SOME/IP-TP分段应将Message类型的TP标志设置为1；
5. 发送时应对More Segment Flag = 1的信息进行等长分段（为1392byte，除最后一片），且按顺序/升序发送，不可以重复发送分片报文；
6. 接收时根据SOME/IP-TP包中的Message ID、Protocol Version、Interface Version、Message Type等标志进行数据重组；
7. 可接收来自不同客户端(IP、port、ID)相同Message ID重新组合多条消息(良好的缓冲机制)；
8. 当接收数据大于设置重组缓冲区时，剩余的数据将会被舍弃；
9. 当新分片数据来临，旧分片的重组任务未结束，则应抛弃旧分片开始新的分片任务；
10. 当检测到分片数据丢失后，应取消该片所属的重组任务；
11. 当检测到分片数据重复后，应可以将重复分片覆盖，使重组可以正常进行；
12. 接收完每个分片之后都应该返回Return Code，但只用最后一个分片的Return Code；
13. 数据重组后应该进行完整性校验，正确重组的数据才能传递给应用程序；
14. 数据重组后，应将分段标志设置为0；
15. 接收数据时，应该可以升序或者降序的对分片数据进行重组；
16. 接收数据时，应一个缓冲区对应一个原始数据的分片的重组，避免相同事件(IP、port、Message ID、TP)；

6.3 Tx Path

对于发送一个基于UDP完整的SOME/IP报文而言，报文的发送需要经历以下几个模块：

1. 应用层调用Rte_Send函数来实现数据SOME/IP序列化；
2. 通过LdCom模块间接调用SomeIpTp_Transmit来开启发送；
3. 通过循环调用SOME/IP-TP的主函数来遍历发送每一个Segement；
4. 同时发送出去的报文也会回复Txconfirmation中断最终传递至RteLdCom模块；

具体发送流程中的函数调用关系如下图24所示：

图24 Tx Path函数调用关系图

6.4 Rx Path 

针对被分割的segment，接收方需要通过下列几个步骤进行接收：

1. 通过SoAd模块来获取来自总线的SOME/IP数据；
2. PDUR模块接收到来自SoAd模块的数据后会触发SomeIpTp_Rxindicaion表明存在segement数据，准备开启接收；
3. SOME/IP-TP模块通过调用PDUR_SomeIpTpStartOfReception开启接收第一个Segement；
4. 剩余的Segment则可以通过不断触发PDUR_SomeIpTpCopyRxData来接收，最终传送至RTE层；
5. 当最后一个segment被接收到后，则通过调用函数PduR_SomeIpRxIndication来完成最终的接收并使得RTE反序列化给到应用层读取；

具体接收流程的函数调用关系如下图25所示：

图25 Rx Path函数调用关系图