丁 明, 周 亮, 畢 銳

(合肥工業(yè)大學(xué)教育部光伏系統(tǒng)工程研究中心,安徽合肥 230009)

含分布式電源的微型電網(wǎng),與傳統(tǒng)電網(wǎng)相比,無論是從系統(tǒng)容量和采集點(diǎn)的規(guī)模上以及控制方法上都有較大區(qū)別。對于微型電網(wǎng)而言,數(shù)據(jù)采集系統(tǒng)的快速響應(yīng)特性顯得猶為重要[1-3]。數(shù)據(jù)采集系統(tǒng)作為微網(wǎng)管理控制系統(tǒng)基礎(chǔ)平臺的重要組成部分,負(fù)責(zé)完成與各遠(yuǎn)端IED(Intelligent E-lectronic Device,簡稱IED)裝置及分布式電源控制器的數(shù)據(jù)交換,同時(shí)為微網(wǎng)能量管理系統(tǒng)的上層高級應(yīng)用提供可靠的數(shù)據(jù)源。數(shù)據(jù)采集系統(tǒng)不但自身有著很強(qiáng)的硬件環(huán)境約束性,同時(shí)要求具有很高的穩(wěn)定性和數(shù)據(jù)實(shí)時(shí)性。

數(shù)據(jù)采集系統(tǒng)周期性數(shù)據(jù)總召、對時(shí)等操作會瞬時(shí)增大網(wǎng)絡(luò)負(fù)荷量。經(jīng)過eEye公司的專業(yè)網(wǎng)絡(luò)數(shù)據(jù)流量監(jiān)測軟件Iris分析,總召周期內(nèi)的數(shù)據(jù)流量是正常狀態(tài)下的3倍之多。這些都要求數(shù)據(jù)采集系統(tǒng)在處理這些重要數(shù)據(jù)時(shí)要具有較高的準(zhǔn)確性、可靠性以及靈活性,能夠?qū)α髁坎环€(wěn)定的數(shù)據(jù)流具有較強(qiáng)的可伸縮處理能力。

遠(yuǎn)動信息的采集將由集中采集向就地分布式采集方向發(fā)展[4]。傳統(tǒng)大電網(wǎng)所面臨的龐大數(shù)據(jù)通信問題可以借鑒微網(wǎng)中的數(shù)據(jù)采集系統(tǒng)解決方案。系統(tǒng)的功能下放與測控設(shè)備分布化將大大提高其自身的可靠性。

1 硬件系統(tǒng)結(jié)構(gòu)

基于目前網(wǎng)絡(luò)系統(tǒng)普遍遵循的橫向分布、縱向分層[5]思想,應(yīng)該優(yōu)先選擇建立一個標(biāo)準(zhǔn)的開放分布式網(wǎng)絡(luò)硬件平臺,平臺結(jié)構(gòu)如圖1所示。

圖1 硬件設(shè)備網(wǎng)絡(luò)結(jié)構(gòu)

通信網(wǎng)絡(luò)的良好連接是保證數(shù)據(jù)實(shí)時(shí)性的物質(zhì)基礎(chǔ)[6]。由于RS485串行通信接口受到節(jié)點(diǎn)數(shù)目的限制以及考慮到對網(wǎng)絡(luò)硬件資源的有效充分利用,采用以太網(wǎng)支撐的網(wǎng)絡(luò)層是經(jīng)濟(jì)且實(shí)用的選擇。網(wǎng)關(guān)作為以太網(wǎng)絡(luò)接口與RS485串行接口的規(guī)約轉(zhuǎn)化器,解決不同廠家設(shè)備的入網(wǎng)問題,同時(shí)增加硬件系統(tǒng)的可擴(kuò)展性。文獻(xiàn)[7]提出一種專用數(shù)字通信網(wǎng)關(guān),通過簡化網(wǎng)絡(luò)結(jié)構(gòu)保證數(shù)據(jù)的實(shí)時(shí)性,但是沒有考慮優(yōu)化網(wǎng)關(guān)的功能約束,避免因此造成的不必要的系統(tǒng)延時(shí)[8]。為保證網(wǎng)關(guān)的靈活性,系統(tǒng)應(yīng)該配備相應(yīng)的網(wǎng)關(guān)外圍參數(shù)修改軟件。

