目录
1. SOME/IP简介：
1.1 什么是SOME/IP：
1.2 什么时候使用SOME/IP：
2. SOME/IP的特点：
2.1 序列化：
2.2 远程过程调用（RPC）:
2.3 服务发现：
2.4 发布/订阅：
2.5 UDP消息的分段：
3. SOME/IP如何工作：
4. SOME/IP帧：
4.1 当以消息的形式接收一系列数据时：
4.2 发送SOME/IP SD帧时：
1. SOME/IP简介：
1.1 什么是SOME/IP：
2011年，宝马集团推出了一种中间件协议，用于任何ECU的各种异构单元之间的数据通信，即面向可扩展服务的IP中间件（SOME/IP）。
- 可扩展性意味着该协议旨在实现具有不同硬件平台、操作系统、嵌入式固件和不同应用软件的异构设备之间的可扩展性和互操作性。
- 面向服务意味着数据仅在客户端请求或服务器通知特定订户时，才在客户端-服务器配置中交换。这确保了带宽永远不会被浪费，数据只在需要时进行通信/交换。
- MiddlewarE意味着这是一个中间件协议。它位于应用层，有自己的通用协议层来处理更具体的操作和应用程序。
- 通过IP意味着这是一种基于以太网的协议。数据通过中间件进行通信。它提供了应用层应在网络电缆上使用哪种第4层协议的答案。
- 例如：当客户端需要来自服务器的数据时，它是由客户端使用TCP协议请求的。如果服务器必须将数据传送给所有活动订户，则通过UDP协议传输。UDP协议上的数据通信可以是单播、组播或广播。
1.2 什么时候使用SOME/IP：
SOME/IP用于ECU客户端/服务器之间的序列化。
2. SOME/IP的特点：
作为一种中间件，SOME/IP作为不同的通用协议层提供了许多不同的功能。一些关键特征是：
- 序列化。
- RPC-Remote Procedure Calls： 远程过程调用。
- 服务发现。
- 发布/订阅。
- UDP消息的分段。
2.1 序列化：
序列化是将数据从复杂的数据结构转换为二进制数流的过程，然后可以通过网络传输。
序列化的主要目的是保存数据的当前状态，并在以后的同一系统或不同环境中重建它。
从字节流中恢复数据的反向过程称为反序列化。下图显示了一个示例，其中包含各种基本数据类型的复杂结构被序列化和反序列化。
如果参数有任何更改，序列化有效负载的长度也会更改。为了使解串器知道接收到的有效载荷中参数的确切位置和解串器的长度，保持串行器和解串器之间的某种形式的理解非常重要。此外，应将用户对参数所做的任何更改通知序列化器。在汽车行业，建立串行器和解串器之间理解的解决方案之一是使用包含ECU配置描述的“数据库文件”。当用户对ECU进行任何更改时，他们可以简单地更新有关更改的数据库文件。所有想要访问此ECU的应用程序都会更新有关更改的信息，在访问ECU之前，它们需要读取数据库文件。
2.2 远程过程调用（RPC）:
在SOME/IP中，RPC有以下4种方法：
- 请求/响应方法：在这种方法中，调用函数的请求从客户端发送到服务器，响应从服务器发送回客户端。响应可以是肯定的确认或错误消息。该功能应客户端ECU的请求在服务器ECU上运行。
- Fire and Forget方法：在该方法中，调用函数的请求从客户端发送到服务器，服务器不与客户端通信任何响应。
- 事件：当值发生变化或周期性地传递给客户端时，从服务器传递给客户端的消息。服务器仅向已订阅该服务的客户端通知值的更改。每次事件发生时都会发送通知。
- 字段：字段表示实体的状态。它可以是通知器、getter或setter。
- Notifier是在值更改时从服务器发送到客户端的字段。
- Getter是客户端发送给服务器用于读取值的字段。
- Setter是客户端发送到服务器以更改值的字段。
2.3 服务发现：
使用SOME/IP协议的数据通信发生在客户端-服务器安排中。
服务器提供许多不同的服务，客户端设备可以订阅这些服务。
该协议允许客户端动态查找服务、订阅服务并配置对服务的访问。
服务发现有两种机制来传达服务的可用性，称为“提供服务”和“查找服务”。
- “提供服务”是指服务器ECU向客户端提供可用的服务。
- “查找服务”是指客户端向服务器ECU请求可用服务。
2.4 发布/订阅：
SOME/IP中的数据通信是通过发布/订阅进行的。
客户端可以订阅服务器提供的服务，服务器可以向活动订阅者发布通知。这允许在客户端设备和服务器之间进行动态配置。
通过发布/订阅安排，服务器可以选择性地将数据传递给需要特定ECU间消息的客户端。
2.5 UDP消息的分段：
每当服务器必须向活动订阅者发送通知时，它们都是通过UDP协议发送的。SOME/IP能够在不需要任何碎片的情况下传输大型UDP消息。
3. SOME/IP如何工作：
步骤1：客户端向服务器发送“查找服务”请求，以从服务器查找可用服务。
步骤2：服务器向客户端提供可用服务列表。
步骤3：客户端通过向服务器发送带有subscribe eventGroup的请求来订阅这些服务。
步骤4：服务器检查订阅的有效性，如果正确，服务器会向客户端发回肯定的ACK。多个客户端可能订阅同一服务。
步骤5：服务器向客户端发送数据。数据可以是标量值、复杂数据结构或函数调用。
- SOME/IP支持以下标量数据类型：boolean、uint8、uint16、uint32、uint64、sint8、sint16、sint32、sint64、float32、float64。
- SOME/IP支持以下复杂的数据结构：结构体、字符串、数组、枚举、位字段、联合。
- 注意：服务器和客户端之间的通信可以通过TCP或UDP进行。当服务器需要向多个订阅者（客户端）发送数据时，使用UDP。当数据需要从客户端发送到服务器时（例如：当客户端使用getter、setter、RPC时），使用TCP。
4. SOME/IP帧：
4.1 当以消息的形式接收一系列数据时：
消息ID：消息ID的分配应由用户决定，并且对整个系统是唯一的。此字段类似于CAN ID。
- 消息ID=服务ID（16位）+方法ID（16位数）。
- 服务ID：此字段的值符合要求。
- 方法ID也称为事件ID或通知程序ID：此字段的值符合要求。
长度：此字段以字节为单位，从请求ID开始，直到SOME/IP消息结束。
- 注：长度=8+有效载荷长度
请求ID：此字段允许提供者和订阅者区分同一方法、事件、getter和setter的多个并行使用。
- 请求ID=客户端ID（16位）+会话ID（16位数）。
- 客户端ID：此字段的值符合要求。
- 会话ID：根据需要处理，范围从0x0001到0xFFFF，包装后从1重新开始。
协议版本：此字段标识使用的SOME/IP报头格式（不包括有效载荷格式）。
- 应设置为0x01。
接口版本：此字段包含服务接口的主要版本。
- 此字段的值符合要求。
消息类型：此字段用于区分不同类型的消息。
| 0x00 | Request |
| 0x01 | Request no return |
| 0x02 | Notification |
| 0x80 | Response |
| 0x81 | Error |
| 0x20 | TP Request |
| 0x21 | TP Request no return |
| 0x22 | TP Notification |
| 0x23 | TP Response |
| 0x24 | TP Error |
- 此字段的值应设置为0x02。
返回代码：此字段用于通知请求是否已成功处理。
| 0x00 | E_OK | No error occurred |
| 0x01 | E_NOT_OK | An unspecified error occurred |
| 0x02 | E_UNKNOWN_SERVICE | The requested Service ID is unknown |
| 0x03 | E_UNKNOWN_METHOD | The requested Method ID is unknown. Service ID is known |
| 0x04 | E_NOT_READY | Service ID and Method ID are known. Application not running |
| 0x05 | E_NOT_REACHABLE | System running the service is not reachable (internal error code only) |
| 0x06 | E_TIMEOUT | A timeout occurred (internal error code only) |
| 0x07 | E_WRONG_PROTOCOL_VERSION | Version of SOME/IP protocol not supported |
| 0x08 | E_WRONG_INTERFACE_VERSION | Interface version mismatch |
| 0x09 | E_MALFORMED_MESSAGE | Deserialization error, so that payload cannot be de-serialized |
| 0x0A | E_WRONG_MESSAGE_TYPE | An unexpected message type was received |
- 此字段的值应设置为0x00。
有效载荷：此字段用于标识需要携带的数据。有效载荷的大小取决于所使用的传输协议。例如，对于UDP，有效载荷应在0-1400字节之间。
- 在这种情况下，有效载荷是消息形式的一系列数据。
4.2 发送SOME/IP SD帧时：
灰色部分：
- 消息ID：消息ID的分配应由用户决定，并且对整个系统是唯一的。此字段类似于CAN ID。
- 消息ID=服务ID（16位）+方法ID（16位数）。
- SD消息应使用0xFFFF的服务ID。
- SD消息应使用0x8100的方法ID。
- 长度：此字段以字节为单位，从请求ID开始，直到SOME/IP消息结束。
- 注：长度=8+有效载荷长度
- 请求ID：此字段允许提供者和订阅者区分同一方法、事件、getter和setter的多个并行使用。
- 请求ID=客户端ID（16位）+会话ID（16位数）。
- SD消息应使用0x0000的客户端ID。
- SD消息应根据需要处理会话ID，范围从0x0001到0xFFFF，并在包装后从1重新开始。
- 协议版本：此字段标识使用的SOME/IP报头格式（不包括有效载荷格式）。
- SD消息的协议版本应为0x01。
- 接口版本：此字段包含服务接口的主要版本。
- SD消息的接口版本应为0x01。
- 消息类型：此字段用于区分不同类型的消息。
- SD消息的消息类型应为0x02。
- 返回代码：此字段用于通知请求是否已成功处理。
- SD消息的返回代码应为0x00。
（有效载荷：此字段用于标识需要携带的数据。 在这种情况下，有效载荷是SOME/IP-SD（绿色和蓝色）。 ）
红色部分：
- 标志：包括重新启动标志（位0）、单播标志（位1）、显式初始数据控制标志（位2）。
- 重新启动标志：重新启动后，所有消息的重新启动标志应设置为1，直到SOME/IP标头中的会话ID环绕并再次以1开始。在此之后，重新启动标志设置为0。
- 单播标志：对于所有SD消息，应设置为1，因为这意味着支持使用单播。
- 显式初始数据控制：遵循旧AUTOSAR版本（示例：版本4.2）的实现不支持此功能，必须将此标志设置为0。新版本都应支持此功能，并且必须将此标志设置为始终1。
绿色部分（条目数组）：这可以是SOME/IP-SD事件组或服务条目类型帧，具体取决于类型字段。如果类型字段为0x06或0x07，则使用SOME/IP-SD事件组类型格式。如果使用SOME/IP-SD服务条目类型格式。
SOME/IP-SD 事件组条目类型：
SOME/IP-SD 服务条目类型：
- 条目数组长度：描述条目数组中有多少字节。
- 类型：对Subscribe（0x06）和SubscribeAck（0x07）进行编码。
- 索引第一个选项：索引到第一个选项运行的选项数组中。索引0表示SOME/IP-SD数据包的第一个。
- 索引第二个选项：索引第二次选项运行的选项数组。索引0表示SOME/IP-SD数据包的第一个。
- 选项1的数量：第一个选项运行的长度。长度0表示选项运行中没有选项。
- 选项2的数量：第二个选项运行的长度。长度0表示选项运行中没有选项。
- 服务ID：描述此条目所涉及的服务或服务实例的服务ID。换句话说，此字段描述要订阅的服务。
- 此字段的值符合要求。
- 实例ID：描述此条目涉及的服务实例的服务实例ID，或者如果服务的所有服务实例都是指此条目，则将其设置为0xFFFF。
- 此字段的值符合要求。
- 主要版本：描述服务实例的主要版本。换句话说，此字段与接口版本字段类似。
- TTL：以秒为单位描述条目的生存期。
- 保留：应设置为0x00。
- 初始数据请求标志：如果初始数据应由服务器发送，则应设置为1。
- 预留2：应设置为0x00。
- 计数器：此字段用于区分同一订阅者的相同订阅事件组。如果不使用，则设置为0x00。
- 事件组ID：事件组的ID。
- 此字段的值符合要求。
蓝色部分（选项阵列）：这是IPv4端点选项。
- 选项数组长度：描述选项数组中有多少字节。
- 长度：应设置为0x0009。
- 类型：应设置为0x04。
- 保留：应设置为0x00。
- IPv4地址：单播IP地址。
- L4原型：TCP应设置为0x06，UDP应设置为0x%11。
- 端口号：应设置为第4层协议源端口。
