路線圖生命週期

本頁面說明如何使用 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，確保更新後的路線仍指派給正確車輛。在實驗中新增或移除貨運和車輛時，這項功能會很有幫助，因為它會使用標籤 (而非索引) 比對路線。因此所有車輛和貨運標籤都不得重複。

整合路線規劃

最終路線計畫是資料物件，代表資源和工作的最佳化管理，同時遵循限制和目標。將這項路線規劃整合至系統，用於日常作業。 這通常包括為車隊管理員顯示路線規劃，以及向駕駛人傳送詳細的導航指示。

圖表

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

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

• 免程式碼探索：您可以使用開放原始碼的 Route Optimization 應用程式，瞭解 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 會將您規劃的拜訪順序與即時車輛追蹤資訊配對。