可靠的網(wǎng)絡(luò)硬件平臺應(yīng)該提供冗余網(wǎng)路和互為熱備用服務(wù)器。通過劃分一定的網(wǎng)絡(luò)帶寬,微網(wǎng)系統(tǒng)中的SCADA(數(shù)據(jù)采集與監(jiān)視控制系統(tǒng))監(jiān)控信息、繼電保護(hù)故障信息和電能量信息,都可以根據(jù)相應(yīng)的規(guī)約協(xié)議同時(shí)使用以太網(wǎng)絡(luò)傳輸?shù)奖O(jiān)控層,這樣可以充分利用網(wǎng)絡(luò)資源和降低管理成本。為提高系統(tǒng)通信的開放性、兼容性和可靠性,監(jiān)控層中的調(diào)度監(jiān)控工作站與網(wǎng)關(guān)之間的遠(yuǎn)動數(shù)據(jù)傳輸應(yīng)遵循統(tǒng)一的基于 TCP(Transmission Control Protocol,簡稱TCP)的遠(yuǎn)動協(xié)議。文獻(xiàn)[9]介紹了通過修改同樣支持應(yīng)用服務(wù)數(shù)據(jù)單元(ASDU)的IEC60870-5-103規(guī)約,與IEC60870-5-104具有相同的APCI(應(yīng)用規(guī)約控制信息)傳輸接口,使前者同樣可以支持以太網(wǎng)傳輸。

2 軟件系統(tǒng)設(shè)計(jì)

數(shù)據(jù)采集的軟件系統(tǒng)設(shè)計(jì)中需要考慮到物理網(wǎng)絡(luò)環(huán)境的特性。采用以太網(wǎng)方式組建的數(shù)據(jù)采集系統(tǒng),需要考慮TCP/IP協(xié)議與操作系統(tǒng)的配合,并考慮采集系統(tǒng)作為客戶端與各測控單元或電源控制器鏈路的穩(wěn)定性以及數(shù)據(jù)交互的可靠性。對鏈路的穩(wěn)定性和可靠性的合理維護(hù)須仔細(xì)處理,否則會造成系統(tǒng)的性能大幅度降低[10]。在保證硬件系統(tǒng)具有較強(qiáng)可靠性的前提下,軟件系統(tǒng)應(yīng)該具有可靠的通信通道維護(hù)能力,同時(shí)保持較大數(shù)據(jù)吞吐量。軟件系統(tǒng)設(shè)計(jì)從軟件的結(jié)構(gòu)模型、數(shù)據(jù)模型、信息模型3個方面實(shí)現(xiàn)以上要求。

2.1 結(jié)構(gòu)模型

軟件粒度的選擇決定著各功能模塊的大小。由于規(guī)約的解析和打包功能模塊是可重用性較高的模塊,軟件采用模塊化編程可以將各模塊之間的耦合程度降低,同時(shí)在今后軟件擴(kuò)展其它規(guī)約時(shí)也會很方便。數(shù)據(jù)采集系統(tǒng)的軟件框架如圖2所示,大致可以分為外部接口層、規(guī)約層、通信層等部分。

圖2中實(shí)線箭頭代表上行數(shù)據(jù),虛線箭頭代表下行數(shù)據(jù)。同步命名管道通過外部接口發(fā)布管道名稱。微網(wǎng)能量管理系統(tǒng)數(shù)據(jù)處理模塊根據(jù)管道名稱請求寫管道,然后按照約定的數(shù)據(jù)格式將遠(yuǎn)動控制命令發(fā)送給數(shù)據(jù)采集系統(tǒng)。遠(yuǎn)動控制命令將按照規(guī)約重新打包,通過通信平臺直接發(fā)送到對應(yīng)的網(wǎng)關(guān)。網(wǎng)關(guān)程序?qū)⒔邮盏降目刂泼顪?zhǔn)確送到對應(yīng)的裝置。

