動的モデリング中の技術仕様要件の自動検証

テーマを続ける 「あなたの証拠は何ですか？」, 数学的モデリングの問題を反対側から見てみましょう。 このモデルが人生の素朴な真実に対応していると確信できたら、「ここには正確に何があるのか​​?」という主要な質問に答えることができます。 技術的オブジェクトのモデルを作成するとき、私たちは通常、そのオブジェクトが期待を満たしていることを確認したいと考えます。 この目的のために、プロセスの動的計算が実行され、その結果が要件と比較されます。 これはデジタルツイン、仮想プロトタイプなどです。 ファッショナブルな小さな人たちは、設計段階で、計画したものを確実に実現する方法の問題を解決します。

システムが設計どおりであること、設計が飛ぶのか浮くのかを迅速に確認するにはどうすればよいでしょうか? そして飛ぶとしたらどれくらいの高さになるのでしょうか？ そして浮くとしたらどれくらいの深さになるのでしょうか？

この記事では、技術システムの動的モデルを作成する際の、技術建物の要件への準拠の検証の自動化について説明します。 例として、航空機の空冷システムの技術仕様の要素を見てみましょう。

数値的に表現できる要件を考慮し、特定の計算モデルに基づいて数学的に検証します。 これがあらゆる技術システムの一般要件の一部にすぎないことは明らかですが、オブジェクトの動的モデルの作成に時間、神経、資金を費やすのは、これらの要件を確認するためです。

技術要件を文書の形式で記述する場合、いくつかのタイプの異なる要件を区別することができ、それぞれの要件を満たすための自動検証を形成するために異なるアプローチが必要です。

たとえば、次の小規模だが現実的な一連の要件を考えてみましょう。

1. 水処理システム入口の大気温度：
   駐車場 - マイナス35℃から35℃まで、
   飛行中 - マイナス35度から39度。
2. 飛行中の大気の静圧は 700 ～ 1013 GPa (526 ～ 760 mm Hg) です。
3. 飛行中の SVO 吸気口の入口の全気圧は 754 ～ 1200 GPa (566 ～ 1050 mm Hg) です。
4. 冷却空気温度:
   駐車場 - 27 °С以下、テクニカルブロック - 29 °С以下、
   飛行中 - 25 °С以下、テクニカルブロックの場合 - 27 °С以下。
5. 冷却風量:
   駐車時 - 少なくとも 708 kg/h、
   飛行中 - 660 kg/h以上。
6. 計器室内の気温は 60 °C 以下です。
7. 冷却空気中の微細な自由水分の量は、乾燥空気 2 kg あたり XNUMX g 以下です。

この限られた要件セットの中でも、システム内で別の方法で処理する必要があるカテゴリが少なくとも XNUMX つあります。

• システムの動作条件の要件 (第 1 条から第 3 条)。
• システムのパラメータ要件 (条項 3 ～ 7)。

システム動作条件の要件
モデリング中に開発中のシステムの外部条件は、境界条件として、または一般的なシステムの動作の結果として指定できます。
動的シミュレーションでは、指定された動作条件がシミュレーション プロセスでカバーされていることを確認する必要があります。

パラメトリックシステム要件
これらの要件は、システム自体によって提供されるパラメーターです。 モデリング プロセス中に、これらのパラメーターを計算結果として取得し、特定の計算ごとに要件が満たされていることを確認できます。

要件の特定とコーディング

要件の処理を容易にするために、既存の標準では各要件に識別子を割り当てることが推奨されています。 識別子を割り当てるときは、統一されたコーディング システムを使用することが強く望まれます。

要件コードは、要件の注文番号を表す単純な数字であることも、要件のタイプのコード、要件が適用されるシステムまたはユニットのコード、パラメータ コード、場所コード、および要求コードを含むこともできます。その他、エンジニアが想像できるあらゆるもの。 (エンコーディングの使用については記事を参照してください)

表 1 は、要件コーディングの簡単な例を示しています。

1. 要件のソースコード R-requirements TK;
2. コード 要件のタイプ E - 要件 - 環境パラメータまたは動作条件
   S - システムによって提供される要件。
