路線圖生命週期

本頁面說明使用 Route Optimization API 規劃路線的流程，從找出路線需求開始，到系統中整合路線規劃為止。

按照路徑規劃的階段操作，即可達成下列目標：

  • 對應車隊營運：將實體車隊、複雜限制和業務目標轉譯為 API 程式碼。
  • 為業務最佳化路線規劃：瞭解如何調整路線規劃，以達成目標並改善日常營運。
  • 部署至正式環境：將路徑規劃納入日常營運，加以實施。

下圖顯示路線方案的生命週期。

路線規劃生命週期的流程圖，詳情請參閱下方文字

當您首次整合 API，或業務需求大幅變更時，就會進入路線圖的實作階段。涵蓋第 1 到第 5 階段。

日常作業階段較為輕量，只需進行少量調整。涵蓋第 2 到第 4 階段。

路線的生命週期階段如下：

  1. 界定問題範圍：在開始使用 API 之前，請先找出並整理目標、資源、工作和限制，全面掌握作業情況。
  2. 對應資料：將實際業務情況轉換為 API 參數，讓路線規劃反映車隊的運作方式。
  3. 建立要求並取得路線規劃：將資料輸入 API，即可取得最佳路線規劃。
  4. 調整路線規劃：測試路線規劃，並調整限制和目標，確保路線符合所有需求。
  5. 整合路線規劃：將路線規劃連結至現有系統，提供可執行的導航。

界定問題範圍

使用 API 前，您必須將日常營運的詳細資料整理成清楚的資料類別。這樣一來，您就能在開始導入程序時，清楚瞭解目前的資源和工作、限制條件，以及您希望透過機群達成的目標。

找出資源和工作

規劃路線時，重要步驟是找出資源和工作，也就是車輛和貨物。

車輛 出貨
  • 數量：你有幾輛車？
  • 地點：車輛的起點和終點在哪裡？
  • 時間：車輛駕駛的工作時間為何？
  • 容量：車輛的限制為何？
  • 成本：車隊營運成本為何？
  • 地點：取貨和送貨地點在哪裡？
  • 需求：包裹的重量或尺寸為何？
  • 限制：是否有特定的配送時間？
  • 服務時間：司機需要多少時間停車和卸貨？
  • 需求：運送作業是否需要特定車輛類型或司機？

找出限制

限制是指車輛的使用限制，以及處理貨件的方式限制。這些限制會影響大部分的營運作業，在建立最佳路線計畫時至關重要。

限制通常分為兩類：

硬性限制 軟性限制
這些是無法突破的限制。舉例來說，卡車載重不得超過最大容量，司機也無法在商店關門後取貨。 這些偏好設定在必要時可以違反，但通常會產生罰款。舉例來說，您可能偏好只裝載 80% 的卡車容量，或在目標時間前送達，但如果超過這些限制能獲得更佳路線，您也願意接受。

常見的限制條件包括：

  • 容量限制：車輛可載運的重量、體積或物品數量上限。
  • 時間範圍：地點開放造訪的特定時段，或司機的特定輪班時段。
  • 費用：車輛行駛或取消出貨的費用。API 的主要目標之一，是產生符合成本效益的路線規劃。
  • 駕駛人休息時間：勞工法通常規定駕駛人工作滿一定時數後，必須休息一段時間。

確立業務目標

建立資源和工作及其限制後，接下來就要決定哪些指標對貴商家最重要。這些目標與限制條件相輔相成，可協助您決定規劃路線時最重要的事項。

以下列舉幾個業務目標範例：

車隊規模 距離 時間 費用
您想盡量減少使用的車輛數量，還是想動用整個車隊，提早完成當天的工作？ 您想選擇最短路徑來節省燃料，還是偏好較快但可能較長的路線 (例如行經高速公路)？ 您想盡可能縮短總工時，還是優先在特定時間抵達，即使這會延長路線時間？ 您是否想盡可能降低薪資和燃料等營運費用，還是願意接受較高成本，以符合嚴格的期限？

對應資料

收集資料後，請將資料對應至 API 的屬性。最佳化工具會根據這些資訊，傳回符合您業務實況的路線規劃。

使用下表中的參數，對應您在「界定問題範圍」一節中對應的資源、工作、限制和目標。

變數對應

