淺談Simulink/StateFlow建模

   

淺談Simulink/StateFlow建模

       在汽車、工業控制、航空航天等行業，系統與軟件開發中，基於模型的設計（Model based Design，簡稱MBD）逐步在替代傳統的手工代碼開發方式，在MBD領域，Matlab/Simulink做爲通用化的建模與代碼生成工具及其相關配套的工具鏈通過多年的積累，已經在國內外以上行業中被應用到產品的開發中。

      在筆者所處的行業，因爲對象的強非線性、多變量耦合性、時變特性以及被控對象和控制器的複雜性，在算法、容錯處理以及控制邏輯多方面都有着較高和較複雜的要求，並且以上幾方面經常是耦合在一塊兒。基於以上考慮，不管是對被控對象仍是控制器，建模是一件很是必要的事情。而Simulink是無疑是首選！

       Simulink是從學生時代就接觸的一種通用化建模工具，這一工具一樣也陪伴着走上工做崗位。工做的前兩年，因崗位關係，精力更多的投入到了控制算法的設計與驗證上，相關算法最終也能夠用MBD方式生成代碼，同時也積累了必定的實際應用經驗，當前負責的業務通過積累，有了相對的突破。但，隨着接觸更多更復雜的項目，總感受有點缺憾，畢竟，我的對其餘容錯處理及控制業務邏輯的關注卻相對較少，必定程度上形成了本身視野偏窄，崗位更多的定位在仿真驗證上，這種外部限制也讓本身「鞭長莫及」，有些對自我提升有幫助的工做因不是本身負責，沒法作到全身性的學習與工做結合，對整個控制對象的控制過程的理解天然會有所欠缺。好在後來上層對當前工做職責的界限也有了從新的認知，有幸能在新項目中全面貫徹應用層都進行建模的要求，並且，代碼的需求則直接源自更上層的需求以及模型，中遠期必然是走MBD的方式。

一旦負責了整個應用層的建模，則必須將以上提到的容錯處理、算法以及邏輯上進行通盤考慮。其實，這時候做爲建模人員，最重要的就是根據需求結合實現進行架構設計，這裏的架構設計，從我當前的認知來講，就是基於對工做場景的識別來進行功能的解耦與劃分，場景又能夠分爲大場景與小場景，大場景一般採用狀態機（StateFlow）來定義，小場景則既能夠參考大場景來進行獨立設計成模塊也能夠和功能模塊進行耦合，視具體狀況和我的經驗而定，功能解耦則主要體如今不一樣功能最終須要用同一具體控制機構（被控對象與控制器之間還存在執行機構）來實現，這時候既要劃分不一樣的功能，又要有最終具體控制機構的綜合，在功能模塊中實現功能，在具體控制機構模塊中實現綜合，這裏的綜合更多的體如今優先級的斷定與最終輸出量的抉擇上，以上的經驗也是通過不少項目的實踐和妥協得來的，未必說得上通用最優，但能夠說是針對複雜對象進行控制建模的較好的方法，是一種不錯的架構設計實踐。

    通過幾個月項目「錘鍊」，多番需求的迭代與評審，多輪建模設計，在某個瞬間忽然就開竅了，感受一會兒提升了需求的把控能力，不管是大方向仍是具體細節，任何一個需求的更改，都能在腦子裏快速進行需求的分解並創建初步的Simulink模型，即將需求具體化，而所謂的建模，其實就是編碼實現，由於模塊化的建模即對應相應的函數代碼。

    值得注意的是，Simulink模型一般都是基於數據流的，任何輸入必須對應相應的輸出，不管輸出是中間量仍是最終量都有其對應的物理含義，即使這種含義是人爲賦予的；這與C代碼在常規上仍是區別的，在C語言中，某個全局變量可能隨時會根據不一樣的狀態進行變化，這樣容易致使某個變量在多個功能中賦值，這種處處賦值的危害是顯而易見的，除非實現約定好其中的某幾個，不然無約束必將致使混亂。在Simulink建模中同時被說起的還有StateFlow這一功能，StateFlow能夠創建狀態機也能夠進行流程設計，甚至能夠調用Simulink模塊，調用很是靈活，但靈活帶來的也是複雜性，事實上StateFlow更接近於手工代碼，爲了實現某個相對複雜的邏輯採用StateFlow來實現，既有狀態又有代碼，這種形式實際上就是把C代碼進行一種函數封裝，但顯然不具有通用性，與Simulink混用，用的很差很容易打斷數據流，讓人產生混亂，所以，從我的角度，通常不推薦大量使用StateFlow。建議在如下幾種場景下使用：

1、對於大量使用的基準模塊，若用StateFlow實現更簡單；

2、對於大的場景定義，推薦使用，同時不推薦把具體功能放在狀態機裏邊實現；

3、對於綜合模塊，推薦使用。

    對於狀態中經常使用的功能，則經過產生標識（進入與推出條件完備）與輸出，由Simulink實現，來給綜合模塊進行抉擇。

    限於工做性質，只能囉囉嗦嗦這麼多，估計也就本身聽懂了，畢竟以上經驗之談有行業的侷限性，未必適合其餘的，權當是前陣子工做的一個小結吧。