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

車両効率 (Vehicle Efficiency)

Stateless API のコンテキストでは、車両効率 は、ルート全体で車両の容量がどのように利用されるかを最適化および制御するために設計された一連の制約を指します。これらの制約により、トリップ中の最小負荷とトリップ終了時の最大負荷に関するルールを強制できます。

この機能は、車両が十分に活用されていない（空または非常に少ない貨物で運転している）ことを防ぎ、新しい作業を引き受ける前に車両が負荷を空にすることを保証するなど、特定の運用フローを強制するために重要です。

コアコンセプト (Core Concepts)​

車両効率制約は車両ごとに定義され、特定の需要次元（例：weight、volume、passengers）で動作します。主に2種類のチェックがあります。

1. 積載容量チェック（最小負荷） (Loaded Capacity Check (Minimum Load))​

このチェックは、トリップ中、車両が少なくとも指定された最小量の負荷を運ばなければならないことを強制します。

  • 目的: 車両が非効率的に少ない負荷でトリップを行うのを防ぐため。
  • メカニズム: ソルバーは、停止するたびに車両の負荷をチェックします。負荷が loaded_min_capacity しきい値を下回る場合、違反と見なされます。

2. 非積載容量チェック（非積載時の最大負荷） (Unloaded Capacity Check (Maximum Load when Unloaded))​

このチェックは、車両が「非積載」と見なされるときはいつでも（例：トリップの終了時、または「トリップ」セグメントのソルバーの内部ロジックに応じて一連のドロップオフの後）、車両が指定された最大量を超える負荷を運んではならないことを強制します。

  • 目的: 車両が空または最小限の残留貨物で戻ることを保証するため。これは多くの場合、「最初に配達、次にピックアップ」のワークフローを強制するため、または単にすべての商品が配達されることを保証するために使用されます。
  • メカニズム: ソルバーは、割り当てられたルートの最後、および「トリップ」が完了したと見なされる中間点（例：配達実行後）で車両の負荷をチェックします。負荷が unloaded_max_capacity を超える場合、違反と見なされます。

厳格さとペナルティ (Strictness and Penalties)​

両方のチェックは、厳格 (Strict) または 柔軟 (Flexible) のいずれかとして構成できます。

  • 厳格 (true): 制約を満たす 必要があります。ソリューションが制約に違反する場合、それは無効と見なされ、破棄されます。これは、必須のビジネスルール（例：「トラックはデポに戻るときに空でなければならない」）に役立ちます。
  • 柔軟 (false): 制約は「ソフト」制約として扱われます。違反は許可されますが、ペナルティコストが発生します。オプティマイザーはこれらのペナルティを最小限に抑えようとし、効率制約と移動時間や距離などの他のコストとのバランスを効果的にとります。

構成 (Configuration)​

車両効率制約を有効にするには、JSON ペイロードの車両定義に efficiency オブジェクトを追加します。

パラメータ (Parameters)​

パラメータタイプ説明
demand_namestringチェックする需要次元の名前（例：「units」、「weight」）。capacity および demand オブジェクトのキーと一致する必要があります。
loaded_min_capacitynumberトリップ中に必要な最小負荷（絶対単位）。
loaded_min_capacity_percentagenumberトリップ中に必要な最小負荷（総容量のパーセンテージ、0-100）。
loaded_undercapacity_check_strictbooleanIf true の場合、最小負荷要件は厳格です。
unloaded_max_capacitynumber非積載時に許可される最大負荷（絶対単位）。
unloaded_max_capacity_percentagenumber非積載時に許可される最大負荷（総容量のパーセンテージ、0-100）。
unloaded_overcapacity_check_strictbooleanIf true の場合、最大終了負荷要件は厳格です。

パーセンテージの使用 (Using Percentages)​

絶対値（例：「5 units」）を定義する代わりに、_percentage パラメータを使用して、車両の総容量に対する制約を定義できます。

  • loaded_min_capacity_percentage: 最小負荷を車両の最大容量のパーセンテージ (0-100) として設定します。
  • unloaded_max_capacity_percentage: 最大非積載負荷を車両の最大容量のパーセンテージ (0-100) として設定します。

