车企这几年发现，过去软硬件开销太大了，控制器数量和线束长度都是问题，因此汽车E/E架构都在向Zonal架构发展。

按行业常规估算，单颗边缘应用MCU成本约1美元，单车搭载20个边缘功能节点，仅MCU物料成本即达20美元；协议转换网关成本更高，单台约45美元，单车平均配备4个网关，仅此一项，架构升级后便可节省180美元的物料清单成本。

Zonal架构的推进，还与软件定义汽车（SDV）的发展密切相关。在这一过程中，10BASE-T1S受到关注。为充分释放集中式架构与10BASE-T1S的技术潜力，RCP（Remote Control Protocol，远程控制协议）作为一种轻量化车载通信协议正在逐渐兴起。这一协议可以“去MCU化”，替代传统“MCU+网关”组合架构，打造“域控制器-10BASE-T1S-RCP芯片-终端驱动”的扁平化极简架构。

常见车载以太网标准

芯片厂商也密切关注RCP，这个领域现在很火，NXP之类的厂商已经把RCP放到改变汽车未来的位置。

RCP是Open Alliance（开放联盟）TC18工作组目前正在定义的一种基于以太网的轻量级通信协议，目标是实现不同厂商设备之间的互操作。RCP最早由宝马于2023年5月在OPEN Alliance TC14会议上提出。2024年7月，OPEN Alliance成立TC18工作组，专门推进RCP的标准化工作。

RCP基于10BASE-T1S，实现了“无MCU”（MCU-less）边缘节点控制，促进汽车行业从分布式ECU架构向域控制器、区域控制器，最终转向集中式计算平台——这是软件定义车辆（SDV）时代的核心技术。

RCP主要用于控制连接到汽车以太网的传感器和执行器。这些设备作为网络端点，通过远程计算平台接收控制指令。开放联盟对RCP提出的需求包括：

• 通过车载网络远程控制外围设备接口；

• 支持外围设备接口的发现与配置；

• 提供标准化的远程访问协议；

• 支持通过网络读取和写入寄存器；

• 支持网络安全与功能安全，该项在通用规范中为可选要求；

• 支持远程控制过程中的时间同步，该项在通用规范中为可选要求。

简单理解，RCP的思路是将部分原本由边缘节点MCU完成的协议转换工作移至区域控制器（ZCU）或中央控制器（Central ECU），由上层控制器直接下发外围设备的操作指令，从而减少边缘节点的软件负担。

以SPI执行器控制为例，传统方案需要边缘节点的MCU解析区域控制器发送的SOME/IP报文，再通过SPI接口修改执行器寄存器。采用RCP后，区域控制器中的RCP Client可将控制操作转换为SPI指令，并封装进RCP报文。边缘节点的RCP Server解析报文后，即可通过SPI执行操作，减少本地协议转换。若执行器的寄存器映射发生变化，通常可通过更新区域控制器软件完成适配，具体仍取决于硬件设计。

RCP也考虑了10BASE-T1S的总线型连接。区域控制器可通过扩展命令，在一条报文中携带多个节点的地址和操作指令，从而控制多个边缘节点，或同一节点上的多个控制器。相关实现方式仍在讨论中。

RCP的主要特点是协议轻量、控制逻辑集中，省去了部分复杂的服务管理机制，降低了边缘节点的软件负担，也便于在区域控制器或中央计算平台统一更新控制逻辑。更换执行器或接口时，是否需要修改边缘节点软件，仍取决于具体硬件设计和实现方式。

需要强调一下，RCP与SOME/IP并非替代关系。SOME/IP适合服务发现、远程调用等复杂通信，RCP则更适合直接控制外围接口；RCP也不意味着CAN和LIN会被全面取代，实际选择仍取决于系统带宽、成本和控制需求。

从整车应用来看，RCP的潜在控制对象相当广泛，包括内饰照明的控制、前灯和尾灯控制、车门、悬架控制、汽车音频、电机控制及动力总成相关功能。

RCP的协议字段和封装方式也尚未完全确定。根据现有讨论，RCP报文可能根据应用场景封装在不同协议中，候选方案包括SOME/IP、IEEE 1722和Google Protocol Buffers等。

IEEE 1722很值得关注。我们可以看到，今年3月，英飞凌、Ethernovia、博世、恩智浦、瑞萨、德州仪器联合发布了一个提案：Proposal for PAR to incorporate TC18(RCP) into IEEE 1722。

