梁 捷，梁廣明

(1.廣西電網有限責任公司計量中心，廣西 南寧 530023；2.南寧百會藥業(yè)集團有限公司，廣西 南寧 530003)

0 引 言

隨著廣西電網低壓集抄系統(tǒng)“兩覆蓋”工作的推進[1]，現(xiàn)場發(fā)現(xiàn)許多電能表抄表失敗的原因是由電能表軟件設計缺陷或故障導致的，故障處理時需對故障臺區(qū)中的大量電能表進行軟件更新。此外，隨著智能電網的建設，新能源和電動汽車的接入[2]以及非侵入式智能家居設備的推廣，對電能表提出更多軟件方面的應用功能要求。這些新功能開發(fā)應用也需要對現(xiàn)場已安裝的電能表進行軟件更新來實現(xiàn)測試或應用的目標。

廣西電網當前正在推廣使用的符合南方電網技術規(guī)范的費控電能表，其上行通信協(xié)議雖然給出了軟件遠程升級的報文格式定義，但未給出具體的軟件更新方案。為此，針對傳統(tǒng)的電能表集中式軟件遠程更新模式存在的問題，設計了一種新的分散組播模式的電能表軟件遠程軟件更新方案，詳細介紹了其軟件更新的實現(xiàn)過程并通過實例測試驗證了其可行性。

1 軟件更新方案設計

1.1 總體方案設計

根據國際法制計量組織(OIML)最新修訂的電能表國際建議IR46，智能電能表管理芯片的軟件升級不應影響計量的準確性和穩(wěn)定性[3]，即要求電能表管理芯片能獨立于計量芯片進行軟件更新。

由于現(xiàn)場安裝的電能表在故障處理以及用戶或電網公司有新業(yè)務需求時需要進行軟件更新；且現(xiàn)場電能表安裝數(shù)量龐大，安裝位置分散，到安裝點逐個進行人工更新和由主站進行點對點逐個電能表軟件更新的方式工作量大，不能滿足實際使用需求：因此要求智能電能表的管理芯支持在線軟件更新功能。

傳統(tǒng)對批量電能表進行軟件更新主要基于主站集中分組的軟件更新模式，這里簡稱集中式軟件更新模式。首先，由主站根據自身檔案和需求對電能表進行分組；然后，下發(fā)軟件更新任務，終端根據接收到的更新任務，對電能表進行更新包的組播傳輸；最后，電能表接收更新包并存儲和更新。組播是指根據一定的通信拓撲節(jié)點組成的路徑將待傳輸數(shù)據進行分布式并發(fā)傳輸?shù)姆绞剑捎谕ㄟ^中間節(jié)點進行數(shù)據的分布處理，因此該機制的效率比點對點的單播模式高。集中由主站組播的集中更新方式憑借主站的服務器處理能力，數(shù)據處理和傳輸較快，軟件更新業(yè)務效率高，適用于數(shù)據量大的業(yè)務過程。

但該方式存在的問題是：在對電能表進行分組時，傳統(tǒng)軟件更新方式由主站來發(fā)起，主站根據已經建立的檔案信息來進行分組。由于檔案更新不及時，會出現(xiàn)本臺區(qū)的電能表找不到或者其他臺區(qū)的電能表被劃入本臺區(qū)等主站所建的檔案與實際的臺區(qū)管轄不一致的情況，導致電能表與主站“失聯(lián)”[4]。

對此，為了在保證電能表軟件更新安全可靠的同時提高軟件更新效率，設計了一種由各臺區(qū)的計量終端分解更新任務的分散式更新模式。從主站側觀察，其過程主要可以分為以下5個階段，如圖1所示。

圖1 軟件更新主要流程

如圖1，該模式的主要軟件更新流程如下：

