★ FEATURED ARTICLE 简介这份PDF文档面向汽车电子软件工程师、AUTOSAR ECU配置初学者以及需要完成EB Tresos与SystemDesk工具链联调的技术人员聚焦SystemDesk生成的.arxml系统描述文件导入EB Tresos工程这一常见环节帮助读者理解配置迁移与更新过程中容易出错的节点。文档为单个PDF文件压缩包约674KB体量轻巧便于在开发机或离线环境中随时查阅。目前已有3545人学习反映出该操作在AUTOSAR工程实践中的普遍需求。文档以工程实操为主线围绕工程准备、ECU配置定位、arxml文件替换、SysDes与DBC导入器调用、ECU Extract创建、服务组件及BSWM描述更新、代码生成与错误日志核查等模块展开并对关键步骤的成功提示与常见报错位置作出说明。读者可据此建立从系统描述到ECU配置的完整操作路径降低工具链衔接中的试错成本也便于团队沉淀统一的配置导入规范。1. 换完 arxml 那一刻Project Explorer 里红了一片某开发者在 TC23XL 的 AUTOSAR 工程上改动了一个系统描述用 SystemDesk 重新导出了 arxml顺手把workspace\***_Project\system下的同名文件覆盖掉再打开 EB TresosProject Explorer 里那棵ECU(TRICORE,TC23XL)树红了一片Error Log 里全是找不到引用的短名。文件确实换对了工具也确实能打开但两边模型对不上。EB Tresos 加 SystemDesk 这套组合在汽车电子项目里太常见了系统描述在 SystemDesk 里做ECU 配置和代码生成在 EB Tresos 里做中间靠一个 arxml 传递。装不好不会立刻报错通常是导入器跑完显示 OK直到点下小锤子生成代码才翻车。这篇写给正在被这套流程卡住的人从环境、路径、导入器参数一路写到坏了怎么救。2. 环境准备EB Tresos 与 SystemDesk 的路径约定和版本对齐2.1 先看 arxml 的 schema 版本再决定装哪条工具链装工具之前先别急着双击安装包把 SystemDesk 最新导出的那个 arxml 用文本编辑器打开看文件头。arxml 的根节点是AUTOSARxmlns属性里的命名空间就是 schema 版本AUTOSAR 4.x 是http://autosar.org/schema/r4.03.x 是http://autosar.org/schema/r3.x。这个版本号决定了两件事SystemDesk 导出时选的目标 schema以及 EB Tresos 里 SysDes 导入器能不能吃下这个文件。3.x 和 4.x 的包结构、引用方式差别不小跨版本导入经常表现为「导入器跑完了、没报错、但模型树是空的」。?xml version1.0 encodingUTF-8? !-- SystemDesk 导出的系统描述xmlns 决定 schema 版本必须和 Tresos 工程一致 -- AUTOSAR xmlnshttp://autosar.org/schema/r4.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://autosar.org/schema/r4.0 AUTOSAR_4-2-2.xsd AR-PACKAGES AR-PACKAGE !-- 这个短名就是 Tresos 里 ECU 配置引用的入口改名等于断链 -- SHORT-NAMEVehicleSystem/SHORT-NAME ELEMENTS SYSTEM SHORT-NAMEVehicleSystem/SHORT-NAME /SYSTEM /ELEMENTS /AR-PACKAGE /AR-PACKAGES /AUTOSAR这段里真正要盯的是xmlns和第一个SHORT-NAME。前者要对上工程里已有的 arxml后者要对上 EB Tresos 工程里ECU(TRICORE,TC23XL)节点下挂的系统描述短名。我一般的做法是把旧文件和新文件并排打开只对比前三行和后缀schemaLocation不一致就先回 SystemDesk 重新导出别硬导。参数上还有一个容易忽略的点SystemDesk 导出时有「导出全部」和「仅导出变更」两个选项做这种整体替换要走全量导出增量导出出来的文件缺包导入器照样能跑完只是模型树少一半。版本对齐还包括工具本身。EB Tresos 的安装包分 32 位和 64 位跟着操作系统走SystemDesk 那边如果是同一台机器上装注意两者的工作目录不要互相嵌套。安装路径这一条是血泪经验路径里不要有空格、中文、括号C:\Program Files\EB\...这种默认路径在导入器展开通配符时容易出问题我一般统一装到D:\tools\eb_tresos和D:\tools\systemdesk这种短路径下后面写相对路径、写批处理脚本都省事。2.2 目录与工作区bin、workspace、system 三处路径别写错EB Tresos 的工程目录结构是固定的tresos_gui.exe在工程的bin目录下工程本体在workspace下系统描述文件在workspace\工程名\system下。这三处路径在整条导入链里各出现一次写错任何一处报错信息都不会直接告诉你是哪一处错了只会说找不到文件或者模型为空。先把结构摆出来路径内容写错的典型后果工程\bin\tresos_gui.exe启动程序双击了同目录下的其他 exe界面能开但工程加载不全workspace\工程名\工程根导入器在工作区里找不到system目录通配符展开为空workspace\工程名\system\arxml 与 dbc替换了同名但不在这个目录的文件Tresos 读的还是旧的搭环境的时候我会先跑一段脚本把这个骨架和备份目录建出来顺便确认权限没问题#!/usr/bin/env bash set -euo pipefail PROJ/opt/workspace/ABC_Project # 工程根目录换成自己的工程名 STAMP$(date %Y%m%d_%H%M%S) # 时间戳用于回滚 # 1. 确认三处关键路径都存在缺一个后面的步骤全白做 test -x ${PROJ}/bin/tresos_gui.exe || echo 启动程序不在预期位置 test -d ${PROJ}/system || mkdir -p ${PROJ}/system # 2. 替换前把整个 system 目录打包留底arxml 和 dbc 一起备份 tar -czf ${PROJ}/backup_system_${STAMP}.tar.gz -C ${PROJ} system # 3. 列出当前 arxml 的修改时间替换后用它比对是否真的生效 ls -l --time-stylelong-iso ${PROJ}/system/*.arxmlset -euo pipefail是让脚本在任何一步失败时立刻退出避免带着半成品继续往下跑。tar -czf那条把整个system目录压成一个带时间戳的包回滚时只要tar -xzf解回去比手动改文件快得多。最后那条ls -l看着多余但它记录的是替换前的时间戳后面验证环节全靠这个时间点判断文件到底有没有被覆盖——AUTOSAR 工程里同名文件很多光看文件名判断不了新旧。目录约定还有一层是相对路径和变量的关系。SysDes 导入器的输入框支持变量和通配符System/*.arxml里的System是相对于工程根目录解析的不是相对于你当前所在的目录。所以工程根如果写错通配符能展开出一个空列表导入器仍然会告诉你 Finished。我习惯在替换文件前先在工程根下执行一次find . -name *.arxml -newer 旧文件确认新文件确实躺在system目录里。2.3 第一次启动tresos_gui.exe、工作区选择和许可启动这一步在原文里只是一句「双击 tresos_gui.exe」但第一次装的机器上双击之后的坑比安装本身还多。启动前要确认三件事工程 bin 目录下的可执行文件、工作区路径、以及工具要用到的运行时环境。EB Tresos 自带运行时但如果机器上同时装了多个版本的工具环境变量里指向错的那个版本界面能开、导入器也会列出来只是行为对不上文档。# 启动前自检路径、目录占用、权限 PROJ/opt/workspace/ABC_Project # 路径里不允许出现空格和中文这里做个兜底检查 case ${PROJ} in * *|*[! -~]*) echo 工程路径含空格或非 ASCII 字符建议迁移;; esac # 确认当前用户对 workspace 有写权限导入器要往 system 目录写回中间文件 test -w ${PROJ}/system echo system 目录可写 || echo 权限不足 # 记录一次启动时间后面看日志时用来区分是不是本次会话产生的 date %F %T 启动 tresos_gui ${PROJ}/launch.logcase那段是防御性的只匹配空格和非 ASCII 字符test -w检查写权限导入器运行时会生成中间文件只读目录会让它跑到一半失败。启动之后第一件事是选工作区弹窗里会让你指定 workspace 的位置这里选workspace这一层不要选到工程名里面去。选错了的表现是 Project Explorer 里空空如也或者只看到一堆散落的文件夹看不到ECU(TRICORE,TC23XL)这个节点。再往后是许可。第一次打开导入器列表的时候如果只看到一半的导入器或者SysDes(System Description Importer)灰着点不动基本就是许可没加载上。常见做法是先关掉工具确认许可文件放在安装目录约定的位置再重新启动一次别在界面里反复点重试。这一步处理完环境就算立住了可以进入真正的替换和导入环节。3. 把 arxml 换进去SysDes 导入器与 DBC 导入器的配置细节3.1 覆盖前先备份文件名、短名、时间戳三件事原文第四步说得很干脆在workspace\***_Project\system下找到同名的 arxml用 SystemDesk 新生成的文件替换它。操作本身是复制粘贴但能踩的坑全在「同名」这两个字上。同名包含两层含义文件名相同以及文件内部顶层SYSTEM的短名相同。文件名不同导入器按System/*.arxml展开时会同时看到新旧两个文件最后导入哪个取决于排序短名不同Tresos 里已经建立好的引用会全部指向旧短名替换完成之后模型树里会出现一堆找不到目标的红叉。替换之前我固定会用一段脚本对比新旧两个文件的结构确认这次替换是「同一个系统的升级」而不是「换了一个系统」import sys import xml.etree.ElementTree as ET # 命名空间必须和文件头的 xmlns 完全一致否则所有 find 都返回空 NS {http://autosar.org/schema/r4.0} def load(path): root ET.parse(path).getroot() # 把所有 SHORT-NAME 拉平用于比较包结构和顶层系统名 names [e.text for e in root.iter(NS SHORT-NAME)] return names new_names load(sys.argv[1]) # 参数1SystemDesk 新导出的 arxml old_names load(sys.argv[2]) # 参数2被替换的旧 arxml print(新版节点数:, len(new_names), 旧版节点数:, len(old_names)) # 第一个短名通常是顶层包名必须和旧文件一致否则引用会断 print(顶层短名一致:, new_names[0] old_names[0] if new_names and old_names else False) # 节点数大幅缩水说明导出时选了增量而非全量先回 SystemDesk 重导 print(节点数是否缩水:, len(new_names) len(old_names))两个参数分别是新文件和旧文件的路径运行方式python check_arxml.py new.arxml old.arxml。脚本只做三件事的判断不修改任何文件所以可以放心在替换前跑。第一行输出节点数正常情况下新版应该持平或略多如果明显变少就是 SystemDesk 导出时选了「仅导出变更」回去重导一次全量。第二行判断顶层短名不一致就别替换了先去确认是不是拿错了工程的文件。第三行是兜底提醒。替换动作本身建议用带时间戳的备份而不是直接覆盖PROJ/opt/workspace/ABC_Project NEW_ARXML/path/to/new/ABC.arxml # SystemDesk 导出的新文件 cd ${PROJ}/system # 旧文件改名留底而不是删掉出问题可以直接改回来 mv ABC.arxml ABC.arxml.old.$(date %Y%m%d_%H%M%S) cp ${NEW_ARXML} ./ABC.arxml # 确认替换后的文件大小和时间戳和源文件对齐 ls -l ABC.arxml stat -c %y ABC.arxmlmv而不是rm是为了留一条随时能退回的路。有些团队习惯把旧文件挪到system/backup子目录也可以但要记得导入器的通配符是System/*.arxml只匹配一层子目录里的文件不会被误读进去这点比放在同级目录更保险。3.2 SysDes 导入器的参数输入选择、通配符和变量文件放好之后回到 EB Tresos 界面。原文第五到第九步描述的是同一条链右键Project_Explorer里的根文件夹点Im- and Exporters弹出Creat, manage and run im- and exporters对话框右侧选SysDes(System Description Importer)在All Models表单里依次点System/*.arxml和Edit按钮弹出输入文件选择对话框确认后点OK最后点Run Importer。这条链里真正需要配置的只有输入路径这一个参数其余都是点下一步。但这个参数的写法有讲究输入写法解析方式适用场景System/*.arxml相对于工程根目录匹配一层目录下所有 arxml工程里只有一个系统描述文件时最省事System/ABC.arxml精确匹配单个文件目录里存在历史备份文件避免导入错版本${workspace_loc}/ABC_Project/System/*.arxml变量展开成绝对路径工程被移动过、相对路径解析异常时使用我一般会在第一次导入时用精确路径把文件名写死确认导入成功、模型树正确之后再改回通配符方便后续反复导入。因为System/*.arxml会把目录下所有 arxml 都喂给导入器只要有一个备份文件忘了挪走导入结果就不可预期。Edit input file selection对话框里会自动检测当前描述文件检测结果要看一眼它会列出匹配到的文件数量和解析出来的顶层系统名。文件数量对不上或者顶层系统名是空的点OK之前先退回去检查路径。点Run Importer之后弹出Importer Run Finished这个对话框里显示的「错误信息」有时候是空的有时候是一堆警告警告不等于失败但警告里如果出现 unresolved reference 字样基本可以确定短名对不上回到 3.1 去核对。导入完成后不要急着跑下一步先在 Project Explorer 里展开ECU(TRICORE,TC23XL)确认系统描述节点下的端口、接口、组件数量和 SystemDesk 里看到的一致。这一步是整条链里最容易跳过、也最容易在后面付出代价的地方。3.3 DBC Importer为什么替换完 arxml 还要再跑一次原文第十步是在同一个对话框里选dbc (DBC Importer)点Run Importer跑完弹Warnings During Importer Run没错误就点OK关掉。很多人会问arxml 都导完了为什么还要单独跑一次 DBC。原因是这两类文件描述的东西不一样。arxml 描述的是软件架构层面的系统、组件、接口DBC 描述的是总线上实际收发的报文和信号ECU 的通信配置要靠 DBC 把信号映射到端口上。SystemDesk 重新生成系统描述之后报文和信号的集合可能变了DBC 那边如果不同步更新代码生成阶段就会出现「接口有、信号没有」的不一致。这一步的配置项比 SysDes 少主要是 DBC 文件的路径。工程里通常把 DBC 放在system目录或者单独的dbc目录下路径写法同样支持变量。这里要注意的是 DBC 导入器不会自动去找最新的 DBC 文件它认的是你在输入框里指定的那个路径所以如果 SystemDesk 那边同时更新了 DBC记得先把新文件也复制进来再跑导入器。Warnings During Importer Run这个对话框值得逐条读。常见的警告有两类一类是 DBC 里定义了但 arxml 里没有对应接口的信号另一类是 arxml 里有接口但 DBC 没提供信号的端口。前者通常无害是总线上的预留信号后者要当回事它意味着后续生成的代码里这些端口是悬空的编译能过运行时行为不对。我处理这类警告的习惯是把对话框内容复制到一个文本文件里存进工程的log目录和后面代码生成的日志放一起出问题时按时间顺序排一下就能看出是导入阶段引入的还是生成阶段引入的。4. 向导链与代码生成EcuExtractCreator 到 SwdUpdater_Trigger4.1 两个 unattended wizard 的顺序不能颠倒原文第十一步和第十二步是工具栏上Run all unattended wizards marked with a *下面的两个向导先create an ECU Extract(EcuExtractCreator)弹Results说明 arxml 更新完成再Update Service Component and BSWM Descriptions(SwdUpdater_Trigger)弹Code Generater Run Finished和Results有错误会显示在 Error Log 里。这两个的顺序是硬性的不能反。EcuExtractCreator 做的是从系统描述里抽出属于当前 ECU 的那一部分也就是 ECU ExtractSwdUpdater_Trigger 做的是拿这份 Extract 去更新服务组件和 BSWM 的描述。Extract 还没生成就跑更新更新器读到的是上一轮的旧描述跑完照样提示 Finished但配置里用的还是旧接口。表现出来的现象是明明换了 arxml生成的代码里端口名还是旧的。执行 EcuExtractCreator 时界面会短暂卡住这是正常的它在解析整棵模型树。Results对话框里如果只有信息级别的输出点OK继续如果出现 error先别往下走把 Error Log 打开。日志里定位问题的方法是按时间倒序看最后几条AUTOSAR 的报错通常会把涉及的短名带出来拿着短名回到 arxml 里搜能很快定位是哪个包缺失或者哪个引用指向了不存在的元素。SwdUpdater_Trigger 跑完之后弹出的Code Generater Run Finished名字里有 Code Generator但它本身不生成代码只是更新描述。这个命名容易误导我第一次用的时候以为跑完就有代码了结果在输出目录里找了半天。真正的代码生成是下一步的小锤子按钮。4.2 Generate code小锤子按钮背后做了什么原文第十三步是点工具栏上的小锤子Generate code for the currently selected projects编译工程更新工程文件。这一步是整条链的收口前面所有导入、替换、向导更新的结果都在这里体现成实际的 C 代码和配置文件。点之前先确认当前选中的是哪个工程。Project Explorer 里如果同时打开了多个工程小锤子只对当前选中的那个生效选错了工程的表现是跑完没报错但目标工程的输出目录里文件时间戳没变。代码生成的输出一般在工程的generate或src目录下具体位置由工程配置里的生成路径决定。判断这次生成有没有真正生效不要只看界面提示去看文件时间戳和文件数量。我一般用一条命令扫一遍PROJ/opt/workspace/ABC_Project # 找出最近 10 分钟内被修改过的生成文件数量为 0 说明生成没落到这个目录 find ${PROJ} -type f \( -name *.c -o -name *.h \) \ -newermt -10 minutes | wc -l # 按模块统计生成文件和上一次生成的结果对比数量变化 find ${PROJ}/generate -type f -name *.c | sed s|.*/|| | cut -d_ -f1 | sort | uniq -c第一条命令用-newermt按时间过滤-10 minutes是相对时间写法也可以写具体时间点。输出为 0 说明生成的文件没有落到这个目录可能是工程配置里的输出路径指向了别处也可能是生成过程在编译阶段就中断了。第二条命令按文件名前缀统计模块数量和上一轮的结果比如果某个模块的文件数突然变成 0说明那个模块的配置在导入过程中丢了。编译失败的情况在小锤子这一步最常见。Error Log 里如果有链接错误多半不是代码本身的问题而是前面 Extract 或 BSWM 描述没更新到位导致生成的函数声明和调用对不上。遇到这种情况不要改代码回到第 4.1 节重新跑一遍两个向导再点小锤子。4.3 Error Log 的位置和读法原文提到「如果有错误会显示在 Error Log 中」但没说日志在哪。EB Tresos 的 Error Log 视图在窗口下方如果被关掉了从菜单里重新打开。日志本身的物理文件通常在工程目录下的.metadata或者工作区的日志目录里找.log后缀的文件即可。读日志有个技巧按时间戳排序之后先看第一条 error不要看最后一条。AUTOSAR 工具链的报错经常是连锁的第一条 error 引发的后续几十条都是它的下游。我见过最典型的一次是 arxml 里少了一个包导入器没报向导跑到 SwdUpdater_Trigger 时报了四十多条 unresolved全是同一个缺失包的下游。把第一条 error 里提到的短名拿去 arxml 里搜一搜就找到了根因。5. 避坑与排查arxml 导入后报错、配置丢失、代码不更新5.1 导入阶段的三种翻车第一种Importer Run Finished显示成功但模型树是空的。现象是导入器跑完没报错Project Explorer 里ECU(TRICORE,TC23XL)下面什么都没有或者只有一层空包。原因是 schema 版本不匹配或者导入器实际匹配到的文件数量为 0。解决方式是回到Edit input file selection对话框看它列出的文件数量和顶层系统名数量为 0 就检查路径大小写和目录层级路径写成了system/*.arxml但实际目录名是System在大小写敏感的文件系统上就是匹配不到。第二种导入成功但大量 unresolved reference。现象是模型树里节点都在但一展开就有红叉Error Log 里全是找不到目标的短名。原因是替换的 arxml 顶层SYSTEM短名和旧的没对上或者 SystemDesk 导出时选了增量导出包结构不全。解决方式是先跑 3.1 里的对比脚本确认顶层短名再用全量导出重新替换一次。这一步不要试图在 Tresos 里手工补引用补不完。第三种DBC 导入器报大量警告后代码生成失败。现象是Warnings During Importer Run里列了一堆端口没有信号小锤子点下去编译报未定义符号。原因是 DBC 文件和 arxml 不是同一次导出的报文集合对不上。解决方式是把 SystemDesk 同批导出的 DBC 一起替换进来重跑 DBC Importer再走一遍向导链。5.2 代码生成阶段的两种翻车第四种小锤子跑完没报错但生成目录里的文件时间戳没变。现象是界面提示生成完成去generate目录一看还是昨天的文件。原因是当前选中的工程不是目标工程或者工程配置里的生成路径指向了另一个目录。解决方式是先确认 Project Explorer 里选中的是哪一个工程再去工程配置里核对生成输出路径用 4.2 里的find -newermt命令扫整个工程目录看文件到底生成到哪去了。第五种上一次生成正常这次生成后编译报重复定义。现象是链接阶段报某个函数或变量重复定义Error Log 里指向两个不同的.c文件。原因通常是旧版本的生成文件没有被清理新生成的文件和残留文件同时参与编译。解决方式是在生成之前先清理输出目录或者确认工程配置里勾选了「生成前清理」。这一步在换了 arxml 之后尤其容易出因为模块结构变了旧的模块文件没被覆盖留在了目录里。# 生成前清理输出目录的保守做法先移走确认生成成功再删除 GEN/opt/workspace/ABC_Project/generate if [ -d ${GEN} ]; then mv ${GEN} ${GEN}.old.$(date %Y%m%d_%H%M%S) fi这段脚本把整个生成目录挪走而不是rm -rf生成失败时还能把旧目录挪回来。$(date %Y%m%d_%H%M%S)保证每次备份名字唯一不会互相覆盖。执行完再点小锤子生成目录会被重新建出来里面的文件全部来自本次生成重复定义的问题自然消失。6. 装完怎么验证一次导入闭环的自检验证这件事我不看界面提示只看四个可以量化的东西从文件到代码一层层往下对。检查点验证方式通过标准arxml 是否替换成功ls -l --time-stylelong-iso system/*.arxml时间戳与源文件一致目录里没有多余的旧 arxml导入器是否读到文件Edit input file selection对话框匹配文件数为 1顶层系统名非空Extract 是否更新generate目录下 Extract 相关文件时间戳晚于 arxml 替换时间代码是否真正生成find -newermt统计结果目标模块的.c数量与上一次一致或按预期变化最后再加一条编译验证用命令行编译一次拿退出码判断比看界面上的红色标记可靠# 在工程根目录下执行编译退出码为 0 才算这一轮闭环走通 make -C /opt/workspace/ABC_Project all build.log 21 echo 编译退出码: $? # 有错误时只打印前 20 条避免日志刷屏 grep -i -m 20 error build.logmake -C指定工程目录 build.log 21把标准输出和标准错误一起重定向方便事后翻。$?是上一条命令的退出码0 表示成功。grep -m 20限制输出条数AUTOSAR 工程编译失败时错误信息很容易上百条看前 20 条足够定位第一个根因。这四步加一次编译构成一个完整的闭环。任何一步不对就退回对应的章节重做别跳步——这套流程里每一步的输出都是下一步的输入跳过去看起来省了时间实际上问题会在后面以完全不同的形式冒出来。从那以后我每次替换 arxml都强制先把system目录打包留底、跑一遍短名对比脚本再动导入器。这套动作多花不到两分钟但至少让我不用在半夜对着满屏的 unresolved 猜是哪个包丢了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
