📚 课程目录第3章 RTA-CAR工程创建与配置

3. RTA-CAR工程创建与配置

RTA-CAR 的工程创建并不是“新建一个空项目然后写代码”，而是把整车或 ECU 的通信描述、ECU 资源约束和 RTA 运行时配置三者对齐的过程。一个可用的 RTA-CAR 工程，其核心输入是 ARXML（AUTOSAR 描述文件），核心约束是 ECU Extract（从整车 ARXML 中裁剪出的本 ECU 相关子集），核心产物是 RTA 配置与可编译的代码框架。本节按“新建工程 → 导入 ARXML → 配置 ECU Extract → 设置工程参数 → 生成代码框架”的顺序展开，重点说明每一步实际发生了什么、参数如何影响后续结果。

一、新建 RTA-CAR 工程

在 RTA-CAR 的工程向导中，首先选择目标 AUTOSAR 版本（如 4.2.2 或 4.4.0）与目标芯片/编译器工具链。版本选择不是形式项：ARXML 的 schema、BSW 模块的 API 签名、RTE 生成规则都随版本变化，若工程版本与 ARXML 版本不一致，导入阶段就会报 schema 校验错误。工程目录建议按如下结构组织，便于后续与 CI 集成：

MyEcu_RTA/
├── arxml/            # 原始与裁剪后的 ARXML
│   ├── input/        # 整车/系统级 ARXML
│   └── extract/      # ECU Extract 输出
├── config/           # RTA 配置（.rta 工程文件、BSW 参数）
├── generated/        # RTA 生成的代码框架
├── src/              # 手写应用代码与回调
└── build/            # 编译脚本与产物

新建完成后，工程处于“无描述”状态，此时 RTA 的配置树为空，必须先导入 ARXML 才能建立 ECU 的通信与软件组件视图。

二、导入 ARXML

导入 ARXML 时，RTA-CAR 会解析文件中的元素类型：SWC（软件组件）、Port（端口）、Interface（接口）、Signal、PDU、Frame、ECU 资源等。导入后应重点核对三类信息是否完整：

软件组件与端口：确认本 ECU 上运行的 SWC 及其 PPort/RPort 是否齐全，端口接口类型（Sender-Receiver、Client-Server）是否正确。
通信矩阵：Signal → PDU → Frame 的映射关系，以及每个 PDU 的周期、发送方式（周期/事件）。
ECU 资源：ECU 实例名、CanIf/Com 相关配置、OS 任务与中断的初步描述。

导入后若出现“未解析引用”或“重复定义”，通常说明整车 ARXML 中包含了多个 ECU 的描述，或存在版本混用。此时不要急于手工修补，而应进入下一步用 ECU Extract 做裁剪。

三、配置 ECU Extract

ECU Extract 的本质是“从系统描述中抽取本 ECU 视角的子集”。整车 ARXML 描述的是整个网络，而单个 ECU 只需要它收发的信号、它承载的 SWC、它使用的 PDU 与 Frame。Extract 配置的关键是选择正确的 ECU 实例，并指定裁剪规则。典型配置项包括：

配置项	作用	示例值
ECU Instance	指定目标 ECU 实例名	ECU_Engine
Include SWC	是否包含该 ECU 上的 SWC	是
Include Signal	是否保留相关信号	是
Include Frame	是否保留相关帧	是
Remove Unused	删除未引用元素	是

裁剪后应检查：本 ECU 的发送 PDU 是否都在，接收 PDU 是否只保留了实际使用的信号，避免把其他 ECU 的通信内容带入本工程。Extract 结果会作为后续 Com、CanIf、PduR 配置的输入。

四、设置工程参数

工程参数决定生成代码的形态与运行行为，必须与硬件和系统约束一致。以下参数在集成调试中最容易出错，应逐项确认：

OS 参数：任务数量、优先级、调度策略（抢占/非抢占）、栈大小。任务划分应与 SWC 的 Runnable 触发方式对应，例如 10ms 周期任务承载周期 Runnable，事件 Runnable 绑定到对应 Task。
Com 参数：信号字节序（大端/小端）、初始值、超时监控（Timeout）、更新位（Update Bit）。字节序错误会导致信号解析完全错位，是调试中最常见的通信故障之一。
CanIf 参数：波特率、采样点、控制器模式、硬件对象（HOH/HTH/HRH）分配。采样点与整车网络不一致会造成随机丢帧。
RTE 参数：生成模式（标准/优化）、API 命名规则、是否生成 SWC 桩函数。

建议在首次生成前，把 ECU Extract 结果与工程参数做一次交叉核对：Extract 中出现的每个 PDU 都应在 Com 中有对应配置，每个 Runnable 都应在 OS 中有触发源。缺失项会在生成阶段以警告形式列出，不要忽略。

五、生成代码框架与结果判读

点击生成后，RTA-CAR 会输出 Rte.c/h、Com_Cfg.c/h、CanIf_Cfg.c/h、Os_Cfg.c/h 以及各 SWC 的回调桩文件。生成结果是否可用，可从三个层面判断：

编译层面：生成文件与手写代码一起编译，无未定义符号、无重复定义。若出现 Rte_Write 未定义，通常是 RTE 生成模式或端口绑定未配置。
配置一致性：Com 中的 PDU ID 与 CanIf 中的 HRH/HTH 对应关系正确，PDU 长度与 Frame 长度匹配。
运行层面：下载后观察周期报文的实际周期与信号值。例如配置 10ms 发送的报文，用 CAN 分析仪测量应在 10ms±1ms 内；若偏差过大，应检查 OS 任务周期与 Com 发送模式。

生成代码框架只是起点，不是终点。RTA 生成的 Com/CanIf/Os 配置属于“可编译的骨架”，实际信号处理逻辑、故障响应和应用算法仍需在 SWC 回调中实现。不要直接把生成结果当作完整 ECU 软件。

完成本节操作后，工程应具备：可解析的 ARXML 输入、裁剪正确的 ECU Extract、与硬件一致的工程参数，以及可编译的代码框架。后续的 BSW 配置、RTE 集成与诊断栈添加，都建立在这一步的正确性之上。