车载通信架构 —— SOME/IP-SD 协议介绍
我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
本文主要
-> 1、SOME/IP-SD 基本概述
-> 2、主要功能
-> 3、通信行为
一、SOME/IP-SD 基本概述
SOME/IP-SD 协议是 SOME/IP 协议的一种，其中 SD 是服务发现 Service Discovery 的简称。基于服务的通信需要由 Server 和 Client 共同完成，因此在服务创建并且可用之后，Server 和 Client 需要通过SOME/IP-SD 动态创建两者之间的连接。Client 可以远程调用 Server 提供的服务，或者订阅Server发布的内容，Client 调用服务或者订阅内容之前，需要知道 Server 提供哪些服务，这个过程就是通过服务发现来实现的。
SOME/IP-SD 是服务的信息清单及管理机制，主要实现服务寻址及事件订阅两种功能。对服务进行寻址时，服务提供者（Server 端）通过服务发现（SD）通知其他 ECU（Client 端）某服务可用，并间接地通知该服务的地址信息（Server 端 IP 地址，端口号，协议），服务消费者（Client 端）了解到某服务状态后，能够调用该服务的相关内容。
二、主要功能
SOME/IP-SD 有两个主要功能：
1、是应用程序之间传达自己的服务或获取对方的服务是否可用。二是向其他应用程序订阅服务，也就是通过 SOME/IP-SD 对服务进行订阅，然后再用 SOME/IP 里的 Notification 类型消息发布订阅内容。
SOME/IP-SD 报文主要有以下几类：
（1）OfferService：Server 服务 Ready 并满足服务发布条件后，主动发出 OfferService 报文，告知组播内其他节点，该服务已经启动，可以创建服务连接。
（2）FindService：当 Client 在网络中未收到相关服务的 OfferService 报文或者暂时未收到，而 Client又需要访问该服务，那么 Client 可以发送 FindService 报文主动寻找服务，如果 Server 服务 Ready，会回复 OfferService 报文。
（3） StopOfferService：当 Server 发现服务不可用，不满足服务发布条件时，会主动发送 StopOfferService 报文，告知组播内其他节点，该服务已不可用，停止服务支持。
（4）Subscribe：事件组的交互采用 “订阅 - 发布” 机制，当 Client 收到 OfferServic 报文之后，通过发送 Subscribe 报文主动跟 Server 订阅相关事件组。
（5）SubscribeACK/SubscribeNACK：当 Server 收到 Client 的订阅报文之后，需要先行判断是否符合可订阅的条件，如果该 Client 满足事件组订阅条件，则发送 SubscribeACK，告知 Client 订阅成功。当事件组内的事件准备就绪之后，Server 会以约定好的形式发送相关事件给成功订阅的 Client。如果该Client 不符合事件组订阅条件，Server 会直接回复 SubscribeNACK，告知订阅不成功。
（6）StopSubscribe：当 Client 订阅某个事件组之后，发现后续并不在需要该事件组的数据了，可发送StopSubscribe 报文向 Server 取消订阅相应事件。
三、通信行为
服务端和客户端的通信行为如图所示，包含以下几个阶段：
服务端通信行为：
1、Down Phase
在这个阶段，Service 是不可用的，即服务端无法提供服务。
2、Initial Wait Phase
-> 准备完毕 (Available) 后，进入此阶段。
-> 如果此阶段收到 Find Service 报文，服务端忽略此消息，不做任何处理。
-> 如果服务不可用了，将返回进入 Down Phase。
-> 此阶段需要定义时间参数 INITIAL_DELAY_Min 和 INITIAL_DELAY_Max，初始化时间取其之间的随机值，当定时器超时后，发送第一帧 OfferService，标志着进入下一个阶段。
3、Repetition Phase
-> 为了让客户端快速找到有哪些 Service，此阶段重复发送 OfferService，重复次数由 REPETITIONS_MAX 决定。
-> 发送间隔以 REPETITIONS_BASE_DELAY 为基本时间，每发送一次，间隔是前一间隔的 2 倍。
-> 如果收到某客户端的 FindService，不影响当前阶段的发送计数和计时，延迟一定时间 (REQUEST_
RESPONSE_DELAY) 后，单独发送单播 OfferService 给服务请求端。
-> 如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器。
-> 如果收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器。
-> 如果服务不可用，离开此阶段进入 Down Phase，并发送 StopOfferService 通知所有客户端。
4、Main Phase
-> 此阶段将周期性发送 OfferService，周期时间为 CYCLIC_OFFER_DELAY。
-> 如果收到某客户端的 FindService，不影响发送计数，延迟一定时间 (REQUEST_RESPONSE_DELAY) 后，发送单播 OfferService 给服务请求端。
-> 如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器。
-> 收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器。
-> 如果服务不可用，离开此阶段进入 Down Phase，并发送 StopOfferService。
客户端通信行为
客户端通信行为如图：
A：Down Phase
-> 服务未被应用请求。
-> 收到 OfferService，存储当前服务实例状态，启动 TTL 计时器，此时服务若被应用请求，直接进入 Main Phase。
B:nitial Wait Phase
-> 服务被请求后，进入此阶段。
-> 等待 INITIAL_DELAY 时间（最大和最小值之间的随机值）。
-> 如果此时收到 Offer Service，则取消计时器，直接进入 Main Phase。
-> 如果服务请求被释放，进入 Down Phase。
-> 计时器超时后，发送第一个 Find service，进入下一阶段。
C:Repetition Phase
-> 重复发送 Find service，重复次数由 REPETITIONS_MAX 决定，发送间隔以 REPETITIONS_BASE_DELAY 为基时间，每发送一次，间隔加倍。
-> 收到 Offer Service，停止发送计数和计时，立即进入 Main Phase，触发发送 SubscribeEventgroup( 延迟一定时间）。
-> 如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送 StopSubscribeEventgroup
D:Main Phase
-> 不再周期发送 Find Service。
-> 收到 Offer Service，触发发送 SubscribeEventgroup( 延迟一定时间）。
-> 如果收到 StopOfferService，则停止所有计时器。
-> 如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送 StopSubscribeEventgroup。
客户端状态机转化图如图:
四、SOME/IP 在 SOA 中的应用
SOA 是一种面向服务的架构模型。它可以根据需求将不同的应用服务进行拆分，并通过定义好的服务接口联系起来，从而使得在构建不同系统时，服务可以以一种统一的方式进行交互。在基于 SOA 的软件架构中，服务是最小的功能逻辑块。为了实现一项功能，整车的某个或某些子系统需要进行数据交互，而数据交互的接口就是服务的接口。服务通过服务接口实现信息的交互，进而完成服务本身的功能。
SOA 的关键技术是要求有统一的、标准的通信协议及中间件。SOME/IP 作为一种基于车载以太网协议的、面向服务的灵活中间件，解决 SOA 通信的中间件技术。
根据当前的汽车电子电气架构，汽车将主要由中央域控制器及区域控制器构成。如何在异构平台域控制器上实现SOA软件架构，实现基于面向服务的通信，以及信号与服务的转换，主要有以下两种方案。
软件实现方案一：在M核进行服务化。将大部分服务部署在M核上，由M核和其他控制器进行基于服务的通信；
优点：M 核现有资产复用度高，基于信号的应用部分改动小；数据传输实时性高。
限制：M 核 SOA 程度较低，部署 SOMEIP 协议，M 核资源占用较大。
软件实现方案二：在A核进行服务化。将大部分服务部署在A核上，由A核和其他控制器进行基于服务的通信，
优点：M 核不需要专门部署 SOME/IP 协议，对 M 核的资源占用少；
限制：需根据芯片特性开发不同 IPC 机制，数据传输的实时性低。
