TW202036408A - 通訊伺服器裝置及其操作方法 - Google Patents

Abstract

用於管理酬載（202、204）以供車輛（408）運輸的通訊伺服器裝置（102）、以及其操作方法。通訊伺服器裝置被配置為：對於各自的不同酬載類別的複數酬載（202、204），每一酬載類別與獨有的車輛能力要求相關聯，針對第一酬載類別的第一酬載確定（206）表明了第一車輛能力要求的第一酬載屬性參數的值。針對第二酬載類別的第二酬載，確定表明了第二車輛能力要求的第二酬載屬性參數的值（208）。將第一酬載屬性參數的值及第二酬載屬性參數的值與關聯於車輛的酬載能力資料進行比較（210），並且使用比較結果（212）來確定車輛運輸第一酬載及第二酬載兩者的能力。

Description

通訊伺服器裝置及其操作方法

本發明與一種用於管理酬載以供車輛運輸的通訊伺服器裝置有關。本發明還與一種用於管理酬載以供車輛運輸的方法、以及包括用於實施該方法的指令的電腦程式產品及電腦程式有關。

本發明特別地但非排他地適用於即時彙整聯運車輛的酬載項目以及酬載訂單。

已知有用於管理酬載以供車輛運輸的多種方法，包括於其中依運輸這些酬載的順序指定酬載的方法。例如，已知根據車輛的容量指派酬載的方法。在一種先前考慮的方法中，車輛的容量是根據合併的訂單的複雜性而受限制。在另一種先前考慮的方法中，酬載在路線中的給定彙整點處被彙整、並且藉由確定是否存在跨越複數訂單分支的重疊時間窗來考慮這些訂單分支之間的相容性。在一種先前考慮的方法中，按相似性對訂單進行分組。在另一種先前考慮的方法中，根據遞送地址對訂單進行聚類。

然而，這樣的方法通常沒有考慮可能需要車輛中不同類型的容量的不同類型的酬載。此外，這些方法不能解決酬載或訂單的即時彙整。此外，在其他方面，這些方法中沒有任何方法考慮到如何管理尚未被彙整或聚類的訂單或酬載。

本發明的觀點被定義在獨立項中。本發明的一些可選特徵被定義在附屬項中。

本文中揭露的技術的實施可以提供顯著的技術優勢。例如，可以在相同運輸系統中有效地管理或彙整不同類型的酬載以及酬載項目，以容許更有效地利用運送容量。這種藉由在相同彙整佈置中管理不同類型的酬載以更有效地利用運送容量也因為對於相同數量的酬載項目需要更少的車輛以及車輛運送計劃而允許例如管理系統的更大資料處理容量以及更低計算負擔。此外，由於運送效率增加，對於系統的相同數量的酬載訂單，用於本文所述的運輸佈置的範例的車輛將需要較少的維護並且將經歷較少的磨損。

此外，當系統的車輛已經在使用中或在運送中時，可以進行管理或彙整，以利用原本未使用或未充分利用的容量。此外，在初始階段未被彙整或匹配的訂單或酬載可以在捆綁或彙整過程中的其他階段被重新彙整或重新指派，以允許彙整更多訂單及/或酬載、以及使用車輛的更多未充分利用的容量。在至少一些實施方式中，本文揭露的技術允許確定表明了不同類別的酬載的車輛能力的酬載屬性、以及將其與車輛的酬載能力進行比較，以解決先前考慮的方法無法管理不同類型的酬載，不同類型的酬載需要不同類型的車輛容量。

首先參考圖1，示出了通訊系統100。通訊系統100包括通訊伺服器裝置102、服務提供者通訊裝置104以及使用者通訊裝置106。這些裝置經由各自的通訊鏈路110、112、114而被連接在通訊網路108（例如，網際網路）中。通訊裝置104、106可能能夠經由例如包括行動蜂巢式通訊網路的公共交換電話網路（PSTN網路）之類的其他通訊網路進行通訊，但為清楚起見，在圖1中省略該其他通訊網路。

通訊伺服器裝置102可以是如圖1中示意性示出的單一伺服器、或者具有由分佈在複數伺服器元件上的伺服器裝置102執行的功能。在圖1的範例中，通訊伺服器裝置102可以包括數個單獨的元件，該元件包括但不限於微處理器116、用於裝載可執行指令120的記憶體118（例如，諸如RAM之類的揮發性記憶體），可執行指令定義了在處理器116的控制下伺服器裝置102執行的功能。通訊伺服器裝置102還包括輸入/輸出模組122，該輸入/輸出模組122允許伺服器經由通訊網路108進行通訊。使用者介面124被提供以用於使用者控制、且可包括例如常規計算週邊裝置，該常規計算週邊裝置例如顯示監視器、電腦鍵盤等等。伺服器裝置102還可以包括資料庫126。

