02 AUTOSAR Classic与Adaptive平台下SOME/IP协议栈对比

⭐从 Classic 到 Adaptive：SOME

在车载软件项目中，SOME/IP（Scalable service-Oriented MiddlewarE over IP）是实现服务发现与远程过程调用的核心中间件。然而，AUTOSAR Classic 平台与 Adaptive 平台对 SOME/IP 的实现路径截然不同——前者面向静态、确定性强的嵌入式控制单元（ECU），后者面向高性能、动态部署的计算单元。选型错误将直接导致调试验证周期拉长、交付物不符合平台规范，甚至项目返工。本节的核心意图是理清两种平台下 SOME/IP 协议栈的实现差异，并建立一套可复用的选型与验证依据

💻对象配置与验证链路：静态绑定 vs 动态服务发现

Classic 平台：基于 ARXML 的编译期配置

在 AUTOSAR Classic 中，SOME/IP 协议栈的配置完全通过 AUTOSAR 系统样例（ARXML） 驱动。开发者需要预先定义服务接口（Service Interface）、事件组（Event Group）、方法（Method）和字段（Field），并生成静态代码。关键交付物包括 SomeIpIf_*.c/.h 和 Rte_*.h，这些文件在编译时即固定了服务实例的端口号、通信周期和序列化方式。调试验证时，通常依赖 Classic 调试验证（Classic Debug & Validation） 工具，如 Vector CANoe 或 EB tresos Studio 的协议栈监控器，通过捕获 SomeIpXf_Transmit() 和 SomeIpXf_Receive() 的调用日志来确认报文格式是否正确

Adaptive 平台：基于 Manifest 的运行时动态发现

Adaptive 平台下的 SOME/IP 实现则完全不同。服务接口定义仍通过 ARXML 描述，但最终交付物是 Adaptive 交付物（Adaptive Artifacts），包括 *.json 格式的 Manifest 文件和可执行二进制。服务实例的启动、停止和发现由 ara::com 运行时管理，开发者通过 FindService() 和 OfferService() 接口动态绑定。调试验证环节依赖 environment_setup 调试验证（Environment Setup Debug & Validation），通常使用 Wireshark 配合 vsomeip 的日志输出，或通过 dlt-daemon 捕获 ara::com 的通信事件。一个典型的验证命令是：

# 启动服务端，监听 SOME/IP 服务发现报文（端口 30490）
export VSOMEIP_CONFIGURATION=service.json
export VSOMEIP_APPLICATION_NAME=service_sample
./someip_service --log-level debug 2>&1 | grep "SOME/IP"

这段命令属于“问题代码/原始配置”，核对参数、目标设备和返回信息，并用状态记录确认动作是否真正生效。

该命令输出的日志会显示 OfferService 报文的 Service ID、Instance ID 和 Major Version，这是确认服务是否被正确注册到网络上的直接证据

⭐AUTOSAR的技术资产与验证方式

为了帮助团队在项目初期快速锁定平台，下表从配置方式、运行时行为、调试验证手段和典型交付物四个维度进行对比