遷移属性を使用してビジネス ロジックをモデル化する

このガイドでは、移行属性の使用例について説明します。最適化されたルートに車両の駐車時間を組み込む例と、各ルートが特定の場所への訪問で終わるようにする例の 2 つの例で、実際のシナリオをモデル化する方法について説明します。

始める前に

移行属性 を使用して、最適化されたルートの特定の 移行 にモデル固有の費用と遅延を追加します。これらの費用と遅延は、使用する車両のパラメータに基づいて地図データから計算された移行時間と 費用に加えて追加されます。

移行 とは、ある場所から次の場所をつなぐルートのセグメントです。

場所 とは、車両のルート上の次のいずれかの地点を指します。

  • ルートの開始地点。
  • 集荷または配達が行われる停車地。
  • ルートの終点。

モデルのすべての移行属性を定義するには、リスト ShipmentModel.transition_attributesに追加します。 リストの各要素は、移行属性の 1 つのセットを定義し、移行の開始地点と終了地点のタグを使用してルート内の移行と照合されます。移行属性について詳しくは、 TransitionAttributes のリファレンス ドキュメントをご覧ください。

実際のシナリオをモデル化する

このセクションでは、移行属性を使用して実際のビジネス上の制約を実装する 2 つの簡単な例を示します。

駐車時間を確保する

このシナリオでは、運転手は場所 A に行く前に車両を駐車する必要があります。場所 B は近くにあり、運転手は両方の訪問に同じ駐車スペースを使用できます。運転手が A の直後に B に行く場合、駐車スペースから離れて車両を再度駐車する必要がないため、時間を節約できます。Route Optimization API では、運転手が 1 つの駐車スペースから別の駐車スペースに移動する場合にのみ、移行属性を使用して車両を駐車するための追加時間を追加できます。

駐車時間を訪問時間とは別にモデル化すると、同じ駐車場を使用する訪問がグループ化されたルートの所要時間が短くなります。モデルの精度を高めるとともに、オプティマイザーが訪問がグループ化されたルートを優先するようにします。

Route Optimization API リクエストでこれを行う手順は次のとおりです。

  1. VisitRequest.duration は、訪問の実行に必要な時間のみに使用します。たとえば、荷物を渡して顧客から署名を受け取る場合などです。

  2. モデルで使用される個別の駐車スペースごとに、モデル内の他の用途に使用されていない新しいタグ(PARKING_123 など)を使用します。

  3. このタグを次に追加します。

    1. VisitRequest.tags この駐車スペースを使用するすべての訪問リクエストの。

    2. Vehicle.start_tags 車両がこの駐車スペースからルートを開始する場合は。

    3. Vehicle.end_tags 車両がこの駐車スペースでルートを終了する場合は。

  4. 新しい駐車タグごとに、別の駐車スペースから移動する場合に駐車の遅延を追加するエントリを ShipmentModel.transition_attributes に追加します。 手順は次のとおりです。

    1. TransitionAttributes.excluded_src_tag と TransitionAttributes.dst_tag を PARKING_123 に設定します。

    2. TransitionAttributes.delay を車両の駐車に必要な時間に設定します。

    たとえば、場所のタグが PARKING_123 で、車両の駐車に 150 秒かかる場合は、次の エントリを ShipmentModel.transition_attributes に追加します。

    {
      "excluded_src_tag": "PARKING_123",
      "dst_tag": "PARKING_123",
      "delay": "150s"
    }
    

ルートの最後に必須の清掃を行う

このシナリオでは、ルートの最後に車両を清掃する必要があります。次の追加の制約があります。

  • 清掃は、車両基地に戻る前に専門の清掃施設で行われます。最適化されたルートでは、車両の場所と集荷と配達の場所に基づいて最適な清掃施設が使用されます。
  • 清掃後、車両は追加の集荷や配達を行ってはなりません。
  • 清掃施設までの移動時間と車両の清掃時間は、運転手の勤務時間に含まれ、ルートの最大時間に収まる必要があります。