服務提供者通訊裝置104可以包括數個單獨的元件，該元件包括但不限於微處理器128、用於裝載可執行指令132的記憶體130（例如，諸如RAM之類的揮發性記憶體），可執行指令定義了在處理器128的控制下裝置104執行的功能。裝置104還包括輸入/輸出模組134，該輸入/輸出模組134允許裝置104經由通訊網路108進行通訊。提供使用者介面136以用於使用者控制。如果服務提供者通訊裝置104是例如智慧型手機或平板裝置（或安裝在車輛中的使用者介面），則使用者介面136將是觸控面板顯示器的形式，這在許多智慧型手機以及其他手持裝置中很普遍。替代地，如果服務提供者通訊裝置是例如常規的桌上型或膝上型電腦，則使用者介面可以採用例如常規計算週邊裝置的形式，例如顯示監視器、電腦鍵盤等。否則，如果服務提供者通訊裝置104是例如集線器或監視裝置、控制器或伺服器、或另一系統處理裝置，則使用者介面可以採用觸控面板或常規計算形式。

使用者通訊裝置106可以是例如具有與標籤通訊裝置104的硬體架構相同或類似的硬體架構的智慧型電話或平板裝置。

另外參考圖2，範例性通訊伺服器裝置102是用於管理酬載以供車輛運輸，如上所述，其包括例如處理器116以及記憶體118。該裝置被定址到各自的不同酬載類別的複數酬載，每一酬載類別與獨有的車輛能力要求相關聯，例如酬載類別A（202）以及酬載類別B（204）。通訊伺服器裝置被配置為在處理器的控制下執行記憶體中的指令120以：針對第一酬載類別（類別A）的第一酬載，確定206表明了第一車輛能力要求的第一酬載屬性參數的值；針對第二酬載類別（類別B）的第二酬載，確定208表明了第二車輛能力要求的第二酬載屬性參數的值；將第一酬載屬性參數的值及第二酬載屬性參數的值與關聯於該車輛的酬載能力資料進行比較210；以及使用212比較結果來確定車輛運輸第一酬載及第二酬載的能力。

如上所述，本文描述的技術與管理多種類型的酬載或將多種類型的酬載彙整到車輛運輸架構中有關。考慮了若干不同類型或類別的酬載、內容物或貨物，例如乘客以及貨物，貨物例如包裹、食品、藥品、花卉以及傢俱。因此，酬載是異質的，而不是如先前考慮的系統中是同質的，該系統僅考慮例如貨物或乘客。

對於每一車輛，確定或獲得了（如果先前或在別處確定）與不同類型的酬載或內容物有關的不同類型的容量。還為每一車輛確定了這些不同類型的容量總數。這允許彙整包含或列出不同類型酬載的運輸訂單、並有效利用車輛的容量。訂單本身可以源自例如圖1中所示的使用者106或服務提供者104裝置；例如，使用者可以訂購接送乘客服務，或者服務提供者可以確定要經由網路運輸要遞送給客戶的包裹。

在範例性技術中，引入了若干約束或條件，以允許對來自訂單的酬載以及酬載項目的管理或彙整進行最佳化，以在彙整過程中有效地指派酬載或貨物。例如：針對給定車輛中每一酬載類型，目前佔用的容量；酬載類型與車輛的相容性，以及該車輛內不同酬載類型之間的相容性；對於每一酬載類型以及對於每一訂單的服務等級都可以作為約束，以為要比較的訂單或酬載以及任何給定車輛確定有效解決方案。

在一個範例中，酬載類別A被定義為下列其中之一：乘客；貨物；或易腐物。當然可以合併類別（例如，乘客也可能隨身攜帶貨物，例如行李），但是可以為合併定義其他類別（例如，定義其他類別「乘客加貨物」）。因此，酬載類別（或分類或類型）可能涵蓋不同的酬載項目（或實際上在單一酬載內有複數酬載項目）；例如，貨物可能具有各種大小以及形狀，乘客可能對他們的旅程有不同的要求；可以考慮各種其他因素以有效地調節酬載項目。

因此，每一酬載類別或酬載（或酬載項目）具有相關聯的屬性、特性或分類器/分類，其允許對要管理的該酬載的獨特或特定要求。例如，對於給定的酬載，酬載屬性可以包括可以在車輛的哪個區域中運輸酬載、酬載的大小或形狀、必須多緊急地運輸酬載、是否存在用於酬載的最高或最低溫度等等。