實際概念 API 參數 說明
駕駛或車輛 model.vehicles[] 代表車隊中的單一車輛。
維修中心地點 vehicles[].startWaypoint
vehicles[].endWaypoint 		車輛路線的起點和終點。
營業時間 model.globalStartTime
model.globalEndTime 		整個車隊營運的最早開始時間和最晚結束時間。
工作或套件 model.shipments[] 代表工作。可以是 pickup、delivery 或兩者。
工作地點 pickups[].arrivalWaypoint
deliveries[].arrivalWaypoint 		工作地點的地理位置。
服務時間 pickups[].duration
deliveries[].duration 		在該地點完成工作 (例如卸貨) 所需的時間，不含行程時間。

限制對應

實際限制 API 參數 說明
車輛容量 vehicles[].loadLimits 設定車輛容量的硬性或軟性限制。如果貨件的 loadDemand 超過剩餘限制，就不會指派。
套裝方案大小 shipments[].loadDemands 貨件消耗的車輛容量。
車輛限制 shipments[].allowedVehicleIndices 限制貨件只能由特定車輛或司機取貨或送貨。
營業時間 shipments[].pickups[].timeWindows 或 shipments[].deliveries[].timeWindows 設定可造訪地點的時間。如果車輛無法在這段時間內抵達，系統就會略過這批貨物。
班次長度限制 vehicles[].routeDurationLimit 設定特定司機的工作時間上限 (例如最多 8 小時)，無論全域結束時間為何，都不得超過這個上限。
駕駛休息時間 vehicles[].breakRule 強制執行特定休息規則，例如工作滿一定時數後必須休息。
道路限制 vehicles[].travelMode 指定交通方式 (例如 DRIVE 或 BICYCLE)。這會將路線限制在合法道路上，並決定用於計算行程時間的速度。

目標對應

實際目標 API 參數 說明
盡可能減少車隊規模 vehicles[].fixedCost 適用於車輛的單次使用費用。高固定成本會迫使路線優先使用較少的車輛，而非增加總距離或工作時間。
盡可能縮短距離 vehicles[].costPerKilometer 按每公里計算費用。優先選擇較短的路線，以節省燃料和減少磨損。
盡可能縮短總時間 vehicles[].costPerHour 車輛每小時的費用 (包括行駛和等待時間)。優先著重快速完成。
盡可能縮短行車時間 vehicles[].costPerTraveledHour 專門針對移動時間套用費用。這可區分塞車 (成本高) 和在停靠站等待(成本可能較低) 的情況。
優先處理特定工作 shipments[].penaltyCost 如果略過特定運送作業，則會套用費用。將這個值設為高，可確保重要工作優先於選用工作。

建立要求並取得回應

使用 Route Optimization API 產生路線計畫的步驟如下：

  1. 設定環境：設定 Google Cloud 雲端專案、啟用 API，並設定驗證。如需操作說明，請參閱「入門指南」。這個步驟只需執行一次。
  2. 傳送要求：使用上一節定義的資料對應，建構要求主體。如要瞭解端點、標頭和要求格式，請參閱「提出 API 要求」。
  3. 瞭解回應：收到 API 回應後，請瞭解路線規劃和各個參數的意義。請參閱「解讀回應」。

調整路線規劃

將實際物流作業轉譯為 API 成本和限制，是一項複雜的工作。初始路線規劃可能不符合業務目標或司機期望。如要調整路線規劃，請反覆測試傳回的路線並調整參數，直到找到能達成目標的設定。

調整目標和限制

如果生成的路線圖不符合需求，可以修改特定參數，取得不同結果。收緊或放寬參數會改變路線計畫中解決衝突目標的方式，而放寬參數是找出導致路線計畫發生錯誤的參數的有效方法。

下表列出常見的轉送問題，以及可調整來解決問題的參數。

情境 參數 調整項 說明
略過重要出貨 shipments[].penaltyCost 提高價值，或在其他貨件中加入罰款 如果運送為選用項目，請提高運送的違規費用，以優先處理。如果運送作業為必要 (沒有罰款費用)，請將罰款費用加到其他較不重要的運送作業。這樣一來，這些工作就會變成選用，車輛就能騰出時間和容量，優先處理重要運送工作。
因時間問題而略過出貨 softStartTime/softEndTime 新增軟性時間範圍 硬性時間範圍會捨棄即使只遲到一分鐘的工作。如果司機在軟性時間範圍內抵達，系統會「支付」費用，而非判定指派作業失敗。
因重量而略過運送 loadLimits[].softMaxLoad和costPerUnitAbove 新增軟負載需求 允許車輛稍微超出理想容量 (會扣分)，而不是留下包裹。
機群超載，因此略過出貨 model.vehicles[] 或 shipments[].timeWindows 新增車輛或放寬時間範圍 如果目前車隊的運送量過多 (尤其是在尖峰時段)，請增加車輛或延長送貨時段，分散工作量。
路線太長或效率不彰 vehicles[].costPerKilometer/costPerHour 新增費用或提高費用 告知 API 旅遊費用高昂，促使 API 捨棄較遠的偏遠停靠站，為車隊建立更緊密的路線。
司機班次過長 vehicles[].routeDurationLimit 或 model.vehicles[] 新增時間長度限制，或新增車輛和限制 強制規定駕駛在路上的總時間上限 (例如 8 小時)。除非您也套用時間長度限制，強制求解器將工作負載分配給更多車輛，否則單純新增車輛並不會縮短路線。

