Main Content

このページの翻訳は最新ではありません。ここをクリックして、英語の最新版を参照してください。

Requirements Table

入力条件を使用した形式的要件のモデル化

R2022a 以降

このページをすべて展開する
  • Requirements Table block icon.

ライブラリ:
Requirements Toolbox

説明

Requirements Table ブロックは、形式的要件をモデル化します。ブロックは、[前提条件] 列にリストされている条件の評価から始まります。条件が満たされている場合、他のシミュレーション データが [事後条件] 列の指定された条件を満たすかどうかを確認したり、[アクション] 列の目的のアクション (ブロック出力または関数など) を実行したりできます。詳細については、Requirements Table ブロックを使用した形式的要件の作成を参照してください。

[仮定] タブで仮定を定義すれば、モデルの物理的な制限に基づいて要件を制約することもできます。要件への仮定の追加を参照してください。

このブロックは、Requirements Toolbox™ がある場合にのみ設定できます。

例

電気自動車充電器のロック機構の形式的要件についての解析

電気自動車充電器のロック機構の形式的要件についての解析

Requirements Table ブロックと Simulink® Design Verifier™ を使用して、電気自動車充電ステーションのロック機構の形式的要件を作成、解析、更新する。

ライブ スクリプトを開く
Define Formal Requirements with a Duration

Define Formal Requirements with a Duration

Define formal requirements that use a duration.

ライブ スクリプトを開く
要件に基づくテストに対する仕様モデルの使用

要件に基づくテストに対する仕様モデルの使用

要件に対して設計モデルを検証する体系的なアプローチに従います。

ライブ スクリプトを開く

端子

入力

すべて展開する

入力端子。スカラー、ベクトル、または行列として指定します。定義した各入力データには対応する入力端子が含まれます。

依存関係

入力端子を作成するには、[シンボル] ペインでブロックを開き、入力データを作成します。Requirements Table ブロックのデータの定義を参照してください。

データ型: single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | string | fixed point | enumerated | bus

出力

すべて展開する

出力端子。スカラー、ベクトル、または行列として指定します。定義した各出力データには対応する出力端子が含まれます。

依存関係

出力端子を作成するには、[シンボル] ペインでブロックを開き、出力データを作成します。Requirements Table ブロックのデータの定義を参照してください。

データ型: single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | string | fixed point | enumerated | bus

パラメーター

すべて展開する

メイン

Requirements Table ブロック アイコンの端子ラベルの表示方法を選択します。

  • なし – 端子ラベルは表示されません。

  • FromPortIcon – 入力データと出力データの名前が表示されます。

  • FromPortBlockName – 入力データと出力データの名前が表示されます。

  • SignalName – 端子に接続されている信号に名前がついている場合、その信号名が表示されます。それ以外の場合、データの名前が表示されます。

プログラムによる使用

パラメーター: ShowPortLabels
型: string スカラーまたは文字ベクトル
値: "none" | "FromPortIcon" | "FromPortBlockName" | "SignalName"
既定の設定: "FromPortIcon"

Requirements Table ブロックの内容へのユーザー アクセスを制御します。

  • ReadWrite – Requirements Table ブロックの内容を開いて変更できます。

  • ReadOnly – Requirements Table ブロックを開くことができます。

  • NoReadOrWrite – Requirements Table ブロックを開くことも変更することもできません。

メモ

[読み取り/書き込みアクセス許可] パラメーターが [NoReadOrWrite] になっている Requirements Table ブロックの内容を表示しようとしても、ブロックは応答しません。たとえば、Requirements Table ブロックをダブルクリックすると、Simulink でテーブルの内容は開かれず、メッセージは表示されません。

プログラムによる使用

パラメーター: Permissions
型: string スカラーまたは文字ベクトル
値: "ReadWrite" | "ReadOnly" | "NoReadOrWrite"
既定の設定: "ReadWrite"

シミュレーション中、Atomic サブシステムを含む疑似代数ループの消去を試みます。

  • オフ – Atomic サブシステムを含む疑似代数ループの消去を試みません。

  • オン – Atomic サブシステムを含む疑似代数ループの消去を試みます。

プログラムによる使用

パラメーター: MinAlgLoopOccurrences
型: string スカラーまたは文字ベクトル
値: "off" | "on"
既定の設定: "off"

