Simulink コンポーネントのタイプの検討
Simulink® には、モデルをコンポーネントに整理する方法が複数あります。Simulink コンポーネントのタイプによって、ターゲットとなる要件が異なります。
Simulink コンポーネントを定義するときは、以下の潜在的な要件について検討します。
ファイルの競合 — 各コンポーネントの作業を行うのが 1 人だけである場合はコンポーネントを大きくすることができます。複数の人がコンポーネントを共有する必要がある場合は、設計を小さい論理的な単位に分割しなければなりません。複数の人が同じファイルを編集しなければならない場合は、比較レポートでのモデル変更の移植または復元を参照してください。
再利用性 — モデル内でブロックのグループを複数回使用する予定がある場合は、そのブロックのグループを再利用可能なコンポーネントに定義します。重複を防ぐことで、モデルをより簡単に保守できます。重複のある既存のモデルをリファクタリングするには、モデルのリファクタリングによるコンポーネントの再利用の向上 (Simulink Check)を参照してください。
コード生成 — 物理コンポーネント (デジタル コントローラーなど) 用のスタンドアロン コードを生成しなければならない場合は、物理コンポーネントを表し、適切に定義されたインターフェイスをもつ 1 つのコンポーネントが必要です。
検証コスト — モデルのある部分が頻繁に変更され、多額のテスト費用がかかる場合、モデルのこの部分をコンポーネントとして別のファイルで管理しなければなりません。コンポーネントが別々のファイルで定義されている場合、プロジェクトのソース管理を使用して変更を管理および追跡できます。ソース管理の詳細については、構成管理を参照してください。
シミュレーション速度 — 数値特性の異なるコンポーネントに異なるソルバーを使用すると、シミュレーション速度が高速化する可能性があります。同様に、サンプルレートに基づいてブロックをグループ化することでシミュレーション速度が高速化する可能性があります。詳細については、ソルバー プロファイラーおよびパフォーマンス アドバイザーを使用したシミュレーション パフォーマンスの改善を参照してください。
モデル化要件はコンポーネントのサイズに影響します。たとえば、ブロック数が 500 未満のモデルは、それよりも大きいモデルよりも簡単にテストできます。ただし、参照モデルに 500 を超えるブロックが含まれている場合、モデルの階層構造に対するシミュレーションは高速になる可能性があります。
Simulink コンポーネント
Simulink コンポーネントのさまざまなタイプが、多様なモデル化要件に対応します。
| モデル化要件 | コンポーネントのタイプ | コンテンツのソース | モデルでの実装 | 詳細 |
|---|---|---|---|---|
| 他のコンポーネントのブロック線図の単純化 | サブシステム "サブシステム" はその入力と出力のプロパティを継承できるダイナミックなインターフェイスを備えたブロックの一意のグループです。 | なし — コンテンツを各サブシステムに手動で追加しなければなりません。 | Subsystem ブロック
| サブシステムへのブロックのグループ化 |
| ユーティリティとブロックセットの格納 | リンクされたサブシステム "リンクされたサブシステム" はライブラリに格納されている Subsystem ブロックのリンクされたインスタンスです。ライブラリ リンクを無効にすると、リンク付きブロックの各インスタンスが一意になります。 | 親ライブラリ ブロックまたはプロトタイプ ブロックが含まれるライブラリ ファイル ( | ライブラリ リンクをもつ Subsystem ブロック
| リンク付きブロック |
| コードの再利用、ユニット テスト、およびファイルの競合とマージの問題の削減 | サブシステム参照 "サブシステム参照" は入力と出力のプロパティを継承できるダイナミックなインターフェイスを備えたブロックの再利用可能なグループへの参照です。 | 参照サブシステムが含まれるサブシステム ファイル ( | Subsystem Reference ブロック
| モデルでの参照サブシステムの作成と使用 |
| コードの再利用、単体テスト、並列ビルド、大きなコンポーネント | モデル参照 "モデル参照" はその入力と出力のプロパティを指定する定義済みのインターフェイスを備えたモデルへの参照です。 | 保護モデルとなる場合もある参照モデルが含まれるモデル ファイル ( | Model ブロック
| モデル参照の動作と機能 |
複数のタイプのコンポーネントで同じ要件に対処できます。たとえば、モデル参照でファイル競合とマージの問題を削減し、サブシステムを単体テストできます。
Simulink モデルでは、これらのコンポーネントを組み合わせて使用できます。たとえば、大きなモデルのファイル競合を最小限に抑える場合は、サブシステムを参照サブシステムと参照モデルに変換することで、どちらも別のファイルに保存されます。
サブシステム参照またはモデル参照をライブラリからモデルにドラッグすると、モデルはコンテンツを定義するサブシステム ファイルまたはモデル ファイルを直接参照します。親ライブラリ ブロックに直接適用されたマスクがある場合にのみ、モデルはライブラリ リンクをもちます。通常は、参照ファイルに保存され、ライブラリ リンクを必要としないモデル マスクを使用しなければなりません。
高水準のコンポーネント選択ガイドライン
このフロー チャートは、コンポーネント タイプを選択するにあたっての開始点を提供します。
ヒント
サブシステムが大きくなることが予期される場合は、サブシステムがブロックを機能的にグループ化するように、サブシステムを Atomic にします。Atomic サブシステムは、親モデルの実行時に単一ブロックまたはアトミック単位のように動作します。サブシステムをモデル参照に変換するには、Atomic な動作が必要です。
次の表に、コンポーネント タイプを選択するためのフロー チャートの情報を示します。
| コンポーネントの用途 | コンポーネントのタイプ |
|---|---|
| コンポーネントは、別のファイルを使用せずに、モデル内で機能的に関連するブロックをグループ化する。 | サブシステムを検討します。 |
コンポーネントはパブリッシュされたユーティリティであり、ほとんど変化がない。 | リンクされたサブシステムを検討します。 |
| コンポーネントは、親モデルのコンテキストに合わせてインターフェイスを適応させることができ、物理端子の接続、ユニット テスト、およびテスト ハーネスを使用した再利用可能なコード生成をサポートする。 | サブシステム参照を検討します。 |
コンポーネントは、定義されたインターフェイスまたはスタンドアロンの動作を必要とするか、参照モデルのアクセラレータ モード シミュレーションによる利点が得られるほど頻繁に再利用される。コンポーネントで、コード生成および知的財産の保護もサポートする。 | モデル参照を検討します。 |
モデルの階層構造が参照モデルのアクセラレータ モード シミュレーションからメリットが得られるかどうかは、多くの要素によって異なります。アクセラレータ モードでシミュレーションを実行する参照モデルごとに、Simulink でシミュレーション ターゲットをビルドしコンパイルする必要があります。これらのターゲットは参照モデルの追加のインスタンスで再利用され、それにより、モデルの階層構造に参照モデルのさまざまなインスタンスが含まれる場合に、シミュレーションが高速化されます。参照モデルが変更されない場合、Simulink キャッシュ ファイル (.slxc) に格納されているそのシミュレーション ターゲットを再利用できます。詳細については、シミュレーションを高速化するための Simulink キャッシュ ファイルの共有を参照してください。
各種コンポーネント化手法を使用するタイミングの概要については、Component-Based Modeling in Simulink (4 分 28 秒) を参照してください。
モデル化要件の考慮事項
高水準のガイドラインに基づいてコンポーネントを実装する前に、追加のモデル化要件について検討してください。たとえば、コンポーネント インターフェイスで物理的接続が必要な場合、サブシステム、リンクされたサブシステム、または参照サブシステムを使用する必要があります。知的所有権保護が必要な場合、参照可能な保護モデルを作成する必要があります。
コンポーネントがモデル化要件を満たすかどうかを判断するには、Simulink コンポーネントの機能の比較を参照してください。
