TWI778349B

TWI778349B - 韌體更新方法及通訊系統

Info

Publication number: TWI778349B
Application number: TW109112236A
Authority: TW
Inventors: 黃偉; 王凱民; 廖仁忠; 薛清益; 林亦欣; 謝孟哲
Original assignee: 中華電信股份有限公司
Priority date: 2020-04-10
Filing date: 2020-04-10
Publication date: 2022-09-21
Also published as: TW202139117A

Abstract

本發明實施例提供一種韌體更新方法及通訊系統。在此方法中，依據網路拓樸資訊對那些電表分群以產生數個更新群組，依據各更新群組中的電表的數量決定批次更新參數，並依據批次更新參數對些電表進行韌體更新作業。網路拓樸資訊相關於中繼站與受其服務的電表的連線情形，且各更新群組中的電表受相同的中繼站所服務。此批次更新參數包括單一更新群組的更新上限數。同時僅有更新上限數的那些電表執行韌體更新作業。藉此，可讓更新作業不影響用電資料上傳作業。

Description

韌體更新方法及通訊系統

本發明是有關於一種更新技術，且特別是有關於一種韌體更新方法及通訊系統。

先進讀表基礎建設(Advanced Metering Infrastructure，AMI)在政府積極的推動下，其通訊建設將扮演重要腳色。值得注意的是，部分電表可能需要透過不同通訊方式將電表資料上傳至後端平台(例如，頭端系統(Head-End System，HES)、電表資訊管理系統 (Meter Database Management System，MDMS)等)。而隨著電表建置數量增加，甚至高達數百萬具，通訊基地台(例如， NB-IoT、LTE-M等通訊基站)之負載亦隨之增加，且甚至影響設備的上網體驗。此外，在對這些電表更新的過程中，除了用電資料，相較更大資料量的更新資料也會同時湧入通訊基地台，從而造成資料擁塞，甚至會暫停服務。

有鑑於此，本發明實施例提供一種韌體更新方法及通訊系統，透過批次更新來錯開高負載情形。

本發明實施例的韌體更新方法，其適用於受中繼站服務下的數台電表。韌體更新方法包括下列步驟：依據網路拓樸資訊對那些電表分群以產生數個更新群組。網路拓樸資訊相關於中繼站與受其服務的電表的連線情形，且各更新群組中的電表受相同的中繼站所服務。依據各更新群組中的電表的數量決定批次更新參數。此批次更新參數包括單一更新群組的更新上限數。依據批次更新參數對些電表進行韌體更新作業。同時僅有更新上限數的那些電表執行韌體更新作業。

本發明實施例的通訊系統包括數台電表、中繼站及頭端管理系統。電表用以上傳資料。中繼站為那些電表提供網路服務，並接收那些電表所上傳的資料。頭端管理系統依據網路拓樸資訊對電表分群以產生數個更新群組，依據各更新群組中的電表的數量決定批次更新參數，並依據批次更新參數經由中繼站對電表進行韌體更新作業。網路拓樸資訊相關於中繼站與受其服務的電表的連線情形，且各更新群組中的電表受相同的中繼站所服務。此批次更新參數包括單一更新群組的更新上限數。同時僅有更新上限數的那些電表執行韌體更新作業。

基於上述，本發明實施例的韌體更新方法及通訊系統，透過分批更新來因應於大量設備同時更新情形，進而避免資料擁塞而影響其他設備的網路體驗。

為讓本發明的上述特徵和優點能更明顯易懂，下文特舉實施例，並配合所附圖式作詳細說明如下。

圖1是依據本發明的一實施例的通訊系統1的元件方塊圖。請參照圖1，通訊系統1包括(但不僅限於)一台或更多台中繼站30、一台或更多台電表50、及頭端管理系統100。

中繼站30例如是家用演進型節點B(Home Evolved Node B，HeNB)、eNB、次世代節點B(gNB)、基地收發器系統(Base Transceiver System，BTS)、轉發器(repeater)、路由器、交換器、或可程式化邏輯控制器(Programmable Logic Controller，PLC)。

