1 引言

1.1 ADAS 软件栈分层回顾

在典型的 ADAS ECU 软件体系中，按照 AUTOSAR 标准可以划分为三层结构：

  1. 应用层（Application Layer）：由多个软件组件（Software Component, SW-C）构成，用于实现特定功能，例如：目标检测、车道识别、轨迹规划、纵横向控制等。这一层体现算法与业务逻辑。

  2. 运行时环境（Runtime Environment, RTE）：作为中间件，负责软件组件之间、以及软件组件与基础软件之间的数据与服务交互。

  3. 基础软件层（Basic Software, BSW）：提供任务调度、通信协议栈（CAN、Ethernet）、存储管理（NVM）、诊断服务（UDS）等通用能力。

这种分层结构的目的在于实现 算法逻辑与硬件平台的解耦，从而使软件能够跨芯片、跨 ECU 平台进行迁移。

1.2 为什么需要 RTE

在没有 RTE 之前，应用层组件通常需要直接访问底层驱动或协议栈。例如，从 CAN 中读取目标信息、从 NVM 读取标定参数、或向执行器发送控制指令。这种方式存在两个核心问题：

  1. 强绑定：应用层逻辑与硬件驱动紧密耦合，难以在不同 ECU 或不同 SoC 平台上复用。

  2. 通信模型不统一：不同数据来源、类型和访问方式不一致，组件之间的接口难以标准化。

为解决上述问题，AUTOSAR 引入 RTE 作为统一中间层：

  • 屏蔽底层硬件、驱动和通信协议的差异；

  • 为软件组件之间提供标准化数据交互接口；

  • 使用自动代码生成确保系统描述与运行行为保持一致。

因此，RTE 的核心意义可以归纳为一句话：

应用层的算法不再关心“数据从哪里来、如何传递”，只需从标准化端口读取或写入数据。

2 RTE 是什么

2.1 RTE 的角色与定位

RTE（Runtime Environment）是 AUTOSAR 中 位于应用层与基础软件之间的中间件层。其主要作用是：

  • 为软件组件提供访问外部数据或服务的统一接口；

  • 根据系统配置生成可直接编译运行的代码；

  • 实现软件组件之间、组件与硬件之间的隔离。

在 ECU 构建过程中，RTE 并不是手写编程的模块，而是由 AUTOSAR 工具链根据 .arxml 系统描述文件 自动生成，每块 ECU 都拥有其 专属版本的 RTE。

2.2 虚拟功能总线（VFB）概念

RTE 表现出的通信模型来源于 AUTOSAR 的一个核心抽象：Virtual Functional Bus（虚拟功能总线，VFB）。

  • 在系统设计阶段，开发者并不关心软件组件运行在哪个 ECU 上；

  • 各组件之间通过逻辑端口互相传递数据，形成虚拟连接关系；

  • RTE 在实现阶段根据部署配置，将这些“逻辑连接”映射为实际运行机制：

场景

RTE 映射方式

软件组件在同一 ECU

使用内存共享或函数调用完成数据传递

软件组件跨 ECU 分布

通过 BSW 的 COM → PduR → 通信驱动 在总线上完成传输

因此，VFB 负责抽象连接，RTE 负责具体实现。

3 RTE 解决的核心问题

3.1 解耦算法与硬件

在 ADAS 系统中，感知、融合和控制等软件组件往往需要访问传感器输入与底层执行器控制接口。如果算法直接依赖硬件驱动或通信协议，那么当 ECU 换芯片、换供应商或通信接口调整时，算法代码必须跟着修改。

RTE 通过标准化接口完成硬件抽象，使软件组件只通过端口收发数据，不关心数据来源和传输方式。例如：

  • 读取摄像头目标信息：Rte_Read(SensorTargets)

  • 写入控制执行量：Rte_Write(ControlCmd)

无论底层是 CAN、以太网、共享内存，还是模拟测试环境（SIL/HIL），算法代码无需变化，提升跨平台复用性。

3.2 提供统一通信方式

不同组件之间可能存在周期数据交换、服务调用、模式通知等多种通信需求。RTE 对这些通信形式进行了收敛与统一，对外表现为一致的 API 接口，对内根据配置选择对应传输机制。

常用通信形式包括：

  • Sender-Receiver：用于周期性数据，如车辆状态、融合结果

  • Client-Server：用于调用服务类组件，如地图查询、路径规划求解

  • Mode-Switch：用于系统模式变化分发，如从“自适应巡航”切换到“车道居中控制”

统一通信模型减少接口差异带来的维护负担，提高系统可理解性。

3.3 调用接口而非直接访问底层

