通信協(xié)議精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的通信協(xié)議主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：通信協(xié)議范文

通信協(xié)議是指雙方實體完成通信或服務所必須遵循的規(guī)則和約定。通過通信信道和設備互連起來的多個不同地理位置的數(shù)據(jù)通信系統(tǒng)，要使其能協(xié)同工作實現(xiàn)信息交換和資源共享，它們之間必須具有共同的語言。

在計算機通信中，通信協(xié)議用于實現(xiàn)計算機與網(wǎng)絡連接之間的標準，網(wǎng)絡如果沒有統(tǒng)一的通信協(xié)議，電腦之間的信息傳遞就通信協(xié)議是指通信各方事前約定的通信規(guī)則，可以簡單地理解為各計算機之間進行相互會話所使用的共同語言。兩臺計算機在進行通信時，必須使用的通信協(xié)議。

（來源：文章屋網(wǎng) ）

第2篇：通信協(xié)議范文

【關鍵詞】CBTC系統(tǒng) 通信協(xié)議 設計 分析

前言：所謂CBTC系統(tǒng)，是指基于通信的列車運行控制系統(tǒng)（Communications Train Control），此項技術最早發(fā)源于歐洲，經(jīng)過多年的發(fā)展，CBTC系統(tǒng)已經(jīng)發(fā)展的比較完善。當前，我國在應用CBTC系統(tǒng)對列車進行控制時，應該在借鑒國外先進技術的基礎上，研發(fā)出適合我國實際情況的CBTC系統(tǒng)，同時，此種新型CBTC系統(tǒng)要以移動通信為基礎。

一、CBTC系統(tǒng)通信協(xié)議的設計

1、需求分析和設計思想。CBTC系統(tǒng)對安全性的要求非常高，因此，在進行通信協(xié)議設計之前，首先需要進行需求分析，主要從系統(tǒng)結(jié)構及安全防護措施兩個方面來進行分析，之后，再在需求分析的基礎上，結(jié)合安全傳輸規(guī)范中的方法，提出具體的設計思想。系統(tǒng)結(jié)構需求：在進行數(shù)據(jù)傳輸?shù)拇罱üぷ鲿r，以標準的TCP/IP四層協(xié)議為基礎，具體使用的為應用層定義的傳輸協(xié)議，鑒于此點要求，系統(tǒng)結(jié)構需求有三種，分別為對上層應用透明、具備安全相關的傳輸功能及訪問保護功能、通信協(xié)議的統(tǒng)一性。防護措施要求：在確定防護措施的要求時，要以影響系統(tǒng)安全的危險因素為基礎，進而根據(jù)EN50159-2標準來進行合理的設計。

2、通信協(xié)議架構設計。在進行CBTC系統(tǒng)的通信協(xié)議設計時，需要具備三大功能，一是具有獨立性，二是對上層應用透明，三是保證雙冗余總線發(fā)送。基于通信協(xié)議功能上的要求，架構設計也應該包含三個層次：第一層次，安全時間層，主要的功能是在進行數(shù)據(jù)傳輸時，加蓋時間戳，同時，在完成數(shù)據(jù)接收之后，將數(shù)據(jù)所帶有的時間戳解析出來，通過對比分析，將信息的正確性與實效性予以確定；第二層次，安全鏈接層，主要功能就是對鏈接進行管理，從而使鏈接處于良好的狀態(tài)當中；第三層次，冗余管理層，安全數(shù)據(jù)處理完成之后，安全鏈接層會對其進行打包，而冗余管理層就是對打包之后的數(shù)據(jù)進行加密，并在兩條總線上發(fā)送，同時接受發(fā)來的報文，進行解密之后傳送給上層。

二、CBTC系統(tǒng)通信協(xié)議的形式化分析

1、系統(tǒng)模型的分解和驗證。對于設計完成的CBTC系統(tǒng)通信協(xié)議來說，有三項指標需要進行考察和驗證，這三項指標分別為鏈接建立時間、信息傳輸延時范圍、信道性能對鏈路狀態(tài)的影響。在實際的考察和驗證中，鏈接建立過程與實際數(shù)據(jù)傳輸過程分別進行驗證，在對鏈接建立過程中進行驗證時，主要是對建立時間進行考察，而對實際數(shù)據(jù)傳輸過程中進行驗證時，主要是對剩余性能指標進行考察，進而通過分解模型，將狀態(tài)空間科學的分析，使模型的動態(tài)特性得到合理的驗證。

2、危險分析。CBTC系統(tǒng)在運行的過程中，存在著很多影響安全的危險因素，而危險分析就是對危險因素進行明確，并確定是否采取有效地防護措施。一般來說，在CBTC系統(tǒng)中，存在的危險因素主要有三種：第一，信道的丟包率，在利用信道進行數(shù)據(jù)傳輸?shù)倪^程中，信息丟失的可能性非常大，因而，信道的丟包率是一項非常主要的危險因素，在對其進行分析時，分析的方法為隨機數(shù)模擬，從而將丟包概率值予以改變，最終得出合理的接受范圍；第二，信道的傳輸延遲，通過分析，將延遲的最大范圍進行明確；第三，入侵者的惡意數(shù)據(jù)，一旦此種危險因素的危險發(fā)生，那么CBTC系統(tǒng)就會出現(xiàn)錯誤，因此，必須要對其采取相應的防護措施。

3、系統(tǒng)的仿真及結(jié)果分析。經(jīng)過前兩個步驟，可以分析相關的性能參數(shù)并得出結(jié)果。在進行系統(tǒng)仿真的過程中，首選需要對鏈接建立時間進行仿真，進而對其性能進行科學的評價，仿真實驗時，建鏈操作為300次，通過對每次操作時間的考察，進行有效地分析，并得出結(jié)果。接著進行信息傳輸延時范圍仿真，采取的是建立模型的方法，同樣實驗次數(shù)為300次，通過取平均值的方式將變化規(guī)律確定。第三是對信道性能對鏈路狀態(tài)的影響進行仿真，以此來分析狀態(tài)的好與壞。通過各項系統(tǒng)仿真的結(jié)果，對其進行全面的分析后可知，CBTC系統(tǒng)的通信協(xié)議具備非常優(yōu)異的性能，而且安全系數(shù)也提高了許多，因此，此次CBTC系統(tǒng)的通信協(xié)議設計的安全性非常高，能夠滿足CBTC系統(tǒng)對安全性的需求，從而保證列車運行控制的有效性。

第3篇：通信協(xié)議范文

關鍵詞：TCP/IP協(xié)議；Internet；網(wǎng)絡通信

1 前言

TCP/IP初步架構的出現(xiàn)源于1964年，冷戰(zhàn)時期美國國防部高級研究計劃局DARPA提出ARPANET研究計劃，目的是希望美國國防部的很多主機、通信控制處理機和通信線路在戰(zhàn)爭中，如部分遭到攻擊而損壞時，其它部分還能正常工作，同時它希望適應從文件傳送到實時數(shù)據(jù)傳輸?shù)母鞣N應用需求，因此它要求的是一種靈活的網(wǎng)絡體系結(jié)構，實現(xiàn)異型網(wǎng)的互聯(lián)(Interconection)與互通(Intercomunication)。

最初ARPANET使用的是租用線路。當衛(wèi)星通信系統(tǒng)與通信網(wǎng)發(fā)展起來之后，ARPANET最初開發(fā)的網(wǎng)絡協(xié)議NCP (Net Control Protocol，網(wǎng)絡控制協(xié)議)因其在通信可靠性較差的通信子網(wǎng)中出現(xiàn)了不少問題，導致了新的網(wǎng)絡協(xié)議TCP/IP的出現(xiàn)。雖然TCP協(xié)議和IP協(xié)議都不是OSI標準，但它們是目前最流行的商業(yè)化的協(xié)議，并被公認為當前的工業(yè)標準或“事實上的標準”。1974年，Kahn最早定義出了的TCP/IP參考模型(TCP/IP Reference Model ); 1985年由Leiner等人對該模型做了進一步的研究；1988年Clark對該模型的設計思想進行了討論。

今天，Internet己經(jīng)發(fā)展得更加商業(yè)化，更加面向消費者，盡管基本目的發(fā)生了改變，但其最初的質(zhì)量標準(也就是開放式、抗毀性和可靠性)依然是必需的。這些特性包括可靠傳輸數(shù)據(jù)、自動檢測、避免網(wǎng)絡發(fā)生錯誤等。更重要的就是TCP/IP是一個開放式的通信協(xié)議，開放性就意味著在任何組合間，不管這些設備的物理特征有多大差異，都可以進行通信。

2 標準TCP/IP協(xié)議

如同OSI參考模型一樣，TCP/IP也是一種分層模型。與OSI參考模型不同的是，TCP/IP參考模型更側(cè)重于互聯(lián)設備間的數(shù)據(jù)傳送，而不是嚴格的功能層次劃分。TCP/IP通過解釋功能層次分布的重要性來做到這一點，但它仍為設計者具體實現(xiàn)協(xié)議留下很大的余地。因此，OSI參考模型適用于解釋互聯(lián)網(wǎng)絡的通信機制，而TCP/IP更適合做互聯(lián)網(wǎng)絡協(xié)議的市場標準。

TCP/IP協(xié)議是一套把因特網(wǎng)上的各種系統(tǒng)互聯(lián)起來的協(xié)議組，可以保證因特網(wǎng)上數(shù)據(jù)準確又快速地傳輸。TCP/IP協(xié)議是一個很大的協(xié)議族，通常表示為一個簡化的四層模型。這四層分別是應用層、傳輸層、網(wǎng)絡層和鏈路層。其中一些常用協(xié)議在TCP/IP分層模型中所處的位置如圖1所示。

圖1TCP/IP層次結(jié)構圖

3IP協(xié)議的實現(xiàn)

3.1 IP數(shù)據(jù)報格式

