大規模 Simulink モデルの構築におけるベスト プラクティスの適用

システムの規模と複雑さが増すにつれて、エンジニアリング チームは、小規模では存在しない一連のまったく新しい課題に直面します。

ほとんどの場合、規模の大幅な拡大には、範囲だけでなく種類の面でもアプローチの変更が必要になります。この原則は、モデルベース デザインで作業する場合、Simulink^® モデルにも当てはまります。ベスト プラクティスに従わないと、単純な概念実証モデルから数十万のブロックを持つ大規模モデルに移行するときに、モデル アーキテクチャ、データ管理、インターフェイス、ファイル管理、シミュレーション パフォーマンスの低さなど、さまざまな問題が発生し始めます。これらの大規模モデルの基本ブロックは小さなものが多く、しばしば異なる個人、チーム、さらには部門によって開発されています。標準化が行われ、ベストプラクティスが遵守されていれば、これらのモデルはスムーズに拡張できます。

この記事では、 Simulinkで大規模で複雑なモデルを操作するときによく発生する課題を管理するための一連のベスト プラクティスについて説明します。このトピック自体は非常に広範囲にわたるため、ここでの目標は、詳細で規範的なガイダンスを提供することではなく、各ベスト プラクティスの基本と、その適用方法をより深く理解するために活用できるその他のリソースへのリンクを紹介することです。

モデルのコンポーネント化におけるモデル参照の使用

顧客と仕事をしていると、意味のあるコンポーネント化が欠如した大規模なモデルを目にすることは珍しくありません。チームはアイデアをテストするためにシンプルなモデルから始めますが、時間が経つにつれて新しい要素や機能が追加され、すべての作業が単一構造のモデル ファイルで行われるため、すぐに扱いにくくなります。

Simulink では、大規模なモデルをコンポーネント化する方法がいくつかあり、最適なアプローチは検討中の特定のユースケースによって異なります。例えば、ブロックやコンポーネントのグループを視覚的に整理したいだけのチームは、モデル内仮想サブシステムを選択することができます。一方、広く使用されるユーティリティを作成し、頻繁に変更する必要がないチームにとっては、リンクされたサブシステム (またはライブラリ) の方が適した選択肢となります。コンポーネントをスタンドアロンモデルとして開発またはシミュレーションすることが目的であれば、モデル参照が最適なアプローチとなります。

モデル参照は、大規模モデルのコンポーネント化の鍵でもあります。その理由の 1 つは、 Simulinkのモデル参照により、チームが独立したモデルとしてコンポーネントを並行して開発できることです。各コンポーネントは完全に機能し、シミュレーション可能であり、独自の SLX ファイルに保存されるため、各チームは他のチームの作業に干渉することなく独立して作業できます。これは設計全体が 1 つのファイルに取り込まれている場合はほぼ不可能です。同様に重要なのは、これらの独立した参照モデルをより大きなモデル内に配置して簡単に統合できることです (図 1)。このアーキテクチャでは、参照モデルのキャッシュされたインスタンスとインクリメンタル ビルドを使用してビルド時間を短縮できます。また、アクセラレーターモードやラピッドアクセラレーターモードの使用も可能になり、これについては後述のパフォーマンスのセクションで詳しく説明します。

データ ディクショナリによるデータ管理のスケールアップ

コンポーネント化の問題を引き起こした同じシナリオを再考してみましょう。チームは、概念実証の初期段階としてシンプルなモデルから開始し、時間をかけてそれを詳細化していきます。単純なモデルの場合、多くのエンジニアは変数、パラメーター、その他のデータをベースワークスペースに保存します。このアプローチは、非公式のワークフロー、迅速なパラメーター調整、ラピッドプロトタイピング、単一開発者プロジェクト、またはパラメーターの普遍的な可視性を必要とするユースケースに適しています。ただし、モデルの範囲と複雑さが増すにつれて、データ管理にベース ワークスペースに依存することにはいくつかの欠点が生じます。たとえば、ベースワークスペースはエンジニアがセッションを終了するたびにクリアされるため、MATLAB^® コード (.m) や MATLAB ファイル (.mat) として手動で保存する必要があります。

