王 華, 劉 冰, 劉煥敏, 段慧芬, 馬東艷

?

一種雙網實時串口通信的設計與實現(xiàn)①

王 華, 劉 冰, 劉煥敏, 段慧芬, 馬東艷

(中國衛(wèi)星海上測控部, 江陰 214431)

設計了一種跨網傳輸?shù)拇谕ㄐ跑浖? 該軟件采用數(shù)據(jù)收發(fā)雙線程機制和數(shù)據(jù)隊列線程間數(shù)據(jù)共享機制, 設計了數(shù)據(jù)通信的數(shù)據(jù)幀類型校驗、數(shù)據(jù)幀CRC校驗和數(shù)據(jù)幀幀長校驗等方法, 保證數(shù)據(jù)高效性、安全性和完整性, 通過速率測試和誤碼測試, 證明該模型實現(xiàn)了可靠、安全和高效的串口通信, 滿足了在試驗網和信息網之間實時數(shù)據(jù)通信的需要.

串口通信; 幀長校驗; 實時數(shù)據(jù)通信; CRC校驗

在飛行器測控領域隨著信息化的發(fā)展和應用, 逐漸開發(fā)和組建了不同的專用業(yè)務的內部局域網絡, 由于各個局域網的業(yè)務流不同, 為了保證其安全性, 在各局域網上進行物理隔離, 但隨著信息發(fā)展與共享的需求, 各局域網之間有一定速率數(shù)據(jù)通信的需求. 因此, 在保證安全性的情況下, 研究了雙網串口通信的方法.

1 串口通信原理

所謂“串行通信”是指數(shù)據(jù)在一根數(shù)據(jù)信號線上一位一位地進行傳輸, 每一位數(shù)據(jù)都占據(jù)一個固定的時間長度. 這種通信方式使用的數(shù)據(jù)線少, 在遠距離通信中可以節(jié)約通信成本, 當然, 其傳輸速度比并行傳輸慢. 典型地, 串口通信傳輸ASCII碼字符的[1]. 使用3根線完成: (1)地線, (2)發(fā)送, (3)接收. 由于串口通信是異步的, 端口能夠在一根線上發(fā)送數(shù)據(jù)同時在另一根線上接收數(shù)據(jù). 其他線用于握手, 但是不是必須的[2]. 文章中的每個串口通信“包”是指一個字節(jié), 其順序為開始位、數(shù)據(jù)位、奇偶校驗位和停止位. 常用的串行通訊協(xié)議有RS232、RS485及RS422等等.

在兩個串行端口通信中參數(shù)必須匹配一致, 包括波特率、數(shù)據(jù)位、停止位和奇偶校驗.

a. 波特率, 表示每秒鐘傳送的bit的個數(shù), 與距離成反比, 表示通信速度的參數(shù).

b. 數(shù)據(jù)位, 標準的值是5、7和8位, 是通信中實際數(shù)據(jù)位的參數(shù). 其設置使用在于傳輸?shù)男畔? 比如, 標準的ASCII碼是0～127(7位). 擴展的ASCII碼是0～255(8位).

c. 停止位, 表示單個包的最后一位. 典型的值為1、1.5和2位. 停止位不僅表示傳輸結束, 并且提供計算機校正時鐘同步的機會. 停止位數(shù)越多, 數(shù)據(jù)傳輸率越慢, 但不同時鐘同步的容忍度越大.

d. 奇偶校驗位, 是默認的檢錯方式. 包括: 偶、奇、高、低和無校驗位. 對于偶和奇校驗的情況, 串口會設置校驗位, 確保傳輸?shù)臄?shù)據(jù)有偶數(shù)個或者奇數(shù)個邏輯高位. 發(fā)送數(shù)據(jù)時, 如果數(shù)據(jù)是011, 那么對于偶校驗, 校驗位為0, 保證邏輯高的位數(shù)是偶數(shù)個. 接收數(shù)據(jù)時, 對“1”的個數(shù)進行校驗, 若發(fā)現(xiàn)不一致, 則說明傳輸過程中出現(xiàn)了差錯.