IP ( Internet Protocol，互聯(lián)網(wǎng)協(xié)議)是TCP/IP協(xié)議中一個最重要的協(xié)議。IP數(shù)據(jù)報以32比特為一個計數(shù)單位(組)，其格式如圖2所示。

圖21P數(shù)據(jù)報格式

3.2IP協(xié)議的軟件實現(xiàn)

IP是TCP/IP協(xié)議中最為核心的協(xié)議。所有的數(shù)據(jù)都以IP數(shù)據(jù)報格式傳輸。IP協(xié)議可以實現(xiàn)無連接數(shù)據(jù)報傳送、數(shù)據(jù)報路由選擇和差錯控制的功能。在本課題中，由于單片機資源有限，結(jié)合實際需要只實現(xiàn)了IP數(shù)據(jù)報傳送和接收，沒有實現(xiàn)路由選擇算法和差錯控制，同時也不支持IP數(shù)據(jù)報的分片和重組。

IP協(xié)議主要通過IP接收函數(shù)和IP發(fā)送函數(shù)兩個函數(shù)實現(xiàn)。

①IP發(fā)送函數(shù)

void ip_send對來自上層的數(shù)據(jù)，按照IP數(shù)據(jù)報的結(jié)構構造數(shù)據(jù)報。通過調(diào)用ARP處理程序解析對應IP的物理地址。若返回NULL值，則將數(shù)據(jù)存入一個已定義的結(jié)構體WAITE中，并發(fā)送ARP請求。若返回對應IP的物理地址，則將數(shù)據(jù)交給底層以太網(wǎng)驅(qū)動程序處理。

②IP接收函數(shù)

void ip rcve (UCHAR xdata*inbuf)單片機收到數(shù)據(jù)包之后，應先對數(shù)據(jù)包的類型進行判斷。如果是IP數(shù)據(jù)報，則調(diào)用該程序。接著再判斷其數(shù)據(jù)域中所使用的協(xié)議類型，是ICMP協(xié)議調(diào)用ICMP處理子程序，是UDP協(xié)議調(diào)用UDP處理子程序，是TCP協(xié)議調(diào)用TCP處理子程序，其它返回。程序流程圖如圖3所示：

圖3IP接收過程流程圖

3.3 校驗和算法

在大多數(shù)TCP/IP協(xié)議中采用的差錯檢驗方法是校驗和，校驗和是在分組上附加的信息。校驗和能夠防止分組在傳輸時所受到的損傷。在發(fā)送端先計算檢驗和并將得到的結(jié)果與分組一起發(fā)送過去。接收端對包括校驗和的整個分組重復進行同樣的計算。若得到的結(jié)果正確則接收此分組，否則就將其丟棄。發(fā)送端和接收端的校驗和計算方法分別如下:

①發(fā)送端按以下步驟產(chǎn)生校驗和

②接收端按以下步驟產(chǎn)生校驗和

下面給出校驗和算法的源程序：

UINT Checksum (UCHAR xdata *checks UINT length)//計算校驗和

{LONG sum=0; UINT i:UINT xdata *ptr: ptr=(UINT xdata *)check;

for (i=0:i

{sum+=*ptr++;}

if (length&0x01)//表示長度為單數(shù)

{sum=sum+((*ptr)&Oxff00);}

sum=(sum&Oxffff)+((sum;16)&Oxffff);//高16位和低16位相加

if(sum&OxffffU000){sum++;}//表示有進位

return((UINT)((sum)&Oxf});}

4TCP協(xié)議的實現(xiàn)

4.1 TCP數(shù)據(jù)報格式

TCP（Transfer Control Protocol，傳輸控制協(xié)議)是傳輸層最常用的協(xié)議，是一個比較復雜的協(xié)議。TCP和IP一樣，也是TCP/IP協(xié)議族中最重要的協(xié)議。它可以提供面向連接的、可靠的數(shù)據(jù)傳輸服務。TCP數(shù)據(jù)報文段格式如圖4所示：

圖4TCP報文段的格式

4.2 TCP協(xié)議的實現(xiàn)

TCP協(xié)議的實現(xiàn)是整個TCP/IP協(xié)議棧中最復雜的一個。TCP協(xié)議是面向連接的、端對端的可靠通信協(xié)議。TCP采取了很多機制來保證它的可靠性，比如TCP連接的建立與關閉機制、超時重傳機制、數(shù)據(jù)包確認機制、流量控制機制等等。在嵌入式系統(tǒng)中實現(xiàn)TCP協(xié)議所要做的就是實現(xiàn)這些機制，當然要在不影響協(xié)議棧功能的前提下適當做一下簡化。

4.3TCP的超時重傳與流量控制機制的實現(xiàn)

當一個TCP連接順利建立起來后，TCP連接的雙方可以互相傳遞數(shù)據(jù)了。TCP的可靠傳輸是靠確認機制來實現(xiàn)的，也就是每發(fā)送一個數(shù)據(jù)包后，只有接收到對方發(fā)送確認包后，才能確定該數(shù)據(jù)包已經(jīng)成功發(fā)送，否則就要重發(fā)。

TCP的流量控制是為了協(xié)調(diào)通信雙方的收發(fā)速率不均衡而設計的。遠端的客戶機一般是通用計算機，相對與本地的嵌入式Web Server來說運行速度要快得多。因此，當遠端快的發(fā)送方向本地慢的接收方發(fā)送數(shù)據(jù)的時候，如果發(fā)送速度很快，則會導致本端來不及處理，甚至導致死機。TCP連接建立時，雙方會利用TCP首部中的Window窗口字段通報雙方的可用窗口。實際上，接收方通報的窗口大小是根據(jù)其接收緩存的大小而定，考慮到本系統(tǒng)在使用TCP協(xié)議時，只設置了一個中等IP包大小接收緩存，因此接收窗口設為1024。同時，每次接收包的ACK確認時，窗口大小不再動態(tài)改變，恒定設置為1024。這樣遠端主機就會以較慢的傳輸速率與本端的Web Server進行通信。

5 結(jié)論

本文主要針對目前流行的TCP/IP網(wǎng)絡通信協(xié)議的實現(xiàn)進行研究和探索，由于時間倉促，加上本人對該領域的研究才剛剛起步，所以還存在一些問題值得進一步研究探討，主要有:

(1) 對于TCP/IP協(xié)議，時間的控制非常重要。包括TCP的超時重傳，TCP狀態(tài)的保活等。如果時間處理不當，將影響整個系統(tǒng)的通訊性能。

(2)如何進一步實現(xiàn)TCP/IP對于多點通信以及完整協(xié)議棧的實現(xiàn)還有待于進一步研究。

(3) IPv6作為下一代互聯(lián)網(wǎng)的核心協(xié)議，能夠提供幾乎無限的地址空間，從根本上克服了IPv4中地址空間不足的問題。因此，下一步可增加對IPv6協(xié)議的研究與實現(xiàn)。

參考文獻

[1] 胡海.嵌入式TCP/IP協(xié)議棧研究與實現(xiàn)[D].西南交通大學,2005.8.

[2] 袁曉莉,徐愛均.基于OS-II和TCP/IP的遠程溫度監(jiān)測系統(tǒng).2005.5.

[3] 吳艷光.嵌入式TCP/IP協(xié)議棧設計方法的研究 [D].太原理工大學,2004.

[4] 馬永力. 基于SX52BD的嵌入式Web服務器的設計與實現(xiàn).山東大學,2005.

[5]路英娟.TCP/IP協(xié)議小議[J].科技情報開發(fā)與經(jīng)濟,2004(6).

[6]葛志輝,李陶深.TCP/IP協(xié)議的脆弱性與相應的對策.2004.

---------

第4篇：通信協(xié)議范文

作者簡介:周青山（1987-）,男，重慶忠縣人，碩士研究生，主要研究方向：嵌入式操作系統(tǒng)、工業(yè)CT數(shù)據(jù)傳輸； 王玨（1961-），男，四川仁壽人，教授，博士生導師，主要研究方向：工業(yè)CT、檢測技術、自動化裝置; 譚輝（1983-），男，湖南耒陽人，助理研究員，碩士，主要研究方向：數(shù)據(jù)采集與傳輸、嵌入式操作系統(tǒng)。

文章編號:1001-9081（2011）08-02065-03doi:10.3724/SP.J.1087.2011.02065

（1.重慶大學 自動化學院，重慶400030; 2.重慶大學 ICT研究中心，重慶400030）

（）

摘 要:為了在強干擾環(huán)境下進行數(shù)據(jù)的準確傳輸，設計了一種基于曼徹斯特碼的通信協(xié)議。協(xié)議分為發(fā)送模塊和接收模塊：在發(fā)送端，采用了數(shù)據(jù)打包傳輸；在接收端，采用了“錯位碼+計數(shù)器”的方法進行時鐘同步。協(xié)議能有效解決數(shù)據(jù)邊界識別問題和時鐘累積誤差造成的相位偏差問題。利用設計和制作的硬件實驗平臺，在模擬的干擾環(huán)境中，進行了40Mbps數(shù)據(jù)的傳輸測試。結(jié)果表明，該通信協(xié)議能夠進行數(shù)據(jù)的準確傳輸。

關鍵詞:曼徹斯特碼；通信協(xié)議；錯位碼；時鐘；相位偏差

中圖分類號: TN915.04文獻標志碼:A

Design and realization of communication protocol based on Manchester code

ZHOU Qing-shan1, WANG Jue1,2, TAN Hui2

（1. College of Automation, Chongqing University, Chongqing 400030, China;

2. ICT Research Center, Chongqing University, Chongqing 400030, China）

Abstract: To transmit data accurately in strong interference environments, a communication protocol based on Manchester code was designed. It is composed of sending module and receiving module: data were transferred in the form of “packets” at the sending end; dislocated code and a counter were used to solve the problem of clock synchronization at the receiving end. The communication protocol could solve the issue of identifying the data boundaries and the phase error caused by the accumulated error of clock. In a simulated interference environment, a transfer rate of 40Mbps was achieved on a platform. The experimental results indicate that the communication protocol is able to transmit data accurately.

