基于PIO 算法的海量用電數(shù)據(jù)協(xié)同交互系統(tǒng)設計

康 峰，劉振華，蘇立偉，楊秋勇，蘇華權

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

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

1 系統(tǒng)結(jié)構設計

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

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

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

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

1.1 計算平臺服務器

與普通服務器相比，計算平臺服務器由可信平臺控制模塊保護。基于可信控制模塊，完成了系統(tǒng)軟件設計、硬件測試、身份認證和數(shù)據(jù)加密[11]。

計算平臺服務器結(jié)構如圖2 所示。

圖2 計算平臺服務器結(jié)構

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

1.2 終端工作站

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

1.3 智能協(xié)同蜜網(wǎng)結(jié)構設計

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

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

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

2 軟件部分設計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實 驗

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語

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