3. 新建SWC工程与工作区配置

在DaVinci Developer中，一个“工程”并不是单个文件，而是一组由工作区（Workspace）统一管理的资源集合：工程文件（.dpa）、导入的ARXML描述文件、生成的代码输出目录、以及团队共享的配置约定。新建工程时如果模板选错、包结构混乱或命名随意，后续在集成阶段往往要付出数倍的返工代价。本节围绕工程模板选择、包结构规划、命名规范、ARXML导入与团队协作目录约定五个关键点展开，目标是让读者能够独立建立一个可被团队直接接续使用的SWC工程骨架。

一、工程模板选择：先明确工程用途

DaVinci Developer新建工程时提供若干模板，常见的有空白工程、基于AUTOSAR Schema的工程、以及从已有ARXML反向生成的工程。选择依据不是“哪个功能多”，而是这个工程未来要承担什么角色：

• 空白工程：适合从零开始设计SWC、手工定义端口与接口的场景，包结构完全由建模者规划，灵活但前期工作量大。
• 基于ARXML导入的工程：适合已有系统描述或OEM提供的通信矩阵，需要在此基础上补充应用层SWC，能直接复用已有的数据类型、端口接口和系统信号。
• 模板工程（Template Project）：团队通常会维护一个内部模板，预置好包结构、命名规则、代码生成配置和目录映射，新建时直接复制模板可保证一致性。

实际工程中推荐第三种做法：由架构负责人维护一份“团队基线模板”，其中已包含标准包层级、常用数据类型库引用、代码生成器路径和输出目录约定。新建工程时选择该模板，只需修改工程名和项目相关参数，即可避免每个成员各自搭建结构导致的差异。

二、包结构规划：让对象有稳定的归属

DaVinci Developer中的包（Package）对应AUTOSAR的AR-PACKAGE，是组织SWC、端口接口、数据类型、常量等元素的基本单位。包结构一旦确定，后续所有元素的引用路径都会依赖它，因此必须在建模开始前规划好。一个可落地的分层思路是按“项目—功能域—元素类型”三级组织：

Project_Root
├── Application
│   ├── SWC          // 应用层软件组件
│   ├── PortInterface // 端口接口定义
│   └── DataType      // 应用数据类型
├── Services
│   ├── SWC          // 服务层SWC
│   └── PortInterface
├── Communication
│   ├── Signal        // 系统信号
│   └── Frame         // 通信帧
└── Common
    ├── DataType      // 跨域共享类型
    └── Constant      // 标定常量

这样划分的好处是：当某个SWC需要引用数据类型时，引用路径稳定且可预测；当多个项目共用Common包时，可以通过ARXML导入而非复制来复用。需要注意的是，包名应避免使用中文、空格和特殊字符，推荐使用大驼峰或下划线分隔，并与团队代码生成器的命名转换规则保持一致。

三、命名规范：从工程名到元素名

命名规范的核心目标是“见名知义、全局唯一、可被工具链正确转换”。建议在工程建立阶段就确定以下规则：

• 工程名：采用“项目缩写_功能域_版本”格式，例如 BCM_LightCtrl_V1，避免使用日期作为版本，因为日期无法表达兼容性。
• SWC名：采用“功能_类型”格式，例如 LightCtrl_AppSWC、LightCtrl_SensorSWC，类型后缀帮助区分应用层、传感器层和服务层。
• 端口接口名：采用“方向_数据类型”格式，例如 PP_LightState（提供端口）、RP_DoorStatus（需求端口）。
• Runnable名：采用“触发事件_功能”格式，例如 RE_10ms_UpdateLight，便于在代码中快速识别调度周期。

命名规范不需要追求绝对完美，但必须在团队内达成一致并写入模板。一旦某个元素被其他SWC引用，改名就会引发连锁修改，因此前期多花十分钟讨论命名，后期能省下数小时的引用修复。

四、导入ARXML：顺序与冲突处理

导入ARXML是新建工程后最常见的操作。DaVinci Developer支持导入AUTOSAR XML文件，但导入顺序会影响引用解析结果。推荐顺序为：先导入数据类型和常量，再导入端口接口，最后导入SWC和系统描述。原因是SWC通常引用端口接口，端口接口又引用数据类型，如果顺序颠倒，工具会提示“引用未解析”。

导入时需要注意两类冲突：一是同名元素重复导入，工具会提示覆盖或跳过，此时应确认是否确实需要更新；二是包路径不一致，例如OEM提供的ARXML使用 /OEM/DataType，而本地工程使用 /Project/Common/DataType，此时应通过包映射或引用调整来对齐，而不是直接复制元素。导入完成后，建议在“Problems”视图中检查未解析引用，确保所有端口和数据类型都能正确链接。

五、团队协作目录约定

工程文件本身只是工作区的一部分，真正决定协作效率的是目录约定。推荐将工程根目录划分为六个子目录，如上方SVG左侧所示：01_Model存放.dpa工程文件和本地ARXML，02_Import存放OEM或上游提供的只读ARXML，03_Generated存放代码生成器输出，04_Output存放编译产物，05_Doc存放接口文档和变更记录，06_Tools存放生成脚本和配置模板。

版本控制策略上，01_Model、02_Import、05_Doc、06_Tools应纳入Git或SVN管理，而03_Generated和04_Output属于可再生产物，应通过.gitignore排除，避免每次生成都产生大量无意义差异。对于02_Import中的OEM ARXML，建议保持只读，任何修改都通过本地覆盖包或映射完成，这样在OEM更新版本时可以快速替换并重新导入。

六、一个可复用的工程建立检查清单

综合以上内容，新建SWC工程时可以按以下顺序执行，确保每一步都有明确的判断依据：