電表50是用來量測電源的儀器，其可裝設於住宅、工廠、公司或各類場所。電表50是數位型電表，可讀取用電量，並據以發送至其他裝置。另值得注意的是，電表50可內建或外接通訊模組51。通訊模組51可能是支援NB IoT、CatM1、PLC、射頻(RF)或其他通訊技術的收發器，並可與中繼站30建立連線且接收或傳送訊號(即，中繼站30可提供對應通訊技術的網路服務給通訊模組51及/或電表50)。

在一實施例中，電表50透過通訊模組51上傳相關於用電資料、組態/設定、設備資訊、或韌體資訊等資料至中繼站30。中繼站30可能進一步轉送這些資料至頭端管理系統100或其他裝置。在另一實施例中，電表50透過通訊模組51下載相關於韌體更新檔、組態/設定等資料。

頭端管理系統100可能是獨立裝置或由多台裝置連接形成。頭端管理系統100中的裝置可以是桌上型電腦、筆記型電腦、平板電腦、智慧手機、伺服器、工作站等電子裝置。這些電子裝置包括諸如處理器(例如，CPU、DSP、ASIC等)、記憶體(例如，快取記憶體、硬碟等)等電子元件以執行運算功能(下文中，頭端管理系統100的主要運作是由其處理器執行)，並包括通訊收發器(例如，支援Wi-Fi、行動網路(例如，***(4G)、第五代(5G)或更後世代)、乙太網路、或光纖網路等通訊技術)以與中繼站30相互傳輸資料，進而經由中繼站30接收來自電表50的資料或傳送資料至電表50。

頭端管理系統100包括提供使用者介面110的軟體模組或設備(例如，網站伺服器、應用程式(APP)伺服器等)、以及韌體更新模組120(可能是由獨立裝置或軟體模組實現)。使用者介面110可能是網頁窗口、或應用程式介面，且使用者可透過輸入裝置(例如，觸控面板、鍵盤、按鍵、滑鼠等)在使用者介面110上輸入資料或觀看資訊(例如，資料統計、設備資訊、設定結果或資料分析結果等)。此外，韌體更新模組120用以管理韌體更新作業的主要運作，且其詳細運作待後續實施例詳述。

在一些實施例中，頭端管理系統100可處理及/或分析自動讀表系統(Automatic Meter Reading/Automated Metering Infrastructure，AMR/AMI)相關資料。例如，計算計費資料、組態/設定資料、負載控制、或時間同步等。

為了方便理解本發明實施例的操作流程，以下將舉諸多實施例詳細說明本發明實施例中通訊系統1之運作流程。下文中，將搭配通訊系統1中各裝置及其元件或模組說明本發明實施例所述之方法。本發明實施例方法的各個流程可依照實施情形而隨之調整，且並不僅限於此。

圖2是依據本發明的一實施例的韌體更新方法的流程圖。請參照圖2，頭端管理系統100的韌體更新模組120依據網路拓樸資訊對那些電表分群以產生數個更新群組(步驟S210)。具體而言，網路拓樸資訊相關於一台或更多台中繼站30與受其服務的那些電表50的連線情形(例如，連線或離線狀態、訊號強度、訊號品質或所用通訊技術等)。例如，第一中繼站30與第一至第三電表50連線；第二中繼站30與第四至第十電表50連線。頭端管理系統100可自中繼站30或電信局端的後台伺服器取得中繼站30的識別碼(例如，細胞識別碼、或其他代碼)、以及與中繼站30連線的電表的識別碼。在一實施例中，韌體更新模組120可依據所屬中繼站30而對所有電表50分群。即，各更新群組中的那些電表50受相同的一台中繼站30所服務。在另一實施例中，韌體更新模組120也可能依據地理區域、型號或韌體版本對所有電表50分群。

需說明的是，頭端管理系統100會定時或反應於特定觸發事件(例如，系統異常、資料擁塞等)更新網路拓樸資訊，以因應於即時變動的連線情形。

