倉庫の容量制限
倉庫には容量制限があることが多く、同時にサービスを提供するトラックの数を制限する必要があります。このモデルはSWAT APIでサポートされており、cumulative limitationパラメータを使用してこの制約を適用できます。
ルート計画への影響:
配車計画問題(VRP)における累積的な制限は、特定のリソースの場所または特定の時間枠内で使用できるリソースの総数または消費できるリソースの総量に対する制約を表します。これらの制限は、デポやその他のサービス場所に適用されることが多く、ルート計画とリソース割り当てに大きな影響を与える可能性があります。
累積的な制限:
累積的な制限は、時間経過に伴うリソースの最大容量または使用量を定義 します。VRPの文脈では、これは多くの場合、倉庫で同時にサービスを提供できる車両の数を指します。たとえば、倉庫には荷積みドックの数が限られている場合があり、同時に荷積みまたは荷降ろしできる車両の数が制限されます。その他の例は次のとおりです。
- 倉庫容量:倉庫には駐車スペースや荷積みベイの数が限られている場合があり、特定の時間に倉庫に存在できる車両の数が制限されます。
- サービス容量:サービス場所にはサービス担当者や機器の数が限られている場合があり、同時にサービスを提供できる車両の数が制限されます。
- リソースの可用性:特定の種類の燃料や特殊なツールなどのリソースは、限られた量でしか利用できない場合があり、特定の時間枠内でそれを使用できる車両の数が制限されます。
例:
配送会社は、荷積みドックが2つしかない中央倉庫から営業しています。これは、2台のトラックしか同時に荷積みできないことを意味します。同社は5台のトラックを保有しており、次の注文を受け取ります。
- 注文1:倉庫での荷積みが必要
- 注文2:倉庫での荷積みが必要
- 注文3:倉庫での荷積みが必要
この例では、cumulative limitationを使用して、特定のサービス時間で倉庫で同時にサービスを提供する車両の数を制限できます。Cumulative limitationは、リクエストのmodel_parametersで設定されます。
実装
ノード、グループ、および対応するサービス時間は、model_parameters.cumulative_limitations構成で設定する必要があります。
groupとnode_uidsは、制限付きでグループ全体を構成するために使用されるgroups、または選択したノードのみを対象とするnode_uidsと同じ構成で一緒に使用できます。
このオプションが正しく機能するには、すべての車両にvehicle_positionタイプのノードが1つ以下で、部分的なルートとしてバインドされている必要があります。このノードは、ピックアップイベントのプレースホルダーです。partial_routeに他のノードが含まれている場合、vehicle_positionノードはリストの最後にある必要があります。
ピックアップが発生する可能性のある時間間隔は、累積制限ノードの時間枠の積集合(つまり、最大の共通間隔)によって識別されます。各サービス間隔の期間はdepot_service_timeです。nodes_uidsオブジェクトのリストには、vehicle_positionノードのuidを保持する必要があります。スケジューラは、ピックアップ時間間隔をサービス間隔に分割し、各サービス間隔に対してmax_cumulative_vehicles個のピックアップノードを作成します。作成されたノードのuidはcumulative_で始まります。これらのノードはすべてオプションですが、影響を受ける各車両にはこのようなノードが1つだけ追加される必要があります。この後、スケジューラはpartial_routeからvehicle_positionノードを削除し、代わりに各サー ビス間隔の車両ごとにpartial_routeの直後にピックアップノードを挿入します。
各累積制限について、vehicle_positionノードは、グループで設定された以外のいくつかのグループに属する場合があります。この場合、node["groups"]の他のグループは、すべてのノードで等しくなければなりません。作成されたpickupノードは、cumulative_limitation.groupを除くvehicle_positionノードからグループリストを継承します。
例:
cumulative_limitations = [{
"group": "CL1",
"node_uids": ["n3"],
"depot_service_time": 300,
"max_cumulative_vehicles": 3
}],
nodes: [
{"uid": "n1", groups = ["CL1", "group_a", "group_b"], <...>}, - valid
{"uid": "n2", groups = ["CL1", "group_b", "group_a"], <...>}, - valid
{"uid": "n3", groups = ["group_b", "group_a"], <...>}, - valid
{"uid": "n4", groups = ["CL1", "group_a", "group_Z"], <...>}, - NOT valid
{"uid": "n5", groups = ["group_a", "group_b", "group_Z"], <...>} - NOT valid
]
vehicle_positionノードのuidに関係なく、最終的なjsonのすべての作成されたピックアップノードはcumulative_で始まり、booking_uidも同様です。
ステートレスAPIからの応答には、拒否された予約にすべての一時的なcumulative_予約が含まれます。
ピックアップノードはpartial_routeからルートの主要部分に移動されるため、zero_cost_if_only_partial_routesフラグはそれらに適用されなくなります。
特殊なケース
groups_orderを使用した特殊なケースcumulative_limitations。両方の機能はgroupsを使用し、partial_routeを変更します。競合を回避するには、次の2つの方法があります。
-
各車両で個別のピックアップノードとvehicle_positionノードを使用する:
- グループ名とその優先順位で
groups_orderを作成します。 groups_orderの優先順位が最も高いpickupノードを作成し、この最優先グループをこのノードのgroupsに追加します。vehicle_positionノードを作成します。- ピックアップノードと
vehicle_positionをpartial_routeに追加します。vehicle_positionノードがリストの最後にあることを確認してください。
- グループ名とその優先順位で
-
各車両でピックアップと
vehicle_positionに同じノードを使用する:- グループ名と優先順位で
groups_orderを作成します。 vehicle_positionノードを作成し、それに最優先グループを割り当てます。vehicle_positionノードのuidをcumulative_limitationsに追加します。vehicle_positionノードのuidをpartial_routeに追加します。- 注:シミュレーション後のこのノードの
uid、booking_uid、およびnode_typeは上書きされます。
- グループ名と優先順位で
例
{
"model_parameters": {
"cumulative_limitations": [
{
"node_uids": ["10W_0_start"],
"depot_service_time": 100,
"max_cumulative_vehicles": 10
}
]
},
...
"vehicles": [
{
"agent_id": "10W_0",
"capacity": {
"CBCM": 21500000,
"WEIGHT": 11710,
},
"lat": 0,
"lon": 0,
"assigned_nodes": [
{
"uid": "10W_0_start",
"node_type": "vehicle_position",
"open_time_ts": "2022-02-18T16:00:00+00:00",
"close_time_ts": "2025-02-18T20:42:00+00:00",
"close_time_ts_dynamic": "2026-02-19T16:42:00+00:00",
"service_time": 0,
"lat": 11.975487,
"lon": 101.399407,
"stop_id": "depot",
"max_slack": null,
"demand": {
"CBCM": 0,
"WEIGHT": 0
},
"groups": [],
"trip_cost": 0
}
],
"partial_route": [
"10W_0_start",
],
"partial_route_end": [
"10W_0_end"
],
...
}
]
}