在 Simulink 中面對一個動輒上千個模塊、信號線密集到幾乎無法滾動查找的模型時很多工程師心里都會冒出同一個念頭如果這套邏輯能像寫函數(shù)一樣定義一次、引用多次、修改一處全局生效該有多省心。R2020a 之前這個問題在 Simulink 里并沒有特別優(yōu)雅的解法。普通 Subsystem 只能復制粘貼改一次要手動同步 N 處Model Reference 則要求把被復用的部分抽成一個完整的頂層模型要配置接口、仿真模式、求解器邊界對于只是想復用一個“子系統(tǒng)級別的小模塊”來說成本明顯偏高。R2020a 推出的 Subsystem Reference 模塊正好補上了這個空白子系統(tǒng)內(nèi)容被保存為獨立的 .slx 文件主模型里只放一個引用塊去指向它同一份定義可以被多個模型、多個實例同時引用。這篇文章會從 Simulink 常用模塊庫的定位出發(fā)講清楚四個問題Subsystem Reference 到底是什么、它和普通 Subsystem、Model Reference 的區(qū)別在哪里如何實操創(chuàng)建并復用一個最小示例在工程建模中會遇到哪些坑以及項目選型時應該怎么判斷。讀完以后你應該能判斷自己的模型是否適合用這個模塊并且能夠直接上手跑通一個完整流程。1. 這篇文章真正要解決的問題很多團隊在推進 Simulink 模型化開發(fā)時通常都會經(jīng)歷三個階段。第一階段模型很小所有邏輯直接畫在一張圖里簡單直接。第二階段模型變大開始用 Subsystem 做層級分組把功能模塊化。第三階段模型很大多個工程師同時在一個模型文件上開發(fā)反復出現(xiàn)合并沖突、修改遺漏、副本同步問題。大部分團隊長期停留在第二階段和第三階段之間。最常見的做法是“復制一個子系統(tǒng)副本”把同一個算法模塊從別的模型里直接復制粘貼過來。這個做法短期有效但會留下三個隱患。第一修改不同步。算法參數(shù)、中間變量、模型配置在任何一個副本上被獨立修改后其他副本不會自動更新。仿真結(jié)果對不上時很難判斷到底是哪一份副本沒有被同步到。第二文件膨脹。一個模型文件里塞進幾十個內(nèi)容幾乎相同的子系統(tǒng)模型保存速度、編譯速度都會下降。用 Git 對比模型變更時差異粒度非常粗很難定位到某個具體子系統(tǒng)的改動。第三協(xié)作沖突。兩個人同時打開同一個模型文件做修改合并時會產(chǎn)生大量沖突。即便用版本控制工具處理二進制模型文件也只能做到“模型級”的對比無法精確到子系統(tǒng)內(nèi)部。Model Reference 是一個可用的解法但成本偏高。模型引用要求把被引用的系統(tǒng)提升為“完整模型”需要顯式聲明接口、仿真模式、代碼生成構(gòu)型等。我只是想復用一個輸入輸出不過兩三個、內(nèi)部邏輯也不算復雜的算法單元用 Model Reference 有點殺雞用牛刀。Subsystem Reference 正好落在中間層。它把子系統(tǒng)內(nèi)容作為獨立文件抽出來但保留了子系統(tǒng)本身的輕量化屬性。你不需要配置完整的模型引用接口不需要考慮獨立仿真模式雙擊引用塊就能進入一個類似模型編輯器的頁面修改后保存所有引用該定義的地方自動生效。這篇文章的目標讀者比較適合以下三類已經(jīng)能用 Simulink 搭建完整仿真模型但正在尋找更科學的模型組織方式的工程師正在做汽車電子、機器人、電力電子方向模型規(guī)模已經(jīng)膨脹到需要模塊復用的開發(fā)者負責 Simulink 模型評審、模型庫建設、團隊建模規(guī)范制定的人員。如果你是剛接觸 Simulink 的初學者這篇文章可以收藏作為進階路線的參考。先跑通文章里的最小示例等模型規(guī)模上來后再對照使用收獲會更大。2. Simulink 常用模塊庫與 Subsystem Reference 的定位要理解 Subsystem Reference需要先把它放回 Simulink 常用模塊庫的全景中看。在 Simulink 的 Library Browser 里模塊按功能被分成若干大類。日常建模中用到最多的幾類如下Sources信號源包含 Constant、Step、Sine Wave、Ramp、Clock、Signal Builder 等負責產(chǎn)生仿真輸入信號。Sinks輸出與顯示包含 Scope、Display、To Workspace、To File 等用于查看和導出仿真結(jié)果。Math Operations數(shù)學運算包含 Gain、Sum、Product、Divide、Math Function、Abs 等用于構(gòu)建控制律、濾波器和數(shù)值運算。Signal Routing信號路由包含 Mux、Demux、Bus Creator、Bus Selector、Selector、Switch 等負責信號的合并、拆分和選擇。Logic and Bit Operations邏輯與位運算包含 Logical Operator、Relational Operator、Bitwise Operator 等用于布爾邏輯和狀態(tài)判斷。Continuous 與 Discrete連續(xù)與離散系統(tǒng)包含 Integrator、Transfer Fcn、Zero-Pole、Unit Delay、Discrete Transfer Fcn 等支撐連續(xù)域和離散域的建模。Ports Subsystems端口與子系統(tǒng)這是 Simulink 模型結(jié)構(gòu)化的核心Subsystem、Atomic Subsystem、Subsystem Reference、Model Reference 都放在這個分類下。Ports Subsystems 這一類解決的是模型組織問題當邏輯太多、一張畫布放不下時如何把它組織成可讀、可復用、可并行開發(fā)的單元。這個分類下的模塊分工很明確。普通 Subsystem 是最基礎的層級封裝所有內(nèi)容保存在父模型中雙擊即可進入編輯適合局部整理。Atomic Subsystem 在普通子系統(tǒng)基礎上增加了“原子執(zhí)行”屬性強調(diào)內(nèi)部邏輯在仿真調(diào)度中作為一個整體執(zhí)行。Enabled Subsystem 帶使能端口受外部門控信號控制是否執(zhí)行。Triggered Subsystem 帶觸發(fā)端口在觸發(fā)邊沿到來時執(zhí)行。Model Reference 引用一個完整模型文件適合大型分布式開發(fā)。R2020a 加入的 Subsystem Reference引用一個獨立的子系統(tǒng)文件定位介于“內(nèi)部子系統(tǒng)封裝”和“頂層模型引用”之間。從模塊庫的組織邏輯來看Subsystem Reference 最接近“把普通 Subsystem 獨立成文件”。它仍然是一個子系統(tǒng)模塊不需要配置獨立的仿真周期、求解器或代碼生成目標只是內(nèi)容不再內(nèi)嵌在父模型中而是存放在單獨文件里。理解這一點后面操作時就不會產(chǎn)生歧義。需要強調(diào)的地方是Subsystem Reference 不是一個新增的算法計算模塊而是一個“容器類模塊”。它和 Model Reference 類似內(nèi)容由外部文件決定。真正決定運算邏輯的是那個被引用的 .slx 文件里的內(nèi)部模塊結(jié)構(gòu)。3. Subsystem Reference 核心概念與原理Subsystem Reference 的核心概念可以拆成三層來看。第一層是定義