1 引言

在我之前的文章中，已对 ADAS 系统的 ASW 与 BSW 做了概述，并详细阐述了应用层的感知、融合、规控与执行流程。为了完整呈现 AUTOSAR 标准下软件组件的协作模式，本章将聚焦位于应用层与基础软件之间、所有 ECU 必须遵循的运行时环境（RTE）。作为 AUTOSAR 体系结构的核心中间件，RTE 通过以下三个方面，为 ADAS 系统提供坚实支撑：

  • 解耦硬件与算法
    RTE 通过标准化接口与自动生成的配置文件，将上层软件组件（SW‑C）与底层基础软件及总线（CAN、Ethernet 等）完全隔离，使得同一份算法代码可在不同 ECU 间复用。

  • 提供统一通信机制
    它承载了组件间及跨 ECU 的数据交换与服务调用，开发者只需面向“虚拟功能总线（VFB）进行逻辑设计，而无需关心底层网络协议的具体实现。

  • 保证实时调度
    在严格的时序约束下，RTE 协同底层操作系统（如 OSEK/VDX、Adaptive AUTOSAR EM），对各可运行实体（Runnable）进行周期或事件触发的精确调度，确保算法在预定时间点上得到执行。

本章将围绕 RTE 的定义与架构定位、核心功能、通信机制、调度策略及安全保障等方面，逐层深入解析其在 ADAS 系统中的“中间件大脑”角色。

2 RTE 定义与架构定位

2.1 RTE 定义

  • 运行时环境（RTE, Runtime Environment）：AUTOSAR 规范中介于应用层与基础软件（BSW）之间的中间件层，为软件组件提供统一的通信和调度接口。RTE 由 AUTOSAR 工具链根据 System Description 文件（.arxml）自动生成，每个 ECU 都有其专属的 RTE 实现。

  • 虚拟功能总线（VFB）：RTE 实现了“虚拟功能总线”概念，为软件组件之间以及组件与底层模块间的信息交换提供抽象层，使开发者无需关心底层总线拓扑与协议差异。

2.2 架构定位

2.2.1 三层架构一部分

  • 在 AUTOSAR 三层架构（基础软件、运行时环境、应用层）中，RTE 位于中间（点此查看），承接上层应用软件组件（SW‑C）与下层 BSW 模块之间的所有交互，屏蔽了硬件差异，确保跨平台及跨 ECU 的软件重用性。

2.2.2 ECU 专属实例

  • 每个 ECU 的 RTE 都是基于该 ECU 的配置和功能需求生成的。例如，多核 ECU 会为每个核生成独立的 RTE 分区，以满足并行执行和资源隔离的要求。

2.2.3 配置驱动生成

  • RTE 代码在 AUTOSAR 构建工具的 RTE Generation 阶段自动生成，包含 Contract Phase（接口校验）和 Generation Phase（代码生成），最终输出端口接口、连接映射及调度表等内容。

3 核心功能与职责

3.1 通信抽象与 API 提供

  • RTE API：为软件组件间通信提供标准化函数调用接口，包括

    • Rte_Read()：从其它 SW‑C 的输入端口或服务读取数据

    • Rte_Write()：向提供端口写入数据以供其它组件消费。

3.2 虚拟功能总线（VFB）映射

  • VFB 概念：在设计时，开发者面向“虚拟功能总线”定义组件间接口；在运行时，RTE 将这些逻辑连接映射到物理总线或内存拷贝等机制上。

  • 映射机制：

    • 同 ECU：通过共享内存或函数调用实现快速、低开销的数据拷贝。

3.3 配置驱动的代码生成

  • ARXML 驱动：在 AUTOSAR 工具链的 RTE Generation 阶段，基于 System Description（.arxml）文件，自动生成 RTE 源代码，包括：

    • Port/Interface 定义

    • 端口连接映射表

    • Runnable 与事件的调度表

  • 自动化流程：开发者无需手写中间件代码，所有接口函数、数据结构和调度逻辑均由 RTE Generator 工具输出，确保与模型描述的一致性 。

