3. SOME/IP 报文格式详解
SOME/IP 报文，说白了就是车载设备之间沟通的「信封」。你想想看，两个 ECU 要交换数据，总得有个统一的格式吧？这个格式就是 SOME/IP 报文。今天我就带你把这个信封拆开，看看每一部分到底长什么样、干什么用。
我个人习惯把 SOME/IP 报文分成两大部分：头部（Header）和载荷（Payload）。头部固定 16 字节，Payload 长度可变。咱们先看头部，一个一个字段过。
SOME/IP 头部固定 16 字节，这是所有实现必须遵守的硬规则。
3.1 Message ID（4 字节）
Message ID 是报文的「身份证号」。它唯一标识一个服务或事件。我刚开始接触 SOME/IP 时，总把它和 CAN 的 ID 搞混——其实完全不是一回事。
Message ID 分两部分：
- Service ID（高 16 位）：标识哪个服务。比如 0x0001 表示「车门控制服务」。
- Method ID（低 16 位）：标识服务里的哪个方法或事件。比如 0x0001 表示「锁车方法」。
举个例子：Message ID = 0x00010001，就是「车门控制服务」的「锁车方法」。
我的经验：调试时抓包看到 Message ID，立刻就能知道是哪个服务在通信。建议团队提前规划好 Service ID 分配表，避免冲突。
3.2 Length（4 字节）
Length 字段表示从 Request ID 开始到报文末尾的总字节数。注意，它不包含 Message ID 和 Length 自身这 8 个字节。
计算公式很简单：
Length = 8（头部剩余部分）+ Payload 长度我记得有一次调试，发现接收端一直报错，查了半天——原来是 Length 算错了，把整个报文长度填进去了。嗯，这里要注意：Length 不包括前 8 字节。
3.3 Request ID（4 字节）
Request ID 用于区分同一个服务的多个并发请求。它包含：
- Client ID（高 16 位）：标识哪个客户端发起的请求。
- Session ID（低 16 位）：标识该客户端的第几次会话。
你想想看，如果多个 ECU 同时请求同一个服务，怎么区分谁是谁？靠的就是 Request ID。Session ID 每次请求递增，响应报文必须携带相同的 Session ID。
避坑指南：我曾经遇到过一个 bug——Session ID 溢出后没有回绕处理，导致响应匹配混乱。建议 Session ID 用满 16 位后从 1 重新开始，不要用 0。
3.4 Protocol Version（1 字节）
这个字段固定为 0x01，表示当前使用的 SOME/IP 协议版本。目前主流版本就是 1。如果将来协议升级，这个字段会变。
说实话，我做了这么多年项目，还没见过非 0x01 的版本。但规范里留了这个字段，就是为了向前兼容。
3.5 Interface Version（1 字节）
Interface Version 表示服务接口的版本号。比如你定义了一个「车门控制服务」v1.0，Interface Version 就是 0x01。如果接口升级到 v2.0，就变成 0x02。
这个字段有什么用？我举个例子：
- 客户端请求时带上 Interface Version。
- 服务端检查版本是否匹配。
- 不匹配就返回错误码。
说白了，就是防止新旧版本混用导致数据解析错误。
3.6 Message Type（1 字节）
Message Type 表示报文的类型。常用的有：
| 值 | 类型 | 说明 |
|---|---|---|
| 0x00 | REQUEST | 请求报文（需要响应） |
| 0x01 | REQUEST_NO_RETURN | 请求报文（不需要响应） |
| 0x02 | NOTIFICATION | 事件通知报文 |
| 0x80 | RESPONSE | 响应报文 |
| 0x81 | ERROR | 错误响应报文 |
我个人习惯把 0x00 和 0x80 看作一对——有请求就有响应。0x01 是「发了就不管了」，适合那些不需要确认的场景。
3.7 Return Code（1 字节）
Return Code 表示调用结果。0x00 表示成功，非 0 表示各种错误。常用的错误码：
| 值 | 含义 |
|---|---|
| 0x00 | E_OK（成功） |
| 0x01 | E_NOT_OK（未指定错误） |
| 0x02 | E_UNKNOWN_SERVICE（未知服务） |
| 0x03 | E_UNKNOWN_METHOD（未知方法） |
| 0x04 | E_MALFORMED_MESSAGE（报文格式错误） |
| 0x05 | E_WRONG_INTERFACE_VERSION（接口版本不匹配） |
我的经验：抓包时如果看到 Return Code 不是 0x00，先别慌。看看 Message Type 是不是 0x81（ERROR），再查错误码表，基本能定位问题。
3.8 Payload（可变长度）
Payload 是报文的「正文」。它包含实际传输的数据，长度由 Length 字段间接决定。Payload 的格式完全由服务接口定义——可以是普通数据、序列化后的结构体，也可以是空。
举个例子，锁车服务：
Payload = 0x01 // 1 表示锁车，0 表示解锁就这么简单。但实际项目中，Payload 往往很复杂，包含嵌套结构体、数组、字符串等。序列化方式由 SOME/IP 的序列化规范决定，咱们后面章节会细讲。
3.9 报文结构总览
下面这张图把整个报文结构串起来，方便你记忆：
3.10 抓包实战小贴士
学完理论，咱们来点实际的。用 Wireshark 抓 SOME/IP 包时，重点关注这几个字段：
- Message ID：一眼看出是哪个服务在通信。
- Message Type：判断是请求还是响应。
- Return Code：非 0 就是有问题。
- Length：检查报文长度是否合理。
避坑指南：我曾经遇到一个 case——服务端一直返回 E_NOT_OK，查了半天发现是客户端把 Message ID 的 Service ID 和 Method ID 搞反了。嗯，这种低级错误，抓包一看就能发现。