メインコンテンツまでスキップ

よくある質問 (FAQ)

このドキュメントには、SWAT API に関するよくある質問のリストが含まれています。

最適化および Integration API (Optimization and Integration API)​

このセクションには、Optimization API api および Integration API api に関連する質問と回答が含まれています。

GET /api/v1/node_scheduler/{job_id}/status に対するさまざまな応答は何ですか？ 計算がまだ実行中の場合、およびエラーが発生した場合の応答は何ですか？​

回答

エンドポイント api は、status フィールドで非同期ジョブに関連する3つのステータスを提供します。

  • PENDING: 計算が進行中であることを示します。
  • FAILED: 計算に失敗したことを示します。
  • SUCCESS: 計算に成功したことを示します。

コンシューマーは、このエンドポイントを定期的に（約5秒ごとに）ポーリングし、PENDING 状態が SUCCESS または FAILED に移行するまで待つ必要があります。その後、エンドポイント api を使用して結果を取得できます。

ソルバーパラメータ time_limit_ms の計算時間には何を設定する必要がありますか？ このパラメータの単位は何ですか？​

回答

単位はミリ秒です。推奨される計算時間は、車両と注文の数、およびそれらの複雑さによって異なります。通常、計算時間は、問題の規模と必要なソリューションの品質に応じて、2分から60分の範囲にする必要があります（計算時間が長いほど、通常はより良い結果が得られます）。api

ピックアップまたはドロップオフされた注文の数に関係なく、サービス時間が同じままであるサービス時間を設定するにはどうすればよいですか？​

回答

ノードのグループに固定サービス時間を指定するには、モデルパラメータ api オブジェクトの compound_zones を使用できます。Compound zones (複合ゾーン)

は、他のプロパティの中でも、そのゾーンに進入または退出するために必要な enter_time と exit_time を秒単位で指定したゾーンのリストです。

積み込み港で同じ固定稼働時間を設定するには、uid が loading port 1 または loading port 2 に設定されているリクエスト本文の node オブジェクトに対して次の設定を使用します。

{
  "compound_zones": [
    {
      "node_uids": ["loading port 1", "loading port 2"],
      "exit_time": 300
    }
  ]
}

次の図は、ノード

に適用される時間パラメータを表しています。compound zone 時間は、ゾーンへの進入/退出に必要な最小時間に基づいてルートの最適化を確実にするために移動時間に追加されるため、車両ノードの割り当て（slack と比較して）に直接反映されません（ノードの固定時間制約である service time と比較してください）。

Driver break scenarios

ノードと車両間の需要と容量のモデルは何ですか？ 複数の次元がある場合、どのように設定すればよいですか？​

回答

需要とは、特定の顧客または場所に配達する必要がある商品またはサービスの量を指します。容量とは、車両が運ぶことができる商品、サービス、または人々の最大量を指します。 車両容量は、1台の車両で満たすことができる需要の量の制限として機能します。車両はその容量を超える量を運ぶことはできないため、ルートに割り当てられた総需要は常に車両の容量以下でなければなりません。 需要は車両とルートの必要性を促進します。すべての顧客にわたる総需要によって、必要な車両の数と、需要を効率的に満たすためにそれらの車両をルーティングする方法が決まります。

VRP アルゴリズムは、実行可能で効率的なソリューションを作成するために、容量と需要のバランスを慎重にとる必要があります。目標は、容量の制約を尊重しながら、移動距離、時間、コストを最小限に抑える方法で、顧客を車両とルートに割り当てることです。

予約を作成するとき、ノードタイプ pickup は正の需要を持ち、dropoff は負の需要を持ちます。需要タイプは任意の文字列ですが、少なくとも1台の車両の需要タイプは、少なくとも1つのノードの容量タイプと一致する必要があります。そうしないと、この需要タイプが車両に割り当てられることはありません。 ノードと車両の次元の一貫性を維持することをお勧めします。ノードに車両に存在しない追加の次元がある場合、予約はその車両に割り当てることができません。

"node":
{
  "demand": {
      "goods": 1,  // Node expects 1 piece of goods delivered
      "human": -1  // Node expects 1 human picked up
  }
}

"vehicle":
{
  "capacity":{
    "goods":10, // Vehicle can carry 10 pieces of good
    "human":20, // Vehicle can carry 20 human beings
    "rat":30 // Vehicle can carry 30 rats
  }
}

可能な限り午後3時までに配達を優先するにはどうすればよいですか？​