3.4 多种通信模式支持

  • 通信模式：RTE 实现了多种端口接口，满足不同业务场景需求：

    • Sender‑Receiver：点对点或发布‑订阅数据交换

    • Client‑Server：请求‑应答式服务调用

    • Mode‑Switch：模式切换通知与管理

    • Non‑Volatile Data：持久化数据读写

    • Parameter：运行时参数配置

    • Trigger：事件触发激活 Runnable

  • 扩展能力：针对每种模式，RTE 提供错误状态检测、超时管理及队列支持，以满足 ADAS 对数据时效性与可靠性的严苛要求 。

4 通信机制与接口

4.1 接口类型

AUTOSAR RTE 支持多种通信模式，以满足不同软件组件间的数据交换与服务调用需求：

  • Sender‑Receiver：基于数据元素的异步点对点或发布‑订阅式通信，适用于周期性或事件驱动的数据交换场景。

  • Client‑Server：同步或异步的请求‑应答式服务调用模型，客户端发起请求，服务器端执行并返回结果。

  • Mode‑Switch：用于向下游组件广播模式变更（如驾驶模式切换），下游组件可根据模式调整逻辑。

  • Non‑Volatile Data：与 NVBlock SW‑C 协作，实现数据在重启后保持不变的持久化读写。

  • Parameter：运行时参数或校准数据的读取接口，用于动态调整算法行为。

  • Trigger：基于事件触发执行 Runnable，可用于紧急任务或异步事件处理。

  • 端口类型：每种接口模式对应不同端口：Require（输入端口）、Provide（输出端口）、Provide‑Require（双向端口）。

  • 端口映射：在 .arxml 描述中，开发者定义 SW‑C 的端口与接口，RTE Generator 根据配置生成：

    • PPort（Provided Port）：提供数据或服务的端口

    • RPort（Required Port）：消费数据或调用服务的端口

    • CPort（Client Port）/ SPort（Server Port）：Client‑Server 模式下对应请求和响应端口

  • 连接管理：RTE 内部维护端口连接表，调用 Rte_Write()、Rte_Read()、Rte_Call() 等 API 时，自动完成内存拷贝或报文封装/解包。

4.3 跨 ECU 通信

  • COM 模块：RTE 对跨 ECU 的 Sender‑Receiver 和 Client‑Server 通信交由 BSW 层的 COM 模块处理，COM 将信号打包为 I‑PDU 并下发给 PduR。

  • PDU Router (PduR)：负责在 COM、LIN、CAN、Ethernet 等各通信模块间路由 I‑PDU，确保数据按照配置到达目标网络接口。

  • 物理传输：最终由 CAN 驱动、Ethernet 驱动等通信驱动层完成信号在网络总线上的收发；上层 RTE 感知不到底层传输细节。

4.4 Adaptive 平台与 SOME/IP

  • 服务导向：在 Adaptive AUTOSAR 中，跨 ECU 通信采用基于 SOME/IP 协议的服务导向架构（Service‑Oriented Architecture），通过 Ethernet 交换器进行高速数据交互。

  • 接口类型：提供 Service Interface（服务）和 API Interface（应用编程接口），应用层通过 SOME/IP 库调用远端服务。

  • 配置与安全：Adaptive 平台可配置安全策略（TLS 等），保证 SOME/IP 服务的认证与加密，满足高阶自动驾驶场景的安全需求。

5 可运行实体（Runnable）与调度

5.1 Runnable 实体定义与作用

  • Runnable 实体：Runnable 是软件组件（SW‑C）提供的一段指令序列，由 RTE 根据配置在其上下文中启动并执行；它是 AUTOSAR 中最小的可调度功能单元 。

  • 执行上下文：每个 Runnable 在 RTE 生成的接口（如 Rte_Read()、Rte_Write()、Rte_Call()）调用下运行，与底层操作系统任务紧密耦合，保障数据一致性和实时性 。

5.2 Runnable 类型与分类

  • Type 1 Runnables：仅包含可在有限时间内完成的指令，不含任何等待点（WaitPoint），通常映射到基本 OS 任务；适用于周期性或快速执行的功能 。

  • Type 2 Runnables：包含至少一个等待点，需在外部事件（如数据到达或模式切换）发生后继续执行，映射到支持等待状态的扩展 OS 任务 。

