Simulink建模Tips（二）
前文《Simulink建模Tips（一）》淺嘗輒止的談了一下基於模型開發過程中建模的一些小的工作習慣總結，但被好友戲稱「隔靴搔癢」、「半瓶子水瞎晃蕩」，寶寶有點不開心。
（下載IND4汽車人學習《Simulink建模Tips（一）》）
痛定思痛之下決定痛改前非，再結合一些具體的實例再來講一講，本著把問題講透這個美好的願望開始動筆，但往往現實情況是理想很豐滿，現實很骨感，讀者們還是不要期望值太高了哈。
1. 關於到底是使用SIMULINK還是Stateflow進行演算法的開發
在MAAB na_0006中有比較清楚的定義和usecase說明，但說實話，規則一旦多了，就容易混，簡單總結如下：
Simulink永遠是建模的第一選擇，僅在如下情況下使用Stateflow：
（1）建模有限狀態機
（2）當Simulink框圖太複雜導致不容易被理解時，使用StateFlow的流程圖
簡而言之： StateFlow負責複雜邏輯和複雜流程，SIMULINK負責運算和其它。
在Stateflow中只運行一些極簡單的運算（什麼叫極簡呢？個人讀下來的感覺就是不超過兩個算術運算符，這其實有點扯），如果必須在Stateflow中進行一些複雜運算，則應使用函數調用Simulink子系統來完成。
首先看看下面一個Chart，大家憑直覺判斷一下這麼做是不是符合MAAB的推薦建模規則？（因為MAAB na_0006的那個例子講得稍微有一些複雜，因此筆者嘗試重新舉個更簡單易懂的栗子來說明）
這個Stateflow仍然是不符合MAAB的，因為表達式out=in+Para*(10-in);還不夠簡單。
推薦的做法是使用函數調用的方法如下：
關於使用Staeflow在進行Dataflow的控制方面可以使得模型的可讀性更強的栗子，通過下圖對比一目了然。
2. Stateflow的interface
這部分的相關內容， MAAB的db_0123中只提了一句Stateflow的輸入輸出信號名應該與其信號名保持一致（可重用的模塊除外）。
但筆者認為，在實際使用過程中，最好再加上一些擴展：
（1）Bus 信號不能作為Stateflow的輸入。
（2）標定參數不建議在Stateflow中定義，最好是在外部模型中定義好，將其作為Stateflow的普通輸入，醬紫的話模型以及模型自動生成的代碼的可讀性和可維護性更好。
3. Stateflow的Chart的設置
這些設置在MAAB的 db_0122有提到。主要目的是為了防止Stateflow的模型模擬結果不能反映設計者的真實意圖以及模型與代碼之間存在偏差。
有一個特別重要的也是開發者特別容易忽略的設置我想特別的強調一下（這句話貌似寫的特別地啰嗦）：一定不要選擇「User Specified State/transition execution order」那個選項。為什麼呢？
為嘛這麼說呢？請看下面的栗子（哎，這個季節，真的想吃上海楊浦區本溪路上的那家陳記栗子了，不知道還在不在）：
函數設計需求：用Stateflow設計一個求絕對值的函數。
問題：下面左圖和右圖有何區別？都實現了函數的功能嗎？
細心一點的讀者應該已經發現，左圖和右圖是不一樣的，不一樣的地方在於左圖中條件[in>=0]的優先順序為1，而在右圖中為2（可能是程序員在一個複雜的邏輯中不小心斷開了某一根連線後再重新連上，這種情況就可能發生）.運行模擬後卻會發現只有左圖實現了求絕對值的功能，而右圖實現的只是將輸入取相反數。幺蛾子出就出在這個execution order上，右圖中優先順序為1的路徑執行完以後，路徑2永遠都不會被執行到了。
為了規避這樣的問題，只要不勾選「User Specified State/transition execution order」這個選項，模型再進行編譯的時候，Matlab會自動重新設定路徑的執行順序，從右圖變成左圖，防止錯誤的發生。
你以為這樣就結束了嗎？當然還沒有，點擊此處閱讀原文
下載IND4汽車人APP，做知識領域的專車司機！
推薦閱讀：
