车载以太网的SOME/IP-SD协议了解与认识

前言

首先，请问大家几个小小问题，你清楚：

你知道什么是SOME/IP SD吗？

SOME/IP-SD报文是如何发送与接收的呢？

SOME/IP-SD 存在哪几种Entry Type呢？

SOME/IP-SD内部状态机转换又是如何？

今天，我们就来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文

通过之前的文章我们了解到了SOME/IP协议的基本组成与SOME/IP的具体工作过程，同时也提到了SOME/IP-SD在SOME/IP协议中所扮演的重要角色：发现服务与订阅服务。鉴于SOME/IP-SD的重要性，本文将着重讲解下SOME/IP-SD的几类Entry Type的具体定义说明，SD报文的发送与接收流程，SD的状态机解析，让大家对SOME/IP-SD协议有个更为清晰的了解与认识。

SD Entry Type总结

Service Entries 通用需求

Service Entry使用的Type ID为0x00，0x01，使用的Entry报文格式为Format Type 1，其中Service Entries包含FindService，OfferService，StopOfferService三种。

如下图1所示展示了Serve Entries的通用需求，该需求是针对接下来要讲述的FindService，OfferService，StopOfferService的共性需求。

图1 Service Entries共性

Find Service Entry设置

如下图2所示为FindService Entry的各个Filed配置注意事项：

图2 FindService Entry 配置

OfferService Entry设置

如下图3所示为OfferService Entry的各个Filed配置注意事项：

图3 OfferService Entry 配置

StopOfferService设置

为了通知Offer Service，必须使用StopOfferService Entry 必须使用，如下图4为StopOfferService配置：

图4 StopOfferService Entry 配置

EventGroup Entries通用需求

EventGroup Entries 目前仅用到Type ID为0x06， 0x07，使用的EventGroup Entry为Type 2。同时EventGroup Entries 包含SubscribeEventgroup，StopSubscribeEventgroup，SubscribeEventgroupAck以及SubscribeEventgroupNack四种。

如下图5所示展示了EventGroup Entries的通用需求，该需求是针对接下来要讲述的FindService，OfferService，StopOfferService的共性需求。

图5 EventGroup Entry通用需求

SubscribeEventgroup设置

如下图6为SubscribeEventGroup的配置注意事项：

图6 SubscribeEventGroup配置

StopSubscribeEventgroup设置

如果需要停止订阅EventGroup，那么就需要调用StopSubscribeEventGroup的Entry来停止。

如下图7为StopSubscribeEventGroup的配置注意事项：

图7 StopSubscribeEventGroup配置

SubscribeEventgroupAck设置

当Client 通过SubcribeEventgroup Entry来订阅相关事件组时，如果Server确认满足订阅条件，那么就会通过SubcribeEventGroupAck来回复正响应，表示成功接受该订阅，Client此次订阅成功。

如下图8为SubcribeEventGroupAck的配置注意事项：

图8 SubscribeEventGroupAck配置

SubscribeEventgroupNack设置

当处在以下几种情况下时，Client请求的SubcribeEventGroup将得不到正响应，而是会回复SubcribeEventGroupNack：

Service ID，Instance ID，EventGroup ID的组合未知；

需要的Tcp连接并没有被客户端发起；

Server端的资源使用过度问题；

参考的Option Entries存在错误，丢失，或者互相矛盾的点；

如下图9为SubcribeEventGroupNack的配置注意事项：

图9 SubscribeEventGroupAck配置

SD Message

了解了上述SD所有Entry Type的设置注意事项，那么也就意味着接下来就要知道如何将这些打包的SD报文发送出去以及如何接收并解析这些SD报文，接下来我们就来了解下SD Message 的发送与接收流程。

Tx Path

正如之前的SOME/IP相关文章所述，SD模块无论是发送还是接收，都需要与一个十分重要的以太网上层抽象模块SoAd打交道，自然其发送与接收报文的过程也就会涉及到两个模块间的函数调用关系，具体的发送流程如下：

S1：SD报文已按照SD报文格式组包成功；

S2：如果是单播，则通过调用SoAd_SetRemoteAddr设置目标地址；如果是多播，则需要先通过通过调用函数SoAd_GetLocalAddr获得本地地址，然后通过SoAd_SetRemoteAddr函数设置目标地址；

S3：最后通过调用SoAd_IfTransmit将SD报文发送至总线上；

如下图10为SD Message的发送时序图，便于大家对SD的报文发送的各个环节有个直观的认识与理解。

图10 SD报文发送时序图

Rx Path

同理，对于SD报文的接收也需要经历以下几个基本环节才能够获取到数据至SD模块并得到正确处理。

S1：当SoAd模块接收到来自总线的SD报文时，就会调用SD模块的回调函数Sd_RxIndication来通知SD模块来处理数据；

S2：通过接收到的RxPduId便可以为SD实例对象获取对应的SoConId；

S3：通过调用函数SoAd_GetRemoteAddr并结合上述的SoConId来获取远程Server的地址；

S4：存储报文与地址信息以便下一步处理；

S5：最后调用函数SoAd_ReleaseRemoteAddr（）来重置SoConID以便下一次使用，同时接收到的Entry均会按照接收到的顺序依次进行处理；

如下图11为SD Message的接收时序图，便于大家对SD的报文接收的各个环节有个直观的认识与理解。

图11 SD报文接收时序图

对于接收环节如果是采用多播模式接收时，那么AUTOSAR规定为了防止由于各个接收节点几乎同时的发送Response至总线所引起的总线负载突然猛增，因此通过一种延迟机制来防止现象的出现：

对于ServerServices，即接收到FindService回复OfferService的时刻可以通过SdServerTimerRequestResponseMinDelay与SdServerTimerRequestResponseMaxDelay参数来控制；

对于ConsumedEventGroup，即接收到OfferService回复SubcribeEventGroup的时刻可通过SdClientTimerRequestResponseMinDelay与SdClientTimerRequestResponseMaxDelay来控制；

SD状态机解析

SD状态机可分为两种：Server端状态机与Client状态机，每种状态机均可以分为两种状态：Down State与Available State。其中Available State可再进一步细分为Initial Wait Phase， Repetition Phase， Main Phase。

Server SD状态机

首先我们来看下Server端的四种状态机的转换过程，如下图12为Server端的通信阶段总体review：

图12 Server端的通信阶段总体Review

如下图13我总结了Server端SD各个状态机的转换关系以及转换之间的若干条件，其中条件1与条件2为“或”的关系，并不是”与“的关系，每个Phase阶段中发生的行为均体现在Action下面。

图13 Server SD状态机转换图

Client SD状态机

首先我们来看下Client端的四种状态机的转换过程，如下图14为Client端的通信阶段总体review：

图14 Client端的通信阶段总体Review

如下图13我总结了Client端SD各个状态机的转换关系以及转换之间的若干条件，其中条件1，条件2，条件3为“或”的关系，并不是”与“的关系，每个Phase阶段中发生的行为均体现在Action下面。

图14 Client SD状态机转换图

审核编辑：郭婷