TWI748672B

TWI748672B - 自動讀表異常分析系統及其方法

Info

Publication number: TWI748672B
Application number: TW109134418A
Authority: TW
Inventors: 董名峰; 林亦欣; 黃偉; 廖仁忠; 薛清益; 邱健唐
Original assignee: 中華電信股份有限公司
Priority date: 2020-10-05
Filing date: 2020-10-05
Publication date: 2021-12-01
Also published as: TW202215351A

Abstract

本發明揭露一種自動讀表異常分析系統及其方法，係由頭端管理子系統(HES)之讀表模組對至少一電表進行讀表，且由日誌伺服器記錄讀表模組對電表進行讀表時之讀表日誌(log)。然後，由電表異常分析模組自日誌伺服器之讀表日誌中擷取關聯於電表之特徵值或異常特徵值，以依據關聯於電表之特徵值或異常特徵值之統計次數或發生比例，分析出電表之讀表異常之原因。

Description

自動讀表異常分析系統及其方法

本發明是關於一種讀表異常分析技術，特別是指一種自動讀表異常分析系統及其方法。

為因應全球減碳與再生能源投入電力網路，世界各國逐漸將目前的電力網路升級為智慧電網，並推動智慧型電表之基礎建設。但因電力網路或智慧電網之區域廣泛又複雜，電表之安裝環境及通訊狀態之差異可能會造成讀表異常之情況，例如通訊品質不佳、停電造成電表未產生數值、網路壅塞、通訊模組脫落、電表故障等。因此，若要派員逐一至現場查測電表之異常原因，則需要花費大量人力及時間成本，故自動分析讀表異常變得相當重要。

再者，智慧電表系統於近年蓬勃發展，各家電表廠商也紛紛投入製作智慧電表。但在頭端管理系統(Head-End System；HES)進行整合讀表時，常因各廠牌之電表特性不同及複雜多樣之安裝環境而造成讀表異常(讀表失敗)，且讀表異常(讀表失敗)之原因包括多種面向，例如電表回應異常、通訊模組異常、電表斷電等。同時，現有的智慧電表系統大多僅提供電表連線及離線狀態，卻無針對電表行為提供異常原因，以致造成維運困難，常需派員至現場查測電表之異常原因，才能知道電表之故障情形，從而增加後續之維運成本。

因此，如何提供一種創新之自動讀表異常分析技術，以減少或免除派員逐一至現場查測電表之異常原因，或者針對電表之異常行為分析出異常原因以降低維運成本，已成為本領域技術人員之一大研究課題。

本發明提供一種創新之自動讀表異常分析系統及其方法，例如能減少或免除派員逐一至現場查測電表之異常原因以節省人力及時間成本，或者能自動依據電表之特徵值或異常特徵值(異常行為)分析出讀表異常之原因以降低維運成本。

本發明之自動讀表異常分析系統包括：至少一電表；頭端管理子系統(Head-End System；HES)，係具有讀表模組以對電表進行讀表；日誌伺服器，係用以記錄頭端管理子系統之讀表模組對電表進行讀表時之讀表日誌(1og)；以及電表異常分析模組，係自日誌伺服器之讀表日誌中擷取關聯於電表之特徵值或異常特徵值，以由電表異常分析模組依據關聯於電表之特徵值或異常特徵值之統計次數或發生比例，分析出電表之讀表異常之原因。

本發明之自動讀表異常分析方法包括：由頭端管理子系統(HES)之讀表模組對至少一電表進行讀表；由日誌伺服器記錄頭端管理子系統之讀表模組對電表進行讀表時之讀表日誌(log)；以及由電表異常分析模組自日誌伺服器之讀表日誌中擷取關聯於電表之特徵值或異常特徵值，以由電表異常分析模組依據關聯於電表之特徵值或異常特徵值之統計次數或發生比例，分析出電表之讀表異常之原因。

為讓本發明之上述特徵和優點能更明顯易懂，下文特舉實施例，並配合所附圖式作詳細說明。在以下描述內容中將部分闡述本發明之額外特徵及優點，且此等特徵及優點將部分自所述描述內容可得而知，或可藉由對本發明之實踐習得。應理解，前文一般描述與以下詳細描述二者均僅為例示性及解釋性的，且不欲約束本發明所欲主張之範圍。

