? ? ? ? SOME/IP全称Scalable service-Oriented Middleware over IP，是目前汽车行业实现SOA架构最核心的通信协议。SOME/IP协议以服务为单位管理整车信息，服务可以包含各种可调用方法（Method）和事件通知组（EventGroup），通过Service Interface将信息进行传递共享，按需分配服务。SOME/IP位于OSI七层模型的5-7层，需要运行于TCP/IP协议栈之上，即所有的SOME/IP报文都是IP报文，都是TCP/UDP报文。
? ? ? ?在以CAN总线为主的车载网络中，通信过程是面向信号的（除了诊断通信之外）。这是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。而SOME/IP则不同，它是在接收方有需求的时候才发送，这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载。
?
1 ServiceDiscovery是SOME/IP实现服务信息共享的核心机制。
FindService由Client端启动时发出，查找所需的服务。
OfferService由Server端发出，通告所提供的服务。
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休眠或关机。
<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应答。
?
2 subscribe服务订阅及ack
订阅发生在Main Phase，Client端在收到所需服务的OfferService之后，判断该服务是否包含所需的事件组，若包含，则向该OfferService包含的节点信息发送Subscribe报文。当Server端收到订阅请求之后，若服务有效应理解发送SubscribeACK，进行应答（订阅TCP服务需要先建立TCP连接）。
?
<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连接。
?
3 Service Interface
Service Interface是各个SWC交换服务信息的媒介，应用层通过发送和解析Service Interface来实现信息传递、远程调用算法、远程控制硬件和信息读取。Service Interface共分为四种，每种的使用场景各不相同，分别是R&R Method、F&F Method、Event和Field。
1 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——所请求的服务；
|
2 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——所请求的服务； |
3 Event用于Server端向已定阅的Client端发送通知，一般用于状态值的通知或触发性事件的通知。发送模式一般分为On Change和Cycle两种，可以根据功能进行TCP发送、UDP单播发送和UDP多播发送。
| Event报文格式包含的关键信息有： ?? ?Service ID——该通知所归属的服务； |
4 Field在报文结构上就是由Method和Event组成，所以报文结构不在赘述，Field接口更侧重于域值的管理，对于AUTOSAR架构而言，在系统配置中单独设立了一个接口用于Field的配置，对于Linux常用的vsomeip协议栈而言，Field的发送可以直接通过调用Method和Event的发送和解析接口实现，Field暴露的服务接口由Notifier、Getter、Setter三种，如下：
? ? ? ? ?Notifier：通知，Server的Client订阅了服务后第一时间主动向其发送数据。
? ? ? ? ?Getter：获取，由Client向Server请求数据。
? ? ? ? ?Setter：设置，由Client修改Server的数据。
4.1 Notifier报文是Event格式，用于服务器端对域值的主动通知，在网络中传输时与Event报文没有区别，尽在内部软件层面存在接口区分。推荐使用On Change模式进行发送。
4.2 Getter报文使用R&R Method格式，用于Client端主动获取域值，Server端收到Getter请求后应使用Getter Response将当前域值发送给Client端，Getter请求报文一般不携带参数。
4.3 Setter报文使用R&R Method格式，用于Client端主动更改域值，Server端收到Getter请求后应使用Setter Response将更新后的域值发送给Client端，Setter请求报文必须携带参数。