兩臺微機點對點常用的串口通信過程, 如圖1所示.

a. 串口初始化, 設置一致的通信參數(shù);

b. 打開串行通信端口;

c. 串行端口通信, 一端發(fā)送數(shù)據(jù)或者一端接收數(shù)據(jù);

d. 通信結束后, 關閉端口, 釋放占用資源.

圖1 串口通信過程

在不同的編程環(huán)境下, 均提供了串口通信控件和函數(shù), 在C#中, 提供了SerialPort控件實現(xiàn)串口通信, 該控件可直接對串口的各類參數(shù)初始化; 提供了backgroundWorker控件, 創(chuàng)建獨立的線程[3].

2 雙網串口通信需求分析與應用設計

2.1雙網串口通信需求分析

在飛行器測控領域中, 在試驗網中數(shù)據(jù)有一定的敏感性, 需將部分非敏感實時數(shù)據(jù)傳輸?shù)叫畔⒕W, 其首要需將非敏感數(shù)據(jù)分離, 并重點保證試驗網的安全性, 因此有以下需求:

將試驗網中的部分試驗數(shù)據(jù)單向傳輸?shù)叫畔⒕W中;

保證數(shù)據(jù)傳輸?shù)目煽啃?

保證數(shù)據(jù)傳輸?shù)膶崟r性, 其傳輸速率滿足需求;

保證數(shù)據(jù)傳輸?shù)陌踩?

2.2應用設計

根據(jù)以上需求, 雙網采用串口單向通信的方式進行數(shù)據(jù)傳輸, 其設計的軟件包括兩部分, 一是數(shù)據(jù)轉發(fā)軟件, 運行在試驗網; 一是數(shù)據(jù)接收軟件, 運行在信息網. 具體設計如圖2所示.

圖2 系統(tǒng)間信息接口

2.2.1雙網通信硬件構成

a. 數(shù)據(jù)轉發(fā)微機(運行數(shù)據(jù)轉發(fā)軟件)+ RS232串口通信卡.

b. 數(shù)據(jù)接收微機(運行數(shù)據(jù)接收軟件)+ RS232串口通信卡.

c. 2個RS232串口通信卡之間通過1.25米RS-232連接線點對點連接.

在圖2中, 試驗網中的試驗數(shù)據(jù)通過廣域網發(fā)送到本地的遠程實時通信軟件, 由其進行統(tǒng)一的數(shù)據(jù)收發(fā)后; 將接收的原碼數(shù)據(jù)包UDP組播發(fā)送給使用者, 數(shù)據(jù)轉發(fā)軟件接收該UDP組播的數(shù)據(jù)包并從串口轉發(fā)出去. 數(shù)據(jù)接收軟件從串口接收數(shù)據(jù)并進行UDP組播; 這樣從試驗網傳輸過來的數(shù)據(jù)通過數(shù)據(jù)處理和存儲, 實現(xiàn)在信息網中進行二次利用.

在需求中要求數(shù)據(jù)從試驗網向信息網發(fā)送數(shù)據(jù), 為保證試驗網的安全性, 在數(shù)據(jù)串口通信軟件設計中采用單工的通信模式, 控制數(shù)據(jù)流向.

在需求中要求數(shù)據(jù)傳輸?shù)膶崟r性和可靠性, 根據(jù)數(shù)據(jù)傳輸需求, 計算所傳輸?shù)母黝悢?shù)據(jù)流量最大不超過25kbit/s, RS-232接口通信板傳輸速率為最大支持115.2kbps(傳輸距離小于15m), 因此采用專用的RS-232接口串口通信板, 其可靠性高、性能穩(wěn)定, 理論上滿足數(shù)據(jù)實時性速率需求[4].

2.2.2軟件設計