应用层组件不再直接访问 BSW 或通信驱动，而是使用 Rte_XXX 接口访问端口数据或服务。

这意味着：

  • 应用层关注功能，不关注网络封包、驱动细节

  • 调试与验证可以在模型级或仿真环境完成

  • 改变数据通道只需修改配置文件，而不改变算法代码

这使得 ADAS 系统更适合大规模协同开发和软件演进。

4 RTE 如何工作

4.1 软件组件与端口模型

在 AUTOSAR 中，每个软件组件都通过端口定义数据或服务接口：

  • PPort（Provided Port）：输出数据或提供服务

  • RPort（Required Port）：输入数据或调用服务

RTE 在系统构建阶段根据组件连接关系生成端口映射结构，以保证组件间数据能够正确传递。

4.2 Rte_Read 和 Rte_Write 的数据流

当软件组件调用 Rte_Read(InputSignal) 时：

  1. RTE 根据映射表查找该信号对应的数据源

  2. 若源组件在同 ECU，则直接从共享内存读取

  3. 若信号来自其他 ECU，则从 COM 模块接收缓冲区读取

类似地，Rte_Write(OutputSignal) 则是将数据写入内存、队列或发往总线。

因此，Rte_Read 和 Rte_Write 是应用层使用最频繁的访问接口。

4.3 跨 ECU 通信依赖 COM 模块

当数据在不同 ECU 之间传输时，RTE 本身并不直接处理网络封装，而是将数据交由基础软件层完成：

RTE → COM → PduR → 网络驱动（CAN/Ethernet）

RTE 保持接口一致性，同时将网络通信细节完全隐藏在 BSW 内部。

5 在 ADAS 中的实际意义

5.1 感知-融合-控制链路中的数据流示例

以典型的 L2 级别车道居中控制功能为例，其数据链路包含三个主要阶段：摄像头目标感知、环境融合与车辆运动控制。

数据在链路中的流动路径可以抽象表示为：

摄像头感知组件 → 融合组件 → 控制决策组件 → 执行器接口组件

在该链路中，各组件以 Sender-Receiver 模式通过 RTE 端口交换信息。例如：

  • 感知模块向融合模块提供车道线模型、目标车辆状态；

  • 融合模块整合多传感器结果并输出目标轨迹；

  • 控制模块基于轨迹规划结果生成转向和加速度指令；

  • 执行器接口模块将控制命令交由底层驱动处理。

在无 RTE 的情况下，这些数据交换需要直接实现为共享内存访问或网络消息处理，不同开发团队之间需要反复沟通数据格式和访问约定，具有较高耦合风险。RTE 将数据交互形式固定为端口信号，使各功能组件在逻辑上独立可替换，有利于模块化开发和验证。

5.2 可移植性与平台迁移能力提升

在 ADAS 软硬件快速演进的背景下，ECU 更替与处理器架构切换较为常见。例如，加速从传统 MCU 平台向高算力 SoC 迁移，或者由单 ECU 架构转向分布式域控制架构。

基于 RTE 的软件组件仅依赖端口接口，因此在迁移过程中：

  • 算法代码无需修改；

  • 只需要调整系统描述和信号映射配置，重新生成 RTE；

  • 可在 SIL（Software-in-the-Loop）与 HIL（Hardware-in-the-Loop）环境中快速验证。

这使得 ADAS 系统具备更好的演化能力，能够适应供应链变化和硬件升级。

6 总结

6.1 RTE 的价值归纳

RTE 是 AUTOSAR 软件架构的核心中间层，其主要作用可以概括为：

  • 通过端口模型实现组件解耦，使算法逻辑独立于硬件平台；

  • 提供标准化通信接口，统一 Sender-Receiver 与 Client-Server 等多种交互方式；

  • 通过自动生成代码维持系统描述与运行行为的一致性；

  • 使软件系统具备可扩展性和可迁移能力，符合智能驾驶软件的迭代特性。

基于 RTE 的组件化设计，使 ADAS 软件能够在复杂系统中保持结构清晰、边界明确，降低协同开发与长期维护成本。

6.2 RTE 的存在

在日常开发中，RTE 通常由工具链自动生成，开发者更常直接调用 Rte_Read、Rte_Write 或端口服务接口。只有在以下场景中，RTE 的存在感会变得清晰：

  • 组件需要迁移到不同 ECU 或不同芯片平台；

  • 数据交互方式发生变化，如由共享内存改为以太网传输；

  • 系统集成阶段出现信号映射不一致、端口配置不完整等问题。

换句话说，RTE 是系统稳定性和可维护性的隐性支撑结构，越是在大型复杂软件工程中，它的价值越明显。