圖2 軟件系統(tǒng)結(jié)構(gòu)

通信平臺將接收的上行數(shù)據(jù)包放入一個工作隊(duì)列,規(guī)約處理模塊對上行數(shù)據(jù)包逐幀預(yù)讀取,并按照規(guī)約將幀數(shù)據(jù)解析為系統(tǒng)生數(shù)據(jù)并存入內(nèi)存實(shí)時(shí)數(shù)據(jù)庫。數(shù)據(jù)采集系統(tǒng)的外部接口是由擁有優(yōu)越安全性的內(nèi)存實(shí)時(shí)庫和同步命名管道共同實(shí)現(xiàn)的,負(fù)責(zé)采集數(shù)據(jù)和控制命令的轉(zhuǎn)發(fā)工作。

由于IEC60870-5-104等系列遠(yuǎn)動協(xié)議是基于TCP連接,數(shù)據(jù)包有可能丟失、延遲、重復(fù)和亂序,因此應(yīng)用層協(xié)議必須使用超時(shí)和重傳機(jī)構(gòu)[11]。規(guī)約處理模塊和計(jì)時(shí)器模塊共同負(fù)責(zé)相應(yīng)的數(shù)據(jù)傳輸按照嚴(yán)格的糾錯機(jī)制運(yùn)行。

2.2 數(shù)據(jù)模型

數(shù)據(jù)采集系統(tǒng)中的動態(tài)數(shù)據(jù)信息交互采用線程池[12]及其相關(guān)技術(shù)。如果以網(wǎng)關(guān)為單位建立收發(fā)數(shù)據(jù)包線程,那么將會產(chǎn)生大量冗余的線程上下文切換處理,占用大量系統(tǒng)資源,很難確保數(shù)據(jù)的實(shí)時(shí)性、完整性和準(zhǔn)確性。通用通信平臺基于IOCP(I/O完成端口)機(jī)制,實(shí)現(xiàn)高效的數(shù)據(jù)收發(fā),是應(yīng)用程序使用線程池處理異步I/O(輸入輸出)請求的一種成熟通信機(jī)制[13]。IOCP是一種優(yōu)化的多線程并發(fā)模型,通過有效的線程管理,減少線程上下文的切換,避免多線程資源競爭,適合于存在大量套接字I/O請求的場合。默認(rèn)狀態(tài)下,線程池中預(yù)先創(chuàng)建的等待線程的數(shù)目稍大于主機(jī)CPU數(shù)量[14]。

系統(tǒng)啟動后,主線程首先會初始化各線程,從數(shù)據(jù)庫服務(wù)器下裝數(shù)據(jù)采集系統(tǒng)的配置信息參數(shù)表,然后創(chuàng)建內(nèi)存實(shí)時(shí)數(shù)據(jù)庫。主線程在程序正常運(yùn)行時(shí)負(fù)責(zé)數(shù)據(jù)顯示和子線程控制。各線程之間關(guān)系如圖3所示。I/O端口監(jiān)視線程將上行數(shù)據(jù)包指針放入工作隊(duì)列中等待邏輯工作線程的處理。工作隊(duì)列將規(guī)約層與通信層的耦合降到最低,而不影響數(shù)據(jù)的實(shí)時(shí)傳輸。工作隊(duì)列的獨(dú)立性越大,規(guī)約層與通信層的耦合也就越松。處于規(guī)約層的邏輯工作線程同樣采用線程池技術(shù)。為避免數(shù)據(jù)流瓶頸的存在,2級線程池分別處于系統(tǒng)不同的結(jié)構(gòu)層,分?jǐn)傁到y(tǒng)負(fù)載從而保證數(shù)據(jù)流的平穩(wěn)過渡。重要的下行控制數(shù)據(jù)直接通過通信平臺提供的發(fā)送接口單獨(dú)發(fā)送,保證控制命令或規(guī)約交互數(shù)據(jù)幀的無延時(shí)下發(fā),同時(shí)上行數(shù)據(jù)與下行數(shù)據(jù)之間互不影響。

