SOME/IP协议详解[2 SOME/IP通信机制]

目录

2.1 SOME/IP 传输层协议

2.2 SOME/IP-SD服务发现(Service Discovery)

2.2.1 FindService & OfferService服务查找

2.2.2 Subscribe & SubscribeACK服务订阅

2.3 远程进程调用(RPC)

2.3.1 Request/Response

2.3.1.1 规范标准

2.3.2 Fire&Forget

2.3.2.1 规范标准

2.3.3 Notification Event

2.3.3.1 规范标准

2.3.4 Field

2.3.4.1 规范标准

2.3.5 四种通信形式总结

---

本章探讨车载ECU需要按照何种规则来实现数据的传输，因此熟悉这部分内容将对车载以太网SOME/IP的开发与测试至关重要。

2.1 SOME/IP 传输层协议

SOME/IP 使用的传输层协议可以是TCP、UDP或SOME/IP-TP。

• 如果传输的数据长度超过了1400字节，并且没有严苛的时间延迟要求，使用TCP传输
• 如果有时间延迟的要求（小于100毫秒），使用UDP传输
• 如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP-TP；SOME/IP-TP支持UDP之上大数据传输。

具体使用哪一种传输层协议跟具体的应用场景有关，如果以上提到的传输层协议均不能满足需求，用户还可以选择其他协议，比如1722等。

SOME/IP 协议在 OSI 七层网络结构中位于应用层，从功能上讲，SOME/IP是一种将服务接口进行打包或解包的中间件：从应用层发送的数据按照 SOME/IP 的格式打包后，再传递到下层的 TCP/IP 或 UDP/IP层，再进行逐层打包和封装，最终通过物理层以比特流的形式进行传输；接收时则按照与打包相反的规则进行解包。见下图：

2.2 SOME/IP-SD服务发现(Service Discovery)

SD机制是SOME/IP实现服务信息共享的核心机制，如其全称ServiceDiscovery，它实现了服务发现的功能，主要是为了实现在车载以太网中告知客户端当前服务实例的可用性及访问方式。

要了解SD需要首先了解SOME/IP的通信架构，SOME/IP服务于分布式系统，采用服务器客户端无规则分布模式，即任何一个车内以太网节点都可能是Server或是Client，甚至是同时作为Server和Client。

服务发现分为两个过程，SOME/IP通过这四种报文来实现服务发现：

• 一个是查找和提供服务的过程，即FindService和OfferService
• 一个是订阅和响应的过程，即Subscribe和SubscribeACK

在通过SOME/IP协议传输数据之前，我们需要知道当前整个车载网络到底存在哪些服务，服务的可用性如何，客户端如何订阅服务端所提供的服务。

如下图5所示即为SOME/IP-SD的基本功能，展现了Client与Server之间的交互关系。

图5 SOME/IP-SD Client与Server交互关系图

由上图可知，SOME/IP 服务发现流程可以分为以下三大基本步骤：

• Client通过发送Find Service的报文去寻找车载网络中可用的服务实例；
•         Server接收到Client的Find Server后通过UDP发送Offer Service响应；
• Client通过发送Subcribe Event Group去订阅相关Event；

        Server检查Client是否满足订阅条件，如果满足回复ACK，如果不满足，则回复NACK；

在SOME/IP协议中，Event Group ID是一种用于标识一组相关事件的机制。

Event Group ID由32位无符号整数表示，每个服务实例可以定义多个Event Group ID。一个Event Group ID通常对应于一组相关事件，例如同一服务实例上的不同状态变化事件或不同错误类型的事件。

当一个服务实例需要向其它服务实例或客户端通知事件发生时，它可以使用Event Group ID来标识这些事件。例如，当一个服务实例的状态发生变化时，它可以向其它服务实例或客户端发送一个事件通知，其中包含该状态变化事件的Event Group ID。

使用Event Group ID可以将相关事件分组，并使其易于管理和监视。例如，当一个服务实例发送一个事件通知时，其它服务实例可以根据Event Group ID过滤接收到的通知，只处理他们感兴趣的事件。这可以减少不必要的网络流量和处理负担，提高系统的效率和可靠性。

此外，Event Group ID还可以用于路由事件通知。当一个服务实例发送一个事件通知时，其它服务实例可以根据Event Group ID将通知路由到正确的接收方，以确保通知被正确处理。这可以帮助服务实例和客户端更好地管理和处理事件通知，提高系统的可维护性和可扩展性。

总之，Event Group ID在SOME/IP协议中具有重要作用，它帮助服务实例和客户端管理和处理事件通知，提高了系统的可靠性、效率、可维护性和可扩展性。

