MBD開發模式下的XIL仿真測驗
“想了解MBD模式下的MIL、SIL、PIL、HIL嗎？”——虹科
汽車從一個發動機加上幾個輪子的簡單形態發展到如今機械與電子高度融合的復雜整體，經歷了巨變，汽車電子控制單元的數量和復雜度也呈幾何級數增加，給軟硬體測驗工程師帶來了巨大的挑戰，以往常用的測驗方法，汽車ECU研發初期利用工具對其進行理論驗證和單一的測驗便在整車仿真或實際環境中測驗，通過這種方式難以發現問題，到最后的整車測驗發現問題需要對該模塊進行重新設計、重新撰寫程式、重新測驗等，耗費了大量的人力和時間成本，我們更加希望在研發初期對硬體和軟體進行高覆寫率的測驗，并能夠模擬其汽車在不同工況下的各項功能測驗以及邏輯驗證，以便于在研發初期就能發現問題，降低開發成本，減短開發時間周期，
目前，汽車行業應用得比較廣泛的軟體開發方式為MBD（Model base design），也就是以模型為基礎的軟體開發，傳統的嵌入式軟體開發模式是無法與之比擬的，感興趣的讀者可以查找相關資料，深入學習，在這里筆者就不展開了，今天主要想和大家探討的是在MBD中我們經常會談到的MIL、SIL、PIL和HIL，XIL是各種測驗環境的專用術語，可能很多人非常熟悉它們之間的區別與聯系，當然也會有部分讀者容易混淆這些概念，我就是其中之一，今天梳理一下分享給大家，希望能為你們帶來一些幫助，
MIL（模型在環測驗）
模型在環測驗，顧名思義就是指基于模型級別所進行的倍訓測驗，用得比較多的是在Matlab的Simulink平臺下，將被控物件與演算法模型連接在一起形成一個倍訓，對被測系統預期行為動作的測驗，測驗套件是由模型生成，而不是由源代碼生成，因此，基于模型的測驗實質是黑盒測驗，在這里舉個例子，在汽車上的車窗升降電機，工程師可以給創建的模型設定輸入，將實際輸出與期望輸出進行對比，如果兩者結果一致，實作功能需求，則通過測驗，可以說MIL是整個測驗程序中較為關鍵的一環，其必須要基于功能需求開展，如果在這個階段中采用了錯誤的測驗用例，也就是沒有對應功能需求，即使其他的所有測驗均通過了，這也將成為一個致命的問題，
SIL （軟體在環測驗）
我們可以將軟體在環測驗看作是從模型在環測驗原有的基礎上引申出來的，實際上就是將控制器模型生成C代碼，這個程序在Simulink平臺上很容易就可以實作，之后對比驗證生成的C代碼和模型二者的功能一致性（等效性測驗），也就是back2back測驗（背靠背測驗），由于在這個測驗中，要用到C代碼的運行結果來進行比較，所以要保證模型生成的C代碼是可以編譯通過的，模型生成的代碼會用到已有代碼的一些頭檔案、定義等內容，我們需要把頭檔案加載到生成的C代碼中，那么，是否一定需要創建被控物件模型，我們才能進行軟體在環測驗？并不是，因為我們的目的是為了驗證生成的C代碼和模型功能的一致性，那么我們也可以通過手工撰寫代碼，比較手寫代碼和模型在相同輸入下的輸出結果是否一致，就能夠達到軟體在環測驗的目的，
PIL（處理器在環測驗）
上邊提到的SIL測驗的目的是為了防止模型生成的C代碼出錯，最后的輸出結果與模型輸出結果不一致，除了生成C代碼這個程序中可能會出錯，在編譯的程序中，同樣也會出現錯誤，我們通常情況下，是在Windows的平臺下建立模型生成C代碼并進行編譯，使用的也是Windows平臺下的編譯器，但是將生成的C代碼運行到目標處理器上，由于編譯環境不一樣，導致編譯出來的結果也不是完全一致，因此可能會引入新的問題，結合模型測驗、SIL測驗、PIL測驗的結果，可以幫助我們找到可能出現的缺陷和錯誤，除此之外，通過PIL測驗我們可以獲得演算法在處理器上運行的總時間，這能夠為實時控制開發帶來便利，
HIL（硬體在環測驗）
HIL是用于測驗控制器系統的，其中包括硬體、底層軟體和應用層軟體，通常情況下，HIL測驗將被控物件的模型生成C代碼并生成可執行檔案匯入到工控機上運行，工控機連接到控制器，在該狀態下，對于被測驗的控制器來說，它并不知道與其連接的是一臺工控機，而是認為當下處于真實環境，相當于是在實際控制系統中作業，無論是不是MBD開發模式，一般在以下情形都有必要進行HIL測驗：
（1）被控物件昂貴，且控制軟硬體技術不成熟，運行不當會危機人身安全或者造成重大財產損失
（2）為了降低開發成本或是控制器開發出來了但是被控物件還未開發出來
HIL測驗提供一個平臺，讓我們能夠將復雜的演算法匯入到動態的控制系統，控制系統的MCU通過各種介面連接到HIL平臺，實作被控物件實時仿真運行，
如果記不住上面的一大段文字，可以通過下面這個表格，對比一下MIL、SIL、PIL、HIL它們之間的聯系與特點：
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/3312.html
標籤：其他