@[supper_runner](SOME/IP协议详解_SD&SI（ServiceDiscovery & ServiceInterface）)
#个人学习记录与分享，欢迎指正。
1. 前言
SOME/IP是目前汽车行业实现SOA架构最核心的通信协议，本文将围绕SOME/IP的ServiceDiscovery机制和Service Interface工作场景着重分享SOME/IP面向服务的实现方法，以及SOME/IP通信机制的优势。大家感兴趣的话后面可以分享一下SOME/IP 的序列化、SOME/IP的ETS协议栈一致性测试和应用服务定义方法。
2. SOME/IP的特点
SOME/IP全称Scalable service-Oriented MiddlewarE over IP，全称很好的概括了SOME/IP协议的特征,但是对于SOME/IP刚接触的朋友直接去理解这四个特征可能会过于抽象，可大概看一眼，先了解下面SD的机制章节和Service Interface章节后再行理解。
2.1.Scalable——可伸缩的
得益于SOME/IP中间件的功能，服务与硬件能够很好的解耦，其对于服务的管理拓展性和可裁剪性都非常好，在系统中增加较少一些服务，甚至增加减少一些ECU对于整个系统来说影响很小，理论上带宽允许的情况下，可以无限增加服务数量（当然服务ID的范围为2字节,此原则不可违反）。
2.2.service-Oriented——面向服务的
SOME/IP协议以服务的单位管理整车信息，服务可以包含各种可调用方法（Method）和事件通知组（EventGroup），通过Service Interface将信息进行传递共享，可以做到按需分配服务，按需分配信息，从而提高通信线路利用率。
（该图为借用图片，已难以溯源，仅用于学习分享，如有侵权请联系删除）
3.3.MiddlewarE——中间件
SOME/IP作为服务于分布式系统的通信协议，可将应用层与Endpoint信息、硬件驱动等底层信息进行松耦合管理，使得应用模块在查找所需服务或提供自身服务时，可以完全不关心底层信息，很好的实现了中间件的功能。
2.4.over IP——基于IP协议
SOME/IP位于OSI七层模型的5-7层（应用层），需要运行于TCP/IP协议栈之上，即所有的SOME/IP报文都是IP报文，都是TCP/UDP报文。
3.SD机制
SD机制是SOME/IP实现服务信息共享的核心机制，如其全称ServiceDiscovery，它实现了服务发现的功能。
要了解SD需要首先了解SOME/IP的通信架构，SOME/IP服务于分布式系统，采用服务器客户端无规则分布模式，即任何一个车内以太网节点都可能是Server或是Client，甚至是同时作为Server和Client。服务发现分为两个过程，一个是查找和提供服务的过程，即FindService和OfferService，一个是订阅和响应的过程，即Subscribe和SubscribeACK。SOME/IP通过这四种报文来实现服务发现。SD报文格式如下：
SD的概括性通信模式图如下：
3.1.FindService & OfferService服务查找
使用场景
FindService由Client端启动时发出，OfferService由Server端发出，分别用于查找所需的服务，和通告所提供的服务。要想了解这两种报文的发送机制，不得不提及SOME/IP的启动行为。SOME/IP协议栈在进行启动时会进入三个阶段。分别是Initial Wait Phase、Repetition Phase、Main Phase。
Initial Wait Phase
在SOME/IP协议栈启动初始，进入Initial Wait Phase，该阶段仅在ECU内部进行初始化不进行对外通信，不会有任何SOME/IP报文发出。
Repetition Phase
协议栈内部初始化完成之后，进入Repetition Phase，该阶段处于发出快发阶段。对于Server端，将开始发送OfferService报文，发送机制为周期倍增模式，直至达到REPETITIONS_MAX次数，然后进入Main Phase。
对于Client端，将开始发送FindService报文查找所需服务，发送机制同样是周期倍增模式，直至达到REPETITIONS_MAX次数，然后进入Main Phase，若Client端在此阶段查找到所需服务则立即跳转入Main Phase。
Main Phase
进入Main Phase后Client端不再发送FindService，但Server端以CYCLIC_OFFER_DELAY继续发送OfferService，直至ECU休眠或关机。
报文特征
FindService& OfferService的报文格式的Entry部分与订阅报文略有区别，格式如下，每个字段都有其相应作用，篇幅有限只能分享几个小知识点，无法一一赘述，感兴趣的朋友可以自行查看协议。
知识点总结
<1> OfferService的TTL字段可以为0，此时表示StopOfferService。
<2> FindService的InstanceID字段为0xFFFF时有特殊含义，表示查找该Service的所有服务实例。
<3>MajorVersion必须完全一致才兼容，MinorVersion向后兼容。
<4>FindService报文一般不携带节点信息.
<5>FindService报文包含的信息为所需的服务ID和服务实例ID。
<6>FindService报文以组播形式在局域网内进行服务搜索。
<7>OfferService报文必须携带节点信息。
<8>OfferService报文包含的信息为所提供的服务ID和服务实例ID。
<9>OfferService报文以组播形式在局域网内进行服务多播。
<10>收到FindService包含的服务是己身提供服务时，Server端应第一时间进行OfferService应答。
3.2.Subscribe & SubscribeACK服务订阅
使用场景
订阅发生在Main Phase，Client端在收到所需服务的OfferService之后，判断该服务是否包含所需的事件组，若包含，则向该OfferService包含的节点信息发送Subscribe报文。当Server端收到订阅请求之后，若服务有效应理解发送SubscribeACK，进行应答（订阅TCP服务需要先建立TCP连接）。
报文特征
Subscribe报文的Entry格式如下：
知识点总结
<1>Subscribe以单播形式发送。
<2>Subscribe必须携带Client端的节点信息，节点信息数量大于0，小于3，在Endpoint中指明Client的Transport Protocol、Port以及Transport Protocol。
<3>Subscribe报文TTL等于0时，表示StopSubscribe。
<4>Subscribe报文订阅的最小单位时是事件组。
<5>Initial Data Requested Flag [1 bit]，请求发送initial Event的标志位。（当前业内不使用）
<6>Counter [uint4]:用于区分相同用户相同事件组的订阅，加一累计。（当前业内不使用）
<7>SubscribeACK以单播形式发送。
<8>SubscribeACK只有在包含多播事件组时才会包含Endpoint信息，其中包含Multicast Transport Protocol和Port，Transport Protocol默认为UDP。
<9>SubscribeACK报文TTL等于0时，表示SubscribeNACK，即拒绝订阅。
<10>若要订阅TCP服务需要先建立TCP连接。
4. Service Interface
Service Interface是各个SWC交换服务信息的媒介，应用层通过发送和解析Service Interface来实现信息传递、远程调用算法、远程控制硬件和信息读取。Service Interface共分为四种，每种的使用场景各不相同，分别是R&R Method、F&F Method、Event和Field。下面我将4种服务接口的使用场景和报文解析分别列举讲解。Service Interface报文格式如下：
4.1.R&R Method
使用场景
R&R Method全称Request&Response Method，工作机制为请求应答机制。当Client搜索到所需服务后，在服务的有效生存时间内，Client端根据功能需求发出Request，对于R&R Method，Server端必须给予Response应答，若Request存在差错，如Service ID无法识别、Interface Version不正确、数据格式不正确等等，Server端需要进行Error应答，并指明错误信息。
R&R Method用于短数据的传输、远程算法的调用、远程设备的控制等等场景。
报文特征
R&R Method报文包含的关键信息有：
Service ID——所请求的服务；
Method ID——所请求的方法；
Length——这里的Length指从Length字段的下一个字节起始的SOME/IP报文字节数；
Interface Version——接口版本号；
Message Type——消息类型。
对于R&R Method，其Method ID的第一个bit必须为零，且0不能作为Method ID，因此其取值范围为0x0001-0x7FFF，另R&R Method的充要标志是Message Type为0。ReturnCode用于Error信息的错误指示。
4.2.F&F Method
使用场景
F&F Method全称Fire&Forget Method，工作机制为请求应答机制。当Client搜索到所需服务后，在服务的有效生存时间内，Client端根据功能需求发出Request，对于F&F Method，Server端不能够给予Response应答，若Request存在差错，如Service ID无法识别、Interface Version不正确、数据格式不正确等等，Server端也不需要进行Error应答。
F&F Method一般用于不需要Response答复执行结果的场景，比如需要Server发送某一个Event，若执行成功，Client会收到Event，因此不需要Response答复，此场景设计一个F&F Method即可。
报文特征
F&F Method报文格式包含的关键信息有：
Service ID——所请求的服务；
Method ID——所请求的方法；
Length——这里的Length指从Length字段的下一个字节起始的SOME/IP报文字节数；
Interface Version——接口版本号；
Message Type——消息类型。
对于F&F Method，其Method ID的第一个bit同样必须为零，且0不能作为Method ID，因此其取值范围为0x0001-0x7FFF，另F&F Method的充要标志是Message Type为1。ReturnCode为0。
4.3.Event
使用场景
Event用于Server端向已定阅的Client端发送通知，一般用于状态值的通知或触发性事件的通知。发送模式一般分为On Change和Cycle两种，可以根据功能进行TCP发送、UDP单播发送和UDP多播发送。
报文特征
Event报文格式包含的关键信息有：
Service ID——该通知所归属的服务；
Event ID——该通知的编号；
Length——这里的Length指从Length字段的下一个字节起始的SOME/IP报文字节数；
Interface Version——接口版本号；
Message Type——消息类型。
对于Event，其Event ID的第一个bit必须为1，且0x8000不能作为Method ID，因此其取值范围为0x8001-0xFFFE(0xFFFF没有见过使用，SOME/IP中全F常表示特殊含义，了解的朋友可以分享一下)，另Event的重要标志是Message Type为2。ReturnCode为0。
4.4.Field
Field在报文结构上就是由Method和Event组成，所以报文结构不在赘述，Field接口更侧重于域值的管理，对于AUTOSAR架构而言，在系统配置中单独设立了一个接口用于Field的配置，对于Linux常用的vsomeip协议栈而言，Field的发送可以直接通过调用Method和Event的发送和解析接口实现，Field暴露的服务接口由Notifier、Getter、Setter三种，如下：
4.4.1.Notifier
Notifier报文是Event格式，用于服务器端对域值的主动通知，在网络中传输时与Event报文没有区别，尽在内部软件层面存在接口区分。推荐使用On Change模式进行发送。
4.4.2.Getter
Getter报文使用R&R Method格式，用于Client端主动获取域值，Server端收到Getter请求后应使用Getter Response将当前域值发送给Client端，Getter请求报文一般不携带参数。
4.4.3.Setter
Setter报文使用R&R Method格式，用于Client端主动更改域值，Server端收到Getter请求后应使用Setter Response将更新后的域值发送给Client端，Setter请求报文必须携带参数。
5. 结语
SOME/IP的知识即有很连贯的逻辑性，又同时包含了很多琐碎的知识，一篇文章很难全部说清楚，更多时候要在实操中学习，这边文章仅对SD和Service Interface做了分享，感兴趣的话可以收藏起来，后续有时间的话，本人再更新下SOME/IP 的序列化、SOME/IP的ETS协议栈一致性测试和应用服务定义实操相关的知识，搞清楚报文的每一个字段可以很好的帮助理解哦，欢迎大家批评指正，一起进步。