隨著系統設計變得越來越復雜，依靠原型來確定系統性能是否滿足設計需求的風險也變的復雜：在需要啟動測試時，原型可能成本高昂，操作風險大，甚至不可用或不完整。因此，越來越多的工程團隊在設計過程的早期就使用仿真和其他測試技術，此時錯誤更易于修復，且成本更低。

Simulink Test 提供了一個集成框架，使您可以在整個設計過程（從桌面仿真到硬件測試）中執行自動化、可重復的測試（圖 1）。

圖 1：通過桌面和硬件在環仿真進行可重復系統測試的框架。

我們將使用一個顫振抑制示例來演示這種工作框架。

顫振抑制系統測試目標和設置

顫振是由作用在機翼上的空氣動力引起的振動。這種現象可以導致機翼振動，嚴重時會導致機翼損壞。控制顫振的一種方法是使用控制表面并試圖抑制振動。

我們的顫振抑制系統有三個輸入：所需的角度（度）、速度（馬赫）和海拔高度（英尺）。它的單一輸出是機翼的測量偏差（弧度）。

我們需要根據兩個設計需求測試系統：

系統在施加擾動的兩秒內將顫振抑制在 0.005 弧度以內

顫振隨時間呈指數衰減 — 具體而言，系統具有正阻尼比

系統需要在各種操作條件下滿足這些需求，以最大限度地減少在現場部署或投入生產時的意外行為。

圖 2 顯示了我們的顫振抑制系統的 Simulink模型。

圖 2：飛機顫振抑制系統模型。

在這個模型中，我們將在三秒鐘后引入擾動，然后測試控制器是否能夠抑制各種馬赫和海拔高度點的顫振。

要執行測試，我們需要具備以下條件：

可以在仿真的每個時間步長監控顫振的測試環境

記錄數據以確定顫振是否隨時間呈指數衰減的能力

依托各種馬赫和海拔高度值進行迭代的能力

設置測試框架測試序列模塊

控制設計工程師有時會創建兩個獨立的模型，一個用于測試的基礎模型，另一個用于布置。確保基礎模型和布置的模型等效具有一定難度。此外，根據測試任務，可能需要自定義輸入或記錄其他數據，這些會更改基礎模型。

Simulink 提供了兩個工具，使我們能夠避免此版本控制問題：測試框架和測試序列模塊。測試框架是一個與被測系統模塊關聯的模型。它有單獨的模型工作區和配置集，但仍然存在于主模型中。它有效地為我們提供了一個沙盒來測試我們的設計，而不會改變或破壞基礎模型。

要在 Simulink 中從頭開始創建測試框架，我們只需右鍵單擊子系統，或者從工具條中選擇Analysis（分析），然后在選擇Test Harness（測試框架）后，選擇Create Test Harness（創建測試框架）。隨后，以交互方式配置新測試框架（圖 3）。

圖 3：Simulink 中的測試框架對話框。

測試序列模塊（圖 4 中紅框表示）使用 MATLAB作為動作語言（圖 5）。它允許您在評估被測組件時有條件地在測試步驟之間轉換。您可以使用條件邏輯、時序算子（例如 before 和 after）和事件算子（例如hasChanged 和 hasChangedFrom）。

圖 4：測試序列模塊（紅框）和數據記錄（藍框）的測試框架模型。

圖 5：支持 MATLAB 動作語言的測試序列。

第一個需求規定顫振應以施加初始擾動的兩秒內被抑制。我們合并了一個測試序列模塊來實施這個測試用例。我們將期望設置為 0 弧度，并在五秒后計算每個時間步長下的誤差。使用verify函數記錄每個時間步長是否滿足條件。

為了計算阻尼比，我們使用圖 4 中藍框內的 To Workspace（到工作區）和 File Scope（文件范圍）將數據以仿真和實時方式記錄下來。

創建和運行桌面仿真

被測系統有兩個輸入：馬赫和海拔高度。需求定義系統應在各種操作條件下進行測試。我們可以使用 Simulink Test Manager 創建各種條件下的自動化測試用例。測試用例使我們能夠在不同的輸入條件下自動測試這兩個需求，并生成有關它們是通過還是失敗的報告。當設計的更改時，可以重新運行這個測試用例。

使用 Test Manager，我們可以為顫振抑制系統新建一個測試框架，添加測試目的描述，并將其鏈接到需求。最后，我們使用腳本迭代為馬赫和海拔高度指定了一些操作條件（圖 6）。

