tsp的理論與實踐(7)取件時間窗

tsp目錄

1. 最簡單的實踐 juejin.im/post/5d1b14…
2. 最簡單的理論 juejin.im/post/5d1b15…
3. 當前tsp的現狀 juejin.im/post/5d1b19…
4. 單起點任務分配 juejin.im/post/5d1c6d…
5. 多起點任務分配 juejin.im/post/5d1dbe…
6. 更簡潔的多起點分配 juejin.im/post/5d1dc2…
7. 起點時間窗 juejin.im/post/5d1f1f…
8. 終點時間窗和hk juejin.im/post/5d1f44…
9. LK簡介 juejin.im/post/5d25b8…
10. tsp系列暫停一下 juejin.im/post/5d302e…

tsp領域的問題, 並不都是tsp問題, 可是, tsp相關的算法通常都能解決, 只要你能爲某一個充滿個性的問題兒子找到他親生的解決方案爸爸.

通過前面六篇的努力, 咱們已經能夠完美的解決多個發件地址發件的配送分配問題了, 可是, 由於公司有運營在, 因此技術不可能沒事幹, 因此, 新的業務需求出現了:

需求概述

1. 客戶須要組織生產, 所以要求咱們下午再過來取件.
2. 客戶要求咱們11:00以後取件.
3. 客戶要求咱們13:30以後再來取件.
4. 總之, 客戶要求咱們某個時間點以後來取件, 咱們至少要計算兩件事:
   1. 這單生意咱們能接嗎? 咱們能在當天成功配送嗎?
   2. 咱們怎麼排出最高效的配送方案, 是讓配送員提早過去等一下.

分析

• 以前的算法都是按照物理距離做爲權重組織的.

• 可是如今有了時間窗的概念, 時間上的距離要考慮進來, 好比如今是9:00, 有一單10:00才能取, 這一單隻距離我3km, 可是, 我和他之間還有1個小時的時間距離. 因此, 咱們的系統裏面天然地出現了兩類距離:

  • 空間轉化的時間距離, 好比3km轉化爲5分鐘.
  • 直接的時間的距離, 好比9:00到10:00是一小時的距離.

• 可是, 若是直接粗暴的使用時間距離, 會引發不少問題, 好比, 1小時的時間距離, 會掩蓋掉物理距離的巨大差別, 好比咱們的時速是60km, 那麼1小時的時間距離致使距離1km和距離60km的隊列的權重是同樣的了. 現實中的這種狀況, 咱們仍是指望1km距離的司機上門取貨, 寧可他找個地方休息60分鐘. 這樣咱們節省了汽油和司機的體力.

• 這個問題咱們也不能粗暴的修正, 好比:

  • 咱們不能說先判斷時間距離, 在時間距離一致的時候, 就判斷空間距離, 這個方案的問題在於, 時間距離不會一致, 某個司機分配了一單, 他送完這單要到9:40, 而後系統一看他距離10:00最近了. 因此這至關遠的一單就給他了.
  • 若是咱們先判斷空間距離, 而後, 就讓司機原地等待到取件. 這樣也是很沒有效率的作法, 由於若是一單是下午18:30取件, 那麼難道司機早上9:00到了客戶那邊, 而後等一天嗎?
  • 咱們也不能說到接近10:00的時候再分配. 好比有一個思路, 當離那個點最近的司機接單也在時效之內了, 那麼就給他. 這樣會致使一個問題: 原本司機原地等待一下就行了, 結果咱們讓他往返跑.

• 所以, 直觀的作法是:

  1. 咱們按照空間距離來生成樹, 可是, 生成的時候要判斷下是否達成時間限制, 若是沒有, 那麼就先不排他, 改成排入距離第二的訂單. 此時要記錄訂單和路徑的關係.
  2. 而後繼續分配, 依舊是這個邏輯, 若是某一單分進來, 不知足時效, 那麼就先不分配.
  3. 此時須要評估一下這個時效單單權重是否依然生效. 參見下圖.
  4. 當某一個時效單分進來, 知足取件時效要求了, 這時咱們要作一次總體的評估, 歷史上須要等待的分配都分一次, 看總體的時間開銷哪種最小.

  第三步的示例:

1. 此時1號單分進來, 可是還不到取件時間.
2. 只能分配c單進來, 此時1的權重不變, 由於a點還在.
3. 而後, 1的取件時間仍是不到, 那麼咱們分配b單進來.
   • 此時要刪除a和1兩個q以前的權重了.
   • 由於a的獨立的對於1的權重是失效的,
   • 由於1號單須要某個時間以後配送, 不能a以後直接配送, a以後必定要作其餘的單, 好比b單,
   • 因此a-1這個權重不會再生效了.

至此訂單分配問題基本都已經解決了, 後續的分享將以路線規劃爲主, 會爲你們介紹LK, LP以及遺傳算法. 敬請期待