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