AI x AUTO 新手上车：车载以太网 SOME/IP 与 TC3 实战｜技术集结

RT-Thread官方账号 2026-06-12 3145

描述

引言

笔者目前是一名刚入门车载软件的新人，最近在接触车载以太网、SOME/IP 和 AUTOSAR CP 相关内容，之前对以太网更多停留在基础概念层面，例如 MAC、IP、TCP/UDP、报文收发流程等，也了解过一些简单的以太网协议栈框架。

对于 AUTOSAR CP，还只是听说过。刚开始学习 SOME/IP 时，最直观的感受是它并不只是“跑在 UDP/TCP 上的一种应用层报文”，而是和服务接口、服务发现、AUTOSAR CP 通信栈配置及实际 ECU 软件架构都相关。单独看报文格式并不难，但一旦放到 AUTOSAR CP 里，就需要把 RTE、SomeIpXf、LdCom、PduR、SoAd、TcpIp、Sd 等模块一起串起来理解，好在现阶段 AI 已经发展到具备很强的辅助能力。对于刚接触 SOME/IP 和 AUTOSAR CP 的新手来说，可以借助 Codex、Claude 等 AI 工具快速检索知识、阅读代码、梳理配置参数。

这篇文章是一份学习过程中的阶段性整理：在英飞凌 TC397评估板基础上，结合程翧车控系统，从SOME/IP 的基本概念开始，介绍 SOME/IP-SD 服务发现机制，再结合 AUTOSAR CP 中的通信协议栈，并说明 SOME/IP 报文在 AUTOSAR CP 中的收发链路。

程翧车控系统是一套POSIX RTOS + AUTOSAR CP的融合系统，OS部分衍生自RT-Thread，在保持RT-Thread内核API兼容基础上实现了AUTOSAR OS，BSW各中间件，从而形成了一套面向车载的灵活性平台：RT-Thread Safety OS作为系统运行基础，承载任务调度、设备驱动、网络协议栈以及上层应用逻辑。AUTOSAR CP 主要面向对实时性、功能安全和确定性有严格要求的传统车控 ECU。它通过分层架构将应用软件、RTE、基础软件 BSW、MCAL 等模块解耦，使不同厂商的软件模块能够按照统一接口协同工作。

SOME/IP 简介

SOME/IP，全称为 Scalable service-Oriented MiddlewarE over IP，是面向车载以太网的服务化通信协议。它运行在 UDP 或 TCP 之上，用服务、方法、事件、字段等概念描述 ECU 之间的交互关系。

SOME/IP 基于以太网通信协议传输，在一帧以太网数据中的位置如下所示：

从协议层次上看，SOME/IP 报文位于 TCP/UDP 数据部分中。下层由以太网、IP、TCP/UDP 负责寻址、传输和链路发送；SOME/IP 则在应用通信层面描述服务标识、方法标识、消息类型和业务负载。

SOME/IP 的核心概念

SOME/IP 报文结构

SOME/IP 报文主要由 SOME/IP Header 和 Payload 两部分组成。Header 是固定结构，Payload 是可变长度的数据负载，用于承载真正的业务数据。

SOME/IP 报文结构如下：

几个比较关键的字段如下：

Message ID：由 Service ID 和 Method ID/Event ID 组成，用于标识具体服务以及服务中的方法或事件。

Length：表示从 Request ID 开始到 Payload 结束的总长度。

Request ID：由 Client ID 和 Session ID 组成，用于区分不同客户端以及同一客户端发起的不同请求。

Message Type：用于区分 Request、Response、Notification、Error 等不同类型的 SOME/IP 消息。

Return Code：主要用于响应报文中表示请求处理结果。

Payload：承载真正的业务数据，例如方法参数、返回值或事件数据。

通信方式

SOME/IP 常见的通信方式可以先简单分为三类：

Method 类似远程过程调用，客户端发起请求，服务端处理后返回响应。它适合用于明确的控制指令或查询操作。

Method 也可以使用 Fire & Forget 方式，只发送请求、不等待响应。