對於給定的酬載類別，可以隱含某些酬載屬性、可以定義其他酬載屬性（例如，在處理訂單期間被指定、或者藉由從資料庫中擷取儲存的細節而被指定）、以及其他屬性可能不是可指派給該酬載類別。對於乘客類別中的酬載，將暗示必須在車輛的車廂（而不是後車廂）中運輸乘客。可以定義乘客是否有其他要求，例如車輛的最小/最大其他乘客乘坐數、或較佳的最大站數。這些可以從乘客的訂單、或者可以從儲存的偏好中取得。其他屬性可能不能指派（防止被指派）給乘客，例如要使用多少後車廂容量。

對於每一酬載屬性，將有酬載屬性參數值，以為酬載或酬載項目定義精確的車輛能力要求是什麼。例如，針對酬載的最高溫度的酬載屬性將具有該最高溫度的酬載屬性參數值，例如攝氏4度。對於要求的車廂位置的酬載屬性，參數值可以是「後車廂」或「車廂」或「冷藏區」。對於大小的酬載屬性，可能有幾個屬性參數，每一參數具有一值；例如，寬度Xcm、長度Ycm、深度Zcm。對於佔用的相似或替代的酬載屬性，針對可用的乘客空間數，參數值可以例如是1至4的值，或者針對佔用的標準貨物空間數，參數值可以是1到n的值。對於重量屬性，參數值可以是重量，例如10 kg。對於緊急屬性，參數值可以是限制遞送的時間，例如熱食品將過冷的時間、或者生物醫學項目的最大運送時間、或者醫學放射性同位素的半衰期或其他指數。對於酬載類別「易碎」，屬性參數可以包括路線上的最大站數、行駛穩定性或路線品質（穩定性/品質已被評價以確定這些參數的值）的最大臨界值。

相應地，與車輛相關聯的酬載能力可以由車輛屬性及/或車輛屬性參數值表示。這些屬性或值可以對應於各自的酬載屬性參數的調節。例如，對於要求的車廂位置的酬載屬性，值為「後車箱」、車輛具有車廂類型的車輛屬性與車輛屬性參數值為「後車箱」及「車廂」將是相容的。對於車廂乘客容量的車輛屬性，對於五人座車輛，參數值可以為「4」。這些車輛屬性以及參數值可以被記錄在資料記錄中的車輛能力資料組成中，例如圖5b所示。

再次參考圖2，酬載類別A將具有獨有或特定的車輛能力要求A’；與貨物酬載相較下，對於乘客酬載，運輸車輛的容量要求將明顯不同。例如，遞送車輛可能沒有乘客車廂，且類似地滿載乘客的汽車在後車廂中可能仍有用於貨物的空間。

然而，儘管不同的酬載類別將具有明顯不同的屬性，這將要求明顯不同的車輛能力，但是也將存在不同類別共有的屬性。例如，乘客以及貨物都可能需要以特定時間遞送或放下。

此外，將酬載的屬性參數值與關聯於車輛的能力進行比較可以包括（或限於）將屬性參數值與另一酬載（例如已佔用車輛（或被安排以佔用車輛）的酬載）的屬性參數值進行比較。例如，可以將貨物酬載項目的尺寸參數值與另一貨物酬載項目的尺寸參數值進行比較，以檢查它們是否都適合車輛的後車廂。如果兩個酬載都需要使用被限於一個酬載項目的食品儲存區域，則這將限制運輸兩者的車輛能力，除非它們在運送的不同階段被運輸。

此外，比較可以不僅與一部車輛進行、而且可以與多部車輛進行，以針對給定的酬載、或酬載類別及屬性的組合確定最佳車輛。

在範例中，給定酬載或訂單的酬載類別可以是合併、或者包括複數類別，應為其取得參數值。例如，乘客也可能有行李，需要考慮貨物以及乘客屬性兩者。

還應注意，與車輛的能力相比，對系統的各種約束（在此範例中由類別、以及屬性及其參數值表示）也將彼此影響。例如，如果安排貨物酬載佔用車廂區域，則儘管該能力最初可用於該車輛，乘客將不再能夠坐在那裡。如果幾個酬載項目具有時間限制屬性，那麼如果現在有太多酬載以至於它們不能全部及時到達目的地，則用酬載完全佔用車輛的解決方案也可能不是滿足所有時間限制約束的解決方案。因此，在酬載屬性與車輛能力之間進行的比較將考慮所有屬性以及參數，以找到一或更多最佳解決方案而一起有效地管理複數酬載。

