基於模型的快速原型開發通常分為四個過程：MiL → SiL → PiL → HiL
1. MiL（Model in Loop）模型在環 在PC上基於模型的測試，它的輸出是經過驗證的控制算法模型。驗證控制算法模型是否准確地實現了功能需求
2. SiL（Software in Loop）軟件在環 將模型生成代碼或者手工編寫代碼，編譯成PC程序，在PC上的測試。它的輸出是經過驗證的嵌入式代碼。 在PC上驗證代碼實現的功能是否與模型一致
3. PiL（Processor in Loop）處理器在環 將代碼編譯成目標系統程序，然后在PC上虛擬目標硬件環境（例如Simics，dSPACE），並進行測試。它的輸出是經過驗證的目標程序。在目標處理器上驗證代碼實現的功能是否與模型一致
4. HiL（Hardware in Loop）硬件在環 將目標系統程序燒入實際硬件設備，並進行測試或者汽車標定。 在ECU/EPP/整套系統上驗證代碼實現的功能是否與需求定義一致。
幾個常見問題：
- 這四個測試名字里都有in the loop，那么是不是一定要有閉環？
- NO，某些控制算法實現的功能本身就是不帶閉環的，比如接收到某信號后點亮某某燈，在這種情況下就不需要閉環。
- 是不是一定要有被控對象模型？
- NO，在筆者有限的認知里
（1） 大部分狹義的的MIL（End2End Test）是需要帶被控對象模型的（也有例外，如上文講的某功能知識控制一個燈的開關，大沒有必要建一個燈泡的模型），廣義的MIL一般不care被控對象模型;
（2） SIL測試可帶被控對象模型，但帶被控對象模型的意義不大；
（3）PIL一般是不帶被控對象模型（PlantModel）的；
（4） HIL（無論哪個層級）一般來說都需要被控對象模型。
- 是不是MIL一定要用浮點數，SIL一定要用定點數？
- No. 有些公司進行開發時直接跳過浮點模型用定點建模，在這種情況下，MIL也是用定點數進行測試；dsp和最新的MCU的浮點運算功能都已經很強大，支持用浮點數生成（編寫）的代碼，在這種情況下SIL也是用浮點來測試。
- 不是模型生成的代碼可不可以做SIL？
- Yes，前面已經講了SIL不一定需要被控對象模型，手寫代碼也可以做SIL，只是測試用例需要提前根據功能定義好。
（一） MIL
MIL就是模型在環，通俗一點理解就是對模型在模型的開發環境下（如SIMULINK）進行仿真，通過輸入一系列的測試用例，驗證模型是否滿足了設計的功能需求。MIL是所有測試中最關鍵的，因為MIL的test accept criterion必須源於功能需求，沒有其它的東西可以參考。而SIL/PIL的測試用例往往都是借用MIL的測試用例，一旦在MIL這個階段的使用了錯誤測試用例，這個Bug很有可能會最終流出去，即便所有的測試都通過了。
a) 狹義的MIL
狹義的MIL一般指針對帶被控對象模型，實現整個控制功能的模型進行End to End的測試。
如下圖，電機控制的MIL模型有MotorController和PlantModel兩個子模型組成：
PlantModel又包含：
- Predriver
- Mosfet全橋
- 電流采樣電路
- PMSM電機
- 電機位置傳感器采集電路
運行simulink仿真，比如我們設定電池電壓13V，電機轉速800rpm，指令力矩2Nm，在scope中我們電機輸出了較理想的正弦波，輸出力矩也穩定在2Nm左右，如下：
做到這一步，MIL就算結束了嗎?非也非也，MIL還有一個重要的任務是為SIL和PIL的testcase收集test vectors（TV）。仿真的側重點在於功能是否已正確實現，而MIL在simulation的基礎上，還要把所有的輸入輸出保存起來作為測試向量將來給SIL/PIL使用。
以MotorController為被控對象，讓我們看看下表：
b) 廣義的MIL
在軟件測試領域還有一個很重要的概念是測試覆蓋度，對於ASIL級別比較高的產品，一般都需要MCDC測試覆蓋度100%，而如果模型比較復雜的話，往往前文所述的狹義的MIL很難達到100%的測試覆蓋度，因此我們還需要對某一個具體的子功能模塊特別設置一些測試用例來測試，在這種情況下，往往不使用PlantModel。
（二） SIL
SIL是一種等效性測試，測試的目的是驗證代碼與控制模型在所有功能上是完全一致的。其基本原則一般是使用與MIL完全相同的測試用例輸入，將MIL的測試輸出與SIL的測試輸出進行對比，考察二者的偏差是否在可接受的范圍之內？
因此這個測試的目的就決定了帶不帶被控對象模型並不是那么重要。SIL測試一般都在PC上完成，對代碼的編譯器一般都是LCC，SDK，MSC等這些。
至於SIL的實現方法，那真是五花八門多種多樣了：
- 將代碼封裝成S function在simulink中進行比較
- 用Matlan GUI開發自定義MIL&SIL工具，完成simulink仿真、S-funtion仿真及比較功能（大部分工作都在后台完成，不用那么多鼠標鍵盤操作）
- Matlab中通過將模型轉換為SIL模型 set_param(model_name, ‘SimulationMode’,’Software-in-the-loop’)
- 使用Targetlink工具箱（死鬼死貴的說）
- 使用基於Microsoft Visual Studio或基於VSC環境開發的其它第三方測試工具，如MxVDev
- 使用與Matlab和Targetlink無縫鏈接的第三方工具，如BTC
（三） PIL
PIL測試與SIL測試的不同在於軟件是使用的目標MCU的編譯器（Tasking）進行編譯鏈接，也需要運行在目標板上，其基本工作原理如下。
其測試通過准則是，使用與SIL相同的測試用例輸入進行測試時，比較PIL和SIL的輸出，如果兩者之差在容許范圍之內，則測試通過。
此外，PIL測試還能夠測量某個功能模塊的程序運行時間、堆棧（系統和用戶）使用情況等等如下圖，這些數據在所有軟件功能模塊集成之前對軟件CPU Load、軟件是否有跑飛的風險都是有非常大的幫助的。
下面，我們再來講講HIL。HIL是Hardware-in-the-Loop Simulation的縮寫。顧名思義，就是硬件在環仿真。其實“硬件”二字的含義比較寬泛，一般來說按照in the loop的深度不同可以分為三個層級：
- ECU級：也可以稱之為信號級，僅僅ECU軟硬件采用實物，閉環回路的其他組成部分均采用虛擬仿真系統
- EPP級：也可以稱之為驅動級，EPP是Electrical Power Package的縮寫， ECU及執行機構采用實物，閉環回路的其他組成部分采用虛擬仿真系統
- System級：也可以稱之為機械級，系統組件采用實物，閉環回路其他組成部分采用虛擬仿真系統
為什么我們要采用HIL？這個問題可從以下幾個方面來回答：
- 在某些項目的初期階段，可能用於試驗認證的MuleCar都沒有造出來，因此可以利用HIL系統先行驗證部分控制策略；
- 在項目開發過程中，軟件Release往往比較頻繁，但是整車驗證的周期比較長且受各種條件限制，不可能針對每一版軟件都進行整車試驗，因此可以用HIL虛擬測試環境來替代部分功能性的整車驗證；
- 某些測試工況（特別是FailSafe故障注入測試）風險很大，需要在HIL上先行模擬仿真測試或用HIL測試取代整車測試（試想一下如下場景：車輛180kph，轉向過程中EPS電機卡死，what will happen？）
- HIL系統可以進行7*24自動化測試， 節約測試周期和人力投入（如EPS全功能故障注入測試，如手動試驗，大概需要2人月，采用HIL測試可在1周內完成）
以EPS為例，HIL系統一般可以由以下幾個部分構成：
- 被測的“Hardware”(ECU/EPP/EPS系統)
- 實時硬件仿真平台：用於模擬與in the loop 的Hard的電氣及通訊輸入輸出接口，提供譬如TAS信號、電機位置信號、電流反饋信號、齒條力負載等等；接收被測Hardware發出的各種信號，傳遞給車輛模型（或車輛模型+轉向系統模型）進行計算仿真；同時可以產生各種故障用於故障模擬。
- 實時仿真模型 用於模擬車輛在不同工況下的工作狀態。一般來說包括車輛動力學模型,轉向系統模型，駕駛員模型等。
- 試驗管理軟件 用於對試驗進行管理、參數設置及監控、可視化界面輸出、生成報告等等。
ECU級的EPS HIL系統
ECU級的EPS HIL系統被測對象是ECU，結構比較小巧，主要用於驗證EPS的軟件算法。EPS執行電機由實時硬件仿真平台（Motor Emulation）進行模擬，這一部分對模型的精度要求很高。
上圖中實時模型仿真的Steering Sensor信號直接傳遞給了EPS軟件，這種處理方法對EPS ECU廠家而言這樣做是可行的（反正自家的軟件，可以隨便改接口）；但對某些OEM而言此路不通，因為EPS軟件不能從模型中直接獲取轉矩和轉角信號，這就需要將實時仿真模型中的扭矩和轉角信號傳遞給實時硬件平台，由實時硬件平台模擬出轉矩和轉角的物理信號（模擬量/PWM/SENT/PAS4/PSI5/旋變等等不同接口，詳見筆者文章《簡述電動轉向系統扭矩轉角傳感器》）提供給ECU。
EPP級的EPS HIL系統
EPP級的HIL與ECU級HIL的區別在於電機采用了真實的助力電機，但仍然沒有轉向系統的其它機械部件，因而需要一個額外的伺服電機（磁粉制動器）來模擬齒條力負載。
System級的EPS HIL系統
系統級的EPS HIL被測對象為整套轉向系統，實時仿真模型中只有整車動力學模型和駕駛員模型（不需要轉向器模型和TAS模型），因此體積龐大。“實時硬件仿真平台“其實就是兩個伺服電機：一個伺服電機工作於扭矩伺服模式，用於模擬齒條力負載（加載在齒條上或輸出軸上均可），力矩指令由整車模型給定；另一個伺服電機工作於位置伺服模式或扭矩伺服模式，用於模擬駕駛員給方向盤各種不同的操作工況，指令由HostPC的測試用例給定。這個層級的HIL系統最接近於真實轉向系統在整車的表現。
常見問題：
（1） 關於系統選型
取決於測試需求、公司技術能力及研發預算。Dspace，ETAS，Hirain等等都是比較成熟的系統供應商，當然如果對本公司技術水平足夠自信的話也可以用NI板卡自己搭建，靈活性更強，造價也會相對低不少。
（2） 整車模型
VeDYNA，Carsim，IPG等都是知名的整車動力學模型供應商，但對於EPS這個應用而言，與整車模型交互的信息並不是很多，輸入給整車模型的輸入主要是車速、發動機轉速和方向盤轉角（轉矩），從整車模型獲取的主要參數是齒條力，某些高級一點的應用需要用到質心側偏角和橫擺角速度等等。
所以不差錢就買成熟模型，自己有技術底蘊也可以自己建車輛動力模型。但無論怎樣，有兩件事情是繞不過去的：
- 整車參數的獲取，直接影響到模型輸出的准確程度。參數不准確，哪怕使用的是知名成熟供應商的模型，也得不到准確的輸出。至於如何獲取准確的參數，一方面找OEM要，另一方面可以通過一些實驗用狀態觀測的方法獲取，那又是另一個Topic了。
- 一般來說，轉向器模型和TAS模型需要自己搭建，可參考下圖建立微分方程
（3） 測試用例
測試用例來源於系統功能需求與安全需求，一般來說分為兩類：
功能與性能測試：
在不同的道路特征下（路面附着系數、水平屬性、側坡屬性、凹凸屬性……）目標車輛處於不同的狀態（滿載/輕載，不同胎壓……）時，駕駛員做不同操縱工況（加減速，雙移線，轉角階躍，轉角脈沖，轉矩階躍，轉矩脈沖，蛇形機動，穩態回轉……）；考察轉向系統的穩定性和操縱感覺。
同上在不同工況下進行故障注入，考察整車的安全性；並檢查故障是否被檢測到，相應的FaultCode，DTC是否被記錄，故障燈是否被點亮；是否能通過診斷會話獲取相關的DTC及Snapshot？