Field 用于表达服务中的状态或属性，通常可以支持 Getter、Setter 和 Notifier，适合描述车门状态、灯光状态、空调温度等状态类数据。

Event 用于服务端主动发布数据，常见于状态变化通知或周期性数据上报。客户端通常需要先订阅对应的 EventGroup，服务端确认订阅后再发送事件通知。

简单来说，Method 更适合“请求-响应”，Field 更适合“状态读写和状态通知”，Event 更适合“服务端主动发布数据”。对本文后续内容来说，只需要先理解这些通信方式最终都会落到 SOME/IP 报文和 AUTOSAR CP 通信栈链路上即可。

SOME/IP-SD：服务发现机制

SOME/IP-SD，即 SOME/IP Service Discovery，用于在车载以太网中完成服务发现、服务发布和事件订阅。它可以理解为 SOME/IP 通信体系中的服务管理机制。

在服务化通信中，客户端并不一定天然知道服务端当前是否在线、服务实例是否可用、事件组是否允许订阅。SOME/IP-SD 的作用就是在业务报文交互之前，先建立服务关系和订阅关系。

SOME/IP-SD 报文也属于 SOME/IP 消息的一种，因此它同样以 SOME/IP Header 作为开始。SOME/IP-SD 报文的数据帧结构如下：

常见的 SOME/IP-SD 报文包括：

Offer Service：服务端发布服务，表示自己当前可以提供某个服务。

Find Service：客户端查找服务，询问网络中是否存在某个服务。

Subscribe Eventgroup：客户端订阅事件组，用于接收服务端后续发布的事件通知。

Subscribe Ack：服务端确认客户端的事件组订阅。

可以简单理解为：SOME/IP 负责承载真正的业务数据，SOME/IP-SD 负责在业务通信之前建立服务关系和订阅关系。后面介绍 AUTOSAR CP 报文收发链路时，也会把业务报文链路和 SD 报文链路分开说明。

AUTOSAR CP 简介

AUTOSAR CP，即 AUTOSAR Classic Platform，是面向传统嵌入式 ECU 的软件架构规范。它强调标准接口、分层解耦和可配置化，常用于车身控制、底盘控制、动力控制、网关等对实时性和稳定性要求较高的场景。

AUTOSAR CP 的典型架构包括应用软件层、RTE、基础软件层和 MCAL：

Application Layer：应用软件层，包含具体业务功能，例如车门控制、灯光控制、空调控制等。

RTE：运行时环境，负责连接应用软件组件和基础软件，为应用提供统一访问接口。

BSW：基础软件层，包含通信、诊断、存储、系统服务、网络管理等基础模块。

MCAL：微控制器抽象层，封装底层芯片外设驱动，例如 CAN、Ethernet、DIO、SPI、ADC 等。

在 AUTOSAR CP 中，应用层不直接访问具体硬件，也不直接处理底层通信协议。应用通常通过 RTE 访问服务接口，通信协议栈、PDU 路由、网络管理、驱动适配等工作则由 BSW 和 MCAL 完成。

放到 SOME/IP 场景中看，应用软件组件并不需要关心以太网帧、IP 地址、端口号以及 UDP/TCP socket 的具体处理。应用只需要通过 RTE 调用服务接口，例如发起 Method 调用、访问 Field、接收 Event 通知。真正的以太网通信、PDU 路由、socket 适配、服务发现等工作，则由 BSW 中的通信相关模块完成。

AUTOSAR CP 中 SOME/IP 报文收发架构

理解 AUTOSAR CP 中的 SOME/IP，不能只看 SOME/IP 报文本身，还需要结合 CP 的分层架构来看。Application Layer 关注服务和业务数据，RTE 负责接口连接，BSW 负责 SOME/IP 相关通信栈处理，MCAL 和以太网驱动负责最终的数据收发。

在 AUTOSAR CP 中，可以把 SOME/IP 相关通信分成两条主线：一条是业务报文链路，负责 Method、Field、Event 等真实业务数据交互；另一条是 SOME/IP-SD 报文链路，负责服务上线发现、服务查找和事件订阅管理。

