よくある質問
このドキュメントには、SWAT APIに関するよくある質問のリストが含まれています。
最適化および統合API
このセクションには、最適化API 
および統合API に関連する質問と回答が含まれています。
GET /api/v1/node_scheduler/{job_id}/status のさまざまな応答は何ですか？計算がまだ実行中の場合とエラーがある場合の応答は何ですか？
回答
エンドポイント は、status フィールドの非同期ジョブに関する3つのステータスを提供します。
PENDING：計算が進行中であることを示します。FAILED：計算が失敗したことを示します。SUCCESS：計算が成功したことを示します。
コンシューマーは、このエンドポイントを定期的に（約5秒ごと）ポーリングし、PENDING 状態が SUCCESS または FAILED に移行するまで待機することが期待されます。その後、エンドポイント を使用して結果を取得できます。
ソルバーパラメータ time_limit_ms の計算時間は何に設定する必要がありますか？このパラメータの単位は何ですか？
回答
単位はミリ秒です。推奨される計算時間は、車両と注文の数、およびその複雑さによって異なります。通常、計算時間は、問題の規模とソリューションの望ましい品質に応じて、2〜60分の範囲内にある必要があります（計算時間が長いほど、通常、より良い結果が得られます）。
集荷または降車する注文の数に関係なく、サービス時間が同じになるようにサービス時間を設定するにはどうすればよいですか？
回答
ノードのグループに固定サービス時間を指定するには、モデルパラメータ オブジェクトで compound_zones を使用できます。複合ゾーン
enter_time と exit_time を秒単位で指定するゾーンのリストです。荷積みポートで同じ固定稼働時間を設定するには、リクエスト本文の node オブジェクトに次の設定を使用します。ここで、uid は loading port 1 または loading port 2 に設定されます。
{
"compound_zones": [
{
"node_uids": ["loading port 1", "loading port 2"],
"exit_time": 300
}
]
}
次の図は、ノード
に適用される時間パラメータを表しています。compound zone 時間は、ゾーンに入る/出るのに必要な最小時間に基づいてルートの最適化を確実にするために移動時間に追加されるため、車両ノードの割り当てに直接反映されません（ノードの固定時間制約である service time と比較してください）。
ノードと車両の間の需要と容量のモデルは何ですか？複数の次元がある場合、それらをどのように設定しますか？
回答
需要とは、特定の顧客または場所に配送する必要のある商品またはサービスの量を指します。容量とは、車両が運ぶことができる商品、サービス、または人の最大量を指します。 車両の容量は、1台の車両で満たす ことができる需要の量に制限を設けます。車両は容量を超えて運ぶことはできないため、ルートに割り当てられた総需要は常に車両の容量以下でなければなりません。 需要は、車両とルートの必要性を促進します。すべての顧客にわたる総需要は、必要な車両の数と、需要を効率的に満たすためにそれらの車両がどのようにルーティングされるかを決定します。
VRPアルゴリズムは、実行可能で効率的なソリューションを作成するために、容量と需要を慎重にバランスさせる必要があります。目標は、容量の制約を尊重しながら、移動距離、時間、およびコストを最小限に抑える方法で、顧客を車両とルートに割り当てることです。
ノードタイプ pickup は正の需要を持ち、dropoff は予約を作成するときに負の需要を持ちます。需要タイプは任意の文字列であり、少なくとも1つの車両の需要タイプは、少なくとも1つのノードの容量タイプと一致する必要があります。そうでない場合、この需要タイプは車両に割り当てられることはありません。
ノードと車両の次元の一貫性を維持することをお勧めします。ノードに車両に存在しない追加の次元がある場合、予約はその車両に割り当てることはできません。
"node":
{
"demand": {
"goods": 1, // ノードは1個の商品の配送を期待します
"human": -1 // ノードは1人の人間の集荷を期待します
}
}
"vehicle":
{
"capacity":{
"goods":10, // 車両は10個の商品を運ぶことができます
"human":20, // 車両は20人の人間を運ぶことができます
"rat":30 // 車両は30匹のネズミを運ぶことができます
}
}
午後3時までの配達を可能な限り優先するにはどうすればよいですか？
回答
配達ウィンドウは、ノードの open_time_ts と close_time_ts によって制御されます。この例では、ドロップオフノードの close_time_ts を午後3時に設定できます。デフォルトでは時間枠は厳密な制約であるため、これにより一部の予約が割り当てられない場合があります。あるいは、allow_vehicle_late フラグを使用して close_time_ts を前倒しすることで優先順位付けを実現できます。
同じ場所にある複数の注文のドロップオフポイントで、荷降ろし時間が守られるようにするにはどうすればよいですか（予定された出発前に荷降ろし）？
回答
回答は、例としていくつかの任意のタイムスタンプを想定しています。
問題提起は、以下のように定式化できます。
- すべての注文は午後12時までに荷降ろしする必要があります
- すべての注文は同じ場所で荷降ろしする必要があります
- 各注文には、荷降ろし時間が必要です（たとえば、注文1、2、3でそれぞれ5分、10分、15分）
- 場所は午前11時から午後12時の間に注文を受け入れることができます
注文を集約できない場合、node.close_time_ts を 午後12時 - 注文3のサービス時間（この例では、具体的には午後11時45分）に調整して、最後の注文に十分な荷降ろし時間を確保できます。注文3は、サービス時間が最も長いため、調整対象として選択されます。これにより、注文3を荷降ろしするのに十分な時間が提供され、ノードは午後12時に閉鎖されるため、それ以降は他の注文は受け付けられません。その結果、注文1と注文2の荷降ろしは、注文3の前にスケジュールされます。正確な順序は、時間枠の特定の長さによって異なることに注意してください。ただし、同じ場所であるため、ルート最適化の観点から運用目的で非常に重要である可能性は低いです。
ルートが最適化された後、車両のすべてのノード/ウェイポイントを取得するにはどうすればよいですか？
回答
目的の結果に応じて、車両のノードを取得するには複数の方法があります。
- 単一の車両に割り当てられたノード（車両が訪問する予定のポイントのシーケンス）を取得するには、
/api/v2/vehicle/{vehicle_id}/assigned_nodes を使用してください。 - 単一の車両の完了したノードを取得するには、
/api/v2/vehicle/{vehicle_id}/completed_nodes を使用してください。 - シミュレーション内のすべての車両の完了したノードと割り当てられたノードを取得するには、
/api/v2/node?simulation={{simulation_id}}&status__in=completed,assigned を使用してください。
API /api/v2/vehicle/{vehicle_id}/nodes_grouped のノードグループ化はどのように機能しますか？
回答
次の例を検討してください。
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:23の別のノードEが追加された場合、
(7:27-7:26)>(5分+5分のサービス時間)であるため、ノードEは別のグループに割り当てられます。
車両とドライバーはどのオブジェクトに割り当てられますか？予約がどの車両に割り当てられているかを見つけるにはどうすればよいですか？
Details
回答
booking、vehicle、および driver の間には暗黙的な関係があります。車両とドライバーは、予約ではなく node に割り当てられます。この場合、ノードは、車両が行く必要がある物理的な場所を表します。各予約には、ドロップオフノードとピックアップノードの少なくとも2つのノードが関連付けられている必要があります。。途中で商品や人が車両間で移動しない単純なシナリオの場合、予約のすべてのノードには同じドライバーと車両が割り当てられます。予約ステータス fail_to_board と fail_to_deliver の違いは何ですか？
Details
回答
予約は、ドライバーが予約の最初のノードで集荷できなかった場合、fail_to_board とマークされます。したがって、配達するものがありません。その場合、この予約は次の実行計画では考慮されません。ただし、ドライバーが商品を配達できた場合、予約ステータスは fail_to_deliver に設定されます。これは、商品がまだ車両に残っており、商品に関連する制約（需要やグループなど）を満たす必要があることを意味します。max_slack パラメータは何を意味しますか？
Details
回答
ノードのmax_slack パラメータは、そのノードで許可されるスラックの最大量を指定します。そのノードでスラックをなくすことが目標の場合は、0に設定できます。 他の制約（ノードの時間枠など）を満たすためにスラックが必要な場所でゼロスラックを要求すると、そのノードの割り当てが妨げられるため、このパラメータは慎重に使用してください。この値を構成すると、ドライバーの休憩の割り当て方法にも影響します。予約が fail_to_board または fail_to_deliver とマークされた場合、ノードはどうなりますか？
Details
回答
予約が集荷できない場合、fail_to_board とマークされ、後続の計算では単に無視されます（集荷された車両に商品や乗客がいないため、降ろすものがないため）。ただし、fail_to_deliver は、車両にまだ商品が残っており、容量の制約に対応する必要があるため、より複雑です。その場合、予約/ノードはまだ車両に割り当てられています（fail_to_board の予約は車両から割り当て解除されます）。ドライバーは、プランナーが再最適化を行うと同時に node_status を送信できます。フィルター式やラベルで条件を使用する例を教えてください
回答
次の例は、Djangoクエリ文字列のJSON形式に従って、vehicle labels またはフィルター式を使用するためのいくつかのオプションを表しています。
'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
ライブ運用中に注文のライブ挿入を試みていますが、すべての予約（すでに割り当てられているものを含む）が拒否されます。なぜですか？
Details
回答
この背後にあるロジックと修正方法の詳細な説明はこちらを参照してください。車両を削除せずに計算から含めたり除外したりするにはどうすればよいですか？
Details
回答
車両モデルには、SWAT RoutesやDriver Appで表示されたまま、最適化目的で車両を有効または無効にするために使用できるin_use フラグがあります。これにより、フローティング（またはオーバーフロー）車両や、計画用の他の車両が残っていない場合にのみ使用する必要がある予備のフリートに便利な手動割り当てが可能になります。もちろん、Docusaurus用にフォーマットされたFAQは次のとおりです。
車両の start_time と end_time は厳密な制約ですか？
Details
回答
はい、車両のstart_time と end_time プロパティは厳密な制約です。ソルバーは、この時間枠外で車両の活動をスケジュールしません。午前8時から午後3時などの車両の稼働時間をモデル化するにはどうすればよいですか？
Details
回答
これをモデル化するには、主に2つの方法があります。- 部分的なルートを持つ車両の場合：
partial_routeの開始ノードと終了ノードでopen_time_tsとclose_time_tsを使用して稼働時間を定義します。 - 部分的なルートを持たない車両の場合： 車両レベルの
start_timeとend_timeフィールドを使用して、車両の稼働時間を指定します。
私の車両は start_time にルートを開始し、最初のドロップオフの前に長時間待機しま す。この待機時間（スラック）を最小限に抑えるために、車両がドロップオフの時間枠に近づいて集荷を開始するようにするにはどうすればよいですか？
Details
回答
集荷とドロップオフの間のスラック時間を最小限に抑えるには、主に3つのアプローチがあります。-
trip_costを設定する：- 方法： ノードに小さな
trip_cost（例：0.01〜0.1）を適用します。 - 効果： これにより、ソルバーは集荷とドロップオフの間の移動時間を最小限に抑えるようになり、効果的にスラックを削減します。
- 互換性： このアプロー チは、
dynamic_breaksと正しく連携することが期待されます。 - 欠点： ソルバーのパフォーマンスが低下する可能性があります。
- 方法： ノードに小さな
-
max_slackを0に設定する：- 方法： 集荷ノードで
max_slack: 0を設定します。 - 効果： これにより、そのノードでのスラック時間がゼロになり、ハード制約になります。
- 要件： これが拒否を引き起こさずに機能するには、リクエスト内のすべての時間枠が重複している必要があります。集荷時間枠とドロップオフ時間枠が重複していない場合、予約は拒否されます。
- 互換性： この方法は、
dynamic_breaksとは正しく連携しません。dynamic_break_min_path_durationよりもパスの期間が短い場合でも、休憩が追加される可能性があります。
- 方法： 集荷ノードで
-
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つのイベント間で発生するスラック（アイドル）時間が含まれます。したがって、ソルバーは、この総時間を短縮するソリューションを優先し、予約が車両内で費やす時間を効果的に最小限に抑えます。