版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)
文檔簡介
1、1基于CAN網(wǎng)采用滑動窗口技術(shù)傳輸電網(wǎng)故障信息的方案實現(xiàn)唐喜1孟巖1(北京四方繼保護自動化股份有限公司研發(fā)中心北京100085)摘要:摘要:針對CAN(ControllerAreawk)網(wǎng)傳輸智能電子設(shè)備IED(IntelligentElectronicDevice,以下簡稱IED)信息速度慢的現(xiàn)狀,提出基于CAN網(wǎng)結(jié)構(gòu)采用滑動窗口技術(shù)實現(xiàn)IED內(nèi)部各通信插件之間信息交換的方法,將以太網(wǎng)TCPIP協(xié)議中的“一問多答”、“斷點續(xù)傳”等先進
2、技術(shù)應(yīng)用到CAN網(wǎng),可使IED大量的描述信息準(zhǔn)確、快速交換,尤其是IED長時間故障錄波后,可快速上傳到分析終端進行故障診斷,緩解IED嵌入式系統(tǒng)的緩沖壓力,提高IED長時間故障錄波次數(shù),滿足國內(nèi)外市場對IED連續(xù)故障錄波能力的高要求。對比試驗發(fā)現(xiàn),與傳統(tǒng)的“停止等待協(xié)議”相比,“滑動窗口協(xié)議”傳輸電網(wǎng)故障信息更加高效,同時“滑動窗口協(xié)議”配置靈活,通過設(shè)變窗口尺寸,即可兼容“停止等待協(xié)議”。此技術(shù)也可用于IED其它信息要求快速交換的場合
3、。關(guān)鍵詞:關(guān)鍵詞:IED;滑動窗口;停止等待協(xié)議;嵌入式系統(tǒng)0引言引言電力行業(yè)正在飛速發(fā)展,電力系統(tǒng)不斷壯大,快速、準(zhǔn)確定位電網(wǎng)故障顯得尤為重要,從而用戶對IED故障錄波[1]能力要求也不斷提高,迫使各大IED生產(chǎn)廠家不斷推出新的硬件、軟件平臺,隨著近幾年電子工業(yè)的發(fā)展,硬件不斷網(wǎng)絡(luò)化,軟件網(wǎng)絡(luò)化也有了新的進展,但出于對IED實時性的特殊要求,保護軟件直接借用TCPIP協(xié)議[2]顯然不能滿足快速性要求,為此需要采用簡單、可靠協(xié)議,通常各
4、IED生產(chǎn)廠家對IED內(nèi)部各插件之間的通信協(xié)議均是自己制訂,沒有統(tǒng)一的標(biāo)準(zhǔn),在對故障錄波能力要求不高的情況下,都可以滿足要求。但隨著國內(nèi)外市場對IED故障錄波能力要求的不斷提高,傳統(tǒng)的軟件協(xié)議已不能滿足要求。故障錄波存儲容量、傳輸速度、打印速度等已成為衡量IED能力的一個重要指標(biāo)。以往電網(wǎng)出現(xiàn)大擾動時,故障復(fù)雜,再加上連續(xù)故障,大多數(shù)IED的故障錄波并不理想,有的因為故障錄波超過存儲容量,更多的還是因為IED嵌入式系統(tǒng)[3]緩沖受限,故
5、障錄波后不能及時存儲、上傳至遠方,造成錄波數(shù)據(jù)丟失,即使不丟失,想及時查看故障波形也需要等待好長時間,原因就在于大多數(shù)IED對于錄波處理采用傳統(tǒng)的“停止等待協(xié)議”[4],不能滿足錄波容量大、快速傳輸?shù)囊?,成為IED錄波處理能力的瓶頸。本文提出的滑動窗口技術(shù)可以打破此瓶頸,提高IED錄波處理能力的性能指標(biāo),并給出基于CAN網(wǎng)的實現(xiàn)方案及對比試驗。1原理原理CAN[5]屬于現(xiàn)場總線的范疇它是一種有效支持分布式控制或?qū)崟r控制的串行通信網(wǎng)絡(luò)。
6、CAN已經(jīng)形成國際標(biāo)準(zhǔn),并已被公認(rèn)為幾種最有前途的現(xiàn)場總線之一。CAN具有十分優(yōu)越的特點,使人們樂于選擇。這些特性包括:?低成本?極高的總線利用率?很遠的數(shù)據(jù)傳輸距離(長達10Km)?高速的數(shù)據(jù)傳輸速率(高達1Mbits)?可根據(jù)報文的ID決定接收或屏蔽該報文?可靠的錯誤處理和檢錯機制[6]?發(fā)送的信息遭到破壞后,可自動重發(fā)?節(jié)點在錯誤嚴(yán)重的情況下具有自動退出總線的功能3(1)窗口機制滑動窗口協(xié)議的基本原理就是在任意時刻,發(fā)送方都維持了
7、一個連續(xù)的允許發(fā)送的幀的序號,稱為發(fā)送窗口;同時,接收方也維持了一個連續(xù)的允許接收的幀的序號,稱為接收窗口。發(fā)送窗口和接收窗口的序號的上下界不一定要一樣,甚至大小也可以不同。不同的滑動窗口協(xié)議窗口大小一般不同。發(fā)送方窗口內(nèi)的序列號代表了那些已經(jīng)被發(fā)送,但是還沒有被確認(rèn)的幀,或者是那些可以被發(fā)送的幀。下面舉一個例子(假設(shè)發(fā)送窗口尺寸為2幀,接收窗口尺寸為1幀)。①初始態(tài),發(fā)送方?jīng)]有幀發(fā)出,發(fā)送窗口前后沿相重合。接收方0號窗口打開,等待接收
8、0號幀。②發(fā)送方打開0號窗口,表示已發(fā)出0幀但尚確認(rèn)返回信息。此時接收窗口狀態(tài)不變。③發(fā)送方打開0、1號窗口,表示0、1號幀均在等待確認(rèn)之列。至此,發(fā)送方打開的窗口數(shù)已達規(guī)定限度,在未收到新的確認(rèn)返回幀之前,發(fā)送方將暫停發(fā)送新的數(shù)據(jù)幀。接收窗口此時狀態(tài)仍未變。④接收方已收到0號幀,0號窗口關(guān)閉,1號窗口打開,表示準(zhǔn)備接收1號幀。此時發(fā)送窗口狀態(tài)不變。⑤發(fā)送方收到接收方發(fā)來的0號幀確認(rèn)返回信息,關(guān)閉0號窗口,表示從重發(fā)表中刪除0號幀。此時
9、接收窗口狀態(tài)仍不變。⑥發(fā)送方繼續(xù)發(fā)送2號幀,2號窗口打開,表示2號幀也納入待確認(rèn)之列。至此,發(fā)送方打開的窗口又已達規(guī)定限度,在未收到新的確認(rèn)返回幀之前,發(fā)送方將暫停發(fā)送新的數(shù)據(jù)幀,此時接收窗口狀態(tài)仍不變。⑦接收方已收到1號幀,1號窗口關(guān)閉,2號窗口打開,表示準(zhǔn)備接收2號幀。此時發(fā)送窗口狀態(tài)不變。⑧發(fā)送方收到接收方發(fā)來的1號幀收畢的確認(rèn)信息,關(guān)閉1號窗口,表示從重發(fā)表中刪除1號幀。此時接收窗口狀態(tài)仍不變。若從滑動窗口的觀點來統(tǒng)一看待1比特
10、滑動窗口、后退n及選擇重傳三種協(xié)議,它們的差別僅在于各自窗口尺寸的大小不同而已。1比特滑動窗口協(xié)議:發(fā)送窗口=1幀,接收窗口=1幀;后退n協(xié)議:發(fā)窗口1幀,接收窗口1幀;選擇重傳協(xié)議:發(fā)送窗口1幀接收窗口1幀。(2)1比特滑動窗口協(xié)議[13]當(dāng)發(fā)送窗口和接收窗口的大小固定為1時,滑動窗口協(xié)議退化為停等協(xié)議(stop--wait)。該協(xié)議規(guī)定發(fā)送方每發(fā)送一幀后就要停下來,等待接收方已正確接收的確認(rèn)(acknowledgement)返回后才
11、能繼續(xù)發(fā)送下一幀。由于接收方需要判斷接收到的幀是新發(fā)的幀還是重新發(fā)送的幀,因此發(fā)送方要為每一個幀加一個序號。由于停等協(xié)議規(guī)定只有一幀完全發(fā)送成功后才能發(fā)送新的幀,因而只用一比特來編號就夠了。(3)后退n協(xié)議由于停等協(xié)議要為每一個幀進行確認(rèn)后才繼續(xù)發(fā)送下一幀,大大降低了信道利用率,因此又提出了后退n協(xié)議。后退n協(xié)議中,發(fā)送方在發(fā)完一個數(shù)據(jù)幀后,不停下來等待應(yīng)答幀,而是連續(xù)發(fā)送若干個數(shù)據(jù)幀,即使在連續(xù)發(fā)送過程中收到了接收方發(fā)來的應(yīng)答幀,也可
12、以繼續(xù)發(fā)送。且發(fā)送方在每發(fā)送完一個數(shù)據(jù)幀時都要設(shè)置超時定時器。只要在所設(shè)置的超時時間內(nèi)未收到確認(rèn)幀,就要重發(fā)相應(yīng)的數(shù)據(jù)幀。如:當(dāng)發(fā)送方發(fā)送了N個幀后,若發(fā)現(xiàn)該N幀的前一個幀在計時器超時后仍未返回其確認(rèn)信息,則該幀被判為出錯或丟失,此時發(fā)送方就不得不重新發(fā)送出錯幀及其后的N幀。從這里不難看出,后退n協(xié)議一方面因連續(xù)發(fā)送數(shù)據(jù)幀而提高了效率,但另一方面,在重傳時又必須把原來已正確傳送過的數(shù)據(jù)幀進行重傳(僅因這些數(shù)據(jù)幀之前有一個數(shù)據(jù)幀出了錯),
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 基于滑動窗口技術(shù)的RFID數(shù)據(jù)清洗算法和實現(xiàn).pdf
- 個人量化方案(修訂稿)
- 超前地質(zhì)預(yù)報方案-修訂稿
- 醫(yī)療技術(shù)標(biāo)準(zhǔn)(修訂稿)
- 安邦論壇修訂稿
- 普通高中課程方案修訂稿
- 數(shù)控技術(shù)應(yīng)用專業(yè)人才培養(yǎng)方案(修訂稿)
- 我爸爸(修訂稿)
- 突發(fā)應(yīng)急預(yù)案(修訂稿)
- 護理查房修訂稿
- 某某省數(shù)字政府設(shè)計方案(修訂稿)
- 滄州職業(yè)技術(shù)學(xué)院章程(修訂稿)
- 花甲水庫庫底清理實施方案(修訂稿)
- 消防監(jiān)督檢查規(guī)定修訂稿
- 消防監(jiān)督檢查規(guī)定修訂稿
- 員工懲處管理規(guī)定修訂稿
- 花甲水庫庫底清理實施方案(修訂稿)
- 戈巷季節(jié)性施工方案修訂稿
- 花甲水庫庫底清理實施方案(修訂稿)
- 常見病知識修訂稿
評論
0/150
提交評論