データディクショナリは、大規模モデルを扱うプロジェクトや分散開発、スコープ内のデータの管理の場合、ベースワークスペースよりも適しています。これにはいくつかの理由があります (図 2 を参照)。1 つ目はデータの永続性です。データはデータ ディクショナリ (.sldd) ファイル内の特定のファイル形式で保存されるため、チームはモデルやベース ワークスペースとは別にデータを定義、管理、更新できます。2 番目に、チームはデータを複数の辞書に分割して、データの整理をさらに改善できます。3 番目に、データ ディクショナリは変更追跡ワークフローで効果的に機能します。このワークフローでは、チームはどのような変更が行われたか、いつ行われたか、誰が行ったかを確認でき、必要に応じて以前のバージョンに戻すこともできます。

ここで重要なのは、ベース ワークスペースとデータ ディクショナリのどちらを使用するかの選択は、すべてまたは何もしないというものではないということです。2 つのアプローチは共存できるため、チームは時間の経過とともにベース ワークスペースから 1 つ以上のデータ ディクショナリに徐々に移行できます。

バスを使用したインターフェイスの簡略化

コンポーネント化された階層型モデルでサブシステムを接続する場合、最初は、あるコンポーネントから別のコンポーネントに渡される各要素に個別の信号線を使用するのが最も簡単な方法のように思えるかもしれません。もちろん、これは単純なインターフェースには有効ですが、このアプローチはすぐに、必要以上に複雑かつ煩雑で管理が難しいモデルを生み出す可能性があります。

Simulink では、バスを使用することで、一連の信号 (または要素) を単一の線で表現できるため、インターフェースを簡略化し、煩雑さを軽減できます。これは複数のワイヤを束ねるのと同様の概念です。この価値は簡単な例で簡単にわかります。バッテリー システムの異常な状態を識別するための故障検出コンポーネントを検討します。このコンポーネントには、最大および最小セル電圧、最大および最小セル温度、コンタクタの状態、パックの電圧と電流、電流制限など、11 種類の入力があります。11 個の個別の入力ポートを持つコンポーネントを作成することは確かに可能ですが、入力を論理グループに分割し、各グループにバスを使用する方がきれいです。たとえば、セル電圧信号とセル温度信号はすべて同じコンポーネントから発生し、すべて関連しているため、これらを 1 つの 4 要素バスにグループ化することは理にかなっています (図 3)。明らかに、これは比較的些細な例ですが、バスを使用してコンポーネント インターフェイスだけでなく、より広義には複雑なモデルを簡略化する方法を示しています。

プロジェクトによるファイル管理の改善

これまでに概説したベスト プラクティスに従うことによる副作用の 1 つは、管理する必要があるファイルの数が増加することです。設計全体が単一のモデルである場合、チームが管理する必要があるファイルのセットは比較的小さくなりますが、コンポーネント化とデータ ディクショナリが積極的に使用されると、急速に増加する可能性があります。ファイル管理戦略がなければ、ファイルの急増が問題になる可能性があります。

Simulink で作業する際、チームはプロジェクトを活用してファイル管理の作業を自動化することができ、モデリング、シミュレーション、その他の高付加価値な活動により多くの時間を費やすことができます。たとえば、プロジェクトを設定する際、チームはプロジェクトパス内のフォルダを指定します。これらのフォルダーは、プロジェクトを開いたときに検索パスに追加され (プロジェクトを閉じると削除されます)、プロジェクトのすべてのユーザーがフォルダー内のファイルにアクセスできるようになります。チームは、プロジェクトの環境設定を自動化する起動ファイルや、設定手順を元に戻して環境をクリーンアップするシャットダウンファイルを指定することもできます。さらに、プロジェクトは、起動時に頻繁に使用するファイルを開いたり、よく使用するタスクのショートカットを作成したりするように構成できます。

プロジェクトは、チームがよくある間違いを避けるのにも役立ちます。たとえば、複雑なモデルの階層構造では、同じ名前の 2 つのモデル ファイルが異なるディレクトリに存在することは珍しくありません。プロジェクトを使用する際、エンジニアは優先順位の低いファイルが検出されたことを知らせる警告を受け取ります。また、プロジェクトが終了すると、エンジニアは保存されていない変更を保存するように求められるため、作業の損失を防ぐことができます。

