分享

SOME/IP协议介绍

 ZHAOHUI 2022-12-10 发布于上海

SOME/IP(Scalable service-Oriented MiddlewarE over IP)是指基于 IP 的可扩展的面向服务的中间件。SOME/IP 协议于 2011 年由 BMW 集团的 Dr. Lars Völker 设计,是一种面向服务的车载以太网通信协议,位于 TCP/UDP 之上,兼容当前国际共同探讨的基础软件开发平台。

01.
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)提供的服务。

02.
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服务元素实现其通信行为,示意图如下图。

图片

Method 服务元素示例如下图所示。

① Client 可通过 Method 封装 Request 消息对 Server 进行远程方法调用(RPC);

② Server 对于 Method 调用的执行结果可通过封装 Response 消息返回给 Client(Request & Return),或者不需要 Server 返回消息(Fire & Forget);

③ 需要事先向 Server 订阅服务(SD)。

图片

Field 服务元素示例如下图所示。

① Getter:Client 主动获取 Field 值;

② Setter:Client 主动设置 Field 值;

③ Notifier:Server 达到触发条件后向订阅的 Client 发送 Field 最新值;

④ 需要事先向 Server 订阅服务(SD)。

图片

Event 服务元素示例如下图所示。

① 由 Server 向 Client 单向发送消息;

② 可周期发送或根据事件状态(如值改变、特定条件满足等)发送通知类消息;

③ 需要事先向 Server 订阅服务(SD)。

图片

03.
SOME/IP 协议技术价值及车载应用场景

随着汽车通信总线及整车电子电气架构的不断发展,基于 CAN 总线的面向信号的通信模式已不能满足智能汽车 SOA 架构的发展要求,SOME/IP 协议是当前汽车通信实现 SOA 架构最核心的通信协议之一。

SOME/IP 协议被广泛应用于车载以太网控制器中,尤其是智驾域、座舱域、车身域控等通信数据量大、对通信带宽要求高的控制器中。另外,基于 SOME/IP 实现 Signal to Service 的转换,也已经是域控制器中必不可少的技术。

04.
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 端)了解到某服务状态后,能够调用该服务的相关内容。

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 发现服务不可用,不满足服务发布条件时,会主动发送 StopOfferService 报文,告知组播内其他节点,该服务已不可用,停止服务支持。

④ 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 所示,包含以下几个阶段:

图片

⑦ 服务端通信行为:

服务端通信行为如下图所示。

图片

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。
服务端状态机转换图如下图所示。

图片

⑧ 客户端通信行为

客户端通信行为如下图所示。

图片

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,触发发送 SubscribeEventgroup( 延迟一定时间)。

如果服务请求被释放,进入 Down Phase,若此时有订阅行为,则发送 StopSubscribeEventgroup。

d. Main Phase

不再周期发送 Find Service。

收到 Offer Service,触发发送 SubscribeEventgroup( 延迟一定时间)。

如果收到 StopOfferService,则停止所有计时器。

如果服务请求被释放,进入 Down Phase,若此时有订阅行为,则发送StopSubscribeEventgroup。

客户端状态机转化图如下图所示。 

图片


05.
SOME/IP 在 SOA 中的应用

(1) 基本概述

SOA 是一种面向服务的架构模型。它可以根据需求将不同的应用服务进行拆分,并通过定义好的服务接口联系起来,从而使得在构建不同系统时,服务可以以一种统一的方式进行交互。在基于 SOA 的软件架构中,服务是最小的功能逻辑块。为了实现一项功能,整车的某个或某些子系统需要进行数据交互,而数据交互的接口就是服务的接口。服务通过服务接口实现信息的交互,进而完成服务本身的功能。

SOA 的关键技术是要求有统一的、标准的通信协议及中间件。SOME/IP 作为一种基于车载以太网协议的、面向服务的灵活中间件,解决 SOA 通信的中间件技术。

(2) 在域控制器中的典型应用

根据当前的汽车电子电气架构,汽车将主要由中央域控制器及区域控制器构成。如何在异构平台域控制器上实现 SOA 软件架构,实现基于面向服务的通信,以及信号与服务的转换,主要有以下两种方案。软件实现方案一:在 M 核进行服务化。将大部分服务部署在 M 核上,由 M 核和其他控制器进行基于服务的通信,如下图所示。

优点:M 核现有资产复用度高,基于信号的应用部分改动小;数据传输实时高。

限制:M 核 SOA 程度较低,部署 SOMEIP 协议,M核资源占用较大。

图片

软件实现方案二:在 A 核进行服务化。将大部分服务部署在 A 核上,由 A 核和其他控制器进行基于服务的通信,如下图所示。

优点:M 核不需要专门部署 SOME/IP 协议,对 M 核的资源占用少;

限制:需根据芯片特性开发不同 IPC 机制,数据传输的实时性低。

图片

本文整理自中国汽车基础软件信息安全研究报告

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多