前言
首先，请问大家几个小小问题，你清楚：
- 你知道什么是SOME/IP SD吗？
- SOME/IP-SD有何作用呢？
- SOME/IP-SD 包含哪些内容呢？
- SOME/IP-TP 为什么会存在？
今天，我们就来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：
在这里插入图片描述
正文
正如之前文章《一文入门车载以太网，吐血推荐，不看可惜！》中所介绍的那样，车载以太网协议栈总共可划分为五层，分别为物理层，数据链路层，网络层，传输层，应用层，其中今天所要介绍的内容SOME/IP就是一种应用层协议。
SOME/IP协议内容按照AUTOSAR中的描述，我们可以更进一步的拆分为三类子协议：应用层的SOME/IP标准协议，SOME/IP-SD协议以及TP层的SOME/IP-TP协议，这三部分内容相辅相成，完整详细的阐述了SOME/IP协议的全部内容，是研究SOME/IP协议的必经之路。
通过上篇《一文搞懂车载以太网之SOME/IP(上)》我们全面讲解了SOME/IP标准协议的全部内容，想必大家已经对SOME/IP有了一个较为基础的了解，接下来本文将着重讲解剩余的两部分协议内容：SOME/IP-SD协议以及TP层的SOME/IP-TP协议。
有关SOME/IP序列化内容限于篇幅有限，请听下回分解，敬请关注！
SD(Service Discovery) 顾名思义为服务发现，具备发现服务的基本功能，这是从节点作为Client来考虑的，需要找到网络上对应的服务；对应地，网络中必然存在至少提供该服务的节点，该节点可被称Server，因此这样的供需场景就是SD协议工作的场景。
在这种供需场景中我们看到了提供服务，订阅服务的过程，该过程如果用专业术语来讲可称为Subcribe/Publish模型，该模型涉及到Client与Server两方，交互过程如之前文章所描述如下图1所示：
图1 SOME/IP-SD 交互过程
由上图可知，Subribe/Publish的过程主要经历以下四个阶段：
-
对于需要服务的Client而言，通过FindService方式来发现当前网络中存在的服务；
-
如果Server存在服务就会通过Offer Service方式来广播通知自身存在的服务；
-
Client根据已发现的服务中通过Subcribe EventGroup的方式来订阅相关事件，同时在Server段发现Client的订阅满足条件则会回复正确的肯定响应；
-
当Client订阅成功后，Server端便会按照服务的基本属性来事件型或者周期性提供Client端相关的服务；
总而言之，SOME/IP-SD就是用于定位服务，检查服务可用性以及部署与发布服务句柄的一种应用层协议，该协议只能运行在UDP之上，服务发现报文格式与SOME/IP标准协议一致，且Message ID固定为0xFFFF8100，其中Service ID是0xFFFF，Method ID为0x8100。
SOME/IP-SD协议头
首先，依照惯例我们先来看下SOME/IP-SD的报文格式如下图2所示：
图2 SOME/IP-SD Message Format
一般而言，如果没有特别要求，在SD报文格式中的内容均按照大端方式传输。
由于SOME/IP-SD报文实际上也只是SOME/IP报文的一种，只不过是在SOME/IP标准协议的基础上扩展了Entry，Option等字段，其中Entry用于同步服务实例的状态以及发布/订阅关系的管理，Options则用于传输Entry的附加信息。
接下来，我们将针对上述的协议中各种字段为大家一一解释如下表1：
表1 SOME/IP-SD 协议内字段解释
Entry Array
如上表1中所述，Entry Array按照SD的定义可分为以下两种：
- **Service Type：**用于FindService，OfferService，StopOfferService这几种场景；
- EventGroup Type： 用于 SubscribeEventgroup， StopSubscribeEventgroup，SubscribeEventgroupAck，SubscribeEventgroupNack这几类场景。
如下图3所示，首先我们介绍下为Service Entry Array中定义的各个字段内容：
图3 Service Entry Array定义
对上述Service Entry Array定义的各个Field解释说明如下表2所示：
表2 Service Entry Array字段解释说明
介绍完Service Entry Array，相比之下EventGroup Entry Array又存在哪些差异呢？
如下图4为EventGroup Entry Array的各个字段内容的定义：
图4 EventGroup Entry Array定义
相比Service Entry Array，EventGroup Entry少了Minor Version，但是多出了Counter以及EventGroup ID内容，接下来我们将对上述EventGroup Entry Array定义的各个Field解释说明如下表3所示：
表3 EventGroup Entry Array字段解释说明
Option Array
Option Array作为SOME/IP-SD报文最后的部分，其主要作用就是为了提供在通信的过程中提供下附加信息，如配置信息，IP地址，端口号等。不过其作为SD报文的一部分也存在着自身的字段内容。
AUTOSAR将Option Array主要分为以下三种：
- Configuration Options：用于配置通信过程的必要的信息
- **Endpoint Options(IPV4/IPV6)😗*用于传递IPV4或者IPV6的Endpoint信息(IP地址+Port号)以及使用的传输层协议；
- Multicast Options(IPV4/IPV6):用于广播IPV4或者IPV6的IP地址及Port号，其中传输层协议只能使用UDP协议；
Configuration Options
接下来我们来对这三种Option进行一一解读。首先来看看Configuration Option的字段定义：
图5 Configuration Option 字段定义
注意：configuration options仅适用于任意Service ID的Service Entry Array以及Service ID为0xFFFE的EventGroup Entry Array。
针对上述字段解释如下表4所示：
表4 Configuration Option Array 字段解释说明
对于那些非标准的SOME/IP 服务，由于不能够被Service ID进行标识，此时就需要通过一个key “otherserv”的值来进行标识，这类服务则可通过使用0xFFFE作为Service ID同时附带otherserv的value的configuration option来完成双方的通信。
IPV4 Endpoint Option
如下图6为IPV4 Endpoint Option的字段定义：
图6 IPV4 Endpoint Option字段定义
IPV6 Endpoint Option
如下图7为IPV6 Endpoint Option的字段定义：
图7 IPV6 Endpoint Option字段定义
IPv4 Multicast Option
如下图8为IPv4的Multicast Option各字段内容定义：
图8 IPv4 Multicast Option
IPv6 Multicast Option
如下图8为IPv6的Multicast Option各字段内容定义：
图9 IPv6 Multicast Option定义
IPv4 SD Endpoint Option
如下图10为IPv4 SD Endpoint Option的字段定义：
图10 IPv4 SD Endpoint Option定义
IPv6 SD Endpoint Option
如下图11为IPv6 SD Endpoint Option的字段定义：
图11 IPv6 SD Endpoint Option定义
由于上述六种IPV4与IPV6字段内容大体结构一致，因此我们将该两者放在一起来对各字段内容进行解释说明：
表5 IPv4/IPv6 六类Option字段解释说明
SD状态机状态机这部分由于涉及的内容细节较多且较为独立，同时限于篇幅有限，后期会专门针对SD状态机，SD报文接收发送等环节给大家单独分享，敬请期待SOME/IP-SD状态机专题篇！
我们知道CAN-TP是用来对当总线CAN数据过大时，就需要对CAN整包数据进行分割拆包进行发送，这个时候发送方的TP层就起作用，同理对于接收方而言，也需要将分割的数据包进行组包完成整包数据的重组还原。
因此，举一反三，我们便可以知道SOME/IP-TP模块的主体功能就是为了实现对应用层发送数据过大时进行的必要拆包与组包的工作，进而完成大量数据包的发送与接收。
SOME/IP作为一种应用层协议，即可以运行在TCP之上，也可以运行在UDP之上，由于TCP协议本身支持发送大量数据同时还支持流控等特点因此无需用到SOME/IP-TP,该协议仅针对运行在UDP协议基础上的SOME/IP协议。
该模块作为AUTOSAR中定义的标准模块，在AUTOSAR中与各个模块的交互关系又是如何的呢？
如下图12所示，则较为清晰的表明了SOME/IP-TP在CP AUTOSAR的具体位置以及与其他模块的交互关系：
图12 SOME/IP-TP在AUTOSAR的位置及交互关系
从图中可以直接看出SOME/IP-TP直接与PDUR层进行交互，当上层应用模块发送大量数据时，会通过PDUR发送数据给到SOME/IP-TP模块进行拆包，拆分的包按将照协议格式再通PPDUR模块依次发送。
对于接收方而言，则是接收来自PDUR的报文，通过SOME/IP-TP模块进行组包，组包后的结果给到PDUR，然后由PDUR再传输至上层应用模块。
了解了SOME/IP-TP的主体功能以及大概的工作过程，接下来我们一起解析下SOME/IP-TP协议。
SOME/IP-TP作为SOME/IP报文的一种，因此前面的SOME/IP Header则保持一致，只是SOME/IP-TP存在自身的协议头，让我们一起来学习一下。
SOME/IP-TP协议头
如下图13为SOME/IP-TP层的协议头字段内容：
图13 SOME/IP-TP 协议头字段内容
针对上图中每个字段内容地详细解释请参考上篇链接《一文搞懂车载以太网SOME/IP(上)》
其中Message Type更为细节地定义如下图14所示：
图14 Message Type 字段内容
- 当且仅当TP-Flag==1时，OffsetField，Reserved Field以及More Segement Flag才会存在；
- 当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就是最后一条。
Tx Path
对于发送一个基于UDP完整的SOME/IP报文而言，报文的发送需要经历以下几个模块：
- 应用层调用Rte_Send函数来实现数据SOME/IP序列化；
- 通过LdCom模块间接调用SomeIpTp_Transmit来开启发送；
- 通过循环调用SOME/IP-TP的主函数来遍历发送每一个Segement；
- 同时发送出去的报文也会回复Txconfirmation中断最终传递至RteLdCom模块；
具体发送流程中的函数调用关系如下图15所示：
图15 Tx Path函数调用关系图
Rx Path
针对被分割的segment，接收方需要通过下列几个步骤进行接收：
- 通过SoAd模块来获取来自总线的SOME/IP数据；
- PDUR模块接收到来自SoAd模块的数据后会触发SomeIpTp_Rxindicaion表明存在segement数据，准备开启接收；
- SOME/IP-TP模块通过调用PDUR_SomeIpTpStartOfReception开启接收第一个Segement；
- 剩余的Segment则可以通过不断触发PDUR_SomeIpTpCopyRxData来接收，最终传送至RTE层；
- 当最后一个segment被接收到后，则通过调用函数PduR_SomeIpRxIndication来完成最终的接收并使得RTE反序列化给到应用层读取；
具体接收流程的函数调用关系如下图16所示：
图16 Rx Path函数调用关系图
