3. ETAS RTA-CAR与安全开发环境搭建
RTA-CAR 是 ETAS 面向 AUTOSAR Classic Platform 的嵌入式基础软件与配置工具链，其核心由 RTA-CAR 配置器（基于 Eclipse 的 RTA-CAR Explorer）、BSW 模块生成器、MCAL 配置工具以及编译集成脚本组成。在安全开发语境下，环境搭建的目标不仅是“能编译”，而是让工具链、工程结构、模块选型与工作空间都满足 ISO 26262 对工具置信度（TCL）、配置可追溯性和构建可复现性的要求。本节围绕工具链安装、工程配置、安全相关模块选型与工作空间初始化四个环节展开，并给出可执行的配置示例。
一、工具链安装与版本锁定
RTA-CAR 的安装通常以发行包（Release Package）形式提供，包含 RTA-CAR 主程序、RTA-RTE、RTA-BSW、RTA-OS 以及对应 AUTOSAR 版本的模板工程。安装前应先确认三项输入：目标 AUTOSAR 版本（如 R4.2.2 或 R4.4.0）、目标 MCU 与编译器（如 Infineon TC3xx + Tasking V6.2r2）、以及安全等级（ASIL B 或 ASIL D）。这三项决定了后续可用的 MCAL 驱动包和 BSW 模块版本。
安装过程建议采用独立目录并记录版本指纹，例如：
# 示例：安装目录与版本记录（参数为教学示例）
RTA_CAR_HOME=/opt/etas/rta-car-r422
RTA_CAR_VERSION=RTA-CAR 4.2.2
MCAL_PACKAGE=TC3xx_MCAL_2.3.0
COMPILER=Tasking_V6.2r2
# 记录到工程根目录的 toolchain.lock 文件
echo "$RTA_CAR_VERSION | $MCAL_PACKAGE | $COMPILER" > toolchain.lock版本锁定是安全开发的关键动作。ISO 26262-8 要求对工具链进行版本管理，避免因工具升级导致生成代码行为变化而无法追溯。建议将 toolchain.lock 纳入版本控制，并在构建脚本中校验实际版本与锁定版本是否一致，不一致时直接终止构建。
二、工程配置与工作空间初始化
RTA-CAR 工程以“工作空间（Workspace）+ 工程（Project）”两级结构组织。工作空间是配置器的工作目录，工程则对应一个 ECU 的完整 BSW 配置。初始化时先创建工作空间，再导入模板工程，随后按 ECU 硬件资源调整 MCAL 与 BSW 参数。
工作空间初始化的典型操作如下：
# 示例：工作空间初始化（教学示例）
mkdir -p ~/rta_ws/ecu_demo
cd ~/rta_ws/ecu_demo
# 从模板复制基础工程
cp -r $RTA_CAR_HOME/templates/R4.2.2/TC3xx_Base ./ecu_demo_project
# 启动配置器并指定工作空间
$RTA_CAR_HOME/eclipse/rta-car -data ~/rta_ws/ecu_demo工程配置的核心是 .arxml 文件的组织。RTA-CAR 将配置分为系统描述、ECU 资源、BSW 模块配置和 RTE 配置四类。安全相关配置应单独建立目录，例如 /Safety，用于存放 Wdg、Fls、E2E、Crc 等模块的配置，便于审计时快速定位。
三、安全相关模块选型
安全相关模块的选型应基于“安全机制—模块—诊断覆盖”的对应关系。下表给出常见安全机制与 RTA-CAR 模块的映射示例（参数为教学示例，实际项目需按安全分析确定）：
| 安全机制 | RTA-CAR 模块 | 关键配置项 | 典型诊断覆盖 |
|---|---|---|---|
| 程序流监控 | WdgM | 监督实体、检查点周期 | 高 |
| 看门狗 | Wdg / WdgIf | 触发窗口、超时时间 | 高 |
| 数据完整性 | Crc | CRC 类型、计算范围 | 中 |
| 端到端保护 | E2E | Profile、数据ID | 高 |
| 存储校验 | Fls / Fee | 扇区校验、冗余块 | 中 |
| 时钟监控 | Mcu / Gpt | 时钟源、超时阈值 | 中 |
选型时需注意模块间的依赖关系。例如 WdgM 依赖 WdgIf 和具体 Wdg 驱动，E2E 依赖 Com 或 PduR 的调用点。若目标为 ASIL D，应优先选择支持内存保护（MPU）和运行时校验的模块组合，并在配置中启用 WdgM 的 WdgMTriggerCondition 与 WdgMExpiredSupervision 等安全相关参数。
四、工作空间初始化后的验证
初始化完成后，应执行一次最小构建验证，确认工具链、工程与模块配置三者一致。验证步骤包括：生成 BSW 代码、编译链接、检查生成文件中的安全相关配置是否生效。例如检查 WdgM_Cfg.c 中是否包含预期的监督实体数量，检查 E2E_Cfg.c 中是否包含配置的 Profile。
# 示例：最小构建验证（教学示例）
cd ~/rta_ws/ecu_demo/ecu_demo_project
make generate # 生成 BSW 代码
make all # 编译链接
grep -c "WdgMSupervision" generated/WdgM_Cfg.c
# 预期输出：与配置的监督实体数量一致，例如 3若生成代码中缺少安全模块配置，通常说明模块未在配置器中激活，或 .arxml 未正确导入。此时应回到配置器检查模块的 Active 属性，并确认工程引用的 .arxml 路径与工作空间一致。
toolchain.lock 和构建脚本一并提交到版本库，形成可复现的基线。后续每次工具升级或模块变更都应更新基线并重新执行最小构建验证。上图将工具链、工程、模块与工作空间四层关系集中呈现：工具链层通过 toolchain.lock 锁定版本，工程层以 .arxml 分类组织并将安全配置放入 /Safety 目录，模块层按“机制—模块—诊断覆盖”选型，工作空间层完成初始化与最小构建验证。四层之间是逐层约束的关系，任何一层版本或配置变化都会影响最终生成代码的安全属性，因此建议在每次变更后重新执行验证。