• Client成功订阅相关事件后，Server会按照事件本身属性来实现对已订阅该事件的Client的发布；

SD的概括性通信模式图如下：

2.2.1 FindService & OfferService服务查找

• 使用场景

FindService由Client端启动时发出，OfferService由Server端发出，分别用于查找所需的服务，和通告所提供的服务。要想了解这两种报文的发送机制，不得不提及SOME/IP的启动行为。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休眠或关机。

• 报文特征

FindService& OfferService的报文格式的Entry部分与订阅报文略有区别，每个字段都有其相应作用，详见本文章节5.2.1。

• 知识点总结

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.2.2 Subscribe & SubscribeACK服务订阅

• 使用场景

订阅发生在Main Phase，Client端在收到所需服务的OfferService之后，判断该服务是否包含所需的事件组，若包含，则向该OfferService包含的节点信息发送Subscribe报文。当Server端收到订阅请求之后，若服务有效应理解发送SubscribeACK，进行应答（订阅TCP服务需要先建立TCP连接）。

• 报文特征

Subscribe报文的Entry格式，详见本文章节5.2.2。

• 知识点总结

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连接

• 订阅例子（来自于page 45 of AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol）

2.3 远程进程调用(RPC)

远程进程调用主要可分为四种通信模式，见下面四小节。

2.3.1 Request/Response

Request/Response通信模式，可归纳为Method中的一种。

Request-Response模型作为一种最为常见的通信方式，其主要任务就是客户端发送请求信息，服务端接收到请求，进行相关处理之后进行相应的响应。其基本通信模型如下图6所示。

图6 Request-Response通信模型

2.3.1.1 规范标准

Request/Response Communication请求/响应通信

One of the most common communication patterns is the request/ response pattern. One communication partner (in the following called the client) sends a request message, which is answered by another communication partner (the server).

最常见的通信模式之一是请求/响应模式。 客户端发送请求消息，服务器端应答。

Client

• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field
• Optionally set the Request ID to a unique number
• Set the Protocol Version according
• Set the Interface Version according to the interface definition
• Set the Message Type to Request (i.e. 0x00)
• Set the Return Code to 0x00

Server

• builds it header based on the header of the client ,and in addition
• Construct the payload
• Set the length to the 8 Bytes + new payload size
• Set the Message Type to RESPONSE (i.e. 0x80) or ERROR (i.e. 0x81)
• Set the Return Code

Mapping

For the response and error message the IP addresses and port number of the transport protocol shall match the request message.

对于Response和Error message，传输层的IP Address和Port口需要和Request message匹配：

2.3.2 Fire&Forget

Fire&Forget通信模式，可归纳为Method中的一种。

该通信模型的主要任务就是客户端向服务端发送请求，服务端无需进行任何响应，有点类似诊断服务中的抑制正响应。

图7 Fire&Forget通信模型

2.3.2.1 规范标准

Fire&Forget Communication

Requests without response message are called fire&forget.

请求但不需要回复的消息成为fire&forget 。

The implementation is basically the same as for Request/Response with the following differences:

其实现基本上和for Request/Response 一样，只有如下的区别：

• There is no response message.

        没有response消息。

• The message type is set to REQUEST_NO_RETURN (i.e. 0x01).

        message type设置为REQUEST_NO_RETURN (如0x01)。

• Fire & Forget messages shall not return an error. Error handling and return codes shall be implemented by the application when needed.

        Fire & Forget消息不能返回error，如果需要的话，error处理和返回值由应用程序实施 。

2.3.3 Notification Event

Notification Event通信模式。

该通信模式主要描述了发布/订阅消息内容，主要任务就是为了实现客户端向服务端订阅相关的事件组，当服务端的事件组发生或者值发生变化时，就需要向已订阅该事件组的客户端发布更新的内容。

客户端首先使用了 SOME/IP-SD 订阅（Subscribe）某一事件组（Event Group），当事件组中包含的事件发生之后，服务端就会自动给订阅了该事件的客户端发送相关的通知（Notification），Notification 消息不需要接收方进行回复。请注意，SOME/IP 协议中的 Event 总是分组在一个 Event Group 中，因此只能订阅 Event Group 而不是Event本身。

图8 Notification event通信模型

2.3.3.1 规范标准

1. Notification Events 通知事件

• Notifications describe a general Publish/Subscribe-Concept. Usually the server publishes a service to which a client subscribes. On certain events the server will send the client a event, which could be for example an updated value or an event that occurred.

        Notification描述了一般的发布/订阅概念。通常，服务器端发布服务而客户端前来订阅。在某些事件上，服务器端向客户端发送event，该event可以是例如更新的值 或者发生的事件。

