3.1 仿真运行机制

3.1 仿真运行机制

本节摘要：按下运行键后，Simulink 依次经历编译与初始化，随后进入"按时间点推进、在每个时间点上先算导数再更新状态"的主循环。本节把这个过程完整拆开：编译期发生什么、时间轴由哪些时刻构成、连续与离散模块在循环里各被调用了什么。它是本章后续三节的地基——求解器选型、过零检测、步长实验，全部建立在对这个循环的理解之上。

从一次运行日志说起

小林的模型最近出现了两个怪现象：同一个模型，某次运行在进度 30% 处明显减速；还有一次，她只是在子系统里调整了模块的摆放位置，运行时的警告信息却变了。两个现象都指向同一个事实：仿真不是"从 t 等于零匀速走到 t 等于结束"的黑盒过程，它有自己的阶段划分与执行规则。要解释现象，先看机制。

编译期：运行键按下后的第一秒

仿真开始后到第一个积分步之前，Simulink 完成四件事。第一，模型编译：把框图展开为执行清单，确定所有模块的计算次序（拓扑排序），初始化各模块的运行时数据结构。这时你会看到窗口短暂繁忙——模型越大、层次越深，编译期越长，这也是"仿真加速"策略里"缓存编译结果"的由来（第 10 章展开）。第二，确定采样命中点：收集全图所有离散速率与配置的固定步长，生成主循环要访问的时间点序列。第三，初始化状态与参数：连续状态向量按模块声明的初值装配，参数从工作区或字典解析落地。第四，数据一致性检查：端口维度、数据类型、采样时间能否对上，任何不匹配在这里直接报错终止——这解释了小林看到的"改个摆放位置警告就变"：位置影响了拓扑排序的并列项裁决，执行次序警告随之改变。

理解编译期还有一个实用价值：回调与断点。模型回调（InitFcn 之类）在初始化阶段执行，把参数加载脚本挂在回调上，"打开模型必先跑参数脚本"的团队约定就从纪律变成了机制。

主循环：先导数，再更新

初始化完成，主循环启动。循环体在每个时间点上做的事可以压缩成两句口诀：连续状态先算导数、由求解器积分推进；离散状态在采样点更新、其余时刻保持。变步长求解器还会在口诀外多一层行为：在一个时间点与下一个之间试探多个候选步长，用误差估计决定接受还是减半重试——这正是 3.2 节的伏笔。

时间轴不是均匀网格。它由一串"时刻"构成：采样命中点（每个离散速率的节拍）、过零事件点（3.3 节）、求解器自己选中的输出点。混合系统里，两条速率的命中点交错出非均匀序列；某次仿真的时间点数远超预期，往往就是某个环节产生了海量事件。小林的"进度 30% 减速"事后查明是负载转矩进入了振荡区，变步长求解器为跟踪振荡不断收缩步长——现象在引擎舱里立刻有了因果解释。

输出与记录：循环里最后的动作

每个被接受的步长完成后，求解器把配置了记录的信号写入日志。记录方式影响内存与速度：全部信号用示波器直连会拖慢仿真，正确做法是用信号日志（To Workspace 或信号记录标记）收集关键量，仿真结束后再统一出图。记录时间点也有讲究——定步长下日志点就是步长点；变步长下默认是求解器接受点，若需要等间隔数据（比如做频谱分析），要么启用"细粒度输出"配置，要么在指定输出时间网格。

一个值得养成的习惯：区分"仿真失败"与"结果错误"。求解器发散、步长坍缩到下限，这类失败会显式报错；而步长偏大导致的精度劣化不报任何错，曲线看起来"大概没问题"，数值却已经失真。后者比前者危险得多，也正是 3.4 节对照实验要量化的对象。

⚠️ 常见坑：把 StopTime 改小来"加速调试"，却忘了变步长求解器的误差容限没有同步收紧——长仿真与短仿真的步长轨迹不同，短跑得通不代表长跑得对。

回调清单：把机制变成机制化的习惯

理解初始化阶段之后，回调就从"高级特性"变成"机制化的挂载点"。一张最小回调清单：InitFcn 挂参数加载（1.2 节"打开模型必先跑参数脚本"的团队约定，落在这里就从纪律变成自动）；StartFcn 挂仿真前的状态复位与记录器清零；StopFcn 挂结果归档（仿真一结束自动把日志写入带时间戳的文件，实验记录不再靠手动保存）；PostContinueUpdate 一类步进级回调慎用——每步都执行的开销在大仿真里非常可观，除非做在线监控，否则别碰。

调试效率上还有一手值得学：编译缓存。编译期是重复仿真的固定开销，模型没变时开启缓存（Accelerator 模式或重用编译结果的选项），第二轮仿真直接跳过编译期。调试时反复"改参数—重跑"的场景下，这笔节省随迭代次数线性放大——这也是第 10 章提速清单里"配置级"优化的预演。注意缓存的失效条件：换了求解器、改了结构、动了采样时间都会触发重编译，参数数值变化则不会——这恰好符合"结构一次定、参数反复调"的工作节奏。

一次减速疑案的完整读数

把机制串成一次实战读取。某长时程仿真（两小时工况）跑到一半遥遥无期，按本节机制逐项读数：步数统计显示已执行的步数远超理论需要——求解器在频繁收缩步长；过零计数高企——某个滞环环节在临界点附近反复横跳；失败重试计数同样偏高——容差对当前的模型刚度偏紧。三项读数拼出完整因果链：滞环横跳制造事件风暴，事件风暴压缩步长，步长压缩后误差估计变严又推高重试率——三种开销互相放大，仿真的有效推进速度被拖到原地踏步。

治理动作随之各就各位：滞环加迟滞宽度（消事件源头）、容差按 3.4 节契约重新定价（消重试）、二者落定后步长自然恢复常态。这个案例的价值在于展示了"读数"的正确打开方式：诊断统计不是三个孤立的数字，而是同一条因果链上的三个环节——机制清楚了，读数自己会讲故事。

本节要点回顾

• 两个阶段：编译初始化一次完成，主循环按时间点推进，编译耗时随模型规模增长；
• 编译期四件事：编译执行清单、生成采样命中点、初始化状态参数、数据一致性检查；
• 两句口诀：连续状态先算导数再积分，离散状态采样点更新其余保持；
• 时间轴非均匀：由采样命中、过零事件与求解器输出点交错构成，事件风暴是减速的常见根源；
• 记录决定后处理质量：关键量用信号日志，等间隔需求显式配置输出网格；
• 失败与失真要分清：发散会报错，精度劣化不报错——后者必须靠收敛检查兜底。

引擎的运转方式看清了，下一节回答随之而来的问题：循环里那个"求解器"到底是谁，从哪个家族里挑。