1:自動讀表異常分析系統

10:電表

11:通訊模組

20:通訊集收設備或基地台

30:頭端管理子系統(HES)

31:讀表模組

32:電表管理模組

33:電表清單

40:日誌伺服器

41:特徵值

50:電表異常分析模組

51:異常分析規則庫

60:通訊模組管理子系統

S11至S17、S21至S23:步驟

S31至S34、S41至S50:步驟

圖1為本發明之自動讀表異常分析系統的基本架構示意圖；

圖2為本發明之自動讀表異常分析系統及其方法中關於讀表與記錄異常訊息之流程示意圖；

圖3為本發明之自動讀表異常分析系統及其方法中關於更新待異常分析之電表清單之流程示意圖；

圖4為本發明之自動讀表異常分析系統及其方法中關於電表異常原因分析之流程示意圖；以及

圖5為本發明之自動讀表異常分析系統及其方法中關於電表異常分析模組之控制流程示意圖。

以下藉由特定的具體實施形態說明本發明之實施方式，熟悉此技術之人士可由本說明書所揭示之內容了解本發明之其它優點與功效，亦可因而藉由其它不同的具體等同實施形態加以施行或運用。

圖1為本發明之自動讀表異常分析系統1的基本架構示意圖。如圖所示，自動讀表異常分析系統1可包括至少一個或複數個(如二個或三個以上)電表10、通訊集收設備或基地台20、頭端管理子系統(HES)30、日誌(log)伺服器40、電表異常分析模組50與通訊模組管理子系統60等。而且，自動讀表異常分析系統1可為雲端架構(如雲端讀表異常分析系統)，以提供雲端多平台(如頭端管理子系統30、日誌伺服器40與通訊模組管理子系統60等多個雲端平台)之資料整合。

各電表10均具有通訊模組11，且通訊模組11可為射頻(Radio frequency；RF)、電力線通訊(Power Line Communication；PLC)、窄頻物聯網(Narrowband Internet of Things；NB-IoT)、場域網路(Field Area Network；FAN)等通訊組件，而通訊集收設備可為電腦或伺服器等。頭端管理子系統30可為頭端管理平台、頭端管理伺服器等，並具有讀表模組31、電表管理模組32與電表清單33。讀表模組31可為讀表器、讀表軟體或程式等，電表管理模組32可為電表管理器、電表管理軟體或程式等，電表清單33可為需要或待異常分析之電表清單。日誌伺服器40可為雲端伺服器或網路伺服器等。電表異常分析模組50可為電表異常分析器、電表異常分析軟體或程式等。通訊模組管理子系統60可為通訊模組管理伺服器、通訊模組管理軟體、CMP(communication management platform；通訊管理平台)通訊模組管理系統等。但是，本發明並不以此為限。

頭端管理子系統30之讀表模組31可透過通訊集收設備或基地台20與電表10之通訊模組11進行通訊，且電表10之通訊模組11會定期或每隔一段時間發出連線訊號至頭端管理子系統30之讀表模組31，再由頭端管理子系統30之讀表模組31依據連線訊號至頭端管理子系統30之電表管理模組32取得關於電表10之電表資訊，以對電表10進行讀表。若電表10之讀表過程中發生異常，則頭端管理子系統30之讀表模組31可將讀表過程中之異常訊息記錄至日誌伺服器40；反之，若電表10之讀表過程中未發生異常(即讀表正常)，則頭端管理子系統30之讀表模組31可將讀表過程中之讀表資料儲存至頭端管理子系統30中。

本發明藉由頭端管理子系統30之讀表模組31對電表10進行讀表(讀表流程)時，頭端管理子系統30之讀表模組31可一併或同時將電表10之讀表時之讀表日誌(讀表歷程)記錄至日誌伺服器40，以由電表異常分析模組50自日誌伺服器40之讀表日誌(1og)中擷取各類關聯於電表10之特徵值41或異常特徵值(見圖4)，進而由電表異常分析模組50依據各類關聯於電表10之特徵值41或異常特徵值之統計次數或發生比例，自動學習或分析出電表10之讀表異常之資訊(例如讀表異常之原因)。因此，電力公司或電表單位可藉此預先得知電表10之讀表異常之原因，以判斷或決定如何派員維修電表10或加強讀表異常之地區的通訊品質，亦能大幅減少人力成本。

