康 峰，劉振華，蘇立偉，楊秋勇，蘇華權(quán)

（1.廣東電網(wǎng)有限責(zé)任公司客戶服務(wù)中心，廣東廣州 510000；2.廣東電網(wǎng)有限責(zé)任公司信息中心，廣東廣州 510000）

在電力系統(tǒng)規(guī)模龐大、網(wǎng)絡(luò)結(jié)構(gòu)日趨復(fù)雜的今天，電力數(shù)據(jù)流量和負(fù)荷的不確定性對電力系統(tǒng)調(diào)度算法提出了更高的要求。對于大容量電力數(shù)據(jù)協(xié)同交互系統(tǒng)的協(xié)作互動設(shè)計，需要集體智慧的創(chuàng)造，分布在不同地點的不同設(shè)計團(tuán)隊?wèi)?yīng)經(jīng)常進(jìn)行數(shù)據(jù)交互、協(xié)作，以確保工作順利進(jìn)行[1]。在協(xié)同環(huán)境的系統(tǒng)結(jié)構(gòu)和數(shù)據(jù)管理的交互要求下，傳統(tǒng)的基于海量用電數(shù)據(jù)協(xié)同交互系統(tǒng)設(shè)計方式的優(yōu)化算法有兩種，一種是采用邊緣計算方法[2]，其基于邊緣計算的框架，利用邊緣服務(wù)器提供全局的監(jiān)控能力和虛假數(shù)據(jù)檢測功能；另一種是基于OpenFlow 協(xié)議[3]，該方法提出一種面向電力業(yè)務(wù)的IP 與光傳輸網(wǎng)集中式統(tǒng)一控制架構(gòu)以及業(yè)務(wù)協(xié)同控制機(jī)制，以實現(xiàn)電力IP網(wǎng)絡(luò)與光傳輸網(wǎng)的高效協(xié)同。然而，上述兩種方法受海量電力數(shù)據(jù)的復(fù)雜協(xié)同交互和隨機(jī)不確定性的影響，導(dǎo)致協(xié)同交互效果不佳。針對這一問題，設(shè)計了基于鴿群算法（Pigeon-Inspired Optimization，PIO）的海量用電數(shù)據(jù)協(xié)同交互系統(tǒng)。

1 系統(tǒng)結(jié)構(gòu)設(shè)計

在系統(tǒng)結(jié)構(gòu)設(shè)計中，以文件、聲音、圖像等形式，動態(tài)交換海量協(xié)作交互數(shù)據(jù)，并選擇一個合適的瀏覽器發(fā)布到用戶地址[4]。利用客戶端/服務(wù)器模型，負(fù)責(zé)用戶與服務(wù)提供商之間的通信描述，實現(xiàn)用戶的實時交互[5]。

利用WWW 瀏覽器將服務(wù)器與協(xié)同用戶結(jié)合，并通過HTTP 協(xié)議實現(xiàn)海量用電數(shù)據(jù)協(xié)同交互[6]。整個體系結(jié)構(gòu)如圖1 所示。

圖1 海量用電數(shù)據(jù)協(xié)同交互系統(tǒng)總體結(jié)構(gòu)

由圖1 可知，服務(wù)端負(fù)責(zé)維護(hù)已經(jīng)被用戶訪問的產(chǎn)品信息，并將其轉(zhuǎn)換為選定的數(shù)據(jù)格式[7-8]。無論是通過WWW 瀏覽器訪問還是使用CAD 數(shù)據(jù)協(xié)同交互，服務(wù)器會在向用戶發(fā)送數(shù)據(jù)前，將數(shù)據(jù)轉(zhuǎn)換成規(guī)范規(guī)定的格式，在互聯(lián)網(wǎng)上交流[9-10]。

1.1 計算平臺服務(wù)器

與普通服務(wù)器相比，計算平臺服務(wù)器由可信平臺控制模塊保護(hù)?；诳尚趴刂颇K，完成了系統(tǒng)軟件設(shè)計、硬件測試、身份認(rèn)證和數(shù)據(jù)加密[11]。

計算平臺服務(wù)器結(jié)構(gòu)如圖2 所示。

圖2 計算平臺服務(wù)器結(jié)構(gòu)

由圖2 可知，啟動設(shè)備上電后，可信控制模塊先于CPU 啟動，形成信任鏈，實現(xiàn)主動防御設(shè)備系統(tǒng)的初始狀態(tài)[12]。在可信控制模塊的支持下，實時或觸發(fā)式的動態(tài)測量系統(tǒng)的進(jìn)程、模塊、執(zhí)行命令等關(guān)鍵信息，保證了系統(tǒng)執(zhí)行部分主動防御功能。