Key words: Manchester code; communication protocol; dislocated code; clock; phase error

0 引言

在工業(yè)領域中，強干擾場所的數(shù)據(jù)傳輸逐漸普遍，對數(shù)據(jù)傳輸可靠性的要求也愈來愈高。目前，為了獲得在強干擾環(huán)境下數(shù)據(jù)的可靠傳輸，除了采用抗干擾能力強的差分電平外，還會通過降低數(shù)據(jù)傳輸速率、增大協(xié)議和硬件復雜度等方法來進一步保證其可靠性，從而導致在數(shù)據(jù)傳輸速率、傳輸可靠性、運行和維護成本間形成了一個矛盾體，難以獲得一個折中方案［1-3］。為了獲得簡單協(xié)議下強干擾環(huán)境中數(shù)據(jù)的可靠傳輸，降低強干擾環(huán)境中數(shù)據(jù)傳輸?shù)倪\行和維護成本，本文設計了一種基于曼徹斯特碼（Manchester Code）的通信協(xié)議，并設計和制作了基于現(xiàn)場可編程門列陣（Field Programmable Gate Array, FPGA）的實驗平臺對其進行測試。

曼徹斯特碼，又稱數(shù)字雙相碼,是一種時鐘自同步的編碼技術。與其他編碼技術相比，曼徹斯特碼不存在直流分量,能夠從接收端的線路碼中提取符號同步信號，并且編碼規(guī)則相對簡單，抗干擾能力強，適合在一些干擾較大的場所進行數(shù)據(jù)傳輸［4-5］。

如圖1，對于單極性不歸零碼（Unipolar Non Return to Zero, NRZ）的數(shù)據(jù)信號“0”和“1”，將“0”編碼為“01”，將“1”編碼為“10”的這種形式的編碼稱之為曼徹斯特I型碼［6］；反之，稱為曼徹斯特II型碼。本文采用曼徹斯特I型碼進行設計，在后面提到的曼徹斯特編碼均為I型碼。

圖1 曼徹斯特碼

1 協(xié)議設計

通信協(xié)議分為兩部分：發(fā)送模塊和接收模塊。

1.1 發(fā)送模塊

如圖2所示，前方傳輸過來的數(shù)據(jù)存入先進先出（First Input First Output, FIFO）存儲器中進行緩存，在數(shù)據(jù)打包控制器的控制下，將NRZ數(shù)據(jù)轉(zhuǎn)換為曼徹斯特碼后打包輸出。

圖2 發(fā)送模塊結(jié)構

1.1.1 編碼方式選擇

直接將輸入數(shù)據(jù)與時鐘進行同或（或者異或）是比較常用的曼徹斯特編碼方式［7］，此處采用同或編碼方式。如果NRZ的一位碼元時間為1/P，則選用頻率為2P的時鐘對NRZ進行同或處理，所得的編碼即為曼徹斯特碼，如圖3所示。

圖3 曼徹斯特碼同或編碼

1.1.2 數(shù)據(jù)打包傳輸

發(fā)送端的協(xié)議設計，需要充分考慮到接收端的特性。對于接收端，在連續(xù)的曼徹斯特碼流中，首先需要確定每位原始數(shù)據(jù)所對應的兩位編碼數(shù)據(jù)，即數(shù)據(jù)邊界的確定。例如，接收端接收的是連續(xù)的“10”序列，同時也可以判斷為是連續(xù)的“01”序列，需要進行數(shù)據(jù)邊界確定。因此，在發(fā)送端，采用了數(shù)據(jù)幀的傳輸方式，為每幀數(shù)據(jù)添加同步字頭用以進行數(shù)據(jù)邊界的正確識別，此處設定的每幀有效數(shù)據(jù)為256b。

正確的曼徹斯特碼不會存在連續(xù)的3個或以上的“1”或者“0”，所以將數(shù)據(jù)的同步字頭設定為“111000”；將命令字的同步字頭設定為“000111”，如表1所示。

第5篇：通信協(xié)議范文

【關鍵詞】網(wǎng)絡通信協(xié)議；電氣監(jiān)控系統(tǒng)；概況；應用；IEC60870—5—103協(xié)議；實時性；可靠性

隨著社會主義市場經(jīng)濟的快速發(fā)展與科學技術的不斷進步，作為各產(chǎn)業(yè)平穩(wěn)生產(chǎn)的基礎，電氣設備必須具備良好的安全性、穩(wěn)定性及高效性。在電氣監(jiān)控系統(tǒng)內(nèi)優(yōu)化應用網(wǎng)絡通信協(xié)議，可對電氣監(jiān)控系統(tǒng)的性能進行有效提高。作為通信網(wǎng)絡的根本規(guī)則，網(wǎng)絡通信協(xié)議的各種類型都存有既定通信模式。網(wǎng)絡通信協(xié)議不同則其傳輸訪問機制也存有極大的不同。在進行少數(shù)信號傳輸或大量信號傳輸與發(fā)出時，此類傳輸訪問機制性能都存有極大不同。本文以網(wǎng)絡通信協(xié)議為依據(jù)，對電力監(jiān)控系統(tǒng)內(nèi)最常用的通信協(xié)議進行了優(yōu)化運用，如IEC60870—5—103等，在設備投資金額不增加的基礎上，達到完善電氣監(jiān)控系統(tǒng)的目的。

一、電氣監(jiān)控系統(tǒng)網(wǎng)絡通信協(xié)議的概況

作為一種網(wǎng)絡通用語言，網(wǎng)絡通信協(xié)議是指為連接不同操作系統(tǒng)和不同硬件體系結(jié)構的互聯(lián)網(wǎng)絡引提供的通信支持。其從邏輯上將網(wǎng)絡進行7層劃分，各層都具備路由器、交換機等相應的物理設備。在電氣監(jiān)控系統(tǒng)內(nèi)IEC60870—5—103、IEC60870—5—104等為主要的網(wǎng)絡通信協(xié)議類型，具體如下：

1、IEC60870—5—103協(xié)議。

作為國際電工委員會制定的繼電保護設備信息接口規(guī)范，IEC60870—5—103協(xié)議可在通信前置機和繼電保護裝置間的信號傳輸中充分應用。該協(xié)議主要選取主從—對多的非平衡傳輸方式，主站為通信前置機，從站為繼電保護裝置，每秒9600bit為標準傳輸速率，格式報文形式主要分為2種：固定幀長報文、可變幀長報文。其表述的2類信息傳輸方式為按照相應規(guī)定運用的服務數(shù)據(jù)單位與為標準化報文傳輸沒有涵蓋的全部可能應用過程，或全部可能信息利用通用分類服務傳輸。

2、IEC60870—5—104協(xié)議。

在IEC60870—5—103基礎上，國際電工委員會為滿足網(wǎng)絡運輸又進行了IEC60870—5—104遠動通信協(xié)議的制定。其不僅能夠在集控中心與變電站、調(diào)度端進行全面運用，還能在變電站內(nèi)的通信網(wǎng)加以合理運用。一般選取RFC2200協(xié)議作為該協(xié)議物理層、鏈路層等主要協(xié)議。作為標準TCP/IP協(xié)議子集，RFC2200可使IEC60870—5—104協(xié)議應用于TCP/IP協(xié)議的高帶寬網(wǎng)絡傳輸。與其他協(xié)議相比，IEC60870—5—104協(xié)議具有良好實時性、可靠性等優(yōu)勢，且能夠進行大流量數(shù)據(jù)傳輸，為信息擴展提供便利。

二、網(wǎng)絡通信協(xié)議在電氣監(jiān)控系統(tǒng)中的應用

在科技快速發(fā)展的今天，電氣監(jiān)控系統(tǒng)愈加完善，將網(wǎng)絡通信協(xié)議合理應用于電氣監(jiān)控系統(tǒng)，對提升電氣監(jiān)控系統(tǒng)實時性、可靠性具有至關重要的作用，為此，本文以優(yōu)化其應用性能為例對網(wǎng)絡通信協(xié)議在電氣監(jiān)控系統(tǒng)中的應用進行了分析與探究。

1、實時性優(yōu)化應用

電氣監(jiān)控系統(tǒng)實時性提升的方式較多，一般分為2大類：升級電氣監(jiān)控系統(tǒng)硬件、優(yōu)化軟件算法。根據(jù)工作需求，可通過軟件優(yōu)化網(wǎng)絡通信協(xié)議，以此達到提高電氣監(jiān)控系統(tǒng)實時性的目的。首先，IEC60870—5—103協(xié)議為例分析。光纖接口、EIARS485接口為IEC60870—5—103協(xié)議電氣的主要接口類型。光纖傳輸具有良好抗干擾能力及較快傳輸速度。在相同變電站或距離較短情況下繼電保護裝置和監(jiān)控系統(tǒng)的兩種接口傳輸速度基本一致。在通信鏈路拓撲方面兩種接口一致，基于此，兩種接口具有相同分析方式。本文將EIARS485接口作為分析研究重點，具體內(nèi)容如下：作為三線制半雙工接口，EIARS485接口在同一時間點上只能接收、發(fā)送信號，但不能同時進行接收、發(fā)送操作。通信權可由EIARS485總線上并聯(lián)的3個繼電保護裝置依次取得，依次將數(shù)據(jù)傳送給通信前置機。繼電保護裝置數(shù)據(jù)向通信前置機傳送的快慢，由通信權時間間隔的長短加以確定。但電氣出現(xiàn)大面積故障的情況下，繼電保護裝置極易出現(xiàn)大量變位信號。如一個繼電保護裝置進行5個遙信信號上傳，完成此5個變位遙信信號傳輸需20幀以上報文。其次，IEC60870—5—104協(xié)議為例分析。以太網(wǎng)傳輸為IEC60870—5—104協(xié)議的主要形式，平衡傳輸全雙工接口為以太網(wǎng)RJ45接口類型。對該協(xié)議實時性造成影響的主要因素包含2點，第一以太網(wǎng)的傳輸性能，對其起決定作用的因素為網(wǎng)絡拓撲結(jié)構及以太網(wǎng)帶寬；第二，該協(xié)議報文信號攜帶效率。根據(jù)筆者工作性質(zhì)，為提升電氣監(jiān)控系統(tǒng)網(wǎng)絡通信協(xié)議性能，本文以優(yōu)化提升IEC60870—5—104協(xié)議報文信號攜帶效率為主進行分析。本協(xié)議傳輸數(shù)據(jù)以I格式幀為主。該協(xié)議規(guī)定ASDU（一個）在249字節(jié)以下，可進行一個火一組信號傳輸。應用于現(xiàn)有監(jiān)控系統(tǒng)的IEC60870—5—104協(xié)議，I格式幀（一個）旺旺只進行一個變位遙信信號傳輸。為提高信號傳輸信號，需對I格式幀長度進行有效增加。

