說說HIL那些事（三）之capl VS simulink

上期我們說到如何利用CAPL編程實現控制器的在線模擬。

底下，我用VCU整車控制器連接真實的CAN匯流排進行了在線模擬試驗，這種方法可行，但有它的局限性。

代碼不便公開，在這裡說說結論吧。

比如，進行系統上下電試驗時，我通過編程去控制上下電流程涉及到的輸入信號，可以得到我們期望的輸出。但是在做扭矩控制試驗時，就不行了。因為輸出扭矩大小涉及的東西比較多，不光和加速踏板、剎車踏板位置有關，還和車速有關。要模擬整車環境的話，我還得建立一個整車動力學模型去動態地計算出車速並通過CAN線發給VCU，同時扭矩輸出還要受到電池輸出功率的限制等。涉及條件太多，即使做出來，費時費力還容易出現各種bug……

由此看來，CAPL編程只適用於做一些控制邏輯比較簡單的模擬。那麼對於複雜的邏輯控制，我們應該怎麼辦呢？

現下汽車行業最主流的一種開發方式叫基於模型的設計（Model Based Design，簡稱MBD）。這種開發方式擺脫了手寫代碼的繁瑣，通過Simulink模塊的搭建，用圖形化的方式表達控制邏輯，簡單直觀，方便管理。好處有很多，網上關於MBD的帖子有很多，在這裡就不羅列了。

Simulink搭建整車模型，基本的樣子如圖1所示。（圖1來源於MathWorks培訓視頻）

圖1 汽車控制模型

雙擊圖片中的模塊，裡面的結構如圖2所示。（圖2，3不要去看邏輯，因為沒有邏輯，隨意撘的樣子，哈哈）

圖2 控制模型的子模塊

再雙擊圖2中的綠色模塊，裡面的內容如圖3所示。

圖3 子模塊中部分邏輯的具體實現

用Subsystem子系統模塊對實現同一功能的內容進行封裝，通過這樣層層的嵌套，模型的層次更加分明，也更便於我們理解和管理各個子功能模塊。

採用基於模型設計的開發方式，我們只需要調用Simulink庫中的各種模塊，按照我們想要實現的控制邏輯拼搭起模型即可。然後，對編譯器做一些具體設置，build一下（Ctrl+B），Matlab自帶的編譯器就可以將這些圖形模塊以及模塊之間的運算關係編譯成代碼供我們使用。這裡簡化的有點誇張，不過確實非常的快捷方便。

對基於模型設計的開發方式我們點到即止，現在，回到我們HIL測試模擬環境的實現。

在HIL模擬中，我們也可以使用Simulink中的圖形模塊搭建控制器的外圍環境模型。需要我們提取出電池、電機、充電機、整車等之間的邏輯關係或者說特性，來構建它們的模擬模型。然後自動生成代碼，供我們測試調用。這樣比我們去手寫CAPL代碼簡直方便很多。

目前各家車企進行HIL測試基本都是基於Simulink平台來模擬測試環境。具體的實現方法有很多，但無論是CANoe和Simulink的聯合模擬，還是dSPACE實時系統通過實時介面與Simulink連接模擬，只是測試工具不同，實質都是通過將Simulink模型生成可下載執行的C代碼，與測試工具進行連接，與被測對象進行交互模擬。

但是，用Simulink建立的環境模型去模擬也有它的缺點。因為整個模型的模擬步長Sample time在生成代碼時是統一配置的。這樣的話，所有從模型中發出來的信號，發送周期都一樣，不符合匯流排上的實際情況。匯流排上傳遞的報文很多，不同的報文有不同的收發周期。這就需要我們對每個信號再單獨設置採樣周期。設置之後，在測試界面你會發現，測試工具還是統一按照整個模型的模擬步長對信號進行採樣，但信號的變化周期是按照我們單獨設置的周期進行變化，雖然不影響測試結果，但看起來不太對勁。而CAPL編程可以用timer計時器對每個信號的採樣周期進行單獨設置，比較符合匯流排上的實際情況。

綜上兩文，我們可以看到CAPL編程和Simulink建模在模擬測試中各有長短。CAPL編程做一些控制邏輯比較簡單的模擬，簡單快捷，幾條代碼就可以搞定，Simulink建模在邏輯比較複雜的模擬中，有著CAPL無法比擬的優勢，圖形化的建模省去了手寫代碼的繁瑣，更加高效方便。

今天就說到這裡吧。

下一期準備換個話題聊了。話題未定，不如你來「四杯咖啡」的後台，我們一起喝喝咖啡，聊一聊下期的主題。

See you next time！

微信搜索「四杯咖啡」，我的個人微信公眾號，後面會在公眾號不定期更新文章，感興趣的朋友，歡迎關注！