1. SOME/IP 协议概述
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是指基于 IP 的可扩展的面向服务的中间件。SOME/IP 协议于 2011 年由 BMW 集团的 Dr. Lars Völker 设计，是一种面向服务的车载以太网通信协议，位于 TCP/UDP 之上，兼容当前国际共同探讨的基础软件开发平台。
(1) SOME/IP 协议功能介绍
SOME/IP 协议采用 C/S（Client/Server）的通信架构，其中 Server 是服务提供者，Client 是服务消费者。
根据服务接口类型，使用远程服务调用（Remote Procedure Call）机制，通过数据序列化和反序化（Serialization/Deserialization）使得数据得以在网络中传输。
通过可用服务发现 SD（Service Discovery）机制来实现服务的动态配置。
SOME/IP 主要可以提供以下功能：
① 数据序列化与反序列化（Serialization/Deserialization）：服务通信数据与二进制数据流之间的双向转换；
② 可用服务发现（SD）：管理服务状态，发现和提供服务，动态配置 SOME/IP 报文发送；
③ 服务发布与订阅（Publish/Subscribe）：管理服务的发布与订阅关系；
④ 远程服务调用（RPC）：实现控制器（Client）使用网络内其他控制器（Server）提供的服务。
(2) SOME/IP 协议服务接口介绍
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 服务元素实现其通信行为，示意图如图 4.5-1 所示。
图4.5-1 控制器通信行为示例
Method 服务元素示例如图 4.5-2 所示。
① Client 可通过 Method 封装 Request 消息对 Server 进行远程方法调用（RPC）；
② Server 对于 Method 调用的执行结果可通过封装 Response 消息返回给 Client（Request & Return)，或者不需要Sever 返回消息（Fire & Forget）；
③ 需要事先向 Server 订阅服务（SD）。
图4.5-2 控制器通信行为示例之Method
Field 服务元素示例如图 4.5-3 所示。
① Getter:Client 主动获取 Field 值；
② Setter:Client 主动设置 Field 值；
③ Notifier:Server 达到触发条件后向订阅的 Client 发送 Field 最新值；
④ 需要事先向 Server 订阅服务（SD）。
图4.5-3 控制器通信行为示例之Field
Event 服务元素示例如图 4.5-4 所示。
① 由Server 向 Client 单向发送消息；
② 可可周期发送或根据事件状态（如值改变、特定条件满足等）发送通知类消息；
③ 需要事先向 Server 订阅服务（SD）。
图4.5-4 控制器通信行为示例之Event
(3) SOME/IP 协议技术价值及车载应用场景
随着汽车通信总线及整车电子电气架构的不断发展，基于 CAN 总线的面向信号的通信模式已不能满足智能汽车 SOA 架构的发展要求，SOME/IP 协议是当前汽车通信实现 SOA 架构最核心的通信协议之一。
SOME/IP 协议被广泛应用于车载以太网控制器中，尤其是智驾域、座舱域、车身域控等通信数据量大、对通信带宽要求高的控制器中。另外，基于 SOME/IP 实现 Signal to Service 的转换，也已经是域控制器中必不可少的技术。
2. SOME/IP-SD 协议介绍
(1) 基本概述
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 端）了解到某服务状态后，能够调用该服务的相关内容。
service Instance ID [uint16]:描述此条目所涉及的服务实例的service Instance ID。对于任何实例，服务实例ID都不应设置为0xFFFF。
(2) 主要功能
SOME/IP-SD 有两个主要功能：
- 应用程序之间传达自己的服务或获取对方的服务是否可用。
- 向其他应用程序订阅服务，也就是通过 SOME/IP-SD 对服务进行订阅，然后再用 SOME/IP 里的 Notification 类型消息发布订阅内容。
SOME/IP-SD 报文主要有以下几类：
① OfferService：Server 服务 Ready 并满足服务发布条件后，主动发出 OfferService 报文，告知组播内其他节点，该服务已经启动，可以创建服务连接。
② FindService：当 Client 在网络中未收到相关服务的 OfferService 报文或者暂时未收到，而 Client 又需要访问该服务，那么 Client 可以发送 FindService 报文主动寻找服务，如果 Server 服务 Ready，会回复 OfferService 报文。
③ StopOfferService：当 Server 发现服务不可用，不满足服务发布条件时，会主动发送 StopOffer- Service 报文，告知组播内其他节点，该服务已不可用，停止服务支持。
④ Subscribe：事件组的交互采用 “订阅- 发布” 机制，当 Client 收到 OfferServic 报文之后，通过发送 Subscribe 报文主动跟 Server 订阅相关事件组。
⑤ SubscribeACK/SubscribeNACK：
当 Server 收到 Client 的订阅报文之后，需要先行判断是否符合可订阅的条件，如果该 Client 满足事件组订阅条件，则发送 SubscribeACK，告知 Client 订阅成功。
当事件组内的事件准备就绪之后，Server 会以约定好的形式发送相关事件给成功订阅的 Client。如果该Client 不符合事件组订阅条件，Server 会直接回复 SubscribeNACK，告知订阅不成功。
⑥ StopSubscribe ：当 Client 订阅某个事件组之后，发现后续并不在需要该事件组的数据了，可发送 StopSubscribe 报文向 Server 取消订阅相应事件。
(3) 通信行为
服务端和客户端的通信行为如图 4.5-5 所示，包含以下几个阶段：
图4.5-5 SOME/IP协议服务端和客户端的通信行为阶段
⑦ 服务端通信行为：
服务端通信行为如图 4.5-6 所示。
图4.5-6 服务S端通信行为
a. Down Phase
在这个阶段，Service 是不可用的，即服务端无法提供服务。
b. Initial Wait Phase
· 当服务准备完毕 (Available) 后，进入此阶段。
· 如果此阶段收到 Find Service 报文，服务端忽略此消息，不做任何处理。
· 如果服务不可用了，将返回进入 Down Phase。
· 此阶段需要定义时间参数 INITIAL_DELAY_Min 和 INITIAL_DELAY_Max，初始化时间取其之间的随机值，当定时器超时后，发送第一帧 OfferService，标志着进入下一个阶段。
c. 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 通知所有客户端。
d. Main Phase
· 此阶段将周期性发送 OfferService，周期时间为CYCLIC_OFFER_DELAY。
· 如果收到某客户端的 FindService，不影响发送计数，延迟一定时间 (REQUEST_RESPONSE_ DELAY) 后，发送单播 OfferService 给服务请求端。
· 如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅Entry 的 TTL 计时器。
· 收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器。
· 如果服务不可用，离开此阶段进入 Down Phase，并发送 StopOfferService。
服务端状态机转换图如图 4.5-7 所示。
图4.5-7 服务端S状态机转E换图
⑧ 客户端通信行为
客户端通信行为如图 4.5-8 所示。
图4.5-8 客户端通信行为
a. Down Phase
· 服务未被应用请求。
· 收到 OfferService，存储当前服务实例状态，启动 TTL 计时器，此时服务若被应用请求，直接进入 Main Phase。
b. Initial 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，触发发送 SubscribeEvent- group( 延迟一定时间）。
· 如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送 StopSubscribeEvent- group。
d. Main Phase
· 不再周期发送 Find Service。
· 收到 Offer Service，触发发送 SubscribeEventgroup( 延迟一定时间）。
· 如果收到 StopOfferService，则停止所有计时器。
· 如果服务请求被释放，进入 Down Phase，若此时有订阅行为，则发送 StopSubscribeEvent- group。
客户端状态机转化图如图 4.5-9 所示。
图4.5-9 客户端状态机转换图
3. SOME/IP 在 SOA 中的应用
(1) 基本概述
SOA 是一种面向服务的架构模型。它可以根据需求将不同的应用服务进行拆分，并通过定义好的服务接口联系起来，从而使得在构建不同系统时，服务可以以一种统一的方式进行交互。
在基于 SOA 的软件架构中，服务是最小的功能逻辑块。为了实现一项功能，整车的某个或某些子系统需要进行数据交互，而数据交互的接口就是服务的接口。
服务通过服务接口实现信息的交互，进而完成服务本身的功能。
SOA 的关键技术是要求有统一的、标准的通信协议及中间件。SOME/IP 作为一种基于车载以太网协议的、面向服务的灵活中间件，解决 SOA 通信的中间件技术。
(2) 在域控制器中的典型应用
根据当前的汽车电子电气架构，汽车将主要由中央域控制器及区域控制器构成。
如何在异构平台域 控制器上实现 SOA 软件架构，实现基于面向服务的通信，以及信号与服务的转换，主要有以下两种方案。
软件实现方案一：在 M 核进行服务化。将大部分服务部署在 M 核上，由 M 核和其他控制器进行基于服务的通信，如图 4.5-10 所示。
优点：M 核现有资产复用度高，基于信号的应用部分改动小；数据传输实时性高。
限制：M 核 SOA 程度较低，部署 SOMEIP 协议，M 核资源占用较大。
图4.5-10 域控制器应用-方案一
软件实现方案二：在 A 核进行服务化。将大部分服务部署在 A 核上，由 A 核和其他控制器进行基于服务的通信，如图 4.5-11 所示。
优点：M 核不需要专门部署 SOME/IP 协议，对 M 核的资源占用少；
限制：需根据芯片特性开发不同 IPC 机制，数据传输的实时性低。
SOME/IP 序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式，大多编译器很容易实现；并且采用一字节对齐，序列化后没有冗余数据，报文的有效负载段都是有意义的数据，所以总体传输效率得到了一定提升。另外，SOME/IP 通信报文中的Payload 也会添加时间戳和Rolling Counter等信息，SOC 一侧的应用在使用MCU 传来的数据之前，会先把时间戳取出来，并作数据校验、对齐、分析等工作。SOME/IP 报文结构
SOME/IP 协议均基于UDP 协议开发，它在用户有需求的时候才发送报文，这种方法有以下几点优势：
- 传输效率高。与CAN 等周期性的网络相比，总线上不会出现过多不必要的数据，从而减少了资源消耗，点对点的全双工传输模式也让通信效率变得更高。
- 通信速率快。对于雷达这类较大的数据，需要MCU 能在短时间内及时地将数据传输到SOC，使用以太网是目前各类总线通信中速率最快的，它最能满足大数据量的通信需求。
- 数据长度长。CAN-FD 报文数据长度最大64 字节，LIN 报文数据长度最大8 字节，单帧Flexray报文数据长度最大254 字节，而基于UDP 的以太网单帧报文长度可达1500 字节，能满足大数据的通信需求。
- 实现较简单。以太网已有成熟的TCP/IP 协议栈，基于Linux 平台还有开源的Vsomeip 协议栈，可直接移植使用。
如果这篇没有解决您的问题，可以查看下面这一片：
https://blog.csdn.net/zjfengdou30/article/details/125332151
扫一扫
695
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