由于數(shù)據(jù)傳輸控制的需要,規(guī)約層需要向各網(wǎng)關(guān)定時(shí)下發(fā)交互數(shù)據(jù)幀。這些下行數(shù)據(jù)發(fā)送請求直接轉(zhuǎn)發(fā)到完成端口的完成隊(duì)列(Completion Queue)中,由I/O端口監(jiān)視線程池中的線程實(shí)時(shí)同步處理。

圖3 核心線程關(guān)系圖

(1)I/O端口監(jiān)視線程。網(wǎng)絡(luò)層的數(shù)據(jù)收發(fā)速度是系統(tǒng)性能的重要標(biāo)志之一。完成端口監(jiān)視線程同步返回完成端口上的異步調(diào)用請求。其主要流程如圖4所示。由于對上行數(shù)據(jù)包只作簡單的轉(zhuǎn)發(fā)處理,IOCP的工作負(fù)載能力足以滿足系統(tǒng)內(nèi)所有網(wǎng)關(guān)的數(shù)據(jù)收發(fā)工作。

圖4 I/O端口監(jiān)視線程流程圖

(2)邏輯工作線程。邏輯工作線程主要處理接收到的數(shù)據(jù)包,完成數(shù)據(jù)的分流,是數(shù)據(jù)采集系統(tǒng)的樞紐。它的處理類似于I/O端口監(jiān)視線程,都采用線程池技術(shù),但邏輯工作線程的激活個數(shù)是由工作隊(duì)列內(nèi)的工作任務(wù)數(shù)量決定的。邏輯工作線程處理工作隊(duì)列中任務(wù)的效率將是決定采集數(shù)據(jù)實(shí)時(shí)性的一個關(guān)鍵因素。這種利用工作隊(duì)列任務(wù)量管理線程池的方法具有很強(qiáng)的靈活性。線程內(nèi)部主要流程如圖5所示。上傳的連接狀態(tài)變化任務(wù)Job_ConnecterStateChange將按照對應(yīng)的網(wǎng)關(guān)號創(chuàng)建或修改網(wǎng)關(guān)上下文GatewayContext。網(wǎng)關(guān)上下文包含規(guī)約傳輸控制所需的所有實(shí)時(shí)控制參數(shù)。

圖5 邏輯工作線程流程圖

(3)同步命名管道線程。命名管道能夠保證2個相互通信的進(jìn)程之間互不干擾又協(xié)調(diào)一致工作。為縮短重要遠(yuǎn)動控制命令響應(yīng)周期,并且保證遙控/遙調(diào)命令數(shù)據(jù)的獨(dú)立性和安全性,下行數(shù)據(jù)不經(jīng)過實(shí)時(shí)數(shù)據(jù)庫,而是單獨(dú)建立一個同步等待線程,以觸發(fā)內(nèi)核對象 Named Pipe(命名管道)讀事件激活該線程。

命名管道支持雙向數(shù)據(jù)傳輸。在成功接收到并成功發(fā)送數(shù)據(jù)處理模塊的遙控/遙調(diào)命令后,同步管道觸發(fā)寫管道事件,將原包內(nèi)容回送給數(shù)據(jù)處理模塊。后者則確認(rèn)數(shù)據(jù)包準(zhǔn)確到達(dá)數(shù)據(jù)采集系統(tǒng)。遙信變位事件的實(shí)時(shí)告警也是通過同步命名管道告知數(shù)據(jù)處理模塊,從而圖形顯示模塊能夠根據(jù)遙信觸發(fā)事件查詢實(shí)時(shí)數(shù)據(jù)庫中更新的遙信信息,不需要定時(shí)掃描實(shí)時(shí)庫,減輕了系統(tǒng)負(fù)擔(dān),縮小了圖形數(shù)據(jù)顯示的延時(shí)。線程內(nèi)部主要流程如圖6所示。

圖6 同步命名管道線程流程圖

