基于分散組播模式的電能表軟件更新技術(shù)研究

梁 捷，梁廣明

(1.廣西電網(wǎng)有限責(zé)任公司計(jì)量中心，廣西 南寧 530023；2.南寧百會藥業(yè)集團(tuán)有限公司，廣西 南寧 530003)

0 引 言

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

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

1 軟件更新方案設(shè)計(jì)

1.1 總體方案設(shè)計(jì)

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

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

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

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

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

圖1 軟件更新主要流程

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

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

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

1.2 更新方案詳細(xì)設(shè)計(jì)

1.2.1 更新請求

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

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

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

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

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

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

(1)

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

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

圖2 更新請求流程

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

1.2.2 更新分組

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

圖3 軟件更新分組流程

1.2.3 更新程序下載

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

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

圖4 更新程序下載流程

1.2.4 更新程序下載確認(rèn)

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

圖5 更新程序下載確認(rèn)流程

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

1.2.5 軟件更新程序安裝

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

圖6 更新程序更新流程

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

2 更新過程關(guān)鍵問題

2.1 原程序拷貝及回滾

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

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

2.2 更新程序的完整性及安全性核驗(yàn)

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

2.3 更新相關(guān)事件記錄

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

3 實(shí)驗(yàn)驗(yàn)證

為驗(yàn)證所設(shè)計(jì)的電能表更新模式的可行性，搭建模擬測試平臺進(jìn)行測試，由測試主站通過該模式給61只同一廠家同一批次的費(fèi)控電能表進(jìn)行遠(yuǎn)程軟件更新。結(jié)果顯示1024 kB的應(yīng)用程序更新時間為16 min左右。

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

4 結(jié) 語

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