★ FEATURED ARTICLE 简介面向汽车电子 AUTOSAR 开发者的实操型 PDF 文档围绕在 EB Tresos 工程中导入 SystemDesk 生成的 arxml 系统描述文件展开适合已具备 ECU 配置基础、需要完成配置替换、描述更新与代码生成的工程师参考。内容以十三个连续步骤串联完整流程从启动 tresos_gui、导入 workspace 工程到在 system 目录替换同名 arxml再通过 Im- and Exporters 调用 SysDes 与 DBC 导入器依次运行 EcuExtractCreator、SwdUpdater_Trigger 等向导直至编译工程并核对 Error Log 提示覆盖导入、更新、校验与排错等关键节点对导入器选择、提示框确认及常见错误定位均有说明。资源包仅含一个 PDF 文件大小约 674KB轻量易存便于随查随用。目前已有 3545 人学习可作为配置迁移与流程复盘的操作清单也适合团队内部交接和新人上手时对照参考帮助理清工具链协同的先后顺序减少重复试错。1. 双击 tresos_gui.exe 之前先弄清 arxml 该落在哪个目录接手一个 TC23XL 的旧工程时最先卡住的往往不是配置项而是那份由 SystemDesk 生成的 arxml 到底该落在哪个目录。EB Tresos 的工程是三层结构bin 放启动器workspace 放工程工程里再套一层 system 放系统描述文件这三处只要有一处对不上导入器照样安安静静跑完然后什么都没改。见过最典型的翻车现场是arxml 被替换到了工程根目录而不是 system 子目录SysDes importer 弹出 Importer Run Finished 且一条错误都没有结果回头一看 ECU Extract 里还是旧信号人当场懵住。这类问题如果不把步骤写死事后几乎没法反查。下面按一次完整导入走一遍环境怎么对齐、文件怎么替换、导入器按什么顺序排、最后怎么验证是真的生效了。2. 环境对齐TC23XL 工程里 bin、workspace、system 三层目录各放什么装工具这件事EB Tresos 本身反而最简单难的是把工程目录和文件的关系理清楚。这一章先把「装什么、放在哪、怎么确认就位」讲完后面几章才好动手。EB Tresos 是 AUTOSAR 的 ECU 配置工具SystemDesk 负责系统级描述两者之间唯一的交付物就是 arxml 文件。所以环境对齐的核心不是软件版本号而是文件位置和引用路径。不同大版本的 Project Explorer 视图名、导入器在右键菜单里的位置会有出入认功能不认位置别照着别人的截图死找。2.1 开工前先数清楚手里的文件我一般会先在纸上列一份清单缺哪一样当场就能看出来不至于做到第九步才发现没有 DBC。对象作用就位标志bin 目录下的 tresos_gui.exeEB Tresos 图形界面启动器双击能正常拉起主窗口workspace 根目录存放一个或多个 EB 工程目录下能看到待修改工程的文件夹***_Project 工程目录本次要改的目标工程目录内有 system 子目录与工程元数据SystemDesk 新生成的 ***.arxml本次要导入的系统描述文件名与原工程内文件同名或准备好改名原 system 目录下的旧 arxml回滚基线替换前已备份带时间戳工程对应的 DBC 文件通信矩阵供 DBC Importer 使用能在工程配置里找到引用位置表格里最后一行容易被忽略。如果没有 DBC第十步的 DBC Importer 要么跳过要么报找不到输入文件两种情况都会让人误以为是前面 SysDes 导入失败的连带反应。先确认清楚能省掉一轮排查。还有一点SystemDesk 导出的 arxml 有时不是一个文件而是主文件加若干分包引用。只替换主文件、把旧分包留在原地是最隐蔽的一种错误——文件时间戳变了导入器也不报错但系统描述里混着新旧两套定义。遇到工程规模较大的情况我宁可把 system 目录下所有 arxml 一起列出来比对时间戳也不要凭印象只换一个。2.2 启动器与工作区从 bin 目录起别用桌面快捷方式双击 bin 文件夹下的 tresos_gui.exe而不是开始菜单或桌面快捷方式。原因很实际一台机器上装了两三个版本做对比是常事快捷方式指向的往往是最后安装的那一个而工程是用旧版本建的一打开就提示工程版本不匹配接下来就是一轮没有必要的折腾。从 bin 目录直接起启动的是哪个版本一目了然。启动后会出现工作区选择。这里建议显式指定 workspace 路径不要用默认工作区因为默认工作区常常在用户目录下和工程实际所在的盘符不是一回事。Eclipse 系的启动器普遍认-data参数命令行拉起更可控# 从安装目录的 bin 下启动显式指定工作区根目录 C:\Tools\EB_Tresos\bin\tresos_gui.exe -data D:\workspace-data后面跟的是工作区根目录不是某个具体工程目录指向工程本身会打不开。路径里尽量不带空格和中文这不是玄学——代码生成阶段有些构建脚本会把路径原样拼进 makefile没加引号的地方一遇到空格就断最后报出来的错误跟路径八竿子打不着能查半天。提示快捷方式的工作目录起始位置如果不是 bin 目录个别版本的相对资源会加载失败。用命令行启动时先cd到 bin 再执行或者确认快捷方式的起始位置已经指向 bin。工程导入走 File 里的导入现有工程入口选到 workspace 下那个 ***_Project 目录勾选后完成。导入完成后 Project Explorer 里应该能看到工程节点和它下面的 ECU 节点节点名形如 ECU(TRICORE,TC23XL)——前半段是 ECU 名称后半段是架构与芯片系列TC23XL 对应 TriCore 架构的 TC23x 系列。这个节点名是从工程配置里读出来的如果显示的不是你预期的芯片说明工程目录选错了先退回去核对别往下走。2.3 覆盖之前先做一次可回滚的备份替换文件之前必须先留后悔药。这不是流程洁癖是血泪经验arxml 一覆盖原来的系统描述就没了而 EB Tresos 不会替你保存历史版本。压缩整个工程目录顺便把 arxml 的哈希单独存一份后面验证阶段能直接对比。# 工程整体打包文件名带时间戳避免多次备份互相覆盖 $stamp Get-Date -Format yyyyMMdd_HHmmss $proj D:\workspace\xxx_Project Compress-Archive -Path $proj -DestinationPath D:\backup\xxx_Project_$stamp.zip -Force # 单独记录 system 目录下 arxml 的哈希作为替换前的基线 Get-FileHash $proj\system\*.arxml -Algorithm SHA256 | Out-File D:\backup\arxml_hash_$stamp.txt-Force的作用是允许覆盖同名压缩包配合时间戳后缀基本不会撞名Get-FileHash用 SHA256 而不是默认算法是为了和团队里其他人给的校验值对得上。哈希文件不是形式主义替换之后跑一次同样的命令两边一比就知道到底换没换成功比盯着修改时间靠谱——复制工具保留原时间戳的情况并不少见。注意备份必须在 EB Tresos 完全关闭的状态下做。工程开着的时候编辑器持有内存副本退出时可能把内存状态回写磁盘正好盖掉你刚备份出来的内容等于白备。做完这三步环境部分就算落地了启动器从 bin 起工作区显式指定工程导入后节点名对得上备份和基线哈希都在手边。接下来才是真正动文件的部分。3. 替换与导入把 SystemDesk 的 arxml 喂给 SysDes 导入器这一章是整条链路里最容易出错的一段因为它包含两个独立的动作文件层面的覆盖替换和工具层面的导入执行。很多人只做了第一个就以为完事或者把导入器里的「编辑输入选择」当成「执行导入」。下面按实际操作顺序拆开写。3.1 打开 ECU(TRICORE,TC23XL) 并确认当前配置基线工程导入完成后在 Project Explorer 里双击 ECU(TRICORE,TC23XL) 节点进入 ECU 配置界面。这一步的作用不是改什么而是建立一个「改之前长什么样」的印象大致有哪些 SWC、有哪些服务组件、通信栈里挂了几个 PDU。等导入跑完再回来看变化是不是符合预期心里有底。如果双击之后配置树是灰的或者加载报错先别急着怀疑 arxml。常见原因是工程是从别人机器上整包拷过来的里面残留了绝对路径。处理办法是关掉工程重新导入一次让工具重新解析工程元数据。这一步不做后面所有导入器都会以失败告终而且报的错五花八门很容易带偏方向。进入配置界面后顺手看一眼 Error Log 面板。如果打开工程时就已经有一堆历史错误堆在那儿后面导入产生的错误会被淹在里面。可以先清空日志视图让接下来的操作有一个干净的观察窗口。3.2 用同名文件替换 system 目录下的 arxml原始流程里的表述是在工程路径workspace\***_Project\system下找到同名的 ***.arxml用 SystemDesk 新生成的文件替换它。关键词是「同名」——导入器的输入选择里写的往往是固定文件名或者System\*.arxml这样的通配你换了个名字导入器读的还是旧文件于是出现「导入成功但内容没变」这种最费解的现场。替换用复制覆盖不要用重命名原文件再拷入的方式中间态容易出岔子# 源文件来自 SystemDesk 的导出目录目标必须是工程内的 system 子目录 $src D:\from_systemdesk\xxx.arxml $dst D:\workspace\xxx_Project\system Copy-Item -Path $src -Destination $dst -Force # 替换后立刻确认目录里只有预期的那一份并核对时间戳 Get-ChildItem $dst -Filter *.arxml | Select-Object Name, Length, LastWriteTime-Force允许覆盖已存在的同名文件第二条命令列出的结果要重点看两件事文件名是不是和工程引用的完全一致修改时间是不是刚才这一分钟。如果 SystemDesk 那边分包导出目录里会多出若干 arxml这时要确认旧的那批分包已经被清掉否则新旧定义会同时被导入器扫到报出来的错误往往指向某个重复定义的端口跟真实原因隔着好几层。注意替换动作要在 EB Tresos 关闭或者至少工程未打开的状态下完成。工程开着时工具缓存里还是旧文件内容你替换完再点导入读到的可能是缓存白忙一场。替换完成后重新打开工程、进入 ECU 配置界面再往下走。3.3 Edit 与 Run ImporterSysDes 的两个动作别做反回到配置界面在 Project Explorer 窗口里对着根文件夹点右键下拉菜单里找 Im- and Exporters弹出标题为 Creat, manage and run im- and exporters 的对话框。这个对话框的结构是左侧或上方是导入器列表右侧是选中导入器的参数区和执行按钮。在右侧列表里选 SysDes(System Description Importer)然后左击 All Models 表单依次点System\*.arxml这一行和 Edit 按钮弹出 Edit input file selection 对话框。这个对话框会自动检测当前描述文件确认无误后点 OK——注意这里的 OK 只是关掉输入选择窗口导入并没有发生。这是全流程里最容易误解的一处Edit 定义「读哪些文件」Run Importer 才真正「读进去」。输入选择的写法有两种取向绝对路径和相对路径。绝对路径在换机器、换盘符、换工作区之后必然失效而工程在团队之间来回拷是常态。常见做法是保持相对工程根目录的写法形如System\*.arxmlSystem是工程内的系统描述目录反斜杠是 Windows 路径分隔符*.arxml匹配该目录下所有 arxml。工具支持在路径里使用变量和文件名通配具体可用的变量名以自己工程里能列出来的为准别照抄别人的。用通配的好处是分包文件不会漏坏处是旧文件如果没清干净也会被一起读进来所以 3.2 那一步的清理必须做扎实。确认输入后点 Run Importer开始更新描述文件。跑完会弹出 Importer Run Finished 对话框里面有错误信息列表。没有错误就点 OK 关闭。有错误的话不要直接关窗口先把内容复制出来逐条看第一条——导入器的错误列表往往是连锁的第一条错了后面几十条都是它的衍生品从最后一条开始看只会越看越乱。这一步跑完系统描述层面的更新才算完成。但它只是把 SystemDesk 的 arxml 读进了 EB 的模型通信矩阵和服务组件描述还没跟上所以紧接着要做 DBC 导入和两个 wizard。4. DBC 导入与两个 wizard把描述推到代码生成之前从 SysDes 导入完成到能点小锤子生成代码中间还隔着三步DBC 导入、ECU Extract 创建、服务组件与 BSWM 描述更新。这三步的顺序不是随便排的每一步的输入都是上一步的产出。顺序错了工具不会拦你但结果一定是错的。4.1 dbc (DBC Importer) 紧跟 SysDes 的原因SysDes 导入更新的是系统描述包含软件组件、端口、接口这些通信矩阵那一层也就是报文、信号、PDU 的定义走的是 DBC 这条路。两者在模型里是交叉引用的系统描述里声明的信号最终要落到某条报文上而报文来自 DBC。所以 SysDes 跑完必须马上跑 DBC让通信侧的数据跟系统侧对齐。操作还在刚才那个对话框里不用关。右侧列表选 dbc (DBC Importer)点 Run Importer 开始更新。跑完弹出标题为 Warnings During Importer Run 的对话框——注意它叫 Warnings 不叫 Errors这个命名差异是有含义的DBC 里节点名对不上、某些信号在 DBC 中缺失、报文周期定义冲突这类问题通常以降级警告的形式出现导入会继续但结果是残缺的。我的处理原则是警告一条都不放过。逐条读重点看「节点名不匹配」这一类因为它意味着 DBC 里的 ECU 名和工程里的 ECU 名不一致后续生成代码时通信栈初始化会缺东西而且这种缺失在编译阶段不报错只在运行或者集成测试时才暴露。确认没有需要处理的内容后点 OK关闭这个对话框最后关掉整个 Creat, manage and run im- and exporters 窗口。4.2 create an ECU Extract(EcuExtractCreator) 的产出边界关掉导入器窗口后回到主界面工具栏找到 Run all unattended wizards marked with a * 这个下拉里面选 create an ECU Extract(EcuExtractCreator)。它的作用是从完整的系统描述里把属于当前这个 ECU 的那部分提取出来形成 ECU Extract。为什么要提取因为 SystemDesk 那边的系统描述是整车或者整个域级别的包含所有 ECU 的组件而当前工程只负责其中一个 ECU代码生成只需要自己这一份。EcuExtractCreator 就是这把筛子。跑完弹出 Results 对话框说明 arxml 文件更新完成。这里要留意 Results 对话框的内容它不只是「完成」两个字。里面会列出本次提取涉及的组件和变更条目扫一眼数量级是否合理如果只提取出个位数的组件而你的 ECU 明明挂了几十个 SWC那基本可以判定上一步的 SysDes 导入没吃进全部内容回头查 3.2 的文件替换。4.3 Update Service Component and BSWM Descriptions(SwdUpdater_Trigger)紧接着同一个下拉里选 Update Service Component and BSWM Descriptions(SwdUpdater_Trigger)。这一步负责更新服务组件Service Component和 BSWM基础软件模式管理的描述。前面几步动的是系统层和通信层这一层动的是 ECU 内部的模式管理与服务接口描述。跑完会依次弹出 Code Generater Run Finished 和 Results 两个对话框点 OK 依次关闭。这时候如果过程中有问题会显示在 Error Log 里。也就是说前面几步的错误是弹窗形式的这一步的错误是落在日志里的不看日志就等于没做验证。顺序上再强调一次SysDes → DBC → EcuExtractCreator → SwdUpdater_Trigger。我见过有人图省事先跑 SwdUpdater 再回头补 SysDes结果服务端口全报未定义日志几百行最后还是得从头按顺序重跑一遍。工具不校验顺序但模型之间的引用关系会替你校验。全部跑完之后点工具栏上的小锤子按钮 Generate code for the currently selected projects编译工程、更新工程文件。这一步耗时最长也是最容易在最后关头翻车的地方——前面所有配置问题都会在这里集中爆发报错形式还特别分散有的是生成器脚本报路径错误有的是模板渲染找不到某个配置项还有的干脆什么都没输出。所以下一章专门写排查。5. 排查五类在 EB Tresos 导入 arxml 时反复出现的坑下面五条基本覆盖了我在 TC23XL 工程上遇到的大部分情况。每条按现象、原因、解决三段写能对号入座就直接照着处理。第一条导入器全程无报错ECU Extract 里还是旧信号。现象是 Importer Run Finished 弹窗干净Results 也正常但打开配置看信号列表新增的信号一个都没有。原因是 arxml 替换到了错误的位置——最常见的是放到了工程根目录或者机器上存在两个同名工程目录改的是 A 目录、打开的是 B 目录。解决方式是回到 system 目录用哈希核对确认文件确实是新的再全盘搜一次同名 arxml看是否存在多份。这条我吃过两次第二次之后养成了替换完立刻Get-FileHash比对的习惯。第二条Edit 对话框里 All Models 表单是空的或者报找不到文件。现象是点开 Edit 之后输入选择列表里没有可选项路径显示为红色或空白。原因是输入选择写的是绝对路径工程被拷到别的机器、别的盘符之后路径失效也可能是通配符写成了正斜杠在 Windows 下没被识别。解决办法是改回相对工程根目录的写法System\*.arxml重新点 Edit 让它自动检测一遍。团队协作的工程绝对路径基本等于定时炸弹。第三条DBC Importer 弹出一堆警告通信栈相关配置出现空缺。现象是 Warnings During Importer Run 里列了十几条内容集中在节点名和信号名。原因是 DBC 文件里的 ECU 节点名与工程里的 ECU 名不一致或者本次系统描述新增的信号在 DBC 里还没有定义。解决分两步先对齐 ECU 名这个改起来快再逐条看缺失信号确认是 DBC 版本落后还是本来就不该由这个 ECU 接收。别为了清警告随手把信号删掉那是把问题推到集成阶段。第四条SwdUpdater 跑完Error Log 里大量端口未定义的报错。现象是日志里成片的 service port 找不到、接口未声明。原因八成是顺序做反了——先跑了 SwdUpdater后跑或者压根没跑 SysDes 导入导致服务组件引用的接口在模型里还不存在。解决方式是严格按 SysDes → DBC → EcuExtractCreator → SwdUpdater_Trigger 重跑一遍不要试图单步补。重跑前把工程关掉再打开清掉内存里的中间状态。第五条点小锤子生成代码失败或者只生成了一半。现象是生成过程跑到中途停住报错内容与配置毫无关系比如找不到某个中间文件、路径解析失败。原因通常是上一次生成留下的中间产物没清干净或者工程路径里带了空格和中文导致构建脚本拼接出错。解决办法是先清一次生成产物再重新生成同时把工程挪到纯英文无空格路径下。另外看 Error Log 要从第一条看起生成器报的错经常是级联的最后一条往往只是「因此失败」。提示每一条排查做完都建议把当时的 Error Log 导出留档。同一个工程的导入问题往往会在换版本、换人接手时重复出现有一份历史日志下次能省掉大半时间。6. 验证跑通用 Error Log、Results 和生成产物三处对账导入流程走到小锤子那一步很多人看到没弹错误窗口就认为结束了。这是最危险的心态因为 EB Tresos 的失败模式里静默失败占的比例相当高文件没换、导入器读了旧路径、wizard 跳过没跑全都可以一路无错地走到最后。真正可靠的验证是把三个地方的输出对起来看。第一处是 Error Log 面板。不是扫一眼有没有红叉而是从头读前二十条。级联错误的第一条才是根因后面的都是衍生品。如果第一条是路径类错误基本可以判定是工程位置或者输入选择的问题直接回第 5 章第二条处理。第二处是每一步的 Results 对话框内容。EcuExtractCreator 和 SwdUpdater_Trigger 跑完都会给 Results里面列出本次处理的组件与变更条目。数量级要和工程规模对得上TC23XL 这种规模的 ECU提取出的组件数通常在几十这个量级如果只有个位数说明 SysDes 那一步没吃进全部内容。第三处是生成产物本身这也是最硬的证据。配置改没改进去最终要落到生成的 C 文件上。用信号名或者端口名去生成目录里搜一遍# 在生成目录里递归搜索新增的信号名确认配置真的落到了代码 Get-ChildItem -Path D:\workspace\xxx_Project\src -Recurse -Include *.c,*.h | Select-String -Pattern NewSignalName | Select-Object Path, LineNumber, Line-Recurse保证子目录也扫到-Include限定只搜 C 源文件和头文件避免把工程元数据也匹配进来。有输出说明信号进了代码没输出说明前面某一步的配置根本没落到生成链路。这条命令比翻日志直观得多尤其是接手别人的工程、不确定上一次有没有改干净的时候。三处对完之后再做一次反向验证把要验证的信号在配置里改个名字重新跑一遍完整的导入和生成链路看代码里的名字有没有跟着变。链路是通的名字会变链路某处断了名字纹丝不动这时候再回第 5 章按现象对号入座比盲目重装工具有效得多。从那以后我每次做 arxml 导入不管工程多小、时间多赶都强制走一遍「备份哈希 → 替换核对 → 顺序执行 → 生成产物搜一遍」这条线一步都不省。吃过静默失败的亏就知道工具不报错不等于事情做对了。这套流程整理成了一份按步骤走的记录需要照着做的可以拿去对照着操作。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