1)更新請求：軟件更新請求由主站發(fā)起，主站獲取待更新電能表廠家版本信息及待更新的模塊信息，并下發(fā)更新初始化命令，讓電能表或模塊做好更新準備。2)更新分組：對電能表進行軟件更新分組，分組由集中器或采集器完成，分組完成后根據分組情況下發(fā)組地址。3)更新程序下載：軟件更新程序的下載由主站下發(fā)，為滿足南方電網對電能表信息安全防護和完整性的要求，更新程序本身需進行加密和完整性校驗。終端通過透傳方式[5]直接將更新程序下載到電能表，為了提高更新效率，主站對更新文件采用組播方式下發(fā)[6]。4)更新程序下載確認：軟件更新文件下發(fā)完成后，由集中器或采集器完成下載完整性檢測，以點對點方式獲取更新文件下載信息，對丟失包重新下發(fā)，所有包都接收完成后，對更新程序進行完整性校驗，然后費控電能表通過其內置的嵌入式安全控制模塊(embedded secure access module,ESAM)芯片進行解密。5)更新程序更新：下載完成主站下發(fā)啟動更新命令，可選擇立即更新和定時更新兩種模式，滿足更新要求后將下載的新程序更新到電能表管理芯的程序運行區(qū)，實現(xiàn)電能表的在線軟件更新功能；電能表更新完成后由主站主動讀取電能表更新狀態(tài)字命令，確認是否更新成功。軟件更新過程中計量芯正常工作，計量功能正常運行，避免因管理芯更新而導致電量漏記的問題。

該模式可依靠終端的抄表機制實現(xiàn)軟件更新對象的實時和準確核對，但業(yè)務流程比集中式模式復雜且對終端的處理能力要求較高。適用于待更新電能表規(guī)模不大、要求及時進行信息反饋的更新業(yè)務。此外，更新文件采用主站分別下載到終端，由終端再對待更新電能表進行更新文件下發(fā)的方式，需在終端預留更新文件存放空間，對終端存儲要求高。實際應用中可根據具體應用場景和需求選擇集中或分散更新的模式。

1.2 更新方案詳細設計

1.2.1 更新請求

區(qū)別于傳統(tǒng)集中軟件更新方式，出于如下考慮，不采用主站直接對電能表下發(fā)更新請求的模式：

1)主站直接操作電能表，一方面要通過臺區(qū)識別確定電能表所屬的終端；另一方面，在一對一更新時，主站需要知道待更新電能表的通信地址。而實際主站記錄的電能表、終端等的檔案信息并不能確保100%無誤，從而無法保證一定能找到所有需更新的電能表。

2)主站直接操作電能表在更新期間會增加主站與終端之間的信道通信壓力。

3)主站獲取電能表更新判斷結果后，需要對更新的電能表信息進行保存，由于電能表數(shù)量龐大，信息存儲會占用較多數(shù)據存儲空間。

故所提模式的更新流程是：首先，由主站發(fā)起任務，主站獲取更新文件中待更新電能表廠家版本信息及待更新的模塊信息；然后，將更新任務信息發(fā)送給終端，由終端分別對其所轄電能表進行逐一的更新請求的處理，確定哪些電能表需要進行更新。假設計量終端所轄臺區(qū)中所有電表組成的集合為M={m1,m2, …,mN-1,mN}，則需更新電能表集合MQ定義為

MQ={mn∈M|mn∈MT∩MC且R(mn)

(1)

式中：MT為能與計量終端正常通信的電能表組成的集合；MC為與更新文件對應的廠家一致的電能表組成的集合；R(mn)表示序號為n的電能表的軟件版本日期；Rs為更新文件對應的軟件版本日期。

將MQ中的電能表通信地址、版本號等信息返回給終端，終端組織所有滿足更新條件的電能表信息上傳給主站。具體流程如圖2所示。

圖2 更新請求流程

從上述過程可見，所提方法的更新請求對于主站來說只需要知道每個終端下面是否有需要進行更新的電能表即可，不需要知道具體哪些電能表需要進行更新。此外，該過程中，終端ESAM需具備與電能表建立安全傳輸?shù)膽眠B接的功能，若暫不支持，可以采用明文傳輸?shù)姆绞健?/p>