• SOME/IP is used only for transporting the updated value and not for the publishing and subscription mechanisms. These mechanisms are implemented by SOME/IP-SD.

        SOME / IP仅用于传输更新的值，而不用于发布和订阅机制。这些机制由SOME / IP-SD实现 。

• When more than one subscribed client on the same ECU exists, the system shall handle the replication of notifications in order to save transmissions on the communication medium. This is especially important, when notifications are transported using multicast messages.

        当同一ECU上有多个订阅客户端时，系统应对notification进行复制以便节省通信介质上的传输。当使用多播消息传输通知时，这尤其重要。

2. Strategy for sending notifications发送notification的策略

For different use cases different strategies for sending notifications are possible and shall be defined in the service interface. The following examples are common:

对于不同的用例，可以使用不同的发送通知策略，并且应在服务接口中定义。 以下是常见的例子： 

• Cyclic update循环更新

        send an updated value in a fixed interval (e.g. every 100 ms for safety relevant messages with Alive).

        以固定间隔发送更新值（例如，每100毫秒用于Alive的安全相关消息）。

• Update on change变化更新

        send an update as soon as a “value” changes (e.g. door open).

        一旦“值”发生变化（例如开门）就发送更新。

• Epsilon change Epsilon更改

        only send an update when the difference to the last value is greater than a certain epsilon. This concept may be adaptive, i.e. the prediction is based on a history; thus, only when the difference between prediction and current value is greater than epsilon an update is transmitted.

        仅当与最后一个值的差异大于某个阈值时才发送更新。 该概念可以是自适应的，比如预测是基于历史值; 因此，只有当预测值和当前值之间的差值大于epsilon时才发送更新。

2.3.4 Field

访问进程控制（Field）。

访问进程通信机制主要是为了实现针对对应用程序的数据获取与更改，主要任务就是实现客户端通过Getter获取Server的值，通过Setter设置Server的值。

Field就可理解为一个Service的基本属性，可包含Getter，Setter，Notifier三种方式。其中Getter就是读取Field中某个值的方法，Setter就是一种改变Field值的方法，而Notifier则是一种当Field中的值发生变化的触发事件。

图9 Field的通信模型

由上图可知，在Getter与Setter的方式中我们使用的Request/Response机制。在Getter的请求报文中是一个空的Payload，响应报文中的Payload才是需要获取的值；使用Setter请求时，请求消息中的Payload则是要设置的值，如果设置成功，那么响应报文中Payload就是设定成功的值。

同时我们也可得出服务实体在SOME/IP协议中是一个十分重要的概念。一个服务实体可以是Field，Events以及Method的任意组合。

2.3.4.1 规范标准

Fields

• A field shall be a combination of getter, setter and notification event.

        field应为getter，setter和notification事件的组合。

• A field without a setter and without a getter and without a notifier shall not exist. The field shall contain at least a getter, a setter, or a notifier.

        不存在没有setter且没有getter且没有notifier的field。 该field应至少包含一个getter，一个setter或一个notifier。

• The getter of a field shall be a request/response call that has an empty payload in the request message and the value of the field in the payload of the response message.

        field的getter应是一个请求/响应调用，其request消息中payload为空，response消息中payload中的值就是field的值。

• The setter of a field shall be a request/response call that has the desired value of the field in the payload of the request message and the value that was set to the field in the payload of the response message.

        field的setter应是一个请求/响应调用，其将field的期望值放在request消息的payload中，这个值被设置到response消息的payload中。

• Note注意：

        If the value of the request payload was adapted (e.g. because it was out of limits) the adapted value will be transported in the response payload.

        如果request消息中 payload的值被调整了（例如，因为它超出限制），则这个调整后的值将放在response消息的有效载荷中发送。

        The notifier shall send an event message that transports the value of a field on change and follows the rules for events.

        如果该field的值改变，notifier应发送一个event消息以传输该值，当然，要遵循event规则。

2.3.5 四种通信形式总结

客户端可以通过远程调用 Getter 方法获取 Field 的值，也可以通过远程调用 Setter 方法设置 Field 的值。另外，和 Event 相似，当客户端订阅了某个事件组，若Event Group中包含的 Field 发生变化，服务端会主动的通过 Notification 消息通知客户端；当然，用户也可以选择周期发送Notification 消息。

Field 和 Event 的区别是：

1. Field 是一个持续存在的变量，比如多媒体音量、车速、环境温度等，这些可以在任何时刻获取；
2. 而 Event 指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。

下面看一个实际的例子来对这些通信模式产生更具体的印象：