SOME/IP（二）

SOME/IP-SD协议规范解读

        此篇文章需要大家先看完前面一篇对于SOME/IP-SD的介绍，还没看过的需要先看一下第一遍文章 SOME/IP介绍（一）-CSDN博客

        首先，要想明白SOME/IP的服务是如何互相通信上的，就需要熟练了解SOME/IP-SD的协议规范。下面将结合生活中常见的“美团平台”给大家做对比讲解讲述SOME/IP-SD是什么，以及它如何巧妙的将不同设备间的服务连通起来。

1. Entry

1.1 加入“平台”

        ECUs为了完成SOME/IP交互，需要统一加入到类似“美团外卖”的平台，在SOME/IP-SD协议栈中这个“美团外卖”平台就是UDP Multicast——所有设备启动SOME/IP时，都需要加入到一个统一的UDP组播中。

        

1.2 A提供的服务（如有）

        如果想要被人来消费你的服务，你需要在“平台”中使用组播包发送自己的服务，发服务的时候需要发服务的全部信息（id，instance，major ver，minor ver， TTL）

        比如，A设备提供了“酸菜鱼火锅”服务，A就需要将自己服务通过“平台”发出来，特别注意，提供服务的时候会要求协商TTL，通常这个TTL不会设置为全F，原因就是A可能因为某些意外或非意外闭店，那A必须得让消费者知道。所以A在提供服务的时候就会用TTL告诉大家——我今天19：00~20：00可以提供“酸菜鱼火锅”，如果A在20:00前发现，自己还能继续干他1个小时，那A就会提前再到平台上给大家发一个Offer service Entry出来。这就是如下这段规范描述的内容了。

        

1.3 B请求服务（如需要）

        如果B加到"平台“（UDP组播）时要消费”酸菜鱼火锅"（一般消费什么服务是整车系统定义好的，大家谁是消费者谁是服务提供者都是需要明确定义的），那B就可以通过请求服务Entry来请求服务。

        

问：为什么B要有请求服务这个动作，按道理A不是一直在周期发送自己的offer service Entry吗，B等下个周期不就知道A提供了服务吗？

答：这就是SOME/IP协议妙的地方，A确实是一直周期发送offer的，但是B有可能上线比A晚，错过了A发的offer包，如果B要等下个周期，就会存在B有段时间不能用服务的情况，所以协议里面就加上了A可以主动请求服务的操作了。

笔者理解：如果B加入组播（但是此时还不需要使用服务）后不是马上使用服务，而是过了一段时间才需要使用服务，在这段时间内A如果已经发过了offer包（且服务没有过期），那么B就不需要再发request了

1.4 B订阅事件组（如需要）

        SOME/IP协议栈中描述的订阅都是订阅的“事件组”而不是“事件”，SOME/IP协议栈的意思就是如果你关注某个event，但是可能对同组其他event不关心，那么不好意思，协议栈层面是没有办法帮你解决这个问题的，只能靠底层自己去过滤event了。即你要么订阅一个组内所有events，要么就不订阅这个组。

        NOTE: 订阅包的发送一定是在收到A的offer之后发的，也就是说订阅跟offer包一样，是一个周期发送的包。

1.5 A对B的订阅回应（sub ACK）

        对#4中B发来的订阅的回复

2. Option

        打个不恰当的比喻：

        1. A：我提供“火锅“服务，也支持外卖订餐，大家有需要的来哈（offer service）

        2. B：我要定你个外卖，要什么口味、什么菜（订阅）

        3. A：好嘞（订阅ACK）

        4. C:  我要吃火锅

        看看上面的例子，大家有没有发现一个问题，那就是A要给B送餐去哪里？C要去哪里才能找到A？

        所以，SOME/IP就引入了option的概念，在大家互相沟通的时候，让对方知道自己服务地址

        

        1. A：我提供“火锅“服务，也支持外卖订餐，大家有需要的来哈（offer service），我的地址是xx，联系电话是xx

        2. B：我要定你个外卖，要什么口味、什么菜（订阅），我的地址是xx，联系电话是xx

        3. A：好嘞（订阅ACK），做好后送到B的地址即可

        4. C:  我也要吃火锅（request），直接去A的地址请求即可

        

2.1 SOME/IP option类型与entry映射表

        SOME/IP定义了每种Entry对应可以携带的option类型，如下：

2.2 OfferService中的Endpoint option

        ECUA在offer service时候，需要告知其他ECU，可以通过那个Endpoint来访问我的服务，这个就是IPV4/IPV6 endpoint，拿IPV4举例，你需要告诉其他ECU，别人要用的服务时候，给你那个IP地址、port发UDP还是TCP包（注：ECUA要先创建TCP server端才能发offer出去）

        

2.3 SUB中的Endpoint

        ECUB如要订阅ECUA的EG（Event group)，需要携带上自己的option，告知ECUA，你以后将event发给我指定的IP地址、指定端口、指定UDP/TCP协议。

NOTE:客户端订阅时候，如果是使用的TCP协议，客户端必须先保证连上ECUA的TCP server，才能发sub包，不然ECUA在收到sub包后会认为你ECUB没有连上我，订阅个锤子，直接会给ECUB回复sub Nack（即订阅失败），对应的协议规范如下：

2.4 SUB ACK中Multicast option讲解

        上表中有一个特别需要说明的地方，sub ACK中为何会有一个Multicast option可选择。

        原因：如果A提供了服务，服务中event group1（简称EG1)，如果B、C、D、E大家都来订阅这个EG，那么A就可以不用给B\C\D\E一个一个的单独发过去了，那么A在回复B\C\D\E的订阅时候，就提前告诉他们——这个EG里面的events我有可能发到MulticastXX中哈，你们要注意了哈。

B...E他们收到这个option后，就需要时刻监听这个multicast，因为有可能A会单独给你发event，也有可能A懒得给你们一个个发（其实不是懒，是因为SOME/IP协议考虑到以太网负载原因，用组播包代替了4个单播包），直接发到组播地址中去了。这个过程匹配的就是协议栈如下内容：

了解上面entry和option后基本可以定位分析SOME/IP-SD常见问题了