做多机协同控制仿真的人，大概都经历过这样一个阶段：一开始用理想通信假设，所有智能体实时共享状态，模型跑得又快又稳；等到要考虑真实网络环境的时候，一加入通信延迟，原本收敛得很好的轨迹瞬间变得拖拖拉拉，参数稍微激进就直接振荡发散。我在这个坑里待了不短时间，最后总结出一条路子——与其把延迟当“扰动”躲着走，不如直接在Simulink里把它建成系统的一部分，老老实实分析它对多机轨迹一致性的影响。
这篇文章记录的就是我基于Simulink搭建的通信延迟下多机轨迹一致性仿真分析模型，覆盖建模范式、通信链路搭建、控制器实现、参数整定和踩坑排查几个环节。适合正在做多智能体协同控制、无人机或机器人编队、车辆队列控制等方向的研究生和工程师参考。内容偏工程实操，理论部分点到为止，重点是让你拿到一个能直接跑的建模思路，以及看懂为什么通信延迟会让整个系统变“脆”。
1. 这个仿真场景到底在解决什么问题
1.1 多机轨迹一致性：从理想共识到现实约束
多机轨迹一致性，说白了就是让多个独立运动的智能体——无人机、移动机器人、车辆——最终在位置上、速度上达成一致，或者按照某种约定保持特定队形。它属于多智能体系统一致性（Consensus）问题里比较贴近工程应用的一支。教科书上最经典的提法是：每个智能体是一个动力学节点，通过邻居之间的信息交互，设计分布式协议，使得所有节点的状态收敛到同一个值。
注意“分布式”这三个字，它意味着每个智能体只能拿到自己和邻居的信息，没有中心节点全局调配。这个限制直接决定了我们对问题的建模方式：所有智能体通过通信链路形成一个网络拓扑，拓扑用图来描述，一个邻接矩阵就能塞进MATLAB工作空间，Simulink模型则负责把图上的信息流变成可观测的动态过程。
我在仿真里最常用的是一阶和二阶混合的系统模型。一阶模型描述速度控制型的单积分器系统，比如理想环境下直接给速度指令的小车；二阶模型更贴近无人机和车辆的实际特性，位置和速度是分离的状态变量，控制输入以加速度形式注入。后者在一致性协议上多了一个速度阻尼项和相对速度反馈项，调参空间更大，仿真结果也更有现实感。
初始条件怎么设也值得说。多机一致性分析通常让各智能体从不同的初始位置出发，比如均匀分布在一条直线或者一个圆周上，这样仿真曲线里能明显看到“从发散到收敛”的过程。Simulink里给Integrator模块的初始值赋一个数组，例如[0.5; 2.0; 3.5]，跑出来的位置曲线就会从不同起点逐渐靠拢，看起来非常直观。
1.2 通信延迟：为什么一致性会变差甚至崩塌
理想条件下，如果每个智能体能实时拿到邻居的状态，一阶一致性系统的收敛速度由拓扑图的拉普拉斯矩阵的第二小特征值决定，信号处理领域叫它代数连通度。代数连通度越大，收敛越快。这也是为什么设计拓扑时常常追求连通性好的图结构。
但一旦引入通信延迟，情况就完全不同。用控制语言说，延迟在信号通路里引入了一个e^(-sτ)的相位滞后，会让闭环系统的极点往虚轴方向移动，甚至越过虚轴。直观表现就是：收敛速度变慢，响应出现超调，增益稍大就开始振荡，严重时轨迹直接发散。我做过一组典型对比实验，在无延迟情况下系统能在2秒内收敛到误差0.01以内，加上100ms的固定延迟后，收敛时间变成3.5秒，再把控制增益调高试图加速，结果振荡幅度越来越大——原因就是增益与延迟上界之间存在制约关系。
有意思的是，延迟带来的问题不只是数值上的劣化。如果模型里把通信链路建模成“瞬时可得”，即控制律直接使用邻居的实时状态，Simulink在仿真时会产生代数环。代数环意味着模型隐含了一条零延迟反馈回路，这在物理上是无法实现的，也恰好说明真实系统里通信环节的延迟不是可以忽略的细节，而是模型完备性的必要条件。把这个逻辑想明白，就会理解为什么研究一致性的人对通信延迟如此敏感：网络延迟不是一个小数点后几位的损耗，而是结构性的稳定性威胁。
2. Simulink建模的整体思路与架构设计
2.1 模型分层：把通信、控制、对象分开
我个人的习惯是把仿真模型拆成四个层次：被控对象层、通信层、控制层、观测评估层。
被控对象层每个智能体用一组积分器表示。一阶模型就是一个Integrator，输入是控制量u_i，输出是状态x_i；二阶模型是两个串联积分器，分别是速度和位置。每个智能体的子系统封装成一个Subsystem或者Model块，端口设计成统一的输入输出接口，包括控制输入、状态输出和用于模拟通信延迟的本地状态输入。这样做的好处是，后续要换智能体数量、换动力学模型，都不用动上层协议逻辑。
通信层是整个模型的心脏，它负责把某个智能体的状态按一定延迟传递给它的邻居。我将每个输出信号先经过一个Transport Delay模块，再在接收端汇总到控制器。这其实是一种很关键的模型语义：延迟发生在信号发送的一侧，而不是接收端，这和真实通信的行为一致——信息发出后经过网络传播才到达对方节点。如果你把延迟模块放在接收端，仿真理没变，但信号流看起来会别扭，后面做模块复用时会更容易出错。
控制层接收来自通信层的延迟邻居状态，计算一致性协议给出的控制量，再传给被控对象层。观测评估层则用Scope、To Workspace、Time Scope等模块记录所有智能体的状态和误差指标，供离线绘制曲线和性能对比。分层之后，遇到过不收敛的情况，我可以先用观测层定位是哪个智能体、哪个状态出问题，再回溯到通信层看延迟参数，最后才去动控制层，排查效率高出很多。
2.2 关键模块选型：Transport Delay还是Variable Transport Delay
通信延迟在Simulink里的表达方式有几种，我分别试过，说下实际感受。
Transport Delay模块最简单，固定延迟时间，输入输出关系是y(t) = u(t - τ)。它适合固定步长的离散仿真，只要延迟时间和步长是整数倍关系，精度很高；不是整数倍时会有插值近似（内部通常用Foster/Safonov或Thiran近似），但我建议在正式分析前把步长和延迟调成整数倍关系，避免引入额外的插值误差。
如果要做随机延迟、抖动或者网络负载变化，Transport Delay就不够用了，需要换Variable Transport Delay，它的延迟时长由一个外部输入端口给定。我在模拟网络抖动时，用Random Number模块生成满足一定分布的延迟时间，接到Variable Transport Delay的控制输入上，就能模拟出真实的网络波动效果。需要注意的是，Variable Transport Delay在仿真中容易出现变步长模式下的数值问题，所以一旦用了它，建议固定步长求解器，步长取延迟最小值的大约十分之一，曲线才会平滑。
另一个常见的替代方案是Memory或者Unit Delay，它们只能产生一个仿真步长的延迟。如果步长很小、代表微秒级，而实际通信延迟是毫秒级，就需要串很多个Unit Delay，模型会变得臃肿难读，不推荐作为主方案。我一般只在打破代数环的场景里用Unit Delay，主通信延迟模型还是用Transport Delay。
2.3 网络拓扑与信号路由：向量信号优于Bus信号
多机系统里N个智能体之间的交互关系用邻接矩阵A表示，A_ij = 1表示节点i能接收到节点j的信息。在Simulink里，我有两种做法让这个拓扑生效。
一种是把所有智能体的状态合成一个大向量，例如用一个Vector Concatenation把所有位置状态拼成N维向量，再在控制函数里按拓扑切片取邻居状态。这种方法直观，适合N不大的情况，而且向量信号在Simulink里处理效率高，后面做矩阵运算也方便。
另一种是用Bus信号，把每个智能体的状态作为单独的Bus元素，再用Bus Selector提取。遇到“Bus Selector没有可选信号”这种问题，多半是Bus Creator的输入信号没有命名，或者创建的Bus对象没有正确关联。经验是：用Bus前先给每个信号命名，再把Bus Creator的输出类型设为非虚拟总线并绑定定义好的Bus对象，否则Simulink不会在Bus Selector的下拉框里列出元素。这个小坑很多Simulink教程里都一笔带过，实际踩到才知道多烦。
对绝大多数一致性分析场景，我更推荐向量信号。原因很朴素：一致性算法本质上是矩阵运算，向量信号天然能和邻接矩阵乘起来，而Bus信号还需要反复拆装。多智能体数量一旦扩展到十几二十个，Bus模型的维护成本会明显上升。
3. 通信延迟的建模方法与参数设置
3.1 延迟的来源与建模粒度
先把延迟掰开揉碎。一个数据包从节点j发出到节点i收到，中间经历的时间可以拆成几段：发送端排队时间、链路传播时间、接收端处理时间。在无线自组网或者无线局域网场景里，几十毫秒是常态，复杂网络条件下上百毫秒也不稀奇。对于一致性分析，我们并不需要把每一段都建得很细，通常用两种粒度。
粒度一是固定延迟，把整个通信过程等效为一个常数τ。适合做理论验证、求延迟上界的场景。粒度二是随机延迟，用某种分布描述延迟的波动，比如均匀分布或者指数分布，再加一个均值作为基准。随机延迟更接近真实网络，但仿真结果会出现随机性，分析时要跑多次求平均，不像固定延迟那样一次就能看出规律。
我的建议是分阶段建模：第一阶段用固定延迟把所有机制调通，第二阶段引入随机延迟，第三阶段再考虑丢包。丢包可以用一个摆动开关配合随机数实现：每次仿真步进时判断是否丢包，是的话让接收端保持上一拍的数据，也可以直接把数据置为无效值。但说实话，丢包和延迟对一致性影响的机理不同，丢包更接近信息缺失，延迟是信息迟到，两者叠加会让问题复杂不少。跨机器运行时还要注意时钟不同步甚至跳时的问题，那会让延迟模型的校准变得很痛苦，初学者建议先把固定延迟这部分吃透再往下走。
3.2 在Simulink里搭一条可调延迟链路
具体搭建上，我给每个智能体的输出状态配置一个延迟通道。比如系统有N个智能体，每个智能体把自己的位置x_i传给邻居之前，先经过一个Transport Delay模块，其延迟时间参数来自一个独立的Constant模块，这样我可以把延迟值做成MATLAB脚本里的变量，跑参数扫描时不需要打开模型改东西。
这一步有个容易忽略的点：延迟模块的位置。我坚持把Transport Delay放在发送端，即每个智能体的状态在进入网络之前就被延迟了，然后通过信号线直接连接到接收智能体。还有一个细节是，为了统计误差，我会在被控对象输出端另外引一条无延迟的状态线到评估模块，避免评估环节被延迟污染。换句话说，模型里“真实状态”和“通信观测状态”是两条路径，前者用于分析，后者送入控制器，这样仿真里的因果逻辑才清晰。
如果要做随机延迟，把Transport Delay换成Variable Transport Delay，外部延迟输入端口接一个随机信号源。这里我会对随机信号做一个下限保护，把最小延迟限制到至少一个仿真步长以上。原因很实际：零延迟（小于等于一个步长的延迟）会导致信号直通，产生代数环或者在离散求解器下数值异常。
3.3 延迟参数设置的依据与扫描策略
延迟值应该取多少才算“合理”？这取决于你的通信场景。一个无人机集群用WiFi或者5G链路，控制周期通常在10ms到100ms量级，端到端延迟取50ms是合理的基准值；如果模拟的是多机器人通过蓝牙串口通信，延迟会更大；如果是工业有线网络的运动控制，延迟可能是微秒到毫秒级，但那对一致性分析的意义就不大了，更多是实时同步问题。
我的扫描策略是这样：先取一组典型值做基准，比如0ms、50ms、100ms、200ms四个档位，跑完之后把收敛误差曲线画在一起，观察延迟对收敛时间的影响趋势。然后再对延迟值做密集扫描，例如从0到300ms、步长25ms，记录系统首次出现发散时的延迟临界值，或者绘制“延迟-最大允许增益”曲线。后一条曲线很有用，能直接看出在什么延迟条件下该把控制增益压到多低。
还有仿真步长和延迟的配合问题。我通常用固定步长求解器，比如ode4（四阶龙格库塔）或者ode5，步长设成0.001秒。这样即使延迟是0.05秒，也是50个步长的整数倍，Transport Delay内部不需要插值，延迟链路的精度最高。如果步长是0.004秒而延迟是0.05秒，出现比例不是整数，模块会用分数延迟近似，虽然仿真也能跑，但一致性收敛曲线的误差会被插值噪声污染，定位问题时会干扰判断。
4. 一致性控制器的实现细节
4.1 一致性协议与控制律推导
无向拓扑下的一阶一致性协议是教科书经典：
u_i = -k * sum( a_ij * (x_i - x_j) )写成向量形式就是dot x = -k L x，其中L是拉普拉斯矩阵。系统收敛速度取决于L的最小非零特征值，也就是前面说的代数连通度。如果我们给一阶系统加上积分补偿项，其实就变成类PID结构，在很多工程场景中能消除稳态误差，但一致性协议本身如果拓扑连通，误差天然为0，不一定需要积分项，反而积分会给系统增加额外极点，延迟环境下更容易失稳。
加了通信延迟后，控制律使用的是邻居的延迟状态：
u_i(t) = -k * sum( a_ij * ( x_i(t) - x_j(t - τ) ) )这里有一个易错点：x_i(t)是自身当前状态，x_j(t - τ)是收到的邻居延迟状态。模型里如果偷懒，把自身状态也取成延迟版，系统就变成了异步共识，收敛条件会发生变化，仿真结果和理论分析对不上。所以我特别强调，Simulink模型中必须分清“本地实时状态”和“邻居延迟状态”两路信号，宁可多画几条线，也不要让信号混在一起。
二阶系统的一致性协议更复杂一点，我常用的形式是：
u_i = -k_p * sum( a_ij * (x_i - x_j) ) - k_d * sum( a_ij * (v_i - v_j) )位置项保证空间收敛，速度项提供阻尼，相当于一个PD结构。直觉上，如果只有位置反馈没有速度阻尼，多机之间会像弹簧一样来回振荡，永远不能真正停下来；有了速度相对反馈，系统才能消耗掉相对动能，最终以相同速度并排前进或保持相对静止。k_p和k_d的比值是关键，比值过大容易出现位置超调，比值过小则速度收敛太慢。
4.2 用MATLAB Function写控制律：简洁与坑
在Simulink里实现上述控制律，我选择MATLAB Function块，把所有智能体的状态向量作为输入，在函数内部做矩阵运算，直接输出控制量向量。这个方案代码量小、可读性好，也方便把邻接矩阵从MATLAB工作空间直接传进去。
函数骨架大概是这样的：
function u = consensus_controller(x, A, k_p, k_d) N = length(x) / 2; positions = x(1:N); velocities = x(N+1:2*N); u = zeros(N, 1); for i = 1:N for j = 1:N if A(i,j) ~= 0 u(i) = u(i) + k_p * (positions(j) - positions(i)) ... + k_d * (velocities(j) - velocities(i)); end end end end熟悉MATLAB的人一眼能看出，这其实可以写成矩阵乘法，用拉普拉斯矩阵会更紧凑。但循环版本在N不大时性能完全够用，而且容易调试，打印中间变量也方便。
这里有个关键细节：输入向量x中，位置的延迟版本和实时版本如何组织？我的做法是把模型分成两路输入给MATLAB Function——一路是实时状态，来自被控对象积分器的直接引出；另一路是延迟状态，来自通信层传输后的信号。函数内部用实时状态作为x_i，用延迟状态作为x_j。如果只输入延迟状态，控制律就变成了全异步形式，语义就变了。
用MATLAB Function还有一个常见的报错来源：输入信号的维度在仿真开始后才能确定。如果初始时刻某个信号的维度不对，会导致“Port width mismatch”或者“Dimension mismatch”报错。解决方法是把所有输入信号先经过一个明确的Vector Concatenation，并且在脚本里用工作空间变量定义好N，保持各端口维度一致。
4.3 控制增益整定：从无延迟试到有延迟
增益整定是我做过最多轮操作的一步。标准流程是：先在零延迟的理想模型上调好k_p和k_d，使系统收敛快、超调小；加入通信延迟后，大概率出现振荡或不收敛，这时候把增益按一定比例回退，观察临界稳定点。
理论上，延迟系统的稳定上界可以用频域判据估算。以二阶系统为例，如果系统在无延迟时闭环主导极点是-σ ± jω_d，加入延迟τ后，相位裕度会减小ω_d τ这么多，当总相位裕度降到0以下系统就失稳。实际操作中我不太会做精确的频域计算，更常用的是扫参数法：固定延迟值，从较小的增益开始逐步放大，记录临界增益值，画出“延迟-临界增益”曲线。这条曲线能给整个系统提供一个比较直观的稳定边界参考。
整定后的经验值没有统一答案，但有一个重要的模式：通信延迟越大，允许的增益越小。如果追求快速收敛，要么减小拓扑直径，让信息更快到达全局；要么改进协议结构，增加预测补偿或者Smith预估器，这都是后续可以扩展的方向。
5. 实操过程中的踩坑记录与排查技巧
5.1 排查流程：从单机到多机逐层测
做多机模型调试，我最忌“一把梭”——直接搭好N机模型，跑不出来才开始迷茫。我的固定流程是分层验证：第一步，把控制器输入全部换成实时状态，相当于零延迟，跑通理想一致性问题，确认每个智能体的被控对象和积分器连接无误；第二步，双机互联加通信延迟，看看两个节点是否还能达成一致，这时候问题最容易暴露，因为信号链路少，从Scope里能看清楚延迟信号和实时信号的对齐情况；第三步扩展到N机，确认拓扑连接正确。
这个流程看似基础，但很多人直接跳到第三步。有次我遇到过模型怎么调都不收敛，最后发现是邻接矩阵在MATLAB工作空间里定义的是有向图，而我在画拓扑时默认成无向图，有个方向的连接根本没生效。不逐层排查，这种问题光看仿真曲线真的很难定位。
5.2 仿真步长与延迟量化带来的“假发散”
固定步长仿真下，Transport Delay的延迟时间如果不是步长的整数倍，模块会使用分数延迟近似，这会引入插值误差。在一致性分析中，这种误差的表现是曲线出现高频毛刺，甚至在某些条件下被误判为不稳定——我管它叫“假发散”。
排查方法很简单：把步长进一步减小，比如从0.001变成0.0005，如果振荡幅度大幅下降或者消失，说明是数值问题而非系统动力学问题；如果振荡依然存在，才需要怀疑控制参数。另一个办法是把延迟值凑成步长的整数倍，看现象是否改善。这个判断技巧在分析延迟对稳定性影响时非常重要，否则很可能会得出“延迟导致系统发散”的错误结论，而实际上是步长太粗导致的数值假象。
5.3 代数环：不只是报错提示
Simulink检测到代数环时会提示，但很多人直接点击接受或者依赖求解器自动处理，忽略了代数环本身是有物理意义的。当控制律里直接使用无延迟的邻居状态，而控制量又马上反送回被控对象时，反馈回路中不存在任何时间滞后，Simulink就必须在同一个仿真步内迭代求解方程——在真实物理系统里这是不存在的。
解决代数环最正规的方式，是让通信路径上有一个明确的延迟。这恰好和这个模型的主题完美契合：加入Transport Delay后代数环自动消失，因为延迟打破了即时反馈，给控制器传递的是“上一刻”的邻居状态。如果因为某些原因不想加延迟，可以加一个Unit Delay或Memory，用一个人为的一个步长滞后代替通信延迟，但仿真结果的物理意义就弱化了一层。
5.4 代码生成、外部模式与覆盖率分析的注意点
如果这个模型要部署到硬件或者做半实物仿真，有几个细节跟纯仿真完全不同。首先，求解器必须改成离散、固定步长，Transport Delay在离散求解器下的实现会转化为延时计数器和延迟线，行为更可控。其次，模型里的MATLAB Function块如果包含不支持代码生成的函数，Embedded Coder会报错，建议把控制律翻译成纯基本运算，或者直接用Simulink模块搭出来。
外部模式（External Mode）用于在上位机实时调参，我把延迟参数、增益参数都设为可调参数，在运行过程中直接修改数值。但要注意，Transport Delay模块的延迟时间在外部模式下修改后，模型是否需要重新编译取决于目标硬件和求解器的支持程度，有的平台只有改步长或者改固定参数时才需要重建。最保险的做法是，把延迟参数设计成一个查表结构，通过Lookup Table间接读取，调参时只改表格内容，避免直接触碰模块内部参数。
做MCDC覆盖率分析时，如果模型里包含逻辑判断，比如if-else处理边界情况，需要先把逻辑分支模块化再加Merge和空子系统占位，否则生成的覆盖率报告会有大量未执行分支。这个虽然不属于一致性仿真本身的核心，但和安全相关代码验证强相关，提前知道能少踩坑。另外，用Embedded Coder做代码生成时，可以用数据字典管理参数和信号别名，比直接在工作空间里散放变量规范得多。
5.5 常见问题速查
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 状态曲线出现阶梯状毛刺 | 步长过大引起的延迟量化误差 | 减小步长，或让延迟为步长整数倍 |
| 系统不收敛但无振荡 | 控制增益过小，或拓扑不连通 | 增大增益，检查邻接矩阵是否连通 |
| 系统高频振荡或发散 | 增益过大或延迟过大 | 回退增益，绘制临界增益曲线 |
| 初始阶段大幅跳变 | 初始状态不平滑或代数环迭代问题 | 平滑初始条件，检查是否存在代数环 |
| Bus Selector下拉框无信号 | Bus Creator输入未命名或未用非虚拟总线 | 给信号命名并绑定Bus对象 |
| 加入随机延迟后曲线异常 | Variable Transport Delay数值问题 | 固定步长求解器，限制延迟下界 |
这张表是我自己的经验整理，不一定覆盖所有情况，但照着排查可以少走很多弯路。
6. 结果分析与可扩展方向
6.1 从仿真曲线里提炼结论
仿真跑完，数据怎么分析也是学问。我一般记录三类量：实时状态曲线、一致性误差曲线，也就是所有智能体状态两两差值的最大值或均方根，以及收敛时间。把延迟参数设为不同值跑几遍，误差曲线的下降斜率就能很直观地告诉系统在延迟下的收敛性能。
还有一个重要参考量是“最大允许延迟”。具体做法：固定一组控制增益，遍历延迟值，找出闭环系统刚好保持稳定的临界延迟。这个值可以用于指导真实通信链路的设计：如果临界延迟是150ms，而实际网络最坏延迟是200ms，那系统就有失稳风险，要么换低延迟链路，要么降低控制增益。
6.2 从固定延迟扩展到随机延迟与丢包
固定延迟分析透彻之后，可以把通信层换成随机延迟模型，比如用均值50ms、方差20ms的高斯分布或均匀分布，再叠加一个丢包开关。随机性出现后，仿真结果必须跑多组，例如50次蒙特卡洛，取统计特征，单独一次随机仿真没有说服力。可以用MATLAB脚本控制Simulink模型的多次仿真，记录每次的收敛时间，最后画箱线图，能更真实评估系统在非理想网络下的表现。
这里我可以给出一个简单的脚本思路：用sim函数在循环里反复调用模型，每次修改工作空间的延迟参数，把To Workspace记录的误差信号导出到数组，最后统一画图。批量跑参数扫描时，建议关闭Simulink的动画刷新，用set_param(model, 'SimulationCommand', 'start')方式可以稍微提速，N不大时提升并不明显，但N到20以上就值得用了。
6.3 与Carsim、电机驱动等场景的联动
多机一致性分析不是孤立的题目，很多实际工程场景都能嫁接上去。比如车辆编队问题，可以用Carsim和Simulink联合仿真，把这里的二阶积分器替换成Carsim提供的整车动力学模型，通信延迟层保持不变，控制层加入队形约束和车道保持限制，就能做四轮转向车辆的编队控制仿真，比纯线性模型可信度高不少。关键是Carsim模型的输入输出端口要封装好，和一致性控制器之间的接口尽量保持简单。
无人机集群方向，如果这个模型收敛性和参数边界都摸清了，下一步就是生成C代码部署到飞控上做半实物仿真，通信延迟的建模经验可以直接沿用。电力电子方向也有可以借鉴的地方，像电机驱动逆变器仿真、光伏逆变器仿真、变压器励磁涌流仿真，这些场景的共性问题都是控制器与执行器之间存在延迟，虽然动力学模型完全不同，但“延迟如何影响闭环稳定性和轨迹跟踪”的分析逻辑是通用的。我之前帮一个做电池管理的朋友看模型，他用Simulink安时积分法估算SOC，里面采样延迟对估算精度的影响，本质上也是“延迟信息是否可信”的问题——概念同构，一理通百理明。
从我个人的仿真体验出发，建议把通信延迟当作模型的一等公民来对待，而不是事后补丁。模型从一开始就保留延迟链路，参数先放在一个保守值上，比如100ms，调控制参数时始终带着它做约束，这样出来的模型在复杂网络条件下才有参考价值。
最后再分享一个我自己的习惯：每次跑完一组仿真，我会把延迟值、增益、收敛时间、是否振荡记成一个简单的表格存下来，用MATLAB脚本批量跑参数扫描，然后边看曲线边在表里标注释。几次积累下来，我对自己这套模型的稳定边界心里有数了，不用每次都从头试。Simulink仿真这东西，真正有价值的不是模型图画得漂亮，而是你愿意在参数空间里老老实实跑一遍，把边界摸清楚。这篇记录到的坑和方法，但愿能帮你少走几段弯路。
