3. Vector配置工具链核心操作

DaVinci Configurator（下称 DaVinci CFG）是 Vector 工具链中承担 AUTOSAR ECU 配置的核心工具。它并不直接生成可刷写的二进制，而是把工程师在图形界面中的选择，固化成一组可版本管理的配置描述文件（.dpa、.arxml 等），再由 DaVinci Developer 与生成器产出 RTE、BSW 代码。因此，本节的目标不是“点完按钮”，而是建立一条可重复、可校验、可导出、可回滚的配置基线。

一、工程创建：先定“骨架”，再谈参数

新建工程时，DaVinci CFG 会要求选择 ECU 工程模板与 AUTOSAR 版本。这一步决定了后续可用的模块集合与元模型版本，一旦选错，后期改版本会引发大量参数迁移。典型操作路径是：File → New → Project，在向导中指定工程名、存储路径、目标 AUTOSAR 版本（如 4.2.2 或 4.4.0）以及芯片/ECU 描述文件（.epc 或 .ecu）。

工程创建后，工具会生成一个默认的容器结构：顶层是 ECU 实例，其下挂载 BSW 模块、SWC 描述与系统描述。此时应立刻做两件事：一是确认 EcucDefs 路径指向的模块定义文件版本与项目要求一致；二是把工程目录纳入 Git，并在 .gitignore 中排除生成物目录（如 generated/、build/），只保留配置源文件。这样后续每次参数编辑都能形成可对比的 diff。

二、模块导入：按依赖顺序，而非按菜单顺序

模块导入的本质是把 ECU 需要的 BSW 模块实例加入工程。DaVinci CFG 支持从模块库中勾选导入，也支持导入已有的 .arxml 配置片段。关键原则是按依赖顺序导入：底层驱动（如 Mcu、Port、Dio）先于服务层（如 Com、PduR、CanIf），服务层先于应用层（如 Rte、Swc）。若顺序颠倒，工具会因找不到被引用容器而报错。

导入时建议一次只导入一个功能簇，导入后立即执行一次 Validate，确认无“未解析引用”再继续。对于从旧工程迁移的场景，优先使用 Import → ARXML 并勾选“Merge”而非“Replace”，避免覆盖已有参数。导入完成后，在工程树中应能看到模块实例及其 ECUC 容器层级，例如 CanIf → CanIfConfig → CanIfInitCfg。

三、参数编辑：定位容器，理解引用

参数编辑是工作量最大的一环。DaVinci CFG 的参数以 ECUC 容器树呈现，每个参数都有明确的类型：数值型（如 CanIfRxPduId）、枚举型（如 CanIfRxPduCanIdType）、布尔型（如 CanIfRxPduReadNotifyStatus）以及引用型（如 CanIfRxPduRef 指向某个 PDU）。

编辑时最容易出错的是引用型参数。例如在配置 CanIf 接收 PDU 时，CanIfRxPduRef 必须指向 CanIf 模块内已定义的 PDU 容器；若指向了 Com 模块的 PDU，校验会报“引用类型不匹配”。因此建议的编辑顺序是：先建容器，再填引用，最后设数值。对于枚举型参数，不要凭记忆选择，应查看工具右侧的说明面板，确认每个枚举值的语义。

另一个实践要点是参数变更的可追溯性。DaVinci CFG 支持在参数上添加注释（Comment），建议每次修改都写清“为什么改”：例如把 CanIfRxPduCanId 从 0x123 改为 0x1A3，注释写“对齐整车 CAN 矩阵 V2.1 第 14 页”。这样在后续 diff 审查时，评审人不需要猜测变更意图。

四、校验：把错误挡在导出之前

DaVinci CFG 的校验分为两个层次：语法/引用校验和一致性规则校验。前者检查参数值是否在合法范围、引用是否可解析；后者检查跨模块约束，例如 CanIf 的波特率是否与 Can 控制器配置一致、Com 的信号长度是否与 PDU 长度匹配。

执行校验的入口通常是 Project → Validate 或工具栏的 Validate 按钮。校验结果按 Error / Warning / Info 分级。实践原则是：Error 必须清零才能导出；Warning 需要逐条评估，确认是“已知可接受”还是“潜在缺陷”；Info 仅作参考。对于 Warning，建议在配置报告中记录处理结论，而不是简单忽略。

五、导出：产出可交付、可复现的配置包

导出阶段的目标是生成两类产物：一是供下游工具使用的 .arxml 配置描述；二是供团队审查的配置报告。DaVinci CFG 支持 File → Export → ARXML，导出时可选择是否包含未使用的模块、是否展开默认值。建议勾选“导出完整配置”，以便下游工具获得完整上下文。

导出完成后，应立即做三件事：第一，把导出的 .arxml 与工程源文件一起提交到 Git，并打上基线标签（如 baseline-v1.0.0）；第二，生成配置报告（参数清单 + 校验结果），归档到制品库；第三，记录本次导出的工具版本、AUTOSAR 版本和导出时间，写入 reports/export-manifest.txt。这样，任何一次配置变更都能追溯到具体的输入、工具版本和输出。

六、可重复配置基线的检查清单

为了让“可重复”不只是一句口号，建议在每次基线冻结前对照以下清单逐项确认。清单中的字段和判定条件均来自上述操作环节，可直接用于团队评审。

把上述五段操作串起来，DaVinci CFG 的配置工作就不再是“一次性手工劳动”，而是一条可重复执行的流水线：工程创建确定骨架，模块导入确定范围，参数编辑确定行为，校验确定质量，导出确定交付物。每一次基线冻结，都是这条流水线的一次完整运行；而 Git 中的配置源文件与制品库中的导出包，共同构成了可回滚、可对比、可审计的配置基线。