最後に、プロジェクトはソース管理を効率化し、更新、コミット、プッシュ、プル、フェッチなどの一般的な操作をユーザーインターフェースから直接アクセスできるようにします (図 4)。

シミュレーションパフォーマンスの最適化

これまで取り上げてきたベスト プラクティスは、主に大規模なモデルの構造とそれに関連するデータやファイルに焦点を当てたものでした。これらのベスト プラクティスを実装したお客様は、会話の中でよくシミュレーション パフォーマンスの向上について次のような質問をされます。「今や大規模なモデルをより優れた方法で構築できるようになったが、どうすればそのシミュレーション時間を短縮できるのか」。

シミュレーション パフォーマンスを向上させるためのツールがいくつかあります。最初のステップとして、シミュレーションに時間がかかる要因となっている構成設定を特定するために、一連のチェックを実行するパフォーマンスアドバイザーをお勧めします。次に、初期設定の MATLAB コード (たとえば、コールバック内) を含むモデルについては、MATLAB が最も多くの時間を費やしている部分を特定するために、MATLAB のプロファイラー アプリを実行する方が良いでしょう。Simulink プロファイラーは、モデルの実行時間を評価し、シミュレーション パフォーマンスの低下に寄与している可能性のある問題を特定します。最後に、可変ステップソルバーを使用しているチームには、ソルバー プロファイラーを実行することをお勧めします。これにより、ソルバーの動作が分析され、ソルバーのリセットや異常に小さいタイムステップなどの潜在的な問題が特定され、それらを解決するための推奨事項が提供されます。これらのツールの使用方法やタイミングなどに関するガイダンスは、トラブルシューティングとシミュレーション パフォーマンスの高速化ガイドに記載されています (表を参照)。

大規模モデルをコンポーネント化したチームは、アクセラレータモードまたはラピッドアクセラレータモードを使用してシミュレーションの速度を向上させることができます。これらのモードは、通常 Simulink シミュレーションで使用されるインタープリター型コードを生成コードに置き換えます。モデルの初期化中に、 Simulink はコードがすでに生成されているコンポーネントのキャッシュをチェックします。このインクリメンタル ビルド プロセスでは、前回のシミュレーション以降に変更されたコンポーネントのみを再構築してキャッシュに追加する必要があるため、多数のコンポーネントを含む大規模なモデルの初期化時間が大幅に短縮されます。

初期化時間を短縮するもう一つの方法は、特にモデルを反復的にシミュレーションする場合、高速リスタートを使用することです。チームがモデルに構造的な変更を加えずに複数のシミュレーションを実行する場合、高速リスタートにより、モデルをコンパイルせずにシミュレーションを実行し、そのたびにシミュレーションを終了することで、プロセスを高速化できます。代わりに、最初のシミュレーションでモデルがコンパイルおよび初期化され、その後の各シミュレーションでモデルの動作点のスナップショットがキャプチャされます (図 5)。

結論として、エンジニアリング チームがSimulinkモデルのスケーリングの複雑さに対処する際には、ベスト プラクティスを順守することが不可欠になります。この記事では、モデルのコンポーネント化、データ管理、パフォーマンスの最適化に不可欠な戦略を概説し、モデル開発に対する構造化されたアプローチの重要性を強調しました。パフォーマンス アドバイザー、 MATLABプロファイラー、ソルバー プロファイラーなどのツールを活用することで、チームはシミュレーション パフォーマンスを強化し、生産性を向上させることができます。これらのプラクティスにより、大規模モデルの管理性、効率性、適応性が維持されます。モデルベース デザインの環境が進化し続ける中、これらのガイドラインは、チームがますます複雑化するエンジニアリングの課題の要求を満たす堅牢なモデルを構築するのに役立ちます。さらに詳しく知りたい場合は、このホワイト ペーパーを通して紹介されているその他のリソースやトレーニングの機会を活用することをお勧めします。

この記事の内容は、MathWorks Automotive Conference で発表された「コンポーネントから複雑なシステムまで、大規模モデル構築のためのベスト プラクティス」という講演 (この講演に関する「詳細情報」、Web セミナー、トレーニングを参照) に基づいています。冒頭で述べたように、これは 1 つの記事や講演で網羅的に扱うことのできない広大なトピックです。