简介面向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 DescriptionSystem 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 ExtractECU 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-NAMEApplicationECU_Pkg/SHORT-NAME ELEMENTS ECUC-EXTRACT SHORT-NAMEEXTR_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 与 RTEOsTask 是 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选对 ScheduleRTE 中的 Runnable 不会自己跑必须由 OsTask 承载。打开 EcucValueCollection 编辑器底部切到 Os task Properties 标签页右键表格空白区域选择 Create Os Task弹窗直接 Finish。此时会生成一个默认任务 OsTask_0把它改名为 OsTask_ASW。这里有一项 Os Task Schedule 需要确认可选值 FULL 与 OTHER。FULL 表示任务允许被更高优先级任务抢占适合大部分应用层 RunnableOTHER 表达的语义更接近不可抢占任务适合与中断同步的短逻辑。实际项目中我见过不少因为缺省值没改导致调度表生成不完整的情况。默认生成的 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映射 TaskRunnable_ReadSensorSWC_SensorOsTask_ASWRunnable_ControlSWC_ControllerOsTask_ASWRunnable_SendSignalSWC_InstrumentOsTask_ASW这张映射表最终写入 EcucValueCollection 的 Rte 容器RTE 生成器根据它产出任务调度表。如果 Runnable 数量多建议按执行周期分组10ms 的控制链放一个 Task100ms 的报文发送放另一个 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 Generator4.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_BSWBSW 组件也会产生 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-osenvRTAOS40这个参数让 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 生成即可。本文还有配套的精品资源点击获取