この要件をモデル化するには、空のルートまたは最後の訪問が清掃施設への訪問であるルートのみを許可します。Route Optimization API では、清掃施設またはルートの開始地点以外の場所からルートの終了地点への移行を禁止することで、これを行います。

  1. モデル内のどこでも使用されていない 2 つの新しいタグ(CLEANED と ROUTE_END など)を選択します。前者は車両が清掃される場所または清掃される場所、後者はルートの終点です。
  2. 車両ごとに、次の属性を持つ清掃施設への訪問を表す配達専用の新しい配送を追加します。
    1. 各清掃施設の場所は、この配送の配達訪問リクエストとして表す必要があります。
    2. 清掃施設の配送の各訪問リクエストの VisitRequest.tags に CLEANEDを追加します。これは、この場所から出発する車両が清掃済みであることを示します。モデル内の他の訪問リクエストではこのタグを使用しないでください。これにより、車両が清掃されていないと見なされます。
    3. 車両が他の用途で使用されていない場合は、 penalty_cost を小さい値に設定して、オプティマイザーがこの配送をスキップできるようにします。
  3. 車両ごとに、CLEANED を Vehicle.start_tagsに追加します。 これは、前営業日の終わりに清掃されたことを前提として、集荷または配達を行う前に車両を清掃済みとしてマークし、開始地点から終了地点に直接移動できるようにするために使用されます。このようなルートが実際には発生しない場合でも、このシナリオを許可することで、オプティマイザーは最適化されたルートをより効率的に検索できます。

  4. 車両ごとに、ROUTE_END を Vehicle.end_tags に追加します。

  5. 清掃されていない車両が車両の終了地点に到着することを禁止する新しいエントリを ShipmentModel.transition_attributes に追加します。プロパティは次のとおりです。

    1. TransitionAttributes.excluded_src_tag を CLEANED に設定します。

    2. TransitionAttributes.dst_tag を ROUTE_END に設定します。

    3. TransitionAttributes.delay を大きな値に設定します。遅延をルートの最大時間よりも長くすると、オプティマイザーがルートでこの移行を使用することを効果的に禁止できます。

    たとえば、モデルの時間スケールが 1 営業日の場合、24 時間(86,400 秒)の遅延を使用して、清掃施設とルートの開始地点以外の場所からルートの終点への移行を禁止できます。

    {
      "excluded_src_tag": "CLEANED",
      "dst_tag": "ROUTE_END",
      "delay": "86400s"
    }
    

遅延と費用のどちらを選択するか

遅延と費用のどちらを選択するかは、実装するビジネス ロジックと制約の性質によって異なります。 TransitionAttributes.delay は、ハード制約を実装する場合や、 費やした時間でトレードオフを表す場合に最適です。 TransitionAttributes.cost は、ソフトな設定や、追加費用として表されるトレードオフを実装する場合に適しています。費やした時間と費用の両方が関係する場合は、遅延と費用を任意に組み合わせることができます。

車両の清掃の例では、非常に長い 遅延 を使用しています。これは、ルートの最後に 車両を清掃することが厳格な要件であり、長い遅延 によってオプティマイザーが要件を無視することを防ぐためです。費用のみを設定した場合、 オプティマイザーは清掃をスキップすることを選択できます。他の方法で 費用を補う方法が見つかった場合です。たとえば、車両を清掃しないことで "節約"した時間でより多くの配送を行うなどです。

駐車の例では、車両の駐車に必要な追加時間に対応する短い 遅延 を使用しています。運転手が有料駐車場に停車する場合は、遅延と組み合わせて 費用 を使用することもできます。

すべての訪問リクエストに一致する移行属性を追加する方法

上記の例では、特定のタグが付いている場所、またはタグが付いていない場所に一致する移行属性を使用しています。ただし、すべての移行に適用される移行属性を追加する必要がある場合はどうすればよいでしょうか?

タグを省略することはできません。各 TransitionAttributes メッセージには、 TransitionAttributes.src_tag と TransitionAttributes.excluded_src_tag のいずれか 1 つと、 TransitionAttributes.dst_tag と TransitionAttributes.excluded_dst_tagのいずれか 1 つが必要です。

ただし、 TransitionAttributes.excluded_src_tag または TransitionAttributes.excluded_dst_tag をモデル内のどこでも使用されていないタグに設定することで、すべてのタグに一致させることができます。これにより、このタグが付いていないすべての場所が一致しますが、どの場所でも使用されていないタグを意図的に選択したため、これらの移行属性はすべての場所に一致します。

関連情報