注: 特定の制約に対して、絶対値パラメータまたはパーセンテージパラメータのいずれかを使用する必要があります。同じ需要タイプに対して両方を同時に使用しないでください。

JSON ペイロードの例 (Example JSON Payload)​

車両がトリップ中に常に少なくとも15ユニットを運んでいることを確認するように構成する方法の例を次に示します。これにより、車両はドロップオフに進む前に、より小さなピックアップ（例：10ユニットと5ユニット）を統合する必要があります。10ユニットの単一のピックアップは最小負荷制約に違反するためです。

{
  "vehicles": [
    {
      "agent_id": "vehicle_1",
      "capacity": {
        "units": 100
      },
      "efficiency": {
        "constraints": [
          {
            "demand_name": "units",
            "loaded_min_capacity": 15,
            "loaded_undercapacity_check_strict": true,
            "unloaded_max_capacity": 0,
            "unloaded_overcapacity_check_strict": false
          }
        ]
      }
      // ... その他の車両プロパティ
    }
  ]
}

シナリオ: ピックアップ前のドロップオフの確保 (Scenario: Ensuring Drop-offs Before Pickups)​

車両効率の一般的なユースケースは、車両が新しいピックアップを開始する前にすべての配達（ドロップオフ）を完了しなければならないワークフローを強制することです。これにより、残留負荷をデポに運んだり、フローを混合したりする結果になる場合、ピックアップとドロップオフの「インターリーブ」が効果的に禁止されます。

非積載容量チェック を 0 に設定し、それを 厳格 にすることで、車両がルートを終了するときにアイテムを積載していないことを保証します。車両が配達する商品を持って開始するシナリオでは、これによりオプティマイザーはすべてのドロップオフをスケジュールせざるを得なくなります。配達を完了する 前 に車両が新しいアイテムをピックアップしようとすると、ルートの終了時にそれらの新しいアイテムがまだ積載されている可能性があり（新しいアイテムの宛先によって異なります）、この制約によってそれが防止されます。

具体的には、負荷を持って戻ることを厳密に禁止する（これは暗黙的にドロップオフの完了を促す）には、次を使用します。

"efficiency": {
    "constraints": [
        {
            "demand_name": "weight",
            "unloaded_max_capacity": 0,
            "unloaded_overcapacity_check_strict": true
        }
    ]
}

この構成は、需要タイプ weight に対して厳格な過剰容量チェックを強制します。一連の連続したドロップオフの後の最大容量を0として定義し、ピックアップが空でない戻りをもたらす場合、すべてのドロップオフが完了するまで車両がピックアップを実行するのを効果的に防ぎます。

なぜこれが計画にとって重要なのでしょうか？ (Why is this important for planning?)​

  1. コスト削減: 最小負荷 (loaded_min_capacity) を強制することで、些細な量の貨物のために車両を派遣することを避け、配達単位あたりの燃料とドライバーのコストを節約します。
  2. 運用コンプライアンス: 多くのロジスティクス業務には、「クリーン」な返品に関する厳格なルールがあります（例：空のコンテナを返品する、または相互汚染がないことを確認する）。unloaded_max_capacity 制約は、これらの物理的または規制上の要件を直接モデル化します。
  3. ワークフロー制御: これにより、プランナーはすべての停止を手動で順序付けることなく、「すべてを最初に配達する」などの優先される運用パターンに向けてソルバーを導くことができます。
ヒント

柔軟 な制約（strict = false）を使用する場合、model_parameters のペナルティコストを調整するか（該当する場合）、ソルバーの内部デフォルトペナルティに依存して、効率と他の要因のバランスをとることで、制約の「強度」を制御できます。

プレイグラウンド (Playground)​

以下のプレイグラウンドを使用して、車両効率 の概念を試すことができます。 この例では、車両には 15ユニット の 積載効率 制約があります。ピックアップはそれぞれ10ユニットと5ユニットであるため、車両はドロップオフに進む前に、最小負荷要件を満たすために両方のピックアップ場所を訪問せざるを得ません。

Loading...