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

篇1

【關鍵詞】 直放站 監控 直放站監控系統 通信協議

一、引言

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

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

（2）監控系統應該具有穩定性、可靠性、擴展性、前瞻性等技術能力，可是目前已有的多種通信協議和監控系統已不能滿足監控功能擴充、協議擴充、多種類型設備兼容的需求。

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

二、直放站監控系統原理

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

三、 直放站的監控現狀

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

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

四、 當前主流通信監控協議

在早期建設過程中，各廠家對直放站監控系統采用的是不同的通信協議，各廠家之間難以實現互聯互通，這對建立統一監控系統帶來了諸多不便，同時對設備監控性能考核也缺少統一的評判依據。

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

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

五、 兩大主流通信監控協議之比較

5.1 通信協議功能比較

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

5.2 通信協議結構比較

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

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

5.3 協議通信方式擴展性比較

中國聯通監控協議的網絡功能擴充性差，其未考慮網絡層的存在，很難在現有功能之上再進行擴充。

中國移動監控協議采用了目前在通信領域被普遍認同和使用的協議分層的設計思想， 整個體系由承載層、接入層、網絡層和監控應用層組成[4]。

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

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

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

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

5.4 協議監控對象自由度比較

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

聯通監控協議將多個告警狀態信息放在統一格式的數據塊中， 當只想設置下行輸入功率告警上門限值時， 根據其通信協議的格式要求， 必須同時攜帶和輸入上行輸出功率告警上門限的值和下行輸出功率告警上門限的值。當出現下行輸入過功率告警時， 也必須上報其他兩項信息， 并由監控中心進行告警判斷和甄別。

中國移動監控協議因將各個監控對象作為一個個體而存在的，將每個設備運行狀態封裝在各自獨立的數據塊， 如果用戶只想設置下行輸入功率告警上門限值， 則用戶只需輸入此值， 無須攜帶其他冗余的監控信息。其協議格式如下圖所示

5.5 協議告警處理機制比較

中國聯通監控協議的告警處理機制是以實時告警的方式來上報告警和告警恢復的，這在告警的及時性上是比較好的機制，但在直放站實際工作環境中常出現惡劣環境，從而導致設備的運行狀態在短時間發生頻繁切，為此上報大量的重復告警和誤告警。

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

六、結束語

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

參考文獻

[1]許奕，直放站監控規范的研究與應用，通信世界，2007年3月，第10期，20

[2].中國聯通，中國聯通CDMA直放站綜合網絡監控管理協議規范V2.0，2004，7

[3]胡憲華，吳捷，直放站與分布系統監控協議的研究與開發，電信科學，2006年第11期，26-27

篇2

乙方：_________

為了滿足寬帶網用戶使用高科技視頻通信的需要，促進中國互聯網增值業務的發展，_________ 公司推出具有國際領先水平的可視電話視頻通信業務。為維護甲、乙雙方的合法權益，雙方就甲方使用乙方提供的視頻通信服務一事，根據國內現時的相關法律、行規規定達成如下協議，以供共同遵照執行：

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

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

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

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

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

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

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

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

（4 ）乙方對硬件的缺陷或故障所負的責任僅限于在保修期內修理或調換。

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

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

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

7.為提高通信質量，乙方可能會對網絡采取擴容、調整、軟件升級等措施。乙方應按有關規定以業務公告或其他形式提前告知甲方。對因此導致甲方通信中斷、號碼更改等而造成的損失，乙方不承擔違約賠償責任。

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

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

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

11. 甲方要求停止接受乙方服務時，應在結清所有費用后終止本協議。

12. 由于乙方提供給甲方的是互聯網增值業務，因此乙方對由于互聯網的狀況引起的諸如不能接通、中斷、音像質量不穩定等不負任何責任。

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

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

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

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

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

18. 本協議的解釋權歸乙方。

甲方（蓋章）：_________

乙方（蓋章）：_________

負責人（簽字）：_______

負責人（簽字）：_______

篇3

[關鍵詞]局域網；通信協議；TCP/IP

HowTOConfiguretheCommunicationProtocolsoftheLAN

WangGuangming

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

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

KeyWords:LAN;CommunicationProtocols;TCP/IP

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

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

一、通信協議

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

1.內部協議

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

2.外部協議

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

3.選擇網絡通信協議的原則

我們在選擇通信協議時一般應遵循以下的原則：

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

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

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

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

二、局域網中常用的三種通信協議

BEUI協議

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

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

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

人們常將NetBIOS和NetBEUI混淆起來，其實NetBIOS只能算是一個網絡應用程序的接口規范，是NetBEUI的基礎，它不具有嚴格的通信協議功能。而NetBEUI是建立在NetBIOS基礎之上的一個網絡傳輸協議。