接著，頭端管理系統100的韌體更新模組120依據各更新群組中的那些電表的數量決定批次更新參數(步驟S220)。具體而言，批次更新參數包括各更新群組的更新上限數。為了避免更新過程中同時間過多資料傳輸，韌體更新模組120可基於網路拓樸資訊彈性地變動同時間各更新群組/中繼站50的更新上限數。

圖3是依據本發明的一實施例的批次更新參數決定方法的流程圖。請參照圖3，使用者透過使用者介面110選擇韌體更新清單。此韌體更新清單記錄特定區域的一台或更多台中繼站30所服務的一台或多台電表50(步驟S310)。韌體更新模組120可依據網路拓樸資訊判斷已離線的電表50及那些電表50的訊號強度(即，接收來自中繼站30的訊號強度)。接著，韌體更新模組120可自韌體更新清單中剔除已離線的電表50(即，其為離線狀態或未與中繼站30連線)(步驟S320)。此外，韌體更新模組120可依據網路拓樸資訊中那些電表50對應的訊號強度修改韌體更新清單(步驟S330)。例如，韌體更新模組120將當前訊號強度低於設定值或介於特定範圍內的電表50自韌體更新清單中剔除。需說明的是，步驟S320及S330的順序可能相反或同時，本發明實施例不加以限制。

確認各中繼站30的韌體更新清單之後，韌體更新模組120可取得各中繼站30的最大容許數量。此最大容許數量可能相關於更新資料量、所用通訊技術、用電資料量、訊號品質等因素。這些因素可與對應最大容許數量記錄在對照表中，以方便韌體更新模組120查詢。韌體更新模組120即可依據此最大容許數量及那些更新群組中的那些電表50的數量(即，各韌體更新清單中電表50的數量)決定單一群組的更新上限數(步驟S340)。例如，更新上限數等於最大容許數量，或者更新上限數等於最大容許數量的三分之二。也就是說，針對任一更新群組，此中繼站30只允許此更新上限數的電表50下載更新資料。

在一實施例中，批次更新參數更包括更新間隔時間。此更新間隔時間相關於電表50對應的通訊技術所容許的最低更新間隔時間。例如，NB IoT的最低更新間隔時間比PLC短。韌體更新模組120可依據網路拓樸資訊取得那些電表50的通訊模組51的通訊技術，並依據各電表50對應的通訊技術決定各更新群組對應的更新間隔時間(步驟S350)。若有其他低於此時間的設定，韌體更新模組120可選擇此最低更新間隔時間來決定更新間隔時間。例如，等於或高於特定數值等。

韌體更新模組120可依據同一中繼站30所服務的電表50的數量(例如，相同基地台識別碼或其他代碼，並用以區別更新群組)，對那些中繼站30分別設定分段同時更新上限數(步驟S360)。

接著，韌體更新模組120可依據批次更新參數對那些電表50進行韌體更新作業(步驟S230)。具體而言，同時僅有設定的更新上限數的那些電表50執行韌體更新作業。即，各更新群組中的電表50將分批進行韌體更新作業。

圖4是依據本發明的一實施例的韌體更新作業的流程圖。請參照圖4，韌體更新模組120可判斷韌體更新清單中的那些電表50的目前版本與所欲更新版本是否相同(步驟S410)。若目前版本與所欲更新版本相同(即，已具有最新韌體)，則韌體更新模組120可自韌體更新清單中剔除這些已具有最新韌體的電表50(步驟S415)。若有任一電表50的目前版本與所欲更新版本不相同或韌體更新清單已被修改(如步驟S415)，則韌體更新模組120可根據前述設定的更新上限數對這些數量的電表50下達更新命令(步驟S420)。此外，韌體更新模組120亦根據所設定的更新間隔時間及更新群組傳送對應的更新資料(步驟S430)。例如，每間隔10分鐘更新10具通訊模組51。需說明的是，此更新資料可能適用於更新通訊模組51、及/或電表50的韌體。此外，本發明實施例的韌體更新作業是基於空中下載技術(Over-the-Air Technology，OTA)。OTA是透過行動通訊或其他通訊技術的空中介面所進行的遠程管理技術。通訊模組51、及/或電表50下載更新資料之後即可自動更新或升級。

