OPEN Alliance RCP 远程控制协议详解

技术笔记 › 车载网络
, , , ,

前言

随着汽车电子架构从分布式向**区域架构（Zonal Architecture）**演进，如何通过以太网统一控制分布在车身各处的外设接口，成为行业关注的焦点。OPEN Alliance 推出的 RCP（Remote Control Protocol） 正是为解决这一问题而生的标准化协议。

本文基于 OA RCP Specification v0.4.7 rev1 草案，带你全面了解这一新兴协议的设计理念、核心机制和应用场景。

一、什么是 RCP？

1.1 定义

Remote Control Protocol (RCP) 是一种基于客户端-服务器架构的远程控制协议，允许 RC 客户端通过车载以太网，远程控制连接到 RC 服务器端点上的设备。

核心思想：将应用逻辑集中到高性能计算机（HPC）中，边缘节点只保留标准化的硬件抽象层。

1.2 设计目标

RCP 的设计围绕五大目标展开：

目标 说明
远程访问底层接口 通过网络完整访问 SPI、I2C、GPIO 等外设，提供硬件抽象
同质化集成 标准化端点接口，屏蔽不同供应商硬件差异
弥补分布式系统局限 支持延迟/带宽优化、同步执行、抖动补偿、不可靠信道
软硬件解耦 不同供应商的 HW/SW 模块可互换，行为定义明确
前后向兼容 新旧版本可安全交互，忽略未知消息类型

1.3 为什么需要 RCP？

传统分布式架构中，每个 ECU 都包含完整的应用逻辑和硬件驱动，导致：

  • 外设芯片供应商绑定严重
  • 供应链缺乏弹性
  • 软件升级困难

RCP 通过 OEM IP 与商品 IP 分离 的方式解决这些问题：

  • OEM IP：应用逻辑、设备驱动等，集中在 HPC 中
  • 商品 IP：标准化的 RC Server + 物理接口，位于边缘节点

二、系统架构

2.1 整体架构

RCP 系统由以下核心组件构成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌─────────────────┐         ┌─────────────────┐
│  Central ECU    │         │   Zonal ECU     │
│  (RC Client)    │         │  (RC Client)    │
└────────┬────────┘         └────────┬────────┘
         │                           │
         └─────────────┬─────────────┘
                       │
               IVN (车载以太网)
                       │
         ┌─────────────┴─────────────┐
         │                           │
┌────────▼────────┐        ┌────────▼────────┐
│   Edge Node     │        │   Edge Node     │
│  (RC Server)    │        │  (RC Server)    │
│  ┌───────────┐  │        │  ┌───────────┐  │
│  │ Endpoint  │  │        │  │ Endpoint  │  │
│  │  (SPI)    │  │        │  │  (GPIO)   │  │
│  └───────────┘  │        │  └───────────┘  │
│  ┌───────────┐  │        │  ┌───────────┐  │
│  │ Endpoint  │  │        │  │ Endpoint  │  │
│  │  (I2C)    │  │        │  │  (PWM)    │  │
│  └───────────┘  │        │  └───────────┘  │
└─────────────────┘        └─────────────────┘

2.2 核心组件说明

组件 说明
RC Node RC 节点，可以是客户端或服务器
RC Client 客户端，通过网络调用端点功能；软件实现，OEM 负责
RC Server 服务器，提供可被客户端访问的端点（SPI、I2C、GPIO 等）
RC Endpoint 端点，RC Server 中每个可寻址的组件
RC Edge Node 边缘节点，RC Server + 附加通信层（PTP、MACsec 等）

2.3 RC Server 内部结构

RC Server 内部采用模块化设计：

  • RC 请求处理器：验证请求，路由到对应端点的请求存储区
  • 请求存储区：每个端点维护独立的请求队列
  • RC 响应处理器：聚合响应和确认，管理消息分片
  • 响应/确认队列：可被多个请求流共享
  • EP0（端点 0）：RC Server 自身，用于配置和状态管理
  • EP1（端点 1）：可选的休眠/唤醒功能

三、协议基础

3.1 协议栈

RCP 基于 IEEE 1722（AVTP 音视频传输协议）扩展而来：

1
2
3
4
5
6
7
┌─────────────────────────────────┐
│      RCP (Remote Control)       │  ← 本规范定义
├─────────────────────────────────┤
│   IEEE 1722 (AVTP, 0x22F0)      │  ← 传输层
├─────────────────────────────────┤
│      Ethernet (Layer 2)         │
└─────────────────────────────────┘