2.IPX/SPX及其兼容協議

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

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

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

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

3.TCP/IP協議

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

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

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

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

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

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

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

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

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

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

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

三、通信協議的安裝、設置和測試

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

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

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

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

四、小結

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

參考文獻

[1]阮家棟俞麗和《微型計算機網絡原理及應用》北京中國紡織大學出版社1995

[2]瞿坦《計算機網絡及應用》北京化學工業出版社2002

篇4

【關鍵詞】SPI協議;雙DSP通信;TMS320DM642;TMS320C6747

1.引言

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

圖1 典型水聲通信機的架構

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

2.SPI協議

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

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

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

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

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

3.系統硬件接口設計

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

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

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

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

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

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

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

4.系統軟件設計

硬件接口設計為實現SPI高速率傳輸創造了通道，但難以保證數據傳輸的可靠性和有效性。為此，我們設計了SPI主機（TMS320C6747）和SPI從機（TMS320DM642）通信的軟件協議。

為了能進行指令和大容量數據傳輸，并且易于對接收到的SPI數據進行實時解析，為“指令”和“數據”設計了不同的“幀”結構。

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

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

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

構建的“幀”結構如下表所示。

“指令”幀格式：

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

“數據”幀格式：

0x55A5 序號 數據長度 數據…… CRC

采用上述協議后，有效地保障了SPI主機和從機之間雙向、可靠、高速、穩定的指令和數據傳輸。

5.結論

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

參考文獻

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

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

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

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

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

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

[7]任宇飛，張相，程乃平.一種透明傳輸的雙向SPI接口的設計與實現[J].電視技術，2009，49（2）：51-54.

基金項目：福建省自然科學基金（項目編號：2013J01253）;中央高校基本科研業務費專項資金資助（項目編號：2010121062）;國家自然科學基金（項目編號：61301098）資助。

作者簡介：

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

篇5

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

1 監控系統分站統一通信協議框架

1.1 制定監控系統分站統一通信協議的目的

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

1.2 統一通信協議構架

下表1給出了監控通信協議幀的一般格式，以此為基礎我們相應的構架來對監控系統通信協議進行構建，無論是主從通信結構還是無主通信結構都能夠運用此通信協議。

表1 監控通信協議幀的一般格式

2 監控系統中心站數據通信框架

因為一致的通信協議不能馬上應用于監控系統所有的分站，而分站數據不能直接被高層的應用接收，因此監控系統接入協議必須進行專門的制定。下面羅列的類型可供監控系統中心站接入協議選擇：

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

圖1 OPC的客戶/服務器結構

圖2 對象管理架構

篇6

【關鍵詞】計算機網絡路由通信協議

隨著應用需求的增加，現代計算機網絡變得日趨復雜，網絡接入的通信設備數量迅猛增加，這就使得單IP多目通信成為現代計算機網絡的主要特點之一。為實現該通信，必須對通信數據進行路由，確保數據能夠被準確傳輸到目的地址中。

一、計算機網絡路由通信協議目標及其存在問題概述

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

二、動態路由選擇協議及其分類

動態路由選擇協議可以促使路由器對當前網絡內的各終端和路由設備生成一個明確的了解，然后按照協議要求將網絡通信數據經由最佳傳輸路徑轉發到接收端。目前常用的動態路由選擇協議存在兩種類型：一類為基于距離矢量的動態路由選擇協議，另一類為基于鏈路狀態路由的動態路由選擇協議。

2.1距離矢量路由選擇協議

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

2.2鏈路狀態路由選擇協議

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

三、改進的路由選擇協議

為綜合上述兩類路由的優點，同時盡量消除其中存在的缺陷或不足，可以設計一種主動層次多目路由協議。該協議中定義路由器只用于進行信息轉發，而與路由路徑相關的內容由容錯網關計算完成。在提升多目路由的快速收斂特性，可以將路由的拓撲結構設計為層次式結構。

具體來說，改進的路由選擇協議使用ARD協議來實現主動路由協議，利用SNMP協議來控制形成路由網絡的拓撲結構和鏈路狀態，利用容錯網關進行內部域報文通信和通信信息路由計算，利用管理網關進行外部域通信信息路由計算和IP地址管理。

四、內網和外網網關通信協議

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

五、總結

總之，在需要使用多層通信結構的計算機網絡中必須使用路由通信協議來對數據進行路由、對終端設備進行網絡部署。好的動態路由算法不僅可以增強數據傳輸的有效性、降低數據路由所帶來的資源損耗，還能夠增強路由網絡內的通信帶寬，確保各設備處于最佳運行狀態。

