在 Simulink 中面对一个动辄上千个模块、信号线密集到几乎无法滚动查找的模型时很多工程师心里都会冒出同一个念头如果这套逻辑能像写函数一样定义一次、引用多次、修改一处全局生效该有多省心。R2020a 之前这个问题在 Simulink 里并没有特别优雅的解法。普通 Subsystem 只能复制粘贴改一次要手动同步 N 处Model Reference 则要求把被复用的部分抽成一个完整的顶层模型要配置接口、仿真模式、求解器边界对于只是想复用一个“子系统级别的小模块”来说成本明显偏高。R2020a 推出的 Subsystem Reference 模块正好补上了这个空白子系统内容被保存为独立的 .slx 文件主模型里只放一个引用块去指向它同一份定义可以被多个模型、多个实例同时引用。这篇文章会从 Simulink 常用模块库的定位出发讲清楚四个问题Subsystem Reference 到底是什么、它和普通 Subsystem、Model Reference 的区别在哪里如何实操创建并复用一个最小示例在工程建模中会遇到哪些坑以及项目选型时应该怎么判断。读完以后你应该能判断自己的模型是否适合用这个模块并且能够直接上手跑通一个完整流程。1. 这篇文章真正要解决的问题很多团队在推进 Simulink 模型化开发时通常都会经历三个阶段。第一阶段模型很小所有逻辑直接画在一张图里简单直接。第二阶段模型变大开始用 Subsystem 做层级分组把功能模块化。第三阶段模型很大多个工程师同时在一个模型文件上开发反复出现合并冲突、修改遗漏、副本同步问题。大部分团队长期停留在第二阶段和第三阶段之间。最常见的做法是“复制一个子系统副本”把同一个算法模块从别的模型里直接复制粘贴过来。这个做法短期有效但会留下三个隐患。第一修改不同步。算法参数、中间变量、模型配置在任何一个副本上被独立修改后其他副本不会自动更新。仿真结果对不上时很难判断到底是哪一份副本没有被同步到。第二文件膨胀。一个模型文件里塞进几十个内容几乎相同的子系统模型保存速度、编译速度都会下降。用 Git 对比模型变更时差异粒度非常粗很难定位到某个具体子系统的改动。第三协作冲突。两个人同时打开同一个模型文件做修改合并时会产生大量冲突。即便用版本控制工具处理二进制模型文件也只能做到“模型级”的对比无法精确到子系统内部。Model Reference 是一个可用的解法但成本偏高。模型引用要求把被引用的系统提升为“完整模型”需要显式声明接口、仿真模式、代码生成构型等。我只是想复用一个输入输出不过两三个、内部逻辑也不算复杂的算法单元用 Model Reference 有点杀鸡用牛刀。Subsystem Reference 正好落在中间层。它把子系统内容作为独立文件抽出来但保留了子系统本身的轻量化属性。你不需要配置完整的模型引用接口不需要考虑独立仿真模式双击引用块就能进入一个类似模型编辑器的页面修改后保存所有引用该定义的地方自动生效。这篇文章的目标读者比较适合以下三类已经能用 Simulink 搭建完整仿真模型但正在寻找更科学的模型组织方式的工程师正在做汽车电子、机器人、电力电子方向模型规模已经膨胀到需要模块复用的开发者负责 Simulink 模型评审、模型库建设、团队建模规范制定的人员。如果你是刚接触 Simulink 的初学者这篇文章可以收藏作为进阶路线的参考。先跑通文章里的最小示例等模型规模上来后再对照使用收获会更大。2. Simulink 常用模块库与 Subsystem Reference 的定位要理解 Subsystem Reference需要先把它放回 Simulink 常用模块库的全景中看。在 Simulink 的 Library Browser 里模块按功能被分成若干大类。日常建模中用到最多的几类如下Sources信号源包含 Constant、Step、Sine Wave、Ramp、Clock、Signal Builder 等负责产生仿真输入信号。Sinks输出与显示包含 Scope、Display、To Workspace、To File 等用于查看和导出仿真结果。Math Operations数学运算包含 Gain、Sum、Product、Divide、Math Function、Abs 等用于构建控制律、滤波器和数值运算。Signal Routing信号路由包含 Mux、Demux、Bus Creator、Bus Selector、Selector、Switch 等负责信号的合并、拆分和选择。Logic and Bit Operations逻辑与位运算包含 Logical Operator、Relational Operator、Bitwise Operator 等用于布尔逻辑和状态判断。Continuous 与 Discrete连续与离散系统包含 Integrator、Transfer Fcn、Zero-Pole、Unit Delay、Discrete Transfer Fcn 等支撑连续域和离散域的建模。Ports Subsystems端口与子系统这是 Simulink 模型结构化的核心Subsystem、Atomic Subsystem、Subsystem Reference、Model Reference 都放在这个分类下。Ports Subsystems 这一类解决的是模型组织问题当逻辑太多、一张画布放不下时如何把它组织成可读、可复用、可并行开发的单元。这个分类下的模块分工很明确。普通 Subsystem 是最基础的层级封装所有内容保存在父模型中双击即可进入编辑适合局部整理。Atomic Subsystem 在普通子系统基础上增加了“原子执行”属性强调内部逻辑在仿真调度中作为一个整体执行。Enabled Subsystem 带使能端口受外部门控信号控制是否执行。Triggered Subsystem 带触发端口在触发边沿到来时执行。Model Reference 引用一个完整模型文件适合大型分布式开发。R2020a 加入的 Subsystem Reference引用一个独立的子系统文件定位介于“内部子系统封装”和“顶层模型引用”之间。从模块库的组织逻辑来看Subsystem Reference 最接近“把普通 Subsystem 独立成文件”。它仍然是一个子系统模块不需要配置独立的仿真周期、求解器或代码生成目标只是内容不再内嵌在父模型中而是存放在单独文件里。理解这一点后面操作时就不会产生歧义。需要强调的地方是Subsystem Reference 不是一个新增的算法计算模块而是一个“容器类模块”。它和 Model Reference 类似内容由外部文件决定。真正决定运算逻辑的是那个被引用的 .slx 文件里的内部模块结构。3. Subsystem Reference 核心概念与原理Subsystem Reference 的核心概念可以拆成三层来看。第一层是定义 
长河君 · 2026/8/31 2:34:40 · 阅读 1.2k Simulink Subsystem Reference：模块复用与模型组织新方案
在 Simulink 中面对一个动辄上千个模块、信号线密集到几乎无法滚动查找的模型时很多工程师心里都会冒出同一个念头如果这套逻辑能像写函数一样定义一次、引用多次、修改一处全局生效该有多省心。R2020a 之前这个问题在 Simulink 里并没有特别优雅的解法。普通 Subsystem 只能复制粘贴改一次要手动同步 N 处Model Reference 则要求把被复用的部分抽成一个完整的顶层模型要配置接口、仿真模式、求解器边界对于只是想复用一个“子系统级别的小模块”来说成本明显偏高。R2020a 推出的 Subsystem Reference 模块正好补上了这个空白子系统内容被保存为独立的 .slx 文件主模型里只放一个引用块去指向它同一份定义可以被多个模型、多个实例同时引用。这篇文章会从 Simulink 常用模块库的定位出发讲清楚四个问题Subsystem Reference 到底是什么、它和普通 Subsystem、Model Reference 的区别在哪里如何实操创建并复用一个最小示例在工程建模中会遇到哪些坑以及项目选型时应该怎么判断。读完以后你应该能判断自己的模型是否适合用这个模块并且能够直接上手跑通一个完整流程。1. 这篇文章真正要解决的问题很多团队在推进 Simulink 模型化开发时通常都会经历三个阶段。第一阶段模型很小所有逻辑直接画在一张图里简单直接。第二阶段模型变大开始用 Subsystem 做层级分组把功能模块化。第三阶段模型很大多个工程师同时在一个模型文件上开发反复出现合并冲突、修改遗漏、副本同步问题。大部分团队长期停留在第二阶段和第三阶段之间。最常见的做法是“复制一个子系统副本”把同一个算法模块从别的模型里直接复制粘贴过来。这个做法短期有效但会留下三个隐患。第一修改不同步。算法参数、中间变量、模型配置在任何一个副本上被独立修改后其他副本不会自动更新。仿真结果对不上时很难判断到底是哪一份副本没有被同步到。第二文件膨胀。一个模型文件里塞进几十个内容几乎相同的子系统模型保存速度、编译速度都会下降。用 Git 对比模型变更时差异粒度非常粗很难定位到某个具体子系统的改动。第三协作冲突。两个人同时打开同一个模型文件做修改合并时会产生大量冲突。即便用版本控制工具处理二进制模型文件也只能做到“模型级”的对比无法精确到子系统内部。Model Reference 是一个可用的解法但成本偏高。模型引用要求把被引用的系统提升为“完整模型”需要显式声明接口、仿真模式、代码生成构型等。我只是想复用一个输入输出不过两三个、内部逻辑也不算复杂的算法单元用 Model Reference 有点杀鸡用牛刀。Subsystem Reference 正好落在中间层。它把子系统内容作为独立文件抽出来但保留了子系统本身的轻量化属性。你不需要配置完整的模型引用接口不需要考虑独立仿真模式双击引用块就能进入一个类似模型编辑器的页面修改后保存所有引用该定义的地方自动生效。这篇文章的目标读者比较适合以下三类已经能用 Simulink 搭建完整仿真模型但正在寻找更科学的模型组织方式的工程师正在做汽车电子、机器人、电力电子方向模型规模已经膨胀到需要模块复用的开发者负责 Simulink 模型评审、模型库建设、团队建模规范制定的人员。如果你是刚接触 Simulink 的初学者这篇文章可以收藏作为进阶路线的参考。先跑通文章里的最小示例等模型规模上来后再对照使用收获会更大。2. Simulink 常用模块库与 Subsystem Reference 的定位要理解 Subsystem Reference需要先把它放回 Simulink 常用模块库的全景中看。在 Simulink 的 Library Browser 里模块按功能被分成若干大类。日常建模中用到最多的几类如下Sources信号源包含 Constant、Step、Sine Wave、Ramp、Clock、Signal Builder 等负责产生仿真输入信号。Sinks输出与显示包含 Scope、Display、To Workspace、To File 等用于查看和导出仿真结果。Math Operations数学运算包含 Gain、Sum、Product、Divide、Math Function、Abs 等用于构建控制律、滤波器和数值运算。Signal Routing信号路由包含 Mux、Demux、Bus Creator、Bus Selector、Selector、Switch 等负责信号的合并、拆分和选择。Logic and Bit Operations逻辑与位运算包含 Logical Operator、Relational Operator、Bitwise Operator 等用于布尔逻辑和状态判断。Continuous 与 Discrete连续与离散系统包含 Integrator、Transfer Fcn、Zero-Pole、Unit Delay、Discrete Transfer Fcn 等支撑连续域和离散域的建模。Ports Subsystems端口与子系统这是 Simulink 模型结构化的核心Subsystem、Atomic Subsystem、Subsystem Reference、Model Reference 都放在这个分类下。Ports Subsystems 这一类解决的是模型组织问题当逻辑太多、一张画布放不下时如何把它组织成可读、可复用、可并行开发的单元。这个分类下的模块分工很明确。普通 Subsystem 是最基础的层级封装所有内容保存在父模型中双击即可进入编辑适合局部整理。Atomic Subsystem 在普通子系统基础上增加了“原子执行”属性强调内部逻辑在仿真调度中作为一个整体执行。Enabled Subsystem 带使能端口受外部门控信号控制是否执行。Triggered Subsystem 带触发端口在触发边沿到来时执行。Model Reference 引用一个完整模型文件适合大型分布式开发。R2020a 加入的 Subsystem Reference引用一个独立的子系统文件定位介于“内部子系统封装”和“顶层模型引用”之间。从模块库的组织逻辑来看Subsystem Reference 最接近“把普通 Subsystem 独立成文件”。它仍然是一个子系统模块不需要配置独立的仿真周期、求解器或代码生成目标只是内容不再内嵌在父模型中而是存放在单独文件里。理解这一点后面操作时就不会产生歧义。需要强调的地方是Subsystem Reference 不是一个新增的算法计算模块而是一个“容器类模块”。它和 Model Reference 类似内容由外部文件决定。真正决定运算逻辑的是那个被引用的 .slx 文件里的内部模块结构。3. Subsystem Reference 核心概念与原理Subsystem Reference 的核心概念可以拆成三层来看。第一层是定义