1.2 終端工作站

終端工作站設(shè)有高端通用的微型架構(gòu)，并配置大屏幕顯示、大容量內(nèi)存及外接存儲器，具有強(qiáng)大的信息處理、高性能的圖形圖像處理以及網(wǎng)絡(luò)連接等功能。該工作站采用了英特爾至強(qiáng)處理器，能夠在100 MHz 總線上多路處理數(shù)據(jù)[13]。

1.3 智能協(xié)同蜜網(wǎng)結(jié)構(gòu)設(shè)計

采用智能化協(xié)作蜜網(wǎng)結(jié)構(gòu)，可以監(jiān)控整個網(wǎng)絡(luò)的覆蓋范圍，實時監(jiān)控蜜網(wǎng)蜜罐內(nèi)入侵行為數(shù)據(jù)[14]。這要求蜜網(wǎng)在不引起明顯延遲的情況下執(zhí)行任務(wù)。智能協(xié)同蜜網(wǎng)結(jié)構(gòu)如圖3 所示。

如圖3 所示，在逆向代理運行模式下，其操作流程能夠按照控制器配置所需，通過從數(shù)據(jù)包中提取特定標(biāo)簽信息，然后蜜網(wǎng)控制器生成SDN 流量規(guī)則，檢查SDN 交換機(jī)標(biāo)簽信息，從而實現(xiàn)相應(yīng)的網(wǎng)絡(luò)流量控制策略[15]。

圖3 智能協(xié)同蜜網(wǎng)結(jié)構(gòu)

2 軟件部分設(shè)計

2.1 基于PIO算法的協(xié)同交互數(shù)據(jù)全局最優(yōu)解確定

PIO 算法是根據(jù)鴿群飛行特征采取的一種優(yōu)化算法，在飛行的不同階段選擇不同的導(dǎo)航工具。鴿群在飛行時依靠自己的航路圖和引導(dǎo)規(guī)劃飛行路線，飛到目的地后，就變成了依靠地標(biāo)導(dǎo)航，重新規(guī)劃自己的飛行路線，并根據(jù)新計劃對初始航線做一些改動，以完成整個飛行過程[16]。

設(shè)海量用電數(shù)據(jù)協(xié)同交互問題的解空間是D維空間，第i只鴿子的位置和速度表達(dá)式為：

式中，R表示方位因子，取值范圍為0～1；e-Rt表示鴿子搜索的不同方位次數(shù)；xgbest表示鴿子全局搜索的最優(yōu)位置；t表示迭代次數(shù)；rand 表示隨機(jī)數(shù)。

海量用電數(shù)據(jù)協(xié)同交互中全局最優(yōu)解輸出流程如圖4 所示。

圖4 全局最優(yōu)解輸出流程

圖4 中的終止條件為當(dāng)鴿群接近目的地時開始按照路標(biāo)操作，到達(dá)最終目的地。操作員在鴿群更新的時候，會根據(jù)鴿子的適應(yīng)程度排序，并且將不熟悉路標(biāo)或無法辨認(rèn)的鴿子丟掉。

更新鴿群數(shù)量計算公式，如下所示：

其余種群的鴿群中心位置計算公式為：

式中，f(·)表示適應(yīng)度函數(shù)。

以鴿子的飛行目的地為中心，分析其飛行過程中的飛行狀態(tài)。大多數(shù)鴿群都是直接朝目標(biāo)飛行，有些則會沒有目標(biāo)飛行，但當(dāng)其看到成群飛向目的地的鴿子時，也會跟著飛向同一個方向。因此要不斷地更新鴿子的位置，計算公式如下所示：

群體中所有個體都按照式（1）和（2）更新自己的速度和位置，記錄種群的全局最優(yōu)解和種群的歷史最優(yōu)解。如果迭代結(jié)束條件不滿足，則重新計算種群中的個體適應(yīng)值。

按種群個體的適應(yīng)值來分類鴿子，并遺棄劣質(zhì)鴿子，實現(xiàn)種群最優(yōu)解的全局更新。如果不能滿足終止條件，可確定剩余種群的中心位置，反之，輸出種群最優(yōu)解。

2.2 協(xié)同交互流程設(shè)計

根據(jù)確定的基于PIO 算法的協(xié)同交互數(shù)據(jù)全局最優(yōu)解，獲取滿足終止條件的交互數(shù)據(jù)。為了保證海量用電數(shù)據(jù)間的高效協(xié)同交互，設(shè)計如下流程：

步驟一：通過數(shù)據(jù)交換接口接收共享信息、圖形、文件等信息。

