2. 通信栈配置工具链入门
在 MICROSAR 车载通信栈的工程集成中，Vector DaVinci Configurator Pro（以下简称 DaVinci CFG）是承载 ECU 配置的核心工具。它并不直接“写代码”，而是把来自系统设计阶段的通信描述、来自 ECU 抽象描述的信息，以及工程师手工补充的配置参数，统一收敛为可生成 MICROSAR 代码的工程数据库。理解这一工具链的入口——工程创建、模块导入、ECU Extract 与系统描述文件的关联——是后续所有通信栈配置工作的前提。
一、工具链中的三类输入文件
在动手创建工程之前，必须先分清进入 DaVinci CFG 的三类文件，它们的来源、格式和作用完全不同：
- 系统描述文件（System Description，.arxml）：由系统架构师在 DaVinci Developer 或同类工具中完成，描述整车或子系统层面的通信矩阵，包括 CAN/CAN FD、LIN、FlexRay、Ethernet 的报文、信号、PDU、节点与集群关系。它回答的是“网络上有什么、谁发给谁”。
- ECU Extract（.arxml）：从系统描述中“抽取”出属于某一个具体 ECU 的部分，只保留该 ECU 需要收发的报文、信号、PDU 以及相关通信参数。它回答的是“这个 ECU 在网络上要做什么”。
- ECU 工程配置（.dpa / 工程目录）：DaVinci CFG 自身的工程文件，保存模块实例、参数取值、生成器设置等。它回答的是“这个 ECU 内部如何实现这些通信”。
三者的关系可以概括为：系统描述是全集，ECU Extract 是按 ECU 切分的子集，而 DaVinci CFG 工程则是在子集之上叠加 ECU 本地配置后的可生成实体。下图给出了这一关联关系与数据流向。
二、创建工程与导入模块
启动 DaVinci CFG 后，通过 File → New → Project 创建工程。向导中需要选择目标 ECU 的芯片系列与 MICROSAR 版本，这一步决定了后续可用的模块集合与生成器版本。工程创建完成后，进入 Project → Add Module 或直接在模块视图中添加所需模块。通信栈集成通常至少需要以下模块：
- Can：CAN 控制器驱动，负责报文收发与硬件寄存器操作。
- CanIf：CAN 接口层，向上屏蔽不同总线驱动的差异。
- Com：通信服务层，管理信号打包/解包、超时监控与更新位。
- PduR：PDU 路由器，决定 PDU 在 Com、CanIf、Dcm 等模块间的流向。
- EcuC：ECU 抽象层，提供 PDU 与容器的全局定义。
- Os：操作系统，承载通信任务与中断。
模块导入的顺序并非随意。由于 PduR 需要引用 Com 和 CanIf 中的 PDU 句柄，EcuC 需要先于 PduR 定义 PDU，因此推荐顺序为：EcuC → Can → CanIf → PduR → Com → Os。若顺序颠倒，配置界面中会出现大量“未解析引用”的红色提示，虽然不阻止保存，但会显著增加排查成本。
三、ECU Extract 的导入与关联
ECU Extract 的导入是本节最关键的操作。在 DaVinci CFG 中通过 Project → Import → ECU Extract 选择对应的 .arxml 文件。导入时工具会解析其中的通信对象，并尝试与工程中已存在的模块建立映射。此时需要重点关注三类关联：
- PDU 关联：ECU Extract 中的每个 PDU 需要映射到 EcuC 中的 PDU 定义，并指定其所属的 Com 信号或 CanIf 报文。
- 信号关联：信号需要绑定到 ComSignal，并设置字节序、起始位、长度等参数。这些参数通常由 Extract 带入，但字节序与初始值需人工确认。
- 帧关联：CAN 报文需要绑定到 CanIf 的 RxPdu/TxPdu，并指定 Can 控制器的硬件对象（HOH）。
导入完成后，建议在 Project → Verify 中执行一次一致性检查。工具会列出未关联的 PDU、未绑定的信号以及参数冲突项。一个常见的示例是：Extract 中某报文长度为 8 字节，但工程中 CanIf 的对应 PDU 被误设为 6 字节，Verify 会报长度不匹配。此时应回到 Extract 或工程中修正，而不是忽略警告。
四、系统描述文件的关联方法
系统描述文件与 ECU Extract 的关系需要特别说明：DaVinci CFG 工程通常不直接导入完整的系统描述，而是通过 ECU Extract 间接关联。但在以下两种场景中，需要显式关联系统描述：
- 多 ECU 协同配置：当同一工程需要参考其他 ECU 的通信行为时，可通过
Project → Add System Description挂载系统描述文件，用于交叉校验。 - 通信矩阵更新：当系统描述发生变更时，重新生成 ECU Extract 并重新导入，而不是手工修改工程中的 PDU 和信号。手工修改容易与系统描述脱节，导致后续集成失败。
System.arxml、ECU_Extract.arxml 和工程文件 Project.dpa，并在版本控制中记录三者的版本对应关系。每次系统描述更新后，先更新 Extract，再更新工程，避免版本错位。
五、一个可复用的工程初始化检查清单
为便于实际执行，下面给出一个可直接对照使用的初始化检查清单。字段和判断依据均围绕 DaVinci CFG 工程创建与文件关联这一任务，不引入无关管理项。
| 检查项 | 操作位置 | 通过标准 |
|---|---|---|
| 工程芯片与 MICROSAR 版本 | New Project 向导 | 与目标 ECU 实际芯片及 MICROSAR 版本一致 |
| 模块导入顺序 | Add Module | EcuC → Can → CanIf → PduR → Com → Os |
| ECU Extract 导入 | Import → ECU Extract | 无未解析引用，PDU/信号/帧均建立映射 |
| PDU 长度一致性 | EcuC / CanIf | 与 Extract 中定义的长度一致 |
| 信号字节序与起始位 | Com | 与通信矩阵一致，初始值已确认 |
| 一致性检查 | Project → Verify | 无错误项，警告项已逐条确认 |
| 文件版本对应 | 工程目录 | System.arxml、ECU_Extract.arxml、.dpa 版本匹配 |
完成上述步骤后，工程即具备进入下一阶段配置的条件。此时不必急于生成代码，而应先确认模块间的引用关系已经闭合：EcuC 中的 PDU 被 PduR 引用，PduR 的路由目标指向 Com 或 CanIf，CanIf 的报文绑定到 Can 控制器。只有这条链路完整，后续的 Com 信号配置与代码生成才有意义。