6.2 脚本化建模与仿真控制
6.2 脚本化建模与仿真控制
本节摘要：从"在画布上拖一次模块"到"用脚本生成一百个变体并自动收集结果"，中间隔着的只是几组命令。本节按构建、配置、驱动三层组织脚本化工具箱：程序化添加模块与连线、读写模型配置、批量仿真与结果收集，并给出"什么该脚本化、什么留在画布"的边界判断。前面各章出现过的命令行片段，在本节合并成一套完整的工作方法。
三个层次的自动化地图
建模与仿真相关的重复劳动，按对象分成三层。构建层的对象是模型本身：添加模块、连线、设参数、建子系统——对应"程序化生成模型骨架""按模板批量改造模型"类需求。配置层的对象是模型设置：求解器、步长、容差、优化选项——对应"多配置对比""按项目规范统一下发配置"类需求。驱动层的对象是仿真运行：跑、停、改参、收结果——对应"参数扫描""蒙特卡洛实验""回归基线"类需求。第 3 章 3.4 节的四组对照实验、第 5 章 5.3 节的二十次重复仿真，都是驱动层脚本的应用实例。
构建层先给一段完整的可复现代码——从空文件到可运行的闭环骨架，十行以内：
% 程序化搭一个最小闭环：阶跃源 + 一阶对象 + 增益控制 + 示波 new_system('auto_build'); open_system('auto_build'); add_block('simulink/Sources/Step', 'auto_build/ref', 'Time', '0'); add_block('simulink/Continuous/Transfer Fcn', 'auto_build/plant', ... 'Denominator', '[0.05 1]'); % 一阶对象 add_block('simulink/Math Operations/Sum', 'auto_build/err', ... 'Inputs', '+-'); % 误差求和 add_block('simulink/Math Operations/Gain', 'auto_build/K', 'Gain', '2.0'); add_block('simulink/Sinks/Scope', 'auto_build/scope'); add_line('auto_build', 'ref/1', 'err/1', 'autorouting', 'on'); add_line('auto_build', 'plant/1', 'err/2', 'autorouting', 'on'); add_line('auto_build', 'err/1', 'K/1', 'autorouting', 'on'); add_line('auto_build', 'K/1', 'plant/1', 'autorouting', 'on'); add_line('auto_build', 'plant/1', 'scope/1', 'autorouting', 'on'); sim('auto_build'); % 即刻可运行
这段脚本的工程意义在"可重放"：评审组要求看不同对象参数下的对比？改一行循环重放；新人要复现实验环境？把脚本发给他，跑出来的模型与你分毫不差。画布操作是"一次性手艺"，脚本是"可分发的工艺"。
图：三层自动化与适用需求
驱动层实战：一次完整的参数扫描
驱动层是收益最高的层，给一个可直接套用的模板。任务是扫比例增益，回答"增益多大时超调越过红线"：
% 参数扫描模板：扫 Kp，记录超调与调节时间 load_system('auto_build'); Kp_list = 1.0:0.5:5.0; results = zeros(numel(Kp_list), 3); % 列：Kp、超调、调节时间 for k = 1:numel(Kp_list) set_param('auto_build/K', 'Gain', num2str(Kp_list(k))); out = sim('auto_build', 'StopTime', '2'); y = out.yout{1}.Values.Data; t = out.tout; ov(k) = max(y) - y(end); % 简化超调定义 ts(k) = t(find(abs(y - y(end)) > 0.02*abs(y(end)), 1, 'last')); results(k, :) = [Kp_list(k), ov(k), ts(k)]; end % 出图与红线判断 % 首个超调越限的 Kp 即答案，结果表随实验报告归档
模板里藏着三个好习惯：结果落表（不是只看图）、扫描范围按工程红线设计、实验脚本与结果一起归档（下季度有人质疑结论，重放即可）。并行加速是顺手的升级——扫描各点彼此独立，parfor 一换，多核机器上时间除以核数。
边界：什么不该脚本化
自动化有收益边界，三条判断。探索性操作留画布：第一次尝试一个结构想法，手拖模块比写脚本快十倍，结构定型后才值得写成脚本沉淀。一次性任务不值得包装：为只跑一遍的操作写通用脚本，开发成本高于收益。视觉布局少花精力：脚本生成的模型布局难免凌乱，对要评审的模型，最后一步手动整理排版，或用自动排布命令收尾。
还有一条隐蔽纪律：脚本里的模型路径与参数名要"按接口引用，不按巧合引用"。set_param 的模块路径写死 'auto_build/K'，一旦有人重命名模块，脚本悄无声息地失效或报错——正式项目里给关键模块固定名称（不加自增后缀），或用查找接口按注释定位，脚本才抗得住模型演化。
⚠️ 常见坑：批量脚本跑了一夜，早上发现第 3 个变体起全部报错——脚本没有在首个异常处停止，后续结果全部基于错误配置。实验脚本要有断言：关键配置写入后读回校验，不一致立即中止。
本节要点回顾
- 三层地图：构建层对结构、配置层对设置、驱动层对运行，自动化按对象选工具；
- 可重放是核心价值：脚本让模型生成与实验执行从"手艺"变成"可分发的工艺"；
- 扫描模板三习惯：结果落表、按红线设计范围、脚本与结果同归档；
- 并行顺手加：独立扫描点用并行循环，时间除以核数；
- 三条边界：探索留画布、一次性不包装、布局最后手动收尾；
- 两条纪律：模块按接口引用、实验脚本带断言——抗演化、防跑偏。
数据与操作都制度化后，模型的最后一公里是"凭什么被信任"。第 7 章验证与测试见。