適切に構造化された堅牢なモデル: AnyLogic モデリングのワークショップ

暗い灰色の背景にジェンガ

何ヶ月も複雑なモデルに取り組んできて、ほぼ準備ができたときに、クライアントから大幅な変更を加えてほしいと頼まれたときを想像してください。追加の作業、再構築、そして当初そこに存在する予定ではなかったものを適合させなければなりません。

このような状況を回避する方法、または少なくともダメージを軽減する方法はあるのでしょうか? その答えは、柔軟性の余地を残し、シミュレーションを完全に制御できる強固なモデル基盤にあります。

突然の変更を実装する必要があるときに崩れないようにシミュレーション モデルを構築する方法は、十数年の経験を持つシミュレーションの専門家である Dr. Benjamin Schumann のワークショップの焦点でした。AnyLogic のグローバル カンファレンスで発表され、現在はオンラインで共有されているこのワークショップは、あらゆるスキル レベルを対象とした、堅牢なモデルの構築方法に関する詳細なガイドです。

このブログ投稿は、最新の How to Structure Your Models So They Never Crumble ワークショップの概要を説明したもので、ファクトリ モデルの例を使用して、初心者、上級者、および超上級者向けの AnyLogic ユーザー向けに技術的な詳細を詳しく掘り下げています。

コンテンツ:

基本:ビジュアル構造と埋め込みエージェント

AnyLogic を使い始めたばかりの人は、キャンバス上で要素をドラッグ アンド ドロップするだけでモデルを構築する傾向があります。簡単かつ迅速なので、小規模なプロジェクトに適している可能性があります。ただし、大規模で複雑なモデルの場合、Ben 氏は、最初に強固な基盤を築くという、時間はかかりますがより安全な方法を取ることを提案しています。

モデル要素をキャンバス上に積み上げる代わりに、エージェントごとに以下のようなカラフルな長方形にモデル要素をグループ化できます。これらの四角形の上で各エージェント タイプが何を行うかを定義することもできます。例えば、Main エージェントは実際のモデルを保持してデータを処理することしかできません。

モデル要素が書かれた 4 つのカラフルな長方形
モデル要素のグループ化

ほとんどの AnyLogic ユーザーが次に行うことは、Mainエージェントでモデル ロジックを直接構築することです。ただし、Ben の提案は、これを Model という別のエージェントに置き、その後 Model に埋め込むことです。これらすべてにより、プロジェクトの後半で透明性と柔軟性がもたらされます。

エージェントに対する柔軟性と制御をさらに高めるには、単一のエージェント タイプではなく、最初は空のエージェントの集団を常に作成する必要があります。

AnyLogic でモデル母集団を作成するためのウィンドウ
AnyLogic でのモデル母集団の作成

ワークショップの工場シミュレーションの例では、製品と機械という 2 つのエージェントが動作します。Ben は、それらのそれぞれについて、Model 内に個別のエージェントを作成します。ここでのもう 1 つの提案は、エージェント ステートチャートを使用して Main で単純な階層スキームを描画することです。そうすることで、モデル内のエージェント間の関係を追跡するのに役立ちます。

AnyLogic のモデルの階層を表すステートチャート
モデルの階層を表すステートチャート

モデルの健全性チェックとその他のエージェント階層のトリックについては、ビデオのこのセクションでまとめられています。

スキルの向上: 一般的なフローチャートとオブジェクト指向プログラミングの概念

ユーザーはモデル ロジックを Main に配置する傾向があるため、大規模で複雑なプロジェクトでは乱雑になり、エラーが発生しやすくなる可能性があります。プロセスモデリング フローチャートを簡素化する 1 つの方法は、反復的なブロック シーケンス用の カスタム フローチャート ブロックを作成することです。もう 1 つの解決策は、フローチャートの異なる部分がそれぞれのエージェントに配置されるようにフローチャートを分割することです。2 つ目についてさらに詳しく見てみましょう。

工場シミュレーションの例に戻って、マシン エージェント (A_Machine) と製品エージェント (A_Product) が独自のフローチャートを持っているとします。製品は 1 台ずつマシンを訪問し、各製品には訪問する必要があるマシンの to-doリストがあります。

このプロセスを開始するために、Ben はまず、モデルの実行時に機械や製品が作成される順序を制御できる関数を作成します。次に、エージェントを指定するパラメータを設定します。オブジェクト指向プログラミングのカプセル化原理に従って、各エージェントに対して個別にこれを行う方法は、将来的に役立つでしょう。状況によってモデルの変更が必要になった場合でも、コードを大規模に書き直す必要がなくなります。

各エージェントが独自のフローチャートを持っている場合、これはシステムとしてどのように機能するのでしょうか?

製品が工場に到着し、最初の機械に送られて処理されます。

AnyLogic での製品処理フローチャート
Main の製品のフローチャート

その後、しばらく処理されて、次のマシンに移動するか、工場から出荷されます:

AnyLogic でマシンが製品をどのように処理するか示すフローチャート
Machine エージェントでマシンが製品をどのように処理するか示すフローチャート

機械が製品の処理を完了し、工場から出荷されるように設定すると、製品は MainSink ブロックに送信されます。

