導(dǎo)語：如何才能寫好一篇通信協(xié)議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

【關(guān)鍵詞】 直放站 監(jiān)控 直放站監(jiān)控系統(tǒng) 通信協(xié)議

一、引言

直放站作為一種中繼產(chǎn)品，不僅可以在不增加基站數(shù)量的前提下保證網(wǎng)絡(luò)覆蓋，而且具有結(jié)構(gòu)簡單、投資較少和安裝方便等優(yōu)點，可廣泛用于移動信號難于覆蓋的盲區(qū)和弱區(qū)，是實現(xiàn)“小容量、大覆蓋”目標的一種優(yōu)選方案。對直放站設(shè)備進行遠程監(jiān)控，可以實時獲取設(shè)備的各種工作參數(shù)，并根據(jù)實際需要進行調(diào)整，如遇設(shè)備故障，可在第一時間內(nèi)獲知并及時派人進行維護，這對于提高設(shè)備維護效率和質(zhì)量，確保設(shè)備長期、穩(wěn)定運行具有重要意義。目前，由于直放站設(shè)備廠家各自為政，沒有一個統(tǒng)一、合理的監(jiān)控通信協(xié)議，因此直放站市場也出現(xiàn)了一些問題[1]：

（1）各地運營商基本同時使用著多個不同設(shè)備廠家的直放站及室內(nèi)覆蓋設(shè)備，但不同廠家的監(jiān)控項目功能和設(shè)備的監(jiān)控通信協(xié)議各不相同，給運營商的直放站設(shè)備統(tǒng)一管理工作帶來了很大不便。

（2）監(jiān)控系統(tǒng)應(yīng)該具有穩(wěn)定性、可靠性、擴展性、前瞻性等技術(shù)能力，可是目前已有的多種通信協(xié)議和監(jiān)控系統(tǒng)已不能滿足監(jiān)控功能擴充、協(xié)議擴充、多種類型設(shè)備兼容的需求。

（3）考慮到未來4G直放站室內(nèi)覆蓋設(shè)備的特點及未來新增設(shè)備兼容性的需要，制定一套高標準的統(tǒng)一監(jiān)控技術(shù)規(guī)范以及建立一個統(tǒng)一的、有前瞻性的直放站覆蓋設(shè)備監(jiān)控平臺已勢在必行。

二、直放站監(jiān)控系統(tǒng)原理

直放站監(jiān)控系統(tǒng)一般由監(jiān)控單元、通信信道和監(jiān)控中心三部分組成。監(jiān)控單元是安裝在直放站設(shè)備內(nèi)部的監(jiān)控電路，它的主要功能包括設(shè)備上電初始化與自檢，本地信號的采集、控制和處理，與監(jiān)控中心數(shù)據(jù)交換等。通信信道完成監(jiān)控單元與監(jiān)控中心的物理連接。監(jiān)控中心的主要職能是對眾多廠家提供的多類型、多數(shù)量的直放站進行“集中控制，統(tǒng)一監(jiān)管”。監(jiān)控中心對直放站的操作主要包括參數(shù)設(shè)置、數(shù)據(jù)查詢、告警處理三種主業(yè)務(wù)；直放站作為被監(jiān)管對象，在被動應(yīng)答來自監(jiān)控中心的命令外還必須將當前故障信息以告警命令的形式主動上報給監(jiān)控中心。監(jiān)控中心和直放站的通信方式可以是RS232串口直連、有線MODEM撥號和CDMA短信方式、TCP、UDP等。不管采用什么通信方式，直放站統(tǒng)一監(jiān)控協(xié)議只是作為應(yīng)用層協(xié)議[2]，與具體的傳輸介質(zhì)、傳輸手段無關(guān)[2]。直放站監(jiān)控系統(tǒng)基本組成如下圖所示：

三、 直放站的監(jiān)控現(xiàn)狀

由于種種原因，直放站的監(jiān)控一直沒有國際標準化組織的統(tǒng)一規(guī)范，也無實際的行業(yè)使用規(guī)范。近年來，國內(nèi)外設(shè)備廠家大多根據(jù)各自的理解和需求，逐步開發(fā)了一些直放站監(jiān)控設(shè)備，但數(shù)百種產(chǎn)品的監(jiān)控協(xié)議不統(tǒng)一、功能不健全、系統(tǒng)不開放，遠不能滿足電信級監(jiān)控需求，運營商幾乎無法開展有效的直放站的網(wǎng)絡(luò)監(jiān)控和運行管理。所以一直以來直放站設(shè)備故障通常都是被動發(fā)現(xiàn)，如用戶投訴或巡檢等， 因此反應(yīng)速度慢，工作效率低，嚴重影響了網(wǎng)絡(luò)質(zhì)量和網(wǎng)絡(luò)服務(wù)。

近年來出現(xiàn)了一些直放站的監(jiān)控協(xié)議，并開展了產(chǎn)品化工作，但這些通信協(xié)議由于有先天的缺陷，如各廠家對運營商統(tǒng)一協(xié)議理解有歧義、而且對應(yīng)用層協(xié)議格式也不統(tǒng)一。另外還由于廠家設(shè)備實現(xiàn)的差異性，即使有統(tǒng)一監(jiān)控協(xié)議封裝信息，也不能夠完全保證一家對其它廠家設(shè)備管理的透徹性和高效性，為此，并沒有真正形成電信級的直放站與分布系統(tǒng)的監(jiān)控功能[3]。

四、 當前主流通信監(jiān)控協(xié)議

在早期建設(shè)過程中，各廠家對直放站監(jiān)控系統(tǒng)采用的是不同的通信協(xié)議，各廠家之間難以實現(xiàn)互聯(lián)互通，這對建立統(tǒng)一監(jiān)控系統(tǒng)帶來了諸多不便，同時對設(shè)備監(jiān)控性能考核也缺少統(tǒng)一的評判依據(jù)。

為此，中國聯(lián)通在CDMA 直放站建設(shè)不久就開始關(guān)注這一問題并著手尋找解決方案，經(jīng)過近一年的研討論證與反復(fù)修改，于2002 年底推出了《中國聯(lián)通CDMA 直放站統(tǒng)一監(jiān)控管理協(xié)議規(guī)范》。此標準的頒布執(zhí)行對規(guī)范直放站市場和監(jiān)控性能的提高具有極其重要的意義，逐漸成為直放站監(jiān)控領(lǐng)域的技術(shù)規(guī)范，并逐漸成為各網(wǎng)絡(luò)運營商制定直放站協(xié)議標準的重要參考。在CDMA 統(tǒng)一協(xié)議成功應(yīng)用的同時，統(tǒng)一監(jiān)控的需求也日益提高，GSM 設(shè)備的接入和管理相比之下顯得較為混亂，各省分公司和設(shè)備供應(yīng)商都急盼早日制定GSM直放站統(tǒng)一監(jiān)控協(xié)議。為此，并于2004年初正式頒布了《中國聯(lián)通GSM 直放站綜合網(wǎng)絡(luò)監(jiān)控管理協(xié)議規(guī)范》，該標準的頒布為統(tǒng)一監(jiān)控的實現(xiàn)提供了進一步的便利。中國聯(lián)通推出的相關(guān)監(jiān)控協(xié)議規(guī)范也成了當時眾多直放站廠家的廠家協(xié)議模板。

在中國聯(lián)通CDMA、GSM協(xié)議標準相繼形成的同時，另一大運營商中國移動也于2005年7月頒布了中國移動直放站設(shè)備監(jiān)控接口技術(shù)規(guī)范1.0.0，并在全國推行，各直放站廠家也紛紛依據(jù)此規(guī)范進行通信協(xié)議的編碼，從而中國兩大主流通信監(jiān)控協(xié)議就此形成。

五、 兩大主流通信監(jiān)控協(xié)議之比較

5.1 通信協(xié)議功能比較

兩在主流監(jiān)控協(xié)議在規(guī)范監(jiān)控系統(tǒng)功能方面，都明確了監(jiān)控系統(tǒng)的具體功能，主要包括設(shè)備參數(shù)信息：如設(shè)備類型、廠家代碼、上報號碼、版本號等，監(jiān)控參數(shù)信息：如通信方式、查詢/設(shè)置電話號碼等，告警使能：如電源掉電告警使能等，告警狀態(tài)：如電源掉電等，設(shè)置參數(shù)：如電平告警門限、功放開關(guān)等，實時采樣數(shù)據(jù)：如輸出功率等。為此，兩大協(xié)議都基本上實現(xiàn)了通信協(xié)議所需具備的功能項，滿足直放站監(jiān)控的需要。

5.2 通信協(xié)議結(jié)構(gòu)比較

中國聯(lián)通監(jiān)控協(xié)議為非模塊化的設(shè)計：所有的監(jiān)控信息都集中在一條報文中，報文在組裝、發(fā)送、接收、處理等方面都是不可分割的，這使直放站的監(jiān)控系統(tǒng)很難實現(xiàn)模塊化設(shè)計，穩(wěn)定性和可維護性不強。協(xié)議設(shè)計也沒有充分考慮多幀數(shù)據(jù)的處理（如建立緩沖區(qū)、采用先入先出等），對監(jiān)控中心發(fā)送的多條數(shù)據(jù)無法識別其通信順序，使得多包發(fā)送適應(yīng)能力差，監(jiān)控功能的實現(xiàn)效率和性能較低。

中國移動監(jiān)控協(xié)議采用軟件工程理論中倡導(dǎo)的集約式模塊化開發(fā)設(shè)計方法， 使各個模塊不僅可以獨立安裝， 還可以對某個模塊單獨升級。模塊化結(jié)構(gòu)設(shè)計方法的關(guān)鍵在于模塊間接口的標準化、通用化、規(guī)格化程度。筆者將數(shù)據(jù)協(xié)議結(jié)構(gòu)分成模塊（ 每個模塊的規(guī)模小到可以管理的程度） ， 然后分別將各個模塊隱藏在內(nèi)部接口后面， 讓模塊之間通過接口相互交流。監(jiān)控協(xié)議的模塊化總體思路是： 承載層模塊負責將通信設(shè)備驅(qū)動收發(fā)的字符流轉(zhuǎn)化為協(xié)議接入層的監(jiān)控報文，接入層接收承載層提供的監(jiān)控協(xié)議報文并進行幀識別、差錯控制和報文封裝等處理， 然后提交給網(wǎng)絡(luò)層進行目的節(jié)點操作數(shù)據(jù)流的分發(fā)， 并分解出操作指令和監(jiān)控應(yīng)用層數(shù)據(jù)單元，監(jiān)控應(yīng)用層負責監(jiān)控對象單元的提取、識別、執(zhí)行、回應(yīng)以及設(shè)備主動告警信息的形成， 由此實現(xiàn)了各層模塊間的獨立性和關(guān)聯(lián)性。協(xié)議分層結(jié)構(gòu)和模塊化設(shè)計思路解決了監(jiān)控協(xié)議的靈活組裝、升級換代和二次開發(fā)等問題， 提高了協(xié)議的適應(yīng)能力。

5.3 協(xié)議通信方式擴展性比較

中國聯(lián)通監(jiān)控協(xié)議的網(wǎng)絡(luò)功能擴充性差，其未考慮網(wǎng)絡(luò)層的存在，很難在現(xiàn)有功能之上再進行擴充。

中國移動監(jiān)控協(xié)議采用了目前在通信領(lǐng)域被普遍認同和使用的協(xié)議分層的設(shè)計思想， 整個體系由承載層、接入層、網(wǎng)絡(luò)層和監(jiān)控應(yīng)用層組成[4]。

承載層： 通信的實際鏈路， 此層確定了數(shù)據(jù)通信的實際信道類型， 向接入層提供面向字節(jié)的數(shù)據(jù)包。承載層用于適應(yīng)并實現(xiàn)直放站遠程監(jiān)控的多種通信方式（包括短信、數(shù)據(jù)傳輸、GPRS等）， 解決了監(jiān)控數(shù)據(jù)流的承載問題。承載層概念的引入， 實現(xiàn)了底層通信鏈路的可擴展性， 用戶可以將通用的底層通信方式各自模塊化封裝，當出現(xiàn)新的數(shù)據(jù)鏈路方式， 通信協(xié)議和設(shè)備監(jiān)控模塊可以方便地將其接入到監(jiān)控系統(tǒng)中。

接入層： 接入層是網(wǎng)絡(luò)層與承載層之間的接口， 用于承載層各通信方式之間的匹配， 同時對上層數(shù)據(jù)進行編碼， 以適應(yīng)和屏蔽不同承載層的特性和差異。由于監(jiān)控數(shù)據(jù)流載體的復(fù)雜性， 同時為利用各個物理載體的信號特性， 監(jiān)控數(shù)據(jù)不宜采用完全一樣的數(shù)據(jù)幀格式， 而是應(yīng)支持數(shù)據(jù)傳輸、GPRS 和短信等多種接入層協(xié)議， 實現(xiàn)通信方式的多樣性和可擴展性， 這樣接入層為上層協(xié)議屏蔽了通信信道的細節(jié)特征， 并保證網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)的可靠傳輸。

網(wǎng)絡(luò)層： 網(wǎng)絡(luò)層承載監(jiān)控應(yīng)用層協(xié)議包， 進行數(shù)據(jù)包尋址處理和分組， 向監(jiān)控應(yīng)用層提供本設(shè)備需要處理的監(jiān)控指令和數(shù)據(jù)， 并可以實現(xiàn)通信包的轉(zhuǎn)發(fā)（ 轉(zhuǎn)發(fā)的包不需要監(jiān)控應(yīng)用層來處理） 。網(wǎng)絡(luò)層提供點對點設(shè)備監(jiān)控信息的交互，提供了網(wǎng)間廣播功能， 降低了網(wǎng)絡(luò)維護的工作量， 提高了網(wǎng)絡(luò)的靈活度， 還可以通過動態(tài)路由技術(shù)來克服目前網(wǎng)絡(luò)需要靜態(tài)分配網(wǎng)絡(luò)地址的弊端， 在路由技術(shù)支持下， 設(shè)備可以選擇多個通信鏈路， 從而適應(yīng)多種通信方式的監(jiān)控。

