相信很多人都會和simulink打交道，用來仿真算法、生成代碼、構建plant做測試。simulink的好處就是模塊拖過來、一連線就可以用，所見即所得，so easy!為什么還要談規范呢？

我們建立模型的目的，是為了實現一定的功能。如果是你一個人參與的工作，模型搭建完一段時間后你也許還會回來打開重新看看，解決一下bug、重理一下思路。如果你們是一個團隊，每個人做一部分建模的工作，就需要統一大家的建模風格，這樣任何一個人的工作都能確保別人在短時間內能理解和使用。如果大家有過代碼編程的經歷，相信都知道拿到別人的混亂的代碼，去理解他背后的設計思想是一件多么痛苦的事情。如果這個別人就是你自己，你在心里就會反復的在問自己當初為什么，為什么！

模型也跟代碼一樣，只是它是用圖形化的方式去表達設計思想而已。沒有規矩就不成方圓，合理的統一建模規范，有很多好處，比如：

• 便于將各子模型做集成
• 統一接口定義
• 模型、代碼、文檔的統一風格顯示
• 模型復用性
• 模型易讀性
• 模型易維護性
• 模型無障礙交流、傳遞

如果你不知道上述優點的具體含義，你就理解為建?？梢愿?高大上 、逼格更高就行了。

那具體的建模規范內容有哪些？怎么遵循呢？這就不得不提MAAB了。

MAAB

mathworks自己在官網上已經發布了具體的建模規范，MAAB（ MathWorks Automotive Advisory Board）。

這個規范最開始的初衷并不是要弄一個建模規范出來，而是mathworks在汽車行業里有些重要的客戶，比如 Ford, Daimler Benz, and Toyota等，他們在使用simulink的過程中，會對mathworks公司提出很多新功能的需求，為了統一他們提需求的規范，建立了MAAB?，F在MAAB更新到3.0了，度娘第一屏結果就能找到。

舉個栗子

MAAB里面講了simulink和stateflow的建模規范，100多頁，上百條的規范。以后有時間我會挑一些重要的內容寫出來。這里給大家舉個簡單的例子，看看都是哪些類型的建模規范。

比如項目要實現一個模塊，模塊的輸入是一個模擬量in，模塊的輸出分兩部分，一是out1=3*in+1，二是如果in大于1，就輸出真，否則就輸出假。

于是很快就得到了下面的模型

這模型很簡單吧，這樣搭建肯定能實現功能需求，但從建模規范的角度，有很多不合理的地方。修改了一下，得到如下模型，大家可以找找不同。

命名規范

maab中關于文件、路徑、變量、信號的命名都有規定。通常來說只能用大小寫字母、阿拉伯數字和“_”。最常犯的錯誤就是用 空格 。可以想想C語言里面，變量命名能加空格嗎？用空格對于后期寫腳本處理，也會帶來麻煩。

當然有的公司自定義的規范里，也不許用"_"，那命名就只能用駱駝方法，寫成MyIn，MyOut1， MyOut2這樣。

信號流向

按照大家的閱讀習慣，信號一定要從左到右流動。也即輸入口在左邊，輸出口在右邊。讀模型的時候，大家的習慣都是先找輸入模塊，然后再看信號經過了哪些模塊的處理，到哪里輸出了。

上面的錯誤例子里面，讀者打開模型后，首先要找到正上方的輸入口，然后還要看goto連到了哪些from模塊，腦子要轉一大圈，很費勁，體驗感很差。

信號名

對于模型的輸入輸出口（包括bus、goto等），一定要有明確的命名，這主要是從模型易讀性、代碼生成、后期驗證測試等方面考慮的。

模塊名

如果通過模塊的外觀，就能很明確的知道該模塊的功能，那就應該隱藏模塊名。比如例子里面的add、constant、compare等模塊。

模塊參數

重要的模塊參數，應該顯式的表示出來。比如例子里面的乘法系數3、加法1、比較值1等。

具體的實現方法是，模型點擊右鍵properties->block annotaiton。

有人會問，例子里面的乘法系數不是已經在模塊中間顯示出來了，為啥還要多此一舉？想想這種情況，如果gain的參數不是一個很短的一個數字，如果是3.1414926怎么辦？是把gain模塊拉得很長來顯示嗎？

比較模塊

盡量用顯示比較模塊，這樣更容易閱讀。特別是switch模塊，輸入最好用u2~=0選項。

錯誤的例子：

正確的例子：