2. Simulink模型工程化基础
当Simulink模型从个人验证走向团队协作与持续集成时，最先暴露的问题往往不是算法本身，而是“模型文件怎么放、参数从哪里来、配置怎么统一、模块怎么复用、版本怎么管”。这一节围绕六个工程化支点展开：模型文件组织、数据字典、配置集、模型引用、库链接与版本管理。它们共同决定了一个模型能否被稳定地构建、测试和交付。
一、模型文件组织：让目录结构表达工程边界
Simulink工程通常不是单个.slx文件，而是由模型、数据、脚本、测试和生成代码共同组成的集合。推荐按“职责”而非“文件类型”组织顶层目录，例如：
project_root/
├─ models/ % 顶层模型与子系统模型
│ ├─ controller.slx
│ └─ plant.slx
├─ libraries/ % 自定义库与库链接源
│ └─ ctrl_lib.slx
├─ data/ % 数据字典与参数文件
│ ├─ controller.sldd
│ └─ plant_params.m
├─ config/ % 配置集与脚本
│ └─ ci_config.m
├─ tests/ % 测试模型与测试用例
│ └─ controller_test.mldatx
└─ build/ % 生成代码与报告（不纳入版本控制）
关键原则是：模型文件与生成物分离。build/、slprj/、*.slxc 等中间产物应写入 .gitignore，避免污染版本库。模型文件名应稳定、可读，避免使用“final_v2_真正最终版”这类命名。对于需要并行开发的模块，可将其拆分为独立模型或库，减少多人同时修改同一文件造成的合并冲突。
二、数据字典：把参数和信号从模型里“抽出来”
数据字典（.sldd）用于集中管理Simulink.Signal、Simulink.Parameter、枚举类型和总线定义。它的价值在于：模型只引用名称，具体数值和类型由字典决定，从而支持同一模型在不同配置下复用。
例如，在数据字典中定义：
Kp = Simulink.Parameter(1.2);
Kp.DataType = 'double';
Kp.Min = 0; Kp.Max = 10;
Kp.DocUnits = 'N·m/rad';
sensor_bus = Simulink.Bus;
sensor_bus.Elements(1) = Simulink.BusElement;
sensor_bus.Elements(1).Name = 'speed';
sensor_bus.Elements(1).DataType = 'double';
模型中的增益模块不再填写数字1.2，而是填写Kp。这样，标定、测试和代码生成都围绕字典进行。需要特别注意的是：数据字典必须与模型建立关联（Model Explorer中绑定），否则模型仍会使用本地工作区变量，导致CI环境中“找不到变量”的典型错误。
三、配置集：把仿真与代码生成配置固化下来
配置集（Configuration Set）保存求解器、步长、硬件目标、代码生成选项等设置。工程化实践中，不应依赖“某台电脑上默认的配置”，而应把配置集导出为脚本或.mat文件，并在CI启动时统一加载。
一个典型的配置脚本片段如下：
cs = Simulink.ConfigSet;
cs.Solver = 'FixedStepDiscrete';
cs.FixedStep = '0.001';
cs.StopTime = '10';
cs.GenCodeOnly = 'off';
cs.TargetLang = 'C';
set_param('controller', 'ConfigurationSet', cs);
配置集应区分“仿真配置”和“代码生成配置”。前者关注求解器精度与速度，后者关注目标硬件、编译器、代码风格。两者混用会导致仿真通过但生成代码失败，或反之。建议在config/目录下保存多个命名清晰的配置脚本，如sim_fast.m、sil_config.m、pil_config.m。
四、模型引用与库链接：复用与解耦的两种手段
模型引用（Model Reference）把一个模型作为另一个模型的组件，支持独立编译、增量加载和并行构建。它适合“功能边界清晰、需要独立测试”的模块。库链接（Library Link）则把一组模块封装为库，供多个模型共享，修改库后所有引用处同步更新。
两者的选择可参考：需要独立仿真、独立代码生成、独立测试的，用模型引用；只需要共享模块实现、不独立编译的，用库链接。库链接要避免“禁用链接后直接修改”的坏习惯，否则库更新无法传播，形成隐性分叉。对于库中的关键模块，可启用“链接时修改”保护，或使用库链接的版本锁定。
五、版本管理：管什么、不管什么、怎么管
Simulink模型的版本管理比纯文本代码更复杂，因为.slx是二进制压缩包，.sldd也是二进制格式。直接对二进制文件做diff几乎不可读，因此需要配合MATLAB的模型比较工具（visdiff）和Git的文本化策略。
建议纳入版本控制的文件包括：.slx、.sldd、.m配置脚本、.mldatx测试文件、.slreqx需求链接文件。不建议纳入的包括：slprj/、*.slxc、*.autosave、build/、*.exe、*.dll。对于.slx，可在Git中配置.gitattributes，将其标记为binary，避免自动合并产生损坏。
版本管理的关键纪律是：每次提交对应一个可构建状态。提交前应运行一次模型编译（Ctrl+D）和最小测试集，确保没有未保存的改动、没有断开的库链接、没有缺失的数据字典变量。对于多人协作，建议使用分支策略：主分支保持可发布，功能分支按模块拆分，合并前通过CI流水线自动检查模型编译和测试通过率。
六、六要素的协同关系
这六个要素不是孤立的。数据字典为模型引用提供参数，配置集决定模型引用是否独立编译，库链接为多个模型提供共享实现，版本管理则把上述所有文件作为一个整体进行追踪。一个常见的CI失败场景是：本地仿真通过，CI上却报“变量未定义”。原因通常是数据字典没有随模型一起提交，或者配置脚本没有在CI中执行。解决方法是把数据字典绑定、配置集加载、模型编译和测试执行写成一条可重复的流水线脚本，并在每次提交时自动运行。
总结来说，模型文件组织解决“放在哪”，数据字典解决“参数从哪来”，配置集解决“怎么跑”，模型引用与库链接解决“怎么复用”，版本管理解决“怎么追踪”。把这六件事在项目启动阶段就固定下来，后续的持续集成与自动测试才有稳定的基础。