柯秋立，蘇凱雄
（福州大學 物理與信息工程學院，福建 福州 350002）
摘要：為了對北斗衛星無線電測定業務(Radio Determination Satellite Service，RDSS)報文與衛星無線電導航業務(Radio Navigation Satellite Service，RNSS)報文的控制實現功能集成，設計一種針對北斗用戶終端模塊的軟件系統。基于前后臺分離的設計思想來構架該軟件，即后臺線程負責使用串口與用戶終端模塊通信,包括對RDSS/RNSS數據的接收解析和對RDSS數據的封裝發送；前臺用戶界面完成數據的可視化，并實現靈活的人機交互。前后臺線程之間采用并發技術實現通信數據的快速處理。
關鍵詞：RDSS；RNSS；集成; 控制
中圖分類號：TN927+.2文獻標識碼：ADOI： 10.19358/j.issn.1674-7720.2017.10.005
引用格式：柯秋立，蘇凱雄.北斗通信終端軟件的設計與實現［J］.微型機與應用，2017,36（10）：15-17,22.
0引言
北斗衛星導航系統作為后起之秀，相關應用等待挖掘，具有很大的市場潛力。鑒于GPS的應用經驗，在北斗一代系統導航終端的市場化過程中，有北斗系統RDSS業務與GPS RNSS業務相結合的導航終端案例，并且北斗二代系統也實現了與GPS類似的RNSS業務［1］，因而結合了RDSS業務與RNSS業務的終端軟件將會在北斗導航系統的應用過程中發揮出巨大作用。
本文針對此需求，設計一種控制軟件系統，對北斗RDSS、RNSS綜合業務進行報文控制，包括數據通信、授時、終端移動數據獲取等功能，并且具有較好的人機交互效果。
1北斗衛星導航終端系統概述
如圖1所示，一個完整的北斗衛星導航終端系統，主要由北斗用戶終端模塊（該模塊同時具有北斗一代的RDSS業務功能與GPS、北斗二代的RNSS業務功能）、Windows平臺、后臺數據處理線程、人機界面四個部分組成。整個北斗導航終端系統的功能主要是RDSS/RNSS數據幀的接收解析與封裝發送。數據幀接收過程：北斗用戶終端首先將天線接收到的北斗信號經過模塊內部的信號處理，轉換成串口數據并輸出到PC。串口數據進入PC后由后臺線程根據幀協議解析，得到用戶應用數據。該應用數據將被人機界面進行可視化處理。數據幀發送過程：用戶在人機界面發送命令時，該命令對應的應用數據被后臺線程封裝成協議幀并輸出到串口。北斗用戶終端將得到的串口數據經過內部信號處理后，通過天線發送出去。
2軟件系統實現
軟件系統的設計主要由兩部分組成：后臺線程設計和用戶界面設計。下面針對這兩部分的具體實現做詳細闡述。
2.1后臺線程實現
后臺線程的設計主要涉及RDSS/RNSS協議幀的接收、解析算法，解析與顯示快速響應算法。算法涉及RDSS/RNSS兩種報文，基于兩種不同的協議規范，一種是北斗用戶機接口協議（4.0），另一種是NMEA0183協議。
2.1.1用戶接口協議
用戶接口協議規范了通信應用數據幀的格式。北斗一代接口數據傳輸協議（4.0）在該控制軟件中主要用于規范北斗通信數據和定位數據，而NMEA0183協議主要用于規范衛星的位置數據和終端設備的移動數據。
北斗用戶機接口協議（4.0）如圖2所示。“用戶地址”是指作為發送方的北斗卡號碼，而接收方的北斗卡號碼被包含在“信息內容”字段中。
由北斗用戶機接口協議（4.0）可知，該協議數據幀是以字節為單位來表示信息，所以要將該數據幀原有的字節類型轉換為方便計算機處理的基本數據類型［2］。
北斗用戶機接口協議（4.0）中，在北斗終端設備之間進行數據通信的方式有“代碼”、“漢字”兩種。在北斗終端設備實際通信過程中，當通信數據出現中英文數字混合的情況時，應選擇“代碼”方式發送；如果單純發送數字，由于數字的范圍是0~9,為了更有效地利用有限帶寬，可以在“代碼”通信方式中進行拓展，用4 bit來表示一個數字，而不是原來ASCII規范的1 B來表示一個數字。
NMEA0183協議（National Marine Electronics Association ）是為海用電子設備制定的標準格式，定義了接收機輸出信息的標準。該協議用逗點隔開數據流，數據流長度為30~100字符不等，通常以每秒間隔選擇輸出［3］。常用的NMEA0183協議語句功能如表1所示。
2.1.2數據接收算法
數據幀接收模塊的輸入為字節數據流，模塊通過不斷地讀取串口緩沖區，經內部處理，輸出完整的協議幀語句。數據接收模塊的內部流程圖如圖3所示。
由于RNSS（北斗二代、GPS）數據幀采用NMEA0183協議規范，RDSS（北斗一代）數據幀采用北斗用戶機接口協議（4.0）規范，因而數據幀的接收需要適配兩種協議規范。
根據圖2北斗用戶機接口協議（4.0）規范，該類數據幀的完整接收策略為：接收方先接收該幀的長度數據，作為該幀數據量大小的標準；然后，接收幀體并計數，當計數值與長度數據相等時就表示該幀接收完整。
根據NMEA0183協議規范，該類數據幀的完整接收策略為：接收到幀頭“$”時表示有效數據開始，一直接收，直到收到幀尾“\\r\\n”時表示一個數據幀結束。
2.1.3數據解析算法
數據解析涉及北斗用戶機接口協議（4.0）和NMEA0183協議，而且由于兩類數據流都是由同一個串口來進行數據通信，因而數據解析時，算法必須適配兩種協議。
部分數據解析的算法流程圖如圖4所示。
解析即在數據幀里提取相應字段的信息并顯示。首先需要將數據幀從字節流形式通過ASCII規范轉換為字符串形式以便編程處理［4］。將數據幀轉換為字符串形式后，利用編程語言的字符串分割方法便可以很容易地得到各個字段的應用數據信息。
對于通信信息“$TXXX”、時間信息“$SJXX”、定位信息“$DWXX”、移動數據“$RMC”直接將應用數據交付用戶界面；對于有關可見衛星編號、衛星俯仰角、信號載噪比的“$GSV”語句，需要將衛星編號與其俯仰角或載噪比等數據組合成鍵值對再交付用戶界面，以便于該數據在柱狀圖、星座圖上顯示。
2.1.4快速響應方法
數據接收與數據解析，這兩個流程之間的同步形式直接決定了軟件響應的速度。該軟件將這兩個流程分別設計成兩個獨立的線程，并且采用緩沖技術，極大地提高了響應速度。
首先，在內存空間開辟n個緩存區。
之后，數據接收線程將完整的數據幀填入緩存區1。緩存區1填完之后，數據接收線程將新的完整數據幀填入緩存區2。重復這個過程直到最后一個緩存區n被填完，又重新開始填充緩存區1。數據接收線程將一直循環這樣的流程。
與此同時，數據解析線程首先判斷緩存區1是否填滿，如果已經填充完成，那么就將該數據幀進行解析；如果還沒完成，那么等待。緩存區1的數據幀解析完成之后，立刻又對緩存區2的數據幀進行解析。直到最后一個緩存區n的數據幀被解析完，又重新從緩存區1開始解析數據幀。數據解析線程將一直重復這樣的流程。
2.2前臺界面設計
用戶界面的輸入主要有“定位申請”和“通信申請”命令，而接收的信息主要有用戶通信信息、用戶移動數據（速度、經緯度等）和衛星數據（衛星數、衛星俯仰角等）。本次用戶界面設計采用Visual Studio 2010為開發工具。利用Windows Form框架［5］將解析得到的應用數據如衛星信號載噪比數據、衛星俯仰角數據在柱狀圖、星座圖上進行顯示，而對于其他簡單的應用數據，則使用文字顯示。最終得到如圖5所示界面。
3軟件系統測試
本次軟件設計的測試平臺是PC Windows操作系統環境，北斗終端用戶機采用FB3511。該軟件將對用戶機的報文進行控制處理。運行軟件，待鎖定北斗衛星信號后開始進行測試。
(1)定位功能功能測試
按下“單次定位”按鈕，“北斗報文顯示”框給出經緯度信息，如圖6。輸出的經緯度信息與測試地經緯度一致，表明RDSS定位報文控制功能正確實現。圖中，“單次定位”命令未能及時響應，這是由于該北斗卡限制報文發送頻度為60秒所致。
(2)通信功能測試
在“收方地址”填入本機卡號307577，即發給本臺設備。在信息發送框填入“你好，北斗 hello BD”，在“北斗報文顯示”框里面就會收到該信息，如圖7。收發信息一致，表明RDSS收發報文功能正確實現。
(3)設備移動信息功能測試
設備的移動數據由北斗衛星不斷地發送到用戶終端設備，如圖8。授時時間符合北京時間，定位衛星數、視野衛星數等與接收的報文數據一致，設備移動信息包括対地速度與航向與設備實際情況一致，表明RNSS報文解析功能正確實現。
4結論
該軟件系統采用了Windows Form框架和多線程并發技術進行軟件設計，合理規劃各個數據處理流程的分工，將數據處理的負荷合理分配到各個部分。實際測試表明，該軟件能夠對RDSS/RNSS兩種協議報文進行可靠、準確的控制，做到快速響應，為后續的軟件應用研究奠定基礎。
參考文獻
［1］ 黃建華.北斗RDSS機制下的導航地圖更新設想及實踐［J］.測繪通報,2012(5):44-46,49.
［2］ 文斌,寧志強,陳愛萍.基于“北斗一代”的ZigBee無線網關設計［J］.電訊技術,2011,51(9):92-95.
［3］ 朱炳瑜,肖純賢,陳永虎,等.智能車載系統的設計［J］.南開大學學報(自然科學版),2011,44(6):14-17.
［4］ 薛雅娟,陳維鋒,郭勇,等.C# .NET環境下GPS OEM板接收機數據的提取［J］.成都信息工程學院學報,2006,21(5):645648.
［5］ 林淑真,楊秀芝,蘇凱雄,等.基于Web的鋰電池組管理系統［J］.微型機與應用,2015,34(21): 21-23,33.