SOME/IP 业务报文收发

SOME/IP 业务报文的收发可以理解为从“应用服务接口”到“以太网通信栈”的逐层转换。上层 SWC 输出的是服务调用参数或业务结构体数据，下层真正发送的是经过 SOME/IP、UDP/TCP、IP、Ethernet 层层封装后的以太网数据。

典型链路如下：

其中，各模块职责可以简单理解为：

SWC 通过 RTE 访问 SOME/IP 服务接口，将 Method、Field 或 Event 相关业务数据传递到通信链路。

SomeIpXf 负责序列化和反序列化，将应用侧结构体数据和 SOME/IP payload 字节流进行转换。

LdCom 位于 RTE/SomeIpXf 与 PduR 之间，负责承接较大的 SOME/IP 业务数据，并以 PDU 形式传递给 PduR。

PduR 是 AUTOSAR CP 中的 PDU 路由模块，负责在不同通信模块之间转发 PDU。

SomeIpTp 用于 SOME/IP-TP 场景下的报文分段和重组，主要用于 UDP 承载的大数据 SOME/IP 报文。

SoAd 在基于 PDU 的 AUTOSAR 通信模块和基于 socket 的 TcpIp 协议栈之间建立映射关系，为 PDU 选择合适的 socket 进行发送或接收。

TcpIp/Eth 相关模块继续完成传输层、网络层和链路层处理，最终通过以太网完成报文收发。

这里还需要注意 TCP 和 UDP 的差异。对于 TCP 方式，SOME/IP 报文作为 TCP payload 传输，通常不需要经过 SomeIpTp；对于 UDP 方式，如果业务数据较大并使用 SOME/IP-TP，则链路中会增加 SomeIpTp 模块，用于对 SOME/IP 报文进行分段发送和接收重组。也就是说，SomeIpTp 主要解决 UDP 场景下大数据 SOME/IP 报文的分段问题。

SOME/IP-SD 报文收发

SOME/IP-SD 报文不承载真正的业务数据，而是负责在业务通信之前建立服务关系和订阅关系。例如服务端通过 Offer Service 表示自己提供某个服务，客户端通过 Find Service 查找服务，通过 Subscribe Eventgroup 订阅事件组。

SD 报文链路如下：

从 AUTOSAR CP 的角度看，SOME/IP-SD 属于 BSW 通信栈中的服务发现能力。SD 报文同样经过 TcpIp/Eth、SoAd 和 PduR，但最终不会进入 LdCom 或应用业务处理链路，而是交给 Sd 模块处理。

Sd 模块接收到服务发现报文后，会根据报文类型更新本地服务状态或订阅状态。例如收到 Offer Service 后，客户端可以知道目标服务已经上线；收到 Subscribe Ack 后，客户端可以确认事件组订阅成功。对于应用层来说，这些细节通常不会直接暴露出来，应用更多感知的是服务是否可用、事件订阅是否成功。

因此，业务报文链路解决“数据怎么传”，SD 报文链路解决“服务怎么找到、事件怎么订阅”。

SOME/IP 在英飞凌 TC397 上的实践

前面介绍了 SOME/IP 的协议概念以及它在 AUTOSAR CP 通信栈中的位置、报文收发架构，接下来结合英飞凌 TC397 平台，梳理 SOME/IP 通信实践流程。

TC397 是英飞凌 AURIX TC3xx 系列中的高性能车规级 MCU，基于 TriCore 架构，面向汽车电子高实时性、高可靠性和功能安全场景。它集成多核 CPU、片上 Flash、SRAM、丰富的通信外设以及安全相关硬件能力，适合用于车身控制、网关、底盘控制、动力控制以及车载以太网通信等应用。

在本文的实践场景中，TC397 作为目标运行平台，承载 RT-Thread Safety OS、AUTOSAR CP 基础软件模块、以太网驱动、TCP/IP 协议栈以及 SOME/IP 相关通信模块。演示业务模拟“中央控制器控制灯光状态”的场景，重点验证 SOME/IP Method 调用、SOME/IP-SD 服务发现以及以太网报文收发链路。