2、可靠性優(yōu)化應用

利用通信前置機、數(shù)據(jù)服務器、遠動機等設備的冗余配置及通信網(wǎng)絡冗余配置可實現(xiàn)電氣監(jiān)控系統(tǒng)可靠性。在具體應用中，硬件即便冗余配置，但卻存在冗余設備無擾無縫切換等問題。為達到網(wǎng)絡通信協(xié)議優(yōu)化運用，需提升通信前置機冗余切換、通信網(wǎng)絡冗余切換的可靠性，進而達到電氣監(jiān)控系統(tǒng)可靠性提升的目的。

（1）將EIARS485接口應用于IEC60870—5—103協(xié)議時，EIARS485接口一個的情況下主機只能有一臺，也就是說EIARS485接口一個情況下2臺通信前置機無法利用該接口將報文發(fā)送給一臺繼電保護裝置。為對該協(xié)議傳輸可靠性進行有效提升，需并接2臺通信前置機的全部EIARS485接口。要求位于工作狀態(tài)的通信前置機為1臺，位于熱備狀態(tài)的通信前置機為1臺。如工作狀態(tài)前置機內(nèi)隨意一個EIARS485接口通信中斷被熱備狀態(tài)通信前置機檢測出來后，熱備狀態(tài)前置機可將此EIARS485接口主機地位占據(jù)，利用此EIARS485接口將報文發(fā)送給繼電保護裝置。該情況下，工作狀態(tài)通信前置機需將此EIARS485接口主機地位拋棄，進而達到IEC60870—5—103協(xié)議雙機熱備接口切換。

（2）通信前置機、數(shù)據(jù)服務器、遠動機與以太網(wǎng)冗余配置為現(xiàn)有監(jiān)控系統(tǒng)的主要構成部分。冗余配置可對信號傳輸可靠性有效提升。但現(xiàn)階段最常見的雙機雙網(wǎng)切換機制為“硬切換”，也就是說一般情況下冗余的2臺通信前置機內(nèi)利用冗余通信網(wǎng)絡內(nèi)一條與運動機或服務器進行通信的只有一臺。如前置機正常運行時如出現(xiàn)故障或通信網(wǎng)絡中斷，可向冗余的另一臺通信前置機進行通信切換。但其存有諸多問題，如只能利用通信前置機內(nèi)部軟件對通信前置機切換、通信網(wǎng)絡切換進行判斷，通信在切換過程中為中斷情況，不能實現(xiàn)無擾連續(xù)切換。在IEC60870—5—104協(xié)議內(nèi)對冗余通信網(wǎng)絡傳輸數(shù)據(jù)如何應用沒有進行詳細規(guī)定。如選取并行冗余協(xié)議，可將鏈路冗余體增設到各設備內(nèi)部，以此實施冗余網(wǎng)絡通信數(shù)據(jù)處理。但該功能在傳統(tǒng)變電站監(jiān)控系統(tǒng)設備內(nèi)并不具備，如選取該并行冗余協(xié)議，需進行現(xiàn)有監(jiān)控系統(tǒng)設備重新設計。在對現(xiàn)有設備不改動的情況下，應適當修改現(xiàn)有協(xié)議通信方式，進而達到冗余網(wǎng)絡并行數(shù)據(jù)傳輸?shù)哪康摹?/p>

三、結(jié)束語

綜上所述，作為國民經(jīng)濟的主要構成部分，電氣監(jiān)控系統(tǒng)內(nèi)網(wǎng)絡通信協(xié)議的合理運用，可有效管理與控制質(zhì)量、安全工作，完善電氣監(jiān)控系統(tǒng)。本文以IEC60870—5—103協(xié)議與IEC60870—5—104協(xié)議為例，對其在電氣監(jiān)控系統(tǒng)內(nèi)的實時性優(yōu)化應用、可靠性優(yōu)化應用進行了進一步分析研究，以此提升電氣監(jiān)控系統(tǒng)的性能，降低經(jīng)濟損失，及提高系統(tǒng)安全性。

參考文獻

[1]丁騰波,林亞男,趙萌.智能變電站虛擬局域網(wǎng)邏輯結(jié)構劃分方案的研究[J].電力系統(tǒng)保護與控制,2012(01)

[2]葛江波.IEC60870-5-104傳輸規(guī)約如何實現(xiàn)遠動技術網(wǎng)絡化[J].太原大學學報,2010(02)

[3]竇曉波,胡敏強,吳在軍,杜炎森,閔濤.數(shù)字化變電站通信網(wǎng)絡的組建與冗余方案[J].電力自動化設備.2008(01)

[4]李勁草.網(wǎng)絡通信協(xié)議在電氣監(jiān)控系統(tǒng)中的優(yōu)化應用[J].包裝世界,2012(06)

[5]張小美,鄭毓蕃,許建強,陸國平.存在時延和數(shù)據(jù)丟失的網(wǎng)絡控制系統(tǒng)的控制器設計[J].信息與控制,2006(03)

[6]王培增,董世軍.IEC60870-5-103傳輸規(guī)約在微機保護測控裝置中的應用與實現(xiàn)[J].繼電器,2007(05)

[7]周森,鄭玉平,劉晗,張毅,紀南,侯國俊,陸詠.IEC60870-5-103規(guī)約在微機型繼電保護測試系統(tǒng)中的應用[J].繼電器,2005(23)

第6篇：通信協(xié)議范文

 

0引言

 

近幾年來，隨著人們對于網(wǎng)絡信息傳輸質(zhì)量的要求越來越高，并且各種應用的增加導致整個網(wǎng)絡信息量增大，亟需有效提高網(wǎng)絡的服務質(zhì)量。基于量子糾纏態(tài)理論，在數(shù)據(jù)鏈路層對通信協(xié)議進行分析，得到停等協(xié)議和選擇重傳量子通信協(xié)議，可以明顯減少信息在鏈路中的傳輸時延，有效提高信息在鏈路中的傳輸速率[12]。但是，選擇自動重傳協(xié)議對于每一個發(fā)送的數(shù)據(jù)幀都要求進行應答，一定程度上加重了通信負擔;滑動窗口協(xié)議只要求對于一定量的數(shù)據(jù)幀發(fā)送一個應答即可，將有效簡化通信過程。因此，研究基于量子糾纏態(tài)的滑動窗口通信協(xié)議具有一定的意義。本文利用量子理論中量子糾纏態(tài)，提出一種基于數(shù)據(jù)鏈路層的滑動窗口量子通信協(xié)議，并對該協(xié)議進行分析。

 

1量子糾纏態(tài)

 

量子信息學是近20多年來由量子理論、信息科學以及計算機科學相結(jié)合起來的新型學科[3]，主要利用量子態(tài)的特性，探索以全新的方式對信息進行存儲、計算、編碼和傳輸?shù)目赡苄訹45]。量子糾纏態(tài)是量子光學和量子信息學領域中的一個重要概念，量子態(tài)的糾纏是量子信息工程中的重要資源，并廣泛應用于量子通信和量子計算的理論研究中[67]。量子糾纏現(xiàn)象最先是由(einsteinpodolskyrosen，EPR)發(fā)現(xiàn)的量子力學的特殊現(xiàn)象，對于2個或多個量子系統(tǒng)之間的非定域、非經(jīng)典的關聯(lián)性描述，是量子系統(tǒng)內(nèi)各個子系統(tǒng)或各自由度之間關聯(lián)的力學屬性。那么，量子糾纏態(tài)是實現(xiàn)信息高速傳輸?shù)牟豢善谱g通信的理論基礎[4]。由量子糾纏交換實現(xiàn)量子遠程通信，表明量子狀態(tài)的轉(zhuǎn)移是瞬間實現(xiàn)的，極大縮短了通信時間。

 

2滑動窗口通信協(xié)議

 

滑動窗口協(xié)議是基于數(shù)據(jù)鏈路層允許多個數(shù)據(jù)幀同時進行信息傳輸以此來提高傳輸效率而提出的[8]。對于每一個數(shù)據(jù)幀用一定位數(shù)的二進制標識，并限定每個窗口的最大傳輸?shù)臄?shù)據(jù)幀數(shù)。同時，分別在發(fā)送方設置發(fā)送窗口，接收方設置相應的接收窗口;接收方不必對每一個數(shù)據(jù)幀進行應答，只需對這個窗口的最后一個數(shù)據(jù)幀進行應答，表示整個窗口的所有數(shù)據(jù)幀接收正確，之后接收下一個窗口的數(shù)據(jù)。對于當產(chǎn)生錯誤或者丟失一個、多個數(shù)據(jù)幀時，需要重傳這個窗口的所有數(shù)據(jù)幀。

 