AnyLogic で製品が処理後に工場からどのように出荷されるかを示すフローチャート
製品が処理されて工場から出荷されるまでを説明するフローチャート

スキルの向上: 一般的な KPIとアニメーション

優れたモデリングの重要な原則の 1 つは、ロジックを視覚化から分離することです。この原則に従って、Ben は、対応するエージェント (この例では A_MachineA_Product) を監視し、それらのパフォーマンスをグラフの形式で知らせる個別のエージェントを作成することを提案しています。これにより、一般的な KPI を完全に制御し、エージェントのアクティビティを測定する際の間違いを回避し、ロジック エージェントの計算をより効率的にすることができます。

ここで、Java マジックをひとつまみ、スパイ エージェントを作成し、そのパラメータと関数を設定するだけで実現できます。最後に、マシンの KPI を表示する方法を Main に理解させるために、さらに Java コードを使用する必要があります。

更新された階層を表すモデル ステートチャート
UI_Machine エージェントによるモデル階層の更新

アニメーションに関しては、単純なルールを適用できます。モデルに移動するオブジェクトがある場合、アニメーションをロジック エージェントに直接設定します。それ以外の場合は、スパイエージェントに設定します。

さらなる前進: ダッシュボードとデータ処理

統計を表示するさまざまなスパイ エージェントがあるので、それらを Dashboard という新しいエージェントにグループ化して、必要なダッシュボードを柔軟に作成できるようにしてはどうでしょうか? たとえば、マシンのグラフのみを表示し、ダッシュボード上の実際のアニメーションを配置する正確な場所を選択することができます。

ダッシュボードにさらにエージェント タイプ (製品など) を追加したい場合は、別のパラメータ、エージェントの母集団 (pop_UI_Product)、および製品を作成する関数を作成するだけです。次に、ダッシュボードを見やすい位置に配置します。

Dashboard エージェント自体は Main に埋め込まれ、アニメーションを起動する関数を作成する必要があります。

更新された階層を表すモデル ステートチャート
UI_Dashboard エージェントによるモデル階層の更新

ワークショップの締めくくりに、Ben がモデル データのロードと保存に関するヒントを共有します。優れたモデリングの一般原則はデータをモデルから分離することですが、彼の提案は、それをさらに一歩進めて、Model inputs の間に追加のレイヤーを置くことです。なぜ彼はこのアプローチが強力だと感じたのでしょうか?

実際のデータは乱雑で時間の経過とともに変化する可能性があるため、モデルを実行し続けるには適切にフォーマットされたクリーンなデータが必要です。ここで Model 入力層が行うことは、データをモデルに変換して、常に処理済みの入力を処理できるようにすることです。

したがって、実際のデータ構造が変更された場合でも、この Model 入力層にわずかな変更を加えるだけで、モデルは引き続き機能します。その影響は感じられないでしょう。

これを機能させるには、まず Excel スプレッドシートにデータを追加する必要があります。次に、各データ構造 (マシンなど) に対して POJO (plain old Java object) と呼ばれる Java クラスを作成し、Java コードを使用して構造を複製します。

Excel のデータ構造
Excel のデータ構造
Java コードのデータ構造
Java コードのデータ構造

次のステップは、InputData という Java クラスを作成することです。このクラスは、一方では Excel ファイルからデータをロードし、他方ではテスト用に新しいデータを作成します。

AnyLogic の InputData の Java コード
特定の Excel ファイルからデータをロードするインスタンスと、事前に作成されたデータを含む別のインスタンスを作成する InputData のコード

これで、Model エージェントの入力データ (そのためのパラメータを使用) によってモデルを定義できるようになりました。そのため、たとえば工場の機械にさらに特性を追加する必要がある場合、そのために何十もの新しいパラメータを作成する必要はありません。 

Main では、エージェントのアクションを正しく設定する必要があります。モデルを開始すると、Main は最初にデータをロードし、次にモデルとそのエージェントを作成し、最後にオプションのステップであるアニメーションを起動する必要があります。 

重要なポイントとワークショップのビデオ

このワークショップのコツとアプローチは、実装が簡単ではないように見えるかもしれませんが、モデルを柔軟に制御できるようになり、大規模で複雑なプロジェクトでは不可欠になります。

要約すると、このワークショップから得た 4 つの重要なポイントは次のとおりです:

  1. 初心者の場合は、Model に埋め込まれたエージェントとして Main を使用してください。
  2. もう少し上級の場合は、エージェントと関数のカプセル化を開始してください。エージェントはパラメータを介して指定され、関数は引数を介して指定されることに注意してください。
  3. アニメーションをモデルのロジックから分離します。他のエージェントのパフォーマンスを追跡するスパイ エージェントを作成します。動的アニメーション プロパティは必要ありません。スパイ エージェントがあり、それらを時々更新するだけで済みます。
  4. 実際のデータをモデルから分離するだけでなく、間に Model 入力層を入れてください。このアプローチにより、クライアントのデータから独立し、モデルがより堅牢になります。

How to Structure Your Models So They Never Crumble ワークショップを視聴し、より優れたシミュレーション モデリングの実践方法を学びましょう。




月刊ニュースレターを購読していただくと、最新のブログ投稿をお届けします。

関連記事