3. 航空機ステータス コード 0 – 任意、G – 駐機中、F – 飛行中。
4. 物理パラメータのタイプ コード T – 温度、P – 圧力、G – 流量、湿度 H;
5. 要件のシリアル番号。

ID 必要条件	説明	パラメーター
REGT01	水冷システムの入り口の周囲温度：駐車場 - マイナス35°Сから。 最大35°С。
REFT01	防空システムの入り口の大気温度：飛行中 - マイナス35°Сから39°С。
REFP01	飛行中の静大気圧は 700 ～ 1013 hPa (526 ～ 760 mm Hg) です。
REFP02	飛行中の SVO 吸気口の入口の全気圧は 754 ～ 1200 hPa (566 ～ 1050 mm Hg) です。
RSGT01	冷却空気温度: 駐車時 27 °С 以下
RSGT02	冷却空気温度: 駐車場、技術ユニットの場合は 29 °С 以下
RSFT01	飛行中の冷却空気温度は25℃以下
RSFT02	冷却空気温度: 飛行中、技術ユニットの場合は 27 °С 以下
RSGG01	冷却風量: 駐車時 708 kg/h 以上
RSFG01	冷却空気流量: 飛行中 660 kg/h 以上
RS0T01	計器室内の気温は 60 °С 以下
RSH01	冷却空気中の微細な自由水分量は、乾燥空気 2 kg あたり XNUMX g 以下です。

要件検証システムの設計。

設計要件ごとに、設計パラメータと要件で指定されたパラメータの対応を評価するためのアルゴリズムがあります。 一般に、どのような制御システムにも、要件をチェックするためのアルゴリズムがデフォルトで常に含まれています。 そして、どんなレギュレーターにもそれらは含まれています。 温度が限界を超えると、エアコンがオンになります。 したがって、規制の最初の段階は、パラメーターが要件を満たしているかどうかを確認することです。

また、検証はアルゴリズムであるため、制御プログラムの作成に使用するものと同じツールを使用できます。 たとえば、SimInTech 環境では、モデルのさまざまな部分を含むプロジェクト パッケージを作成し、別個のプロジェクト (オブジェクト モデル、制御システム モデル、環境モデルなど) の形式で実行できます。

この場合の要件検証プロジェクトは同じアルゴリズムプロジェクトとなり、モデルパッケージに接続されます。 また、動的モデリング モードでは、技術仕様の要件に準拠するための分析が実行されます。

システム設計の考えられる例を図 1 に示します。

図 1. 検証プロジェクトの設計例。

制御アルゴリズムと同様に、要件も一連のシートとして作成できます。 SimInTech、Simulink、AmeSim などの構造モデリング環境でのアルゴリズムの操作を容易にするために、サブモデルの形式でマルチレベル構造を作成する機能が使用されます。 この構成により、制御アルゴリズムの場合と同様に、さまざまな要件をセットにグループ化して、一連の要件の処理を簡素化することができます (図 2 を参照)。

図 2. 要件検証モデルの階層構造。

たとえば、検討中のケースでは、環境に対する要件とシステムに対する直接的な要件の XNUMX つのグループが区別されます。 したがって、XNUMX レベルのデータ構造が使用されます。つまり、それぞれがアルゴリズムのリーフである XNUMX つのグループです。

データをモデルに接続するには、プロジェクトの部分間で交換するためのデータを保存する信号データベースを生成するための標準スキームが使用されます。

ソフトウェアを作成およびテストする場合、制御システムで使用されるセンサー (実際のシステム センサーのアナログ) の測定値がこのデータベースに保存されます。
テスト プロジェクトの場合、動的モデルで計算されたパラメーターはすべて同じデータベースに保存できるため、要件が満たされているかどうかを確認するために使用できます。

この場合、動的モデル自体は、任意の数学モデリング システムで実行することも、実行可能プログラムの形式で実行することもできます。 唯一の要件は、モデリング データを外部環境に発行するためのソフトウェア インターフェイスの存在です。

図 3. 検証プロジェクトを複雑なモデルに接続する。

基本的な要件検証シートの例を図 4 に示します。開発者の観点から見ると、これは要件検証アルゴリズムがグラフィカルに示された従来の計算図です。