本發明藉由頭端管理子系統30之讀表模組31與電表10之通訊模組11進行讀表時，頭端管理子系統30(讀表模組31)將電表10之讀表時的所有行為資訊(如電表連線、詢問電表資訊、電表事件通知、電表休眠等)記錄至日誌伺服器40，亦可透過日誌伺服器40提取電表10之讀表時的所有行為資訊之特徵值41或異常特徵值(見圖4)，也能整合頭端管理子系統30與通訊模組管理子系統60，還能由電表異常分析模組50分析電表10之讀表異常(讀表失敗)之原因及提供維修程序(維修步驟)。若電表10之讀表異常之原因中存在無判斷方式之異常情形，則將不同的特徵值41或異常特徵值儲存至日誌伺服器40，進而由日誌伺服器40透過學習分析不同的特徵值41或異常特徵值，以增加或更新關於讀表異常之原因之判斷方式，能提供減少或免除派員至電表之現場即可分析出讀表異常之原因，從而降低維運成本及時間。

為提升智慧電表之讀表成功率，快速分析電表10之異常原因以加速排除障礙變得相當重要。因此，本發明整合來自頭端管理子系統30、日誌伺服器40與通訊模組管理子系統60等之資訊，以即時分析電表10之異常原因，讓管理人員或維運人員能快速得知電表10之狀態及異常原因，以提前作為是否派員至電表10之現場維修參考，亦能大幅減少現場查測電表10之時間。

本發明由電表異常分析模組50透過頭端管理子系統30(電表管理模組32)取得電表10之最後上線時間及讀值狀況，以依據電表10之最後上線時間及讀值狀況判斷電表10是否需要異常分析與記錄最後上線時間及讀值狀況於頭端管理子系統30之待異常分析之電表清單33，再將電表異常分析模組50連結至通訊模組管理子系統60，進而透過通訊模組管理子系統60查詢電表10(通訊模組11之門號)之流量，以確認電表10之通訊狀態。然後，由電表異常分析模組50至日誌伺服器40取得讀表模組31所記錄之電表10之特徵值41或異常特徵值(見圖4)，進而依據特徵值41或異常特徵值即時判斷電表10之異常狀態，以提供相應之維修方式。

圖2為本發明之自動讀表異常分析系統1及其方法中關於讀表與記錄異常訊息之流程示意圖，並參閱圖1予以說明。

如圖2之步驟S11與步驟S12所示，電表10之通訊模組11可定期或每隔一段時間發送連線訊號通過通訊集收設備或基地台20至頭端管理子系統30之讀表模組31，且讀表模組31收到連線訊號後會至頭端管理子系統30之電表管理模組32取得關於電表10之電表資訊，例如電表資訊為金鑰、通訊模組11之國際行動裝置識別碼(International Mobile Equipment Identity；IMSI)等。

如圖2之步驟S13所示，在取得關於電表10之電表資訊後，讀表模組31可對電表10進行讀表。接著，如圖2之步驟S14所示，由讀表模組31判斷是否完成讀表？若是(已完成讀表)，則進行圖2之步驟S15以完成讀表；反之，若否(未完成讀表)，則進行圖2之步驟S16。然後，如圖2之步驟S16所示，由讀表模組31判斷讀表是否異常？若是(讀表有異常)，則進行圖2之步驟S17，以由讀表模組31將讀表之異常訊息記錄至日誌伺服器40；反之，若否(讀表無異常)，則返回圖2之步驟S13，以由讀表模組31繼續進行讀表。

圖3為本發明之自動讀表異常分析系統1及其方法中關於更新待異常分析之電表清單33之流程示意圖，並參閱圖1予以說明。

如圖3之步驟S21所示，電表異常分析模組50可定期或每隔一段時間至頭端管理子系統30之電表管理模組32確認各電表10之電表資訊是否有儲存至頭端管理子系統30中，以依據電表資訊確認電表10之最後上線時間。

