车载以太网-SOME/IP简介

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

SOME/IP (Scalable service-Oriented MiddlewarE over IP) 是车载以太网通信引入的一个概念，位于OSI 7层模型的层4(传输层)之上。

• 在以CAN总线为主的车载网络中，通信过程是面向信号的（除了诊断通信之外），这是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。

• 而SOME/IP则不同，它是在接收方有需求的时候才发送，这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载。

• 在车载网络中，某个ECU有时会需要调用实现在其他ECU上的个服务，这个时候它俩就分别扮演了client和server的角色，而SOME/IP就是实现这种远程服务调用的接口

• 如下图所示

服务的远程调用

• 序列化（Serialization）：它是数据在数据单元中的表示方式，可以是UDP或TCP消息。当数据在网络上传输时，读取数据的电子控制单元（ECU）可能具有不同的体系结构、操作系统等。只有当存在一种机制来实现一致的数据传输时，才能确保互操作性。SOME/IP允许进行某些序列化。

• 远程过程调用（Remote Procedure Call，RPC）：这是一种远程调用函数的方法，由客户端ECU请求。当客户端ECU需要从服务器获取一些数据时，它使用RPC进行数据交换。RPC可能有返回值，也可能没有返回值，即客户端可以请求数据作为响应，也可以仅调用函数在服务器端执行某些任务。

• 服务发现（Service Discovery）：服务发现（SD）协议是SOME/IP概念的支柱。在面向服务的体系结构中，服务（功能实体-方法、事件或字段）必须是可发现的。SOME/IP SD协议管理此方面-是否提供服务或停止使其可用。

• 发布/订阅（Publish/Subscribe）：客户端可以订阅服务器的内容，以便动态接收服务器的更新数据。SOME/IP的发布/订阅功能推断客户端需要哪些数据（事件/字段）并共享这些数据。Pub/Sub由SOME/IP SD管理。

到目前为止，我们已经了解了面向服务的体系结构的概念以及SOME/IP在其中的实现中的作用。现在，我们将深入了解SOME/IP和以太网如何实现ECU之间的客户端/服务器通信。

在开始探索之前，我们必须了解一些与SOME/IP相关的术语。

• 服务：由事件、方法或字段组合而成的接口

• 服务实例：服务的单个实例；它实现了服务接口

• 事件：服务器向客户端发送的消息，表示某些事件发生了

• 字段：服务的一部分，表示状态，因此始终具有一个值

• Getter/Setter：读取/写入字段属性的请求/响应调用

• 事件组：多个事件的逻辑组合

• 方法：可以被调用的函数、子例程或过程

• 通知器：负责在字段值更改时发送事件消息

• 通知事件：由通知器发送的事件消息

SOME/IP数据在以太网报文中的位置

SOME/IP作为ECU间通信协议的附加价值

SOME/IP作为ECU间通信协议的附加价值在于，它使得面向服务的体系结构成为可能。它不仅使整个车辆网络具有动态性和灵活性，而且提供了实现CPU密集型应用所需的骨干。

让我们看看SOME/IP带来的其他优点：

1. 更容易向车辆电子系统添加新功能。

2. 作为连接生态系统的一部分，为车辆系统提供所需的灵活性。

3. 可以使用事件和方法使用以太网实现复杂的服务接口。

4. 它支持单播和组播。

5. 引入事件、通知器等可以降低数据路径的复杂度。
   SOME/IP在汽车行业中的常见应用

总体情况

SOME/IP是一款巧妙设计的中间件，具有CAN、MOST和FlexRay的特性以及备受追捧的面向服务的通信。它与另一项开创性技术——自适应AUTOSAR的合作已经引起了人们的关注。它们共同具有改变汽车软件开发和集成到ECU网络的方式的潜力。

从上面这个图可以看出来，SOME/IP其实是构架在传输层之上的应用层通信协议，它的内容虽然很多很杂，但本质上也就是定义了SOME/IP 包头和数据的内容而已。

上图是SOME/IP数据的格式，除了最下面的Payload之外都属于SOME/IP的header。SOME/IP消息由报头header和有效负载Payload组成。

• 消息ID：服务ID和事件/方法ID的组合

• Length：包含从请求ID到SOME/IP消息结束的长度（以字节为单位）

• 请求ID：允许提供者和订阅者区分同一方法、事件、getter或setter的多个并行使用

• 协议版本：包含SOME/IP协议版本的8位字段

• 接口版本：包含服务接口主要版本的8位字段

• 消息类型：用于区分消息类型

• 返回码：用于指示请求是否已成功处理。

Message Type [8 Bit]，它有以下几种取值：

• REQUEST （期待响应的请求）

• REQUEST_NO_RETURN（不期待响应的请求）

• NOTIFICATION（事件通知）

• RESPONSE（响应消息）

• ERROR（报错消息）

REQUEST，REQUEST_NO_RETURN，RESPONSE属于同一类远程过程调用方法，当client有需求的时候，发送一个request消息，server根据这个消息类型（REQUEST或REQUEST_NO_RETURN）来决定是否发送response消息。过程如下图所示。

方法调用过程

NOTIFICATION属于事件通知类的服务，首先由client向server订阅服务内容，然后server向client自动发布服务内容。

Event Notification

Field Notification

NOTIFICATION又分为Event和Field 两类，这两类通知都需要首先使用SOME/IP-SD(Service Discovery)来进行服务订阅，然后才能发布通知。