為了滿足需求, 保證數(shù)據(jù)傳輸?shù)目煽啃浴踩约暗驼`碼率, 因此串口通信的軟件設計也尤為重要, 因此數(shù)據(jù)轉發(fā)軟件和數(shù)據(jù)接收軟件的設計如圖3所示.

圖3 優(yōu)化的串口通信軟件設計

在串口通信中, 容易出現(xiàn)數(shù)據(jù)丟幀、傳輸速率低、誤碼率高及數(shù)據(jù)傳輸發(fā)送端和接收端數(shù)據(jù)幀長不一致等問題, 因此, 在數(shù)據(jù)轉發(fā)和數(shù)據(jù)接收軟件的中, 均采用了雙線程設計, 一個接收線程, 一個發(fā)送線程, 數(shù)據(jù)收發(fā)功能明確; 在數(shù)據(jù)轉發(fā)軟件的UDP數(shù)據(jù)接收線程中增加了數(shù)據(jù)幀類型校驗功能, 該功能起到非敏感數(shù)據(jù)轉發(fā)控制的作用, 通過數(shù)據(jù)幀類型判斷, 屬于允許轉發(fā)的數(shù)據(jù), 才送入隊列通過串口發(fā)送出去, 否則不符合條件, 該數(shù)據(jù)丟棄. 另外對轉發(fā)的數(shù)據(jù)設計了數(shù)據(jù)幀CRC校驗和數(shù)據(jù)幀幀長校驗等功能, 采用數(shù)據(jù)隊列的方法存儲和共享數(shù)據(jù), 實現(xiàn)線程間數(shù)據(jù)同步, 保證數(shù)據(jù)的安全性, 防止數(shù)據(jù)丟失.

3 串口通信關鍵技術實現(xiàn)

串口通信程序采用C#.NET開發(fā)平臺, 使用SerialPort控件實現(xiàn), 在編寫串口通信的過程中將遇到的問題及解決方法, 一一進行闡述[5].

3.1串口通信幀信息校驗

對通信的可靠性檢查就需要‘校驗’, 校驗是對數(shù)據(jù)本身的檢查, 奇偶校驗碼作為一種檢錯碼雖然簡單, 但是漏檢率高. 在數(shù)據(jù)通信中用的最廣泛的檢驗差錯方法, 是一種漏檢率低得多也便于實現(xiàn)的循環(huán)冗余碼CRC(Cyclical Redundancy Check), 它是利用除法及余數(shù)的原理進行錯誤偵測(Error Detecting). 實際應用時, 該方法在發(fā)送端用數(shù)學方法計算生成一個CRC校驗碼, 在信息碼位之后隨信息一起發(fā)出. 在接收端也用同樣方法計算生成一個CRC校驗碼. 將這兩個校驗碼進行比較, 如果一致就證明所傳信息正確; 否則數(shù)據(jù)傳輸有錯誤. CRC碼是由兩部分組成, 前部分是信息碼, 就是需要校驗的信息, 后部分是校驗碼, 如果CRC碼共長個bit, 信息碼長個bit. 它的編碼規(guī)則是[6]:

① 首先將原信息碼(bit)左移位(+=);

② 運用一個生成多項式()(也可看成二進制數(shù))用模2除上面的式子, 得到的余數(shù)就是校驗碼. 模2除就是在除的過程中用模2加, 模2加實際上就是我們熟悉的異或運算, 就是加法不考慮進位, 公式是: 0+0=1+1=0,1+0=0+1=1即‘異’則真, ‘非異’則假. 具體算法如下.

3.2串口通信幀長校驗

在串口通信過程中, 由于試驗信息是按照約定的數(shù)據(jù)幀形式進行一幀一幀的發(fā)送, 數(shù)據(jù)的幀長隨著數(shù)據(jù)類型的不同而變化的, 在串口數(shù)據(jù)收發(fā)的過程中, 經常出現(xiàn)發(fā)送端數(shù)據(jù)幀長和接收端數(shù)據(jù)幀長不一致的情況, 導致數(shù)據(jù)的誤碼率直線上升; 在經過測試與分析后發(fā)現(xiàn), 是由于串口異步通信的機制, 數(shù)據(jù)按位傳輸, 發(fā)送端一次性發(fā)出的數(shù)據(jù), 接收端接收線程檢測到有數(shù)據(jù), 觸發(fā)串口接收, 但接收的數(shù)據(jù)長度不定無法控制, 就導致一幀數(shù)據(jù)可能出現(xiàn)分批接收的情況, 或者出現(xiàn)多幀數(shù)據(jù)一次性接收的情況.

為了解決這個問題, 于是設計在數(shù)據(jù)幀發(fā)送前添加了數(shù)據(jù)幀長校驗, 對CRC校驗后的數(shù)據(jù)進行二次封裝, 添加幀長校驗信息, 其幀長校驗信息格式如圖4所示. 這樣通過幀長校驗信息, 在接收端進行幀長校驗, 將分批接收的數(shù)據(jù)或者一次性接收的多幀數(shù)據(jù)進行解析提取和恢復.

圖4 幀長校驗格式

圖4中, 將幀頭設計為2個字節(jié), 幀頭內容可以設置為任意與數(shù)據(jù)域內容不沖突的字符或數(shù)據(jù), 在雙網串口通信中, 采用了不使用的特殊字符'$'作為幀頭標識. 幀長為校驗后的數(shù)據(jù)字段與CRC校驗碼長度之和, 根據(jù)實際應用情況將幀長字段設置為2字節(jié), 數(shù)據(jù)類型為Int16. 這樣通過設計的幀長校驗格式, 在接收端進行幀長校驗.

如圖5所示, 接收端幀長校驗步驟:

① 在串口接收線程中, 串口等待接收數(shù)據(jù), 判斷如果接收端口收到數(shù)據(jù)字節(jié)數(shù)大于4字節(jié), 則開始接收數(shù)據(jù), 并將其存儲于待解析數(shù)據(jù)隊列, 進入步驟2; 否則繼續(xù)等待;

② 將待解析數(shù)據(jù)隊列中的數(shù)據(jù)進行數(shù)據(jù)幀解析和提取. 首先判斷幀頭標識是否為‘$’, 如果不一致, 表示該幀數(shù)據(jù)幀頭缺失, 數(shù)據(jù)丟棄; 否則到步驟3;

③ 取首幀幀長字段值, 判斷是否與隊列數(shù)據(jù)長度是否一致; 如果一致, 表示隊列中只有1幀數(shù)據(jù), 可將該幀數(shù)據(jù)直接解析出來, 并從待解析數(shù)據(jù)隊列刪除; 如果大于隊列數(shù)據(jù)長度, 表示待解析隊列中, 1幀數(shù)據(jù)未接收完整, 轉入步驟1; 如果小于隊列數(shù)據(jù)長度, 表示待解析隊列中包含多幀數(shù)據(jù), 則轉入步驟4;

④ 通過幀頭‘$’和幀長字段值, 循環(huán)解析提取單幀數(shù)據(jù), 按照步驟3直至數(shù)據(jù)解析完畢; 跳轉至步驟1, 串口繼續(xù)等待數(shù)據(jù)接收.

圖5 數(shù)據(jù)幀長校驗流程

3.3雙網串口通信性能測試

在文章設計的雙網數(shù)據(jù)通信中, 數(shù)據(jù)轉發(fā)軟件中設計了UDP數(shù)據(jù)接收線程和串口發(fā)送線程, 在初始代碼實現(xiàn)后, 進行串口通信速率測試過程中發(fā)現(xiàn)當發(fā)送數(shù)據(jù)按照200幀/s, 幀長為60字節(jié), 總流量約93.8kbit/s, UDP接收及串口收發(fā)兩端均正常, 并且串口收發(fā)無延時. 當按照300幀/s, 幀長為60字節(jié), 總流量約140.7kbit/s, UDP接收端開始出現(xiàn)數(shù)據(jù)丟幀的情況, 串口數(shù)據(jù)收發(fā)和UDP端相比, 出現(xiàn)明顯的數(shù)據(jù)時延. 經測試分析, 接收UDP組播數(shù)據(jù)時, 創(chuàng)建UDP端口時, UDP端口接收數(shù)據(jù)量受限于接收緩沖區(qū)的大小, 因此在UDP端口初始化時, 需要設置接收緩沖區(qū)的大小. C#中代碼如下.

這樣優(yōu)化后, 通過不同速率測試, 極限情況下按照2000幀/s, 幀長均為40字節(jié), 總流量<625kbit/s的情況發(fā)送數(shù)據(jù), 數(shù)據(jù)收發(fā)均正常, 消除了UDP端口數(shù)據(jù)接收丟幀的情況; 由于串口通信速率遠低于該速率, 與UPD接收數(shù)據(jù)速率相比有明顯時延, 并隨著時間數(shù)據(jù)差距逐漸增加, 通過使用隊列存儲數(shù)據(jù), 消除了接收與發(fā)送之間速率差造成的丟幀情況.

誤碼率是最常用的數(shù)據(jù)通信傳輸質量指標, 用來衡量數(shù)據(jù)在規(guī)定時間內數(shù)據(jù)傳輸精確性, 表示在一定時間內收到的數(shù)字信號中發(fā)生差錯的比特數(shù)與同一時間所收到的數(shù)字信號的總比特數(shù)之比, 也稱為“誤比特率”. 在雙網串口通信中, 通過數(shù)據(jù)幀類型校驗、數(shù)據(jù)幀CRC校驗和數(shù)據(jù)幀幀長校驗, 增強了串口數(shù)據(jù)通信可靠性、完整性及安全性. 試驗網誤碼率要求為低于10E-6, 按照此要求進行了測試, 詳見表1, 測試結果符合要求.

計算方法: 誤碼率=接收出現(xiàn)差錯的比特數(shù)/總的發(fā)送的比特數(shù).

表1 誤碼測試結果

4 結語

本文設計的雙網串口通信軟件, 通過數(shù)據(jù)收發(fā)雙線程機制和數(shù)據(jù)隊列線程間數(shù)據(jù)共享機制的應用, 有效提高了數(shù)據(jù)通信的高效性, 通過數(shù)據(jù)通信的數(shù)據(jù)幀類型校驗、數(shù)據(jù)幀CRC校驗和數(shù)據(jù)幀幀長校驗等方法, 有效保證數(shù)據(jù)通信的可靠性和完整性, 經速率測試和誤碼測試, 證明該設計模式實現(xiàn)的跨網串口數(shù)據(jù)通信可靠、安全和高效, 滿足了今后在試驗網和信息網之間實時數(shù)據(jù)通信的需要.

1 李江全,聶晶,梁習卉子,等.單片機串口通信及測控應用實戰(zhàn)詳解.北京:人民郵電出版社,2014.

2 李江全.Visual C#.NET串口通信及測控應用典型實例.北京:電子工業(yè)出版社,2012.

3 鄭阿奇.Visual C#網絡編程.北京:電子工業(yè)出版社,2011.

4 王小科,王軍.C#開發(fā)實戰(zhàn)1200例.北京:清華大學出版社, 2011.

5 王小科,趙會東.C#程序開發(fā)范例寶典.北京:人民郵電出版社,2012.

6 呂曉敏.嵌套循環(huán)冗余碼(CRC)的優(yōu)化與檢驗[碩士學位論文].杭州:浙江大學,2012.

Design and Implementation of Real-Time Serial Communication on Networks

WANG Hua, LIU Bing, LIU Huan-Ming, DUAN Hui-Fen, MA Dong-Yan

(China Satellite Maritime Tracking and Control Department, Jiangyin 214431, China)

This paper presents the design of a serial communication software cross network transmission, the software uses the data transceiver double thread mechanism and data queue data sharing mechanism between the threads, in order to ensure the data security efficiency and integrity, those methods are designed on the data communication, such as data frame type check, data frame CRC check and data frame length check. Through the test, the rate and bit error test, it proves that this model to realize serial communication is reliable, safe and efficient, to meet the future real-time data communication between the mission network and the information networks needs to be.

serial communication; data frame length check; real-time data communication; CRC check

2016-06-13;

2016-07-25

[10.15888/j.cnki.csa.005642]