关键特性：

  • 二层协议，EtherType = 0x22F0
  • 也支持 IP/UDP 封装
  • 数据以 流（Stream） 形式组织
  • 每个 PDU 携带 stream_id 和发送方 MAC 地址

3.2 两种头部类型

头部类型 全称 用途
TSCF Time-Synchronous Control Format 包含呈现时间，用于定时执行的请求
NTSCF Non-Time-Synchronous Control Format 立即执行或条件执行的请求；也用于响应和确认

3.3 两种消息格式

RCP 使用 IEEE 1722 的 ACF（AVTP Control Format）扩展：

格式 全称 适用场景
ACF_ABB Abbreviated Byte Bus 标准请求、定时请求（简洁格式）
ACF_GBB Generic Byte Bus 条件请求、取消请求、带时间戳的响应（功能丰富）

3.4 端点寻址

  • byte_bus_id：在流内标识目标端点
  • RC Server 通过查找表映射：stream_id + byte_bus_id → endpoint
  • 同一端点可被不同客户端使用不同的 byte_bus_id 访问

四、请求类型详解

RCP 定义了三大类请求，支持灵活的执行模式。

4.1 标准请求（强制功能）

  • 格式：ACF_ABB
  • 执行时机：尽快执行（尽力而为）
  • TSCF 模式下：推迟到呈现时间执行
  • 关键字段：
    • transaction_num：流内请求标识
    • op：0=期望数据响应，1=不期望数据

4.2 条件请求（可选功能）

条件请求使用 ACF_GBB 格式，mtv=0（时间戳无效），条件编码在 message_timestamp 字段中。

子类型一览

类型 编码 说明
复合请求 0x0F / 0x8F 基于定序器（Sequencer）状态执行
复合等待 0x0B / 0x8B 接口达到指定状态时生成响应
触发执行 0x0E / 0x8E 基于触发信号发生执行
链式请求 0x01 顺序执行，等待前一个请求完成
定时请求 0x0A 在预定义的呈现时间执行

注意：0x0F/0x0B/0x0E 系列在看门狗溢出时会被清除；0x8F/0x8B/0x8E 系列则保持有效。

复合请求工作原理

复合请求是 RCP 最强大的特性之一，它允许构建基于状态机的执行序列：

1
2
3
Sequencer State: [State 1] → [State 2] → [State 3] → ...
                      ↓            ↓            ↓
                 Request A    Request B    Request C
  • 通过 cmp_sequencer 关联到特定定序器
  • cmp_start_state：达到此状态时开始执行
  • cmp_next_state：执行完成后设置的状态（0=保持不变）
  • cmp_repetitions：重复次数（0xFFFF=无限重复）

链式请求

  • 同一 AVTPDU 内的多个请求可串联执行
  • 链的第一个请求可以是任意类型
  • 后续请求等待前一个请求完成后再执行
  • 如果第一个请求有重复计数，整个链都会重复

4.3 取消请求

类型 编码 必选/可选 说明
清除全部 0x05 强制 清除同一流中的所有请求
清除非安全状态 0x06 可选 清除所有非安全状态的请求
清除单个 0x07 可选 通过 transaction_num 取消特定请求

正在执行的请求不会被中止。被取消的请求会返回 REQUEST_CANCELED 错误。

五、响应类型

RCP 定义了四种响应类型，通过 evt 字段区分：

响应类型 evt[3:0] 说明
确认 (Acknowledge) 0xF 请求已被接受并存入请求存储区
写响应 0x0 写请求成功执行（op=1，无负载）
读响应 0x0 读请求成功执行（op=0，含数据）
错误响应 < 0x9 执行失败（err=1，含错误码）

格式规则：

  • 带时间戳 → ACF_GBB 格式
  • 不带时间戳 → ACF_ABB 格式（默认）
  • transaction_num 与请求对应
  • evt 计数器（0x1-0x8）用于多响应请求，从 0x8 回卷到 0x1

六、时间戳机制

RCP 支持两种时间戳，基于 gPTP (IEEE 802.1AS) 同步。

6.1 两种时间戳对比

类型 位置 位宽 回卷周期 用途
呈现时间戳 (avtp_timestamp) TSCF 头部 32 bit ~4 秒 请求执行的最早时间
捕获时间戳 (message_timestamp) ACF_GBB 消息 48 bit ~585 年 信号捕获/请求接受的时间