一旦已將酬載屬性參數值與關聯於車輛的能力資料進行比較210，此比較的結果就可以用於確定車輛是否確實可以運輸這些酬載。以此方式，酬載的特性或屬性可以用作對用於填充或佔用可用車輛的可能解決方案的約束。因此，這些技術可以用作在一組可用車輛之間最佳化一組酬載的分配或分佈的方法。類似地，這些技術當然可以用於相反目標的最佳化中，以最佳化一組可用車輛對一組給定酬載的分配。

當然，一旦已建立用於參照車輛能力來約束酬載屬性的系統，這接著可以用於捆綁或彙整訂單。這些訂單可能包含酬載及其類別及/或屬性的細節、並可能指定酬載的拾取及放下位置。如上所述的訂單可以例如來自使用者（例如訂購位置之間的乘客運輸）、或者來自服務提供者，該服務提供者可能已經將貨物以及拾取及放下位置匯編成訂單。

圖3是示出一系列酬載及訂單的範例的示意圖。給定的車輛具有初始位置1。第一包裹2具有發送者位置、且第二包裹3具有不同的發送者位置。車輛離開初始位置並行進以進行拾取2及3。然後，車輛行進以在第一食品訂單餐館位置4拾取第一食品酬載、並在第二食品訂單餐館位置5拾取第二食品酬載。接著，車輛在位置6接載第一乘客、並在位置7接載第二乘客。然後，車輛針對這些各自的酬載以行進至各自的放下位置。在位置8放下第一乘客、以及在位置9放下第二乘客。在10處放下第一食品訂單，在11處放下第二食品訂單。最後，在位置12處放下第一包裹，在13處放下第二包裹。

這些酬載當然可以源自使用者或服務提供者的複數訂單。例如，在不同位置的第一乘客以及第二乘客可能是由兩個不同使用者的不同訂單導致的。在不同位置的兩個包裹可能來自相同或不同的使用者或服務提供者的不同訂單。這兩個食品訂單可能是從不同位置為相同使用者訂購的、或為不同使用者訂購的。

在這種情況中的這些酬載可以全部被容納在同一車輛中，且這將例如由藉由限制酬載的屬性、確定屬性參數的值並將這些與車輛的能力以及與此訂單收集（本文中稱為訂單束）中其他酬載的計劃佔用進行比較的上述方法而已被確定。

此外，可以在收集、聚集或捆綁訂單中管理拾取以及放下位置，以產生不僅從能力使用的觀點而且從車輛行進距離的觀點來看都是有效的訂單束或訂單集。

例如，給定了包括酬載以及位置的初始訂單組，最初可以拒絕具有在（例如，距初始訂單的）給定臨界值距離之外的位置的任何酬載或訂單。因此，可以進行訂單比較，首先藉由位置的相似性將訂單分組且接著藉由如上所述的有效率的車輛使用來最佳化訂單、或者反之亦然。第三種模式可以平行地最佳化兩個方面。

在範例性技術中，藉由將訂單位置解析為圖形問題來執行訂單位置的比較。所有訂單的拾取以及放下位置都被表示為圖中的節點。圖形中任兩個節點之間的連結被表示為弧。另外，目前車輛位置可以被包括在圖形分析中。

在一個範例中，比較了兩組訂單，每一訂單包含酬載以及位置。基於依照旅行推銷員問題（TSP）的建模解決方案（為本領域已知的建模典範）計算出兩組訂單的匹配分數。基本上，這種類型的建模確定了將訪問圖中所有節點的最短路徑。因此，可以藉由確定為了完成這兩組訂單還需要行進多遠來比較兩組訂單。因此，可以藉由比較訂單組的旅行時間的增加來評估不同的訂單組比較。可以設定臨界值合併直接行程時間以拒絕會過度增加行程時間的任何訂單或訂單組。在一範例中，訂單批次處理效率分數被計算為： 訂單批次處理效率=總訂單直接行程時間/批次駕駛員行程時間。

其中總訂單直接行程時間是在單獨行程中要完成每組訂單所花費的時間，並且批次駕駛員行程時間是在合併行程中要完成所有訂單所花費的時間。

雖然可以用此方式收集或捆綁訂單，但也可以應用如上所述的約束。因此，在範例性技術中的匹配過程中，可以對訂單進行比較以找到足夠有效的束，但是如果訂單中的酬載與車輛不相容、或彼此不相容、或與訂單/酬載/行程時間的服務等級要求不相容、或者如果車輛對於特定酬載已滿載，則可以拒絕訂單。