このブロックのエントリが同じレートで実行される必要があるか、または別のレートで実行できるかを指定します。

  • Requirements Table ブロックのエントリが異なるレートで実行できる場合、サンプル時間は継承 (-1) として指定します。

  • エントリを同じレートで実行する必要がある場合は、このレートに応じてサンプル時間 Ts を指定します。

プログラムによる使用

パラメーター: SystemSampleTime
型: string スカラーまたは文字ベクトル
値: "-1" | "[Ts 0]"
既定の設定: "-1"

コードの生成

これらのパラメーターを有効にするには、Simulink Coder™ または Embedded Coder® が必要です。

ブロックが Atomic (非バーチャル) サブシステムに対するコードの生成に使用するコードの形式を選択します。

  • 自動 – Simulink Coder および Embedded Coder は、モデル内の Requirements Table ブロックのインスタンスのタイプと数に基づいて最適なコード形式を選択します。

  • インライン – Simulink Coder および Embedded Coder は Requirements Table ブロックを無条件でインライン化します。

  • 再利用できない関数 – Simulink Coder は個々の関数を別個のファイルに明示的に生成します。

  • 再利用可能な関数 – Simulink Coder と Embedded Coder は、モデルがブロックのインスタンスを複数含む場合、ブロックのコードの再利用を可能にする、引数をもつ関数を生成します。

    このオプションが生成する別の関数の引数により、参照モデル全体にわたる Requirements Table ブロックの複数のインスタンスを含むモデル参照階層の生成コードで、Requirements Table ブロックの再利用が可能になります。この場合、ブロックはライブラリに含まれている必要があります。

ヒント

  • Requirements Table ブロックの複数のインスタンスを 1 つの再利用可能な関数として表す場合、インスタンスをそれぞれ [自動] または [再利用可能な関数] として指定できます。それらのどちらか一方を使用するのが最適です。両方を使用すると、各指定につき 1 つずつ、2 つの再利用可能な関数が作成されます。これらの選択の結果は、再利用が不可能な場合にのみ異なります。[自動] を選択しても、Requirements Table ブロック コードの関数やファイル名は制御できません。

  • [再利用可能な関数] と [自動] のオプションは両方とも、Requirements Table ブロックのインスタンスが複数存在するかどうかと、コードが再利用可能かどうかを判定しようとします。これらのオプションは、再利用が不可能な場合にのみ次のように異なります。

    • [自動] はインライン化されたコードを生成します。インライン化が禁止されている場合は、Requirements Table ブロックのインスタンスごとに別の関数を生成します。

    • [再利用可能な関数] は、モデル内の Requirements Table ブロック インスタンスごとに、引数をもつ別の関数を生成します。

  • 生成されたコードがソース管理対象であるときに [再利用可能な関数] を選択する場合、[ファイル名オプション] を [サブシステム名を使用]、[関数名を使用]、または [ユーザー指定] に設定します。そうしないと、モデルを変更するたびにコード ファイルの名前が変更され、ファイルのソース管理ができません。

プログラムによる使用

パラメーター: RTWSystemCode
型: string スカラーまたは文字ベクトル
値: "Auto" | "Inline" | "Nonreusable function" | "Reusable function"
既定の設定: "Auto"

Simulink Coder がブロックに生成する関数に名前を付ける方法を選択します。

Embedded Coder がある場合は、コンフィギュレーション パラメーター [コード生成] 、 [識別子] ペインのオプションを使用して関数名を管理できます。

  • 自動 – 既定の命名規則 model_block() を使用して一意の関数名を割り当てます。ここで、model はモデルの名前、block はブロックの名前 (または、コードが再利用されている場合は同一のものの名前) です。

  • サブシステム名を使用 – Requirements Table ブロックを関数名として使用します。既定では、関数名は命名規則 model_block を使用します。

    メモ

    Requirements Table ブロックがライブラリ ブロックにあり、[関数のパッケージ化] パラメーターが [再利用可能な関数] に設定されている場合、[サブシステム名を使用] オプションを設定すると、コード ジェネレーターはその関数名とファイル名に対してライブラリ ブロックの名前を使用します。

  • [ユーザー指定] – [関数名] フィールドを有効にします。有効な C または C++ 関数名を入力します。この名前は一意であることが必要です。

詳細については、サブシステム コードを別々の関数およびファイルとして生成 (Simulink Coder)を参照してください。

依存関係