6.2 关键规则

  • 呈现时间戳仅由客户端发送，服务器从不使用 TSCF 头部
  • 服务器始终使用 NTSCF 头部 + ACF_GBB 中的 message_timestamp
  • 确认时间戳 = 请求被接受的时间
  • 响应时间戳 = 物理接口捕获信号的时间
  • 每个端点可分别启用/禁用时间戳
  • 同步丢失时，本地振荡器继续运行（可能不精确），客户端负责取消请求

七、RC Server 生命周期

RC Server 有 5 个递进的生命周期状态：

1
Server_undiscovered → Server_discovered → Server_HW_configured → Server_RCP_configured → Server_RCP_runmode

各状态说明

状态 接受的操作
未发现 (undiscovered) 仅接受发现请求（EP0 读，stream_id=0，byte_bus_id=0）
已发现 (discovered) 仅 EP0 请求（ACF_ABB, NTSCF）；可通过 EP0 访问完整寄存器映射
硬件已配置 (HW_configured) 通过分配的 stream_id/byte_bus_id 访问端点配置；EP0 访问限于”根流”
RCP 已配置 (RCP_configured) 所有端点接受请求，但不执行（仅存入存储区）；部分配置锁定
运行模式 (runmode) 完全运行；端点执行存储区中的请求；定序器初始化为状态 1

关键规则

  • 状态只能逐步推进，不能跳过
  • 断电后从可恢复的最高状态启动（从非易失性存储器）
  • 每次状态转换时，配置可存入非易失性存储器
  • 标记为 W* 的参数在 RCP_configured 状态下禁止写入
  • 发现请求可广播，一次性查找网络中所有服务器

八、端点类型总览

RCP 定义了 13 种端点类型，覆盖汽车电子常用外设接口：

编号 端点类型 说明
EP0 RC Server 服务器自身 — 配置、状态、发现
EP1 唤醒控制 休眠/唤醒管理
— SPI SPI 控制器接口
— GPIO 通用数字 I/O
— PWM_OUT 脉冲宽度调制输出
— PWM_IN 脉冲宽度调制输入
— I²C I²C 控制器接口
— UART 通用异步收发器
— ADC 模数转换器
— LIN commander LIN 总线主站
— CAN controller CAN 总线控制器
— ISELED 集成智能嵌入式 LED
— MDIO 管理数据 I/O（PHY 控制）

端点特性

  • 每个端点有系统范围内唯一的可发现标识符
  • 物理端点提供硬件抽象（类似 MCAL），而非精确的硬件模型
  • 每个端点维护独立的请求存储区
  • 支持运行时配置更新、统计信息读取、端点特定功能调用

九、强制 vs 可选功能

强制功能（每个 TC18 兼容服务器必须实现）

  • ✅ NTSCF 头部处理
  • ✅ 标准请求处理
  • ✅ 端点 0（EP0）实现
  • ✅ 取消全部请求功能

可选功能包

时间同步功能包：

  • TSCF 头部处理
  • gPTP (IEEE 802.1AS) 实现
  • 定时请求支持
  • 带时间戳的确认和响应

复合请求功能包：

  • 复合请求 (0x0F, 0x8F)
  • 复合等待请求 (0x0B, 0x8B)
  • 至少 4 个定序器
  • 清除非安全状态请求 (0x06)

增强取消功能：

  • 清除单个请求 (0x07)

十、总结与展望

核心价值

RCP 协议的核心价值在于：

  1. 架构解耦：应用逻辑与硬件彻底分离，OEM 掌握核心 IP
  2. 供应链弹性：标准化接口降低供应商绑定风险
  3. 软件定义：外设功能可通过软件动态配置和升级
  4. 成本优化：边缘节点简化为标准化的”哑”设备

当前状态

  • 版本：v0.4.7 rev1（草案阶段）
  • 状态：仍在快速演进中
  • 参与方：BMW、NXP、Infineon、TI、Bosch、Cetitec 等

适用场景

  • 区域架构（Zonal Architecture）中的边缘节点控制
  • 车身电子（灯光、门窗、座椅等）的集中控制
  • 传感器数据采集和执行器控制的统一接口
  • 跨域控制器的外设共享

参考资料

  • OPEN Alliance RCP Specification v0.4.7 rev1
  • IEEE 1722-2025 Standard for Layer 2 Transport Protocol for Time Sensitive Applications
  • IEEE 802.1AS (gPTP) Timing and Synchronization

本文基于 RCP v0.4.7 rev1 草案整理，协议内容可能随版本更新而变化。建议以最新官方规范为准。