SOME/IP 服务模型

一、为什么车载软件需要 SOME/IP

在域控和服务化架构中，功能不再只是 ECU 间的信号矩阵，而是一个个服务。例如座舱域需要获取车辆状态、ADAS 需要发布感知结果、网关需要提供诊断路由。SOME/IP 提供了面向服务的通信模型，适合以太网和 AUTOSAR Adaptive 场景。

SOME/IP 常见能力：

能力	说明
Method	请求/响应调用
Event	发布/订阅事件
Field	带 getter/setter/notify 的状态
SD	服务发现和订阅管理

二、SOME/IP 报文头

text 复制代码

0                   31
┌───────────────┬───────────────┐
│ Service ID    │ Method/Event ID│
├───────────────┴───────────────┤
│ Length                         │
├───────────────┬───────────────┤
│ Client ID     │ Session ID     │
├───────┬───────┬───────┬───────┤
│ Proto │ IfVer │ MsgTy │ RetCode│
└───────┴───────┴───────┴───────┘

关键字段：

字段	作用
Service ID	服务编号
Method ID/Event ID	方法或事件编号
Client ID	客户端标识
Session ID	请求会话
Message Type	请求、响应、通知等
Return Code	调用结果

三、Method、Event、Field 区别

模型	通信方式	适合场景
Method	Request/Response	查询版本、执行控制命令
Event	Publish/Subscribe	周期车辆状态、传感器结果
Field	Getter/Setter/Notifier	状态变量，如车速、挡位

不要把所有东西都做成 Method。高频状态更适合 Event 或 Field notify，否则请求/响应开销大，还容易造成客户端轮询风暴。

四、Service Discovery 基本流程

text 复制代码

Server                 Client
  | OfferService          |
  |---------------------->|
  |                       |
  |        FindService    |
  |<----------------------|
  | OfferService          |
  |---------------------->|
  |                       |
  | SubscribeEventGroup   |
  |<----------------------|
  | SubscribeAck          |
  |---------------------->|
  | Event Notification    |
  |---------------------->|

SOME/IP SD 通常使用 UDP 30490，服务数据可用 TCP 或 UDP。

抓包：

bash 复制代码

tcpdump -i eth0 -nn -vv udp port 30490

Wireshark：

text 复制代码

someipsd

五、服务 ID 设计

示例：

text 复制代码

Service ID: 0x1234 VehicleStateService
Instance ID: 0x0001 FrontDomain
Method ID: 0x0001 GetVehicleSpeed
Event ID:  0x8001 VehicleSpeedChanged
EventGroup ID: 0x0001 VehicleStateEvents

Event ID 通常最高位为 1，用于和 Method 区分。实际项目要遵循平台规范和接口文档。

六、服务端伪代码

cpp 复制代码

class VehicleStateSkeleton {
public:
    void OfferService()
    {
        sd_offer_service(service_id, instance_id, ttl);
    }

    Speed GetVehicleSpeed()
    {
        return current_speed_;
    }

    void NotifySpeed()
    {
        someip_send_event(service_id, instance_id,
                          event_id_speed, encode(current_speed_));
    }
};

服务端要处理：

服务启动后周期 Offer。
客户端订阅后发送事件。
TTL 到期前刷新。
服务停止时 StopOffer。

七、客户端伪代码

cpp 复制代码

void on_service_available(ServiceHandle h)
{
    proxy = std::make_unique<VehicleStateProxy>(h);
    proxy->SubscribeVehicleStateEvents();
    proxy->GetVehicleSpeedAsync(on_speed_response);
}

void on_speed_event(const Speed &speed)
{
    update_dashboard(speed);
}

客户端不要假设服务永远在线，要处理服务消失、重连、重复 Offer、TTL 过期。

八、案例：服务能 Find 但订阅失败

现象：客户端能发现服务，但收不到 Event。

排查：

抓 SD，Find/Offer 正常。
抓 SubscribeEventGroup，发现 EventGroup ID 写错。
服务端返回 Subscribe Nack。
修正接口配置后，事件通知正常。

结论：服务发现成功不代表事件订阅成功，必须继续看 Subscribe Ack/Nack。

九、排查表

现象	可能原因	验证	处理
找不到服务	Offer 未发、组播/VLAN 错	抓 30490	修 SD 和网络配置
找到服务但调用失败	Method ID/版本错	看 ReturnCode	对齐接口版本
收不到事件	未订阅或 EventGroup 错	看 SubscribeAck	修订阅配置
服务反复上下线	TTL 太短或刷新异常	抓 Offer 周期	调整 TTL/周期
多实例冲突	Instance ID 重复	抓 SD entry	规范实例 ID

十、上线检查

Service ID、Instance ID、Method ID、Event ID 文档化。
SD Offer/Find/Subscribe 抓包确认。
TTL、Offer 周期符合平台要求。
服务上下线客户端能恢复。
ReturnCode 和错误处理覆盖。
高并发客户端订阅压测完成。

十一、常见坑

把 Event ID 和 Method ID 混用。
只看 Offer，不看 SubscribeAck。
TTL 过短导致服务抖动。
服务端停止时不发 StopOffer。
客户端不处理服务重新出现。
接口版本升级后未兼容旧客户端。

十二、总结

SOME/IP 的核心是服务模型和服务发现。Method 适合调用，Event 适合发布，Field 适合状态。工程联调时要按 SD、订阅、数据报文、返回码逐层排查，不能只凭应用日志判断服务是否正常。