1. 背景

SOME/IP是一种汽车中间件解决方案，其全称是Scalable Service-Oriented Middleware over IP，即位于 IP 协议层以上的一种面向服务的可扩展的中间件。

• 中间件：该术语起源于复杂的软件系统开发，用以实现软件组件之间的数据交换，这种数据交换通常需要经由网络，中间件的任务就是确保需要交换数据的软件组件在网络中透明地传输数据。SOME/IP 作为一种中间件负责组织传输复杂数据（消息传递）并约定软件组件之间的函数调用（远程过程调用，RPC）。
  如今汽车中的软件数目十分庞大，并且还会随着汽车内部功能和系统的分布扩张而不断增加。这些分布式功能可能使用到一个 ECU 中的不同进程，也可能扩展到不同 ECU 的各种进程中去，随着系统复杂度的增加，不可能仅仅将消息放入到网络中传输就完成功能的实现，还需要使用 RPC 来正确控制这些分布式功能；另外，不同 ECU 可能使用不同的软件架构以及操作系统，因此还需要中间件来桥接不同的便携式操作系统接口（如 Linux 或 QNX 和 AUTOSAR 系统之间的衔接）。
• 可扩展性：表示 SOME/IP 能够实现不同硬件平台、不同操作系统或嵌入式固件以及不同应用软件的异构设备之间的可扩展性和互操作性。
• 面向服务：面向服务通信的概念是与传统汽车电子行业中的面向信号通信相对应的一个概念，面向服务通信是仅当客户端请求或服务器通知特定订阅者时，才在客户端与服务器间交换数据。这确保了不会浪费带宽，并且仅在需要的时间进行数据通信。
  高端信息娱乐系统最需要基于服务提供的复杂接口，如复杂的数据类型、对数据库的访问、列表的传输等。在其他使用车载网络的系统中，CAN 总线的使用仍占主导地位，信息在网络中传输，由接收器决定如何处理该信息。但是，在新型应用领域，如辅助驾驶领域，CAN 的通信方式越来越不适用。另外，在 CAN 中，数据长 8Byte，且没有大量的头信息，这些均限制了 RPC 或服务发现( Service Discovery , SD ）的使用。
• 位于 IP 协议层以上：这表明了 SOME/IP 协议在汽车以太网协议栈中所处的位置，汽车以太网协议栈总共可划分为五层，分别为物理层、数据链路层、网络层、传输层、应用层，SOME/IP 协议是一种应用层协议。
  SOME/IP 是一种汽车中间件解决方案。从一开始就被设计为能够完美适配不同尺寸和不同操作系统的设备，像是小型 ECU 如摄像头、 AUTOSAR ECU、以及信息娱乐 ECU 如车载信息娱乐系统（Head Units），还有远程通信设备等，都可以使用 SOME/IP 协议有效地交换 ECU 间的消息。同时 SOME/IP 还支持信息娱乐领域的功能以及车辆中其他领域的功能，使 SOME/IP 能够用于 MOST 以及更传统 CAN 方案的替换方案。

2. SOME/IP协议

2.1 面向服务的通信

区别于传统 CAN/LIN 等面向信号（Signal-Oriented）的通信方式，SOME/IP 提供面向服务（Service-Oriented）的通信方式。

• 面向信号的通信——为了将信号进行传输；
  • 基于信号的通信解决方案中的软件和硬件紧密耦合，ECU 之间的通信是静态定义的。
  • 基于信号的通信是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。
• 面向服务的通信——为了对服务的相关信息进行传输。
  • 发送方仅在接收方需要时才发送数据。优点在于总线上不会出现过多不必要的数据，从而降低负载，不过这仅仅是基于服务通信的一方面。当谈论到自动驾驶、ADAS、联网汽车等时，面向服务的架构 (SOA) 是必不可少的。在以太网和 SOME/IP 的支持下，SOA 将整个系统建模为 service interface，可以轻松地将新软件添加到系统中，而无需担心与其他软件的兼容性。
    

SOME/IP 为应用程序提供抽象的面向服务的接口，因此，应用程序不需要处理 IP 地址和端口，而只需要处理服务。Server 端提供了一个实现服务接口的服务实例（服务接口，直白理解就是服务与外界通信的接口，也就是服务模块与外界沟通的基本出入口）。Client 端则通过SOME/IP 方式使用服务实例。

2.2 SOME/IP通信机制

• Request & Response Method（双向方法）：客户端发送请求，服务端回复响应，是一种有问有答的对话方式。
• Fire & Forget Method（单向方法）：客户端发送请求，服务端不需要响应，是一种只问不答的对话方式。
• Event（事件）：客户端首先使用了 SOME/IP-SD 订阅（Subscribe）某一事件组（Event Group），当事件组中包含的事件发生之后，服务端就会自动给订阅了该事件的客户端发送相关的通知（Notification），Notification 消息不需要接收方进行回复。请注意，SOME/IP 协议中的 Event 总是分组在一个 Event Group 中,因此只能订阅 Event Group 而不是Event本身。
• Fields（字段）：Field 表示可以远程访问的“属性”，即客户端可以远程访问的服务端中的变量。

2.3 SOME/IP协议报文格式

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

2.3.1 Message ID [32 Bit]

Message ID 用于唯一标识服务的 Method 或 Event，可区分不同的服务。Message ID 对于整个车辆系统来说必须是唯一的 。
Message ID 的结构：

• 前 16 位是 Service ID，每个服务需要有一个唯一的服务 ID，由系统集成商进行标识。
• 后 16 位是 Method ID。
  对于 Method ，Message ID 的结构如下：
  
  其中 Method ID 的第一个位（bit）是 0。使用 16 位的 Service-ID 和从 0 位开始的16位的 Method-ID (对于实际值，Method-ID中还剩下15位)，这将允许最多 65536个服务，每个服务最多 32768 个方法。
  对于 Events 和 Notifications ，Message ID 的结构如下：

对于 Events 来说，Method ID 的第一个位（bit）是 1。这意味着每个服务最多可以有32768 个事件或通知。

Method ID 的最高位可用来判断具体的通信方式，即采用的是 Method 还是Event 。

2.3.2 Length [32 Bit]

Length 字段长度为 32位，包含从 Request ID 开始到 SOME/IP 消息结束的长度，长度是以字节为单位的。注意，Length 不包括 Message ID 和 Length 。

2.3.3 Request ID [32 Bit]

Request ID 是客户端的唯一标识符，要能在响应到达前或超时前不被重用。

• 在生成响应消息时，服务器必须将 Request ID 从请求中复制到响应消息中去，这才使得客户端可以将响应对应到发出的请求上。
  Request ID 前 16 位是 Client ID，用来区分特定的客户端，在整车系统中该值必须唯一；后 16 位是 Session ID，用来标识同一客户端的多次请求。
  

Session ID 主要用于 Request & Response 类型的多次调用，每调用一次，Session ID 增加 1。
如果会话不在活动状态，Session ID 设置为 0x0000，当会话处于活动状态时，Session ID 设置为 [0x0001, 0xFFFF] 范围内的值。当 Session ID 为 0x0000 时，服务器并不会对这个请求作出反应。

2.3.4 Protocol Version [8 Bit]

该字段存放 SOME/IP 协议的版本号，用来识别使用的 SOME/IP 头格式（不包括 payload 的格式）。目前固定为 1。

2.3.5 Interface Version [8 Bit]

该字段存放服务接口的版本号，用来识别服务接口的主版本号。

2.3.6 Message Type[8 Bit]

Message Type 字段用于区分不同类型的消息

2.3.7 Return Code [8 Bit]

Return Code 用来表示请求是否被成功处理。为了简化 header 布局，每个消息中都会传输 Return Code 字段。

2.3.8 Payload [variable size]

Payload 由 Event 的数据元素或 Method 的参数组成，大小取决于所使用的传输层协议，对于UDP，payload 介于 0 到 1400个字节之间，由于 TCP 支持 payload 分段，所以支持更大的长度。
注意：SOME/IP 所有的 Header 字段必须以网络字节顺序(大端字节序)编码。Payload 内参数的字节顺序应由配置来定义。