図 4. 要件チェックシート。

チェックシートの主要部分を図5に示します。チェックアルゴリズムは制御アルゴリズムの設計図と同様に作成されます。 右側には、データベースから信号を読み取るためのブロックがあります。 このブロックは、シミュレーション中に信号データベースにアクセスします。

受信した信号を解析して要件検証条件を算出します。 この場合、航空機の位置 (駐機中か飛行中か) を決定するために高度解析が実行されます。 この目的のために、他の信号とモデルの計算されたパラメーターを使用できます。

チェックされる検証条件とパラメータは標準検証ブロックに転送され、そこでこれらのパラメータが指定された要件に準拠しているかどうか分析されます。 結果は、チェックリストの自動生成に使用できる方法で信号データベースに記録されます。

図5. 要件検証計算シートの構成

テストされるパラメータは、データベースに含まれる信号を必ずしも使用する必要はなく、シミュレーション プロセス中に計算されたパラメータによって制御されます。 検証条件を計算するのと同様に、要件草案の枠組み内で追加の計算を実行することを妨げるものはありません。

たとえば、次の要件があります。

目標への飛行中に補正システムを作動させる回数は 5 回を超えてはならず、補正システムの合計動作時間は 30 秒を超えてはなりません。

この場合、要件の設計図に起動回数と総稼働時間に対抗するアルゴリズムを追加します。

典型的な要件検証ブロック。

各標準要件のチェック ボックスは、特定の種類の要件の充足度を計算するように設計されています。 たとえば、環境要件には、駐機中および飛行中の周囲動作温度の範囲が含まれます。 このブロックはモデル内の気温をパラメーターとして受け取り、このパラメーターが指定された温度範囲をカバーするかどうかを判断する必要があります。/p>

このブロックには、param とcondition という XNUMX つの入力ポートが含まれています。

最初のものには、チェックされるパラメータが供給されます。 この場合は「外気温」です。

ブール変数が XNUMX 番目のポートに提供されます。これは、チェックを実行するための条件です。

1 番目の入力で TRUE (XNUMX) が受信された場合、ブロックは要件検証計算を実行します。

0 番目の入力が FALSE (XNUMX) を受け取った場合、テスト条件は満たされません。 これは計算条件を考慮するために必要です。 この例では、この入力はモデルの状態に応じてチェックを有効または無効にするために使用されます。 シミュレーション中に航空機が地上にある場合、飛行に関連する要件はチェックされません。逆も同様です。航空機が飛行中の場合、待機中の操作に関連する要件はチェックされません。

この入力は、計算の初期段階など、モデルを設定するときにも使用できます。 モデルが必要な状態になるとチェック ブロックは無効になりますが、システムが必要な動作モードに達するとすぐにチェック ブロックがオンになります。

このブロックのパラメータは次のとおりです。

• 境界条件: チェックする必要がある範囲の上限 (UpLimit) と下限 (DownLimit)。
• 境界範囲で必要なシステム露出時間 (TimeInterval) (秒単位)。
• リクエストID ReqName;
• 範囲超過の許容性 Out_range は、チェックされた範囲を超える値が要件に違反するかどうかを決定するブール変数です。

場合によっては、テスト値の出力は、システムにある程度のマージンがあり、動作範囲外で動作している可能性があることを示しています。 他の場合、出力はシステムが設定値を範囲内に維持できないことを意味します。

図 6. 図の典型的なプロパティ チェック ブロックとそのパラメータ。

このブロックの計算の結果、出力で Result 変数が形成され、次の値が取られます。

• 0 – rNone、値は定義されていません。
• 1 – r完了、要件は満たされています。
• 2 – rFault、要件が満たされていません。

ブロック イメージには次のものが含まれます。

• 識別子のテキスト。
• 測定限界パラメータのデジタル表示。
• パラメータステータスの色の識別子。

ブロック内には、かなり複雑な論理推論回路が存在する可能性があります。

たとえば、図 6 に示すユニットの動作温度範囲を確認するために、内部回路を図 7 に示します。

図 7. 温度範囲決定ユニットの内部図。