回答

配達ウィンドウは、ノードの open_time_ts と close_time_ts によって制御されます。この例では、ドロップオフノードの close_time_ts api を午後3時に設定できます。デフォルトでは時間枠は厳密な制約であるため、これにより一部の予約が割り当てられない場合があります。あるいは、allow_vehicle_late フラグを使用して close_time_ts を前に進めることで、優先順位付けを実現できます。api

同じ場所にある複数の注文に対して、ドロップオフポイントでの荷降ろし時間が尊重されるようにするにはどうすればよいですか（予定出発前に荷降ろし）？​

回答

回答は、例としていくつかの任意のタイムスタンプを想定しています。

問題ステートメントは次のように定式化できます。

  • すべての注文は午後12時までに荷降ろしする必要があります
  • すべての注文は同じ場所で荷降ろしする必要があります
  • 各注文にはある程度の荷降ろし時間が必要です（たとえば、注文1、2、3の場合は5分、10分、15分）
  • 場所は午前11時から午後12時の間に注文を受け入れることができます

注文を集約できない場合は、node.close_time_ts api を 午後12時 - 注文3のサービス時間（この例では具体的には午前11時45分）に調整して、最後の注文に十分な荷降ろし時間を確保できます。注文3はサービス時間が最も長いため、調整用に選択されます。これにより、注文3を荷降ろしするのに十分な時間が提供され、ノードは午後12時に閉じるため、それ以降は他の注文は受け入れられません。その結果、注文1と注文2の荷降ろしは、注文3の前にスケジュールされます。正確な順序は時間枠の特定の長さによって異なることに注意してください。ただし、同じ場所であるため、ルート最適化の観点から運用上の目的にとって重要である可能性は低いです。

Driver break scenarios

ルートが最適化された後、車両のすべてのノード/ウェイポイントを取得するにはどうすればよいですか？​

回答

目的の結果に応じて、車両のノードを取得する方法は複数あります。

  • 単一の車両に割り当てられたノード（車両が訪問する予定のポイントのシーケンス）を取得するには、/api/v2/vehicle/{vehicle_id}/assigned_nodes api を使用してください。
  • 単一の車両の完了したノードを取得するには、/api/v2/vehicle/{vehicle_id}/completed_nodes api を使用してください。
  • シミュレーション内のすべての車両の完了および割り当てられたノードを取得するには、/api/v2/node?simulation={{simulation_id}}&status__in=completed,assigned api を使用してください。

API /api/v2/vehicle/{vehicle_id}/nodes_grouped api のノードグループ化はどのように機能しますか？​

回答

次の例を検討してください。

  • node_grouping_threshold : 5分
  • ノード A: 7:00
  • ノード B: 7:05
  • ノード C: 7:07, サービス時間5分
  • ノード D: 7:16, サービス時間5分
  • ノード E: 7:27 4つのノードすべてが同じ場所にあると仮定すると、クエリはノード A から D までの単一のグループを生成します。グループ化ロジックはノードに必要なサービス時間を尊重するため、ノード D は同じグループになります。 (7:27-7:26)>(5分+5分サービス時間) であるため、タイムスタンプが 7:23 の別のノード E が追加されると、ノード E は別のグループに割り当てられます。

車両とドライバーはどのオブジェクトに割り当てられていますか？ 予約がどの車両に割り当てられているかを確認するにはどうすればよいですか？​

Details

回答 booking、vehicle、driver の間には暗黙的な関係があります。車両とドライバーは、予約ではなく node に割り当てられます。この場合、ノード は、車両が行く必要のある物理的な場所を表します。各予約には、少なくとも2つのノード（ドロップオフノードとピックアップノード）が関連付けられている必要があります。api。移動中にアイテムまたは人が車両間で移動されない単純なシナリオの場合、予約のすべてのノードには同じドライバーと車両が割り当てられます。

予約状態 fail_to_board と fail_to_deliver の違いは何ですか？​

Details

回答 ドライバーが予約の最初のノードでピックアップを行わなかった場合、予約 は fail_to_board とマークされます。したがって、配達するものは何もありません。その場合、この予約は次の実行計画では考慮されません。ただし、ドライバーが商品を配達できた場合、予約状態は fail_to_deliver に設定されます。これは、商品がまだ車両にあり、商品に関連する制約（需要やグループなど）を満たす必要があることを意味します。

max_slack パラメータは何を意味しますか？​

Details

