2. DaVinci项目工作空间与工程创建
在 Vector DaVinci 工具链中，工作空间（Workspace）是承载所有工程、配置与生成产物的顶层容器。理解它的目录结构，是后续新建 AUTOSAR 工程、导入系统描述文件、配置参数以及做版本管理的前提。DaVinci Configurator、DaVinci Developer、DaVinci CFG 等工具共享同一套工作空间概念，但各自在目录中写入的文件类型不同。本节围绕“工作空间怎么组织、工程怎么建、系统描述文件怎么进来、参数怎么配、版本怎么管”这条主线展开。
一、工作空间目录结构
一个典型的 DaVinci 工作空间根目录下，通常包含以下几类内容：工程目录（每个 AUTOSAR 工程一个子目录）、工具级配置、日志与临时文件、以及生成输出目录。工程目录内部又按“输入—配置—生成”三层组织：输入层放系统描述文件（.arxml）、ECU Extract、DBC/LDF 等；配置层放 DaVinci 工程文件（.dpa、.dcf 等）与参数集；生成层放生成的代码、模板输出与报告。下面这张结构图给出了一个可落地的工作空间布局，可作为团队统一约定的起点。
需要强调的是，generated/ 目录中的内容应当被视为“可重建产物”，不应纳入版本库；而 config/ 中的 DaVinci 工程文件与参数集才是团队协作的核心资产。把这条边界划清楚，后续的版本管理策略才有意义。
二、新建 AUTOSAR 工程
在 DaVinci Configurator 中新建工程，通常有两种入口：一是从零创建空白 AUTOSAR 工程，二是基于已有模板或示例工程派生。推荐做法是：先确定目标 AUTOSAR 版本（如 4.2.2 或 4.4.0）与 ECU 类型，再选择对应的工程模板。新建时需要填写的关键信息包括工程名称、存储路径、AUTOSAR 版本、目标编译器与芯片系列。工程名称建议采用“项目_ECU_版本”的命名方式，例如 BCM_ECU_A_4.4.0，便于在多个工程并存时快速识别。
新建完成后，DaVinci 会在工程目录下自动生成 .project、.cproject 以及初始的 .dpa 工程文件。此时工程是“空壳”，还没有任何 ECU 配置内容，下一步必须导入系统描述文件。
三、导入系统描述文件
系统描述文件（System Description，通常为 .arxml）由系统架构师在 DaVinci Developer 或第三方工具中导出，描述了 ECU 之间的通信、信号、服务接口与拓扑关系。导入时需要注意三点：
- 版本匹配：系统描述文件的 AUTOSAR 版本必须与工程版本一致，否则导入会报 schema 校验错误。
- 导入范围：只导入与本 ECU 相关的 ECU Extract，而不是整个系统描述，避免引入无关的 ECU 实例导致配置膨胀。
- 导入顺序：先导入系统描述，再导入通信矩阵（DBC/LDF），最后导入诊断描述（CDD/ODX），顺序颠倒会导致引用找不到。
导入完成后，DaVinci 会在工程中建立 ECU 实例、端口、信号与 SWC 的映射关系。此时应运行一次“一致性检查”（Consistency Check），确认没有未解析的引用或缺失的端口。若检查通过，说明输入层已经就绪，可以进入参数配置阶段。
四、工程参数配置
参数配置是 DaVinci 工程的核心工作。以通信栈为例，需要配置的参数包括：CAN 控制器波特率、CAN FD 数据段波特率、报文发送类型（周期/事件）、信号初始值与超时监控、以及 ComM 通道映射。下面给出一个 CAN 通道的示例参数表，用于说明配置的粒度与典型取值（示例值，非实测结果）：
| 参数 | 示例值 | 说明 |
|---|---|---|
| CanControllerBaudRate | 500 kbps | 经典 CAN 仲裁段波特率 |
| CanControllerFdBaudRate | 2 Mbps | CAN FD 数据段波特率 |
| CanControllerSamplePoint | 80% | 采样点位置 |
| CanIfTxPduBufferSize | 8 | 发送缓冲区数量 |
| ComTimeout | 100 ms | 信号接收超时监控 |
| ComMChannelMode | FULL_COMMUNICATION | 通道通信模式 |
配置完成后，应执行“生成”操作，DaVinci 会根据参数生成 Can_Cfg.c/h、Com_Cfg.c/h 等文件。生成后要检查生成报告中的警告与错误数量，并确认关键宏定义（如 CAN_BAUDRATE）与配置值一致。若生成报告出现“未配置必填参数”的提示，必须回到配置界面补齐，不能强行编译。
五、版本管理策略
DaVinci 工程的版本管理有其特殊性：.arxml 是文本格式，适合 diff；.dpa 与 .dcf 可能是二进制或 XML 混合格式，diff 可读性差。因此建议采用“分层管理”策略：
- 输入层：
.arxml、.dbc、.ldf纳入 Git，按版本打 tag，例如sysdesc_v1.2。 - 配置层：
.dpa、.dcf纳入 Git，但每次提交前导出一次 XML 格式的配置快照，便于 diff 审查。 - 生成层：
generated/不纳入 Git，通过 CI 在构建时重新生成，保证可复现。 - 工具版本：在仓库根目录放置
tool_version.txt，记录 DaVinci 版本号与补丁号，避免因工具版本不一致导致配置漂移。
_logs/ 中的 HTML 或 XML）归档到版本库的 reports/ 目录，作为配置变更的审计依据。这样当出现通信异常时，可以快速定位是哪一次参数变更引入的。最后需要提醒的是，工作空间与工程的创建不是一次性动作，而是贯穿项目生命周期的持续维护过程。随着 ECU 数量增加、AUTOSAR 版本升级、系统描述文件迭代，工作空间的结构与版本策略都需要相应调整。把目录约定、导入顺序、参数配置规范与版本管理策略固化为团队规范，才能让 DaVinci 工程在多人协作中保持稳定与可追溯。