回路ブロック内では、ブロック パラメーターで指定されたプロパティが使用されます。
ブロックの内部図には、要件への適合性の分析に加えて、シミュレーション結果の表示に必要なグラフが含まれています。 このグラフは、計算中の表示と計算後の結果の分析の両方に使用できます。

計算結果はブロックの出力に送信され、同時にプロジェクト全体の結果に基づいて作成される一般的なレポート ファイルに記録されます。 (図8参照)

シミュレーション結果に基づいて作成されるレポートの例としては、所定のフォーマットに従って作成されたhtmlファイルが挙げられます。 フォーマットは、特定の組織で受け入れられるフォーマットに任意に設定できます。

回路ブロック内では、ブロック パラメーターで指定されたプロパティが使用されます。
ブロックの内部図には、要件への適合性の分析に加えて、シミュレーション結果の表示に必要なグラフが含まれています。 このグラフは、計算中の表示と計算後の結果の分析の両方に使用できます。

計算結果はブロックの出力に送信され、同時にプロジェクト全体の結果に基づいて作成される一般的なレポート ファイルに記録されます。 (図8参照)

シミュレーション結果に基づいて作成されるレポートの例としては、所定のフォーマットに従って作成されたhtmlファイルが挙げられます。 フォーマットは、特定の組織で受け入れられるフォーマットに任意に設定できます。

図 8. シミュレーション結果に基づくレポート ファイルの例。

この例では、レポート フォームがプロジェクト プロパティで直接構成され、テーブル内の形式がグローバル プロジェクト信号として設定されます。 この場合、SimInTech 自体がレポートのセットアップの問題を解決し、結果をファイルに書き込むためのブロックがこれらの行を使用してレポート ファイルに書き込みます。

図 9. グローバル プロジェクト シグナルでのレポート形式の設定

要件に対する信号データベースの使用。

プロパティ設定の作業を自動化するために、標準的なブロックごとに信号データベースに標準構造が作成されます。 (図10参照)

図 10. 信号データベース内の要件チェック ブロックの構造の例。

信号データベースは以下を提供します。

• 必要なシステム要件パラメータをすべて保存します。
• 指定されたパラメータと現在のモデリング結果から既存のプロジェクト要件を簡単に表示できます。
• スクリプト プログラミング言語を使用して、XNUMX つのブロックまたはブロックのグループをセットアップします。 信号データベースの変更は、図内のブロック プロパティ値の変更につながります。
• テキストの説明、技術仕様項目へのリンク、または要件管理システムの識別子を保存します。

要件の信号データベース構造は、サードパーティの要件管理システムと連携するように簡単に構成できます。要件管理システムとの相互作用の一般的な図を図 11 に示します。

図 11. 要件管理システムとの対話の図。

SimInTech テスト プロジェクトと要件管理システム間の対話のシーケンスは次のとおりです。

1. 委託条件は要件に分類されます。
2. 技術仕様の要件は、技術プロセスの数学的モデリングによって検証できるように特定されます。
3. 選択した要件の属性は、標準ブロックの構造で SimInTech 信号データベースに転送されます (最高温度と最低温度など)。
4. 計算プロセス中に、構造データがブロック設計図に転送され、解析が実行され、結果が信号データベースに保存されます。
5. 計算が完了すると、分析結果は要件管理システムに転送されます。

要件のステップ 3 ～ 5 は、設計プロセス中に設計や要件に変更が発生し、変更の影響を再テストする必要がある場合に繰り返すことができます。

結論。

• 作成されたシステムのプロトタイプにより、技術仕様の要件に準拠するために既存のモデルを分析する時間が大幅に短縮されます。
• 提案されたテスト技術は既存の動的モデルを使用し、SimInTech 環境で実行されない動的モデルを含むあらゆる動的モデルにも使用できます。
• バッチデータ編成を使用すると、モデル開発と並行して要件検証パッケージを作成したり、これらのパッケージをモデル開発の技術仕様として使用したりすることもできます。
• このテクノロジーは、多額のコストをかけずに既存の要件管理システムと統合できます。

最後まで読んでいただいた方には、 プロトタイプがどのように動作するかを示すビデオへのリンク。

出所： habr.com