接著，如圖3之步驟S22所示，電表異常分析模組50判斷電表10之最後上線時間是否超過最後上線時間門檻？若是(電表10之最後上線時間超過最後上線時間門檻，如4小時)，且頭端管理子系統30無成功從電表10讀回資料，則進至步驟S23，電表異常分析模組50將電表10之表號更新至待異常分析之電表清單33，以由電表異常分析模組50對電表清單33內有關電表10之電表資訊進行分析，進而依據電表資訊之分析結果產出電表10之異常原因。反之，若否(電表10之最後上線時間未超過最後上線時間門檻，如4小時)，則返回步驟S21以繼續確認電表10之最後上線時間。

圖4為本發明之自動讀表異常分析系統1及其方法中關於電表異常原因分析之流程示意圖，並參閱圖1予以說明。

如圖4所示，電表異常分析模組50之異常分析規則庫51可透過開發端(如開發人員)之讀表經驗，以自動依據特徵值41或異常特徵值之統計次數或發生比例判斷電表10之異常原因，且將關聯於電表10之異常分析規則加入異常分析規則庫51中。

舉例而言，當電表10有讀值，但日誌伺服器40經常出現連線逾時、電表無回應、讀表無回應等相關紀錄時，經由開發端之讀表經驗確認而判定為此紀錄為通訊不佳，因此電表異常分析模組50可提取此紀錄之特徵值，並將此紀錄之異常分析規則(例如，if連線逾時>0 &電表無回應>0 &讀表無回應>0 then通訊不佳)加入異常分析規則庫51中。

又，當電表10無讀值、持續有收到傳送連線訊號，且日誌伺服器40出現電表10之最後一口氣、電表重開機等相關紀錄時，經由開發端之讀表經驗確認而判定此紀錄為電表異常，因此電表異常分析模組10可提取此紀錄之特徵值，並將此紀錄之異常分析規則(例如，if最後一口氣>2 &電表重開機>2 then電表異常)加入異常分析規則庫51中。

接著，電表異常分析模組50可至日誌伺服器30提取需要或待異常分析之電表10之特徵值41或異常特徵值，例如特徵值41或異常特徵值為複數個不同的特徵值(1)至特徵值(n)，其中n為正整數。在一實施例中，特徵值(1)至特徵值(n)可分別為電表逾時之次數、電表無回應之次數、電表回應無資料之次數、發送最後一口氣之次數、重新開機之次數、國際行動裝置識別碼(IMSI)配對不符、解密失敗之次數及停電事件之次數...等。

然後，如圖4之步驟S31所示，由電表異常分析模組50透過異常分析規則庫51判斷電表10之異常原因。若電表異常分析模組50透過異常分析規則庫51無法判斷出電表10之異常原因，則進行圖4之步驟S32，以將電表10之特徵值41或異常特徵值記錄至電表異常分析模組50。接著，如圖4之步驟S33所示，待累積電表10之特徵值41或異常特徵值之大量數據後，電表異常分析模組50可針對電表10之特徵值41或異常特徵值之大量數據進行關聯分析等方式以找出關聯的異常分析規則或增加新的異常分析規則。

當異常分析規則庫51無法分類異常原因時，會將無法分類之異常原因分類為其它原因，待收集到多日數據後，透過關聯分析找出日誌伺服器40最常出現之關鍵字，並將最常出現之關鍵字增加為新的特徵值，再透過開發端之讀表經驗協助判斷電表10之新的異常原因。例如，針對無法分析異常原因之電表10，日誌伺服器40皆有大量重複進行電表10之表號註冊(電表註冊次數)之紀錄及通訊中斷(通訊錯誤)之紀錄，因此透過開發端判斷此紀錄為模組鬆脫，並將此紀錄之異常分析規則(例如，if電表註冊次數>1 &通訊錯誤>1 then模組鬆脫)加入異常分析規則庫51中。

然後，如圖4之步驟S34所示，完成分析後，將關聯的異常分析規則或新的異常分析規則加入電表異常分析模組50之異常分析規則庫51中。