更新路線圖

您通常需要更新路線規劃，同時保持基本路線不變，例如在現有司機的行程中新增取貨地點。如要這麼做，請使用插入參數，為 API 提供先前解決方案的起點，讓 API 修改現有方案，而不是從頭計算新方案。

以下是使用插入參數更新路徑規劃的不同方式：

  • 將前一次回應中的路線傳遞至新要求的 injectedFirstSolutionRoutes 欄位。這能加快最佳化搜尋速度，並在每日作業開始前重新規劃，例如整合最後一刻的運送作業。
  • 使用 injectedSolutionConstraint 欄位控制變更程度。這項功能在作業已開始時非常實用，可讓您保留司機目前的路線，或修正已執行的部分行程。
  • 請將 interpretInjectedSolutionsUsingLabels 設為 true，確保更新後的路線仍指派給正確的車輛。在實驗中新增或移除運送和車輛時，這項功能非常實用，因為系統會使用標籤 (而非索引) 比對路線。因此所有車輛和貨運標籤都不得重複。

整合路線規劃

最終路線規劃是資料物件，代表在遵循限制和目標的情況下，以最佳方式管理資源和工作。將這份路線圖整合到系統中，用於日常作業。 這通常包括為車隊管理員提供路線規劃圖，以及向司機發送即時路線指示。

圖表

如要讓車隊管理員驗證及監控路線規劃，您可以透過下列方式，以視覺化方式呈現路線規劃：

如要讓車隊管理員驗證及監控路線規劃，您可以在資訊主頁地圖上顯示路線規劃。視目前的開發階段而定，您可以透過下列方式查看路線圖：

  • 免程式碼探索：您可以使用開放原始碼的路線最佳化應用程式，瞭解 API 如何將資料轉換為地圖上的實際路徑。這個網頁應用程式是探索工具，可讓您建構情境、調整限制參數，並在編寫任何程式碼前，以視覺化方式呈現產生的路線計畫。
  • 顯示造訪順序：您可以在地圖上以編號點顯示造訪順序，在自己的系統中評估最佳化和調度計畫。方法是在 API 回應的每條路線中，找出 visits 陣列。這個陣列中的項目會按照駕駛人應執行的順序排列。您可以疊代這份清單，使用 shipmentIndex 擷取每個停靠站的位置座標，並使用地圖程式庫，根據清單中的順序在地圖上顯示編號標記。
  • 繪製實體路線：您可以在地圖上查看確切的規劃路徑，瞭解最佳化工具選擇特定順序的原因。這條折線代表規劃和評估的預定路徑，而非駕駛人實際行駛的即時路線。在要求中設定 populatePolylines: true，即可取得每條路線的 encodedPolyline 欄位，並使用 Maps JavaScript API 的 google.maps.geometry.encoding.decodePath() 方法解碼。

派送給司機

您可以使用 Navigation SDK，將即時路線整合至司機應用程式，或提供 Google 地圖消費者應用程式的深層連結。

  • Navigation SDK：如果您有自訂司機應用程式，可以整合 Navigation SDK for Android 或 iOS，在應用程式中提供即時路線指引。您可以將 API 回應中的工作資訊整合到系統中，並使用 SDK 進行導航。如要將 API 回應中的路線傳遞至 SDK，請在要求中設定 populateTransitionPolylines: true。這會為回應中的每個轉場效果生成 routeToken。
  • 車隊引擎： 如要進行進階車隊管理，您可以將 API 產生的路線規劃匯入車隊引擎，即時監控路線執行情況。雖然 API 會提供預定路徑的折線供評估，但 Fleet Engine 會將您規劃的造訪順序與即時車輛追蹤功能配對。