圖 6：在測試管理器界面中使用 MATLAB 腳本為不同的馬赫和海拔高度值設置迭代。

我們現在將使用此測試自動化工作流程來測試我們的兩項需求。第一項需求已使用測試序列模塊予以處理。重新調用 verify 函數。如果驗證標準在任何時候出現失敗，則整體測試將失敗。

對于第二項需求，我們添加了模塊來記錄仿真數據。我們需要對測量的角度進行一些數據分析，以確定測試是通過還是失敗。通過在每次運行仿真后執行 cleanup 回調函數可完成這項分析（圖 7）。我們可以利用以前的數據分析工作來進行指數擬合，并根據擬合參數聲明通過或失敗。

圖 7：在測試管理器界面中為自定義標準設置cleanup回調函數。

從現在開始，測試將根據我們指定的操作條件自動檢查我們的系統。我們可以在 Results and Artifacts 窗格中看到測試結果（圖 8）。我們可以檢查 verify 語句的輸出，確定未評估測試標準、評估通過及評估失敗的時間。此外，我們可以可視化記錄的指定和測量角度數據。

圖 8：verify語句的輸出（需求 1）。

系統在仿真中通過了所有測試，但讓我們仔細研究以確保滿足需求。顫振應以施加擾動的兩秒內為界的需求。鑒于擾動在仿真中施加了三秒，預期 verify 語句在仿真的前五秒未經測試。從那以后，我們可以看到測試通過了。

測量角度數據表明，顫振不僅是有界的，而且是衰減的，這符合第二個需求（圖 9）。

圖9：測量角度輸出。

實時測試

我們現在準備使用硬件在環 (HIL) 仿真來測試硬件。HIL 的目標是實時仿真被控對象模型動態，同時與將在實際使用的嵌入式控制器連接。為了進行 HIL，我們將運行 Simulink 的筆記本電腦、Speedgoat 實時仿真機以及嵌入式控制器通過模擬和數字 I/O 進行連接連接（圖 10）。

圖10：測試硬件：Windows PC（紅）、Speedgoat目標（藍）和嵌入式控制器（綠）。

在筆記本電腦上，我們從模型中生成 C 代碼并將其編譯為實時應用。該應用可通過以太網連接下載到 Speedgoat 實時目標計算機。生成的代碼包括被控對象模型動態、與控制器通信所需的 I/O驅動程序以及包含 verify 函數的測試評估模塊。

仿真與實時測試之間的關鍵區別在于我們刪除了仿真控制系統并使用在嵌入式處理器上布置的控制系統。然后，我們可以在其實際工作頻率下測試已布置的控制系統及其輸入和輸出。

我們現在將使用測試管理器創建實時測試（圖 11）。

圖11：設置實時測試的Test Manager界面。

在實時測試中，我們構建與之前一樣的環境，外加一個被測系統環境 Target Computer（目標計算機）。測試將允許在實時仿真機中。

我們將在與以前相同的各種操作條件下測試需求，并且對測量的角度進行相同的數據分析，以確定測試是通過還是失敗。我們可以在測試管理器中查看測試結果（圖 12）。

圖 12：實時測試結果。

我們發現某些測試條件下的實時測試失敗了。如圖 12 和圖 13 所示，verify 語句在各個點處失敗，并且測量的角度不會衰減，從而導致系統不穩定。

圖13：來自實時測試的測量角度輸出。

是什么差異導致仿真中通過，而 HIL 測試時失敗？

測試失敗有多種原因，這些原因凸顯了使用硬件進行測試的重要性。首先，在仿真模型中，使用雙精度值作為接口直接連接控制器和被控對象。實時仿真與生產控制器之間的連接通過數字和模擬信號建立，因此，由于量化誤差，我們在接口中立即失去精度。其次，仿真測試沒有考慮實際系統中存在的實際延遲。第三，在仿真中測試的控制設計可能未在生產控制器中正確實施。

盡管這些測試沒有通過，但我們仍有工作要做，我們需要創建一份報告發送給同事。我們要使用測試管理器中的報告生成器創建一個報告，記錄執行測試的人員、測試標準、需求的鏈接以及結果摘要。

隨著系統設計的發展，我們可以使用測試管理器和我們已經創建的測試來自動執行迭代測試并為這些測試生成報告。