對于滑動窗口協(xié)議，假如待傳送的數(shù)據(jù)幀為m個，每個滑動窗口最多N個數(shù)據(jù)幀，且每個數(shù)據(jù)幀在傳輸?shù)倪^程中出錯和丟失的概率為p。假定每個數(shù)據(jù)幀的發(fā)送時延為ta，數(shù)據(jù)幀沿發(fā)送鏈路從發(fā)送端到接收端的傳輸時延為tp，接收端接收到數(shù)據(jù)幀的所用的處理時延為tpr，接收端發(fā)送確認幀的發(fā)送時延為 tb，確認幀在鏈路中的傳輸時延為tp，假設發(fā)送端的處理時延也同為tpr。由于數(shù)據(jù)幀的傳輸過程中是連續(xù)發(fā)送，則存在數(shù)據(jù)幀之間傳輸時間的重疊。即設時間重疊的系數(shù)為β，則0≤β<1，重疊時間為βt，當β=0時，重疊時間為0，即只一個數(shù)據(jù)幀進行傳輸;同時數(shù)據(jù)幀的發(fā)送時間有先后順序，不可能同時發(fā)送所有數(shù)據(jù)幀，那么數(shù)據(jù)幀之間的發(fā)送時間不能完全重疊，β不能等于1。因此，一個數(shù)據(jù)幀從發(fā)送端到接收端的傳輸時間為

 

也就是說，如果出錯或丟失的數(shù)據(jù)幀越多，則滑動窗口量子通信協(xié)議將越有效;并且在無差錯信息傳輸中滑動窗口量子通信協(xié)議也將比選擇連續(xù)重傳量子通信協(xié)議更好。可得出：在單一一個窗口的出錯或丟失需要重傳的數(shù)據(jù)幀的概率為p1=y/x，那么對于所有的數(shù)據(jù)幀有：當p1> c+1xt4+t5(t4+t5)x-1時，滑動窗口量子通信協(xié)議比選擇連續(xù)重傳量子通信協(xié)議更優(yōu)。因此，滑動窗口量子通信協(xié)議在遠程通信和通信信道較差、出錯率很高以及傳輸時延很高的情況下具有更明顯的優(yōu)勢。

 

3結(jié)論

 

利用量子力學中的量子糾纏態(tài)，提出了一種基于數(shù)據(jù)鏈路層的滑動窗口量子通信協(xié)議。該協(xié)議在鏈路的空閑時段通過量子糾纏態(tài)的分發(fā)建立量子信道，信息的發(fā)送通過經(jīng)典信道進行傳輸，而后通過量子信道進行反饋確認信息來完成。由于確認量子信息傳輸?shù)乃矔r性，可有效減少信息的傳輸時間，提高了鏈路的吞吐量。通過與選擇連續(xù)重傳量子通信協(xié)議對比，滑動窗口量子通信協(xié)議在十分嚴峻的環(huán)境和遠程通信中能夠更好地提高信息的傳輸效率，特別是在衛(wèi)星通信方面將有更大作用。但是對于所需要重傳的數(shù)據(jù)幀是整個窗口的所有數(shù)據(jù)幀進行重傳，但是整個窗口的所有數(shù)據(jù)幀并不是全部都出錯或丟失需要重傳，有的數(shù)據(jù)幀是完整接收依然被丟棄重傳，造成了一些不必要的數(shù)據(jù)幀的傳輸，信道的利用率下降。如果能夠?qū)τ诨瑒哟翱诹孔油ㄐ艆f(xié)議中需要重傳的數(shù)據(jù)幀進行選擇性重傳將是更有效的解決方案。

 

作者簡介：

第7篇：通信協(xié)議范文

關鍵詞：無線傳感器網(wǎng)絡；體系結(jié)構；通信體系；MAC協(xié)議；路由協(xié)議；傳輸層協(xié)議

[Abstract] This paper is based on the analysis of network characteristics. The paper introduces the concept and characteristics of communication system, wireless sensor network middleware and application system of three levels, and an overview of wireless sensor networks and media access control protocol, routing protocol, such as transport protocol communication system research and prospect.

Keywords: wireless sensor networks; architecture; communication system; MAC protocol; routing protocol; transport layer protocol

中圖分類號：E965文獻標識碼：A 文章編號：

無線傳感器網(wǎng)絡是由大量無處不在的、具有無線通信與計算能力的微小傳感器節(jié)點構成的自組織分布式網(wǎng)絡系統(tǒng), 是能根據(jù)環(huán)境自主完成指定任務的“智能”系統(tǒng), 是一項涉及多門前沿學科發(fā)展的綜合性技術。MEMS 將多種傳感器集成為一體, 制造小型化、低成本、多功能的傳感器節(jié)點; 大量的MEMS 傳感器節(jié)點只有通過低功耗的無線通信技術聯(lián)成網(wǎng)絡才能夠發(fā)揮其整體和綜合作用; 具有群體智能的自主自治系統(tǒng)的行為實現(xiàn)和控制是自動控制和人工智能領域的前沿研究內(nèi)容。

1、體系結(jié)構

無線傳感器網(wǎng)絡與移動專用網(wǎng)絡( Mobile Adho c Netw ork, MANET ) 相比, 具有節(jié)點數(shù)量多、分布密集, 通信采用廣播方式, 拓撲結(jié)構變化頻繁, 能量、計算和存儲能力有限, 沒有統(tǒng)一的標識等特點。這對無線傳感器網(wǎng)絡在設計上提出了新的要求和挑戰(zhàn), 即資源受限、可擴展性、容錯性、自組織、實時性和安全性等。其中, 資源受限, 尤其是能量有限是無線傳感器網(wǎng)絡的一個重要特征。由于傳感器節(jié)點多采用電池供電, 而且一旦部署就無人值守, 更換電池成本過大, 在設計無線傳感器網(wǎng)絡時,必須盡可能采用低功耗的器件、節(jié)能的協(xié)議算法和管理策略, 以便減少傳感器節(jié)點的能耗, 延長整個網(wǎng)絡的壽命。

組網(wǎng)與通信是通信體系的主要功能, 這一層包括開放系統(tǒng)互聯(lián)OSI 七層模型中的物理層, 數(shù)據(jù)鏈路層, 網(wǎng)絡層和傳輸層。無線傳感器網(wǎng)絡的計算模型涉及網(wǎng)絡的組織、管理和服務框架, 信息傳輸路徑的建立機制、面向需求的分布信息處理模式等問題,是無線傳感器網(wǎng)絡發(fā)展需要首先解決的問題。通信協(xié)議是核心內(nèi)容, 包括無線信道調(diào)制、共享信道分配、路由構建及與因特網(wǎng)互聯(lián)等。

2、通信體系

在通信體系的四層協(xié)議棧中, 物理層負責數(shù)據(jù)的調(diào)制、發(fā)送與接收, 涉及傳輸?shù)拿浇椤㈩l段的選擇、載波產(chǎn)生、信號檢測、調(diào)制解調(diào)方式、數(shù)據(jù)加密和硬件設計等。WSNs 采用的傳輸媒體主要有: 射頻( RF) 、可見光、紅外線等, 其中, 射頻是最常用的。到目前為止, 物理層已基本完成了無線傳感器網(wǎng)絡節(jié)點的設計開發(fā), 代表性的節(jié)點有U CLA 和Rockwell 自動化中心研制的WINS, MIT 研制的µAMPS, U C Berkeley 的Smar t Dust 和Mo tes。在這些平臺中, Mo tes 硬件平臺和其配套的TinyOS操作系統(tǒng)應用最為廣泛, 為全球300 多家研究機構所采用。目前, 物理層的工作主要集中于低功耗低成本高可靠性的模塊特別是通信模塊的研制和片上系統(tǒng)SoC 的設計。

3 MAC協(xié)議

3.1 基于調(diào)度算法的MAC協(xié)議

在基于調(diào)度算法的MAC 協(xié)議中, 傳感器節(jié)點可發(fā)送數(shù)據(jù)的時間通過一個調(diào)度算法來決定。這樣, 多個傳感器節(jié)點就可以同時、沒有沖突的在無線信道發(fā)送數(shù)據(jù)。這類協(xié)議中, 主要的調(diào)度算法是時分多復用T DMA, 即將時間分成多個時間片, 幾個時間片組成一個幀, 在每一幀中, 分配給傳感器節(jié)點至少一個時間片來發(fā)送數(shù)據(jù)。這類協(xié)議的調(diào)度算法通常尋找一個盡可能最近的用于發(fā)送數(shù)據(jù)的幀來達到高的空間利用率和低的數(shù)據(jù)包等待時間。

典型的協(xié)議有SMACS, DE-MAC和EMACS。基于調(diào)度的MA C 協(xié)議都是分布式的, 因此需要時間同步機制, 而不需要全局信息。這樣, 就可以在高動態(tài)變化的環(huán)境比如網(wǎng)絡拓撲改變的情況下充分適應并保持最佳的特性。這類協(xié)議提供了信道的公平使用, 與合適的調(diào)度算法配合就可以避免沖突的發(fā)生。但是許多基于T DMA 的協(xié)議必須使用較為精確的時間同步來調(diào)度, 增加了網(wǎng)絡的負載。另外, 有些T DMA 協(xié)議仍然存在一定的沖突, 導致很難控制這些沖突來保證實時性和節(jié)省能耗。

3.2非碰撞的MAC協(xié)議

非碰撞的MAC 協(xié)議通過消除碰撞來節(jié)能。好的非碰撞協(xié)議能夠潛在地提高吞吐量, 減少時延, 提供實時性保證。當前存在的問題是多信道的使用。這需要對無線傳感器網(wǎng)絡的節(jié)點硬件設計上提出了一個附加的要求( 有些節(jié)點必須有兩個收發(fā)器) 。另一個問題是協(xié)議的復雜性( 因為節(jié)點的計算能力有限, 傳感器網(wǎng)絡的協(xié)議總是越簡單越好) 。

3.3基于競爭的MAC協(xié)議

