基于can網(wǎng)采用滑動窗口技術(shù)傳輸故障錄波的方案實現(xiàn)(修訂稿2)

1、1基于CAN網(wǎng)采用滑動窗口技術(shù)傳輸電網(wǎng)故障信息的方案實現(xiàn)唐喜1孟巖1(北京四方繼保護(hù)自動化股份有限公司研發(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é)議中的“一問多答”、“斷點(diǎn)續(xù)傳”等先進(jìn)

2、技術(shù)應(yīng)用到CAN網(wǎng)，可使IED大量的描述信息準(zhǔn)確、快速交換，尤其是IED長時間故障錄波后，可快速上傳到分析終端進(jìn)行故障診斷，緩解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ò)化也有了新的進(jìn)展，但出于對IED實時性的特殊要求，保護(hù)軟件直接借用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、障錄波后不能及時存儲、上傳至遠(yuǎn)方，造成錄波數(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)越的特點(diǎn)，使人們樂于選擇。這些特性包括：?低成本?極高的總線利用率?很遠(yuǎn)的數(shù)據(jù)傳輸距離(長達(dá)10Km)?高速的數(shù)據(jù)傳輸速率（高達(dá)1Mbits）?可根據(jù)報文的ID決定接收或屏蔽該報文?可靠的錯誤處理和檢錯機(jī)制[6]?發(fā)送的信息遭到破壞后，可自動重發(fā)?節(jié)點(diǎn)在錯誤嚴(yán)重的情況下具有自動退出總線的功能3(1)窗口機(jī)制滑動窗口協(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ù)已達(dá)規(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ā)送方打開的窗口又已達(dá)規(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)仍不變。若從滑動窗口的觀點(diǎn)來統(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é)議要為每一個幀進(jìn)行確認(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ù)幀進(jìn)行重傳（僅因這些數(shù)據(jù)幀之前有一個數(shù)據(jù)幀出了錯），