(4)計(jì)時(shí)器線程。延時(shí)連接、定時(shí)發(fā)送的控制幀以及數(shù)據(jù)超時(shí)糾錯機(jī)制都需要一個異步的定時(shí)器。該定時(shí)器線程同樣使用了和同步管道相同的內(nèi)核對象觸發(fā)的等待線程技術(shù)。以100 ms為單位,內(nèi)核對象每次被觸發(fā)之后,對每個有效網(wǎng)關(guān)上下文中的所有定時(shí)器對象做相應(yīng)的狀態(tài)檢查并作相應(yīng)的操作或置位,線程內(nèi)部流程如圖7所示。

圖7 計(jì)時(shí)器線程流程圖

(5)鏈接監(jiān)視線程。通信過程中,需要可靠的錯誤恢復(fù)機(jī)制。在出現(xiàn)數(shù)據(jù)異常時(shí),規(guī)約層傳輸控制可能會斷開與某個網(wǎng)關(guān)的鏈接并立即重連。為減少阻塞型鏈接在延時(shí)連接過程中對其它鏈接數(shù)據(jù)收發(fā)的影響,通信平臺需要一個異步連接機(jī)制。鏈接監(jiān)視線程中分配各網(wǎng)關(guān)相應(yīng)的LinkContext(鏈接上下文),該上下文中保存了鏈接對應(yīng)的鏈接套接字、數(shù)據(jù)緩沖地址以及順序控制參數(shù)。當(dāng)建立一個新的鏈接,線程調(diào)用關(guān)聯(lián)函數(shù)將當(dāng)前鏈路套接字與IOCP關(guān)聯(lián)后,這條鏈路上的所有數(shù)據(jù)交互都會經(jīng)過完成端口,線程內(nèi)部流程如圖8所示。

圖8 鏈接監(jiān)視線程流程圖

2.3 信息模型

規(guī)約處理類CProtocol Process作為主干類提供初始化通信平臺、數(shù)據(jù)交互處理、管理計(jì)時(shí)器以及返回自定義常見錯誤信息等操作。規(guī)約支持類CPackFrame和CSolveFrame配合規(guī)約處理類提供打包和解包方法接口,完成數(shù)據(jù)收發(fā)工作,同時(shí)CSolveFrame類將上行數(shù)據(jù)及時(shí)更新到實(shí)時(shí)數(shù)據(jù)庫中。通信類CCommunication基于IOCP實(shí)現(xiàn),對規(guī)約處理類提供通用通信接口。程序中的異步套接字采用微軟公司的封裝類CAsync-Socket。異步套接字是為了避免在同一線程中的阻塞問題。IOCP機(jī)制如前所述是通過管理多線程的上下文切換改善效率,同時(shí)封裝了異步套接字的調(diào)用。數(shù)據(jù)操作類 CIOCPBuffer基于OVERLAPPED數(shù)據(jù)結(jié)構(gòu)為IOCP通信提供各類數(shù)據(jù)操作。它是IOCP依賴的特定數(shù)據(jù)結(jié)構(gòu),與CPtrQueue建立的數(shù)據(jù)緩存循環(huán)隊(duì)列所屬范疇不同。工作隊(duì)列操作類CJobProcess提供一個靜態(tài)工作隊(duì)列鏈表JobQueueList以確保其唯一性,同時(shí)提供對隊(duì)列成員的具體操作。

系統(tǒng)靜態(tài)對象如圖9所示,其中Gateway-Context(網(wǎng)關(guān)上下文)和 LinkContext的區(qū)分,不僅降低了網(wǎng)絡(luò)層與規(guī)約層耦合,同時(shí)方便了管理。兩者的對應(yīng)點(diǎn)是網(wǎng)關(guān)號。連接成功并成功創(chuàng)建和初始化的上下文將存放于ContextMap映射中,以網(wǎng)關(guān)號作為對象主鍵。斷開連接或刪除網(wǎng)關(guān)時(shí),相應(yīng)的上下文直接從映射中釋放。LinkContext中的鏈路狀態(tài)分為可用狀態(tài)USABLE和不可用狀態(tài)UNUSABLE,GatewayContex中的網(wǎng)關(guān)狀態(tài)分為關(guān)閉CLOSED、連接CONNECTED、激活A(yù)CTIVE、待關(guān)閉CLOSING。鏈路狀態(tài)的改變必須通知對應(yīng)的網(wǎng)關(guān)上下文,而網(wǎng)關(guān)狀態(tài)中只有關(guān)閉和待關(guān)閉才會影響到鏈路狀態(tài)。

