このセクションでは、ツアープランのProblemsの定式化のベストプラクティスについて説明します。 これにより、Problemを最も効果的に作成できるように、重要なポイントとヒントが提供されます。
デポで集荷ジョブや配達ジョブを追加しない
最も一般的な配達サービスのシナリオでは、配達で 1 つのデポが定義されます。 デポとは、すべてのジョブが集荷され、車両のシフトが開始および終了する場所のことです この場合、デポからのジョブの集荷を追加する必要はありません。 ソルバーは、集荷がデフォルトでデポで実行されるとみなし、ラストマイル配達の問題を解決します。
同様に、配達なしで集荷が手配された場合、ソルバーはデフォルトで配達終了時にデポに配達されるとみなします。 そのため、これらの配達をデポに追加する必要はありません。
ただし、デポに集荷または配達を追加しても問題は発生せず、解決されますが、最適化の観点からは次の問題が発生します
- 問題の複雑さが増すため、解決に時間がかかることがあります。
- ジョブの数が増加するため、ロケーション/ トランザクションの数が増加し、問題解決の総コストが増加します。
ただし、デポで集荷ジョブを追加する必要がある場合があります。
- 問題には複数の拠点があり、車両は複数の拠点で共有できます。
- デポでのジョブの集荷には、特定の時間帯があります。
不要な時間帯の使用の回避
最も一般的なラスト マイル配送シナリオでは、顧客が特定の期間内に仕事を完了する必要がない限り、配送時間枠は必要ありません。 このような場合は、個々のジョブに時間帯を追加しないでください。 車両のシフト時間帯を使用して車両の時間を定義でき、すべての作業が車両シフト中に配達されます。 可能な限り時間のかかる作業を回避し、問題の複雑さを軽減して、より効果的なソリューションを迅速に生成できます。 また、 1 つの時間帯で十分な場合に複数の時間帯を追加することは避け、全体的なパフォーマンスを向上させる必要があります。
時間帯の使用方法については、 こちらを参照してください。
スキルを使用する状況
スキルは、特定の車両タイプを特定の作業にマッピングするために使用できる、最も強力な機能の 1 つです。 これらのジョブを実行できるのは、ジョブスキルに一致するスキルを持つ車両のみです。 そのため、作業に必要な場合にのみ、車両にスキルを設定する必要があります。 スキルを使用する場合は、車両の積載量、作業量、シフト時間を考慮する必要があります。 一致するスキルを持つ車両に十分な積載量または時間が残っていない場合、そのようなスキルを必要とするジョブの割り当ては解除されたままになります。
スキル の使用方法の詳細については、 こちらを参照してください。
コストパラメータを効果的に使用する方法
コスト パラメーターは、最適化の観点からソルバーを導く上で重要な役割を果たします。デフォルトでは、ソルバーは、ツアー全体の所要時間や移動距離だけではなく、すべてのツアーの全体コストを最小化するように設計されています。車両には、次の 3 つのコストパラメータがあります。
- 時間コスト - 車両 1 台あたりの所要時間 ( 秒単位 )
- 走行距離コスト - 車両 1 台あたりの走行距離(メートル単位)
- 固定費 - 輸送あたりの車両の固定費
ソリューションの総コストは、ソリューションで指定されているすべてのツアーについて、上記の 3 つのコストのすべてのコントリビューションのリニアのの組み合わせです。つまり、 3 つのコストのすべてのコントリビューションが考慮され、最適化の指針となります。
コスト要因は、さまざまなコストのコントリビューションに対する重要な重み付け要因であり、最適化の指針となります。 実世界のコストと同一である必要はありません。 ソリューションのツアーオブジェクトには、実際のコスト要因に基づいて実世界のツアーコストの見積もりを計算するためのすべての統計情報が含まれています ( 必要な場合 ) 。
対応する車両タイプによって提供される個々のツアーの出発地点の比率distance cost
とtime cost
順序に影響があります。 たとえば、高い time cost
と低い distance cost
を設定すると、より速い走行速度が許可される道路、例: 高速道路では、総走行距離が長くなる代わりに優先される可能性があり、その結果、停止地点の順序に影響を与える可能性があります。
これとは対照的に、低い time cost
と高い distance cost
を設定すると、短いツアーが好まれますが、ツアー期間は長くなる可能性があります。
高いfixed cost
と低いtime cost
とdistance cost
は、ツアーの数を減らすことにつながりますが、その代わりにツアー全体の距離や時間が長くなる可能性があります。
テリトリーの効果的な使用
テリトリーの最適化機能は、柔軟性に優れており、特定の地域または地域間で車両を配送するという観点から、車両を適切に利用して、より実用的なツアーを作成するのに役立ちます。
車両のプライマリテリトリーは優先度が 1 で、近隣のテリトリーは優先度が低いものを追加する必要があります。 そのようにすると、車両は積載量と時間に余裕がある場合にのみ、近隣のテリトリーから作業を引き継ぎます。
車両が定義されたテリトリー外で作業を行うことを許可されていない場合は、該当する車両タイプで true に設定されている厳密なフラグを使用します。 この場合、車両は、まだ積載量が残っている場合でも、定義されているテリトリー内からのみ作業を行います。
Territories Optimizationの使用方法については、 こちらを参照してください。
不要な運行管理 プロファイルの追加の回避
運行管理 プロファイルは、運行管理 のルーティングデータを定義するために使用されます。 複数のプロファイルは、互いに大きく異なる場合にのみ追加する必要があります。たとえば、次のような場合に、別のプロファイルを追加する必要があります。
- 車両の種類(車、トラック、スクーター、自転車、歩行者、 バス、プライベートバス )
- 車両によっては、特定のパラメータ(ルート、オプション、国を除く)が使用されている場合があります
- 交通状況に応じて、車両ごとに異なる出発時間を定義する必要があります
プロファイルが同じであることが想定されている場合は、それらを複製しないでください。
たとえば、次のようになります。
"profiles": [
{
"name": "c1",
"type": "car"
},
{
"name": "c2",
"type": "car"
}
]
単純な使用 :
"profiles": [
{
"name": "c1",
"type": "car"
}
]
ツアーの結果は同じですが、問題はより明確になり、ソルバーのパフォーマンスが向上します。
また、制約内に追加された各運行管理 プロファイルによって処理時間が全体的に増加するため、プロファイルの数は少なくしておく必要があります。
不要な車両タイプの追加の回避
車両タイプが異なるのは、それらの間に大きな違いがある場合に限ります ( デポからの開始時間と終了時間の違いなど ) 。 また、 2 つの車両タイプが同じ場合は、 2 つの異なる車両タイプを使用しないでください。車両数を 2 に増やして、それらを 1 つに統合する必要があります。 このようにすると、問題の複雑さが軽減され、パフォーマンスが向上する可能性があります。
Relations
sequence
と flexible
のRelationsは制約に対して検証されないため、可能な限り制約を順守するジョブをこれらのRelationsに追加するようにしてください。
ツアープランの使用についての詳細は こちらを参照してください。
需要とキャパシティの使用
Problemsを効果的に構築するための基本的な要素の 1 つは、作業の「需要」と車両の積載量を使用することです。 これらの 2 つのパラメータは常に考慮する必要があります。問題のすべてのジョブは、総需要量がすべての車両の総積載量を超えていない場合にのみ割り当てることができます。
Capacity -demandの相互関係の詳細は、 こちら を参照してください。
Traffic
デフォルトでは、ライブトラフィックは利用可能な場合はいつでもツアープランで有効になっています。 状況によっては、交通状況が変化して作業場所に到達できないことがあります ( 道路閉鎖など ) 。 ユーザーがこの問題を回避する場合 "traffic": "historicalOnly"
は、問題の定義で設定を行ってライブトラフィックを無効にするオプションがあります。 その結果、ライブトラフィックに割り当てられなかったジョブが正しく割り当てられる可能性があります。
未割り当てのジョブ理由
ジョブが割り当て解除された理由が複数ある場合があります ( スキルと容量の制約の両方により割り当て解除された場合など ) 。 ただし、現在、未割り当てのジョブの理由として考えられるものは 1 つだけです。 また、未割り当てのジョブの理由が、実際に表示されているものと異なる場合があります。 そのため、割り当てられていないジョブを割り当てるために、表示されている理由を修正するだけでなく、さまざまな修正問題の定義を適用することをお勧めします。