多數(shù)分布式MAC 協(xié)議采用載波監(jiān)聽或沖突避免的機制并采用附加的信令控制消息來處理隱藏和暴露節(jié)點問題。基于競爭的協(xié)議對無線信道的訪問采用競爭機制。比如: S-MAC , T-MA C ,ARC-MA C 。基于競爭的協(xié)議通常很難提供實時性保證, 而且由于沖突的存在, 浪費了能量。基于競爭的協(xié)議在有些應用場合( 比如主要考慮節(jié)能而不太關心時延的可預測性時) 有較大的應用。基于競爭的協(xié)議需要解決的是提供一個實時性的統(tǒng)計上界。根據(jù)這類協(xié)議的分布式和隨機的補償特性, 基于競爭的協(xié)議沒有確切的保證不同節(jié)點的數(shù)據(jù)包的優(yōu)先級。因此, 有必要限制優(yōu)先級倒置的概率以建立統(tǒng)計上的端到端的時延保證。

3.4混合的MAC協(xié)議

混合協(xié)議主要是將多種機制結(jié)合起來, 以獲取一個優(yōu)缺點的折衷。比如: 物理層驅(qū)動協(xié)議, 混合TDMA-FDMA 的MAC , 以及CAT-MAC 。混合協(xié)議糅合了多種機制的協(xié)議, 可以在很大程度上滿足傳感器網(wǎng)絡的需求, 但是必須注意消除各種機制的缺點。

通過對現(xiàn)有MA C 協(xié)議的分析, 我們認為可以在分析現(xiàn)有的非碰撞協(xié)議, 對其性能的提高與其硬件成本的增加進行權衡, 找到一個平衡點, 開發(fā)一種既有較高實時性和能量有效性, 又不因為硬件設備的附加而增加很多成本的協(xié)議; 改進現(xiàn)有的非碰撞協(xié)議, 降低其復雜度, 以便更易于在傳感器網(wǎng)絡實現(xiàn); 結(jié)合其他機制, 提出一種混合的協(xié)議, 以滿足傳感器網(wǎng)絡的需要。

4 、路由協(xié)議

由于傳感器網(wǎng)絡具有不同于傳統(tǒng)無線ad-hoc網(wǎng)絡的特點, 因此對它的路由的研究非常有挑戰(zhàn)性。首先, 由于節(jié)點眾多, 不可能建立一個全局的地址機制; 其次, 產(chǎn)生的數(shù)據(jù)有顯著的冗余性, 因此可以利用數(shù)據(jù)聚合來提高能量和帶寬的利用率; 第三, 節(jié)點的能量和處理能力有限, 因此需要精細的資源管理;最后, 由于網(wǎng)絡拓撲變化頻繁, 需要路由協(xié)議有很好的魯棒性和可擴展性。

4.1以數(shù)據(jù)為中心的路由協(xié)議

這類協(xié)議是建立在對目標數(shù)據(jù)的命名和查詢上, 并通過數(shù)據(jù)聚合減少重復的數(shù)據(jù)傳送。和傳統(tǒng)的基于地址的路由有顯著的差異。以數(shù)據(jù)為中心的路由協(xié)議主要有SPIN, DD , Rumo r Ro uting , Gr adient-based Rout ing , CADR ,

COU GAR 等。

4.2 分層次的路由協(xié)議

分層次路由協(xié)議的主要思想是讓節(jié)點參與特定的節(jié)點集群( cluster) 內(nèi)的多跳通信, 集群首領再進行數(shù)據(jù)聚合, 減少向sink 節(jié)點傳送的消息數(shù)量, 從而達到節(jié)省能量和提高可擴展性的目的。典型的集群形成是基于節(jié)點的能量儲備及節(jié)點同集群首領的接近程度。分層次的路由協(xié)議主要有: LEACH ,Hierarchica-l PEGASIS, TEEN , EARCSN 等。

4.3基于位置的路由協(xié)議

基于位置的路由協(xié)議利用節(jié)點的位置信息通過把數(shù)據(jù)傳送到指定區(qū)域而不是整個網(wǎng)絡, 來降低能耗。這方面的協(xié)議主要來源于移動Ad Hoc 網(wǎng)絡,設計時都考慮了節(jié)點的移動性。但在節(jié)點移動性很少或者根本不移動的情況下, 它們也非常適用。基于位置的協(xié)議有: MECN , GAF , GEAR 等。

4.4基于網(wǎng)絡流的路由協(xié)議

基于網(wǎng)絡流的路由協(xié)議的目標是: 在實現(xiàn)路由功能的同時, 考慮端對端的時延要求, 滿足一些網(wǎng)絡QoS 要求。這類路由協(xié)議主要有MLER , MCF , SAR , SPEED 等。

5、傳輸層協(xié)議

無線傳感器網(wǎng)絡的傳輸層協(xié)議主要實現(xiàn)與Internet 或其它的網(wǎng)絡進行互聯(lián)。由于可擴展性、以數(shù)據(jù)為中心的路由等特性和能耗、硬件資源的限制等問題, 傳感器節(jié)點無法像Internet 上的服務器一樣存儲大量的數(shù)據(jù), 而確認( ACK) 在無線傳感器網(wǎng)絡中的代價太過于昂貴, 導致TCP 和U DP 無法直接應用到無線傳感器網(wǎng)絡上。

第8篇：通信協(xié)議范文

一、電氣監(jiān)控系統(tǒng)網(wǎng)絡通信協(xié)議的概況

作為一種網(wǎng)絡通用語言，網(wǎng)絡通信協(xié)議是指為連接不同操作系統(tǒng)和不同硬件體系結(jié)構的互聯(lián)網(wǎng)絡引提供的通信支持。其從邏輯上將網(wǎng)絡進行7層劃分，各層都具備路由器、交換機等相應的物理設備。在電氣監(jiān)控系統(tǒng)內(nèi)IEC60870―5―103、IEC60870―5―104等為主要的網(wǎng)絡通信協(xié)議類型，具體如下：

1、IEC60870―5―103協(xié)議。作為國際電工委員會制定的繼電保護設備信息接口規(guī)范，IEC60870―5―103協(xié)議可在通信前置機和繼電保護裝置間的信號傳輸中充分應用。該協(xié)議主要選取主從―對多的非平衡傳輸方式，主站為通信前置機，從站為繼電保護裝置，每秒9600bit為標準傳輸速率，格式報文形式主要分為2種：固定幀長報文、可變幀長報文。其表述的2類信息傳輸方式為按照相應規(guī)定運用的服務數(shù)據(jù)單位與為標準化報文傳輸沒有涵蓋的全部可能應用過程，或全部可能信息利用通用分類服務傳輸。

2、IEC60870―5―104協(xié)議。在IEC60870―5―103基礎上，國際電工委員會為滿足網(wǎng)絡運輸又進行了IEC60870―5―104遠動通信協(xié)議的制定。其不僅能夠在集控中心與變電站、調(diào)度端進行全面運用，還能在變電站內(nèi)的通信網(wǎng)加以合理運用。一般選取RFC2200協(xié)議作為該協(xié)議物理層、鏈路層等主要協(xié)議。作為標準TCP/IP協(xié)議子集，RFC2200可使IEC60870―5―104協(xié)議應用于TCP/IP協(xié)議的高帶寬網(wǎng)絡傳輸。與其他協(xié)議相比，IEC60870―5―104協(xié)議具有良好實時性、可靠性等優(yōu)勢，且能夠進行大流量數(shù)據(jù)傳輸，為信息擴展提供便利。

二、網(wǎng)絡通信協(xié)議在電氣監(jiān)控系統(tǒng)中的應用

在科技快速發(fā)展的今天，電氣監(jiān)控系統(tǒng)愈加完善，將網(wǎng)絡通信協(xié)議合理應用于電氣監(jiān)控系統(tǒng)，對提升電氣監(jiān)控系統(tǒng)實時性、可靠性具有至關重要的作用，為此，本文以優(yōu)化其應用性能為例對網(wǎng)絡通信協(xié)議在電氣監(jiān)控系統(tǒng)中的應用進行了分析與探究。

1、實時性優(yōu)化應用

電氣監(jiān)控系統(tǒng)實時性提升的方式較多，一般分為2大類：升級電氣監(jiān)控系統(tǒng)硬件、優(yōu)化軟件算法。根據(jù)工作需求，可通過軟件優(yōu)化網(wǎng)絡通信協(xié)議，以此達到提高電氣監(jiān)控系統(tǒng)實時性的目的。

首先，IEC60870―5―103協(xié)議為例分析。光纖接口、EIA RS485接口為IEC60870―5―103協(xié)議電氣的主要接口類型。光纖傳輸具有良好抗干擾能力及較快傳輸速度。在相同變電站或距離較短情況下繼電保護裝置和監(jiān)控系統(tǒng)的兩種接口傳輸速度基本一致。在通信鏈路拓撲方面兩種接口一致，基于此，兩種接口具有相同分析方式。本文將EIA RS485接口作為分析研究重點，具體內(nèi)容如下：

作為三線制半雙工接口，EIA RS485接口在同一時間點上只能接收、發(fā)送信號，但不能同時進行接收、發(fā)送操作。一般選取圖1作為通信拓撲結(jié)構。通信權可由EIA RS485總線上并聯(lián)的3個繼電保護裝置依次取得，依次將數(shù)據(jù)傳送給通信前置機。繼電保護裝置數(shù)據(jù)向通信前置機傳送的快慢，由通信權時間間隔的長短加以確定。但電氣出現(xiàn)大面積故障的情況下，繼電保護裝置極易出現(xiàn)大量變位信號。如一個繼電保護裝置進行5個遙信信號上傳，完成此5個變位遙信信號傳輸需20幀以上報文。