回答 ノードの max_slack パラメータは、そのノードで許可される スラック の最大量を指定します。そのノードでスラックを排除することが目標である場合は、0に設定できます。API このパラメータを慎重に使用してください。他の制約（ノードの時間枠など）を満たすために必要な場合にスラックをゼロにする必要があると、そのノードの割り当てが妨げられます。この値を構成すると、ドライバーの休憩の割り当て方法にも影響します。

予約が fail_to_board または fail_to_deliver としてマークされた場合、ノードはどうなりますか？​

Details

回答 予約をピックアップできない場合、fail_to_board としてマークでき、その後の計算では単に無視されます（ピックアップされた車両に商品や乗客がいないため、ドロップオフするものはありません）。ただし、fail_to_deliver はより複雑です。車両にはまだ商品が残っており、そのための容量制約に対応する必要があるためです。その場合、予約/ノードはまだ車両に割り当てられています（fail_to_board 予約は車両から割り当て解除されます）。ドライバーは、プランナーが再最適化を行うのと同時に node_status を送信できます。

フィルタ式および/またはラベルで条件を使用する例を提供してください​

回答

次の例は、vehicle labels を使用するためのいくつかのオプション、または Django クエリ文字列の JSON 形式に従ったフィルタリング式を表しています。

Examples

'1' AND '2' AND '3'

{"and": ["1", "2", "3"]}

'1' OR '2' OR '3'

{"or": ["1", "2", "3"]}

'1' AND ('2' OR '3') AND NOT ('4' AND '5')