圖5為本發明之自動讀表異常分析系統1及其方法中關於電表異常分析模組50之控制流程示意圖，並參閱圖1予以說明。

如圖5之步驟S41所示，電表異常分析模組50可依據待異常分析之電表清單33至頭端管理子系統30(電表管理模組32)查詢電表10之最後上線時間，以依據電表10之最後上線時間判斷電表10是否有定期傳送連線訊號通過通訊集收設備或基地台20至頭端管理子系統30(讀表模組31)。若是(電表10有定期傳送連線訊號至頭端管理子系統30)，則判斷為下列情況一。反之，若否(電表10無定期傳送連線訊號至頭端管理子系統30)，則判斷為下列情況二。

情況一：電表10有定期傳送連線訊號至頭端管理子系統30，且頭端管理子系統30之讀表模組31可以與電表10之通訊模組11連線，但無法取得負載之資料等相關資料。此時，如圖5之步驟S42所示，由電表異常分析模組50透過頭端管理子系統30提取需要或待異常分析之電表清單33以分析電表10之異常原因。接著，如圖5之步驟S43所示，由電表異常分析模組50判斷是否可成功分析電表10之異常原因？若是(電表異常分析模組50可成功分析電表10之異常原因)，則進行圖5之步驟S44，以由電表異常分析模組50記錄電表10之異常原因之分析結果。反之，若否(電表異常分析模組50無法成功分析電表10之異常原因)，則依序進行圖5之步驟S45、步驟S46與步驟S47，由電表異常分析模組50記錄電表10之特徵值41或異常特徵值，待累積特徵值41或異常特徵值之大量數據後，由電表異常分析模組50針對電表10之特徵值41或異常特徵值之大量數據進行關聯分析以找出關聯的異常分析規則或增加新的異常分析規則，再將關聯的異常分析規則或新的異常分析規則加入電表異常分析模組50之電表異常規則庫51中。

情況二：電表10無定期傳送連線訊號至頭端管理子系統30，且電表10無法連線至頭端管理子系統30。此時，大多是電表10之通訊模組11之硬體有異常或是頭端管理子系統30有異常，故電表異常分析模組50可透過通訊模組管理子系統60確認電表10之通訊模組11之門號之流量。如圖5之步驟S48所示，電表異常分析模組50透過通訊模組管理子系統60(如CMP通訊模組管理子系統)判斷電表10之通訊模組11之門號是否無流量？若是(電表10之通訊模組11之門號無流量)，則進行圖5之步驟S49，由電表異常分析模組50透過通訊模組管理子系統60判斷為電表10之通訊模組11之異常。反之，若否(電表10之通訊模組11之門號有流量)，則電表異常分析模組50透過通訊模組管理子系統60判斷為頭端管理子系統30之異常。

舉例而言，綜合圖1至圖5所述，下列以24小時為單位作為實施例進行異常分析。首先，電表異常分析模組50於跨日時(即跨半夜24時)至頭端管理子系統30更新電表10之最後上線時間，並將最後上線時間超過最後上線時間門檻(如4小時)之電表10更新至需要或待異常分析之電表清單33。接著，電表異常分析模組50至日誌伺服器40擷取異常電表之讀表日誌，並從日誌伺服器40提取電表10之特徵值41或異常特徵值。例如，下列表1所示電表清單(電表異常原因)中，特徵值41或異常特徵值可為電表逾時之次數、電表無回應之次數、電表回應無資料之次數、發送最後一口氣之次數、重新開機之次數、國際行動裝置識別碼(IMSI)配對不符、解密失敗之次數及停電事件之次數...等。

表1：電表清單(電表異常原因)

通常可將異常情況分為兩大類，例如通訊模組11無連線訊號與通訊模組11有傳送連線訊號。若日誌伺服器40無電表10傳送之異常紀錄，且無成功問回或詢得負載之資料，則將異常情況分類為通訊模組11無連線訊號。此時，電表異常分析模組50會至通訊模組管理子系統60查詢電表10之通訊模組11是否有進行網路通訊。