監(jiān)控應(yīng)用層： 監(jiān)控應(yīng)用層針對各種監(jiān)控所需功能， 實現(xiàn)了面向監(jiān)控功能的數(shù)據(jù)組織和數(shù)據(jù)結(jié)構(gòu)。監(jiān)控應(yīng)用層解決了設(shè)備監(jiān)控信息的語法表示問題， 提供格式化的數(shù)據(jù)表示和數(shù)據(jù)轉(zhuǎn)換服務(wù)， 并提供網(wǎng)絡(luò)層與上層應(yīng)用軟件之間的接口服務(wù)。監(jiān)控應(yīng)用層采用最基本的設(shè)備狀態(tài)為基本監(jiān)控項， 通過對高獨立性的基本監(jiān)控項的算法設(shè)計形成告警信息， 從而實現(xiàn)了監(jiān)控項的高獨立性和設(shè)備監(jiān)控功能的自由組合， 使得對單個或多個參量的監(jiān)控功能操作時不再受相互關(guān)聯(lián)的設(shè)備狀態(tài)信息制約，提高了監(jiān)控信息的傳輸效率。同時監(jiān)控應(yīng)用層保證了每種監(jiān)控功能目的單純、語義清晰， 設(shè)備每項監(jiān)控功能對應(yīng)特定的一個監(jiān)控代碼和數(shù)據(jù)類型。監(jiān)控應(yīng)用層也幫助系統(tǒng)預(yù)留了數(shù)據(jù)的壓縮和解壓縮、加密和解密等拓展功能。

5.4 協(xié)議監(jiān)控對象自由度比較

中國聯(lián)通監(jiān)控協(xié)議的監(jiān)控對象不獨立，導(dǎo)致監(jiān)控項的內(nèi)容相互關(guān)聯(lián)， 當出現(xiàn)告警時，需從上報報文中提取并解析相關(guān)信息，獲得真正的告警信息，使得單個監(jiān)控項的操作變得復(fù)雜。當增加新的監(jiān)控項時，需重新定義監(jiān)控內(nèi)容，使得系統(tǒng)監(jiān)控的靈活性無法保證，同時增加了軟件代碼的冗余，不利于監(jiān)控算法的形成。協(xié)議格式如下圖：

聯(lián)通監(jiān)控協(xié)議將多個告警狀態(tài)信息放在統(tǒng)一格式的數(shù)據(jù)塊中， 當只想設(shè)置下行輸入功率告警上門限值時， 根據(jù)其通信協(xié)議的格式要求， 必須同時攜帶和輸入上行輸出功率告警上門限的值和下行輸出功率告警上門限的值。當出現(xiàn)下行輸入過功率告警時， 也必須上報其他兩項信息， 并由監(jiān)控中心進行告警判斷和甄別。

中國移動監(jiān)控協(xié)議因?qū)⒏鱾€監(jiān)控對象作為一個個體而存在的，將每個設(shè)備運行狀態(tài)封裝在各自獨立的數(shù)據(jù)塊， 如果用戶只想設(shè)置下行輸入功率告警上門限值， 則用戶只需輸入此值， 無須攜帶其他冗余的監(jiān)控信息。其協(xié)議格式如下圖所示

5.5 協(xié)議告警處理機制比較

中國聯(lián)通監(jiān)控協(xié)議的告警處理機制是以實時告警的方式來上報告警和告警恢復(fù)的，這在告警的及時性上是比較好的機制，但在直放站實際工作環(huán)境中常出現(xiàn)惡劣環(huán)境，從而導(dǎo)致設(shè)備的運行狀態(tài)在短時間發(fā)生頻繁切，為此上報大量的重復(fù)告警和誤告警。

中國移動監(jiān)控協(xié)議制訂了“9 次告警重發(fā)機制”（即告警3 min 確認機制”：每2 s采樣1 次，3 min 共采樣90 次，當采樣處于告警狀態(tài)的次數(shù)大于等于上門（ 如40%， 即36 次）時，設(shè)備就上報告警，當采樣處于告警狀態(tài)的次數(shù)小于等于下門限（ 如10%， 即正常狀態(tài)的次數(shù)大于等于81 次） 時， 才可上報告警恢復(fù)正常的信息，而且當直放站連續(xù)3次上報告警信息后末收到監(jiān)控中心的回應(yīng)包的，如果上傳失敗，直放站停止告警，在間隔一個規(guī)定的時間（3小時）后，繼續(xù)上報告警，如果再連續(xù)3次失敗，則在間隔一個規(guī)定的時間后繼續(xù)，共循環(huán)3次，即9次重發(fā)機制）、“告警使能機制”、“告警屏蔽機制”、“告警同步機制”等， 建立了完善、合理、可靠的告警處理機制，在防止監(jiān)控中心頻繁收到重復(fù)告警和誤告警方面起了明顯效果。

六、結(jié)束語

兩大主流監(jiān)控協(xié)議在各自的領(lǐng)域都發(fā)揮著重要的作用，在當前網(wǎng)絡(luò)發(fā)展階段，對當前在網(wǎng)的直放站及分布系統(tǒng)的監(jiān)控及綜合監(jiān)控建設(shè)都起著重要的作用。雖然中國移動監(jiān)控協(xié)議比中國聯(lián)通監(jiān)控協(xié)議在模塊化、結(jié)構(gòu)、可擴展性等方面更有優(yōu)勢，但協(xié)議在站點編號、多級站點還可以改進其擴展性，以符合更多類型、更多網(wǎng)絡(luò)結(jié)構(gòu)的設(shè)備接入，如接入GSM、WCDMA、TD-SCDMA、cdma 1X、cdma 2000、TD-LTE、LTE FDD、WLAN、固網(wǎng)寬帶等系統(tǒng)的光纖分布系統(tǒng)設(shè)備[5]。直放站監(jiān)控協(xié)議的制訂是一項嚴謹、科學、系統(tǒng)的工作，也是一項不斷完善的工作，隨著4G網(wǎng)絡(luò)的發(fā)展及逐步接入電信級監(jiān)控的發(fā)展趨勢，兩大主流通信監(jiān)控協(xié)議合二為一或是另定義標準協(xié)議也可以是后續(xù)的研究方向。

參考文獻

[1]許奕，直放站監(jiān)控規(guī)范的研究與應(yīng)用，通信世界，2007年3月，第10期，20

[2].中國聯(lián)通，中國聯(lián)通CDMA直放站綜合網(wǎng)絡(luò)監(jiān)控管理協(xié)議規(guī)范V2.0，2004，7

[3]胡憲華，吳捷，直放站與分布系統(tǒng)監(jiān)控協(xié)議的研究與開發(fā)，電信科學，2006年第11期，26-27

篇2

乙方：_________

為了滿足寬帶網(wǎng)用戶使用高科技視頻通信的需要，促進中國互聯(lián)網(wǎng)增值業(yè)務(wù)的發(fā)展，_________ 公司推出具有國際領(lǐng)先水平的可視電話視頻通信業(yè)務(wù)。為維護甲、乙雙方的合法權(quán)益，雙方就甲方使用乙方提供的視頻通信服務(wù)一事，根據(jù)國內(nèi)現(xiàn)時的相關(guān)法律、行規(guī)規(guī)定達成如下協(xié)議，以供共同遵照執(zhí)行：

1.為了保證乙方對甲方的服務(wù)質(zhì)量，甲方必須向乙方提供包括姓名（單位用戶則為單位全稱）、出生年月、住址（包括郵政編碼）、身份證號、工作單位、聯(lián)系電話等在內(nèi)的客戶資料。若甲方提供的客戶資料虛假或不詳細，乙方保留向甲方要求進一步提供身份證復(fù)印件（單位用戶則為法人營業(yè)執(zhí)照副本復(fù)印件）的權(quán)利，必要時有權(quán)停止向甲方提供服務(wù)，并依法追究甲方的法律責任。乙方保證對甲方提供的身份資料只作提供本協(xié)議項下的服務(wù)之用，未經(jīng)甲方授權(quán)不向任何第三方公開，但法律另有規(guī)定的除外。

2.乙方提供的視頻通信服務(wù)內(nèi)容及其價格見乙方網(wǎng)址_________ ，甲方向乙方申請服務(wù)過程中所生成的訂單等文件作為本協(xié)議的附件，與本協(xié)議具有同等法律效力。

3.甲方保證合法地使用乙方提供的服務(wù)，否則將承擔相應(yīng)的法律責任。

乙方提供給甲方的軟件是乙方及其關(guān)聯(lián)方具有自主知識產(chǎn)權(quán)的產(chǎn)品，甲方只能為接受乙方提供的服務(wù)而使用。甲方不能對其修改、解析或試圖尋找它的源代碼。任何前述的行為及為進一步轉(zhuǎn)載或重新分發(fā)而對本軟件進行復(fù)制或仿制給其他服務(wù)器或地址的行為都是禁止的。

4.乙方的終端是按照電腦工業(yè)標準由新的或相對新的零部件制作的。乙方保證乙方的終端無材料上或工藝上的瑕疵。保修期限為一年，從終端安裝之日起算。具體如下：

（1 ）由于郵寄給甲方而產(chǎn)生的終端損害包括在保修范圍內(nèi)。但保修范圍不包括由于外部原因引起的損害，包括但不限于意外事故、濫用、不正確的使用、打開封閉的電話機及視頻通信裝置、電源問題、不按照指令使用、不按照規(guī)定檢修、將乙方終端與非乙方提供的設(shè)備和網(wǎng)絡(luò)連接引起的問題等。

（2 ）在一年的保修期內(nèi)，乙方可視具體情形自由選擇是修理終端設(shè)備或調(diào)換終端設(shè)備，但甲方須在保修期內(nèi)書面通知乙方的技術(shù)支持部門方可享受此保修期。

（3 ）乙方從修理的終端設(shè)備上替換下的任何部件都由乙方所有。乙方可以使用新部件，也可以使用任何可達到技術(shù)要求的部件進行修理。乙方修理或調(diào)換設(shè)備后，原有的保修期并不相應(yīng)延長。

（4 ）乙方對硬件的缺陷或故障所負的責任僅限于在保修期內(nèi)修理或調(diào)換。

（5 ）如果乙方提供的終端設(shè)備被甲方或甲方的雇員或任何其他第三人擅自打開，保修期自動終止。

5.甲方應(yīng)在規(guī)定日期內(nèi)足額向乙方交納服務(wù)費用。逾期除應(yīng)補交所欠費用外，還應(yīng)交納違約金（每日按所欠費用千分之三計）；逾期超過一個月，乙方有權(quán)中止提供服務(wù)；逾期超過三個月，乙方有權(quán)終止提供服務(wù)，并向甲方追繳欠費和違約金。

6.若甲方對乙方收取的通信費用存在異議，乙方有責任調(diào)查解釋，核實處理。

7.為提高通信質(zhì)量，乙方可能會對網(wǎng)絡(luò)采取擴容、調(diào)整、軟件升級等措施。乙方應(yīng)按有關(guān)規(guī)定以業(yè)務(wù)公告或其他形式提前告知甲方。對因此導(dǎo)致甲方通信中斷、號碼更改等而造成的損失，乙方不承擔違約賠償責任。

8.乙方為更好地為甲方提供服務(wù)，當研制出軟件新版本時將對甲方現(xiàn)有軟件進行自動升級。甲方同意乙方作前述自動升級。

9.甲方應(yīng)根據(jù)乙方的要求和自身能力對通信費用進行控制，甲方月通信費超過選定的信用額時，乙方有權(quán)暫停提供部分或全部視頻通信服務(wù)，直至甲方繳清已發(fā)生費用。

10. 乙方應(yīng)依法保護甲方的通信自由和通信秘密不受侵害。當司法機關(guān)因國家安全或追查刑事犯罪的需要，要求協(xié)助調(diào)查時，乙方可以依法暫停向甲方提供視頻通信服務(wù)，暫停期間月租費按規(guī)定照常收取。

11. 甲方要求停止接受乙方服務(wù)時，應(yīng)在結(jié)清所有費用后終止本協(xié)議。

12. 由于乙方提供給甲方的是互聯(lián)網(wǎng)增值業(yè)務(wù)，因此乙方對由于互聯(lián)網(wǎng)的狀況引起的諸如不能接通、中斷、音像質(zhì)量不穩(wěn)定等不負任何責任。

13. 在甲方使用乙方提供的終端、軟件或服務(wù)時，乙方不對其他的服務(wù)提供商或任何第三方的行為或過失承擔責任。乙方對小于連續(xù)24小時的服務(wù)中斷及服務(wù)的局限或打斷不負責任。乙方及任何乙方服務(wù)提供商對任何故障或過失的責任，僅限于甲方受影響時的服務(wù)費用。乙方及任何乙方服務(wù)提供商對任何附帶的、懲罰性的或繼起的損害賠償要求（如損失的利益）不負任何責任。

14. 對不可抗力（如地震、洪水等自然災(zāi)害、戰(zhàn)爭、暴亂等）及政府行為而使本協(xié)議部分或全部不能履行，雙方互不承擔違約責任。

15. 本協(xié)議如有變更，乙方將以業(yè)務(wù)公告的形式通知甲方；若甲方對新協(xié)議有異議，須在業(yè)務(wù)公告出后一個月內(nèi)與乙方協(xié)商，否則將視為甲方已熟悉并同意本協(xié)議的變更。

16. 本協(xié)議的目的是為了保護甲、乙雙方的利益，如有未盡事宜，雙方可以協(xié)商解決，也可以直接提交_________ 仲裁委員會進行仲裁。

17. 本協(xié)議經(jīng)甲乙雙方簽字、蓋章后生效，一式兩份，雙方各持一份，具有同等法律效力。

18. 本協(xié)議的解釋權(quán)歸乙方。

甲方（蓋章）：_________

乙方（蓋章）：_________

負責人（簽字）：_______

負責人（簽字）：_______

篇3

[關(guān)鍵詞]局域網(wǎng)；通信協(xié)議；TCP/IP

HowTOConfiguretheCommunicationProtocolsoftheLAN

WangGuangming