此外，在車輛本身是在途中時，可以將訂單或酬載與車輛相容性資料進行比較。例如，酬載或訂單可以與已經在其他酬載的取放位置之間途中的車輛進行比較（或是針對這些進行排程），並且可能已經將酬載指派或裝載到車輛上。然後將即時進行酬載或訂單與車輛酬載或指派的訂單之間的比較。下文將參考圖6更詳細地描述類似的範例性技術。

圖4是示出用於管理酬載以供車輛運輸的範例性通訊系統的示意性方塊圖。服務提供者的伺服器402（其可以類似於圖1中的裝置104）以及使用者裝置404（其可以類似於圖1中的裝置102）是產生訂單的裝置。然後將訂單傳送到根據本文所述的技術處理訂單以及酬載的通訊伺服器406，以有效率地管理及/或彙整訂單以及酬載。通訊伺服器406還與一或更多車輛408、以及伺服器或資料庫410通訊。伺服器410可以為運輸網路的車輛提供備份資料供應、或者可以儲存車輛已經進行或正在進行的行程的細節、或車輛可能進行的固定或重複行程的細節。

通訊伺服器406使用來自車輛408以及伺服器或資料庫410的資訊以進行酬載及/或訂單之間的比較，以便如本文所述來確定用於那些酬載及/或訂單的車輛能力。伺服器402及410、使用者裝置404及車輛408與通訊伺服器406之間的通訊當然可以經由例如圖1中所示的網路108之類的網路。

當然應注意，車輛408可以是自動駕駛車輛。在這種情況下，根據本文描述的技術，用於車輛的編程可以包括由酬載及訂單的比較所確定的路線。

對於裝置402及404，軟體應用程式可以包括介面或GUI中的特徵以及功能性，包括但不限於下列中的一或更多：用於輸入所請求服務的開始位置或起始位置的部分；用於輸入所請求服務的目的地位置的部分；用於選擇服務類型（例如，計程車、私家車、共乘（ride-share）或汽車共乘（car-pool）、接駁車、公共汽車、遞送等）的部分；地圖，其可以包括使用者的計算裝置的目前位置、所請求的服務的開始或起始位置、所請求的服務的結束或目的地位置、或一或更多可用服務提供者的位置的指示；最喜歡的起始以及目的地位置；以及至其他特徵及功能性的連結。

用於管理酬載的一些過程可能類似於用於管理與運輸相關的服務（例如，計程車、私家車服務、接駁車、共乘、電子叫車服務、遞送服務等）的已知技術，包括接收訂單、執行搜尋使用者位置附近的適合且可用的服務提供者或車輛（或使用者提供的開始或起始位置）、以及將適合且可用的服務提供者與服務請求進行匹配。

圖5a以及圖5b是示出資料記錄550的範例以及處理用於管理供車輛運輸的酬載的那些資料記錄的示意圖。在本文所述系統的使用範例中，當使用者希望下訂單時，使用者通訊裝置（例如，行動電話）使用在使用者的裝置上運行的應用程式來產生訂單資料。服務請求者的應用程式通常以封包的形式輸出訊息，封包具有表明該封包的ID以及定址資訊的標頭。如圖5a以及圖5b所示，封包的內容（酬載、欄位）由使用者的訂單資訊組成，且在圖5a的此範例中，此訂單資訊包括：酬載屬性資料組成504以及位置資料組成506。類似的資料記錄（來自另一來源，可能是另一使用者）類似地具有標頭503、酬載屬性資料組成505以及位置資料組成507。

例如在本文所述的範例性通訊伺服器裝置中執行的本文所述的技術可以使用資料記錄550的資料欄位來確定如本文所述的資料記錄之間的比較。例如，可以處理這些資料記錄的位置資料組成506及507以產生比較。在這種情況下，資料記錄被合併為訂單束資料記錄，該訂單束資料記錄具有標頭522、束屬性資料組成524（藉由處理資料記錄550的訂單酬載屬性資料組成而產生）以及類似地束位置資料組成526（藉由位置組成的比較而產生）。

在圖5b中，與來自另一資料記錄的酬載屬性資料組成504相比，處理了來自一個資料記錄的車輛能力資料組成554，以產生用於另一資料記錄的資料組成欄位564（標頭562），該欄位由針對車輛能力資料組成554與屬性資料組成504之間的比較的比較結果填充。