{"and": [{"or: ["2", "3"]}, {"not": {"and": ["4", "5"]}}]}

車両をアップロードしましたが、車両のリストに表示されませんか？​

Details

回答 project_id または project 値がない（またはこれらの値が null に設定されている）車両は表示されません。SWAT モデルは承認にプロジェクトを使用します。シミュレーション内の車両であっても、プロジェクトに関連付けられていない場合はアクセスできません。

すべて正しく設定されているにもかかわらず、注文が拒否されます（オファーがありません）​

Details

回答 この問題を解決するために、低ソルバーレベルでのいくつかの設定を使用できます。これは通常、ソルバーが最初の非常に早い段階で実行可能な初期ソリューションを見つけられない場合に発生します。多くの場合、大規模な VRP 問題（1000以上のノード）に対して不適切なヒューリスティックが選択されていることが原因です。これに対処するには、FSS パラメータを 調整 し（たとえば、3、16、17、8 などの値を使用）、use_local_search_metaheuristic 設定を無効にし、ラムダ係数を0.95に増やしてみてください。 これは、シミュレーション レベルでも実行できます。

ライブ運用中に注文のライブ挿入を行おうとしていますが、（すでに割り当てられているものを含む）すべての予約が拒否されます。なぜこれが起こっているのですか？​

Details

回答 これの背後にあるロジックと修復方法の詳細な説明については、こちら を参照してください。

削除せずに計算から車両を含めたり除外したりするにはどうすればよいですか？​

Details

回答 車両モデルには、SWAT Routes または Driver App で表示されたまま、最適化の目的で車両を有効または無効にするために使用できるフラグ in_use があります。これにより、車両への手動割り当てが可能になります。これは、フローティング（またはオーバーフロー）車両、または計画に残っている他の車両がない場合にのみ使用する必要がある予備フリートに便利です。

もちろん、Docusaurus 用にフォーマットされた FAQ です。

車両の start_time と end_time は厳密な制約ですか？​

Details

回答 はい、車両の start_time と end_time プロパティは 厳密な制約 です。ソルバーは、この時間枠外の車両のアクティビティをスケジュールしません。

午前8時から午後3時までのような、車両の稼働時間をモデル化するにはどうすればよいですか？​

Details

回答 これをモデル化するには、主に2つの方法があります。

  1. 部分的なルートを持つ車両の場合: partial_route の開始ノードと終了ノードで open_time_ts と close_time_ts を使用して稼働時間を定義します。
  2. 部分的なルートを持たない車両の場合: 車両レベルの start_time と end_time フィールドを使用して、車両の稼働時間を指定します。

車両は start_time にルートを開始し、最初のドロップオフの前に長時間待機します。この待機時間（スラック）を最小限に抑えるために、ドロップオフ時間枠に近い時間帯に車両にピックアップを開始させるにはどうすればよいですか？​

Details

回答 ピックアップとドロップオフの間のスラック時間を最小限に抑えるための主なアプローチは3つあります。

  1. trip_cost を設定する:

    • 方法: ノードに小さな trip_cost（たとえば、0.01 - 0.1）を適用します。
    • 効果: これにより、ソルバーはピックアップとドロップオフの間の移動時間を最小限に抑えるようになり、スラックが効果的に削減されます。
    • 互換性: このアプローチは、dynamic_breaks と正しく連携することが期待されます。
    • 欠点: ソルバーのパフォーマンスが低下する可能性があります。

  2. max_slack を 0 に設定する:

    • 方法: ピックアップノードで max_slack: 0 を設定します。
    • 効果: これにより、そのノードでのスラック時間が強制的にゼロになり、ハード制約になります。
    • 要件: 拒否を発生させずにこれを行うには、リクエスト内のすべての時間枠が重複している必要があります。ピックアップ時間枠とドロップオフ時間枠が重複しない場合、予約は拒否されます。
    • 互換性: このメソッドは、dynamic_breaks と正しく 機能しません。パス期間が dynamic_break_min_path_duration より短い場合でも、休憩が追加される場合があります。

  3. finalization_type: 'max' を使用する:

    • 方法: ピックアップノードで finalization_type: 'max' を設定します。
    • 効果: これにより、ピックアップはその時間枠内で可能な限り遅く発生するようにプッシュされます。
    • 警告: この設定は連鎖的な「遅延」効果をもたらし、ソルバーが後続のすべてのノードを可能な限り遅くスケジュールする原因となる可能性があり、これは望ましくない副作用になる可能性があります。
    • 互換性: このメソッドも dynamic_breaks と正しく 機能しません。

推奨事項: 特に dynamic_breaks が必要な場合に最も堅牢な方法は、小さな trip_cost を使用することです。

1つのピックアップノードだけで finalization_type: 'max' を設定すると、ルート内の他のノードに影響しますか？​

Details

回答 はい。単一のノードでも finalization_type: max を設定すると、その車両のルート内の後続のすべてのノードのスケジュールに影響を与え、可能な限り遅くスケジュールされる可能性があります。

待機時間を短縮するためにピックアップノードで max_slack: 0 を使用していますが、動的休憩が割り当てられません。なぜですか？​

Details

回答 これは既知の競合です。max_slack: 0 を設定すると、dynamic_breaks を挿入するためのロジックと互換性のないハード制約が作成されます。ソルバーは、ゼロスラック要件と休憩挿入のルールの両方を同時に満たすことはできません。動的休憩が要件である場合は、max_slack: 0 の代わりに trip_cost メソッドを使用する必要があります。

車両の開始位置ノードで max_slack: 0 を設定するとどうなりますか？​

Details

回答 車両の割り当てられた開始位置ノード（部分的なルート内）で max_slack: 0 を設定することは、最初のスラックなしで旅の開始時に車両がすぐに出発することを保証するための有効な方法です。これはハード制約です。

スラック時間は、最適化のためのソルバーの目的関数で考慮されますか？​

Details

回答 いいえ、デフォルトではありません。スラック時間は通常、ノード割り当てが行われた後のルーティングソリューションの副産物です。最適化の目的の一部としてソルバーにスラックを積極的に最小化させるには、trip_cost や slack_cost などのパラメータを使用する必要があります。

trip_cost を使用する場合、運転時間とアイドル時間が異なるルートにどのように影響しますか？​

Details

回答 trip_cost を使用すると、ソルバーは個々の注文の合計移動時間を最小限に抑えようとします。この移動時間は、注文のピックアップからドロップオフまでの全期間であり、2つのイベント間に発生するスラック（アイドル）時間が 含まれます。したがって、ソルバーは各注文のこの合計時間を短縮するソリューションを好み、予約が車両に費やす時間を効果的に最小限に抑えます。

cvrptw モードで、車両がデポからルートを開始しないのはなぜですか？​

Details

回答 prebook_cvrptw モードでは、ソルバーは、デポ -> ドロップオフ -> ドロップオフ スキーマに従うために、各車両に明示的な開始点を必要とします。車両の partial_route が設定されていない場合、ソルバーは必ずしもデポではなく、利用可能な任意のノードからルートを開始する場合があります。

これを修正するには、デポノードの uid（通常はタイプ point のノード）を含む partial_route を車両に定義する必要があります。例： "partial_route": ["node-depot-uid"]。partial_route または partial_route_end に含まれるノードは、車両に自動割り当てされたと見なされます。

タグ:
に最終更新