圖9 系統(tǒng)靜態(tài)對象

邏輯工作線程池中的線程接收到TCP數(shù)據(jù)包之后,會將其轉(zhuǎn)存到一個數(shù)據(jù)緩存循環(huán)隊(duì)列QRec-Queue中。這個數(shù)據(jù)緩存循環(huán)隊(duì)列提供可靠的讀寫操作,不支持定點(diǎn)插入,能夠很好地保證數(shù)據(jù)的完整性和順序性。引入數(shù)據(jù)循環(huán)隊(duì)列是為了避免數(shù)據(jù)的收發(fā)影響解析數(shù)據(jù)幀。根據(jù)分層解析原則,從QRecQueue隊(duì)列中預(yù)讀取的I幀將會被再次深入解析,本文中把讀取到的I幀寫入解包緩存循環(huán)隊(duì)列I_FrameBuf。它與QRecQueue同樣都是數(shù)據(jù)緩存循環(huán)隊(duì)列類CPtrQueue的對象。

3 數(shù)據(jù)采集系統(tǒng)的應(yīng)用

合肥工業(yè)大學(xué)微網(wǎng)實(shí)驗(yàn)平臺基于上述網(wǎng)絡(luò)硬件平臺構(gòu)建思想,采用專用測控裝置和數(shù)字網(wǎng)關(guān)。系統(tǒng)內(nèi)目前已有71個遙控點(diǎn)、609個遙測信息點(diǎn)和266個遙信信息點(diǎn)。

根據(jù)軟件系統(tǒng)設(shè)計(jì)的思路,編制系統(tǒng)主程序：DAS-MGEMS。根據(jù)文獻(xiàn)[15,16]提供的測試原則,經(jīng)過專業(yè)測試軟件的壓力測試、配置參數(shù)測試和應(yīng)用功能測試,目前軟件已在合肥工業(yè)大學(xué)微網(wǎng)實(shí)驗(yàn)平臺通過各功能模塊的聯(lián)調(diào)實(shí)驗(yàn),系統(tǒng)運(yùn)行正常、穩(wěn)定可靠,達(dá)到設(shè)計(jì)的要求?；贖P公司的系統(tǒng)性能測試軟件 LoadRunner對主程序DAS-MGEMS運(yùn)行時(shí),系統(tǒng)的CPU使用率變化和TCP數(shù)據(jù)包傳輸請求量變化的對比,如圖10所示。網(wǎng)內(nèi)數(shù)據(jù)流量因?yàn)橄到y(tǒng)周期事件所導(dǎo)致的瞬時(shí)劇烈波動對系統(tǒng)資源負(fù)載變化的影響不明顯,系統(tǒng)運(yùn)行畫面如圖11所示。

圖10 數(shù)據(jù)采集系統(tǒng)運(yùn)行參數(shù)對比圖

圖11 系統(tǒng)運(yùn)行畫面

4 結(jié) 論

本文首先介紹了數(shù)據(jù)采集系統(tǒng)運(yùn)行的網(wǎng)絡(luò)硬件環(huán)境,在此基礎(chǔ)上提出建立基于IOCP機(jī)制和優(yōu)化的通信管道維護(hù)技術(shù)的軟件模型,并對各關(guān)鍵技術(shù)做了詳細(xì)介紹。根據(jù)面向?qū)ο蟮慕Ｋ枷?采用UML建立軟件的對象模型,使用C++語言編制軟件,軟件在實(shí)驗(yàn)平臺中應(yīng)用效果良好。通過對系統(tǒng)深入分析,得到以下結(jié)論：