1.2.2 更新分組

在主站以單播方式進行單個電能表軟件更新的時候，不需要進行分組操作。而對批量電能表更新時，根據組播通信技術要求，此時需要對待更新的電能表進行分組。為減少主站與終端之間的交互，最終減少通信壓力，所設計更新模式的更新分組不由主站完成，而是由主站發(fā)起任務，通過下發(fā)分組地址到終端，再由終端將組地址下發(fā)到待更新的電能表，實現(xiàn)對待更新電能表的分組。具體流程如圖3所示。

圖3 軟件更新分組流程

1.2.3 更新程序下載

更新的程序文件下載采用主站下發(fā)到終端的方式。這是考慮到分組后采用組播地址進行文件下發(fā)與采用將更新文件下發(fā)到終端后再由終端下發(fā)到電能表這兩種方式相比，雖然主站到終端之間的通信量在理想狀態(tài)下相差不大，但實際上組播方式進行通訊傳輸過程中，一次下發(fā)成功率比采用主站下發(fā)到終端的方式低。當通信失敗時，需要對缺失的包進行補發(fā)。由于組播機制通常不會預留用于補發(fā)的信道資源，故需要補發(fā)的電能表通信環(huán)境會比其他電能表惡劣。一些電能表可能需要通過多次補發(fā)才能實現(xiàn)完成整個更新包的傳輸，此時如果都通過主站來補發(fā)，主站通信量會劇增，從而可能導致通信的堵塞。故選擇采用主站傳輸更新程序到終端，然后再給電能表進行更新的方式。

更新程序由電能表生產廠家提供。其內容主要包括廠家信息、更新文件版本信息、更新電能表ID信息、更新文件信息及更新文件包。更新文件中包括各個模塊的可執(zhí)行程序及整體校驗，更新文件通過AES-128算法進行加密，作為一個整體的文件，采用分塊傳輸?shù)姆绞竭M行下發(fā)，文件下載時需要支持鏈路層分幀，以便后期分塊幀的重組。由于是組播下發(fā)，電能表不應答，為獲得較高的成功率，可適當延長主站下發(fā)數(shù)據幀時兩幀的時間間隔。更新程序下發(fā)具體流程如圖4所示。

圖4 更新程序下載流程

1.2.4 更新程序下載確認

由于終端對更新文件下載的過程為單方向傳輸，故為了確保所有電能表均接收到完整的更新文件，終端在文件組播完成后即發(fā)起文件下載確認任務，對所轄更新電能表接收信息的確認。更新模式的確認流程如圖5所示。

圖5 更新程序下載確認流程

圖5中，電能表更新文件是否接收完整，由終端查詢電能表文件傳輸塊狀態(tài)字進行判斷。對于丟包的數(shù)據，集中器通過對塊狀態(tài)字進行分析，按下述兩種補發(fā)策略進行更新程序補發(fā)：對大批量電能表都丟失的數(shù)據塊，采用組播方式補；對于少量電能表丟失的數(shù)據塊，采用單播方式進行補發(fā)。在進行下載文件的確認時，如果有某些包補發(fā)不成功，終端會進行有限次數(shù)的重復補發(fā)，若超過補發(fā)次數(shù)，則放棄該電能表的補發(fā)，繼續(xù)更新流程。上述異常情況下，后續(xù)電能表收到更新啟動命令時若數(shù)據包接收不完整，則返回異常應答給主站，主站再進一步的處理。

1.2.5 軟件更新程序安裝

升級程序安裝時，首先由主站下發(fā)啟動安裝更新任務；為了確保接收電能表均能接收到完整的更新文件，由終端采用點對點方式下發(fā)該命令到電能表，電能表應答啟動更新結果傳給終端，終端再透傳給主站，流程如圖6所示。