5.3 Runnable 激活与触发器（RTE 事件）

  • RTE-Event 配置：通过 ARXML 文件配置多种事件类型——TimingEvent（定时事件）、DataReceivedEvent（数据接收事件）、ClientRequestEvent（客户端请求事件）、ModeSwitchEvent（模式切换事件）、TriggerEvent（触发器事件）等，以指定 Runnable 的激活条件 。

  • 事件驱动与周期调度：定时事件可设定周期执行；而数据接收、服务调用或模式切换等事件仅在条件满足时触发 Runnable，优化资源利用并满足实时调度需求 。

5.4 调度机制与 OS 集成

  • 任务映射：在 RTE 生成阶段，工具链根据 ARXML 中的调度属性为每个 Runnable 分配或生成 OS Task，形成 Runnable–Task 映射表；运行时 RTE 依此表驱动调度和执行 。

  • 与 OSEK/VDX 协作：在 Classic AUTOSAR 平台上，RTE 调度依赖 OSEK OS 的基本/扩展任务模型，并可选用 OSEKtime 提供的高优先级时间触发机制；在 Adaptive AUTOSAR 中，则由 Execution Management 组件通过线程和服务管理实现更灵活的调度策略 。

6 错误检测与安全保障

6.1 数据状态监控

  • DataSendCompletedEvent：RTE 在完成数据发送后，通过 DataSendCompletedEvent 通知接收的 SW‑C，表明一次数据传输已结束。

  • Rte_Feedback API：提供数据完整性与有效性状态，如数据是否过期、失效或错误，组件可根据反馈决定是否采用默认值或触发降级逻辑。

6.2 错误传播与隔离

  • FDIR 过程：RTE 支持 Fault Detection、Isolation、Recovery（FDIR）框架，先检测错误（Error），再隔离源头，最后执行恢复动作。

  • 错误传播模型：错误可通过数据、控制流、资源访问或时序偏差等方式扩散；RTE 在检测到错误后，会尽早阻断传播路径，避免故障蔓延。

  • 隔离策略：隔离并非直接关闭组件，而是识别并定位错误源，生成诊断信息，以便后续恢复（如重启或降级）时使用。

6.3 冗余与容错恢复

  • 端到端通信保护：在 Sender‑Receiver 接口层启用 E2E Transformer Error 或 Protection Wrapper，利用 CRC、计数器等机制检测通信错误，接收方可独立验证数据一致性并自动发现异常。

  • 默认安全值与降级：当检测到通信或数据异常时，RTE 可提供预定义安全默认值，并触发降级策略，确保系统以安全模式运行。

  • 自动恢复：隔离完成后，通过调用 OSRestartTask 或 RTE 提供的 Partition Restart 接口，实现故障组件的重启或重置。

6.4 功能安全支持

  • ASIL 继承：根据 ISO 26262 ASIL 继承规则，RTE 与基础软件须遵循应用软件的最高 ASIL 要求，或通过分区与隔离措施证明“无干扰性”。

  • Freedom from Interference：通过内存分区、时间隔离和访问控制，防止一个 SW‑C 或 BSW 模块的错误蔓延至其他模块，从而满足 ISO 26262 第 6 章第 7 条款的要求。

  • 安全手册：对每种安全机制，需编制安全手册，明确故障模型、使用约束及验证方法，保证满足 ISO 26262 标准的功能安全验证要求。

7 总结

RTE 作为 AUTOSAR 三层架构的核心中间件，自动生成于 ARXML 配置文件，负责解耦应用层组件与基础软件，实现跨 ECU 及跨硬件平台的可移植性与复用性 。同时，通过虚拟功能总线（VFB）提供统一通信接口，消除了底层网络协议差异，简化了开发流程 。

在通信与调度方面，RTE 支持 Sender‑Receiver、Client‑Server、Mode‑Switch、Trigger 等多种接口模式，并与 OS（如 OSEK/VDX）或 Adaptive EM 协同实现周期与事件驱动的 Runnable 调度，满足 ADAS 对实时性的严格要求 。

在错误检测与安全保障方面，RTE 内置 FDIR 机制，支持端到端通信保护、错误隔离与自动恢复，并遵循 ISO 26262 ASIL 继承与内存/时间隔离原则，为 ADAS 系统提供稳定可靠的安全运行环境 。