车载以太网之SOME/IP-SD专题篇

智能汽车电子与软件 2022-08-09 17:15

【应用手册】TI 全新MCU及C29内核的能源设施应用方案 【有奖直播】精密半导体参数测试解决方案

关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯

来源：ADAS与ECU之吾见

作者：奋斗的农民工

前言

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

你知道什么是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配置注意事项:

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的配置注意事项：

StopSubscribeEventgroup设置

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

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

SubscribeEventgroupAck设置

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

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

SubscribeEventgroupNack设置

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

Service ID，Instance ID，EventGroup ID的组合未知；
需要的Tcp连接并没有被客户端发起；
Server端的资源使用过度问题；
参考的Option Entries存在错误，丢失，或者互相矛盾的点；

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

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的报文发送的各个环节有个直观的认识与理解。

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的报文接收的各个环节有个直观的认识与理解。

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

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