如上列表1所示之電表1：頭端管理子系統30查無電表1於前一日之最後上線時間、日誌伺服器40也無記錄、且通訊模組管理子系統60查詢電表10之通訊模組11沒有進行網路通訊，因此電表異常分析模組50判斷電表10之異常原因為通訊模組11之異常，故電力公司或電表單位須派員至現場更換電表10之通訊模組11。

若異常情況為通訊模組11有傳送連線訊號，則電表異常分析模組50會依據來自日誌伺服器40之特徵值41或異常特徵值判斷電表10之異常原因，下列以電表2至電表6之實施例予以說明。

如上列表1所示之電表2：電表2之最後上線時間為10點14分25秒，且有發送停電事件集之最後一口氣，因此電表異常分析模組50判斷電表2之異常原因為停電中或地區停電中，但電表2於復電後會恢復正常。

如上列表1所示之電表3：電表3之最後上線時間為23點59分27秒，表示電表3有持續傳送連線訊號，但無問回或詢得任何負載之資料且沒有電表逾時之錯誤。因此，確定讀表時之通訊模組11有正常詢問數值，但電表11回應無產出資料(無產生負載之資料)，故電表異常分析模組50判斷電表3之異常原因為電表10之異常，須派員至現場維修電表10。

如上列表1所示之電表4：電表4之最後上線時間為23點50分51秒，表示電表4有持續傳送連線訊號，但無問回或詢得任何負載之資料且有大量解密失敗之異常，因此電表異常分析模組50判斷電表4之異常原因為金鑰之錯誤或異常，故須至系統確認金鑰。

如上列表1所示之電表5：電表5之最後上線時間為23點58分52秒，表示電表5有持續傳送連線訊號，但大量出現電表無回應、電表回應無資料及最後一口氣，且不斷重新開機，因此電表異常分析模組50判斷電表5之異常原因為電表10之異常，故須派員至現場維修電表10。

如上列表1所示之電表6：電表6之最後上線時間為23點56分46秒，表示電表6有持續傳送連線訊號，有問回或詢得負載之資料 (但並非可以即時問回或詢得負載之資料)，且讀表時發生電表逾時，因此電表異常分析模組50判斷電表6之異常原因為通訊不佳，故須改善電表6之基地台設定。

綜上，本發明之自動讀表異常分析系統及其方法可至少具有下列特色、優點或技術功效。

一、本發明之電表異常分析模組能分析(自動分析)電表於讀表時之異常資訊(如原因)，以快速提供維運人員之維運參考，進而減少現場維修電表或通訊模組之成本。

二、本發明之日誌伺服器能藉由記錄電表之讀表時之行為資訊(讀表日誌)，如電表連線、詢問電表資訊、電表事件通知、電表休眠等，以供電表異常分析模組透過提取這些行為資訊(讀表日誌)之特徵值或異常特徵值，有利於分析讀表異常(讀表失敗)之原因。

三、本發明之電表異常分析模組能從通訊模組管理子系統(如CMP通訊模組管理系統)取得通訊資料(如電表或通訊模組之門號之流量)，並與日誌伺服器中有關電表之讀表日誌(如關聯於電表之特徵值或異常特徵值)比對分析，以利提供更精準之異常原因之分析結果。

四、本發明之自動讀表異常分析系統可為雲端架構，以提供頭端管理子系統、日誌伺服器與通訊模組管理子系統等雲端多平台之資料整合，並對電表異常時之日誌進行異常原因分析，俾透過特徵值之演算分析以自動產出電表或讀表時之異常原因，有利於加快維運人員之判斷速度，進而減少維運人員至現場檢測電表或通訊模組之成本及時間等資源。

五、本發明能整合頭端管理子系統(HES)、日誌伺服器、通訊模組管理子系統(如CMP通訊模組管理子系統)等多個系統或平台之資料或資源。

上述實施形態僅例示性說明本發明之原理、特點及其功效，並非用以限制本發明之可實施範疇，任何熟習此項技藝之人士均能在不違背本發明之精神及範疇下，對上述實施形態進行修飾與改變。任何使用本發明所揭示內容而完成之等效改變及修飾，均仍應為申請專利範圍所涵蓋。因此，本發明之權利保護範圍應如申請專利範圍所列。