延續主題 ，我們從另一個側面來看數學建模的問題。 當我們確信模型符合生活的樸素真理後，我們就可以回答主要問題：“我們這裡到底有什麼？” 在創建技術物件的模型時，我們通常希望確保該物件滿足我們的期望。 為此，對過程進行動態計算，並將結果與要求進行比較。 這是數位孿生、虛擬原型等。 時尚的小傢伙，在設計階段解決瞭如何確保我們得到我們計劃的問題。
我們如何快速確保我們的系統完全符合我們的設計，我們的設計會飛翔還是漂浮？ 如果它飛的話，能飛多高？ 如果它漂浮的話，有多深？
本文討論在創建技術系統的動態模型時自動驗證是否符合技術建築的要求。 作為範例，讓我們來看看飛機空氣冷卻系統技術規範的一個要素。
我們考慮那些可以用數字表達並基於特定計算模型進行數學驗證的要求。 顯然，這只是任何技術系統一般要求的一部分，但正是在檢查這些要求的過程中，我們花了時間、精力和金錢來創建物件的動態模型。
當以文件的形式描述技術需求時，可以區分幾種類型的不同需求，每種需求都需要不同的方法來形成需求滿足的自動驗證。
例如，考慮這組小但現實的需求：
- 水處理系統入口處的大氣溫度：
停車場 - 從負 35 度到 35 度，
飛行中 - 從負 35 度到 39 度。 - 飛行中大氣的靜壓為 700 至 1013 GPa（526 至 760 毫米汞柱）。
- 飛行中SVO進氣口入口處的總氣壓為754至1200 GPa（566至1050毫米汞柱）。
- 冷卻空氣溫度：
在停車場 - 不超過 27 ℃，對於技術區 - 不超過 29 ℃，
飛行中 - 不超過 25 度，技術塊 - 不超過 27 度。 - 冷卻空氣流量：
停車時 - 至少 708 公斤/小時，
飛行中 - 不低於 660 kg/h。 - 儀器室內空氣溫度不超過60℃。
- 冷卻空氣中細小遊離水分含量不大於2克/公斤乾空氣。
即使在這組有限的要求範圍內，系統中至少有兩類需要以不同的方式處理：
- 系統運作條件要求（第1-3條）；
- 系統的參數要求（第 3-7 條）。
系統運作條件要求
在建模過程中開發的系統的外部條件可以指定為邊界條件或一般系統運行的結果。
在動態仿真中，需要確保仿真過程涵蓋指定的運作條件。
參數化系統需求
這些要求是系統本身提供的參數。 在建模過程中，我們可以得到這些參數作為計算結果，並確保每次具體計算都符合要求。
需求識別與編碼
為了便於處理需求，現有標準建議為每個需求分配一個識別碼。 在分配標識符時，非常希望使用統一的編碼系統。
需求代碼可以只是一個代表需求訂單號碼的數字，也可以包含需求類型的代碼、其適用的系統或單元的代碼、參數代碼、位置代碼以及工程師可以想像的任何其他東西。 （編碼的使用請參考文章）
表 1 提供了需求編碼的簡單範例。
- 需求來源程式碼 R-需求 TK；
- 要求的代碼類型 E - 需求 - 環境參數或操作條件
S——系統提供的要求； - 飛機狀態代碼 0 – 任意，G – 停放，F – 飛行中；
- 物理參數類型代號T－溫度，P－壓力，G－流量，濕度H；
- 需求的序號。
| ID 需求 |
描述 | 參數 |
| 註冊01 | 水冷系統入口處的環境空氣溫度：停車場內 - 零下 35°С。 高達 35 ℃。 | |
| 雷夫特01 | 防空系統入口處的大氣溫度：飛行中 - 從-35 ℃到39 ℃。 | |
| REFP01 | 飛行中的靜態大氣壓力為 700 至 1013 hPa（526 至 760 毫米汞柱）。 | |
| REFP02 | 飛行中 SVO 進氣口入口處的總氣壓為 754 至 1200 hPa（566 至 1050 mm Hg）。 | |
| RSGT01 | 冷卻空氣溫度：停車時不超過27℃ | |
| RSGT02 | 冷卻空氣溫度：在停車場，技術單位不超過29℃ | |
| RSFT01 | 飛行中冷卻空氣溫度不超過25℃ | |
| RSFT02 | 冷卻空氣溫度：飛行中，技術裝置不超過 27 ℃ | |
| RSGG01 | 冷卻空氣流量：停車時不低於708公斤/小時 | |
| RSFG01 | 冷卻空氣流量：飛行中不少於660kg/h | |
| RS0T01 | 儀表室空氣溫度不超過60℃ | |
| RSH01 | 冷卻空氣中細小遊離水分含量不大於2克/公斤乾燥空氣 |
需求驗證系統設計。
對於每個設計要求，都有一個演算法用於評估設計參數與要求中指定的參數的對應關係。 總的來說，任何控制系統總是預設包含用於檢查需求的演算法。 甚至任何監管機構都包含它們。 如果溫度超出限制，空調就會開啟。 因此，任何調節的第一步都是檢查參數是否符合要求。
由於驗證是一種演算法，因此我們可以使用與創建控製程式相同的工具和工具。 例如，SimInTech 環境可讓您建立包含模型各個部分的專案包，以單獨專案的形式執行（物件模型、控制系統模型、環境模型等）。
這種情況下的需求驗證專案成為同一個演算法專案並連接到模型包。 在動態建模模式下，它會執行分析以確保是否符合技術規格的要求。
圖 1 顯示了一個可能的系統設計範例。
圖 1.驗證專案的設計範例。
就像控制演算法一樣，需求可以製定為一組表格。 為了方便在 SimInTech、Simulink、AmeSim 等結構建模環境中使用演算法，使用了以子模型形式創建多層結構的功能。 這種組織使得可以將各種需求分組，以簡化處理一系列需求的工作，就像控制演算法所做的那樣（見圖 2）。
圖 2. 需求驗證模型的層次結構。
例如，在所考慮的情況下，區分兩組：對環境的要求和直接對系統的要求。 因此，使用兩級資料結構：兩組，每組都是演算法的葉子。
為了將資料連接到模型，使用了產生訊號資料庫的標準方案，該方案儲存用於項目各部分之間交換的資料。
在創建和測試軟體時，控制系統使用的感測器（真實系統感測器的模擬）的讀數會放置在該資料庫中。
對於測試項目，動態模型中計算出的任何參數都可以儲存在同一個資料庫中，從而用於檢查是否滿足要求。
在這種情況下，動態模型本身可以在任何數學建模系統中執行，甚至可以以可執行程式的形式執行。 唯一的要求是存在用於向外部環境發佈建模資料的軟體介面。
圖 3. 將驗證項目連接到複雜模型。
圖4給出了基本需求驗證表的範例。從開發人員的角度來看，它是一個傳統的計算圖，在其上以圖形方式呈現了需求驗證演算法。
圖 4. 需求檢查表。
檢查表的主要部分如圖5所示。檢查演算法的形成與控制演算法的設計圖類似。 右側有一個用於從資料庫讀取訊號的區塊。 該塊在仿真期間存取訊號資料庫。
分析接收到的訊號以計算需求驗證條件。 在這種情況下，執行高度分析以確定飛機的位置（無論是停放還是飛行中）。 為此，您可以使用其他訊號和模型的計算參數。
正在檢查的驗證條件和參數被傳送到標準驗證區塊，在其中分析這些參數是否符合指定的要求。 結果以可用於自動產生檢查表的方式記錄在訊號資料庫中。
圖 5. 需求驗證計算表的結構。
待測試的參數不一定使用資料庫中包含的訊號，而是由模擬過程中計算的參數控制。 沒有什麼可以阻止我們在草案要求的框架內進行額外的計算，就像我們計算驗證條件一樣。
例如這個要求：
飛向目標過程中校正系統的啟動次數不應超過5次，校正系統的總運轉時間不應超過30秒。
在這種情況下，在需求的設計圖中加入了用於計算啟動次數和總運行時間的演算法。
典型需求驗證區塊。
每個標準要求複選框都旨在計算某種類型的要求的滿足。 例如，環境需求包括停放和飛行時的一系列環境工作溫度。 此模組必須接收模型中的空氣溫度作為參數，並確定該參數是否涵蓋指定的溫度範圍。/p>
此區塊包含兩個輸入連接埠：參數和條件。
第一個輸入的是正在檢查的參數。 在本例中為「外部溫度」。
布林變數被提供給第二個連接埠 - 執行檢查的條件。
如果在第二個輸入處接收到 TRUE (1)，則該區塊執行需求驗證計算。
如果第二個輸入接收到 FALSE (0)，則不符合測試條件。 這是必要的，以便可以考慮計算條件。 在我們的例子中，此輸入用於根據模型的狀態啟用或停用檢查。 如果模擬期間飛機在地面上，則不檢查與飛行相關的要求，反之亦然 - 如果飛機在飛行中，則不檢查與停機位操作相關的要求。
該輸入也可以在建立模型時使用，例如在計算的初始階段。 當模型進入所需狀態時，檢查區塊被停用，但一旦系統達到所需的操作模式，檢查區塊就會開啟。
此區塊的參數為：
- 邊界條件：必須檢查的上限（UpLimit）和下限（DownLimit）範圍；
- 邊界範圍（TimeInterval）所需的系統曝光時間（以秒為單位）；
- 請求ID ReqName;
- 超出範圍的允許性 Out_range 是一個布林變量，用於確定超出檢查範圍的值是否違反要求。
在某些情況下，測試值輸出表示系統有一定的餘裕，並且可能在其工作範圍之外運作。 在其他情況下，輸出意味著系統無法將設定點保持在範圍內。
圖 6. 圖中的典型屬性檢查區塊及其參數。
作為該區塊的計算結果，在輸出處形成 Result 變量，該變數採用以下值：
- 0 – rNone，值未定義；
- 1 – rDone，滿足要求；
- 2 – r故障，不符合要求。
區塊影像包含：
- 標識符文本；
- 數字顯示測量極限參數；
- 參數狀態的顏色標識符。
模組內部可能存在相當複雜的邏輯推理電路。
例如，要檢查圖6所示單元的工作溫度範圍，內部電路如圖7所示。
圖 7. 溫度範圍決定單元的內部圖。
在電路塊內部，使用塊參數中指定的屬性。
除了分析是否符合要求之外，該區塊的內部圖還包含顯示模擬結果所需的圖表。 此圖既可用於計算期間的查看，也可用於計算後分析結果。
計算結果傳輸到區塊的輸出，並同時記錄在根據整個專案的結果建立的通用報告文件中。 （見圖8）
基於模擬結果創建的報告的一個範例是根據給定格式建立的 html 檔案。 此格式可以任意配置為特定組織接受的格式。
在電路塊內部，使用塊參數中指定的屬性。
除了分析是否符合要求之外，該區塊的內部圖還包含顯示模擬結果所需的圖表。 此圖既可用於計算期間的查看，也可用於計算後分析結果。
計算結果傳輸到區塊的輸出，並同時記錄在根據整個專案的結果建立的通用報告文件中。 （見圖8）
基於模擬結果創建的報告的一個範例是根據給定格式建立的 html 檔案。 此格式可以任意配置為特定組織接受的格式。
圖 8. 基於模擬結果的報告文件範例。
在本例中，直接在項目屬性中配置報告表單，並將表中的格式設定為全域項目訊號。 在這種情況下，SimInTech 本身解決了設定報告的問題，並且將結果寫入文件的區塊使用這些行寫入報告文件。
圖 9. 在全域項目訊號中設定報告格式
使用訊號資料庫來滿足要求。
為了自動化屬性設定工作，在訊號資料庫中為每個典型模組建立了一個標準結構。 （見圖10）
圖 10. 訊號資料庫中需求檢查區塊的結構範例。
訊號資料庫提供：
- 儲存所有必要的系統要求參數。
- 從指定參數和目前建模結果方便地查看現有專案需求。
- 使用腳本程式語言設定一個區塊或一組區塊。 訊號資料庫的變化會導致圖中模組屬性值的變化。
- 在需求管理系統中儲存文字描述、技術規範項目或識別碼的連結。
需求的訊號資料庫結構可以很容易地配置為與第三方需求管理系統一起工作，與需求管理系統互動的一般圖如圖 11 所示。
圖 11. 與需求管理系統的交互圖。
SimInTech測試項目與需求控制系統之間的互動順序如下：
- 職權範圍分為要求。
- 技術規範的要求已確定，可以透過技術過程的數學建模進行驗證。
- 所選要求的屬性以標準區塊的結構傳輸到 SimInTech 訊號資料庫（例如，最高和最低溫度）。
- 在計算過程中，結構資料被傳輸到模組設計圖，進行分析並將結果儲存在訊號資料庫中。
- 計算完成後，分析結果將傳輸到需求管理系統。
當設計和/或需求發生變更並且需要重新測試變更的影響時，可以在設計過程中重複需求步驟 3 到 5。
結論。
- 創建的系統原型大大減少了現有模型的分析時間，以符合技術規格的要求。
- 所提出的測試技術使用現有的動態模型，甚至可以用於任何動態模型，包括那些未在 SimInTech 環境中執行的模型。
- 使用大量資料組織可以讓您在模型開發的同時建立需求驗證包，甚至可以將這些包用作模型開發的技術規格。
- 該技術可以與現有的需求管理系統集成，而無需花費大量成本。
對於讀到最後的人來說，
來源： www.habr.com