在用於捆綁及彙整酬載及訂單的範例性技術中，採取了許多步驟： 1. 運輸訂單例如按照位置被捆綁在一起。如果給定的束超過所確定的效率臨界值，或者如果束內的訂單遲來（太遲而無法在（2）中被匹配），則將束指派給新的/未佔用的車輛。如果數個訂單的拾取及放下位置彼此靠近，則將這些訂單捆綁在一起。訂單捆綁可減小問題大小、以及促進快速的即時彙整解決時間。新訂單捆綁或彙整的好處來自分數效應–與在途彙整相比，候選集合更大，新訂單彙整品質通常更好；大多數的彙整束來自類似的拾取位置。 2. 對於低於此效率臨界值的束，確定束與目前由佔用/在途車輛執行的運送計劃之間的匹配分數。將每一束與每一在途車輛運送計劃進行比較。對於高於臨界值的匹配分數，為具有該匹配運送計劃的車輛添加訂單束。一旦完成了在途彙整，則立即更新該在途車輛的駕駛員計劃。於在途彙整中，對所有在途車輛執行搜尋。從候選集中剔除遠離任何訂單拾取位置的那些車輛。這種方法減少了預處理時間以及解決時間。在途彙整的好處在於，其可以充分利用在途車輛的容量、且允許車輛在其目前行程結束之前為更多訂單提供服務。 3. 任何剩餘的訂單束不是（a）被彙整在一起並被指派給新的/未佔用的車輛、就是若該彙整不足夠有效率則（b）被分解回單獨的訂單並返回（1）以重新綑綁。

在其他範例性技術中，於上描述的或參考圖6的技術的特徵可以單獨（或以單獨的組合）使用；例如，在比參考圖6所述的方法更簡單的方法中，可以使用比較訂單的預備階段，以便提供訂單束。在其他技術中，在車輛的訂單履行行程期間，可以將訂單（或訂單束）與指派給該車輛的訂單進行比較。可選地，可以將複數訂單聚類，以提高訂單或酬載比較的效率。

圖6是示出了用於管理酬載以供車輛運輸的範例性方法的步驟的流程圖600。在步驟1（602），如上所述，從各個訂單產生訂單束。這些訂單束可以從全新的訂單、或從回收的訂單（請參見下文）、或者從兩者的組合中產生。

捆綁步驟602可以包括如上所述的TSP建模。但是，也可能考慮例如上述那些約束之類的約束，使得訂單束已填充有彼此屬性相容的酬載。

如果訂單束被有效率地利用，則該束被傳遞以被指派620給空車。為了確定束的充分效率，如上所述，可以應用臨界值。在一個範例中，效率將這樣計算： （a）訂單批次效率=總訂單直接行程時間/批次駕駛員行程時間。 （b）駕駛員行程負載=訂單數量 （a）以及（b）兩者都是用於確定是否應將（來自602的）束指派給空車620的標準。

如果在步驟1中訂單束包含遲來的訂單，則即使不滿足所述的兩個條件（或即使效率未超過臨界值），束也將類似地被傳遞以指派給新車輛。這是因為遲來的訂單將需要緊急履行，且因此必須權衡訂單彙整過程中的某些效率以進行這件事。

如果在步驟1中訂單束未被充分利用（並且沒有遲來的訂單），則將其傳遞到步驟2.1（604），其中針對該（或每一）訂單束與每一在途駕駛員計畫配對計算匹配分數。匹配分數的比較過程可以如上所述：TSP建模可用於針對訂單束和每一駕駛員計劃確定位置有多類似，且此外（或替代地），使用約束的在途車輛能力與酬載之間的比較可以如上所述進行。

在步驟2.2（606），一些比較的分數將足夠高，使得給定訂單束可以被指派630到給出高比較或匹配分數的該在途駕駛員計劃。在特定技術中，使用指派演算法或合併最佳化演算法（例如，已知的Kuhn-Munkres演算法）以最佳化比較分數，使得在將束與在途駕駛員計劃進行匹配中的總效率最大化。

如果此步驟仍未找到訂單束的匹配，則在步驟3.1（608），接著將未充分利用的未匹配的訂單束聚類。這可以藉由將每批次訂單束按照其發生時一樣進行而簡單地完成，但是在此範例中，使用群集大小限制的聚合式聚類方法來執行聚類。這種聚類方法不需要預先定義群集的數量。其基於最近鄰居鏈演算法，增加了群集大小約束以及最大距離約束。

一旦訂單束已被聚類，在步驟3.2（610），減少每一群集中的訂單束的數量（與步驟3.1中的可用的不匹配束的數量相比），並進行進一步的彙整步驟。這可以使用TSP建模、或應用約束的比較、或兩者。這可以從這些彙整的訂單束中提供行程計劃。其他技術可以用於此彙整階段。例如，可以使用已知的容量限制的車輛路線問題（Capacitated Vehicle Routing Problem，CVRP）演算法，例如具有收送及時間窗約束的容量限制的車輛路線問題（CVRPPDTW），以便為這些束提供彙整的行程計劃。