其次，IEC60870―5―104協(xié)議為例分析。以太網(wǎng)傳輸為IEC60870―5―104協(xié)議的主要形式，平衡傳輸全雙工接口為以太網(wǎng)RJ45接口類型。對該協(xié)議實時性造成影響的主要因素包含2點，第一以太網(wǎng)的傳輸性能，對其起決定作用的因素為網(wǎng)絡拓撲結(jié)構及以太網(wǎng)帶寬；第二，該協(xié)議報文信號攜帶效率。根據(jù)筆者工作性質(zhì)，為提升電氣監(jiān)控系統(tǒng)網(wǎng)絡通信協(xié)議性能，本文以優(yōu)化提升IEC60870―5―104協(xié)議報文信號攜帶效率為主進行分析。本協(xié)議傳輸數(shù)據(jù)以I格式幀為主。該協(xié)議規(guī)定ASDU（一個）在249字節(jié)以下，可進行一個火一組信號傳輸。應用于現(xiàn)有監(jiān)控系統(tǒng)的IEC60870―5―104協(xié)議，I格式幀（一個）旺旺只進行一個變位遙信信號傳輸。為提高信號傳輸信號，需對I格式幀長度進行有效增加。

2、可靠性優(yōu)化應用

利用通信前置機、數(shù)據(jù)服務器、遠動機等設備的冗余配置及通信網(wǎng)絡冗余配置可實現(xiàn)電氣監(jiān)控系統(tǒng)可靠性。在具體應用中，硬件即便冗余配置，但卻存在冗余設備無擾無縫切換等問題。為達到網(wǎng)絡通信協(xié)議優(yōu)化運用，需提升通信前置機冗余切換、通信網(wǎng)絡冗余切換的可靠性，進而達到電氣監(jiān)控系統(tǒng)可靠性提升的目的。

（1）將EIA RS485接口應用于IEC60870―5―103協(xié)議時，EIA RS485接口一個的情況下主機只能有一臺，也就是說EIA RS485接口一個情況下2臺通信前置機無法利用該接口將報文發(fā)送給一臺繼電保護裝置。為對該協(xié)議傳輸可靠性進行有效提升，需并接2臺通信前置機的全部EIA RS485接口。要求位于工作狀態(tài)的通信前置機為1臺，位于熱備狀態(tài)的通信前置機為1臺。如工作狀態(tài)前置機內(nèi)隨意一個EIA RS485接口通信中斷被熱備狀態(tài)通信前置機檢測出來后，熱備狀態(tài)前置機可將此EIA RS485接口主機地位占據(jù)，利用此EIA RS485接口將報文發(fā)送給繼電保護裝置。該情況下，工作狀態(tài)通信前置機需將此EIA RS485接口主機地位拋棄，進而達到IEC60870―5―103協(xié)議雙機熱備接口切換。

（2）通信前置機、數(shù)據(jù)服務器、遠動機與以太網(wǎng)冗余配置為現(xiàn)有監(jiān)控系統(tǒng)的主要構成部分。冗余配置可對信號傳輸可靠性有效提升。但現(xiàn)階段最常見的雙機雙網(wǎng)切換機制為“硬切換”，也就是說一般情況下冗余的2臺通信前置機內(nèi)利用冗余通信網(wǎng)絡內(nèi)一條與運動機或服務器進行通信的只有一臺。如前置機正常運行時如出現(xiàn)故障或通信網(wǎng)絡中斷，可向冗余的另一臺通信前置機進行通信切換。但其存有諸多問題，如只能利用通信前置機內(nèi)部軟件對通信前置機切換、通信網(wǎng)絡切換進行判斷，通信在切換過程中為中斷情況，不能實現(xiàn)無擾連續(xù)切換。

在IEC60870―5―104協(xié)議內(nèi)對冗余通信網(wǎng)絡傳輸數(shù)據(jù)如何應用沒有進行詳細規(guī)定。如選取并行冗余協(xié)議，可將鏈路冗余體增設到各設備內(nèi)部，以此實施冗余網(wǎng)絡通信數(shù)據(jù)處理。但該功能在傳統(tǒng)變電站監(jiān)控系統(tǒng)設備內(nèi)并不具備，如選取該并行冗余協(xié)議，需進行現(xiàn)有監(jiān)控系統(tǒng)設備重新設計。在對現(xiàn)有設備不改動的情況下，應適當修改現(xiàn)有協(xié)議通信方式，進而達到冗余網(wǎng)絡并行數(shù)據(jù)傳輸?shù)哪康摹?/p>

第9篇：通信協(xié)議范文

關鍵詞：寬帶網(wǎng)絡測試系統(tǒng) TL1通信協(xié)議 VxWorks

0 引言

ISDN、xDSL、Cable、光纖等技術的出現(xiàn)，必將最終把人們帶入全新的數(shù)字寬帶上網(wǎng)時代。而在這眾多的寬帶技術中，xDSL正為越來越多的人所關注。xDSL(數(shù)字用戶線)是目前國際上最流行的寬帶接入技術，DSL技術主要分為對稱和非對稱兩大類。xDSL中“x”代表著不同種類的數(shù)字用戶線路技術。其中，ADSL的建設己經(jīng)成為寬帶接入的主流模式。它利用現(xiàn)有的雙絞銅線能夠滿足用戶寬帶接入通信業(yè)務需求，是實現(xiàn)寬帶上網(wǎng)和網(wǎng)上高速沖浪的理想選擇。

隨著ADSL用戶規(guī)模的急劇膨脹，現(xiàn)有的ADSL業(yè)務維護流程給實際工作帶來了效率低、滿意度差等問題，嚴重制約和阻礙了中國ADSL業(yè)務的高速增長。同時，用戶對通信業(yè)務的質(zhì)量要求越來越高，對于故障解決的及時性和有效性要求也越來越高。如何定位用戶側(cè)故障、線路故障和網(wǎng)絡側(cè)故障，如何快速解決故障，這些都成為DSL發(fā)展的新需求。目前，國內(nèi)關于xDSL測試系統(tǒng)的研究和應用正處于啟動期，無論國內(nèi)廠商還是國外廠商在中國都沒有投入應用的實例。本文基于xDSL寬帶網(wǎng)絡測試系統(tǒng)，主要討論TL1通信協(xié)議模塊的設計及實現(xiàn)。

1 ADSL寬帶網(wǎng)絡測試系統(tǒng)的總體設計

本節(jié)簡單介紹整個系統(tǒng)軟件總體的總體目標及軟件模塊的劃分，以及各模塊的目標及完成的功能以及各模塊之間的關系。并說明測試服務器與DSLAM網(wǎng)管接口、與112系統(tǒng)接口、與97資源數(shù)據(jù)庫接口。

1.1 軟件設計結(jié)構

1.1.1 客戶端軟件 ①測試服務器測試命令呈現(xiàn)界面(包括文本、圖形、報表顯示)；同時匯總?cè)請蟆⒅軋蟆⒃聢髷?shù)據(jù)。②對ATP設備自身的管理界面(包括對設備的配置管理、故障管理、性能管理、拓撲管理等)，相當于設備層面的EMS。③對應用系統(tǒng)的管理界面(包括用戶管理、白志管理、權限管理、用戶自定義設置)。

1.1.2 服務器軟件 ①相對于界面的后臺處理模塊，包括對測試命令的發(fā)送、解析(使用TL1協(xié)議)；對前臺界面的相應處理。②提供與其他系統(tǒng)的API接口(包括112網(wǎng)關系統(tǒng)的接口；DSLAM設備網(wǎng)管的通信協(xié)議)。③支持ATP設備多級組網(wǎng)的要求。④支持多協(xié)議，如TL1，SNMP協(xié)議。

1.1.3 112網(wǎng)關軟件 ①112網(wǎng)關軟件提供和運營商112系統(tǒng)的接口，解析112接口協(xié)議格式。②112網(wǎng)關系統(tǒng)提供脫機存儲功能。

1.1.4 設備層通信軟件 ①在設備層提供TL1協(xié)議的接口，完成客戶端與測試探頭的通信，接收測試任務，發(fā)送測試任務，傳送設備處理后的相應數(shù)據(jù)。②支持被動測試和相關告警信息的主動上傳。被動測試返回結(jié)果打包成TL1響應消息格式，主動上傳的消息打包成TL1自治消息格式，發(fā)送給客戶端，以便客戶端進行識別。

2.2 測試服務器 測試服務器完成規(guī)范定義的測試工作，并完成對設備的管理層面的管理，采用J2EE的解決方案，實現(xiàn)系統(tǒng)跨平臺的處理方式。測試服務器主要包括ATP測試功能、ATP自維護功能、與DSLAM網(wǎng)管接口、與112系統(tǒng)接口、與97資源數(shù)據(jù)庫接口。

測試服務器與DSLAM網(wǎng)管接口，DRAM設備和ADSL測試設備之間需要提供測試總線和測試通信接口，當需要對某一用戶進行測試時，先將該用戶端口的內(nèi)側(cè)或外側(cè)切換到測試總線上，然后通過測試通信接口發(fā)命令給測試設備啟動相關測試，并把測試結(jié)果返回給DSLAM設備，測試完畢后釋放端口與測試總線的連接。

測試服務器與112系統(tǒng)接口，ADSL測試服務器可以位于ADSL網(wǎng)管之外，測試服務器通過網(wǎng)絡與測試設備連接。ADSL網(wǎng)管和ADSL測試服務器分別和112連接，前者實現(xiàn)用戶端口查詢功能，后者實現(xiàn)測試設備測試功能。ADSL網(wǎng)管和112系統(tǒng)的接口是為了把ADSL障礙測試融合到112系統(tǒng)中，以實現(xiàn)ADSL障礙的集中受理、集中測試、集中派修和集中管理。當112系統(tǒng)受理到ADSL用戶報障后，112系統(tǒng)根據(jù)ADSL線路所在的位置〔局向、機框號、槽位、端口號)和需要做的測試命令發(fā)給ADSL網(wǎng)管，ADSL網(wǎng)管收到測試命令后，對相應端口進行測試，然后把測試結(jié)果返回到112系統(tǒng)。

