4. MicroAutoBox开发环境搭建
MicroAutoBox 的车载网络算法联调，本质上是一条“模型 → 实时工程 → 目标机运行 → 上位机观测/自动化”的工具链。这条链路由四个 dSPACE 工具分工承担：ConfigurationDesk 负责硬件拓扑与 I/O 配置并生成实时工程，RTI（Real-Time Interface） 把 Simulink 模型与实时工程连接起来，ControlDesk 负责在线标定与测量，AutomationDesk 负责自动化测试序列。四者版本必须匹配，否则会出现工程无法编译、变量无法映射或仪器无法连接等典型问题。
4.1 安装前的版本与依赖确认
dSPACE 工具链对版本一致性要求严格。安装前先确认三件事：一是 MATLAB/Simulink 版本，RTI 与 ConfigurationDesk 的 Blockset 只支持特定 MATLAB 版本区间；二是 MicroAutoBox 硬件型号与固件版本（如 DS1401/DS1511 等），它决定了可用的 I/O 模块与 RTI 驱动；三是 dSPACE 发行版本号（如 Release 2023-A），四个工具必须来自同一发行版。建议在安装前记录如下信息，作为后续排障依据：
MATLAB R2022b (64-bit)
dSPACE Release: 2023-A
MicroAutoBox: DS1511 + DS1513 I/O 扩展
RTI 版本: 与 Release 2023-A 对应
ControlDesk / AutomationDesk: 同发行版安装顺序建议为：先装 MATLAB，再装 dSPACE 基础平台（含 ConfigurationDesk 与 RTI），最后装 ControlDesk 与 AutomationDesk。安装过程中需要指定 MATLAB 路径，安装器会自动把 RTI Blockset 注册到 Simulink 库浏览器中。安装完成后，用 dSPACE 的 dscheck 或许可管理工具确认 License 已正确指向本机，尤其是需要硬件联网授权（如 dSPACE License Server）的场景。
4.2 ConfigurationDesk：硬件拓扑与实时工程生成
ConfigurationDesk 是整条链路的起点，它描述“目标机上有什么硬件、信号接到哪个引脚、以什么周期采样”。典型流程是：新建工程 → 选择 MicroAutoBox 硬件配置（Hardware Configuration）→ 添加 I/O 功能模块（如 CAN、LIN、ADC、DAC、数字 I/O）→ 绑定到具体连接器与引脚 → 设置采样时间与任务 → 生成实时工程。
以 CAN 通道为例，在 ConfigurationDesk 中添加一个 CAN 模块后，需要指定波特率（如 500 kbit/s）、采样点（如 80%）、以及该通道对应的物理接口。若使用 DS1513 扩展 I/O，还要在硬件树中把扩展模块挂到正确的底板槽位。配置完成后执行 Build，ConfigurationDesk 会生成可在 MicroAutoBox 上运行的实时应用程序（.sdf 或对应工程文件），并输出一份 I/O 映射描述，供 RTI 在 Simulink 中引用。
4.3 RTI：把 Simulink 模型接入实时工程
RTI 的作用是让 Simulink 模型“知道”目标机的硬件资源。安装 RTI 后，Simulink 库浏览器中会出现 dSPACE RTI 相关模块库。工程创建流程通常为：在 Simulink 中新建模型 → 从 RTI 库中拖入 RTI Data 或 Hardware I/O 模块 → 通过 ConfigurationDesk 生成的工程文件建立关联 → 把模型中的信号与 ConfigurationDesk 中定义的 I/O 变量一一映射。
映射时要注意方向与数据类型：输入信号（如 ADC 采集）对应 RTI 的输入端口，输出信号（如 DAC 或 CAN 发送）对应输出端口。若模型中使用 CAN 报文，通常通过 RTI CAN 模块配置报文 ID、DLC 与信号布局。完成映射后，在 Simulink 中执行 Build，RTI 会调用编译器生成目标机可执行文件，并通过 dSPACE 的下载机制部署到 MicroAutoBox。首次下载后，可用 ControlDesk 连接目标机，确认变量列表与硬件状态。
4.4 ControlDesk：在线测量与标定
ControlDesk 是联调阶段最常用的上位机工具。它通过以太网或 USB 与 MicroAutoBox 通信，提供变量监视、参数标定、仪表盘与数据记录功能。工程创建流程为：新建 ControlDesk 工程 → 添加目标机连接（指定 IP 或设备名）→ 导入由 RTI 生成的变量描述文件（.a2l 或 .sdf 对应描述）→ 在 Layout 中放置仪表、示波器、标定控件。
实际联调时，建议先建立一个最小验证布局：一个显示 CPU 负载与任务执行时间的仪表、一个监视关键 CAN 信号的示波器、一个可在线修改的标定量（如 PID 比例系数）。下载后若变量显示为灰色或无法读取，通常说明变量描述文件与目标机程序不匹配，需要重新生成并导入。数据记录可保存为 .mf4 或 .csv，供后续分析。
4.5 AutomationDesk：自动化测试序列
AutomationDesk 用于把重复性的联调测试写成可复用的测试序列。它通常与 ControlDesk 配合：ControlDesk 负责实时访问变量，AutomationDesk 负责按步骤调用这些变量并判断结果。一个典型的测试序列包括：初始化目标机 → 设置输入信号 → 等待稳定 → 读取输出变量 → 与期望值比较 → 记录通过/失败。
创建工程时，先新建 AutomationDesk 工程，添加 ControlDesk 连接，再在测试步骤中引用 ControlDesk 中的变量路径。判断条件可用表达式或阈值比较，例如“CAN 车速信号在 2 s 内达到 60±2 km/h”。测试结果会生成报告，便于回归验证。对于车载网络算法，常把报文周期、超时、信号范围作为自动化检查点。
4.6 四工具协同关系与工程创建检查点
四个工具不是孤立使用的，而是围绕同一份实时工程形成闭环。下面的信号与数据流图展示了从硬件配置到自动化测试的协同关系，以及每个环节的关键输出物。
工程创建完成后，建议按以下顺序做一次最小闭环验证：ConfigurationDesk 生成工程无报错 → RTI 编译下载成功 → ControlDesk 能读到变量并观察到信号变化 → AutomationDesk 能执行一条最简单的“设置输入—读取输出—判断”序列。若其中任一环节失败，优先检查版本匹配与变量描述文件，而不是直接修改模型逻辑。
完成上述四步后，MicroAutoBox 开发环境即具备“配置—编译—运行—观测—自动化”的完整能力，可以进入后续的车载网络算法联调阶段。实际项目中，建议把 ConfigurationDesk 工程、Simulink 模型、ControlDesk 布局和 AutomationDesk 测试序列纳入同一版本管理目录，避免因工具版本或文件不同步导致联调结果不可复现。