如果此最後階段已產生超過效率臨界值（類似於為步驟1定義的效率臨界值）的訂單束行程計劃，則將得出的駕駛員計劃指派給空車。

如果在步驟3.2之後仍然有低效的訂單束，則將這些低效的訂單束分解為其組成的訂單、並用作回收訂單以幫助在步驟1中產生初始訂單束。

應當理解，僅用範例的方式描述了本發明。在不脫離所附申請專利範圍的精神及範圍下，可以對本文描述的技術進行各種修飾。所揭露的技術包括可以獨立方式或彼此組合提供的技術。因此，關於一種技術描述的特徵也可以與另一種技術組合呈現。

1、4、5、6、7、8、9、10、11、12、13:位置 2、3:包裹 100:通訊系統 102:通訊伺服器裝置 104:服務提供者通訊裝置 106:使用者通訊裝置 108:通訊網路 110、112、114:通訊鏈路 116、128:微處理器、μp 118、130:記憶體 120、132:指令 122、134:輸入/輸出模組、I/O 124、136:使用者介面、UI 126:資料庫、DB 402、410:伺服器 404:使用者裝置 406:通訊伺服器 408:車輛 502、503、522、552、562:標頭 504:訂單酬載屬性資料組成 506:訂單位置資料組成 505:訂單酬載屬性資料組成 507:訂單位置資料組成 524:束酬載屬性資料組成 526:束位置資料組成 554:車輛能力資料組成 564:比較結果資料組成 550:資料記錄 600:流程圖

現在將僅利用範例並參考附圖來描述本發明，其中： 圖1是示出具有用於管理酬載以供車輛運輸的範例性通訊伺服器裝置的通訊系統的示意性方塊圖； 圖2是示出用於管理酬載以供車輛運輸的範例性方法的步驟的流程圖； 圖3是示出一系列酬載以及訂單的範例的示意圖； 圖4是示出用於管理酬載以供車輛運輸的範例性通訊系統的示意性方塊圖； 圖5a以及圖5b是示出資料記錄以及處理那些資料記錄以用於管理酬載以供車輛運輸的範例的示意圖；以及 圖6是示出用於管理酬載以供車輛運輸的範例性方法的步驟的流程圖。

Claims (23)