圖6 更新程序更新流程

更新任務有兩種模式：一種為下載完成并校驗后立即進行管理芯片程序安裝的立即安裝模式；另一種為通過設置時間參數(shù)進行定時更新程序安裝的模式，可根據具體應用場景選擇不同方式，大批量現(xiàn)場軟件更新通常采用定時安裝模式，避免更新時和重要采集任務沖突。

2 更新過程關鍵問題

2.1 原程序拷貝及回滾

相對于將要更新的程序，這里將電能表微處理器(MCU)內正在運行的應用程序稱為當前應用程序。相對地，當前下載到外部閃存(FLASH)內、比當前版本高一個版本、還未更新到MCU的應用程序稱為待更新應用程序。

該應用程序在出廠前會燒錄在電能表的管理芯內，同時還會額外下載一個同樣的應用程序到電能表的外部FLASH內；更新程序更新前應將電能表內的原應用程序拷貝到MCU外部的FLASH芯片中。更新后，則將新的應用程序和外部存儲芯片中的原應用程序進行功能核驗。若核驗不一致，則用該拷貝的程序進行回滾覆蓋。若更新后有其他異常情況時，例如新應用程序頻繁異常復位、復位超過門限次數(shù)，電能表自檢到這種異常后也將回滾恢復至原應用程序。

2.2 更新程序的完整性及安全性核驗

更新程序的軟件完整性和安全性分別通過CRC校驗和國標加密算法AES-128[7]保證。先對更新程序整體做循環(huán)見余校驗碼(cyclic redundancy check，CRC)校驗。CRC校驗是發(fā)送方通過對待發(fā)送數(shù)據進行多項式計算，并將計算結果附在報文中，接收方根據同一算法進行查錯的數(shù)據傳輸檢錯方法。通過這種方法來保證軟件的完整性和正確性。然后，根據南方電網費控電能表信息交換安全認證技術要求，再使用AES-128加密算法對包含CRC的更新程序整體進行加密，避免報文的核心數(shù)據域以及CRC被篡改。

2.3 更新相關事件記錄

在電能表更新程序過程中，更新初始化事件、更新校驗成功事件、更新校驗失敗事件、更新激活成功事件、回滾事件，每個事件都會記錄相應時標及對應固件版本號便于后續(xù)的軟件管理和故障分析。

3 實驗驗證

為驗證所設計的電能表更新模式的可行性，搭建模擬測試平臺進行測試，由測試主站通過該模式給61只同一廠家同一批次的費控電能表進行遠程軟件更新。結果顯示1024 kB的應用程序更新時間為16 min左右。

在該更新程序下載過程中，由于采用分塊傳輸，每個程序更新塊大小為512 Bytes，則共需傳2000塊。每個更新塊組幀時作為數(shù)據域，然后加上幀頭、幀尾、地址等上行通訊規(guī)約定義的幀結構部件，則更新報文每條的長度為551 Bytes。采用窄帶載波方式以1200 bit/s速率傳輸。實測通信傳輸時間需要983 s，即約16 min，基本滿足現(xiàn)場應用需求。該時間包含電能表回復幀傳輸時間、收發(fā)雙方通信延時、電能表接收到更新塊后進行存儲和更新的時間。

4 結 語

所設計的電能表遠程管理芯片軟件的分散式更新方案，在案例測試時，觀察到其更新程序下載過程中未影響電能表計量芯的正常工作。程序更新期間，峰平谷各費率的電量累積的準確性也可得到保證，電能表程序更新前后也未引起表內基本參數(shù)和底度等重要數(shù)據的改變，在測試環(huán)境中驗證了其可行性。如何進一步提高該方案在發(fā)送大文件時的傳輸效率和穩(wěn)定性，解決大批量電能表組播更新時的“廣播風暴”問題，值得進一步研究。