(ClassOne,GradeThree,DepartmentofComputerScience,ZaozhuangTeachers''''College,Zaozhuang277100)

Abstract:BasedontheLAN,forNetWare、Windows95/98andthemainisWindowsNToperationsystem,thispaperintroduceandanalysisthecharacteristic、capabilityandtheessentialconfiguremethodofthecommunicationprotocols.

KeyWords:LAN;CommunicationProtocols;TCP/IP

不同的網(wǎng)絡(luò)協(xié)議都有其存在的必要，每一種協(xié)議都有它所主要依賴的操作系統(tǒng)和工作環(huán)境。在一個網(wǎng)絡(luò)上運行得很好的通信協(xié)議，在另一個看起來很相似的網(wǎng)絡(luò)上可能完全不適合。因此，組建網(wǎng)絡(luò)時通信協(xié)議的選擇尤為重要。

無論是幾臺機器組成的Windows95/98對等網(wǎng)，還是規(guī)模較大的WindowsNT、Novell或Unix/Xenix局域網(wǎng)，凡是親自組建或管理過網(wǎng)絡(luò)的人，都遇到過如何選擇和配置網(wǎng)絡(luò)通信協(xié)議的問題。由于許多用戶對網(wǎng)絡(luò)中的協(xié)議及其功能特點不是很清楚，所以在組網(wǎng)中經(jīng)常選用了不符合自身網(wǎng)絡(luò)特點的通信協(xié)議。其結(jié)果就造成了網(wǎng)絡(luò)無法接通，或者是速度太慢，工作不穩(wěn)定等現(xiàn)象而影響了網(wǎng)絡(luò)的可靠性。下面我就分析一下各個協(xié)議的特點和性能借以說明我配置協(xié)議的理論和立場。

一、通信協(xié)議

組建網(wǎng)絡(luò)時，必須選擇一種網(wǎng)絡(luò)通信協(xié)議，使得用戶之間能夠相互進行“交流”。協(xié)議（Protocol）是網(wǎng)絡(luò)設(shè)備用來通信的一套規(guī)則，這套規(guī)則可以理解為一種彼此都能聽得懂的公用語言。關(guān)于網(wǎng)絡(luò)中的協(xié)議可以概括為兩類：“內(nèi)部協(xié)議”和“外部協(xié)議”下面分別予以介紹。

1.內(nèi)部協(xié)議

1978年，國際標準化組織（ISO）為網(wǎng)絡(luò)通信制定了一個標準模式，稱為OSI/RM（OpenSystemInterconnect/ReferenceModel，開放系統(tǒng)互聯(lián)參考模型）體系結(jié)構(gòu)。該結(jié)構(gòu)共分七層，從低到高分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。其中，任何一個網(wǎng)絡(luò)設(shè)備的上下層之間都有其特定的協(xié)議形式，同時兩個設(shè)備（如工作站與服務(wù)器）的同層之間也有其使用的協(xié)議約定。在這里，我們將這種上下層之間和同層之間的協(xié)議全部定義為“內(nèi)部協(xié)議”。內(nèi)部協(xié)議在組網(wǎng)中一般很少涉及到，它主要提供給網(wǎng)絡(luò)開發(fā)人員使用。如果你只是為了組建一個網(wǎng)絡(luò)，可不去理會內(nèi)部協(xié)議。

2.外部協(xié)議

外部協(xié)議即我們組網(wǎng)時所必須選擇的協(xié)議。由于它直接負責計算機之間的相互通信，所以通常稱為網(wǎng)絡(luò)通信協(xié)議。自從網(wǎng)絡(luò)問世以來，有許多公司投入到了通信協(xié)議的開發(fā)中，如IBM、Banyan、Novell、Microsoft等。每家公司開發(fā)的協(xié)議，最初一般是為了滿足自己的網(wǎng)絡(luò)通信，但隨著網(wǎng)絡(luò)應(yīng)用的普及，不同網(wǎng)絡(luò)之間進行互聯(lián)的要求越來越迫切，因此通信協(xié)議就成為解決網(wǎng)絡(luò)之間互聯(lián)的關(guān)鍵技術(shù)。就像使用不同母語的人與人之間需要一種通用語言才能交談一樣，網(wǎng)絡(luò)之間的通信也需要一種通用語言，這種通用語言就是通信協(xié)議。目前，局域網(wǎng)中常用的通信協(xié)議（外部協(xié)議）主要有NetBEUI、IPX/SPX及其兼容協(xié)議和TCP/IP三類。

3.選擇網(wǎng)絡(luò)通信協(xié)議的原則

我們在選擇通信協(xié)議時一般應(yīng)遵循以下的原則：

第一、所選協(xié)議要與網(wǎng)絡(luò)結(jié)構(gòu)和功能相一致。如你的網(wǎng)絡(luò)存在多個網(wǎng)段或要通過路由器相連時，就不能使用不具備路由和跨網(wǎng)段操作功能的NetBEUI協(xié)議，而必須選擇IPX/SPX或TCP/IP等協(xié)議。另外，如果你的網(wǎng)絡(luò)規(guī)模較小，同時只是為了簡單的文件和設(shè)備的共享，這時你最關(guān)心的就是網(wǎng)絡(luò)速度，所以在選擇協(xié)議時應(yīng)選擇占用內(nèi)存小和帶寬利用率高的協(xié)議，如NetBEUI。當你的網(wǎng)絡(luò)規(guī)模較大，且網(wǎng)絡(luò)結(jié)構(gòu)復(fù)雜時，應(yīng)選擇可管理性和可擴充性較好的協(xié)議，如TCP/IP。

第二、除特殊情況外，一個網(wǎng)絡(luò)盡量只選擇一種通信協(xié)議。現(xiàn)實中許多人的做法是一次選擇多個協(xié)議，或選擇系統(tǒng)所提供的所有協(xié)議，其實這樣做是很不可取的。因為每個協(xié)議都要占用計算機的內(nèi)存，選擇的協(xié)議越多，占用計算機的內(nèi)存資源就越多。一方面影響了計算機的運行速度，另一方面不利于網(wǎng)絡(luò)的管理。事實上一個網(wǎng)絡(luò)中一般一種通信協(xié)議就可以滿足需要。

第三、注意協(xié)議的版本。每個協(xié)議都有它的發(fā)展和完善過程，因而出現(xiàn)了不同的版本，每個版本的協(xié)議都有它最為合適的網(wǎng)絡(luò)環(huán)境。從整體來看，高版本協(xié)議的功能和性能要比低版本好。所以在選擇時，在滿足網(wǎng)絡(luò)功能要求的前提下，應(yīng)盡量選擇高版本的通信協(xié)議。

第四、協(xié)議的一致性。如果要讓兩臺實現(xiàn)互聯(lián)的計算機間進行對話，它們兩者使用的通信協(xié)議必須相同。否則中間還需要一個“翻譯”進行不同協(xié)議的轉(zhuǎn)換，這樣不僅影響通信速度，同時也不利于網(wǎng)絡(luò)的安全和穩(wěn)定運行。

二、局域網(wǎng)中常用的三種通信協(xié)議

BEUI協(xié)議

■NetBEUI通信協(xié)議的特點。NetBEUI(NetBIOSExtendedUserInterface，用戶擴展接口)由IBM于1985年開發(fā)完成，它是一種體積小、效率高、速度快的通信協(xié)議。NetBEUI也是微軟最鐘愛的一種通信協(xié)議，所以它被稱為微軟所有產(chǎn)品中通信協(xié)議的“母語”。微軟在其早期產(chǎn)品，如DOS、LANManager、Windows3.x和WindowsforWorkgroup中主要選擇NetBEUI作為自己的通信協(xié)議。在微軟如今的主流產(chǎn)品，如Windows95/98和WindowsNT中，NetBEUI已成為其固有的缺省協(xié)議。有人將WinNT定位為低端網(wǎng)絡(luò)服務(wù)器操作系統(tǒng)，這與微軟的產(chǎn)品過于依賴NetBEUI有直接的關(guān)系。NetBEUI是專門為幾臺到百余臺PC所組成的單網(wǎng)段部門級小型局域網(wǎng)而設(shè)計的，它不具有跨網(wǎng)段工作的功能，即NetBEUI不具備路由功能。如果你在一個服務(wù)器上安裝了多塊網(wǎng)卡，或要采用路由器等設(shè)備進行兩個局域網(wǎng)的互聯(lián)時，將不能使用NetBEUI通信協(xié)議。否則，與不同網(wǎng)卡（每一塊網(wǎng)卡連接一個網(wǎng)段）相連的設(shè)備之間，以及不同的局域網(wǎng)之間將無法進行通信。

雖然NetBEUI存在許多不盡人意的地方，但它也具有其他協(xié)議所不具備的優(yōu)點。在三種通信協(xié)議中，NetBEUI占用內(nèi)存最少，在網(wǎng)絡(luò)中基本不需要任何配置。尤其在微軟產(chǎn)品幾乎獨占PC操作系統(tǒng)的今天，它很適合于廣大的網(wǎng)絡(luò)初學者使用。

■NetBEUI與NetBIOS之間的關(guān)系。細心的讀者可能已經(jīng)發(fā)現(xiàn)，NetBEUI中包含一個網(wǎng)絡(luò)接口標準NetBIOS。NetBIOS（NetworkBasicInput/OutputSystem，網(wǎng)絡(luò)基本輸入/輸出系統(tǒng)）是IBM在1983年開發(fā)的一套用于實現(xiàn)PC間相互通信的標準，其目的是開發(fā)一種僅僅在小型局域網(wǎng)上使用的通信規(guī)范。該網(wǎng)絡(luò)由PC組成，最大用戶數(shù)不超過30個，其特點是突出一個“小”字。后來，IBM發(fā)現(xiàn)NetBIOS存在的許多缺陷，所以于1985年對其進行了改進，推出了NetBEUI通信協(xié)議。隨即，微軟將NetBEUI作為其客戶機/服務(wù)器網(wǎng)絡(luò)系統(tǒng)的基本通信協(xié)議，并進一步進行了擴充和完善。最有代表性的是在NetBEUI中增加了叫做SMB（ServerMessageBlocks，服務(wù)器消息塊）的組成部分，以降低網(wǎng)絡(luò)的通信堵塞。為此，有時將NetBEUI協(xié)議也稱為“SMB協(xié)議”。

人們常將NetBIOS和NetBEUI混淆起來，其實NetBIOS只能算是一個網(wǎng)絡(luò)應(yīng)用程序的接口規(guī)范，是NetBEUI的基礎(chǔ)，它不具有嚴格的通信協(xié)議功能。而NetBEUI是建立在NetBIOS基礎(chǔ)之上的一個網(wǎng)絡(luò)傳輸協(xié)議。

2.IPX/SPX及其兼容協(xié)議

■IPX/SPX通信協(xié)議的特點。IPX/SPX(InternetworkPacketeXchange/SequencesPacketeXchange，網(wǎng)際包交換/順序包交換)是Novell公司的通信協(xié)議集。與NetBEUI的明顯區(qū)別是，IPX/SPX顯得比較龐大，在復(fù)雜環(huán)境下具有很強的適應(yīng)性。因為，IPX/SPX在設(shè)計一開始就考慮了多網(wǎng)段的問題，具有強大的路由功能，適合于大型網(wǎng)絡(luò)使用。當用戶端接入NetWare服務(wù)器時，IPX/SPX及其兼容協(xié)議是最好的選擇。但在非Novell網(wǎng)絡(luò)環(huán)境中，一般不使用IPX/SPX。尤其在WindowsNT網(wǎng)絡(luò)和由Windows95/98組成的對等網(wǎng)中，無法直接使用IPX/SPX通信協(xié)議。

■IPX/SPX協(xié)議的工作方式。IPX/SPX及其兼容協(xié)議不需要任何配置，它可通過“網(wǎng)絡(luò)地址”來識別自己的身份。Novell網(wǎng)絡(luò)中的網(wǎng)絡(luò)地址由兩部分組成：標明物理網(wǎng)段的“網(wǎng)絡(luò)ID”和標明特殊設(shè)備的“節(jié)點ID”。其中網(wǎng)絡(luò)ID集中在NetWare服務(wù)器或路由器中，節(jié)點ID即為每個網(wǎng)卡的ID號（網(wǎng)卡卡號）。所有的網(wǎng)絡(luò)ID和節(jié)點ID都是一個獨一無二的“內(nèi)部IPX地址”。正是由于網(wǎng)絡(luò)地址的唯一性，才使IPX/SPX具有較強的路由功能。

在IPX/SPX協(xié)議中，IPX是NetWare最底層的協(xié)議，它只負責數(shù)據(jù)在網(wǎng)絡(luò)中的移動，并不保證數(shù)據(jù)是否傳輸成功，也不提供糾錯服務(wù)。IPX在負責數(shù)據(jù)傳送時，如果接收節(jié)點在同一網(wǎng)段內(nèi)，就直接按該節(jié)點的ID將數(shù)據(jù)傳給它；如果接收節(jié)點是遠程的（不在同一網(wǎng)段內(nèi)，或位于不同的局域網(wǎng)中），數(shù)據(jù)將交給NetWare服務(wù)器或路由器中的網(wǎng)絡(luò)ID，繼續(xù)數(shù)據(jù)的下一步傳輸。SPX在整個協(xié)議中負責對所傳輸?shù)臄?shù)據(jù)進行無差錯處理，所以我們將IPX/SPX也叫做“Novell的協(xié)議集”。

■NWLink通信協(xié)議。WindowsNT中提供了兩個IPX/SPX的兼容協(xié)議：“NWLinkSPX/SPX兼容協(xié)議”和“NWLinkNetBIOS”，兩者統(tǒng)稱為“NWLink通信協(xié)議”。NWLink協(xié)議是Novell公司IPX/SPX協(xié)議在微軟網(wǎng)絡(luò)中的實現(xiàn)，它在繼承IPX/SPX協(xié)議優(yōu)點的同時，更適應(yīng)了微軟的操作系統(tǒng)和網(wǎng)絡(luò)環(huán)境。WindowsNT網(wǎng)絡(luò)和Windows95/98的用戶，可以利用NWLink協(xié)議獲得NetWare服務(wù)器的服務(wù)。如果你的網(wǎng)絡(luò)從Novell環(huán)境轉(zhuǎn)向微軟平臺，或兩種平臺共存時，NWLink通信協(xié)議是最好的選擇。不過在使用NWLink協(xié)議時，其中“NWLinkIPX/SPX兼容協(xié)議”類似于Windows95/98中的“IPX/SPX兼容協(xié)議”，它只能作為客戶端的協(xié)議實現(xiàn)對NetWare服務(wù)器的訪問，離開了NetWare服務(wù)器，此兼容協(xié)議將失去作用；而“NWLinkNetBIOS”協(xié)議不但可在NetWare服務(wù)器與WindowsNT之間傳遞信息，而且能夠用于WindowsNT、Windows95/98相互之間任意通信。

3.TCP/IP協(xié)議

TCP/IP（TransmissionControlProtocol/InternetProtocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是目前最常用到的一種通信協(xié)議，它是計算機世界里的一個通用協(xié)議。在局域網(wǎng)中，TCP/IP最早出現(xiàn)在Unix系統(tǒng)中，現(xiàn)在幾乎所有的廠商和操作系統(tǒng)都開始支持它。同時，TCP/IP也是Internet的基礎(chǔ)協(xié)議。

■TCP/IP通信協(xié)議的特點。TCP/IP具有很高的靈活性，支持任意規(guī)模的網(wǎng)絡(luò)，幾乎可連接所有的服務(wù)器和工作站。但其靈活性也為它的使用帶來了許多不便，在使用NetBEUI和IPX/SPX及其兼容協(xié)議時都不需要進行配置，而TCP/IP協(xié)議在使用時首先要進行復(fù)雜的設(shè)置。每個節(jié)點至少需要一個“IP地址”、一個“子網(wǎng)掩碼”、一個“默認網(wǎng)關(guān)”和一個“主機名”。如此復(fù)雜的設(shè)置，對于一些初識網(wǎng)絡(luò)的用戶來說的確帶來了不便。不過，在WindowsNT中提供了一個稱為動態(tài)主機配置協(xié)議（DHCP）的工具，它可自動為客戶機分配連入網(wǎng)絡(luò)時所需的信息，減輕了聯(lián)網(wǎng)工作上的負擔，并避免了出錯。當然，DHCP所擁有的功能必須要有DHCP服務(wù)器才能實現(xiàn)。

同IPX/SPX及其兼容協(xié)議一樣，TCP/IP也是一種可路由的協(xié)議。但是，兩者存在著一些差別。TCP/IP的地址是分級的，這使得它很容易確定并找到網(wǎng)上的用戶，同時也提高了網(wǎng)絡(luò)帶寬的利用率。當需要時，運行TCP/IP協(xié)議的服務(wù)器（如WindowsNT服務(wù)器）還可以被配置成TCP/IP路由器。與TCP/IP不同的是，IPX/SPX協(xié)議中的IPX使用的是一種廣播協(xié)議，它經(jīng)常出現(xiàn)廣播包堵塞，所以無法獲得最佳的網(wǎng)絡(luò)帶寬。

■Windows95/98中的TCP/IP協(xié)議。Windows95/98的用戶不但可以使用TCP/IP組建對等網(wǎng)，而且可以方便地接入其它的服務(wù)器。值得注意的是，如果Windows95/98工作站只安裝了TCP/IP協(xié)議，它是不能直接加入WindowsNT域的。雖然該工作站可通過運行在WindowsNT服務(wù)器上的服務(wù)器（如ProxyServer）來訪問Internet，但卻不能通過它登錄WindowsNT服務(wù)器的域。如果要讓只安裝TCP/IP協(xié)議的Windows95/98用戶加入到WindowsNT域，還必須在Windows95/98上安裝NetBEUI協(xié)議。

■TCP/IP協(xié)議在局域網(wǎng)中的配置。在提到TCP/IP協(xié)議時，有許多用戶便被其復(fù)雜的描述和配置所困擾，而不敢放心地去使用。其實就局域網(wǎng)用戶來說，只要你掌握了一些有關(guān)TCP/IP方面的知識，使用起來也非常方便。

IP地址基礎(chǔ)知識。前面在談到IPX/SPX協(xié)議時就已知道，IPX的地址由“網(wǎng)絡(luò)ID”（NetWorkID）和“節(jié)點ID”（NodeID）兩部分組成，IPX/SPX協(xié)議是靠IPX地址來進行網(wǎng)上用戶的識別的。同樣，TCP/IP協(xié)議也是靠自己的IP地址來識別在網(wǎng)上的位置和身份的，IP地址同樣由“網(wǎng)絡(luò)ID”和“節(jié)點ID”（或稱HOSTID，主機地址）兩部分組成。一個完整的IP地址用32位（bit）二進制數(shù)組成，每8位（1個字節(jié)）為一個段（Segment），共4段（Segment1～Segment4），段與段之間用“.”號隔開。為了便于應(yīng)用，IP地址在實際使用時并不直接用二進制，而是用大家熟悉的十進制數(shù)表示，如192.168.0.1等。IP地址的完整組成：“網(wǎng)絡(luò)ID”和“節(jié)點ID”都包含在32位二進制數(shù)中。目前，IP地址主要分為A、B、C三類（除此之外，還存在D和E兩類地址，現(xiàn)在局域網(wǎng)中這兩類地址基本不用，故本文暫且不涉及），A類用于大型網(wǎng)絡(luò)，B類用于中型網(wǎng)絡(luò)，C類一般用于局域網(wǎng)等小型網(wǎng)絡(luò)中。其中，A類地址中的最前面一段Segment1用來表示“網(wǎng)絡(luò)ID”，且Segment1的8位二進制數(shù)中的第一位必須是“0”。其余3段表示“節(jié)點ID”；B類地址中，前兩段用來表示“網(wǎng)絡(luò)ID”，且Segment1的8位二進制數(shù)中的前二位必須是“10”。后兩段用來表示“節(jié)點ID”；在C類地址中，前三段表示“網(wǎng)絡(luò)ID”，且Segment1的8位二進制數(shù)中的前三位必須是“110”。最后一段Segment4用來表示“節(jié)點ID”。

值得一提的是，IP地址中的所有“網(wǎng)絡(luò)ID”都要向一個名為InterNIC（InternetNetworkInformationCenter，互聯(lián)網(wǎng)絡(luò)信息中心）申請，而“節(jié)點ID”可以自由分配。目前可供使用的IP地址只有C類，A類和B類的資源均已用盡。不過在選用IP地址時，總的原則是：網(wǎng)絡(luò)中每個設(shè)備的IP地址必須唯一，在不同的設(shè)備上不允許出現(xiàn)相同的IP地址。表1列出了IP地址中的“網(wǎng)絡(luò)ID”的有關(guān)屬性，“節(jié)點ID”在互不重復(fù)的情況下由用戶自由分配。其實，將IP地址進行分類，主要是為了滿足網(wǎng)絡(luò)的互聯(lián)。如果你的網(wǎng)絡(luò)是一個封閉式的網(wǎng)絡(luò)，只要在保證每個設(shè)備的IP地址唯一的前提下，三類地址中的任意一個都可以直接使用（為以防萬一，你還是老老實實地使用C類IP地址為好）。

子網(wǎng)掩碼。對IP地址的解釋稱之為子網(wǎng)掩碼。從名稱可以看出，子網(wǎng)掩碼是用于對子網(wǎng)的管理，主要是在多網(wǎng)段環(huán)境中對IP地址中的“網(wǎng)絡(luò)ID”進行擴展。舉個例子來說明：例如某個節(jié)點的IP地址為192.168.0.1，它是一個C類網(wǎng)。其中前面三段共24位用來表示“網(wǎng)絡(luò)ID”，是非常珍貴的資源；而最后一段共8位可以作為“節(jié)點ID”自由分配。但是，如果公司的局域網(wǎng)是分段管理的，或者該網(wǎng)絡(luò)是由多個局域網(wǎng)互聯(lián)而成，是否要給每個網(wǎng)段或每個局域網(wǎng)都申請分配一個“網(wǎng)絡(luò)ID”呢？這顯然是不合理的。此時，我們可以使用子網(wǎng)掩碼的功能，將其中一個或幾個節(jié)點的IP地址全部充當成“網(wǎng)絡(luò)ID”來使用，用來擴展“網(wǎng)絡(luò)ID”不足的困難。

當我們將某一節(jié)點的IP地址如192.168.0.1已設(shè)置成一個“網(wǎng)絡(luò)ID”時，網(wǎng)絡(luò)上的其它設(shè)備又怎樣知道它是一個“網(wǎng)絡(luò)ID”，而不是一個節(jié)點IP地址呢？這就要靠子網(wǎng)掩碼來告知。子網(wǎng)掩碼是這樣做的：如果某一位的二進制數(shù)是“1”，它就知道是“網(wǎng)絡(luò)ID”的一部分；如果是“0”便認作是“節(jié)點ID”的一部分。如將192.168.0.1當做“網(wǎng)絡(luò)ID”時，其子網(wǎng)掩碼就是11111111.11111111.11111111.00000001，對應(yīng)的十進制數(shù)表示為255.255.255.1。否則它的子網(wǎng)掩碼就是11111111.11111111.11111111.00000000，對應(yīng)的十進制數(shù)表示應(yīng)為255.255.255.0。有了子網(wǎng)掩碼，便可方便地實現(xiàn)用戶跨網(wǎng)段或跨網(wǎng)絡(luò)操作。不過，為了讓子網(wǎng)掩碼能夠正常工作，同一子網(wǎng)中的所有設(shè)備都必須支持子網(wǎng)掩碼，且子網(wǎng)掩碼相同。表2列出了A、B、C三類網(wǎng)絡(luò)的缺省子網(wǎng)掩碼。

網(wǎng)關(guān)。網(wǎng)關(guān)（Gateway）是用來連接異種網(wǎng)絡(luò)的設(shè)置。它充當了一個翻譯的身份，負責對不同的通信協(xié)議進行翻譯，使運行不同協(xié)議的兩種網(wǎng)絡(luò)之間可以實現(xiàn)相互通信。如運行TCP/IP協(xié)議的WindowsNT用戶要訪問運行IPX/SPX協(xié)議的Novell網(wǎng)絡(luò)資源時，則必須由網(wǎng)關(guān)作為中介。如果兩個運行TCP/IP協(xié)議的網(wǎng)絡(luò)之間進行互聯(lián)，則可以使用WindowsNT所提供的“默認網(wǎng)關(guān)”（DefaultGateway）來完成。網(wǎng)關(guān)的地址該如何分配呢？可舉一個例子來回答：假如A網(wǎng)絡(luò)的用戶要訪問B網(wǎng)絡(luò)上的資源，必須在A網(wǎng)絡(luò)中設(shè)置一個網(wǎng)關(guān)，該網(wǎng)關(guān)的地址應(yīng)為B網(wǎng)絡(luò)的“網(wǎng)絡(luò)ID”（一般可理解為B網(wǎng)絡(luò)服務(wù)器的IP地址）。當A網(wǎng)絡(luò)的用戶同時還要訪問C網(wǎng)絡(luò)的資源時又該怎么呢？你只需將C網(wǎng)絡(luò)的“網(wǎng)絡(luò)ID”添加到A網(wǎng)絡(luò)的網(wǎng)關(guān)中即可。依次類推……網(wǎng)關(guān)連多少個網(wǎng)絡(luò)，就擁有多少個IP地址。

主機名。網(wǎng)絡(luò)中唯一能夠代表用戶或設(shè)備身份的只有IP地址。但一般情況下，眾多的IP地址不容易記憶，操作起來也不方便。為了改善這種狀況，我們可給予每個用戶或設(shè)備一個有意義的名稱，如“WANGQUN”。至于在網(wǎng)絡(luò)中用到“WANGQUN”時，怎樣知道其對應(yīng)的IP地址呢？這完全由操作系統(tǒng)自己完成，我們大可不必考慮。

三、通信協(xié)議的安裝、設(shè)置和測試

局域網(wǎng)中的一些協(xié)議，在安裝操作系統(tǒng)時會自動安裝。如在安裝WindowsNT或Windows95/98時，系統(tǒng)會自動安裝NetBEUI通信協(xié)議。在安裝NetWare時，系統(tǒng)會自動安裝IPX/SPX通信協(xié)議。其中三種協(xié)議中，NetBEUI和IPX/SPX在安裝后不需要進行設(shè)置就可以直接使用，但TCP/IP要經(jīng)過必要的設(shè)置。所以下文主要以WindowsNT環(huán)境下的TCP/IP協(xié)議為主，介紹其安裝、設(shè)置和測試方法，其他操作系統(tǒng)中協(xié)議的有關(guān)操作與WindowsNT基本相同，甚至更為簡單。

■TCP/IP通信協(xié)議的安裝。在WindowsNT中，如果未安裝有TCP/IP通信協(xié)議，可選擇“開始/設(shè)置/控制面板/網(wǎng)絡(luò)”，將出現(xiàn)“網(wǎng)絡(luò)”對話框，選擇對話框中的“協(xié)議/添加”，選取其中的TCP/IP協(xié)議，然后單擊“確定”按鈕。系統(tǒng)會詢問你是否要進行“DHCP服務(wù)器”的設(shè)置？如果你的IP地址是固定的（一般是這樣），可選擇“否”。隨后，系統(tǒng)開始從安裝盤中復(fù)制所需的文件。

■TCP/IP通信協(xié)議的設(shè)置。在“網(wǎng)絡(luò)”對話框中選擇已安裝的TCP/IP協(xié)議，打開其“屬性”，在指定的位置輸入已分配好的“IP地址”和“子網(wǎng)掩碼”。如果該用戶還要訪問其它WidnowsNT網(wǎng)絡(luò)的資源，還可以在“默認網(wǎng)關(guān)”處輸入網(wǎng)關(guān)的地址。

■TCP/IP通信協(xié)議的測試。當TCP/IP協(xié)議安裝并設(shè)置結(jié)束后，為了保證其能夠正常工作，在使用前一定要進行測試。筆者建議大家使用系統(tǒng)自帶的工具程序：PING.EXE，該工具可以檢查任何一個用戶是否與同一網(wǎng)段的其他用戶連通，是否與其他網(wǎng)段的用戶連接正常，同時還能檢查出自己的IP地址是否與其他用戶的IP地址發(fā)生沖突。假如服務(wù)器的IP地址為192.168.0.1，如要測試你的機器是否與服務(wù)器接通時，只需切換到DOS提示符下，并鍵入命令“PING192.168.0.1”即可。如果出現(xiàn)類似于“Replyfrom192.168.0.1……”的回應(yīng)，說明TCP/IP協(xié)議工作正常；如果顯示類似于“Requesttimedout”的信息，說明雙方的TCP/IP協(xié)議的設(shè)置可能有錯，或網(wǎng)絡(luò)的其它連接（如網(wǎng)卡、HUB或連線等）有問題，還需進一步檢查。

四、小結(jié)

在組建局域網(wǎng)時，具體選擇哪一種網(wǎng)絡(luò)通信協(xié)議主要取決于網(wǎng)絡(luò)規(guī)模、網(wǎng)絡(luò)間的兼容性和網(wǎng)絡(luò)管理幾個方面。如果正在組建一個小型的單網(wǎng)段的網(wǎng)絡(luò)，并且對外沒有連接的需要，這時最好選擇NetBEUI通信協(xié)議。如果你正從NetWare遷移到WindowsNT，或兩種平臺共存時，IPX/SPX及其兼容協(xié)議可提供一個很好的傳輸環(huán)境。如果你正在規(guī)劃一個高效率、可互聯(lián)性和可擴展性的網(wǎng)絡(luò)，TCP/IP則將是理想的選擇。

參考文獻

[1]阮家棟俞麗和《微型計算機網(wǎng)絡(luò)原理及應(yīng)用》北京中國紡織大學出版社1995

[2]瞿坦《計算機網(wǎng)絡(luò)及應(yīng)用》北京化學工業(yè)出版社2002

篇4

【關(guān)鍵詞】SPI協(xié)議;雙DSP通信;TMS320DM642;TMS320C6747

1.引言

在水聲通信機的設(shè)計中，經(jīng)常是由一個處理器進行喚醒檢測、AGC（自動增益控制）、A/D（模擬-數(shù)字轉(zhuǎn)換）、D/A（數(shù)字-模擬轉(zhuǎn)換）等工作。另外一個處理器負責信號調(diào)制、解調(diào)、糾錯編碼/解碼等復(fù)雜計算。在我們的水聲通信機設(shè)計中，前端采用低功耗的TMS320C6747浮點DSP，進行數(shù)據(jù)預(yù)處理;后端采用高性能的TMS320DM642定點DSP，進行復(fù)雜計算。這就需要雙DSP分工協(xié)作，共同完成系統(tǒng)整機的功能。不可避免的，將涉及到雙DSP之間大量的指令和數(shù)據(jù)交互操作。我們希望采用靈活的架構(gòu)，簡潔的接口連線，簡單的控制協(xié)議，實現(xiàn)高可靠和高效率的指令與數(shù)據(jù)雙向傳輸，通過大量的實驗，我們最終選擇了SPI協(xié)議，并對典型的SPI協(xié)議進行了改進。典型的水聲通信機的架構(gòu)如圖1所示。

圖1 典型水聲通信機的架構(gòu)

在我們的設(shè)計中，“處理器A”選用了低功耗的TMS320C6747浮點DSP，“處理器B”選用了高性能的TMS320DM642定點DSP。在實際系統(tǒng)中，根據(jù)水聲通信機的不同工作頻段和運算能力要求，處理器A也可選擇FPGA/CPLD或者低功耗單片機;處理器B也可選擇不同運算能力的DSP、ARM或者FPGA。

2.SPI協(xié)議

SPI（Serial Peripheral Interface，串行設(shè)備接口）是Motorola公司于2000年提出的一種串行接口協(xié)議。該接口占用硬件資源少，通信協(xié)議簡單，具有同步時鐘，通信速率較高，分主設(shè)備和從設(shè)備，特別適合處理器與設(shè)備之間交換數(shù)據(jù)，在EEPROM（非易失存儲器）、串行A/D（模擬-數(shù)字轉(zhuǎn)換器）、串行D/A（數(shù)字-模擬轉(zhuǎn)換器）、實時時鐘等嵌入式系統(tǒng)中得到了廣泛的應(yīng)用。

SPI協(xié)議的原理很簡單，它以主從方式工作，這種模式需要有一個主設(shè)備和一個或多個從設(shè)備。典型的SPI協(xié)議定義了4線接口，這也是所有基于SPI的設(shè)備共有的，分別是SIMO（從機輸入、主機輸出），SOMI（從機輸出、主機輸入），SCK（時鐘）和CS（片選）。根據(jù)系統(tǒng)的不同需求，SPI接口也可以采用3線（數(shù)據(jù)單向傳輸）或5線等不同方式，以實現(xiàn)不同的功能。采用4線制SPI接口時，接口示意圖如圖2所示。

從圖2可知，所有的控制信號均由SPI主設(shè)備提供，SPI從設(shè)備只能在被查詢時才能與主設(shè)備建立通信。這種限制在處理器與設(shè)備通信時影響不大，但應(yīng)用在雙處理器對等雙向通信時就有問題，作為從機的處理器無法主動發(fā)起通信，與主機交換數(shù)據(jù)。

在我們設(shè)計的水聲通信機中，雙DSP之間需要對等雙向通信，無論哪一方都能發(fā)起通信，因此需要對典型的SPI通信協(xié)議進行修改，使得從機也能主動發(fā)起通信。這需要修改硬件接口設(shè)計，增加額外的信號線來實現(xiàn)。

SPI協(xié)議沒有定義握手機制，在進行雙向高速率的可靠通信時，需要從硬件和軟件兩方面設(shè)計握手機制。同時，SPI協(xié)議也沒有定義“指令”和“數(shù)據(jù)”傳輸標識，需要由軟件來解析。為了解決上述問題，我們對SPI通信接口進行了改進，主要包括硬件接口設(shè)計和軟件協(xié)議設(shè)計兩部分。

3.系統(tǒng)硬件接口設(shè)計

硬件接口方面，在標準4線SPI協(xié)議的基礎(chǔ)上，增加ENAn、RSm和RSs三根控制線，分別代表從機請求主機通信、主機發(fā)給從機指令/數(shù)據(jù)指示、從機發(fā)給主機指令/數(shù)據(jù)指示。其控制思路如下：

當TMS320C6747（SPI主機）有指令/數(shù)據(jù)發(fā)給TMS320DM642（SPI從機）時，先設(shè)置RSm為某電平（約定高電平代表指令，低電平代表數(shù)據(jù)），然后發(fā)起通信，DM642的SPI模塊配置位從動模式，其底層硬件邏輯將自動檢測接收，并通知DM642進行后續(xù)接收/發(fā)送處理。

ENAn信號線平時為低電平，當DM642有指令/數(shù)據(jù)要傳遞給C6747時，先設(shè)置RSs電平（指示將指令/數(shù)據(jù)傳輸），然后設(shè)置ENAn信號線為高電平，C6747檢測到ENAn信號線電平的變化時，主動發(fā)起與DM642的通信。

我們設(shè)計的改進型SPI接口示意圖如圖3所示，圖3中左側(cè)虛線框內(nèi)的部分為TMS320DM642芯片內(nèi)集成的McBSP0接口，配置為4線SPI從動工作模式;圖3中右側(cè)虛線框內(nèi)的部分為TMS320C6747芯片內(nèi)集成的SPI1接口，配置為4線SPI主控模式，其中SPI1_ENAn由GPIO引腳控制。

圖2 典型的4線制SPI接口連接圖

圖3 TMS320DM642（SPI從）;TMS320C6747（SPI主）

經(jīng)過如此改進之后，TMS320C6747（主機）和TMS320DM642（從機）之間能進行高速率的全雙工數(shù)據(jù)與指令的交互。

4.系統(tǒng)軟件設(shè)計

硬件接口設(shè)計為實現(xiàn)SPI高速率傳輸創(chuàng)造了通道，但難以保證數(shù)據(jù)傳輸?shù)目煽啃院陀行浴榇?，我們設(shè)計了SPI主機（TMS320C6747）和SPI從機（TMS320DM642）通信的軟件協(xié)議。

為了能進行指令和大容量數(shù)據(jù)傳輸，并且易于對接收到的SPI數(shù)據(jù)進行實時解析，為“指令”和“數(shù)據(jù)”設(shè)計了不同的“幀”結(jié)構(gòu)。

進行指令傳輸時，固定每個數(shù)據(jù)包的長度，由“0x55AA”指示一個指令幀的開始，之后跟著幀序號，每次成功傳輸一幀后，幀序號增1，接下來是本機在前次握手通信時收到的幀序號，方便對方據(jù)此判斷前次指令是否被成功接收。

序號之后是20個指令字，最后是CRC校驗字段，接收端對前23個字進行CRC校驗，如果與接收到的CRC不同，則重新請求該指令序號;如果與接收到的CRC相同，則解析該指令。如果接收端收到的幀序號不連續(xù)，則表明兩個序號之間的部分指令出錯，根據(jù)需要可請求重發(fā);如接收端收到的對方“已接收序號”和之前發(fā)送的不同，也能識別出通信出錯。

在進行數(shù)據(jù)傳輸時，由“0x55A5”指示一個數(shù)據(jù)幀的開始，在幀序號之后是數(shù)據(jù)區(qū)的長度，接下來是數(shù)據(jù)區(qū)，最后是CRC校驗。指令幀和數(shù)據(jù)幀的序號分別編號，與傳輸“指令幀”同樣的機制，如果CRC出錯也可以請求重傳。連續(xù)的數(shù)據(jù)區(qū)便于接收端和發(fā)送端啟用EDMA模式，極大提高傳輸大量數(shù)據(jù)的效率。

構(gòu)建的“幀”結(jié)構(gòu)如下表所示。

“指令”幀格式：

0x55AA 序號 已接收序號 指令1 指令2 …… 指令20 CRC

“數(shù)據(jù)”幀格式：

0x55A5 序號 數(shù)據(jù)長度 數(shù)據(jù)…… CRC

采用上述協(xié)議后，有效地保障了SPI主機和從機之間雙向、可靠、高速、穩(wěn)定的指令和數(shù)據(jù)傳輸。

5.結(jié)論

在我們設(shè)計的水聲通信機中，采用了上述改進型SPI接口協(xié)議，TMS320C6747和TMS320DM642最小系統(tǒng)板之間以SPI接口進行板間連接，采用非屏蔽杜邦排線，長度大約10cm，實際測試表明，SPI時鐘速率在8.6 MHz時可穩(wěn)定進行指令和數(shù)據(jù)的全雙工通信。由于通過SPI接口傳輸一個字節(jié)最少需要8個時鐘，加上發(fā)送端準備數(shù)據(jù)、接收端解析并處理數(shù)據(jù)的開銷等，實際測試能以800kB/s穩(wěn)定通信。

參考文獻

[1]http：//.cn/cn/lit/ds/symlink/tms320c6747.pdf

[2]http：//.cn/cn/lit/ds/symlink/tms320dm642.pdf

[3]張巖，馬旭東，張云帆.ARM與DSP的SPI通信設(shè)計實現(xiàn)[J].工業(yè)控制計算機，2008，21（9）：56-57.

[4]高振，羅秋鳳.SPI接口與CRC算法在雙DSP數(shù)據(jù)通信中的應(yīng)用[J].電子產(chǎn)品世界，2011（1-2）：46-48.

[5]梁德堅，劉玉瓊.SPI總線數(shù)據(jù)遠距離傳輸實現(xiàn)[J].電子測試，2009（1）：72-75.

[6]趙，張楚.多媒體處理器中的SPI接口設(shè)計[J].電子測量技術(shù)，2007（6）：126-129.

[7]任宇飛，張相，程乃平.一種透明傳輸?shù)碾p向SPI接口的設(shè)計與實現(xiàn)[J].電視技術(shù)，2009，49（2）：51-54.

基金項目：福建省自然科學基金（項目編號：2013J01253）;中央高?；究蒲袠I(yè)務(wù)費專項資金資助（項目編號：2010121062）;國家自然科學基金（項目編號：61301098）資助。

作者簡介：

解永軍（1978―），男，工程師，主要研究方向：單片機與嵌入式系統(tǒng)，水聲通信技術(shù)。

篇5

近些年來，所有的企業(yè)在擴展信息傳輸系統(tǒng)的功能方面受到了兼容性的嚴重制約，因為監(jiān)控系統(tǒng)的軟件和硬件在擴充和補套以及服務(wù)上都對既定的廠家存在著極大的依賴性。如果企業(yè)運用的監(jiān)控系統(tǒng)出現(xiàn)問題而無法解決，那么就只有采購其他廠家的監(jiān)控系統(tǒng)進行替代。所以說，混亂的通信協(xié)議嚴重局限了系統(tǒng)補套和升級改良系統(tǒng)軟硬件，企業(yè)不斷的更換系統(tǒng)設(shè)備，造成了極大的成本浪費。在這種情況下，我國難以形成有序、良性的安全監(jiān)控系統(tǒng)市場競爭，而行業(yè)壟斷的出現(xiàn)可謂是必然。文章以這個大背景為前提，分析和研究了統(tǒng)一的監(jiān)控系統(tǒng)通信協(xié)議。

1 監(jiān)控系統(tǒng)分站統(tǒng)一通信協(xié)議框架

1.1 制定監(jiān)控系統(tǒng)分站統(tǒng)一通信協(xié)議的目的

監(jiān)控系統(tǒng)不同，其分站與主站之間就會存在不一致的通信協(xié)議，必然會導(dǎo)致難以互相調(diào)換其分站的結(jié)果。假設(shè)我們能夠采用相同的通信協(xié)議來設(shè)計監(jiān)控系統(tǒng)的分站，則當我們另外一個廠家生產(chǎn)的分站來代替原有分站時，系統(tǒng)的運行就不會受到設(shè)備更換的影響，用戶應(yīng)用起來也比較方便，同時也會造成市場上的競爭加劇，進而降低其價格。對于監(jiān)控系統(tǒng)的主站來說，分站的通信協(xié)議統(tǒng)一化也能夠提升其軟件水平，即便是部分卓越的軟件公司沒有具有競爭力的硬件產(chǎn)品，其也能夠?qū)?yōu)秀的軟件應(yīng)用于安全監(jiān)控系統(tǒng)中。這就是對監(jiān)控系統(tǒng)統(tǒng)一通信協(xié)議進行研究的一個原因。除此之外，企業(yè)在構(gòu)建信息化平臺方面也會受益于監(jiān)控系統(tǒng)通信協(xié)議的統(tǒng)一。

1.2 統(tǒng)一通信協(xié)議構(gòu)架

下表1給出了監(jiān)控通信協(xié)議幀的一般格式，以此為基礎(chǔ)我們相應(yīng)的構(gòu)架來對監(jiān)控系統(tǒng)通信協(xié)議進行構(gòu)建，無論是主從通信結(jié)構(gòu)還是無主通信結(jié)構(gòu)都能夠運用此通信協(xié)議。

表1 監(jiān)控通信協(xié)議幀的一般格式

2 監(jiān)控系統(tǒng)中心站數(shù)據(jù)通信框架

因為一致的通信協(xié)議不能馬上應(yīng)用于監(jiān)控系統(tǒng)所有的分站，而分站數(shù)據(jù)不能直接被高層的應(yīng)用接收，因此監(jiān)控系統(tǒng)接入?yún)f(xié)議必須進行專門的制定。下面羅列的類型可供監(jiān)控系統(tǒng)中心站接入?yún)f(xié)議選擇：

（1）文件共享型。以采樣周期或者規(guī)定的時間為單位，監(jiān)控系統(tǒng)設(shè)計者將一組數(shù)據(jù)文件以規(guī)范的文件結(jié)構(gòu)形式進行共享，其他的應(yīng)用就能夠獲取到相應(yīng)的信息，目前所有的監(jiān)控系統(tǒng)都能夠在保證系統(tǒng)正常運行的情況下實現(xiàn)這種方式的文件共享。（2）數(shù)據(jù)庫共享型。對于數(shù)據(jù)庫來說，其優(yōu)勢為開放性、標準化和完備的支持環(huán)境，采用數(shù)據(jù)庫形式，監(jiān)控系統(tǒng)能夠共享實時數(shù)據(jù)或者歷史數(shù)據(jù)，以此為基礎(chǔ)構(gòu)建的數(shù)據(jù)共享標準化模型也非常優(yōu)秀。（3）應(yīng)用軟件在過去必須通過特定的接口程序才能連接到現(xiàn)場設(shè)備或者應(yīng)用程序，之后才能完成通信，加大應(yīng)用程序之間通信的難度，以COM為基礎(chǔ)，規(guī)范了工業(yè)自動化軟件接口便形成了OPC，監(jiān)控中心站軟件業(yè)可以通過OPC方式連接其他軟件，進而完成數(shù)據(jù)信息的傳輸，而為了保證OPC與開發(fā)環(huán)境相兼容，微軟平臺成為了開發(fā)中心站軟件的基礎(chǔ)。下圖1顯示了詳細的OPC結(jié)構(gòu)。（4）對象管理集團OMG針對分布對象提出了一種解決方案，就是所謂的CORBA，而且近些年出現(xiàn)的眾多產(chǎn)品都能夠與CORBA相匹配。對象管理集團研發(fā)了對象管理架構(gòu)用來對分布計算機系統(tǒng)的異構(gòu)性進行解決。下圖2顯示的就是具體的對象管理架構(gòu)。各個模塊之間通過對象請求這條軟件總線進行通信和協(xié)作是該架構(gòu)的核心。

圖1 OPC的客戶/服務(wù)器結(jié)構(gòu)

圖2 對象管理架構(gòu)

篇6

【關(guān)鍵詞】計算機網(wǎng)絡(luò)路由通信協(xié)議

隨著應(yīng)用需求的增加，現(xiàn)代計算機網(wǎng)絡(luò)變得日趨復(fù)雜，網(wǎng)絡(luò)接入的通信設(shè)備數(shù)量迅猛增加，這就使得單IP多目通信成為現(xiàn)代計算機網(wǎng)絡(luò)的主要特點之一。為實現(xiàn)該通信，必須對通信數(shù)據(jù)進行路由，確保數(shù)據(jù)能夠被準確傳輸?shù)侥康牡刂分小?/p>

一、計算機網(wǎng)絡(luò)路由通信協(xié)議目標及其存在問題概述

應(yīng)用路由的目的在于利用諸如UDP等協(xié)議實現(xiàn)多目通信。這種多目通信路由協(xié)議需要具有以下特性。（1）首先是有效性。（2）其次是伸縮性。（3）再次是增量可配置。

二、動態(tài)路由選擇協(xié)議及其分類

動態(tài)路由選擇協(xié)議可以促使路由器對當前網(wǎng)絡(luò)內(nèi)的各終端和路由設(shè)備生成一個明確的了解，然后按照協(xié)議要求將網(wǎng)絡(luò)通信數(shù)據(jù)經(jīng)由最佳傳輸路徑轉(zhuǎn)發(fā)到接收端。目前常用的動態(tài)路由選擇協(xié)議存在兩種類型：一類為基于距離矢量的動態(tài)路由選擇協(xié)議，另一類為基于鏈路狀態(tài)路由的動態(tài)路由選擇協(xié)議。

2.1距離矢量路由選擇協(xié)議

該通信協(xié)議會使得距離矢量路由器按照網(wǎng)絡(luò)結(jié)構(gòu)特性等形成一個路由選擇表，并間隔一定時間向相鄰路由器發(fā)送該選擇表，當相鄰路由器接收到該選擇表后將自身路由信息添加到該路由選擇表中對其進行完善和豐富，當所有路由器均被添加入該選擇表后，路由通信協(xié)議完成路由的聚合過程。當數(shù)據(jù)需要經(jīng)由路由進行轉(zhuǎn)發(fā)時，可以依照該路由選擇表實現(xiàn)。顯而易見的，該通信協(xié)議存在一個明顯的應(yīng)用缺陷，即路由網(wǎng)絡(luò)聚合過程中會出現(xiàn)路由回路。為解決該問題，多種改進算法被提出來改善或修正該問題，如水平分割、抑制時間、跳數(shù)定義等。

2.2鏈路狀態(tài)路由選擇協(xié)議

相對上一種方法而言，該類協(xié)議使用分布式路由算法將網(wǎng)絡(luò)中每一路由的協(xié)議都被用于進行數(shù)據(jù)路由控制和轉(zhuǎn)發(fā)，因而使得數(shù)據(jù)路由實現(xiàn)的復(fù)雜度大大增加。具體實現(xiàn)中，鏈路狀態(tài)路由器會將路由器所在網(wǎng)段、路由鏈路狀態(tài)等聚合成自身路由信息，該信息不會在整個網(wǎng)絡(luò)中進行廣播，而是當出現(xiàn)信息更改時會通知與其相鄰的其他路由，相鄰路由接收到狀態(tài)通知后對自身信息表進行修改，實現(xiàn)狀態(tài)同步。該路由選擇協(xié)議同樣存在較為明顯的缺點：實現(xiàn)數(shù)據(jù)的最優(yōu)路由較為困難，且路由器不能編程。

三、改進的路由選擇協(xié)議

為綜合上述兩類路由的優(yōu)點，同時盡量消除其中存在的缺陷或不足，可以設(shè)計一種主動層次多目路由協(xié)議。該協(xié)議中定義路由器只用于進行信息轉(zhuǎn)發(fā)，而與路由路徑相關(guān)的內(nèi)容由容錯網(wǎng)關(guān)計算完成。在提升多目路由的快速收斂特性，可以將路由的拓撲結(jié)構(gòu)設(shè)計為層次式結(jié)構(gòu)。

具體來說，改進的路由選擇協(xié)議使用ARD協(xié)議來實現(xiàn)主動路由協(xié)議，利用SNMP協(xié)議來控制形成路由網(wǎng)絡(luò)的拓撲結(jié)構(gòu)和鏈路狀態(tài)，利用容錯網(wǎng)關(guān)進行內(nèi)部域報文通信和通信信息路由計算，利用管理網(wǎng)關(guān)進行外部域通信信息路由計算和IP地址管理。

四、內(nèi)網(wǎng)和外網(wǎng)網(wǎng)關(guān)通信協(xié)議

當某一計算機網(wǎng)絡(luò)的網(wǎng)絡(luò)類型較大時通常會將其分為多個小的、相對獨立的自治網(wǎng)絡(luò)每一個獨立的自制系統(tǒng)內(nèi)的路由相關(guān)協(xié)議是統(tǒng)一的。當路由通信協(xié)議將木雕定位于控制路由傳播和確定最佳路由選擇時，該協(xié)議屬于外部網(wǎng)關(guān)通信協(xié)議。雖然該類協(xié)議同樣存在自治系統(tǒng)，但是其自治系統(tǒng)的規(guī)模和復(fù)雜度通常會大于內(nèi)網(wǎng)自治系統(tǒng)。這類路由通信協(xié)議被應(yīng)用在域間信息通信中，處于自治系統(tǒng)的邊緣，只要少量的信息交換即可提供數(shù)據(jù)路由服務(wù)。目前成熟的、應(yīng)用廣泛的外部網(wǎng)關(guān)路由協(xié)議有BGP和EGP等。

五、總結(jié)

總之，在需要使用多層通信結(jié)構(gòu)的計算機網(wǎng)絡(luò)中必須使用路由通信協(xié)議來對數(shù)據(jù)進行路由、對終端設(shè)備進行網(wǎng)絡(luò)部署。好的動態(tài)路由算法不僅可以增強數(shù)據(jù)傳輸?shù)挠行浴⒔档蛿?shù)據(jù)路由所帶來的資源損耗，還能夠增強路由網(wǎng)絡(luò)內(nèi)的通信帶寬，確保各設(shè)備處于最佳運行狀態(tài)。

參考文獻

[1]羅炎炎，柳清芬，祁耀斌.淺論網(wǎng)絡(luò)通信中應(yīng)用的動態(tài)路由選擇協(xié)議[J].沿海企業(yè)與科技，2005（5）

[2]何丹，陳道蓄，謝立.主動層次多目通信路由模型[J].軟件學報，2000，11（6）

篇7

經(jīng)過整個產(chǎn)業(yè)的努力，2016年初，充電聯(lián)盟了充電樁與電動車之間的標準協(xié)議。這極大的推動了新能源汽車的發(fā)展。然而，隨著充電網(wǎng)絡(luò)建設(shè)規(guī)模的不斷擴大，作為整個產(chǎn)業(yè)鏈的重要的兩個環(huán)節(jié)，充電樁運營商和充電樁設(shè)備制造商面臨著非常重要的問題：充電樁與運營管理平臺接口協(xié)議不一致。

一方面，一家充電樁企業(yè)可能要為多個運營商提供設(shè)備，如果不同運營商制定的協(xié)議不一致，充電樁企業(yè)適配的成本會很高。

另一方面，每個運營商制定自己的企標也是摸石頭過河，成熟慢，經(jīng)驗不共享，升級改造測試成本高。兩者都希望能夠有規(guī)范的行業(yè)標準或者國家標準可以作為運營平臺建設(shè)和充電樁設(shè)備開發(fā)的依據(jù)。有了標準，大家可以不用在接口對接上再投入大量的成本，而把重點放在各自的核心業(yè)務(wù)上去。

中國普天曾積極參與了電動汽車行業(yè)充電接口協(xié)議統(tǒng)一的相關(guān)工作，另外，在互聯(lián)互通相關(guān)標準制定方面，普天也是相關(guān)協(xié)議制定的主體單位之一。普天信息技術(shù)有限公司是中國電動汽車充電技術(shù)與產(chǎn)業(yè)聯(lián)盟的副理事單位，作為主編單位之一，積極參與聯(lián)盟組織的《充電樁與運營平臺通訊協(xié)議》的編寫工作。

本次協(xié)議編寫工作，參考了國內(nèi)主流的充電樁運營企業(yè)已有的標準和國際上一些有廣泛影響力的標準如OCPP。基本的思路是滿足運營商的共性需求，支持個性需求的擴展；面向國際市場，兼容國外的主流標準協(xié)議。標準的制定工作得到了聯(lián)盟內(nèi)企業(yè)的積極響應(yīng)，紛紛報名副主編單位和參編單位。

聯(lián)盟內(nèi)部多次組織針對標準的討論，大家摳細節(jié)、鉆場景，討論過程熱烈而高效。1月13日，充電聯(lián)盟最終了《充電樁與運營平臺通訊協(xié)議》的征求意見稿。

為了推動協(xié)議的完善和應(yīng)用，接下來，充電聯(lián)盟會組織相關(guān)企業(yè)進行試點應(yīng)用，針對應(yīng)用中發(fā)現(xiàn)的問題修訂協(xié)議，為協(xié)議的大規(guī)模推廣打下一個堅實的基礎(chǔ)。

此外，聯(lián)盟計劃把協(xié)議棧開源化，促進協(xié)議的推廣和使用，讓更多樁企能快速接受。

篇8

Abstract： The IEC104 protocol is still widely used in the power system， the communication between main station and sub station is related to the safety of power system. The error retransmission mechanism is used to detect the network state， which is a basic method to realize the stable data transmission of IEC104， timeout is handled in accordance with the protocol definition， but the IEC104 protocol does not make further processing of this fault. So， if there is a fault， station staff will experience a long time to find the cause of the trouble. In order to guarantee the communication between the main station and sub station correctly and timely， a system that can monitor the communication process of IEC104 protocol is designed and developed. It implements the monitoring of IEC104 protocol communication process though capture analysis of the communication of simulated remote control station and sub station. Report library error message rate， IEC104 error rate， and repeat message rate are used to objectively evaluate communication of remote control station and sub station， to provide the basis for the control station personnel to quickly find out the fault causes， and to ensure the safe operation of the power system.

關(guān)鍵詞：遠動系統(tǒng)；IEC104規(guī)約；監(jiān)聽；故障分析

Key words： SCADA System；IEC104 protocol；monitoring；fault analysis

中圖分類號：TM764 文獻標識碼：A 文章編號：1006-4311（2017）02-0085-03

0 引言

目前IEC104協(xié)議仍在電力系統(tǒng)中廣泛的應(yīng)用，柳坪和雅都電站的集控中心與下屬電站及調(diào)度通訊均采用IECl04規(guī)約進行通信[1]。自2009年起，IEC60870-5-104規(guī)約在黃梅電網(wǎng)新建變電站和改造站的自動化系統(tǒng)中已大量采用[2]。遠動主站和子站之間能否正確及時的通信關(guān)系到電力系統(tǒng)的安危。利用錯誤重傳機制檢測網(wǎng)絡(luò)狀態(tài)是實現(xiàn)應(yīng)用IEC104穩(wěn)定傳輸數(shù)據(jù)的一個基本方法。超時處理按照規(guī)約定義進行超時斷開處理[3]。但IEC104協(xié)議未對這種故障做出進一步處理，當發(fā)生故障時控制站人員要經(jīng)歷很長時間才能找出故障源，所以開發(fā)一款能夠?qū)EC60870-5-104協(xié)議的通信過程進行監(jiān)聽的系統(tǒng)非常必要。本設(shè)計應(yīng)用端口匯聚和端口鏡像技術(shù)將模擬主站和子站的通信雙報文復(fù)制到端口鏡像并監(jiān)聽這個鏡像端口的通信報文來實現(xiàn)對模擬主站和子站通信報文的監(jiān)聽。通過對模擬遠動主站和子站的通信報文的抓包分析統(tǒng)計出通信過程中的錯誤報文率、IEC104錯誤幀率及重復(fù)報文率來客觀評價遠動主站和子站的通信，為控制站人員快速找出故障原因提供依據(jù)，保障電力系統(tǒng)的安全運行。

1 IEC104協(xié)議通信過程分析

IEC104協(xié)議采用應(yīng)-答模式的通信方式，即發(fā)送一條報文后收到此條報文的確認或回復(fù)報文才認為此次通信成功，否則將會重傳這條報文。協(xié)議采用TCP協(xié)議傳輸報文，使用2404端口作為通信端口。TCP的通信方式采用客戶端/服務(wù)器端的形式，模擬主控站作為客戶端模擬子站作為服務(wù)器端。

服務(wù)啟動后先由控制站檢查當前鏈路的狀態(tài)，然后再發(fā)送一些啟動需要的一些確認和對時等報文，規(guī)約啟動流程如圖1。

規(guī)約啟動后便可以進行遙控、遙信、遙測等操作。根據(jù)協(xié)議規(guī)定為了保障遙控等操作的成功率，在執(zhí)行前需要進行預(yù)置、反校操作，否則從站拒絕執(zhí)行。為了確保通信的成功，協(xié)議采用了應(yīng)-答模式的通信方式，從站在收到主控站的命令時會向主控站發(fā)送命令執(zhí)行確認報文以示命令已接收到并且正要執(zhí)行命令。當執(zhí)行完命令后會向主控站發(fā)送命令執(zhí)行結(jié)束報文以示命令已成功執(zhí)行。主控站可以通過發(fā)送遙控取消報文取消剛剛下發(fā)的命令，從站收到命令后取消相應(yīng)的操作并發(fā)送取消確認報文。未發(fā)生故障的遙控操作和帶取消命令的遙控操作的泳道圖如圖2。

在命令執(zhí)行過程中，由于網(wǎng)絡(luò)原因或其他可能的原因造成未收到某一個條報文的確認報文或回復(fù)報文的情況，按照規(guī)約規(guī)定會啟動重傳機制重傳這條報文，直到收到這條報文的確認或者超過最大重傳次數(shù)斷開鏈路連接。圖3左圖是未收到確認報文遙控操作的泳道圖，右圖是未收到執(zhí)行報文的遙控操作的泳道圖。

IEC104協(xié)議為了確保通信的正常并在發(fā)生網(wǎng)絡(luò)故障時的一些超時處理方案，IEC104協(xié)議采用的超時處理方案如表1。

2 系統(tǒng)建模分析及實現(xiàn)

監(jiān)聽系統(tǒng)采用端口匯聚技術(shù)將物理上的兩個端口連接起來形成一條邏輯鏈路，并使用端口鏡像技術(shù)將通信報文復(fù)制到鏡像端口，通過對鏡像端口的通信報文的監(jiān)聽達到監(jiān)聽主控站和子站之間的通信的目的。

監(jiān)聽系統(tǒng)實現(xiàn)的功能主要有獲取通信報文、解包、獲取IEC104協(xié)議幀、判斷協(xié)議幀是否正確、記錄報文、記錄報文到達時間，分析統(tǒng)計等功能。協(xié)議監(jiān)控系統(tǒng)的用例圖如圖4。

當監(jiān)聽系統(tǒng)啟動后便一直監(jiān)聽IEC104協(xié)議通信端口2404端口有無報文到達，若有到達則獲取報文并作相應(yīng)的處理。使用這種監(jiān)聽方法的優(yōu)點是不會影響主控站和子站的正常通信，監(jiān)聽系統(tǒng)作為第三方僅監(jiān)聽兩站的通信報文。監(jiān)聽系統(tǒng)的主線程流程圖如圖5

監(jiān)聽系統(tǒng)對報文處理過程的活動圖如圖6。

分析統(tǒng)計部分主要是對協(xié)議的傳輸過程和傳輸結(jié)果進行統(tǒng)計和分析。主要統(tǒng)計分析報文到達間隔、報文的錯誤率、IEC104協(xié)議幀的重復(fù)率以及遙控、遙測、對時等操作的完成的時間。

監(jiān)聽系統(tǒng)采用C++編程語言和VC++ 6.0為開發(fā)平臺，使用ws2-32.lib庫函數(shù)，實現(xiàn)對IEC104協(xié)議通信報文的監(jiān)聽。當監(jiān)聽系統(tǒng)啟動后便一直監(jiān)聽2404端口有沒有數(shù)據(jù)到達。通過報文的目的IP地址和源IP地址來區(qū)別主控站和從站并且監(jiān)聽系統(tǒng)會將通信報文保存到數(shù)據(jù)庫中為以后分析數(shù)據(jù)提供數(shù)據(jù)源。監(jiān)聽系統(tǒng)的實現(xiàn)如圖7。

3 結(jié)論

由于建設(shè)時期及所屬項目類別的差異各系統(tǒng)技術(shù)平臺不一通信方式和數(shù)據(jù)組織多種多樣由此形成了一個個信息孤島既影響了現(xiàn)有系統(tǒng)的有效運行也影響了新系統(tǒng)的開發(fā)和實施[4]。本設(shè)計將通信雙方的報文記錄并存儲到數(shù)據(jù)庫中，為以后數(shù)據(jù)共享和分析提供源數(shù)據(jù)可以有效的解決信息孤島的現(xiàn)象。

隨著IEC104協(xié)議在電力系統(tǒng)中得到廣泛的應(yīng)用，遠動主站和子站之間能否正確及時的通信關(guān)系到電力系統(tǒng)的安危。本系統(tǒng)主要針對遠動主站和子站之間能否及時并正確的通信以及出現(xiàn)網(wǎng)絡(luò)故障不能及時發(fā)現(xiàn)的問題，設(shè)計開發(fā)了一種電力遠動設(shè)備的IEC60870-5-104通信協(xié)議監(jiān)聽與測試系統(tǒng)。本系統(tǒng)主要利用端口匯聚和端口鏡像技術(shù)將遠動主站和子站的報文復(fù)制到鏡像端口并使用SOCKET編程對鏡像端口的通信報文進行抓包和分析，實現(xiàn)了對遠動主站和子站的通信的監(jiān)聽與測試，并在發(fā)生通信故障時第一時間報警，為電力遠動系統(tǒng)的正常運行提供了保障。

參考文獻：

[1]關(guān)鴻耀，劉榕.IECl04規(guī)約在水電廠遠動通訊中[J].計算機應(yīng)用 小水電，2011（1）：61.

[2]雷蘭.IECl04規(guī)約在黃梅電網(wǎng)中[J].電氣工程與自動化 機電信息，2013（3）：31.

篇9

關(guān)鍵詞： LabVIEW； J1939協(xié)議； 電池管理系統(tǒng)； 充電機； 協(xié)議測試

中圖分類號： TN915?34 文獻標識碼： A 文章編號： 1004?373X（2013）17?0114?04

0 引 言

隨著近年來電動汽車行業(yè)如火如荼的發(fā)展，電動汽車技術(shù)相關(guān)的各種標準也相繼推出，其中包括了《電動汽車非車載傳導(dǎo)式充電機與電池管理系統(tǒng)之間的通信協(xié)議》（GB/T 27930?2011）[1]。該協(xié)議是基于CAN應(yīng)用層協(xié)議SAE J1939，J1939是目前在國內(nèi)汽車行業(yè)中應(yīng)用廣泛的CAN總線應(yīng)用層協(xié)議[2?4]。只有電池管理系統(tǒng)與充電機之間的正常數(shù)據(jù)交互才能保證電動汽車進行高效、安全的充電。因此，電池管理系統(tǒng)與充電機通信協(xié)議測試是電池管理系統(tǒng)測試的一個必不可少的項目。本課題來源于北方車輛研究所電池管理系統(tǒng)測試平臺項目。美國國家儀器NI PXI CAN采集卡以及LabVIEW為模擬充電機與BMS通信提供了良好的軟硬件環(huán)境。

LabVIEW是美國國家儀器推出的一種程序開發(fā)環(huán)境，圖形化語言使其與其他的代碼類型語言相比之下更為方便直觀[5]。以計算機作為運行環(huán)境的LabVIEW，充分利用了計算機無可比擬的硬件優(yōu)勢，具有強大的數(shù)據(jù)處理能力。開發(fā)者可以很容易實現(xiàn)多線程編程，極大降低了軟件開發(fā)的難度。LabVIEW的前面板提供了豐富的類似傳統(tǒng)儀器的控件，開發(fā)者可以很方便的創(chuàng)建用戶界面。

本文重點在于如何用LabVIEW實現(xiàn)SAE J1939多幀傳輸機制，完成超過8 B報文的接收重組、拆分發(fā)送。以及如何實時判斷通信過程出現(xiàn)的錯誤、指出錯誤類型、定位錯誤發(fā)生的階段。

1 SAE J1939協(xié)議

J1939協(xié)議是基于CAN 2.0B制定的，協(xié)議對物理層、數(shù)據(jù)鏈路層、網(wǎng)路層以及應(yīng)用層都進行了相關(guān)的規(guī)定。本文針對數(shù)據(jù)鏈路層的規(guī)定進行簡單介紹。

1.1 協(xié)議數(shù)據(jù)單元（PDU）

J1939將CAN 2.0B的29位標識符ID劃分為六部分，每部分都代表不同的含義，包括優(yōu)先級（P）、保留位（R）、數(shù)據(jù)頁（DP）、PDU格式（PF）、特定PDU（PS）、源地址（SA），見表1。

根據(jù)CAN 2.0總線的仲裁機制，標識符值越小，CAN幀優(yōu)先級越高，J1939把這一權(quán)利賦予了標識符最高三位（P）。R、DP通常為0。SA代表了該幀數(shù)據(jù)的發(fā)送節(jié)點的地址，CAN網(wǎng)絡(luò)中每個設(shè)備都分配了惟一的SA。在介紹PF與PS之前有必要先介紹下參數(shù)組編號（PGN）的概念。每個PGN代表著惟一的參數(shù)組（可以包含一個或多個參數(shù)），當參數(shù)組的數(shù)據(jù)域大于8 B時，需要遵循J1939的多幀傳輸機制。PGN由R、DP、PF以及PS組成，見表2。從表2中可以看出PDU2格式報文沒有目標地址，此類報文只能發(fā)送給全局地址。由于PS作為PDU2格式參數(shù)組編號的一部分，因此PDU2比PDU1能定義更多的參數(shù)組編號。

1.2 多幀傳輸機制

CAN 2.0B數(shù)據(jù)域最多有8 B，而在J1939協(xié)議中當一個參數(shù)組編號（PGN）所對應(yīng)的數(shù)據(jù)超過8 B時，規(guī)定了一種多幀傳輸機制，發(fā)送者按此機制拆分發(fā)送，接收者按此機制接收重組，因此一個參數(shù)組編號所對應(yīng)的數(shù)據(jù)最多可以為1 785 B。點對點未發(fā)生錯誤的多幀傳輸機制如圖1所示，J1939對傳輸過程出現(xiàn)錯誤的情況也規(guī)定了相應(yīng)的處理機制，在此不作介紹。

TP.CM_RTS、TP.CM_CTS、TP.DT、TP.EndofMsgACK均為J1939特定功能報文，其參數(shù)組編號也由J1939規(guī)定，因此這些參數(shù)組編號不能再被用戶定義。TP.CM_RTS為消息發(fā)送者發(fā)送的請求發(fā)送幀，由此開始建立多幀傳輸鏈接，其數(shù)據(jù)域包括了此次發(fā)送的消息全部字節(jié)數(shù)、全部數(shù)據(jù)包數(shù)（TP.DT幀數(shù)）以及該消息的參數(shù)組編號等信息。接收者根據(jù)自己的接收能力，發(fā)送準備發(fā)送幀TP.CM_CTS，通知發(fā)送者下次可發(fā)送的數(shù)據(jù)包數(shù)、下一個要發(fā)送的數(shù)據(jù)包編號以及消息的參數(shù)組編號。發(fā)送者根據(jù)接收者的要求開始發(fā)送數(shù)據(jù)包TP.DT，數(shù)據(jù)包的數(shù)據(jù)域第一字節(jié)代表了該包號，因此一個數(shù)據(jù)包最多包含消息的7 B。

這個過程循環(huán)進行，直至接收者接收到全部數(shù)據(jù)包后發(fā)送消息結(jié)束應(yīng)答幀TP.EndofMsgACK代表著這次多幀傳輸?shù)慕Y(jié)束。若發(fā)送的消息是全局消息，則所有接收者不應(yīng)有任何應(yīng)答，整個傳輸過程如圖2所示。

2 基于LabVIEW實現(xiàn)J1939協(xié)議平臺

2.1 硬件接口

利用NI PXI?8513 CAN接口板卡實現(xiàn)該系統(tǒng)的硬件接口。NI已為開發(fā)者提供了該板卡的底層驅(qū)動，可以很方便對CAN節(jié)點參數(shù)進行配置以及接收和發(fā)送符合CAN 2.0的消息幀，然而對于多幀傳輸機制還需開發(fā)者自行設(shè)計。由于J1939協(xié)議涉及發(fā)送者與接收者的應(yīng)答，因此在基于LabVIEW開發(fā)J1939同時也利用C語言開發(fā)基思卡爾單片機的電池管理系統(tǒng)中使用的J1939協(xié)議，兩者相輔相成，并且利用VECTOR CANoe軟件監(jiān)視總線，以保證程序開發(fā)的順利進行。

2.2 軟件實現(xiàn)

利用LabVIEW多線程編程以及生產(chǎn)者消費者結(jié)構(gòu)實現(xiàn)J1939協(xié)議。分別為未拆分的發(fā)送報文、已拆分發(fā)送報文、未重組的接收報文、已重組的接收報文建立隊列。創(chuàng)建已重組報文讀取線程，已重組報文出隊列用于應(yīng)用層協(xié)議。創(chuàng)建接收報文處理線程，用于按多幀傳輸機制處理接收到的CAN 2.0數(shù)據(jù)幀，程序流程圖如圖3所示，經(jīng)過目的地址過濾報文后，利用條件結(jié)構(gòu)按照報文參數(shù)組編號進行分類處理，在計算參數(shù)組編號時要注意PDU1與PDU2格式的區(qū)別，主要分為以下幾種情況：數(shù)據(jù)小于7 B的正常數(shù)據(jù)報文：直接入已處理接收報文隊列供應(yīng)用層使用；請求發(fā)送幀TP.CM_RTS：由于兩個節(jié)點之間同一時間最多只能有一個發(fā)送和一個接收的多幀傳輸鏈接，若這時已有一個接收鏈接，則需要發(fā)送放棄鏈接幀TP.ABORT告知發(fā)送者，若無接收鏈接，創(chuàng)建新的接收狀態(tài)機并插入接收狀態(tài)機數(shù)組。接收狀態(tài)機為一個數(shù)據(jù)簇，包含了參數(shù)組編號、下一個接收數(shù)據(jù)包編號、數(shù)據(jù)包總數(shù)、當前已接收字節(jié)數(shù)、字節(jié)總數(shù)、以及已接收字節(jié)數(shù)組。之后應(yīng)發(fā)送準備發(fā)送幀TP.CM_CTS通知發(fā)送者發(fā)送數(shù)據(jù)包，同時應(yīng)開始計時，若發(fā)送者響應(yīng)時間超過規(guī)定時間，應(yīng)發(fā)送放棄幀TP.ABORT；準備發(fā)送幀TP.CM_CTS：此報文為接收者對發(fā)送報文的應(yīng)答，此次發(fā)送狀態(tài)機已建立，搜索相應(yīng)狀態(tài)機，根據(jù)準備發(fā)送幀要求拆分數(shù)據(jù)創(chuàng)建數(shù)據(jù)包TP.DT；數(shù)據(jù)包TP.DT：搜索相應(yīng)的接收狀態(tài)機并核對是否與目前狀態(tài)機相符，如果相符則對數(shù)據(jù)進行重組存入狀態(tài)機的接收字節(jié)數(shù)組，若不符則發(fā)送該參數(shù)組編號的放棄鏈接幀，最后判斷多幀傳輸是否結(jié)束，并根據(jù)是否為全局報文決定是否發(fā)送完成鏈接幀；完成鏈接幀TP.EndofMsgACK：表示相應(yīng)的多幀發(fā)送鏈接已完成，刪除相應(yīng)的發(fā)送狀態(tài)機。廣播公告消息TP.CM_BAM：收到全局消息的請求鏈接幀，只需建立相應(yīng)的接收狀態(tài)機，等待接收數(shù)據(jù)包，而不需要任何的應(yīng)答。

發(fā)送報文均先入未拆分發(fā)送報文隊列；創(chuàng)建未拆分發(fā)送報文處理線程，用于按多幀傳輸機制處理發(fā)送報文，程序流程圖如圖4所示，若發(fā)送報文數(shù)據(jù)超過8 B則需要通過多幀傳輸機制拆分發(fā)送。

2.3 J1939平臺應(yīng)用效果

定義電池管理系統(tǒng)BMS和LabVIEW的J1939協(xié)議地址分別為244和86。首先由BMS發(fā)送PGN為256的9 B報文給LabVIEW，CANoe監(jiān)視到總線時序如圖5所示。

由第一幀ID可以看出源地址為0xF4（244），目的地址為0x56（86），PGN為0xEC00，因此該幀為鏈接管理幀TP.CM，并且Data域控制字節(jié)（第1字節(jié)）為0x10，綜上該幀為BMS發(fā)送給LabVIEW的請求發(fā)送幀，并由Data域可以看出此次報文共有0x09字節(jié)（第2，3字節(jié)），數(shù)據(jù)包共有0x02包（第4字節(jié)），PGN為0x0100（第6，7，8字節(jié)）。同理第二幀為LabVIEW發(fā)送的準備發(fā)送幀，通知BMS從第0x01包（第3字節(jié)）開始發(fā)送0x02（第2字節(jié)）包數(shù)據(jù)包。待接收到BMS發(fā)送的兩幀TP.DT，LabVIEW發(fā)送TP.EndofMsgACK代表此次多幀傳輸完成。LabVIEW接收重組后的數(shù)據(jù)如圖6所示。

同理分析LabVIEW作為發(fā)送節(jié)點的情況，總線時序圖如圖7所示，LabVIEW拆分前的發(fā)送數(shù)據(jù)如圖8所示。綜上分析，利用LabVIEW開發(fā)平臺很好地實現(xiàn)了J1939協(xié)議。

3 通信協(xié)議測試軟件的開發(fā)

通信協(xié)議將整個通信分為多個階段：充電握手階段、充電參數(shù)配置階段、充電階段、充電結(jié)束階段。每個通信階段均涉及充電機與BMS的信息交互，每次信息交互均有超時限制。為了實現(xiàn)對通信協(xié)議進行測試，不僅要模擬充電機與BMS進行通信，還要實時監(jiān)測通信的狀態(tài)，判斷通信過程是否出錯并解析BMS發(fā)送的信息。測試軟件主要測試通信階段出現(xiàn)的時序錯亂以及信息交互超時這兩種錯誤。

在已開發(fā)J1939協(xié)議基礎(chǔ)上進行測試軟件的開發(fā)，J1939協(xié)議提供了兩個接口：需要發(fā)送報文直接入未處理發(fā)送報文隊列、已處理接收報文出隊列供應(yīng)用層使用。通信階段改變利用LabVIEW狀態(tài)機結(jié)構(gòu)來實現(xiàn)。創(chuàng)建充電機接收狀態(tài)、充電機發(fā)送狀態(tài)兩個數(shù)據(jù)簇，記錄接收報文是否已被接收、發(fā)送報文是否已被發(fā)送以及發(fā)送的時間。利用單獨程序線程通過這兩個數(shù)據(jù)簇實時判斷是否有錯誤發(fā)生。

應(yīng)用效果如圖9所示，為了試驗是否能準確測試出錯誤類型，有意將BMS程序設(shè)置為不發(fā)送電池充電需求報文，測試軟件指示超時類型代碼為5，即電池充電需求報文超時，接收錯誤類型主要為通信順序出錯。通過對每個接收超時類型以及順序出錯類型進行測試，結(jié)果表明能很好地實現(xiàn)對通信協(xié)議進行測試。

4 結(jié) 語

在LabVIEW開發(fā)平臺上，利用其強大的數(shù)據(jù)處理能力以及豐富實用的程序結(jié)構(gòu)實現(xiàn)了J1939協(xié)議，在此基礎(chǔ)上開發(fā)電動汽車非車載傳導(dǎo)式充電機與電池管理系統(tǒng)之間的通信協(xié)議測試軟件，不僅可以輔助BMS的程序開發(fā)，還可以作為BMS測試平臺的部分功能評價BMS合格與否。通過與BMS進行通信，并利用CANoe對總線進行監(jiān)視，試驗結(jié)果表明該測試軟件可以實現(xiàn)J1939協(xié)議，能完成多幀傳輸機制，并且可以測試出通信協(xié)議中出現(xiàn)的通信流程錯亂以及通信超時錯誤，可以滿足要求。

參考文獻

[1] 中國國家標準化管理委員會.GB/T 27930?2011電動汽車非車載傳導(dǎo)式充電機與電池管理系統(tǒng)之間的通信協(xié)議[S].北京：中國標準出版社，2011.

[2] SAE Group. SAE J1939?21 data link layer standard [S]. USA： SAE Group， 2001.

[3] 高松.淺談J1939協(xié)議在客車CAN總線中的應(yīng)用[J].農(nóng)業(yè)裝備與車輛工程，2005（2）：30?31.

[4] 蘇喜紅.基于J1939的汽車網(wǎng)絡(luò)控制系統(tǒng)CAN高層協(xié)議設(shè)計與實現(xiàn)[D].哈爾濱：哈爾濱工業(yè)大學，2007.

[5] 陳樹學，劉萱.LabVIEW寶典[M].北京：電子工業(yè)出版社，2011.

[6] 阮奇楨.我和LabVIEW[M].北京：北京航空航天大學出版社，2009.

篇10

【關(guān)鍵詞】STM32；單片機；嵌入式；數(shù)據(jù)通信；HJ/T212

1.引言

近年來，隨著環(huán)保意識的增強，各種各樣的環(huán)保采集、傳輸、監(jiān)控等設(shè)備被廣泛使用，為了指導(dǎo)各個城市污染源在線自動監(jiān)控（監(jiān)測）系統(tǒng)的建設(shè)，規(guī)范數(shù)據(jù)采集、傳輸、存儲和管理，保證各種環(huán)境監(jiān)測儀器、監(jiān)控設(shè)備、傳輸網(wǎng)絡(luò)和環(huán)保部門應(yīng)用軟件系統(tǒng)之間的連通，國家環(huán)保行業(yè)制定了數(shù)據(jù)傳輸標準協(xié)議HJ/T212。

STM32系列單片機基于專為要求高性能、低成本、低功耗的嵌入式應(yīng)用專門設(shè)計的，采用STM32F103系列ARM Cortex-M3內(nèi)核。時鐘頻率72MHz時，STM32功耗36mA，是32位市場上功耗最低的產(chǎn)品，相當于0.5mA/MHz。該系類單片機集成功能豐富、以8位機的價格提供32位的性能，現(xiàn)已廣泛應(yīng)用于多種領(lǐng)域，比如嵌入控制、消費電子產(chǎn)品、家用電器以至及工業(yè)設(shè)備等。

STM32系列單片機這些特點適合在環(huán)保數(shù)據(jù)的采集和傳輸環(huán)節(jié)作為主控MCU使用，本文介紹了HJ/T212在以STM32F103C8T6單片機為主控MCU的環(huán)保數(shù)據(jù)傳輸設(shè)備中的實現(xiàn)方法。

2.HJ/T212協(xié)議包組成

3.HJ/T212協(xié)議在STM32F103C8T6中的實現(xiàn)

STM32F103C8T6處理器內(nèi)的通用同步異步收發(fā)器（USART）提供了一種靈活的方法來與使用工業(yè)標準NRZ異步串行數(shù)據(jù)格式的外部設(shè)備之間進行全雙工數(shù)據(jù)交換。USART利用分數(shù)波特率發(fā)生器提供寬范圍的波特率。支持查詢、中斷和DMA三種方式，當選擇使用DMA方式，可以實現(xiàn)高速數(shù)據(jù)通信。

從協(xié)議可以看出，當接收到兩個字符時可以判斷一個完整的協(xié)議包接收完成。進而對該協(xié)議數(shù)據(jù)幀進行解析協(xié)議解析部分可以用C語言實現(xiàn)，下面的程序流程圖1為STM32F103C8T6響應(yīng)HJ/T212協(xié)議數(shù)據(jù)幀函數(shù)，主要功能是判斷協(xié)議包包頭是否有效，校驗碼是否正確，如果校驗碼正確的則把數(shù)據(jù)包的內(nèi)容按照項目內(nèi)容進行分割處理協(xié)議包的內(nèi)容。由于從上位機發(fā)送的協(xié)議包通常都是一包發(fā)送完成，所以協(xié)議單片機段的協(xié)議解析可以忽略總包號和包號，如果系統(tǒng)設(shè)置訪問密碼，則解析協(xié)議時需要判斷密碼是否正確，只有密碼有效才能認為是有效數(shù)據(jù)包，這個密碼的使用可以對數(shù)據(jù)的傳輸是一種安全措施。設(shè)備唯一標識MN也是一個必要參數(shù)，上位機通過網(wǎng)絡(luò)可能同時與多臺終端相連，此時上位機下發(fā)的指令需要根據(jù)設(shè)備標識符MN判斷上位機要操作的終端設(shè)備。

STM32F103C8T6單片機接收并解析數(shù)據(jù)包后，需要根據(jù)協(xié)議的應(yīng)答要求分步驟進行應(yīng)答。通常收到一包完整數(shù)據(jù)包后，現(xiàn)場機立刻進行請求應(yīng)答，然后返回操作執(zhí)行結(jié)果。

4.CRC算法及其實現(xiàn)

CRC即循環(huán)冗余校驗碼（Cyclic Redun-dancy Check）：是數(shù)據(jù)通信領(lǐng)域中最常用的一種差錯校驗碼，該校驗算法的特點是信息字段和校驗字段的長度可以任意選定。CRC校驗碼的兩個字節(jié)，包含一16位的二進制值。它由傳輸設(shè)備計算后加入到數(shù)據(jù)包中。接收設(shè)備重新計算收到消息的CRC，并與接收到的CRC域中的值比較，如果兩值不同，則有誤。

①裝一個16位寄存器，所有數(shù)位均為1。

②取被校驗串的一個字節(jié)與16位寄存器的高位字節(jié)進行“異或”運算。運算結(jié)果放入這個16位寄存器。

③把這個16寄存器向右移一位。

④若向右（標記位）移出的數(shù)位是1，則生成多項式1010000000000001和這個寄存器進行“異或”運算；若向右移出的數(shù)位是0，則返回③。

⑤重復(fù)③和④，直至移出8位。

⑥取被校驗串的下一個字節(jié)

⑦重復(fù)③～⑥，直至被校驗串的所有字節(jié)均與16位寄存器進行“異或”運算，并移位8次。

⑧這個16位寄存器的內(nèi)容即2字節(jié)CRC錯誤校驗碼。

5.結(jié)束語

STM32F103C8T6為開發(fā)人員提供了高性能的數(shù)字解決方案，通過在該MCU上實現(xiàn)HJ/T212協(xié)議使得系統(tǒng)具有很好的開放性和通用性，同時在別的嵌入式系統(tǒng)的串口通信的實現(xiàn)上也有很好的借鑒意義。

參考文獻

[1]曹圓圓.基于STM32的溫度測量系統(tǒng)[J].儀器儀表與分析監(jiān)測，2010，1：16-18.