区别在于，Event是某一时刻的快照，只是事件通知，而Field除了事件通知之外，还具有Getter和Setter的功能，即对信息进行读写的操作。

SOME/IP-SD可以被当作SOME/IP的一种特殊服务，前面提到过，client可以远程调用server提供的服务，或者订阅server发布的内容，那么client是怎么知道server提供哪些服务呢，就是通过SOME/IP-SD来实现服务发现过程的。

SOME/IP-SD的报文格式

从上图可见，SOME/IP-SD是一种特殊的SOME/IP格式，它对SOME/IP-SD报文中的Payload进行了定义和实现。而Message ID字段则是固定的0xFF FF 81 00。

SOME/IP-SD提供了两种动态发现服务的机制。

1. 一种是Offer Service ，由server向网络上的小伙伴告知它所提供的服务。

2. 另一种是Find Service ，由client向别人请求可用的服务。

本文只是简要介绍，不对通信过程和协议内容做过多分析。

这上面有与SOME/IP相关的全部详细信息。

SOME/IP的功能

1、数据的序列化和反序列化

将网络中的对象，比如结构体或者字符串转换成二进制流进行传输的过程。娱乐信息的控制器可以支持8Byte对齐，所有的ECU应至少支持4Byte对齐序列化要求字节对齐，提高CPU的访问效率。

2、RPC远程调用机制

远程调用机制包括以下几种：

• 请求/响应（R/R）通信

客户端发送一条Request消息，该消息由服务端Response。（带返回值的函数调用）

▲ 图3：请求/响应（R/R）通信

• 焚烧 & 忘记（F & F）通信

客户端向服务器调用方法，无需服务器响应消息的请求称为fire＆forget。（空函数调用）

▲ 图4：焚烧&忘记（F/F）通信

• 通知事件（Notification Event）

与CAN报文类似，当客户端订阅Event Group后，当发生某些特定事件时（周期更新、值发生改变或值改变了ε），服务器就会给客户端发送Event报文。（应用数据转换）

▲ 图5：Notification Event通信

• 域（Field）

Field是Getter、Setter和Notifier的组合。Getter是一个请求/回应调用，请求报文的payload为空，Field的值置于响应报文的payload中。同样Setter也是一个请求/回应调用，将要设置的Field的值置于请求报文的payload中，响应报文的payload也要放置Field设置的值。Notifier同Event类似，Field中的事件报文在Field值更新时会发送出来，但遵循事件发送规则。

▲ 图6：Notification Event通信

AP AUTOSAR

1、ara::com---通讯管理接口

其可实现应用之间的函数调用和事件发送

服务请求：双向数据流，即发送请求者会收到服务端的反馈，可支持多对1的服务请求，即单个服务可被不同客户端调用，客户端可串行或并行进行反馈，具体流程如下：

事件发送：由客户端发起，单向数据流。即数据只可从服务端向客户端流动，支持单个服务向多个客户端的事件发送，流程如下：

3、管理整个网络中服务的状态

• 通信机制

SOME/IP通过以太网提供面向服务的通讯，采用SOME/IP-Service Discovery定位服务实例，并检测服务的运行状态，同时发布订阅处理功能。

▲ 图7：Service Discovery的作用

客户端收到需要的服务，会发送订阅报文，服务端给出订阅ACK后，开始发送Event。所有需要Event或NotificationEvent的客户端必须在运行时间中利用SOME/IP-SD在某个server上注册。

▲ 图8：订阅与Event发送（源自SOME/IP Service Discovery ProtocolSpecification）

1.服务发现通信行为

对每一个服务实例或事件组，服务发现在发送条目时必须至少包含初始等待阶段、重复阶段和主阶段。

2.初始等待阶段

随机等待一段时间后发送报文（发现服务和提供服务条目）。

3.重复阶段

服务发现实现时必须在重复阶段等待一段时间，且发送的条目数量有限制。如果发送的条目数量设置为0，则必须跳过重复阶段。在初始等待阶段之后服务实例进入主阶段。

4.主阶段

在进入主阶段之后，必须等待一段时间后发送第一条报文，循环发送提供服务报文。

当某ECU的服务实例停止服务时，必须发送停止提供服务条目。服务端的状态机如下图所示：

▲ 图9：服务端的状态机（源自SOME/IP Service Discovery Protocol Specification）

客户端在Down阶段如收到提供服务条目，可内部调用服务请求；如未收到提供服务条目，则进入初始等待阶段等待一段时间后进入重复阶段发送报文，接收到提供服务条目，进入主阶段。当收到服务实例停止服务时，服务停止，仍停留在主阶段。客户端的状态机如下图所示：

▲ 图10：客户端的状态机（源自SOME/IP Service Discovery Protocol Specification）

SOME/IP与AUTOSAR

在CP AUTOSAR架构中：

SOME/IP-SD模块位于AUTOSAR BSW Mode Manager module（BswM）和AUTOSAR Socket Adaptor module (SoAd)之间

如图11所示：

BswM模块提供了通用模式请求和服务请求之间的连接。

SoAd模块则处理以太网堆栈和Sd模块之间的服务请求。

通过配置SoAd中的SocketConnection表，可以接收其他ECU的Sd模块发来的单播和多播报文。

▲ 图11：AUTOSAR SOME/IP-SD模块交互（源自Specification of Service Discovery）

来源：

https://zhuanlan.zhihu.com/p/48424110