3. 工作空间与工程结构

在 ConfigurationDesk 中，工作空间（Workspace）是顶层容器，工程（Project）是实际配置工作的基本单元。理解两者的层级关系，是后续所有配置操作的前提。工作空间本身不承载模型逻辑，它只负责组织一个或多个工程，并保存用户级的偏好设置；真正的硬件描述、模型映射、I/O 配置和实时运行参数，全部存放在工程内部。因此，新建工程时选择的路径、模板和命名，会直接影响后续资源引用与版本管理。

新建工程：从模板到初始结构

启动 ConfigurationDesk 后，通过 File → New → ConfigurationDesk Project 进入新建向导。向导第一步要求指定工程名称与存储位置。建议将工程放在独立目录下，例如 D:\CD_Projects\MotorHIL_2024，避免与系统盘或含空格的路径混用，因为部分底层编译工具对空格和中文路径支持不稳定。第二步选择工程模板：空工程（Empty Project）适合从零搭建；示例工程（Sample Project）会预置一个可运行的实时模型与 I/O 配置，适合快速验证工具链。第三步选择目标实时平台，例如 MicroAutoBox II 或 SCALEXIO，该选择决定后续可用的硬件资源库和编译目标。

完成向导后，ConfigurationDesk 会自动生成一套标准目录结构。这个结构不是随意摆放的，而是与工具内部的资源解析规则一一对应。若手动移动或重命名关键目录，工程将无法正确加载。

目录组织：各目录的职责边界

一个典型工程目录包含以下核心部分：

• ProjectName.cdp：工程主文件，记录工程级设置、模块引用关系和工具版本信息，是打开工程的入口。
• Configuration/：存放配置描述文件，包括硬件拓扑、I/O 通道映射、模型接口绑定等。这是工程的核心逻辑所在。
• Models/：存放被集成的 Simulink 模型或 FMU 文件。ConfigurationDesk 不直接编辑模型，而是引用其编译产物。
• Resources/：存放硬件描述文件、A2L 文件、DBC 文件、标定描述等外部资源。资源管理的关键在于路径引用而非文件复制。
• Build/：编译输出目录，包含生成的实时可执行文件、日志和中间产物。该目录通常不纳入版本控制。
• Settings/：保存用户级和工程级的工具偏好，如编译器路径、目标平台连接参数。

需要特别注意的是，Configuration/ 与 Resources/ 的分离设计：前者描述“怎么连”，后者描述“连什么”。当硬件描述文件更新时，只需替换 Resources/ 中的文件，配置逻辑无需改动。这种解耦是工程可维护性的基础。

工程文件类型与配置描述文件

ConfigurationDesk 使用多种文件类型协同工作，常见类型及其作用如下表所示：

其中，配置描述文件（Configuration Description）是工程逻辑的核心载体。它以结构化方式记录：目标平台上有哪些板卡、每个板卡上哪些通道被启用、通道方向是输入还是输出、信号如何与模型端口对应、采样率如何分配。在 ConfigurationDesk 的图形界面中，这些信息以树形结构呈现，但底层仍以 XML 或专用格式存储。理解这一点有助于排查“界面显示正常但编译报错”的问题——通常是描述文件中的引用路径失效或版本不匹配。

资源管理：引用而非复制

资源管理的核心原则是：工程只保存引用路径，不保存资源副本。当添加一个 A2L 文件或 DBC 文件时，ConfigurationDesk 记录的是该文件相对于工程目录的路径。如果资源文件被移动或删除，工程打开时会提示“资源缺失”，此时需要重新定位，而不是重新导入。这种机制的好处是多个工程可以共享同一份硬件描述文件，避免版本分裂；代价是工程的可移植性依赖于目录结构的相对稳定。

为了兼顾共享与可移植，推荐两种做法：其一，将公共资源放在工作空间级别的 SharedResources/ 目录下，各工程通过相对路径引用；其二，若工程需要独立分发，使用 File → Export → Project Archive 将工程与所有引用资源打包为 .cdz 文件，接收方解压后路径关系自动重建。

掌握上述结构后，日常操作可以归纳为一条判断链：新建工程时确认目标平台与模板；配置阶段在 Configuration/ 中完成拓扑与映射；资源变更时只更新 Resources/ 中的引用文件；编译输出统一落在 Build/ 中，不手动干预。当工程需要迁移或共享时，优先使用 .cdz 归档，而不是直接拷贝文件夹。这样既能保持工程内部引用关系完整，也能避免因路径差异导致的资源丢失。