コンポーネントベースのモデル化のガイドライン

コンポーネント化は、さまざまな機能の部分から構成される Simulink^® モデルを開発する組織にメリットをもたらします。モデルコンポーネントを使用することで、以下が可能になります。

チームベースの開発 — 適切に定義されたインターフェイスによってファイル競合を軽減し、コンポーネントを個別に詳細化します。
設計の複雑度を低減 — 比較的小さい問題をコンポーネントごとに解決します。
コンポーネントの再利用 — プロジェクト内および複数のプロジェクト間でアルゴリズムと環境モデルを再利用します。
単体テスト — 変更されていないコンポーネントの再テストを排除し、検証にかかるコストを削減します。
その規模でのパフォーマンス上のメリット — メモリ使用量を削減し、モデルの読み込みとシミュレーションに要する時間を短縮します。
コンポーネントバリアント — コンポーネントの複数の実装から選択します。
知的所有権保護 — サードパーティと共有するコンポーネントの機能とコンテンツの可視性を制限します。

モデルコンポーネントを作成する必要性

コンポーネントの定義と管理に必要な作業について考えると、メリットがコストを上回る場合にのみコンポーネントベースのモデル化を使用すべきです。

既存の Simulink モデルを複数のコンポーネントに分割することは、大きなコード (C、Java^®、または MATLAB^® コード) を取得して、いくつかの関数に分けることと似ています。設計がもともとモジュール化されていない場合、この変換にはかなりの作業と大規模な変更が必要になる可能性があります。

モデルのスケーラビリティと潜在的な要件を事前に考慮すると、Simulink モデルをより簡単にコンポーネントに分割できるようになります。コンポーネントを事前に特定することで、次の問題を回避できます。

不適切なコンポーネント定義 — サブシステムの範囲が経時的に増大することで、コンポーネントの要件を満たすことができない可能性があります。たとえば、サブシステムに含まれる機能の数が多すぎたり少なすぎることが原因で再利用できなかったり、従来の機能と統合するコードを生成できなかったり、ハードウェアインザループテストをサポートできない場合があります。
マージ競合 — 元々 1 人のエンジニアが開発を行うために設計されていたモデルに対して、別のエンジニアが作業を開始すると、マージに時間がかかったり、エラーが発生しやすくなる場合があります。
代数ループ — 1 人のエンジニアがボトムアップ方式でモデルを開発する場合、モデルの複雑度が上がるにつれて、ブロックをサブシステムにグループ化する可能性が高くなります。モデル内のサブシステムは視覚的にグループ化するようなものであり、モデルの実行に影響を与えません。これらのサブシステムを Atomic にするか、サブシステムを参照モデルに変換する場合、診断や修正が困難な、望ましくない代数ループが発生する可能性があります。

設計が複雑になり過ぎて、1 人ですべての詳細を管理することができない場合にも、コンポーネントが役立ちます。たとえば、複雑なモデルとは次のようなものをもつモデルです。

数千のブロック
数百の論理判定
同じ機能に対する複数のバリアントコンフィギュレーション

プロジェクトおよびソース管理はコンポーネントの管理に役立ちます。詳細については、プロジェクトとはおよび構成管理を参照してください。

モデルコンポーネントの定義

1. モデルコンポーネントのタイプの検討	高水準のモデル化要件に合致している Simulink コンポーネントを特定します。
2. モデルコンポーネントの機能の比較	低水準のモデル化要件を満たすモデルコンポーネントのタイプを調査します。
3. モデルコンポーネントのインターフェイスの定義	インターフェイスで設計属性を構成し、モデルコンポーネントのデータを管理します。