任寶軍,高志勇
(南京國電南自電網(wǎng)自動化有限公司,南京210000)
近年來我國電力系統(tǒng)發(fā)展迅速,國網(wǎng)電力系統(tǒng)二次側(cè)終端類產(chǎn)品類型逐年劇增。在配用電領域,采用智能終端設備來實現(xiàn)對各種目標節(jié)點的監(jiān)測以及數(shù)據(jù)采集,并將采集到的數(shù)據(jù)上傳到主站,其產(chǎn)生的巨大計算量對運維管理主站的運算能力提出了一定的要求。其次,現(xiàn)場功能需求的多樣化,要求同時部署多種類型的裝置來滿足實際業(yè)務要求。而目前傳統(tǒng)配用電終端為了實現(xiàn)各種復雜功能,其內(nèi)部軟件在開發(fā)方式上多數(shù)采用多進程方法進行結(jié)構(gòu)解耦。但是多個應用程序(APP)相互之間缺少安全管理機制,某個異常的APP 會影響其他正常的APP 進程,導致整個裝置系統(tǒng)癱瘓?;谝陨蠁栴},提出一種就地化采集數(shù)據(jù)并計算處理的技術,即邊緣計算。采用容器技術[1]實現(xiàn)內(nèi)部應用程序安全隔離,在功能結(jié)構(gòu)上采用實時系統(tǒng)融合管理系統(tǒng)的設計方案,綜合具備實時采樣計算保護與大數(shù)據(jù)量接入進行邊緣計算高級應用分析并存儲的能力。
目前常規(guī)用電類產(chǎn)品主要裝置功能集中于就地數(shù)據(jù)采集與上傳,如進行電表數(shù)據(jù)采集與計量,并將數(shù)據(jù)上傳至主站。因此常規(guī)用電類產(chǎn)品需要選用具備完善文件存儲方案及強大網(wǎng)絡協(xié)議棧功能的Linux 操作系統(tǒng)為基礎平臺,在該平臺上開發(fā)各種應用程序。同時,由于配電類產(chǎn)品注重實時采樣計算與保護功能,因此對系統(tǒng)的實時性要求較高,一般會選擇嵌入式實時操作系統(tǒng)為開發(fā)平臺。
某裝置以Linux 操作系統(tǒng)為基礎運行各種應用進程,每個進程實現(xiàn)各自的業(yè)務需求功能,如圖1所示。各個進程間采用消息傳輸機制或共享內(nèi)存等方式進行進程間通信。這種傳統(tǒng)開發(fā)方式的優(yōu)點是開發(fā)快捷、更新升級方便,但是系統(tǒng)中各個進程的安全性無法得到有效控制[2]。
圖1 常規(guī)應用服務開發(fā)架構(gòu)Fig.1 Development architecture of general application service
具體分析如下:應用服務bin1,bin2,bin3 運行過程中,各個bin 服務間可以直接訪問系統(tǒng)信息以及調(diào)用系統(tǒng)操作接口。bin1獲取系統(tǒng)內(nèi)其他進程號之后,可以對任何進程進行人為kill 操作來結(jié)束該進程;bin3服務在運行一段時間后,由于內(nèi)部程序設計缺陷等問題導致出現(xiàn)該進程占用中央處理器(CPU)以及內(nèi)存使用率高達98.0%以上,且長期占用閃存(flash memory)的寫操作;bin2 進程正常運行。當出現(xiàn)上述3 種運行態(tài)服務進程后,bin1 可隨時終止其他程序進程的正常運行;bin3 進程由于其本身存在漏洞一直占用系統(tǒng)硬件資源,導致其他正常進程無法獲取足夠硬件資源保持正常運行。最終bin2 進程由于受到bin1 的威脅及bin3 的占用導致無法正常運行,整個裝置所有軟件功能服務將徹底癱瘓。
基于Linux 操作系統(tǒng)平臺開發(fā)的用電類產(chǎn)品在數(shù)據(jù)采集、大容量存儲以及網(wǎng)絡傳輸方面具有一定的優(yōu)勢。用電設備一般通過電力線載波通信方式抄讀各個電表或者采集器數(shù)據(jù)。但隨著用戶對現(xiàn)場功能需求逐步提高,在某些應用場景下不僅要實現(xiàn)數(shù)據(jù)就地采集與傳輸,還需要實現(xiàn)就地線路保護功能,實時監(jiān)測線路運行狀態(tài)。當線路發(fā)生短路或接地故障時,要求裝置能快速檢測并切除故障。而Linux系統(tǒng)在實時信號處理方面遠不如實時系統(tǒng)。
為解決這一問題,常規(guī)做法是再增加1 臺專用的配電保護裝置,如圖2 所示。該裝置運行實時系統(tǒng)實現(xiàn)就地故障檢測與保護。因此用電類產(chǎn)品主要用于現(xiàn)場終端設備的數(shù)據(jù)抄讀,配電類產(chǎn)品裝置則用于對現(xiàn)場用戶線路的故障檢測與故障切除。對于用戶來說就需要維護2 種類型的裝置,項目投運初期現(xiàn)場調(diào)試較為繁瑣。
圖2 現(xiàn)場架構(gòu)示意Fig.2 On?site framework
針對常規(guī)配用電終端裝置內(nèi)部安全性以及功能性方面存在的問題,提出基于邊緣計算的終端解決方案,同時采用相互優(yōu)勢融合的設計方案滿足現(xiàn)場使用需求。
基于Docker 的安全容器[3]技術,容器內(nèi)部包含Systemd 系統(tǒng)服務管理軟件、日志服務軟件、Cron 服務軟件等基礎工具。虛擬容器[4]在Linux 系統(tǒng)上運行,并擁有獨立的內(nèi)存、硬盤、處理器以及可映射的硬件接口。各種服務程序從源碼階段編譯成二進制文件,再經(jīng)過一定的轉(zhuǎn)換方式將可執(zhí)行的二進制文件安裝到容器中。
裝置系統(tǒng)內(nèi)部容器運行原理如圖3 所示,整個系統(tǒng)中首先部署容器運行環(huán)境,原有的進程經(jīng)過一系列的轉(zhuǎn)換成為APP 安裝包。在系統(tǒng)內(nèi)部可根據(jù)實際現(xiàn)場運行需要創(chuàng)建多個容器,如Docker 1,Docker 2,…,Docker N。每個容器內(nèi)部安裝多個應用軟件APP 1,APP 2,…,APP N。容器與容器之間相互隔離,無法直接進行數(shù)據(jù)訪問與交互[5]。另一方面,每個容器都可以獨立進行內(nèi)存、存儲、CPU 使用率上限等參數(shù)的設置。當容器中的APP 由于其自身故障導致占用負荷率較高時,會引起容器報警。同時,不同容器之間又是相互隔離的,因此不會影響到其他容器。這就解決了由于某一個進程異常導致整個系統(tǒng)崩潰的問題。
圖3 裝置系統(tǒng)內(nèi)部容器運行示意Fig.3 Operation of internal containers in the system
采用基于Linux 系統(tǒng)運行的容器技術,保證了了系統(tǒng)內(nèi)部各個APP的安全性。但是,Linux操作系統(tǒng)為非實時操作系統(tǒng),無法在對實時性要求較高的場合使用。而電力系統(tǒng)中的故障判斷與保護出口又完全依賴于實時系統(tǒng)進行處理。為此,提出一種將實時處理單元和管理單元融合為一體的邊緣計算架構(gòu)[6-7]。實時系統(tǒng)主要負責實現(xiàn)現(xiàn)場保護功能、采集并計算相關數(shù)據(jù)以及故障的檢測與切除。管理系統(tǒng)負責用電類產(chǎn)品大容量數(shù)據(jù)采集與存儲上傳。這樣可以在同一個裝置中實現(xiàn)多種管理功能,簡化現(xiàn)場維護復雜程度,也便于設備資產(chǎn)的管理。
邊緣計算裝置內(nèi)部框架如圖4所示,將Linux管理系統(tǒng)單元和實時操作系統(tǒng)(RTOS)單元集成在一個硬件平臺上,其中前者主要負責接入各種外部設備,采集讀取多種終端數(shù)據(jù)并進行邊緣計算處理;后者負責采集當前線路的電壓、電流等電氣量數(shù)據(jù)并進行計算,同時根據(jù)預設保護邏輯進行實時監(jiān)控與保護。RTOS 單元可采集故障點前后多個周期的錄波曲線,供后續(xù)故障分析使用。
基于安全容器技術設計的軟件框架主要特點是各個容器相互隔離,且各APP 之間無法直接進行數(shù)據(jù)交互。故在解決安全性問題的基礎上,還需要在隔離情況下實現(xiàn)數(shù)據(jù)交互功能。
圖4 邊緣計算裝置內(nèi)部框架Fig.4 Internal framework of edge computing devices
在系統(tǒng)內(nèi)部創(chuàng)建一個內(nèi)部通信組件如圖5 所示,該通信組件基于消息隊列遙測傳輸(MQTT)協(xié)議實現(xiàn)統(tǒng)一公共服務。這里定義為統(tǒng)一系統(tǒng)業(yè)務APP 交互組件(eSDK),該組件內(nèi)部連接到系統(tǒng)中MQTT 代理服務器。MQTT 消息傳輸是當前物聯(lián)網(wǎng)領域使用較多的一種基于“消息主題+消息內(nèi)容”的傳輸方式,并以“訂閱+接收”的方式接收或者發(fā)送數(shù)據(jù)。容器中的各個APP連接到MQTT代理服務器上,APP 之間通過MQTT 代理服務器進行數(shù)據(jù)交互,實現(xiàn)安全數(shù)據(jù)訪問。具體數(shù)據(jù)訪問流程是,各個APP 先根據(jù)自身需求向MQTT 代理服務器訂閱目標主題,代理服務器會將各個APP 的訂閱請求和主題記錄到本地庫中。當其中一個APP 向代理服務器發(fā)布主題數(shù)據(jù)時,代理服務器會根據(jù)當前的主題內(nèi)容匹配本地的主題庫,搜索出哪些APP 訂閱了該主題,然后將該主題以及攜帶的數(shù)據(jù)內(nèi)容轉(zhuǎn)發(fā)給訂閱者,這樣就實現(xiàn)了容器內(nèi)部APP之間的數(shù)據(jù)交互。
圖5 內(nèi)部通信組件示意Fig.5 Internal communication components
內(nèi)部通信消息主題以路徑為分隔符,格式為:{app}∕{operator}∕{infoType}∕{infoTarget}∕{infoPath}其中,app為發(fā)送方名稱;operator為發(fā)送方執(zhí)行的目標操作,例如設置或者查詢等;infoType 代表是事件還是請求類消息;infoTarget 與infoType 相對應表明是響應請求或者是事件應答;infoPath是消息傳送的目標方,比如對時則目標是系統(tǒng)時鐘。消息體內(nèi)容采用如下json格式:
{
"token":"12345",
"timestamp":"2004-05-03T17:30:08Z",
……
"body":消息體
}
消息內(nèi)容以json 鍵值對對應的字符串形式表現(xiàn),具備一定的可讀性。消息體中token字段表示當前消息的序號體,timestamp 字段表示發(fā)送該消息的時標,用于標記該消息的產(chǎn)生時間。body 字段內(nèi)容可根據(jù)實際現(xiàn)場應用需求自行定義。例如,設置系統(tǒng)時間的消息可以用如下方式表示:
{app}∕set∕request∕esdk∕clock
{
"dateTime":"2020-08-08T17:30:08Z",
"timeZone":"Asia∕Shanghai"
}
eSDK 組件在功能上主要分對上、對下2 種傳輸,對上完成各個容器中APP 之間數(shù)據(jù)轉(zhuǎn)發(fā)工作,對下實現(xiàn)對裝置硬件信息的更改,如修改裝置IP 地址、修改串口波特率等。operator字段定義為傳輸方式,當傳輸方式是對上傳輸時,即代表eSDK 組件接收到APP 的消息傳輸請求,并根據(jù)主題中infoTarget和infoPath 來確定消息傳遞的目標方,再搜索本地消息主題庫確定該主題是否被訂閱、是否是轉(zhuǎn)發(fā)內(nèi)容。最終根據(jù)判斷結(jié)果將本次消息內(nèi)容轉(zhuǎn)發(fā)給目標容器中的APP;當傳輸方式是對下傳輸時,eSDK組件首先判斷該發(fā)起方APP 是否具有操作權(quán)限,并判斷硬件的操作參數(shù)是否合法。如果權(quán)限不足或硬件操作非法則直接將回復操作失敗的消息給發(fā)送方,如果校驗通過則回復操作成功的消息到發(fā)送方。本裝置中定義修改IP 地址、串口波特率、系統(tǒng)時間以及存儲空間告警上限值為高級修改項目,需要較高的執(zhí)行權(quán)限。
前文中已經(jīng)介紹過,基于安全容器且具備邊緣計算的配用電一體化裝置需要接入多種外接設備進行大數(shù)據(jù)采集與存儲,同時還要兼?zhèn)洮F(xiàn)場故障檢測與故障切除的功能。因此,在硬件設計上采用硬件實時系統(tǒng)[8]組合以Linux 系統(tǒng)為主的通信管理系統(tǒng)。實時系統(tǒng)負責進行對實時性要求較高的現(xiàn)場采樣與計算,如交采采樣、線路保護、故障切除。Linux 管理系統(tǒng)負責進行大數(shù)據(jù)采集與存儲計算[9-10]。硬件核心設計架構(gòu)如圖6所示。
圖6 裝置硬件核心設計Fig.6 Core design of the hardware of the device
終端硬件方案中,主處理器選擇主頻為1.2 GHz 的ARM-A7 核心處理器。外部擴展2 GB 的運行內(nèi)存用于對采集的大量數(shù)據(jù)進行邊緣計算,并根據(jù)計算結(jié)果再次進行高級應用分析。同時,還需要在外部擴展8 GB 的閃存,用來對外接多種設備采集的數(shù)據(jù)進行歷史存儲,便于主站對歷史數(shù)據(jù)進行召喚讀取。硬件方案中的從處理器選擇CORTEX-M4芯片,該芯片外接AD7606 模數(shù)轉(zhuǎn)換芯片并通過電壓和電流互感器實現(xiàn)對現(xiàn)場交流電壓和電流數(shù)據(jù)的采集與計算[11],并根據(jù)處理器內(nèi)部的傅里葉算法以及接地算法等計算并判斷當前線路中是否存在短路故障或者其他異常情況。同時實時采集外部開入信號,開入信號可以滿足國家電網(wǎng)公司2 ms 分辨率要求。主處理器與從處理器之間通過高速通用串行總線(USB)接口進行數(shù)據(jù)交互,從處理器將采集到的電壓和電流數(shù)據(jù)以及開入信號傳輸給主處理器。當從處理器檢測到線路故障[12]時會根據(jù)內(nèi)部設置的邏輯單元直接進行保護跳閘[13]出口動作,同時記錄下當前的故障類型及其發(fā)生時間,并對故障點前6 個周波和故障點后8 個周波進行錄波操作,將最終記錄的故障波形數(shù)據(jù)傳輸給主處理器。主處理器通過遠傳通信傳送到遠方主站系統(tǒng)。當主處理器接收到遠方主站遙控下發(fā)的命令后,會通過USB 接口傳輸控制命令到從處理器端,實現(xiàn)上下交互功能。
邊緣計算配用電一體化終端[14]在實現(xiàn)實時系統(tǒng)采集保護功能與大數(shù)據(jù)存儲的同時,還需具備接入多種外部設備的能力。由于主處理器自身可供使用的通用異步收發(fā)傳輸器(UART)接口以及串行外設接口(SPI)有限,而在現(xiàn)場實際使用中采集傳感器多數(shù)以串口作為數(shù)據(jù)輸出途徑,因此需要對主處理器進行串口擴展來滿足多串口的應用需求,如圖7 所示。選用2 片ST16C554 串口擴展芯片,通過8位數(shù)據(jù)總線連接到主處理器。每片串口擴展芯片可 以 擴 展4 路 串 口,2 片 共 計 擴 展8 路RS232 或RS485 接口,可連接電能表、斷路器、智能無功補償器等外部串口設備。
圖7 接口擴展示意Fig.7 Interface extension
測試時在邊緣計算終端外接多塊電能表模擬臺區(qū)抄表現(xiàn)場,裝置通過網(wǎng)絡連接到用電采集主站系統(tǒng)。在用電采集主站系統(tǒng)中根據(jù)電表檔案信息讀取電表當前與歷史記錄數(shù)據(jù),均能正確上傳抄讀項目數(shù)據(jù),結(jié)果如圖8所示。
通過繼電保護測試儀對裝置進行加量以測試裝置實時采樣計算系統(tǒng)功能性,同時通過內(nèi)部維護工具查看裝置對實時采樣計算數(shù)據(jù)的結(jié)果,所有計算數(shù)據(jù)的精度均在0.5%的誤差范圍內(nèi)。另外,給外部交采回路施加小電流接地故障特征波形,利用繼電保護測試儀的故障回放功能施加故障波形。邊緣計算配用電一體化終端能夠正確判斷識別出故障且上送故障特征錄波波形曲線[15-16],波形顯示如圖9所示。
圖8 電表數(shù)據(jù)抄讀效果展示Fig.8 Display of readings on electricity meters
圖9 線路故障抓取特征(截圖)Fig.9 Feature extraction of line faults(screen shot)
基于安全容器技術實現(xiàn)邊緣計算配用電一體化終端裝置,在邊緣計算層次上采用安全容器對各個APP 進行安全隔離管理,在功能層次上采用實時系統(tǒng)組合管理系統(tǒng)方式,具備多種傳感設備接入、大數(shù)據(jù)抄讀、歷史數(shù)據(jù)存儲功能以及對現(xiàn)場實時電壓、電流等狀態(tài)數(shù)據(jù)的采集計算,能監(jiān)測線路故障特征并對故障點前后波形曲線進行錄波操作,為后續(xù)故障分析提供一定的研判依據(jù)。在實際現(xiàn)場中,1 臺裝置實現(xiàn)了配電類裝置和用電類產(chǎn)品的融合,降低了運維管理部門對多種產(chǎn)品型號的維護與管理成本,也降低了工程人員現(xiàn)場調(diào)試復雜程度。