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

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

圖 1：通過桌面和硬件在環(huán)仿真進行可重復系統(tǒng)測試的框架。

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

顫振抑制系統(tǒng)測試目標和設置

顫振是由作用在機翼上的空氣動力引起的振動。這種現(xiàn)象可以導致機翼振動，嚴重時會導致機翼損壞?？刂祁澱竦囊环N方法是使用控制表面并試圖抑制振動。

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

我們需要根據兩個設計需求測試系統(tǒng)：

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

顫振隨時間呈指數(shù)衰減 — 具體而言，系統(tǒng)具有正阻尼比

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

圖 2 顯示了我們的顫振抑制系統(tǒng)的 Simulink模型。

圖 2：飛機顫振抑制系統(tǒng)模型。

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

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

可以在仿真的每個時間步長監(jiān)控顫振的測試環(huán)境

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

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

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

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

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

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

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

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

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

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

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

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

創(chuàng)建和運行桌面仿真

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

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

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

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

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

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

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

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

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

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

圖9：測量角度輸出。

實時測試

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

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

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

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

我們現(xiàn)在將使用測試管理器創(chuàng)建實時測試（圖 11）。

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

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

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

圖 12：實時測試結果。

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

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

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

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

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

隨著系統(tǒng)設計的發(fā)展，我們可以使用測試管理器和我們已經創(chuàng)建的測試來自動執(zhí)行迭代測試并為這些測試生成報告。