实践环境

硬件平台：Application Kit TC397 V2.0。

运行系统：RT-Thread Safety OS 。

软件架构：AUTOSAR CP 基础软件通信栈。

通信方式：车载以太网SOME/IP。

SOME/IP 报文收发工具：EcuBus-Pro。

AUTOSAR 配置工具： Clarence Studio。

网络抓包工具：Wireshark。

其中，TC397 负责运行 ECU 侧软件，作为 SOME/IP 服务端；EcuBus-Pro 用于模拟 SOME/IP 客户端，发送 Method Request、接收 Response，也可以配合服务发现流程进行测试；Wireshark 用于抓取以太网报文，确认 SOME/IP 和 SOME/IP-SD 报文是否符合预期。

多核部署

TC397 的一个重要特点是多核架构。在实践中，可以根据业务实时性、通信负载和调试便利性，将不同功能部署到不同核心上，减少模块之间的相互影响。

本文实践中的核间功能划分如下：

通过 Shell 命令可以查看每个核心中各个任务的运行状态。下图可以看到，以太网通信任务和 Shell 调试任务分别运行在不同核心中：

配置思路

在 AUTOSAR CP 中实践 SOME/IP，核心不是只写业务代码，而是先把通信矩阵、服务接口和通信链路配置清楚。通信矩阵可以理解为 SOME/IP 通信设计的输入文档，用来描述 ECU 之间有哪些服务、谁提供服务、谁消费服务、服务端和客户端的 IP/端口如何分配、使用什么传输方式以及报文中携带哪些数据。

下面给出一个简化后的 SOME/IP 服务通信矩阵示例：

在确定通信矩阵后，需要将这些信息映射到 AUTOSAR CP 的配置项中。整体配置还是非常复杂，在短时间内迅速弄清楚还是存在很大挑战，因为程翧车控系统中的ARXML配置都做过拆分，可以借助AI Agent的方式进行快速生成配置文件进行直接配置，而不一定需要一开始就花费大量时间去熟悉图形化工具的每一个配置入口。比如在已经明确通信矩阵和配置目标的前提下，让 AI 帮助定位并修改工程中的 *.arxml 配置文件和 *.clprj 工程文件，再重新执行配置生成流程，生成新的 BSW 配置代码，下图展示了在实际操作过程中使用AI来快速进行参数配置的过程。

配置后使用Clarence Studio打开工程需要关注到以下几类内容：

服务接口配置：定义 Service、Method、Event、EventGroup 等。

标识信息配置：配置 Service ID、Instance ID、Method ID 等。部分参数配置示例如下：

传输参数配置：配置服务端 IP、客户端 IP、UDP/TCP、端口号、多播地址等。部分参数配置示例如下：

序列化配置：配置应用数据类型和 SOME/IP payload 之间的映射关系。

PDU 路由配置：配置 LdCom、PduR、SoAd、SomeIpTp 等模块之间的路由关系。

服务发现配置：配置 Offer Service、Find Service、Subscribe Eventgroup 等 SD 行为。

这些配置最终会影响 SOME/IP 报文如何从应用层进入 RTE，如何经过 SomeIpXf 序列化，如何通过 LdCom、PduR、SoAd 进入 TcpIp/Eth，以及服务发现报文如何交给 Sd 模块处理。

运行流程

系统运行后，整体流程可以概括为以下几步：

1. TC397 上电启动，初始化 AUTOSAR OS 以及各核心上的基础任务。其中 Core 5 初始化以太网驱动、TcpIp、SoAd、PduR、LdCom、Sd 等 SOME/IP 相关模块；Core 4 运行 Shell 命令和调试相关功能。

2. 服务端通过 SOME/IP-SD 发送 Offer Service，向网络中声明当前 ECU 提供某个 SOME/IP 服务，见下图。

3. 客户端或测试工具通过 Find Service 查找目标服务，确认服务端是否在线，见下图。

