FMCG顧客向けの単一DCから複数の店舗への商品の配送 (Distribution of goods from a single DC to mulitple stores for FMCG customers)
このモデルは、消費者の需要を満たすために店舗での商品の頻繁な補充が必要なため、FMCG で一般的に使用される「マルチストップ配送」と呼ばれることがよくあります。
FMCG ロジスティクスでの仕組みは次のとおりです。
- ルート計画: 複数のサプライヤーの場所や小売店を含む、運用の前に事前に決定されたルートが確立されます。
- 統合: さまざまなサプライヤーからの商品が収集され、単一の車両に統合されます。
- 配達: 車両は、統合された商品を中央倉庫、配送センター、または直接小売店に配達します。
主な特徴:
- 単一 DC: すべての注文は単一の配送センターから発生し、在庫管理と注文の統合を合理化します。
- 複数の店舗: 注文は、定義された地理的領域内のさまざまな店舗に配達されます。
- 1日1回のトリップ: 各配達車両は1日1回のトリップがスケジュールされており、車両の使用率とドライバーのスケジュールを最適化します。
- マルチストップ: 車両はトリップ中にさまざまな店舗で複数のストップを行い、配達を統合することで効率を最大化します。
シナリオ (Scenario)
商品は、事前定義された車両フリートによって、毎朝単一の配送センターから配送されます。車両には、利用可能な容量が異なるさまざまなタイプがあります。店舗からのすべての注文は、配送センターが開く前に利用可能であり、運用中は変更されません。配達注文には、事前定義された既知の配達先住所と WGS84 座標、および車両に必要な既知の容量があります。目標は、移動距離と注文を実行するために必要な車両の数を最小限に抑えることです。
このセクションでは、初期プロジェクトやシミュレーションテンプレートの構成については説明しません。これは通常、SWAT チームによって実行されます。ただし、プロセスのリファレンスは こちら で入手できます。
毎日の運用 (Daily operations)
プロジェクトとデフォルトのシミュレーションが構成されると、ルート最適化のために毎日の運用を開始できます。これを実現するには、それぞれ新しいシミュレーションを作成し、注文をアップロードして、ルート最適化プロセスを実行する必要があります。
シーケンス図 (Sequence diagram)
テンプレートに基づく単一または複数日の運用のためのシミュレーションの新しいインスタンスの作成 (Creating a new instance of simulation for a single or multiple days of operations based on template)
テンプレートを使用してシミュレーションを作成すると、simulation 設定を含む必要なすべてのパラメータがテンプレートから複製され、このシミュレーション用に vehicles が作成されます。シミュレーション作成応答には、新しいシミュレーションの識別子が含まれます。
必要に応じて、シミュレーションオブジェクトパラメータまたは車両パラメータの PATCH リクエストを使用して、シミュレーションのパラメータを更新できます。この場合、デフォルトのシミュレーションとデフォルトのシミュレーションに添付されている車両には影響しません。
POST /api/v2/microservices/simulation_template_instance
JSON ペイロードを見る
POST /api/v2/microservices/simulation_template_instance
{
{
"project_id": 1,
"start_time": "2021-01-10T00:00:00+00:00",
"end_time": "2021-01-10T23:59:00+00:00"
}
}
次の例を使用して、単一のリクエストで複数のシミュレーションを作成できます
JSON ペイロードを見る
POST /api/v2/microservices/simulation_template_instance
{
"project_id": 1,
"template_id": 2,
"start_times": ["2021-01-02T00:00:00+08:00", "2021-01-03T00:00:00+08:00"]
}
注文（予約）のアップロード (Upload orders (bookings))
ペイロードで提供される容量と車両特性に注意してください。たとえば、車両モデル 4W の容量は、2,000の任意の重量単位と7,000,000立方センチメートルとして定義されています。消費アプリケーションは、任意の <string><number> ペアの形式で必要な容量を指定できます。予約が作成されると、オプティマイザーはこれらの容量名を使用して、容量ルーティング問題を解決します。
テンプレートからコピーされたすべての車両でシミュレーションが作成されると、関連する注文（予約）をアップロードできます。このユースケースでは、以下を使用してアップロードを行う必要があります。
POST /api/v2/microservices/logisticsapi
JSON ペイロードを見る
POST /api/v2/microservices/logisticsapi
{
"calculation_uid": "e33e7240-96ba-4c4a-b958-f903eca9b422",
"simulation_id": 1,
"bookings": [
{
"uid": "a87fdfe8-29c6-4483-8fcd-49448362473d",
"pickup_postal_code": "1",
"pickup_location_name": "Pickup name",
"dropoff_postal_code": "2",
"dropoff_location_name": "Dropoff name",
"pickup_location_lat": null,
"pickup_location_lon": null,
"dropoff_location_lat": null,
"dropoff_location_lon": null,
"min_pickup_time": "2021-08-17T08:59:10.073329+00:00",
"max_pickup_time": "2021-08-17T09:14:10.073329+00:00",
"min_dropoff_time": "2021-08-17T08:59:10.073329+00:00",
"max_dropoff_time": "2021-08-17T09:59:10.073329+00:00",
"demand": {
"volume": 1
},
"data": {
"some": "thing",
"number": 1
},
"pickup_service_time": 0,
"dropoff_service_time": 0,
"groups": []
}
],
"upload_strategy": "clear_all",
"optimization_settings": {
"vehicle_cost": null,
"trip_cost": null,
"time_limit_ms": null,
"first_solution_strategies": null,
"max_pickup_slack": null,
"max_dropoff_slack": null,
"mutually_exclusive_groups": null,
"use_local_search_metaheuristic": null,
"allow_upload_after_simulation_start_time": null
},
"vehicles_filter_expression": null,
"vehicle_selection_by_emptiness": false,
"vehicle_selection_in_service": false
}
リクエストは、システムに追加された注文（予約）IDのリストを返します。
シミュレーションの最適化を実行 (Execute optimization for the simulation)
予約がアップロードされると、そのシミュレーションのルートを生成できます。これを実現するには、次のリクエストを発行する必要があります。リクエストは計算をトリガーし、計算の進行状況を追跡するために使用できる内部プロセスの識別子と、計算で使用される内部識別子予約を反映する booking_id のリストを返します。
最適化プロセスは、設定、予約数、車両数によっては時間がかかる場合があります。したがって、最適化リクエストは非同期であり、コンシューマーはポーリングを行い、最適化実行が完了するまで待つ必要があります 。
POST /api/v2/microservices/logisticsapi_optimize
JSON ペイロードを見る
POST /api/v2/microservices/logisticsapi
{
"calculation_uid": <arbitrary unique identifier for the calculation>,
"simulation_id": <simulation id created previously>,
"bookings": [],
"booking_uids": <bookings identifiers to be used for optimization from upload bookings request>
}
計算ステータスのポーリング (Poll calculation status)
最適化プロセスは非同期で実行され、その状態は定期的に（数秒ごとに）ポーリングでき、実行が完了したら結果を取得できます。この場合の processor_id は、前のリクエストからのプロセス識別子です。
GET /api/v2/simulationprocessor/<processor_id>
リクエストは、現在の計算状態を反映する state フィールドを含むオブジェクトを返します。最適化実行が完了すると、フィールドは completed 状態になります。
期待している最適化実行からの回答が得られない場合があります。これには、予約を満たすことができないことを意味する offer rejected の状況が含まれます。これは、一部の制約が満たされていないか、コスト関数が適切に構成されていないことを意味している可能性があります。SWAT チームは、何が間 違っていたかを調査するのに役立ちます。
計算結果の取得 (Retrieve calculation results)
消費アプリケーションのニーズに応じて、計算結果を取得する方法は多数あります。最も一般的な方法は、ノードと車両間の割り当てを取得することです。
シミュレーションで使用されるすべての車両の取得 (Retrieve all vehicles used in the simulation)
GET /api/v2/vehicle?simulation=<simulation_id>
リクエストはそのシミュレーションのすべての車両のリストを返すため、コンシューマーは必要なすべての車両が最適化結果に存在することを確認できます。
車両に割り当てられたピックアップおよびドロップオフポイントの取得 (Retrieve assigned pick up and drop off points for a vehicle)
GET /api/v2/vehicle/<vehicle_id>/assigned_nodes
リクエストは、その車両に割り当てられたドロップオフおよびピックアップポイント（別名 ノード
）のリストを返し、元の予約と、予定の到着および出発予定時刻を参照します。車両に割り当てられたルートの取得 (Retrieve assigned route for a vehicle)
以下を使用することで、車両に割り当てられたルートのジオメトリを取得できます。
GET /vehicle_route_proxy/<vehicle_id>/<wkt_waypoints>
ここで、vehicle_id はジオメトリを取得する車両識別子であり、wkt_waypoints は車両に割り当てられたノードのリストからの緯度/経度ペアのセミコロン区切りリストです。車両作成段階で割り当てられた車両ルーティングプロファイルは、ルートのジオメトリを生成するために使用されます。