在更新的過程中，使用者可隨時決定是否中斷韌體更新作業(步驟S440)。例如，透過使用者介面110取消作業。在一些實施例中，韌體更新模組120也可能自動反應於系統異常、設備異常等情況而自行中斷韌體更新作業。此外，韌體更新模組120可確認是否已對各更新群組中當前連線的電表50(即，韌體更新清單中的電表50)下達更新命令(步驟S450)。各電表50可反應於接收到更新命令而傳送回應給韌體更新模組120，以方便確認命令下達進度。若中斷作業或所有電表50都接收到更新命令，則可結束韌體更新作業。

為了幫助讀者更加理解本發明實施例的發明精神，以下再舉二應用情境說明：

在一應用情境中，假設韌體更新清單是關於台中區域的一萬具電表50的通訊模組51的韌體更新作業。批次更新參數包括同一基地台(中繼站30的範例)僅能同時更新20具通訊模組51的更新上限數、以及間隔20分鐘進行下一批次的20具通訊模組51更新的更新間隔時間。頭端管理系統100可依據批次更新參數依據對各基地台服務下的通訊模組51下達更新命令。假設有100台基地台，則這些基地台都會能同時進行對應數量的韌體更新作業。

在另一應用情境中，假設韌體更新清單是關於台中區域的一千具電表50的通訊模組51的韌體更新作業。批次更新參數包括同一基地台僅能同時更新1具通訊模組51的更新上限數(可能更新資料較大)、以及間隔20分鐘進行下一批次的1具通訊模組51更新的更新間隔時間。同樣地，頭端管理系統100可依據批次更新參數依據對各基地台服務下的通訊模組51下達更新命令。

綜上所述，本發明實施例的通訊系統及其韌體更新方法包括以下特點：

隨著電表建置數量增加，且其韌體更新所需傳輸量更高於定期讀表傳輸量，通訊基地台或通訊設備(DCU)之負荷也隨之增加。本發明實施例透過HES管理電錶通訊設備網路拓譜資訊，並透過HES即時網路拓譜資訊及HES網頁或其他使用者介面所選取的所欲更新設備資料，從而平衡各中繼站進行韌體OTA更新的負載。藉此，可避免資料同時湧入中繼站，且避免資料擁塞影響正常讀表，甚或暫停服務。此外，透過韌體更新模組管控各韌體版本，並可透過自動批次更新大幅減少電表選取與設定時間。

雖然本發明已以實施例揭露如上，然其並非用以限定本發明，任何所屬技術領域中具有通常知識者，在不脫離本發明的精神和範圍內，當可作些許的更動與潤飾，故本發明的保護範圍當視後附的申請專利範圍所界定者為準。

1: 通訊系統 30: 中繼站 50: 電表 51: 通訊模組 100: 頭端管理系統 110: 使用者介面 120: 韌體更新模組 S210~S230、S310~S360、S410~S450: 步驟

圖1是依據本發明的一實施例的通訊系統的元件方塊圖。圖2是依據本發明的一實施例的韌體更新方法的流程圖。圖3是依據本發明的一實施例的批次更新參數決定方法的流程圖。圖4是依據本發明的一實施例的韌體更新作業的流程圖。

S210~S230: 步驟

Claims