IEEE 1722及其扩展版本1722B能够承载多种相关接口的控制数据，并通过ACF中的GPC类型支持通用协议控制信息。通信既可以采用不依赖IP的二层传输方式，也可以通过UDP/IP进行路由。

IEEE 1722还具有Linux和AUTOSAR生态支持，可与MACsec安全机制兼容，并已在音视频桥接（AVB）和时间敏感网络（TSN）系统中得到应用。IEEE 1722可以结合IEEE 802.1系列标准中的流预留等机制，支持对传输延迟的管理。借助这些现有能力，汽车厂商有望在成熟的TSN技术基础上推进RCP应用，减少重复开发工作，加快软件定义汽车架构的落地。

这几年厂商都很关注RCP，并展示了自己的方案。接下来，汽车开发圈来盘点一下当前厂商的最新动态。

onsemi：推出RCP全栈方案oncp

安森美的RCP解决方案名为oncp，涵盖MAC-PHY芯片、专用RCP控制芯片及配套软件工具。

T30HM1TS2500是符合IEEE 802.3cg标准的10BASE-T1S MAC-PHY芯片，可通过SPI接口连接通用MCU，帮助现有设备接入车载以太网。芯片支持低功耗休眠与唤醒、时间戳等功能，并具备PLCA协调器冗余、信号质量监测和线束故障检测等特性，目前已量产交付。

onsemi还开发了专用RCP芯片，集成10BASE-T1S的MAC、PHY和RCP协议引擎，支持GPIO、SPI、UART、I2C、PWM、LIN等多种接口。该芯片已于2026Q1向客户送样。采用这一方案后，部分边缘设备可以省去独立MCU及其底层软件，具体取决于设备的控制需求。

软件方面，oncp提供图形化配置工具，可用于设置引脚功能、设备接口和网络参数，并自动生成配置文件。对于采用Protobuf的车企，可直接对接相应软件流程；其他系统也可通过适配层，将现有控制指令转换为RCP指令。

应用方面，onsemi展示了包括车载音频、长距离线缆通信、位置传感器和模块化车门控制等。其中，无MCU车灯是一个典型案例。

传统车灯模组需要MCU处理通信指令并控制LED驱动器；采用RCP后，区域控制器可通过10BASE-T1S网络直接下发控制指令，减少车灯模组中的芯片数量和外围电路。控制逻辑集中后，车企也更容易通过软件更新车灯功能，例如调整灯光模式、实现动态灯效，以及支持用户自定义照明效果。

Microchip：中央计算模块与SPE

Microchip很早就就布局了10BASE-T1S，也很早就支持RCP标准。其表示，区域架构的一项关键设计是中央计算模块，中央计算模块与单对以太网（SPE）相结合，使区域网络架构成为可能，也为SDV奠定了基础。在采用SPE骨干网和中央计算模块的基础上，还需要考虑如何将外围设备接入网络，并由中央计算模块统一管理，以进一步简化线束设计。

传统方案通常需要通过MCU或网关转发外围设备的数据，因为外围设备无法直接接入网络并与中央计算模块通信。Microchip推出的LAN866x系列10BASE-T1S终端芯片支持基于RCP标准，适用于控制、照明和音频等应用。

该系列芯片可以在10BASE-T1S网络与LED驱动芯片、音频设备等外围器件之间直接传输数据，无需额外网关。借助RCP，这些设备可以在不配置MCU的情况下运行，也无需逐一为每个边缘节点编写软件，所有节点均可由中央计算模块统一控制。

这种集中控制方式有助于缩短开发周期、加快产品上市，同时降低采用SPE带来的线束重量和成本。由于减少了额外的协议转换环节，数据也可以从中央计算模块更直接地传输至各个边缘节点。

9月30日，Microchip扩展其10BASE‑T1S产品组合，推出LAN8679和LAN8680 10BASE‑T1S PMD收发器，以及集成收发器的LAN8660X/1X/2X端点产品系列。

LAN8679 收发器采用紧凑型8引脚VDFN封装，提供开放联盟3引脚（OA3P）标准化接口，可支持空间受限的边缘节点，同时减少引脚数量并简化设计复杂度。LAN8680在此基础上集成系统基础芯片（SBC）功能，包括电源管理、系统唤醒 / 休眠控制和看门狗监控功能。两款器件旨在提升可靠性和安全性，满足汽车和工业等严苛应用环境的需求。

