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

車両ラベルと注文ラベル (Vehicle Labels and Order Labels)

車両と注文の間のこれらの関係を管理する1つの方法は、車両ラベルと注文ラベルを使用することです。これらのラベルは、車両と注文に関する追加情報を提供するタグまたは識別子として機能し、より洗練された詳細なルート最適化を可能にします。

SWAT モデルは、車両ラベルと注文ラベルを使用して、予約を適切な車両に一致させます。これらのラベルは割り当てアルゴリズムをガイドし、一致するラベルを持つ注文と車両のみを考慮するように制限します。さらに、API では、「OR」および「AND」ロジックを使用してラベル解釈ルールを構成できます。ラベルを使用すると、ジオフェンスの管理が難しい運用や十分な柔軟性が得られない運用に対して、ジオフェンス境界を適用せずに車両によるゾーニングを実現できます。

フィルタリングルールの適用方法については フィルタリング を参照するか、API を参照してください。

車両ラベル:

車両ラベルは、特定の特性、機能、または制限を表すために車両に割り当てられる属性または分類です。これらのラベルは、次のようなさまざまな要因に基づくことができます。

  • 車両タイプ: 「バン」、「トラック」、「冷蔵トラック」、「オートバイ」などのラベルは、サイズ、容量、機能に基づいて車両を分類できます。
  • スキルまたは認定: ラベルは、車両に「危険物取り扱い」や「重機操作」などの特定のスキルまたは認定を持つドライバーがいるかどうかを示すことができます。
  • 機器: ラベルは、「テールリフト」、「冷蔵」、「ナビゲーションシステム」などの特殊機器の存在を示すことができます。
  • 可用性: ラベルは、「朝のシフト」や「週末の可用性」などの時間枠またはその他の可用性制約を示すことができます。
  • ゾーンまたは地域: ラベルは、「ダウンタウン配達」や「地域輸送」などの車両の運用ゾーンまたは地域を指定できます。

注文ラベル:

注文ラベルは、特定の要件、優先順位、または制限を表すために注文に割り当てられる同様の識別子です。これらのラベルは、次のような要因に基づくことができます。

  • 注文タイプ: 「壊れやすい」、「緊急」、「高価値」、「腐敗しやすい」などのラベルは、取り扱いのニーズに基づいて注文を分類できます。
  • 顧客タイプ: ラベルは、「VIP 顧客」、「常連客」、「新規顧客」などの顧客のタイプを示すことができます。
  • 配達時間枠: ラベルは、「午前中の配達」や「午後の配達」などの優先または必須の配達時間枠を指定できます。
  • 場所: ラベルは、「市内中心部」や「郊外エリア」などの配達の場所またはゾーンを示すことができます。
  • 特別な指示: ラベルは、「取扱注意」や「裏口への配達」などの注文を処理するための特定の指示を伝えることができます。

車両ラベルと注文ラベルの関係:

車両ラベルと注文ラベルは相互に関連しています。注文に割り当てられたラベルは、それを実行するのに適した車両のタイプを決定します。車両ラベルと注文ラベルを照合することは、効率的で実行可能なルート計画に不可欠です。

それらの関係は次のとおりです。

  • 注文ラベルが車両選択を促進: 注文のラベルは、サービスを提供する車両に必要な特性を指定します。
  • 車両ラベルが注文割り当てを制限: 車両のラベルは、処理できる注文のタイプを決定します。
  • ラベルのマッチングにより互換性を確保: ラベルが一致しない車両に注文を割り当てると、実行不可能または非効率的なルートになる可能性があります。
  • ラベル付けの柔軟性がルーティング効率を向上: 適切に設計されたラベル付けシステムにより、より柔軟で最適化されたルーティングソリューションが可能になります。

例:

ある配送会社は次のラベルを使用しています。

  • 車両ラベル: "Fragile" (壊れやすい), "Perishable" (腐敗しやすい), "Urgent" (緊急), "Downtown" (ダウンタウン)
  • 注文ラベル: "Fragile", "Perishable", "Urgent", "Downtown"

次の注文を検討してください。

  • 注文 1: "Fragile", "Downtown"
  • 注文 2: "Perishable", "Urgent"

このシナリオでは:

ラベルを使用することで、会社は注文を適切な車両と効率的に一致させ、壊れやすいアイテムが慎重に扱われ、腐敗しやすい商品が冷蔵トラックで輸送され、緊急の注文が優先されるようにすることができます。

SWAT API での実装 (Implementation in SWAT APIs)​

ヒント

同じシミュレーション実行内で、ラベルを使用して注文と車両をグループ化できます。一致するラベルを持つさまざまな車両および注文グループに対してシミュレーション実行を分離する必要がある場合は、シミュレーションプロセッサ でフィルタリング式を使用できます。

ラベルを適用して、vehicles、bookings、および nodes 間のラベルのマッチングプロセスを管理できます。

予約オブジェクト の booking.vehicle_labels フィールドには、注文の配達に利用できる車両の車両ラベルがリストされます。次の例では、この vehicle_labels フィールドを使用して注文を最適化すると、T01、T02、または T03 ラベルを持つ 車両 のみがこれらの注文を実行するために使用されます。

// Booking

"vehicle_labels": {
        "or": [
          "T01",
          "T02",
          "T03"
        ]
      }
//Vehicle

"labels": [
          "T01",
          "T02",
          "T03"
        ]
ヒント

