路線圖生命週期

本頁面說明使用 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。
  • Fleet Engine：如要使用進階車隊管理功能，可以將 API 產生的路線規劃匯入 Fleet Engine，即時監控路線執行情況。雖然 API 會提供預定路徑的折線供評估，但 Fleet Engine 會將您規劃的造訪順序與即時車輛追蹤功能配對。