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

FMCG顧客向けの単一DCから複数の店舗への商品配送

このモデルは「多拠点配送」と呼ばれることが多く、消費者の需要を満たすために店舗での商品の頻繁な補充が必要なため、FMCGで一般的に使用されています。

FMCGロジスティクスでの仕組みは次のとおりです。

  • ルート計画:複数のサプライヤーの場所や小売店を含む所定のルートが、運用の前に確立されます。
  • 混載:さまざまなサプライヤーからの商品が収集され、単一の車両に混載されます。
  • 配送:車両は、混載された商品を中央倉庫、配送センター、または直接小売店に配送します。

主な特徴:

  • 単一DC:すべての注文は単一の配送センターから発信され、在庫管理と注文の混載を合理化します。
  • 複数店舗:注文は、定義された地理的地域内のさまざまな店舗に配送されます。
  • 1日1回のトリップ:各配送車両は1日1回のトリップにスケジュールされ、車両の稼働率とドライバーのスケジュールを最適化します。
  • 複数停車:車両は、トリップ中にさまざまな店舗で複数回停車し、配送を混載することで効率を最大化します。

シナリオ

商品は、毎朝、所定の車両フリートによって単一の配送センターから配送されます。車両には、利用可能な容量が異なるさまざまなタイプがあります。店舗からのすべての注文は、配送センターの開店前に利用可能であり、運用中に変更されることはありません。配送注文には、所定の既知の配送先住所とWGS84座標、および車両からの既知の必要な容量があります。目標は、移動距離と注文を実行するために必要な車両数を最小限に抑えることです。

ヒント

このセクションでは、通常SWATチームが実行するため、初期プロジェクトまたはシミュレーションテンプレートの構成については説明しません。ただし、プロセスのリファレンスはこちらで入手できます。

日常業務

プロジェクトとデフォルトのシミュレーションが構成されると、ルート最適化のための日常業務を開始できます。これを実現するには、新しいシミュレーションを作成し、注文をアップロードして、ルート最適化プロセスを実行する必要があります。

シーケンス図

テンプレートに基づいて単一または複数日の運用のためのシミュレーションの新しいインスタンスを作成する

テンプレートを使用してシミュレーションを作成すると、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"]
}

注文(予約)のアップロード

ヒント

ペイロードで提供される容量と車両の特性に注意してください。たとえば、車両モデル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のリストを返します。

シミュレーションの最適化を実行する

予約がアップロードされると、そのシミュレーションのルートを生成できます。これを実現するには、次のリクエストを発行する必要があります。リクエストは計算をトリガーし、計算の進行状況を追跡するために使用できる内部プロセスの識別子と、計算で使用される予約の内部識別子を反映するbooking_idのリストを返します。

ヒント

最適化プロセスは、設定、予約数、車両数によっては時間がかかる場合があります。したがって、最適化リクエストは非同期であり、コンシューマーは最適化の実行が完了するまでポーリングして待機する必要があります。

シミュレーションに予約をアップロードする
POST /api/v2/microservices/logisticsapi_optimize
JSONペイロードを参照
シミュレーションに注文(予約)をアップロードする
POST /api/v2/microservices/logisticsapi
{
"calculation_uid": <計算の一意の識別子>,
"simulation_id": <以前に作成されたシミュレーションID>,
"bookings": [],
"booking_uids": <予約のアップロードリクエストからの最適化に使用される予約識別子>
}

計算ステータスのポーリング

最適化プロセスは非同期で実行され、その状態は定期的に(数秒ごと)ポーリングでき、実行が完了したら結果を取得できます。この場合のprocessor_idは、前のリクエストからのプロセス識別子です。

シミュレーションに予約をアップロードする
GET /api/v2/simulationprocessor/<processor_id>

リクエストは、現在の計算状態を反映するstateフィールドを含むオブジェクトを返します。最適化の実行が完了すると、フィールドはcompleted状態に変わります。

ヒント

最適化の実行から期待どおりの回答が得られない場合があります。これには、予約が満たされないことを意味するoffer rejected状況が含まれます。これは、一部の制約が満たされていないか、コスト関数が適切に構成されていないことを意味する場合があります。SWATチームは、何が問題だったのかを調査するのに役立ちます。

計算結果の取得

消費側アプリケーションのニーズに応じて、計算結果を取得する方法は多数あります。最も一般的な方法は、ノードと車両間の割り当てを取得することです。

シミュレーションで使用されるすべての車両を取得する

シミュレーションに予約をアップロードする
GET /api/v2/vehicle?simulation=<simulation_id>

リクエストは、そのシミュレーションのすべての車両のリストを返すため、コンシューマーは、必要なすべての車両が最適化結果に存在することを確認できます。

車両に割り当てられた集荷および降車ポイントを取得する

車両に割り当てられた予約を取得する
GET /api/v2/vehicle/<vehicle_id>/assigned_nodes

リクエストは、その車両に割り当てられた降車および集荷ポイント(別名ノード

)のリストを、元の予約への参照、およびスケジュールされた推定到着時刻と出発時刻とともに返します。

車両に割り当てられたルートを取得する

車両に割り当てられたルートのジオメトリは、次を使用して取得できます

車両のルートジオメトリを取得する
GET /vehicle_route_proxy/<vehicle_id>/<wkt_waypoints>

ここで、vehicle_idはジオメトリを取得する車両識別子であり、wkt_waypointsは、車両に割り当てられたノードのリストからの緯度/経度ペアのセミコロン区切りリストです。車両作成段階で割り当てられた車両ルーティングプロファイルが、ルートのジオメリを生成するために使用されます。