測試服務器與97資源數(shù)據(jù)接口，應用服務器系統(tǒng)是從電信97工程的數(shù)據(jù)庫(97數(shù)據(jù)庫的數(shù)據(jù))中通過API接口實現(xiàn)數(shù)據(jù)共享，提取97數(shù)據(jù)庫中的相關資源數(shù)據(jù)，例如:局、交換機、主配線架、交接箱、分線盒，端子、號碼等信息。

3 基于VxWorks的TL1通信協(xié)議模塊的設計與實現(xiàn)

3.1 TL1通信協(xié)議模塊在測試系統(tǒng)中的作用 對于被動測試任務，上位機下發(fā)測試任務即TL1測試輸入命令，TL1通信協(xié)議模塊(TLIAgent)接收到測試任務后，對相應的TL1輸入命令進行解析，如果解析后判斷是系統(tǒng)的測試任務參數(shù)或側(cè)試功能，則將相應的功能參數(shù)設定和測試任務發(fā)送給ATP，如不是系統(tǒng)的測試任務或下發(fā)功能參數(shù)錯誤將錯誤的消息對應的響應消息格式化并上報給上位機告知錯誤的命令，ATP探頭接到測試任務后進行測試及數(shù)據(jù)采集，將測試結(jié)果返回給TLIAgent，主要通過結(jié)構體定義數(shù)據(jù)的格式，如測試成功TL1Agent根據(jù)TL1通信協(xié)議將測得的數(shù)據(jù)結(jié)果打包成TLI通信協(xié)議響應格式，發(fā)給上位機，如測試失敗TLIAgent上報測試失敗，在客戶端顯示對應的測試結(jié)果，和相應的表格和波形，此項測試任務完成。

對于自治消息，下位機在進行測試時不斷檢查系統(tǒng)設備狀態(tài)，如風扇轉(zhuǎn)速，設備溫度等狀態(tài)，如出現(xiàn)異常，則將異常狀態(tài)通過TL1Agent上報(函數(shù)調(diào)用)，TL1Agent將自治消息放入自治消息隊列，并發(fā)送給上位機，完成自治消息的上報。TLI協(xié)議用于承載由外接測試設備或內(nèi)置測試板測試的內(nèi)容，包括下發(fā)測試命令、測試模塊的復位等，該協(xié)議內(nèi)容可隨測試內(nèi)容而擴充更新。

此模塊在設備層提供TLI協(xié)議接口，是上位機和測試探頭之間的橋梁。不僅能夠配合完成被動測試任務，還能夠配合完成生產(chǎn)管理信息，自動上報告警信息，設備管理等功能。

3.2 TL1通信協(xié)議模塊的設計及實現(xiàn) 整個模塊采用實時多任務的設計方法。對于任務之間的通信，在VxWorks中，因為整個操作系統(tǒng)使用一個地址空間，所以沒必要對于進程之間的通信使用的信號量和消息隊列有一個全局的名字。信號量允許多個任務相互協(xié)調(diào)其活動，任務間最直接的通信方式是共享各式各樣的數(shù)據(jù)結(jié)構。由于VxWorks中所有任務存在于一個單一的線性地址空間，共享數(shù)據(jù)結(jié)構非常容易。在共享地址空間簡化數(shù)據(jù)交換的同時，需要保證這塊內(nèi)存的互斥訪問，VxWorks提供了許多實現(xiàn)共享臨界區(qū)互斥訪問的機制，信號量就是其中的一種。本模塊使用二進制信號量，用于互斥臨界區(qū)的訪問和任務之間的同步。

二進制信號量可以作為資源可用于不可用的標志，當任務取一個二進制信號量時要調(diào)用semTake()，結(jié)果取決于調(diào)用時該二進制是否可用。如果可用，信號量將變得不可用，而任務繼續(xù)執(zhí)行，如果信號量不可用，任務被掛起到任務阻塞隊列，直到該信號量可用。

當任務釋放一個信號量時要調(diào)用semGive()，結(jié)果也要依賴于調(diào)用時該信號量是否可用。如果可用，本次釋放信號量不起任何作用，如果信號量不可用，并且沒有在等待該信號量，那么信號量變?yōu)榭捎茫蝗绻盘柫坎豢捎茫⑶矣幸粋€或多個任務在等待該信號量，那么阻塞隊列中的第一個任務解除阻塞，而信號量仍不可用。

本模塊中各任務在設定優(yōu)先級時都設為相同的優(yōu)先級，每個任務在處理一條測試命令后將調(diào)用taskDelay() 函數(shù)，延時操作提供一個簡單的任務睡眠機制。taskDelayO用來移動調(diào)用任務到相同優(yōu)先級就緒隊列的尾部。在本模塊中，通過調(diào)用taskDelay()自動將CPU讓給系統(tǒng)中同優(yōu)先級的其他任務來進行處理消息，在嵌入式軟件中，除系統(tǒng)任務外，TL1通信協(xié)議的各任務優(yōu)先級是最高的。

主控函數(shù)，將初始化參數(shù)。傳輸層協(xié)議TCP封裝，全局變量的初始化、各功能參數(shù)設定命令、測試命令的監(jiān)聽、隊列、消息處理函數(shù)的各任務的創(chuàng)建；每個任務也就是一個線程，每個線程都被編制成無限循環(huán)的程序，等待特定的輸入，執(zhí)行相應的任務。

對于TL1消息處理，在系統(tǒng)要進行測試任務之前，啟動嵌入式軟件，主控函數(shù)運行后，處理連接請求線程TL1ServerSession首先要處理來自上位機的連接請求，連接后，然后由TL1AsynClientSession線程從上位機的讀取TL1輸入消息，將獲得的輸入消息放入接收隊列，定義最大線程數(shù)為5，由線程調(diào)度進行判斷線程池，根據(jù)狀態(tài)來判斷將要進行的調(diào)度，是創(chuàng)建消息處理線程還是喚醒消息處理線程，由消息解析處理線程AsynTLlMessageHandler對輸入命令進行解析，解析后的消息出隊列等待消息的發(fā)送，對輸入命令進行解析，通過函數(shù)調(diào)用進行測試命令的下發(fā)，返回測試數(shù)據(jù)，將返回的測試數(shù)據(jù)進行TL1消息格式化處理，得到響應消息放入發(fā)送隊列，等待出隊列進行消息的發(fā)送即將響應消息返回上位機:TL1消息處理流程流程圖

整個系統(tǒng)軟件劃分好模塊后，考慮TL1通信協(xié)議模塊與其它模塊之間的接口，本模塊對其它模塊有兩個接口，一個是與上位機(后臺處理模塊)之間的接口，另一個接口是與硬件驅(qū)動程序之間的接口。

與上位機之間的接口用套接口socket通信進行實現(xiàn)，流套接口提供了雙向的、有序的、無重復并且無數(shù)據(jù)邊界的數(shù)據(jù)流服務。套接口實現(xiàn)客戶端的連接，消息的讀取與發(fā)送消息。與硬件驅(qū)動程序之間的接口進行下發(fā)測試任務和讀取測試后的數(shù)據(jù)，用函數(shù)調(diào)用進行下發(fā)測試任務的實現(xiàn)，如果測試成功，對數(shù)據(jù)的讀取是通過對于本測試任務的一個全局變量來讀取，通過Sprintf函數(shù)對測試后的數(shù)據(jù)進行格式化，如果測試失敗，沒有測試后的數(shù)據(jù)的打包過程，直接進行響應消息的格式化；如果在測試過程中有異常情況要上報時是被調(diào)用的關系，一樣也使用函數(shù)調(diào)用來實現(xiàn)，下位機在不斷的檢查設備的狀態(tài)，如果一旦發(fā)現(xiàn)異常就調(diào)用此模塊的自治消息函數(shù)，上報異常情況，TLIAgent接到異常消息，通過自治消息通道將消息發(fā)給客戶端。模塊之間的接口如圖3所示。

4 結(jié)束語

本系統(tǒng)TL1通信協(xié)議模塊是基于VxWorks的多任務設計，使系統(tǒng)的實時性和穩(wěn)定性都非常好。目前該ADSL寬帶網(wǎng)絡測試系統(tǒng)己通過多個城市電信組織的測試，達到了系統(tǒng)的設計要求和性能指標。該系統(tǒng)不僅提供中國電信規(guī)定的公有接口，還自己定義了一套私有接口，有利于系統(tǒng)的功能的擴充。目前系統(tǒng)軟件雖然完成了功能，也達到了預期的響應測試速度，但有一些設計上存在一些缺陷，如系統(tǒng)的時鐘，并不是由MPC860系統(tǒng)時鐘來進行控制的，而是在開發(fā)的過程中發(fā)現(xiàn)問題后改正的，因為當時硬件平臺MPC860已經(jīng)開發(fā)完，無法進行改進，只能由軟件來自己定義一個時鐘，對于嵌入式軟件模塊如果有需要系統(tǒng)時間的就要通過函數(shù)調(diào)用來完成，這樣的顯示的時間未必很準確，會產(chǎn)生一定的誤差。此外，雖然在開發(fā)之前已經(jīng)進行過需求分析，但在開發(fā)的過程中發(fā)現(xiàn)有些需求并不是很明確，影響到開發(fā)的進度，這在以后的產(chǎn)品的研發(fā)過程中要盡量的避免。

參考文獻

[1]王金剛、宮霄霖等.基于VxWorks嵌入式實時系統(tǒng)設計.北京:清華大學出版社，2004.10.

[2]馮建和.ADSL寬帶接入技術及應用.北京:人民郵電出版社.2002.

[3]孔祥營.嵌入式實時操作系統(tǒng)VxWorks及開發(fā)環(huán)境Tornado.北京:中國電力出版社.2003.

[4]王東.NC-ATS TL1測試指令集.北京:北京中創(chuàng)信測科技股份公司.2003.

[5]馮濤.ATS項目總體方案設計.北京:北京中創(chuàng)信測科技股份公司.2003.

[6]羅國慶.VxWorks與嵌入式軟件開發(fā).北京:機械工業(yè)出版社.2003.