リストについての主要な概念
リストの概要
リスト（グローバルリストと呼ばれることもあります）とは、より複雑なフローを3Dオブジェクト間に作成する際に使用できるツールです。ただし、リストには3Dモデル内のアイテムのフローをコントロールする以外にも多くの目的があることに注意してください。
- コネクションレスルーティング - ポートの代わりにリストを使用して固定リソースのフローを接続できます。これは、多対多ルーティングを行う必要がある場合など、ポート接続を使用すると管理が複雑になり、使用が困難になる場合に特に役立ちます。
- フローアイテムのフィルタリング - リストでは、アイテムの待機期間、アイテムのタイプ、アイテムのラベルの値など、複雑なルールセットを使用してフローアイテムをフィルタリングし、優先度付けできます。固定リソースがリストからアイテムをプルする準備ができると、リストはその検索基準と優先度に一致するアイテムを検索します。たとえば、プロセッサは、値が50より大きく、weightというラベル名が含まれるアイテムをリストからプルできます。このリストは、待機時間が最長またはキューに入っていた時間が最長のフローアイテムに優先度を付けることもできます。
- タスク管理 - ディスパッチャーオブジェクトの代わりにリストを使用して、タスクをタスク実行者に割り当てることができます。リストでは、指定したタスクシーケンスを受け取るタスク実行者（またはその逆）に優先度を付けることができます。リストによって、特定の基準を満たすタスク実行者のみが特定のタスクシーケンスの作業に割り当てられる（またはその逆）ように指定することもできます。
- 固定リソースの優先度付け - 固定リソースをリストに入れて、フローアイテムを処理する固定リソースに優先度を付けることもできます。
次の例では、最初のキューはフローアイテムを［利用可能な製品］というリストに入れます。アイテムは、プロセッサによってリストからプルされるまでキューで待機します。プロセッサは、アイテムタイプのクエリに一致するアイテムをプルします。たとえば、Processor1はタイプ1のアイテムのみをプルします。Processor2はタイプ2のアイテムのみをプルします。
リストの仕組み
週末の混んでいるレストランを想像してください。通常、お客様が来店するとスタッフは順番待ちリストに名前を記入します。このスタッフは、そのお客様グループの人数に合ったテーブルがないかどうかレストランを確認します。お客様の名前がリストの一番上に来て、そのグループの人数に合ったテーブルをスタッフが確認すると、お客様はそのテーブルの席に着きます。
この処理はFlexSimにおけるリストの仕組みとよく似ています。この処理は、何かがアイテム、タスク、3Dオブジェクトをリストにプッシュすると開始されます。たとえば、フローアイテムがキューに入ると、キューはフローアイテムをリストにプッシュできます。そのアイテム/タスク/オブジェクトは、リストエントリとみなされます。リストでは、アイテム/タスク/オブジェクトがリストに待機している期間や、それに関連付けられたラベルなど、各リストエントリに関するデータを追跡できます。このデータを使用して、最初にリストからプルされるリストエントリを決定するカスタムロジック（クエリと呼びます）を作成できます。
最終的には、別のオブジェクト（下流の固定リソースやタスク実行者など）がリストからアイテム/タスク/オブジェクトのプルを試みます。このオブジェクトには、必要なアイテム/タスク/オブジェクトのタイプに関する追加の条件または制限が適用されている場合があります。このリストは、固定リソースまたはタスク実行者に最も一致するリストエントリを決定します。一致が見つかると、固定リソースまたはタスク実行者は、一致するアイテム/タスク/オブジェクトをリストからプルします。
リストで不均衡を管理する方法
リストに多くのアイテム/タスク/オブジェクトがあり、リストからプルできるオブジェクトが不足している場合、リストエントリはプルされるまでリストで待機します。
その逆の場合はどうなるでしょうか。リストからプルする必要のあるオブジェクトが多くあるのに、その要件を満たすだけの十分なリストエントリがない場合はどうなるでしょうか？
レストランの例に戻り、来客の少ない日にレストランに行くことを想像してください。来客の少ない日は、多くのテーブルが空いています。このシナリオの場合、テーブル側にお客様が必要です。レストランのスタッフは、空いているテーブルの図を使用しています。お客様が来店すると、スタッフはテーブルがお客様グループの人数に合っているかどうかや、テーブルセクションの準備が整っているかどうかなど、いくつかの異なる優先度に基づいてお客様を通すテーブルを決定します。
同じように、固定リソースまたはタスク実行者は、一致するアイテム/タスク/オブジェクトがリストに存在しない場合に、リストからプルを試みることがあります。これが発生すると、リストはバックオーダーを作成します。バックオーダーとは、対応する必要があるリストエントリのオープンリクエストです。新しいアイテム/タスク/オブジェクトがリストにプッシュされると、リストはそれを評価して、いずれかのバックオーダーを満たすことができるかどうかを確認します。
リストの構造は抽象的で論理的
リストを文字どおりに理解すべきではない点に注意してください。ビジネスシステムにリストのような正式なメカニズムがないからといって、シミュレーションモデルで使用しないわけではありません。リストとは、ビジネスシステムの基礎となる暗黙のロジックを再現するのに役立つ抽象的な構造であることを覚えておいてください。
たとえば、決まった時間に実行する必要があるすべてのタスクを行うだけの十分な従業員がいない可能性や、処理が必要なアイテムに十分なワークステーションがない可能性など、ビジネスシステムのリソースが限られている状況があります。これらのシナリオでは通常、優先すべきタスクやアイテムを判断するメカニズムが用意されています。単純なFIFO（先入れ先出し）ロジックに加えて何らかの論理システムを使用している場合、リストはシミュレーションモデルでこの種のロジックを再現できます。
アイテム/タスク/オブジェクトがリストにプッシュされても、文字どおりリストに入れられるわけではないという点にも注意してください。たとえば、リストにアイテムをプッシュするキューオブジェクトをモデルに含めることができます。これによりアイテムが物理的または文字どおりリストに配置されるわけではありません。3Dアイテムオブジェクトはキューに残ります。その代わり、そのアイテム/タスク/オブジェクトへの参照がリストに追加されます。これは、レストランでお客様が待っている間、レストランのスタッフが順番待ちリストに名前を記入するのと似ています。
プッシュされたものは必ずプルする
リストを設計する際に留意すべき主要な概念の1つは、「プッシュされたものは必ずプルする」ことです。アイテム、タスク、オブジェクトがリストにプッシュされた場合、そのアイテム、タスク、オブジェクトがシミュレーションの実行中に後でリストからプルされる方法が必要です。アイテム、タスク、オブジェクトをリストからプルするイベントまたはメカニズムの設計を含めないと、それらは無期限にリストで待機します。したがって、何かをリストにプッシュする機能を作成するたびに、それをリストからプルする機能も必ず作成してください。
リストの特徴と主な用語
シミュレーションの実行中にリストのエントリを表示すると、次の画像のようなエントリが表示されます。
リストエントリ
アイテム、タスク、オブジェクトがリストにプッシュされると、そのリストのエントリになります。
値
リストエントリの値は、指定されたリストエントリに関連付けられた一次識別子です。通常、値はリストにプッシュされたアイテム、タスク、オブジェクトへの参照になります。前画像の例では、値はシミュレーションモデルの3つの異なるキュー内のボックスへの参照です。
ただし、リストの設定方法によっては、値は数値、文字列、ノード参照にすることもできます。
フィールド
フィールドは各リストエントリについて追跡すべきデータを指定します。このデータを使用して、最初にリストからプルされるリストエントリを決定するカスタムロジック（クエリと呼びます）を作成できます。クエリはプルすべきリストエントリの制限やフィルタリングもできます。
前画像の例には、3つのフィールドがあります。
- itemType - 各ボックスのアイテムタイプを示します
- age - ボックスがリストで待機している期間を追跡します
- queueSize - 現在このボックスのキューに入っているボックスの合計を表示します
この例では、最長のキューにあり、リストに留まっている期間が最短/最長のボックスに優先度を付けるリストクエリを作成できます。この基準を満たすボックスが最初にリストからプルされます。また、特定のアイテムタイプのボックスだけがプルされるようにクエリを制限することもできます。
FlexSimは、リストにプッシュされているオブジェクトのタイプに応じて、さまざまなデータを追跡するように事前に構築されています。事前に構築されたデータを使用することも、カスタムラベルでデータを追跡することもできます。FlexScriptに慣れている場合は、独自のカスタム式を作成してカスタムデータを作成できます。最終的に、効果的なリストクエリを作成するために必要なフィールドと追跡する必要のあるデータを決定するのはユーザー自身です。
フィールド値
フィールド値は、指定された時点で指定されたリストエントリに対する各フィールドの現在のデータを表示します。前画像の例で、ageフィールドにはボックスがリストで待機しているシミュレーション時間単位の長さが表示されます。このリストによると、最初のキューのボックスが最長である6.81時間単位にわたり待機しています。
リストのタイプ
リストを初めて作成するときに、作成するリストのタイプを決定する必要があります。リストのタイプは5つあります。
- 固定リソースリスト
- アイテムリスト
- タスクシーケンスリスト
- タスク実行者リスト
- 全般リスト
主にリストに何がプッシュされるのかに基づいてリストのタイプを選択します。たとえば、フローアイテムをリストにプッシュする場合は、アイテムリストを選択します。タスクをリストにプッシュする場合は、タスクシーケンスリストを選択します。リストに何をプッシュするのかわからない場合は、全般リストを選択してください。
リストタイプは本当に重要かどうか
リストを作成するうえで最も重要な点の1つは、各リストエントリに関するデータを追跡するのはリストのフィールドであるため、リストのフィールドを選択することです。フィールドとは、リストアイテムをフィルタリングして優先度を付けるクエリの作成に使用する構築ブロックです。
選択するリストのタイプは、リストのプロパティウィンドウの［フィールド］タブで、そのタイプのリストで使用可能な事前に構築されたフィールドのタイプに影響します。また、デフォルトでそのリストに含まれるフィールドにも影響します。任意のリストタイプで使用可能なフィールドを簡単に追加、削除、カスタマイズできます。
選択すべきリストのタイプについて心配する必要はありません。タイプに関係なく、最終的にすべてのリストが同じ機能を持ちます。間違ったタイプのリストを選択しても、そのリストを変更し、他のタイプのリストで使用可能な事前構築されたフィールドを使用できます。
グローバルリストとローカルリスト
リストがグローバルリストとローカルリストのどちらとみなされるかは、どの程度アクセス可能であるかによって決まります。ほとんどのリストはグローバルにアクセス可能です。つまり、特定のシミュレーションモデル内のすべてのオブジェクトがアイテム/タスク/オブジェクトをリストにプッシュまたはプルできます。一方、ローカルリストはシミュレーションモデル内でオブジェクトの特定のインスタンスにのみアクセスできます。処理フローツールを使用して、シミュレーションモデルの異なるインスタンスを設定できます。詳細については、以下のトピックおよびチュートリアルを参照してください。
リストのパーティション
必要に応じて、リストを複数のパーティションに分割できます。パーティションは、パーティションIDと呼ばれるいくつかの識別要因に基づいてリストをコンパートメントに分割する方法です。たとえば、フローアイテムすべてにtypeという名前のラベルがあるとします。このラベルの値は1～10の範囲で指定できます。typeラベルはパーティションIDとして機能する可能性があります。タイプ1のアイテムはパーティション1に入り、タイプ2のアイテムはパーティション2に入る、などです。
カスタムラベルの値やリスト内のフィールドに基づいてパーティションを作成することもできます。パーティションIDには、数値、文字列のほか、ツリー内のオブジェクトまたはノードへの参照を指定できます。パーティションは、まだ存在しないパーティションに値をプッシュするとパーティションが自動で作成されるという点で動的です。
「プッシュされたものは必ずプルする」というルールは、パーティションにおけるプッシュとプルにも適用されることに注意してください。シミュレーションモデルで何かが何かをパーティションにプッシュしたら、シミュレーションの実行中に後でそのパーティションからそれをプルする必要があります。