參考文獻

[1]羅炎炎，柳清芬，祁耀斌.淺論網絡通信中應用的動態路由選擇協議[J].沿海企業與科技，2005（5）

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

篇7

經過整個產業的努力，2016年初，充電聯盟了充電樁與電動車之間的標準協議。這極大的推動了新能源汽車的發展。然而，隨著充電網絡建設規模的不斷擴大，作為整個產業鏈的重要的兩個環節，充電樁運營商和充電樁設備制造商面臨著非常重要的問題：充電樁與運營管理平臺接口協議不一致。

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

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

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

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

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

為了推動協議的完善和應用，接下來，充電聯盟會組織相關企業進行試點應用，針對應用中發現的問題修訂協議，為協議的大規模推廣打下一個堅實的基礎。

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

篇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.

關鍵詞：遠動系統；IEC104規約；監聽；故障分析

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

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

0 引言

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

1 IEC104協議通信過程分析

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

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

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

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

IEC104協議為了確保通信的正常并在發生網絡故障時的一些超時處理方案，IEC104協議采用的超時處理方案如表1。

2 系統建模分析及實現

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

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

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

監聽系統對報文處理過程的活動圖如圖6。

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

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

3 結論

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

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

參考文獻：

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

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

篇9

關鍵詞： LabVIEW； J1939協議； 電池管理系統； 充電機； 協議測試

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

0 引 言

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

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

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

1 SAE J1939協議

J1939協議是基于CAN 2.0B制定的，協議對物理層、數據鏈路層、網路層以及應用層都進行了相關的規定。本文針對數據鏈路層的規定進行簡單介紹。

1.1 協議數據單元（PDU）

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

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

1.2 多幀傳輸機制

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

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

這個過程循環進行，直至接收者接收到全部數據包后發送消息結束應答幀TP.EndofMsgACK代表著這次多幀傳輸的結束。若發送的消息是全局消息，則所有接收者不應有任何應答，整個傳輸過程如圖2所示。

2 基于LabVIEW實現J1939協議平臺

2.1 硬件接口

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

2.2 軟件實現

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

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

2.3 J1939平臺應用效果

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

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

同理分析LabVIEW作為發送節點的情況，總線時序圖如圖7所示，LabVIEW拆分前的發送數據如圖8所示。綜上分析，利用LabVIEW開發平臺很好地實現了J1939協議。

3 通信協議測試軟件的開發

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

在已開發J1939協議基礎上進行測試軟件的開發，J1939協議提供了兩個接口：需要發送報文直接入未處理發送報文隊列、已處理接收報文出隊列供應用層使用。通信階段改變利用LabVIEW狀態機結構來實現。創建充電機接收狀態、充電機發送狀態兩個數據簇，記錄接收報文是否已被接收、發送報文是否已被發送以及發送的時間。利用單獨程序線程通過這兩個數據簇實時判斷是否有錯誤發生。

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

4 結 語

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

參考文獻

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

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

[3] 高松.淺談J1939協議在客車CAN總線中的應用[J].農業裝備與車輛工程，2005（2）：30?31.

[4] 蘇喜紅.基于J1939的汽車網絡控制系統CAN高層協議設計與實現[D].哈爾濱：哈爾濱工業大學，2007.

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

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

篇10

【關鍵詞】STM32；單片機；嵌入式；數據通信；HJ/T212

1.引言

近年來，隨著環保意識的增強，各種各樣的環保采集、傳輸、監控等設備被廣泛使用，為了指導各個城市污染源在線自動監控（監測）系統的建設，規范數據采集、傳輸、存儲和管理，保證各種環境監測儀器、監控設備、傳輸網絡和環保部門應用軟件系統之間的連通，國家環保行業制定了數據傳輸標準協議HJ/T212。

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

STM32系列單片機這些特點適合在環保數據的采集和傳輸環節作為主控MCU使用，本文介紹了HJ/T212在以STM32F103C8T6單片機為主控MCU的環保數據傳輸設備中的實現方法。

2.HJ/T212協議包組成

3.HJ/T212協議在STM32F103C8T6中的實現

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

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

STM32F103C8T6單片機接收并解析數據包后，需要根據協議的應答要求分步驟進行應答。通常收到一包完整數據包后，現場機立刻進行請求應答，然后返回操作執行結果。

4.CRC算法及其實現

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

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

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

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

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

⑤重復③和④，直至移出8位。

⑥取被校驗串的下一個字節

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

⑧這個16位寄存器的內容即2字節CRC錯誤校驗碼。

5.結束語

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

參考文獻

[1]曹圓圓.基于STM32的溫度測量系統[J].儀器儀表與分析監測，2010，1：16-18.