一種韌體更新方法，適用於受至少一中繼站服務下的多個電表，包括：頭端管理系統依據一網路拓樸資訊對該些電表分群以產生多個更新群組，其中該網路拓樸資訊相關於該至少一中繼站與受其服務的該些電表的連線情形，該連線情形包括訊號強度、訊號品質以及通訊技術，且每一該更新群組中的該些電表受相同的一該中繼站所服務；該頭端管理系統選擇一韌體更新清單，其中該韌體更新清單記錄每一該中繼站所服務的該些電表，其中，該頭端管理系統依據每一該電表對應的該訊號強度，將該訊號強度低於設定值的至少一該電表自該韌體更新清單中剔除；該頭端管理系統依據每一該韌體更新清單中的該些電表的數量決定一批次更新參數，其中該批次更新參數包括一該更新群組的一更新上限數以及一更新間隔時間，其中決定該批次更新參數的步驟包括：取得一最大容許數量，其中該最大容許數量相關於更新資料量、該通訊技術、用電資料量或該訊號品質；依據該最大容許數量及每一該韌體更新清單中的該些電表的數量決定該更新上限數；以及依據每一該電表對應的該通訊技術決定每一該更新群組對應的該更新間隔時間，其中該更新間隔時間相關於該通訊技術所容許的最低更新間隔時間；以及該頭端管理系統依據該批次更新參數對該些電表進行一韌體更新作業，其中同時僅有該更新上限數的該些電表執行該韌體更新作業，且每隔該更新間隔時間更換下一批次的該些電表來進行該韌體更新作業。
如請求項1所述的韌體更新方法，其中決定該批次更新參數的步驟包括：依據該網路拓樸資訊取得該些電表的該通訊技術，其中每一該電表使用其對應的該通訊技術上傳或下載資料。
如請求項1所述的韌體更新方法，其中依據該網路拓樸資訊對該些電表分群以產生該些更新群組的步驟包括：依據該網路拓樸資訊判斷已離線的至少一該電表及該些電表的該訊號強度；以及依據該至少一已離線的電表及該些電表的該訊號強度修改該韌體更新清單。
如請求項3所述的韌體更新方法，其中依據該批次更新參數對該些電表進行該韌體更新作業的步驟包括：判斷該韌體更新清單中的該些電表的目前版本與所欲更新版本是否相同；以及自該韌體更新清單中剔除已具有該所欲更新版本的至少一該電表，其中該韌體更新作業是基於空中下載技術(Over-the-Air Technology，OTA)。
一種通訊系統，包括：多個電表，上傳資料；一中繼站，為該些電表提供網路服務，並接收該些電表所上傳的資料；以及一頭端管理系統，經配置用以：依據一網路拓樸資訊對該些電表分群以產生多個更新群組，其中該網路拓樸資訊相關於該至少一中繼站與受其服務的該些電表的連線情形，該連線情形包括訊號強度、訊號品質以及通訊技術，且每一該更新群組中的該些電表受相同的一該中繼站所服務；選擇一韌體更新清單，其中該韌體更新清單記錄每一該中繼站所服務的該些電表，其中，該頭端管理系統依據每一該電表對應的該訊號強度，將該訊號強度低於設定值的至少一該電表自該韌體更新清單中剔除；依據每一該韌體更新清單中的該些電表的數量決定一批次更新參數，其中該批次更新參數包括一該更新群組的一更新上限數以及一更新間隔時間，其中決定該批次更新參數的步驟包括：取得一最大容許數量，其中該最大容許數量相關於更新資料量、該通訊技術、用電資料量或該訊號品質；依據該最大容許數量及每一該韌體更新清單中的該些電表的數量決定該更新上限數；以及依據每一該電表對應的該通訊技術決定每一該更新群組對應的該更新間隔時間，其中該更新間隔時間相關於該通訊技術所容許的最低更新間隔時間；以及依據該批次更新參數經由該中繼站對該些電表進行一韌體更新作業，其中同時僅有該更新上限數的該些電表執行該韌體更新作業，且每隔該更新間隔時間更換下一批次的該些電表來進行該韌體更新作業。
如請求項5所述的通訊系統，其中該頭端管理系統更經配置用以：依據該網路拓樸資訊取得該些電表的該通訊技術，其中每一該電表使用其對應的該通訊技術上傳或下載資料。
如請求項5所述的通訊系統，其中該頭端管理系統更經配置用以：依據該網路拓樸資訊判斷已離線的至少一該電表及該些電表的該訊號強度；以及依據該至少一已離線的電表及該些電表的該訊號強度修改該韌體更新清單。
如請求項7所述的通訊系統，其中該頭端管理系統更經配置用以：判斷該韌體更新清單中的該些電表的目前版本與所欲更新版本是否相同；以及自該韌體更新清單中剔除已具有該所欲更新版本的至少一該電表，其中該韌體更新作業是基於空中下載技術(OTA)。