(1)基于線程池技術(shù)實(shí)現(xiàn)的高效的通信機(jī)制已經(jīng)很成熟,但結(jié)合完成端口,利用系統(tǒng)內(nèi)任務(wù)的工作量實(shí)現(xiàn)系統(tǒng)的自我管理,可以進(jìn)一步提高系統(tǒng)的靈活性和實(shí)時(shí)性。

(2)系統(tǒng)中對通信通道的維護(hù)采用2級上下文機(jī)制,有效方便的管理確保了通信的準(zhǔn)確性。

(3)同步等待線程的多處應(yīng)用、上下文的合理維護(hù)以及IOCP的引入共同促進(jìn)了系統(tǒng)資源的大幅度節(jié)約。

[1]楊 為,丁 明,畢 銳,等.微電網(wǎng)實(shí)驗(yàn)平臺的設(shè)計(jì)[J].合肥工業(yè)大學(xué)學(xué)報(bào)：自然科學(xué)版,2010,33(1)：38-41.

[2]王成山,肖朝霞,王守相.微網(wǎng)綜合控制與分析[J].電力系統(tǒng)自動化,2008,32(7)：98-103.

[3]李 鵬,張 玲,王 偉,等.微網(wǎng)技術(shù)應(yīng)用與分析[J].電力系統(tǒng)自動化,2009,33(20)：109-114.

[4]洪憲平.走向網(wǎng)絡(luò)化的遠(yuǎn)動系統(tǒng)[J].電力系統(tǒng)自動化,2001,25(6)：1-3.

[5]田國政.變電站自動化系統(tǒng)的通信網(wǎng)絡(luò)及傳輸規(guī)約選擇[J].電網(wǎng)技術(shù),2003,27(9)：66-68.

[6]高志遠(yuǎn),龔迎智.模擬RT U軟件的設(shè)計(jì)和實(shí)現(xiàn)[J].電力系統(tǒng)自動化,2008,32(5)：72-75.

[7]閻常友,周 濤,楊奇遜,等.分布式電網(wǎng)動態(tài)監(jiān)測系統(tǒng)通信網(wǎng)關(guān)的研制[J].電力系統(tǒng)自動化,2004,28(20)：68-71.

[8]Kueck J D,Staunton R H,Labinov S D,et al.Microgrid energy management system[D].Oak Ridge：Oak Ridge National Labo ratory,2003：171-173.

[9]廖澤友,蔡運(yùn)清.IEC60870-5-103和IEC60870-5-104協(xié)議應(yīng)用經(jīng)驗(yàn)[J].電力系統(tǒng)自動化,2003,27(4)：66-68.

[10]Richter J,Nasarre C.Windows via C/C++[M].葛子昂,譯.北京：清華大學(xué)出版社,2008：171-173.

[11]趙 淵,沈智健.基于TCP/IP的 IEC60870-5-104遠(yuǎn)動規(guī)約在電力系統(tǒng)中的應(yīng)用[J].電網(wǎng)技術(shù),2003,27(10)：56-61.

[12]王險(xiǎn)峰,劉寶宏.Windows環(huán)境下的多線程編程原理與應(yīng)用[M].北京：清華大學(xué)出版社,2002：21-23.

[13]陳和平,周靜寧,顧晉廣,等.IOCP機(jī)制與網(wǎng)絡(luò)代理服務(wù)器實(shí)現(xiàn)方法[J].計(jì)算機(jī)應(yīng)用,2003,23(4)：109-114.

[14]葉 鋒,陳和平,肖金生.基于IOCP的多串口與網(wǎng)絡(luò)通信的實(shí)現(xiàn)[J].武漢理工大學(xué)學(xué)報(bào)：信息與管理工程版,2008,30(2)：197-200.

[15]何 衛(wèi),徐勁松.IEC60870-5-6一致性規(guī)則探討[J].電力系統(tǒng)自動化,2003,27(15)：78-79.

[16]李國杰,張 丹,姬希娜,等.變電站子站設(shè)備通信協(xié)議一致性測試系統(tǒng)的開發(fā)(一)：設(shè)計(jì)與應(yīng)用[J].電力系統(tǒng)自動化,2006,30(15)：26-29.