このパラメーターを有効にするには、[関数のパッケージ化] を [再利用できない関数] または [再利用可能な関数] に設定します。

プログラムによる使用

パラメーター: RTWFcnNameOpts
型: string スカラーまたは文字ベクトル
値: "Auto" | "Use subsystem name" | "User specified"
既定の設定: "Auto"

ブロック コードの関数の名前

自動生成された名前またはブロック名を使用するのではなく、関数に特定の名前を付ける場合はこのパラメーターを使用します。詳細については、サブシステム コードを別々の関数およびファイルとして生成 (Simulink Coder)を参照してください。

依存関係

このパラメーターを有効にするには、[関数名オプション] パラメーターを [ユーザー指定] に設定します。

プログラムによる使用

パラメーター: RTWFcnName
型: string スカラーまたは文字ベクトル
値: "" | "<function name>"
既定の設定: ""

Simulink Coder がブロックに対して生成する関数の個々のファイルに名前を付ける方法。

  • 自動 – ブロックの構成とモデル内のインスタンス数に応じて、[自動] は異なる結果を返します。

    • コード ジェネレーターがブロックに個別のファイルを生成 "しない" 場合、ブロックの親システムから生成されたコード モジュール内で、ブロック コードが生成されます。ブロックの親がモデルそのものである場合、ブロック コードは model.c または model.cpp 内で生成されます。

    • [関数のパッケージ化] パラメーターで [再利用可能な関数] を選択し、生成されたコードがソース管理対象である場合は、[ファイル名オプション] の値に [自動] 以外の値を指定することを検討してください。これにより、生成されたファイル名が関係のないモデル変更によって変更されるのを防止できます。ファイル名の変更は、ソース管理を使用して構成を管理する場合に問題となる点です。

    • [関数のパッケージ化] パラメーターで [再利用可能な関数] を選択し、モデル参照階層内にブロックの複数のインスタンスがある場合、そのブロック用に再利用可能なコードを生成するには、[ファイル名オプション] を [自動] に設定しなければなりません。

  • サブシステム名を使用 – コード ジェネレーターは、ブロック名をファイル名として使用して別のファイルを生成します。

    メモ

    [ファイル名オプション] が [サブシステム名を使用] に設定されているときに、モデルに Model ブロックが含まれている場合、またはモデル参照のターゲットがモデルに対して生成されている場合、ブロック ファイルが変更されます。このような状況では、Requirements Table ブロックのファイル名はモデル名を接頭辞とするブロック名で構成されます。

  • 関数名を使用 – コードジェネレーターは、[関数名オプション] で指定された関数名をファイル名として使用します。

  • ユーザー指定 – このオプションは、[ファイル名 (拡張子なし)] テキスト入力フィールドを有効にします。コードジェネレーターは、入力した名前をファイル名として使用します。ファイル名は入力しても、.c または .cpp (あるいは別の) 拡張子は含めないでください。このファイル名は一意でなくても構いません。

    メモ

    Requirements Table ブロックのソース ファイル名は一意でなくても構いませんが、循環的な依存状態となるような一意でない名前を付けることは避ける必要があります (sys_a.h が sys_b.h を含み、sys_b.h が sys_c.h を含み、sys_c.h が sys_a.h を含むなど)。

依存関係

このパラメーターを有効にするには、[関数のパッケージ化] を [再利用できない関数] または [再利用可能な関数] に設定します。

プログラムによる使用

パラメーター: RTWFileNameOpts
型: string スカラーまたは文字ベクトル
値: "Auto" | "Use subsystem name" | "Use function name" | "User specified"
既定の設定: "Auto"

生成されたファイルの名前。指定するファイル名は、一意である必要はありません。ただし、循環的な依存状態 (sys_a.h が sys_b.h を含み、sys_b.h が sys_c.h を含み、sys_c.h が sys_a.h を含むど) になるような一意でない名前を付けることは避けてください。

詳細については、サブシステム コードを別々の関数およびファイルとして生成 (Simulink Coder)を参照してください。

依存関係

このパラメーターを有効にするには、[ファイル名オプション] を [ユーザー指定] に設定します。

プログラムによる使用

パラメーター: RTWFileName
型: string スカラーまたは文字ベクトル
値: "" | "<file name>"
既定の設定: ""

拡張機能

バージョン履歴

R2022a で導入

参考

トピック