LAN8660X/1X/2X端点产品系列将PMD收发器集成至单芯片远程控制协议（RCP）解决方案。该方案使设计人员无需外部PHY组件，即可为控制系统、照明和音频等应用部署紧凑且高度集成的边缘节点。

ADI：E2B的RCP方案

ADI开发了名为E2B（Ethernet to Edge Bus）的远程控制协议（RCP），旨在加快10BASE-T1S的应用。E2B简化了网络连接以及传感器、执行器的接入，并使边缘节点能够省去MCU。这样，边缘节点可以采用纯硬件实现，软件则集中部署和管理，与软件定义汽车的发展方向相契合。

ADI推出了多款面向汽车边缘总线E2B的10BASE-T1S RCP收发器，包括AD3300、AD3301、AD3304和AD3305。其中，AD3301为基础款RCP收发器；AD3304和AD3305分别集成2通道和4通道ILaS/ISELED接口；AD3300支持双模式，可用作E2B RCP收发器，也支持开放联盟（OPEN Alliance）10BASE-T1x MAC-PHY串行接口。

ADI的E2B已经将总线协议集成到了芯片中，这就意味着端点无需额外配置MCU，即可直接控制，降低了产品的开发门槛，尤其是软件编写者们。

另外，ADI的E2B通过SPI实现控制，无需以太网的MAC模块。其具体解释道：“传统的CAN和LIN协议的控制，需要先将命令打包成CAN协议或者LIN协议，再传到远端的MCU上进行解析，最后才到达控制系统。

ADI通过E2B在芯片内进行硬解析，然后将I2C或SPI的控制信号打包成以太网信息发到接收端，然后节点的E2B芯片进行硬解码，再通过GPIO口，控制节点的相关器件。”此外，E2B支持TSN时间同步，这对于汽车节点控制而言至关重要。

目前，宝马将成为首批部署E2B的OEM，当然未来E2B的潜力不止如此，在电机、传感器、车身等等传输与控制上都有可能。

目前，很多厂商也有10BASE-T1S的产品，具备RCP的能力。

TI（德州仪器）强调提出面向量产的RCE协议，包括10BASE-T1S、CAN FD Light和UART over CAN三层网络。TI在2026年发布了其中两款PMD收发器，具有TC10的汽车类10BASE-T1S多点OA PMD收发器DP83TD530-Q1及DP83TD535-Q1，另外，还有10BASE-T1S多点OASPIMAC-PHY以太网收发器DP83TD555J-Q1。

NXP（恩智浦）此前曾经联合捷豹讲过RCP专题。在汽车以太网PHY中，TJA1410面向10BASE-T1S应用，是一款符合开放联盟相关规范的三引脚接口PMD收发器，适用于汽车和工业以太网。

Infineon（英飞凌）对于RCP很积极，持续对IEEE进行提案。目前英飞凌的BRIGHTLANE以太网PHY芯片包括10GBASE-T1、5GBASE-T1、2.5GBASE-T1、1000BASE-T1、100BASE-T1、1000BASE-T、100BASE-TX和10BASE-T。

ST在官网也强调了RCP，不过ST主要提供Ethernet dataline ESD protection，不提供PHY。

目前来看，RCP正在决定着10BASE-T1S的普及速度。而相对10BASE-T1S，CAN XL也是在商业化的进程中不断竞争，目前TI、NXP已推出CAN XL相关收发器，MCU和AUTOSAR也开始支持。它保留了CAN总线的仲裁机制和布线方式，同时扩大数据载荷，并支持虚拟网络和协议隧道，适合从CAN FD升级、又暂时不需要全面转向以太网的场景。

CAN XL与10BASE-T1S并非直接替代关系。前者便于现有CAN网络升级，后者更适合融入统一的车载以太网架构。未来，二者可能分别承担本地控制和边缘以太网接入等任务。

RCP则仍处于标准和生态建设阶段。OPEN Alliance TC18正在推进相关工作，宝马已在AES 2026展示基于RCP的座椅方案，不过，规模量产仍有待验证，落地时间取决于标准进展和车企导入节奏。

欢迎关注“EEWorld电源开发圈”