1. 一種用於管理酬載以供一車輛運輸的通訊伺服器裝置，包括一處理器以及一記憶體，該通訊伺服器裝置被配置為在該處理器的控制下執行該記憶體中的指令以： 對於各自的不同酬載類別的複數酬載，每一酬載類別與獨有的車輛能力要求相關聯， 針對一第一酬載類別的一第一酬載，確定了表明一第一車輛能力要求的一第一酬載屬性參數的一值； 針對一第二酬載類別的一第二酬載，確定了表明一第二車輛能力要求的一第二酬載屬性參數的一值； 將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較；以及 使用一比較結果來確定該車輛運輸該第一酬載以及該第二酬載兩者的一能力。
2. 如請求項1所述的通訊伺服器裝置，其中該裝置被配置為：初始比較該第一酬載屬性參數的該值與該酬載能力資料；以及然後將該第二酬載屬性參數的該值與該酬載能力資料進行比較。
3. 如請求項1或請求項2所述的通訊伺服器裝置，其中與該車輛相關聯的該酬載能力資料包括用於與該車輛相關聯的一酬載的一或更多酬載屬性參數。
4. 如前述請求項中任一項所述的通訊伺服器裝置，其中該第一酬載類別包括下列其中之一：一乘客；一貨物；以及一易腐物。
5. 如請求項4所述的通訊伺服器裝置，其中該第一酬載類別包括貨物，以及其中該第一酬載屬性參數是下列中的一者或更多：一尺寸；一形狀；一重量；一指定裝載區；一急迫性；一要求的溫度；以及一易碎性。
6. 如請求項4所述的通訊伺服器裝置，其中該第一酬載類別包括乘客，以及其中該第一酬載屬性參數是下列中的一者或更多：一急迫性；以及一要求的服務等級。
7. 如請求項4所述的通訊伺服器裝置，其中該第一酬載類別包括易腐物，以及其中該第一酬載屬性參數是下列中的一者或更多：一尺寸；一形狀；一重量；一易腐性；一指定裝載區域；一急迫性；一要求的溫度；以及一易碎性。
8. 如前述請求項中任一項所述的通訊伺服器裝置，其中，與該車輛關聯的該酬載能力資料包括與各自的酬載屬性參數的調節對應的一或更多車輛屬性參數值。
9. 如前述請求項中任一項所述的通訊伺服器裝置，其中該裝置被配置為使用酬載屬性參數值以及一車輛酬載能力資料以指派計算用於運輸該各自的酬載的解法的限制。
10. 如前述請求項中任一項所述的通訊伺服器裝置，其中該裝置被配置為：在該車輛的一行程期間，將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較。
11. 如前述請求項中任一項所述的通訊伺服器裝置，其中該裝置被配置為獲得用於運輸酬載的訂單，其中一第一訂單包括至少該第一酬載以及至少一第一訂單位置；以及一第二訂單包括至少該第二酬載以及至少一第二訂單位置。
12. 如請求項11所述的通訊伺服器裝置，其中至少該第一訂單是經由至一通訊裝置的一通訊鏈路而獲得。
13. 如請求項11或請求項12所述的通訊伺服器裝置，其中該裝置被配置為將該第一訂單位置及該第二訂單位置與關聯於該車輛的一位置資料進行比較。
14. 如請求項13所述的通訊伺服器裝置，其中該裝置被配置為在該車輛的一訂單履行行程期間：將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較；以及將該第一訂單位置及該第二訂單位置與關聯於該車輛的一位置資料進行比較。
15. 如請求項11至請求項14中任一項所述的通訊伺服器裝置，其中，在將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較之前的一初步階段，該裝置被配置為： 初步比較該第一訂單與該第二訂單；以及 根據該初步比較的一結果，進行比較該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料。
16. 如請求項15所述的通訊伺服器裝置，其中該裝置被配置為：在初步比較該第一訂單與該第二訂單之後，在該車輛的一訂單履行行程期間，將該第一訂單及該第二訂單與被指派給該車輛的一訂單進行比較。
17. 如請求項16所述的通訊伺服器裝置，其中該裝置被配置為： 在將該第一訂單及該第二訂單與被指派給該車輛的該訂單進行比較之後，將包括該第一訂單及該第二訂單的複數訂單進行聚類；以及 將該第一訂單與被確定為在距離該第一訂單一最小聚類距離處的一第三訂單進行比較。
18. 如前述請求項中任一項所述的通訊伺服器裝置，其中該裝置被配置為：使用所確定的能力來產生用於傳輸到該車輛的一履行指令。
19. 一種用於管理酬載以供一車輛運輸的通訊系統，包括一通訊伺服器裝置、至少一使用者通訊裝置以及一通訊網路裝置，該通訊網路裝置可操作用於該通訊伺服器裝置以及該至少一使用者通訊裝置以經由該通訊網路裝置建立彼此的通訊，其中該至少一通訊裝置包括一第一處理器以及一第一記憶體，該至少一通訊裝置被配置為在該第一處理器的控制下執行該第一記憶體中的第一指令以： 產生用於運輸至少一第一酬載的一訂單， 以及其中： 該通訊伺服器裝置包括一第二處理器以及一第二記憶體，該通訊伺服器裝置被配置為在該第二處理器的控制下執行該第二記憶體中的第二指令以： 對於各自的不同酬載類別的複數酬載，每一酬載類別與獨有的車輛能力要求相關聯， 針對為一第一酬載類別的該第一酬載，確定表明了一第一車輛能力要求的一第一酬載屬性參數的一值； 針對一第二酬載類別的一第二酬載，確定表明了一第二車輛能力要求的一第二酬載屬性參數的一值； 將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較；以及 使用一比較結果以確定該車輛運輸該第一酬載以及該第二酬載兩者的一能力。
20. 一種在一通訊伺服器裝置中執行以用於管理酬載以供一車輛運輸的方法，該方法包括在該通訊伺服器裝置的一處理器的控制下： 對於各自的不同酬載類別的複數酬載，每一酬載類別與獨有的車輛能力要求相關聯， 對於一第一酬載類別的一第一酬載，確定表明了一第一車輛能力要求的一第一酬載屬性參數的一值； 對於一第二酬載類別的一第二酬載，確定表明了一第二車輛能力要求的一第二酬載屬性參數的一值； 將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於該車輛的一酬載能力資料進行比較；以及 使用一比較結果以確定該車輛運輸該第一酬載以及該第二酬載兩者的一能力。
21. 如請求項20所述的方法，包括： 將該第一酬載屬性參數的該值及該第二酬載屬性參數的該值與關聯於一或更多其他車輛的一酬載能力資料進行比較； 使用比較結果來確定該其他車輛運輸該第一酬載以及該第二酬載兩者的能力；以及 使用所確定的能力以指派該車輛中的一車輛用於運輸該第一酬載以及該第二酬載兩者。
22. 一種電腦程式產品，包括用於實施如請求項20所述方法的指令。
23. 一種電腦程式，包括用於實施如請求項20所述方法的指令。

Images