简介：面向AUTOSAR开发者的ECU配置流程文档，来自RTA-CAR 12.1.0工具链的Workflow 03。文档从工作流程01/02生成的系统描述出发，讲解创建ECU Extract、配置EcuC值集合与RTE/OS容器、完成OS/RTE/BSW配置及代码生成，并补充服务SWC映射与更新ECU提取等后续步骤，帮助读者建立从系统级设计到ECU级代码生成的整体路径。压缩包为1个PDF文件，大小1.12MB，内容为完整的应用笔记，包含目录、定义表、工具链版本与前置条件说明，并配有分步操作指引和AR Explorer界面说明，适合已掌握AUTOSAR基础术语、希望上手RTA-CAR工具链的工程师学习。目前已有523人学习浏览，文档还说明了与MCAL及集成代码配合后在虚拟或物理目标上测试的方法，具有直接的项目参考价值。
1. ECU Configuration 的起点：先定边界，再谈配置
做 AUTOSAR 项目时，常被问起一个问题：系统级 System Description 已定稿，ECU 侧的配置到底从哪一步开始？ETAS RTA-CAR 12.1.0 工作流给出的答案是先做 ECU Extract。它不是一次普通导出，而是把整车级拓扑、通信矩阵和软件组件约束裁剪到这个 ECU 自己的边界。边界定了，RTE、OS、BSW 的配置才有挂载点。这篇笔记基于 RTA-CAR 12.1.0，沿着官方工作流 03 的路线，走通从 ECU Extract 创建、EcuC Value Collection 配置、OS/RTE 配置到 BSW 代码生成，再到服务 SWC 映射与 RTE/OS 再生成。适合已完成 System Description、准备把配置下沉到 ECU 的工程师，也适合 RTA-CAR 装好了但不知道先点哪个按钮的人。
2. 从 System Description 拆分出 ECU Extract，并建立 Ecuc 容器
2.1 为什么需要 ECU Extract 而不是直接用 System Description
System Description 描述的是整车视角，里面包含多个 ECU、它们之间的连接拓扑以及整张通信矩阵，而某一款 ECU 真正关心的只是自己的 SWC、端口和信号。如果直接拿 System Description 去生成代码，生成器无法判断哪些元素属于当前 ECU、哪些又是别的 ECU 的东西。ECU Extract 就是这道阀门，它把系统描述中与该 ECU 相关的元素抽出来，形成一份独立描述，后续 RTE、OS、BSW 的配置全部以它为基准。
RTA-CAR 12.1.0 工具链里，这个动作由 ISOLAR-AB 完成。很多人第一次打开工程时找不到 RTE 和 OS 的配置入口，原因往往不是工具坏了，而是 Value Collection 没有正确关联到 ECU Extract。注意，ECU Extract 的创建不产生任何代码，也不修改 System 本身，它只是生成一个引用关系，但这个引用关系决定了后面所有 ECU 配置的语境。多 ECU 项目里，每个 ECU 都要走一遍同样的拆分，拆得越干净，后面代码生成阶段越少出现交叉引用错误。
2.2 创建 ECU Extract：记住去掉 Ignore comspec conflicts
在 ISOLAR-AB 的 AR Explorer 中选择 System 节点，右键菜单选择 Create ECU Extract。弹出窗口中有一项 Ignore comspec conflicts，需要把勾选去掉。这个选项默认是勾上的，含义是通信规格冲突会被静默忽略。比如报文信号长度不一致、周期属性有出入，勾选后工具直接按第一条定义处理，问题被压到后面才暴露。去勾选后这些冲突会直接报出来，表面上多了一步处理，实际上是在配置早期就把脏数据清理掉。
以工作流 02 从 DBC 导入报文为例，DBC 里信号定义和 System Description 中的网络通信参数出现不一致很常见。保留 comspec 检查，ISOLAR-AB 会告诉你冲突点在哪；直接忽略，等 RTE 生成时读到残缺约束再回头查，定位成本高得多。点击 Finish 后，ISOLAR-AB 会在 AR Explorer 中生成 EXTR_ApplicationECU 节点，位置在 System 节点上方。节点名由工程名推导而来，如果你的工程不叫 ApplicationECU，前缀会跟着变，这不影响后续操作。如果这个阶段报了和跨 ECU 连接器相关的错误，按日志提示去 ISOLAR-A 帮助文档搜 EcuExtract，通常是连接器定义本身的问题，需要回到工作流 02 去修，而不是在弹窗里强行忽略。
提示：这里最容易犯的错是把 Ignore comspec conflicts 保留勾选。省一时麻烦，后面 RTE 生成时定位问题反而更耗时。
2.3 配置 EcuC Value Collection 并让它指向 ECU Extract
ECU Navigator 是 ECU 配置的入口。左侧 Bsw Modules 树里默认有一个 EcucValueCollection_0，先把它重命名为 EcucValueCollection。名字短一点，后续在生成脚本和路径检查时都不容易出错。双击打开这个 Value Collection，第一次打开时 RTA-CAR 12.1.0 会弹出 Prerequisite for RTE Configuration 对话框，要求选择该 Value Collection 对应的 ECU Extract。这个弹窗很容易被忽略，直接关掉也能继续操作，但关联不会建立。
在下拉框里选择第 2.2 节生成的 ECU Extract，点 Finish。完成之后，编辑器里会自动出现 Rte 与 Os 两个容器。这两个容器不是可选项而是必需项，RTA-RTE 和 RTA-OS 生成器按固定路径查找它们。如果你打开后没看到这两个容器，说明关联没有生效。此时删掉当前 Value Collection，重新按上面的流程走一遍即可，不需要手动建容器。手动建的容器缺少必要的引用信息，生成器反而不认。
2.4 用 ARXML 内容验证关联是否正确
ECU Extract 的本质是 ARXML 描述，里面保存了从 System 继承下来的 SWC 原型、连接器和通信约束。想验证关联是否正确，可以直接打开 Extract 文件看容器引用：
<AR-PACKAGE> <SHORT-NAME>ApplicationECU_Pkg</SHORT-NAME> <ELEMENTS> <ECUC-EXTRACT> <SHORT-NAME>EXTR_ApplicationECU</SHORT-NAME> <ECUC-EXTRACT-CONTAINER-REF> <TARGET-REF>/ApplicationECU_Pkg/EcucValueCollection</TARGET-REF> </ECUC-EXTRACT-CONTAINER-REF> </ECUC-EXTRACT> </ELEMENTS> </AR-PACKAGE>这段 XML 里，ECUC-EXTRACT-CONTAINER-REF定义了 Extract 与 Value Collection 的绑定关系，TARGET-REF的路径必须与 ECU Navigator 里看到的节点路径一致。路径不一致时，后续生成的报错信息大多是 No EcuExtract found 一类。AR-PACKAGE的SHORT-NAME在不同工程里不同，不需要和示例完全一致。
更直接的验证方式是切回 ECU Navigator，看 Os 模块下是否自动带出 OSDEFAULTAPPMODE。只有 Value Collection 正确关联到 Extract，这个默认应用模式才会出现。这一步通过了，Extract、Value Collection、OS/RTE 容器的三角关系就算搭稳了。
3. 配置 OS 与 RTE：OsTask 是 Runnable 的调度载体
3.1 OS 容器里的默认 AppMode 能做什么
打开 ECU Navigator 中的 Os 模块，OS Contents 下列出了 Application Modes。默认有一个 OsAppMode 名为 OSDEFAULTAPPMODE，基础工程有它就能工作，RTA-OS 生成代码时会把这个模式映射到运行时使用的应用模式枚举。这个枚举会参与任务状态机的判断：一个 OsTask 在哪个 AppMode 下被激活、在哪个模式下挂起，都受它约束。
如果项目只需要一个固定的运行模式，保持默认即可。如果要做多运行模式切换，比如从 Boot 到 App 的过渡，就需要在这里追加新的 OsAppMode，并配置对应的 OsAppModeSchedule。追加之后要注意一个连带影响：Rte_AppMode 枚举会跟着变，重新生成 RTE 前最好清一次旧输出目录，否则生成的枚举头文件里残留旧值，编译期很难发现。
3.2 创建 OsTask_ASW，选对 Schedule
RTE 中的 Runnable 不会自己跑，必须由 OsTask 承载。打开 EcucValueCollection 编辑器，底部切到 Os task Properties 标签页，右键表格空白区域选择 Create Os Task，弹窗直接 Finish。此时会生成一个默认任务 OsTask_0，把它改名为 OsTask_ASW。
这里有一项 Os Task Schedule 需要确认：可选值 FULL 与 OTHER。FULL 表示任务允许被更高优先级任务抢占，适合大部分应用层 Runnable；OTHER 表达的语义更接近不可抢占任务，适合与中断同步的短逻辑。实际项目中我见过不少因为缺省值没改，导致调度表生成不完整的情况。默认生成的 SCHEDULE 不一定是 FULL，所以每一步都要停下来看一眼，别急着点下一步。任务名和调度类型确定后，后面映射 Runnable 才不会乱。
3.3 Entity to Task Mapping 的拖拽映射
创建 Task 后，切到编辑器底部的 Entity to Task Mapping 标签页。右侧 UnMapped Entries 列出尚未映射的 Runnable，左侧 Mapped Entities 是 Task 列表。把 Runnable 从右侧拖到左侧对应 Task 上即可。以示例工程为例，三个典型 Runnable 的映射关系如下：
| Runnable | 所属 SWC | 映射 Task |
|---|---|---|
| Runnable_ReadSensor | SWC_Sensor | OsTask_ASW |
| Runnable_Control | SWC_Controller | OsTask_ASW |
| Runnable_SendSignal | SWC_Instrument | OsTask_ASW |
这张映射表最终写入 EcucValueCollection 的 Rte 容器，RTE 生成器根据它产出任务调度表。如果 Runnable 数量多，建议按执行周期分组：10ms 的控制链放一个 Task，100ms 的报文发送放另一个 Task，避免互相拖累。
常见失误是拖拽时把 Runnable 放到了 Task 的子节点而不是 Task 本体。界面表现是 UnMapped Entries 已清空，但 Task 的调度列表里没有对应实体，RTE 生成日志会提示 mapping missing。处理方式很简单，回到该标签页重新拖一次，不需要手改 ARXML。
等待映射的 Runnable 数量会随着 SWC 增长而增长，RTE 生成器对未映射 Runnable 的处理策略是报错而不是自动兜底。每新增一个 SWC，都要回到这里补一次映射。改动频繁时，可以在 ISOLAR-AB 里用搜索过滤 UnMapped Entries 列表，只显示本次新增的 Runnable，减少误拖。
4. BSW 配置生成与代码生成：ConfGen 和 RTA Code Generator
4.1 ConfGen 先补全配置，不直接产代码
RTA-BSW 自带的 Configuration Generation 工具（即 ConfGen）是容易混淆的点：它的作用不是生成 C 代码，而是把你在 ISOLAR-AB 中给出的模块配置补全成 BSW 模块的完整描述。举个例子，你为 CanSM 勾选了通道和中断，ConfGen 会补全控制器时钟、位时序、过滤器等默认参数，形成代码生成器可以消费的 ECUC 配置。没有这步，BSW 代码生成器看到的配置就是不完整的。
入口在 ISOLAR-AB 工具栏的 RTA-BSW Configuration Generation 按钮。点击后选择工程，在 Generate ECU Configuration 窗口设置 Output Path。这个路径决定了生成配置的存放位置，建议与工程内 ecu_config/bsw 目录层级保持一致。RTA Code Generator 后续按路径索引，路径层级错位会出现引用找不到的问题。第一次使用时把输出路径截图存一下，后面排查问题时能少走弯路。
4.2 EcuM 与 BswM 的样例配置从哪里来
RTE 生成器会主动查找 EcuM 和 BswM 生成的引用。EcuM 的唤醒原因枚举、BswM 的模式切换请求端口，都会被 RTE 生成器用来接线。这两个模块的配置逻辑比较固定，项目之间差异不大，从零配置的成本主要在理解状态机上。RTA-CAR 12.1.0 的 Starter Kit 里提供了现成样例，直接复制比自己从头配省事得多。
处理方式是按需复制：
- ecu_config/bsw/ecucvalues 下的所有 BswM_.arxml 与 EcuM_.arxml，复制到当前工程对应位置的 ecucvalues 目录。
- integrationCfg 整个目录复制到当前工程的 integration 目录。
- 如果 BSW 生成阶段报 MSI_Shutdown.arxml 缺失，从 system_config 目录补一份。
复制后回到 ISOLAR-AB 刷新工程，模块列表里才会出现 BswM、EcuM 以及相关服务组件。如果没出现，检查复制路径是否与工程实际目录名一致。常见错误是把整个文件树带着示例工程的前缀原样复制，导致 ARXML 里的路径引用全部失效。
4.3 用 RTA Code Generator 只跑 BSW 代码生成
RTA Code Generator 的入口在 ISOLAR-AB 工具栏的 Open RTA-Code Generator dialog，它同时管理 RTA-BSW、RTA-RTE、RTA-OS 三个生成器。首次只需要跑 BSW。在 Bsw 区域选中需要生成代码的模块：工作流 02 由 DBC 导入得到的模块全部勾上，BswM 和 EcuM 如果在模块列表里也一并勾选。
确认 BSW Output Path 指向 4.1 节设置的路径，点 Apply，然后取消 RTE 和 OS 的勾选，点 Run。如果模块列表里始终看不到 BswM 和 EcuM，先点工具栏左上角的蓝色 E 按钮重新执行 ConfGen。服务组件要等 ConfGen 完成后才会出现在 Components 区，这是很多初学同事卡住的地方。
生成失败的常见原因是 invalid reference。Starter Kit 里的 arxml 使用示例工程的路径前缀，与当前工程不一致就会报错。把报错信息中的短路径和当前工程实际路径对照，做一次全局替换，再重新生成，通常能解决。
提示：如果项目决定自己从零配置 BswM 和 EcuM，而不是用 Starter Kit，建议先把 Mode Management 专项工作流跑通再继续。否则 RTE 生成时的报错会让排查方向走偏，误以为是 RTE 配置本身出了问题。
5. 服务 SWC 映射、ECU Extract 更新与 RTE 验证
5.1 把 BSW 服务组件映射到组合
BSW 代码生成后，Components 区会出现紫色图标的 Service SWC，例如 CPT_ComM。它不会自动出现在组合中，需要在顶层组合编辑器里通过 Component Prototype 手动添加，选择 CPT_ComM 并确认。随后打开 SWC To ECU Mapping Editor，把新增组件拖进 System Mapping。
这一步修改了 System 模型，所以要重新右键 System，选择 Create ECU Extract 以更新 Extract。之后回到 RTA Code Generator 重新生成 BSW。此时如果不再出现 invalid reference，说明服务链路已经打通。注意，更新 Extract 不是覆盖，而是重新生成，生成后检查一下引用路径是否保持稳定。
5.2 给 BSW Runnable 单独建一个 OsTask_BSW
BSW 组件也会产生 Runnable，比如 BswM 的模式切换、ComM 的通信控制逻辑。如果混在 OsTask_ASW 里，它们与周期任务共享优先级，抖动来源不好定位。常见做法是新建 OsTask_BSW，把这些 Runnable 全部映射进去。创建方式与 OsTask_ASW 完全一致。
优先级上建议 OsTask_BSW 高于应用任务，因为模式切换和网络管理直接影响通信状态机，延迟几个周期可能触发超时。映射完成后，Entity to Task Mapping 里应当能看到所有 BSW Entity 集中在 OsTask_BSW 下，应用 Runnable 集中在 OsTask_ASW 下，层次清晰。
5.3 RTE 生成参数与结果验证
RTE 生成前在 Rte Main 页设置 Rte Output Path 与 Rte Log Path，并在 Rte Command 中追加：
--os-define-osenv=RTAOS40这个参数让 RTE 生成器按 RTA-OS 4.0 的 API 语义生成头文件和宏定义。缺少它时，生成出的适配代码可能指向旧的 OSTask 接口，编译期不报错，但运行时行为对不上。生成完成后验证输出目录：
find . \( -name "Rte_*.h" -o -name "Os.h" \) | xargs wc -l只要 Rte_Type.h、Rte_Events.h、Os.h 都存在，且行数与 SWC 端口数量级匹配，说明 ECU Configuration 链路是完整的。如果日志里报 Mode Management 引用缺失，回到 4.2 节检查 EcuM/BswM 的 arxml 复制是否到位，然后重跑一次 BSW 生成即可。
本文还有配套的精品资源，点击获取