步驟二：當(dāng)服務(wù)器接收到全部數(shù)據(jù)后，通過多級安全認(rèn)證機(jī)制判斷請求是否合理，如果要求不合理，則服務(wù)器拒絕請求；若請求是合理的，服務(wù)器繼續(xù)下一步。

步驟三：服務(wù)器通過servlets 將交換數(shù)據(jù)轉(zhuǎn)換為統(tǒng)一的數(shù)據(jù)格式，滿足用戶合理的數(shù)據(jù)交換請求。

步驟四：通過ORACLE 數(shù)據(jù)庫存儲STEP 數(shù)據(jù)，實現(xiàn)高效管理。

步驟五：用戶從ORACLE 中抽取相應(yīng)的STEP 數(shù)據(jù)，按照數(shù)據(jù)處理指令，或根據(jù)其處理邏輯，將數(shù)據(jù)處理過程轉(zhuǎn)換為實體，完成對數(shù)據(jù)的轉(zhuǎn)換。

3 實 驗

3.1 實驗環(huán)境設(shè)置

使用兩臺物理機(jī)搭建如圖5 所示的實驗環(huán)境。

圖5 實驗環(huán)境裝置

數(shù)據(jù)交互利用OpenSwitch軟件實現(xiàn)，利用虛擬機(jī)的方式，安裝多個虛擬機(jī)系統(tǒng)。在實驗環(huán)境中，通過分別配置HTTP 和SSH 兩個蜜罐，再部署相應(yīng)的服務(wù)類型。設(shè)備的輸入輸出數(shù)據(jù)需要大量的資源來支持，當(dāng)特征識別與顯示識別不一致時，表明其在處理攻擊請求時會出現(xiàn)一些瓶頸。因此，需要從兩個方面評估系統(tǒng)性能，分別是吞吐量和時延。

3.2 系統(tǒng)性能評估

吞吐量反映了系統(tǒng)批量傳輸數(shù)據(jù)的性能，而HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)情形下的吞吐量分別為8.2 Gbit/s 和3.8 Gbit/s。

從吞吐量角度評估邊緣計算方法、OpenFlow 協(xié)議和基于PIO 算法的協(xié)同交互系統(tǒng)，圖6 給出了基于iperf工具下獲取的吞吐量結(jié)果。

圖6 三種系統(tǒng)吞吐量性能對比分析

由圖6 可知，使用邊緣計算方法的HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)下的數(shù)據(jù)吞吐量分別為6.2 Gbit/s和7.1 Gbit/s，與實際吞吐量相差較大；使用OpenFlow協(xié)議的HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)下的數(shù)據(jù)吞吐量分別為4.7 Gbit/s 和4.0 Gbit/s，與實際吞吐量不一致；使用基于PIO 算法的協(xié)同交互系統(tǒng)，HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)下的數(shù)據(jù)吞吐量分別為8.2 Gbit/s 和3.8 Gbit/s，與實際吞吐量一致。

以客戶端和服務(wù)器間往返時間為基礎(chǔ)測量獲取時延，開啟HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)的平均時延分別在0.5 ms 左右和1.0～1.5 ms 范圍內(nèi)波動。三種系統(tǒng)的時延變化如圖7 所示。圖7 中，空心圖形表示HTTP 蜜罐服務(wù)，實心圖形表示SSH 蜜罐服務(wù)。

圖7 三種系統(tǒng)的時延變化對比分析

由圖7 可知，邊緣計算方法開啟HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)的平均時延分別在0.5～0.85 ms 和1.0～1.5 ms 范圍內(nèi)波動；OpenFlow 協(xié)議開啟HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)的平均時延分別在0.25～0.75 ms 和1.20～1.75 ms 范圍內(nèi)波動；設(shè)計系統(tǒng)開啟HTTP 蜜罐服務(wù)和SSH 蜜罐服務(wù)的平均時延分別在0.5 ms 和1.0～1.5 ms 范圍內(nèi)波動。綜上所述，設(shè)計系統(tǒng)的數(shù)據(jù)協(xié)同交互效果更好。

4 結(jié)束語

根據(jù)海量用電數(shù)據(jù)協(xié)同交互的特點，提出了一種基于PIO 算法的海量用電數(shù)據(jù)協(xié)同交互系統(tǒng)設(shè)計方案。該方法通過交換數(shù)據(jù)對象，降低了網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)，提高了數(shù)據(jù)交互的效率。通過實驗證明，該方法雖然能夠有效提高大容量電力數(shù)據(jù)協(xié)同交互的性能，但鴿群算法生成時間短，數(shù)學(xué)理論無法完全證明其收斂性，這將是今后研究的重點。