4. 服务关系建立后，客户端发送 Method Request，例如请求修改灯光状态，见下图。

5. TC397 侧接收到 SOME/IP 请求后，报文依次经过 TcpIp/Eth、SoAd、PduR、LdCom、SomeIpXf、RTE，最终交给应用逻辑处理。

6. 应用处理完成后生成响应数据，再沿 RTE、SomeIpXf、LdCom、PduR、SoAd、TcpIp/Eth 的方向返回 Response，见下图。

最终三号灯如期点亮，如下图所示。

7. 如业务中包含 Event 或 Field Notifier，客户端还可以通过 Subscribe Eventgroup 订阅事件组，服务端在状态变化时发送 Event Notification，这里不再展开。

注意事项

如果您和我一样是一名对 SOME/IP 和 AUTOSAR CP 感兴趣的新人，有几个地方需要特别注意，避免踩坑：

先整理通信矩阵，再动配置。不要一开始就直接改工具里的参数或配置文件，最好先明确服务端、客户端、Service ID、Instance ID、Method ID、IP 地址、端口号、传输协议和 Payload 数据含义。

区分业务报文和 SD 报文。Method、Field、Event 这类业务数据走的是业务报文链路；Offer Service、Find Service、Subscribe Eventgroup 这类服务管理行为走的是 SD 报文链路。两条链路都会经过以太网协议栈，但最终处理模块不同。

不要混淆几个 ID。Service ID 标识服务，Instance ID 标识服务实例，Method ID/Event ID 标识服务中的方法或事件，Client ID/Session ID 用于区分请求来源和请求会话。这些字段看起来都像“编号”，但含义不一样。

IP 和端口要成对检查。服务端 IP、客户端 IP、本地端口、远程端口、UDP/TCP 协议、多播地址都要和通信矩阵、工具配置、抓包结果保持一致。很多通信不通的问题，本质上都是 IP 或端口没有对应上。

理解 PDU 和 socket 的转换关系。AUTOSAR CP 内部更多是以 PDU 形式在 LdCom、PduR、SoAd 等模块之间传递，而真正到以太网发送时，需要通过 SoAd 映射到 TcpIp 的 socket。理解这一点后，再看 PduR 和 SoAd 配置会清晰很多。

注意 SomeIpTp 的使用场景。并不是所有 SOME/IP 报文都会经过 SomeIpTp，它主要用于 UDP 场景下较大 SOME/IP 报文的分段和重组。普通的小数据 Method 请求响应通常不一定需要关注它。

修改配置后一定要重新生成和验证。无论是通过图形化工具配置，还是借助 AI 修改 *.arxml、*.clprj 文件，都需要重新执行配置生成流程，并通过编译、运行和 Wireshark 抓包确认结果。

多核部署要确认任务实际运行核心。配置正确不代表运行时一定正确，尤其在 TC397 这类多核平台上，需要确认以太网通信栈、CAN 通信栈、Shell 调试任务等是否运行在预期核心上。

总结

SOME/IP 是车载以太网中非常重要的服务化通信协议。它通过 Service、Method、Field、Event 等概念，将 ECU 之间的通信从传统“信号交互”扩展为更适合以太网架构的“服务交互”。

在 AUTOSAR CP 中，SOME/IP 并不是孤立存在的协议模块，而是需要和 RTE、SomeIpXf、LdCom、PduR、SoAd、TcpIp/Eth、Sd 等模块一起理解。业务报文链路负责真实数据传输，SOME/IP-SD 链路负责服务发现和事件订阅，两者共同构成完整的 SOME/IP 通信能力。

结合 TC397 平台实践可以看到，完成 SOME/IP 通信不仅需要理解协议格式，还需要梳理通信矩阵、服务接口、IP/端口、PDU 路由、服务发现和多核部署等工程化内容。只有把协议、配置、运行环境和调试手段串起来，才能真正把 SOME/IP 从文档中的协议概念落到可运行、可抓包、可验证的车载通信链路中。

打开APP阅读更多精彩内容