关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
SOME/IP(Scalable service-Oriented MiddlewarE over IP)是指基于 IP 的可扩展的面向服务的中间件。SOME/IP 协议于 2011 年由 BMW 集团的 Dr. Lars Völker 设计，是一种面向服务的车载以太网通信协议，位于 TCP/UDP 之上，兼容当前国际共同探讨的基础软件开发平台。SOME/IP 协议采用 C/S（Client/Server）的通信架构，其中 Server 是服务提供者，Client 是服务消费者。根据服务接口类型，使用远程服务调用（Remote Procedure Call）机制，通过数据序列化和反序化（Serialization/Deserialization）使得数据得以在网络中传输。通过可用服务发现 SD（Service Discovery）机制来实现服务的动态配置。① 数据序列化与反序列化（Serialization/Deserialization）：服务通信数据与二进制数据流之间的双向转换；② 可用服务发现（SD）：管理服务状态，发现和提供服务，动态配置 SOME/IP 报文发送；③ 服务发布与订阅（Publish/Subscribe）：管理服务的发布与订阅关系；④ 远程服务调用（RPC）：实现控制器（Client）使用网络内其他控制器（Server）提供的服务。SOME/IP 协议以服务元素为单位管理数据信息，服务元素可分为 Event、Method、Field 三种类型。Event 是一种单向的数据传输方式，由 Server 向其订阅者发布服务事件；Method 是一种远程函数调用的通信方式；Field 类似于 Event 和 Method 的结合体，允许 Client 获取 / 设置 / 订阅 Server 端事件的状态信息。通过 Service Interface 实现数据信息的传输与共享。基于 SOME/IP 通信协议，以两个控制器为例，空调 ECU 作为 SOME/IP 服务提供者（Server），中控作为SOME/IP服务请求者(Client)，两个控制器分别以Event、Method、Field服务元素实现其通信行为，示意图如下图。① Client 可通过 Method 封装 Request 消息对 Server 进行远程方法调用（RPC）；② Server 对于 Method 调用的执行结果可通过封装 Response 消息返回给 Client（Request & Return），或者不需要 Server 返回消息（Fire & Forget）；① Getter:Client 主动获取 Field 值；② Setter:Client 主动设置 Field 值；③ Notifier:Server 达到触发条件后向订阅的 Client 发送 Field 最新值；① 由 Server 向 Client 单向发送消息；② 可周期发送或根据事件状态（如值改变、特定条件满足等）发送通知类消息；随着汽车通信总线及整车电子电气架构的不断发展，基于 CAN 总线的面向信号的通信模式已不能满足智能汽车 SOA 架构的发展要求，SOME/IP 协议是当前汽车通信实现 SOA 架构最核心的通信协议之一。SOME/IP 协议被广泛应用于车载以太网控制器中，尤其是智驾域、座舱域、车身域控等通信数据量大、对通信带宽要求高的控制器中。另外，基于 SOME/IP 实现 Signal to Service 的转换，也已经是域控制器中必不可少的技术。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 对服务进行订阅，然后再用 SOME/IP 里的 Notification 类型消息发布订阅内容。SOME/IP-SD 报文主要有以下几类：① OfferService：Server 服务 Ready 并满足服务发布条件后，主动发出 OfferService 报文，告知组播内其他节点，该服务已经启动，可以创建服务连接。② FindService：当 Client 在网络中未收到相关服务的 OfferService 报文或者暂时未收到，而 Client又需要访问该服务，那么 Client 可以发送 FindService 报文主动寻找服务，如果 Server 服务 Ready，会回复 OfferService 报文。③ StopOfferService：当 Server 发现服务不可用，不满足服务发布条件时，会主动发送 StopOfferService 报文，告知组播内其他节点，该服务已不可用，停止服务支持。④ Subscribe：事件组的交互采用 “订阅 - 发布” 机制，当 Client 收到 OfferServic 报文之后，通过发送 Subscribe 报文主动跟 Server 订阅相关事件组。⑤ SubscribeACK/SubscribeNACK：当 Server 收到 Client 的订阅报文之后，需要先行判断是否符合可订阅的条件，如果该 Client 满足事件组订阅条件，则发送 SubscribeACK，告知 Client 订阅成功。当事件组内的事件准备就绪之后，Server 会以约定好的形式发送相关事件给成功订阅的 Client。如果该Client 不符合事件组订阅条件，Server 会直接回复 SubscribeNACK，告知订阅不成功。⑥ StopSubscribe：当 Client 订阅某个事件组之后，发现后续并不在需要该事件组的数据了，可发送 StopSubscribe 报文向 Server 取消订阅相应事件。服务端和客户端的通信行为如图 4.5-5 所示，包含以下几个阶段：在这个阶段，Service 是不可用的，即服务端无法提供服务。- 当服务准备完毕 (Available) 后，进入此阶段。
- 如果此阶段收到 Find Service 报文，服务端忽略此消息，不做任何处理。
- 如果服务不可用了，将返回进入 Down Phase。
- 此阶段需要定义时间参数 INITIAL_DELAY_Min 和 INITIAL_DELAY_Max，初始化时间取其之间的随机值，当定时器超时后，发送第一帧 OfferService，标志着进入下一个阶段。
为了让客户端快速找到有哪些 Service，此阶段重复发送 OfferService，重复次数由 REPETITIONS_MAX 决定。发送间隔以 REPETITIONS_BASE_DELAY 为基本时间，每发送一次，间隔是前一间隔的 2 倍。如果收到某客户端的 FindService，不影响当前阶段的发送计数和计时，延迟一定时间 (REQUEST_RESPONSE_DELAY) 后，单独发送单播 OfferService 给服务请求端。如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器。如果收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器如果服务不可用，离开此阶段进入 Down Phase，并发送 StopOfferService 通知所有客户端。此阶段将周期性发送 OfferService，周期时间为 CYCLIC_OFFER_DELAY。如果收到某客户端的 FindService，不影响发送计数，延迟一定时间 (REQUEST_RESPONSE_DELAY) 后，发送单播 OfferService 给服务请求端。如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器。收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器。如果服务不可用，离开此阶段进入 Down Phase，并发送 StopOfferService。
服务端状态机转换图如下图所示。收到 OfferService，存储当前服务实例状态，启动 TTL 计时器，此时服务若被应用请求，直接进入 Main Phase。等待 INITIAL_DELAY 时间（最大和最小值之间的随机值）。如果此时收到 Offer Service，则取消计时器，直接进入 Main Phase。计时器超时后，发送第一个 Find service，进入下一阶段。重复发送 Find service，重复次数由 REPETITIONS_MAX 决定，发送间隔以 REPETITIONS_BASE_DELAY 为基时间，每发送一次，间隔加倍。收到 Offer Service，停止发送计数和计时，立即进入 Main Phase，触发发送 SubscribeEventgroup( 延迟一定时间）。如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送 StopSubscribeEventgroup。收到 Offer Service，触发发送 SubscribeEventgroup( 延迟一定时间）。如果收到 StopOfferService，则停止所有计时器。如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送StopSubscribeEventgroup。
SOA 是一种面向服务的架构模型。它可以根据需求将不同的应用服务进行拆分，并通过定义好的服务接口联系起来，从而使得在构建不同系统时，服务可以以一种统一的方式进行交互。在基于 SOA 的软件架构中，服务是最小的功能逻辑块。为了实现一项功能，整车的某个或某些子系统需要进行数据交互，而数据交互的接口就是服务的接口。服务通过服务接口实现信息的交互，进而完成服务本身的功能。SOA 的关键技术是要求有统一的、标准的通信协议及中间件。SOME/IP 作为一种基于车载以太网协议的、面向服务的灵活中间件，解决 SOA 通信的中间件技术。
根据当前的汽车电子电气架构，汽车将主要由中央域控制器及区域控制器构成。如何在异构平台域控制器上实现 SOA 软件架构，实现基于面向服务的通信，以及信号与服务的转换，主要有以下两种方案。软件实现方案一：在 M 核进行服务化。将大部分服务部署在 M 核上，由 M 核和其他控制器进行基于服务的通信，如下图所示。优点：M 核现有资产复用度高，基于信号的应用部分改动小；数据传输实时高。限制：M 核 SOA 程度较低，部署 SOMEIP 协议，M核资源占用较大。
软件实现方案二：在 A 核进行服务化。将大部分服务部署在 A 核上，由 A 核和其他控制器进行基于服务的通信，如下图所示。优点：M 核不需要专门部署 SOME/IP 协议，对 M 核的资源占用少；限制：需根据芯片特性开发不同 IPC 机制，数据传输的实时性低。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
