2、SOME/IP协议入门：协议栈架构、服务发现、RPC机制与序列化
好，咱们进入正题。从CAN迁移到SOME/IP，你首先得搞清楚这个协议到底长什么样。说实话，我第一次接触SOME/IP时也觉得头大——又是服务发现又是RPC的，跟CAN那种简单粗暴的报文结构完全不是一个路子。但别怕，咱们一步步拆开来看。
2.1 SOME/IP协议栈架构
SOME/IP的全称是Scalable service-Oriented MiddlewarE over IP。说白了，它就是一种面向服务的中间件协议。我习惯把它分成四层来看：
- 传输层：基于UDP或TCP。UDP用于短报文、实时性高的场景；TCP用于大块数据或需要可靠传输的场景。我在项目中遇到过，有些ECU死活连不上，最后发现是UDP端口被防火墙堵了——嗯，这种坑踩过一次就记住了。
- 序列化层：负责把数据结构变成字节流。后面会细讲。
- RPC层：远程过程调用。让一个ECU能像调用本地函数一样调用另一个ECU上的服务。
- 服务发现层：也就是SOME/IP-SD，负责让服务提供者和消费者互相找到对方。
你想想看，这跟CAN的差别有多大？CAN里你直接发ID和数据就行，SOME/IP却要搞这么多层。但好处也很明显——灵活、可扩展、支持动态拓扑。
2.2 SOME/IP服务发现（SOME/IP-SD）
服务发现，说白了就是「谁提供什么服务，谁需要什么服务」的匹配过程。我刚开始做SOME/IP时，觉得服务发现可有可无，直到有一次在实车上调试，发现某个ECU死活找不到另一个ECU的服务——原来是服务发现报文没发出去。
服务发现的核心机制包括：
- Offer Service：服务提供者广播「我这里有XX服务，谁要？」
- Find Service：服务消费者广播「谁有XX服务？我需要！」
- Subscribe/SubscribeACK：消费者订阅某个事件组，提供者确认。
关键点：服务发现报文默认走UDP多播，端口30490。多播地址通常是224.0.0.1或239.192.255.0。我曾经因为多播地址配错，折腾了两天——后来发现是网络工程师把多播给禁了。
服务发现的时序大致是这样的：
- ECU启动后，服务提供者发送Offer Service报文。
- 服务消费者收到后，发送Subscribe报文。
- 提供者回复SubscribeACK，然后开始发送事件或提供方法调用。
这里有个坑：如果消费者先启动，提供者后启动，消费者会定时重发Find Service报文。重发间隔一般是1秒、2秒、4秒...指数退避。我建议你把重发次数设成3次，不然网络负载会很大。
2.3 SOME/IP-RPC机制
RPC，远程过程调用。你想想看，在CAN里你要让另一个ECU干点活，得自己定义一套应用层协议——发个请求报文，等响应报文，还得自己处理超时。SOME/IP把这些都封装好了。
SOME/IP-RPC的核心是Method（方法）和Event（事件）：
- Method：请求-响应模式。客户端发请求，服务端处理完返回结果。比如「查询车速」。
- Event：发布-订阅模式。服务端主动推送数据给所有订阅者。比如「车速变化通知」。
- Field：属性模式。可以get/set/notifier。比如「车门状态」——你可以读它、写它、订阅它的变化。
RPC的报文格式包含：
| 字段 | 长度 | 说明 |
|---|---|---|
| Message ID | 4字节 | 服务ID + 方法ID |
| Length | 4字节 | 从Request ID开始的长度 |
| Request ID | 4字节 | 客户端ID + 会话ID |
| Protocol Version | 1字节 | 当前为1 |
| Interface Version | 1字节 | 接口版本号 |
| Message Type | 1字节 | 0x00=请求, 0x80=响应, 0x02=通知... |
| Return Code | 1字节 | 0x00=成功, 其他=错误码 |
| Payload | 变长 | 序列化后的数据 |
个人经验：Request ID里的会话ID一定要唯一。我见过一个项目，两个客户端用了相同的会话ID，结果响应报文发错了对象——调试时数据乱跳，查了三天才发现是会话ID冲突。
2.4 SOME/IP序列化
序列化，就是把结构体变成字节流。CAN里你直接拼字节就行，但SOME/IP要遵循一套规则——说白了就是「对齐、大小端、长度前缀」这些事。
SOME/IP序列化的核心规则：
- 对齐：每个成员按自身大小对齐。比如uint32要4字节对齐，uint8可以任意对齐。我习惯在结构体末尾加padding，不然不同编译器可能对齐不一样。
- 大小端：默认大端（网络字节序）。但也可以协商成小端。我个人建议统一用大端，省得跨平台时出幺蛾子。
- 长度前缀：动态数组或字符串前面要加长度字段。长度字段通常是4字节。
举个例子，一个简单的车速结构体：
struct VehicleSpeed {
uint32 timestamp; // 4字节，对齐到4
float speed; // 4字节，对齐到4
uint8 quality; // 1字节，对齐到1
uint8 reserved[3]; // 3字节padding，凑到4字节对齐
};序列化后的字节流（大端）：
timestamp: 0x00000001 (4字节)
speed: 0x41200000 (4字节，float 10.0)
quality: 0x01 (1字节)
reserved: 0x000000 (3字节padding)
总长度: 12字节注意：序列化时千万别忘了padding。我曾经在项目里漏了padding，结果两个ECU对同一个结构体的解析结果不一样——一个读出了正确数据，另一个读出了垃圾值。后来发现是结构体末尾的3字节padding没对齐，导致下一个字段的起始地址错了。
对于动态数组，比如车速历史记录：
struct SpeedHistory {
uint32 count; // 4字节，元素个数
VehicleSpeed speeds[]; // 变长数组，每个元素12字节
};序列化时先写count，再依次写每个元素。反序列化时先读count，再循环读元素。
嗯，这里要注意：SOME/IP序列化不支持自描述。也就是说，接收方必须提前知道数据结构——不像JSON那样可以动态解析。所以接口定义文件（ARXML）就特别重要。我建议你在项目一开始就把ARXML定义好，不然后面改起来牵一发动全身。
好了，SOME/IP协议入门就讲这么多。下一章咱们聊聊怎么把CAN的信号映射到SOME/IP的服务上——那才是迁移实战的重头戏。