Optimization API では、一致する booking_uid を持つ各ノードに対して、ラベルを node レベルで適用する必要があります。

割り当てのラベルマッチングロジック (Label Matching Logic for Assignments)​

注文（予約）の車両への割り当ては、それぞれのラベルの相互作用によって異なります。

  • 注文にラベルがあり、車両に一致するラベルがある:

    • 結果: 割り当て可能です。
    • 説明: 車両は、注文に必要な特性を持っています。たとえば、注文に vehicle_labels: {"or": ["refrigerated"]} があり、車両に labels: ["refrigerated", "large_capacity"] がある場合、一致は成功します。

  • 注文に特定のラベル要件がなく、車両にラベルがある:

    • 結果: 割り当て可能です。
    • 説明: 注文には特定のラベル要件が課されていません（例：vehicle_labels が空または存在しない）。したがって、容量や時間枠などの他の制約が満たされていれば、ラベルを持つ車両を含むどの車両でもサービスを提供できる可能性があります。たとえば、特定の vehicle_labels のない注文は、labels: ["zone_A"] を持つ車両に割り当てることができます。

  • 注文にラベルがあり、車両にラベルがない（または一致しないラベルがある）:

    • 結果: 割り当ては不可能です（オファーなし）。
    • 説明: 注文には、車両が持っていない特定の特性（vehicle_labels で定義）が必要です。たとえば、注文に vehicle_labels: {"or": ["refrigerated"]} があり、車両に labels: ["van"]（"van" は "refrigerated" と見なされない）がある場合、割り当ては失敗します。同様に、車両にラベルがまったくない場合（labels: []）、特定のラベルを必要とする注文を満たすことはできません。

  • 注文にも車両にもラベルがない:

    • 結果: 割り当て可能です。
    • 説明: 注文または車両のいずれからも、割り当てを妨げるラベルベースの制限はありません。
ヒント

ラベルマッチングは割り当てプロセスの一部にすぎないことを覚えておいてください。車両容量、時間枠、車両特性などの他の制約も重要な役割を果たします。

ラベルのフィルタリングロジック（例：「AND」、「OR」条件）については、フィルタリング式のドキュメントで詳しく説明されています。たとえば、ラベルが {"and": [{"or: ["Label 1", "Label 2"]}, {"not": {"and": ["Label 4", "Label 5"]}}]} に設定された注文では、以下のシナリオがサポートされます。

警告

ラベルは大文字と小文字が区別されます。ラベルでは空白と特殊文字はサポートされていません。

一致する組み合わせの例 (Examples of Matching Combinations)​

ラベルの組み合わせは、メインの and 句の両方の部分を満たす場合に一致します。(Label 1 or Label 2) が真である必要があり、かつ not (Label 4 and Label 5) が真である必要があります。

  1. {"Label 1"}: 式の最初の部分（"Label 1" or "Label 2" が真）を満たし、"Label 4" と "Label 5" を一緒に含まないため、この組み合わせは一致します。したがって、2番目の部分（not ("Label 4" and "Label 5")）も真です。
  2. {"Label 2", "Label 3"}: これも一致します。"Label 2" が含まれており（最初の部分を満たす）、"Label 4" と "Label 5" の両方は含まれていません（2番目の部分を満たす）。"Label 3" は結果に影響を与えない無関係なラベルです。
  3. {"Label 1", "Label 2"}: "Label 1" と "Label 2" が含まれているため、最初の部分は真であり、一致します。"Label 4" と "Label 5" の両方は含まれていないため、2番目の部分も真です。
  4. {"Label 1", "Label 4"}: これは一致します。"Label 1" が含まれているため、最初の部分は真です。"Label 4" は含まれていますが、"Label 5" は 含まれていない ため、2番目の部分も真です。したがって、"Label 4" and "Label 5" は偽であり、not ("Label 4" and "Label 5") は真です。

一致しない組み合わせの例 (Examples of Non-Matching Combinations)​

メインの and 句のいずれかの部分が偽の場合、ラベルの組み合わせは一致しません。

  1. {"Label 3", "Label 4"}: 式の最初の部分（"Label 1" or "Label 2"）が偽であるため、これは一致しません。組み合わせには "Label 1" と "Label 2" の両方が欠けています。
  2. {"Label 1", "Label 4", "Label 5"}: これは一致しません。最初の部分は真ですが（"Label 1" が含まれているため）、2番目の部分は偽です。"Label 4" と "Label 5" の両方が含まれており、"Label 4" and "Label 5" が真になります。not 演算子により、2番目の句 not ("Label 4" and "Label 5") が偽になります。
  3. {"Label 4", "Label 5"}: これは一致しません。式の両方の部分が失敗します。"Label 1" と "Label 2" の両方が欠けているため、最初の部分は偽です。"Label 4" と "Label 5" の両方が含まれているため、2番目の部分も偽です。
  4. {}: 空のラベルセットは一致しません。"Label 1" または "Label 2" が含まれていないため、最初の部分は偽です。

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

以下のプレイグラウンドを使用して、車両ラベル の概念を試すことができます。 この例では、異なるラベル（「cold」と「dry」）を持つ2台の車両と、特定のラベルを必要とする2つのジョブを定義します。 ソルバーが「冷蔵倉庫ジョブ」を「冷蔵トラック」に、「ドライグッズジョブ」を「ドライトラック」にどのように割り当てるかを観察してください。

Loading...