基于北斗短報(bào)文功能的疏浚船舶數(shù)據(jù)傳輸系統(tǒng)設(shè)計(jì)

繆袁泉，丁琪，胡知斌

（中交疏浚技術(shù)裝備國家工程研究中心有限公司，上海 200136）

0 引言

信息化是現(xiàn)代企業(yè)高效運(yùn)轉(zhuǎn)的必要條件，目前船岸數(shù)據(jù)通信是制約船舶運(yùn)行公司信息化的主要瓶頸之一。船岸數(shù)據(jù)通信可以實(shí)現(xiàn)船公司對船舶的實(shí)時(shí)生產(chǎn)監(jiān)控、技術(shù)支持、基礎(chǔ)管理。衛(wèi)星通信是最適合船舶調(diào)動頻繁、經(jīng)常遠(yuǎn)離陸基公眾寬帶通信網(wǎng)絡(luò)、需要大量傳輸實(shí)時(shí)工況數(shù)據(jù)的疏浚企業(yè)信息化工具之一。

本文研究基于北斗衛(wèi)星導(dǎo)航系統(tǒng)的RDSS（Radio Determination Satellite Service)短報(bào)文通信功能，通過北斗多卡通信終端（以下簡稱多卡機(jī)），將工程船舶實(shí)時(shí)工況信息遠(yuǎn)程傳輸至陸上數(shù)據(jù)庫的衛(wèi)星通信系統(tǒng)[1]。短報(bào)文通信是指衛(wèi)星移動終端和北斗衛(wèi)星或北斗地面服務(wù)站之間能夠直接通過衛(wèi)星信號進(jìn)行雙向的信息傳遞，通信以短報(bào)文（類似手機(jī)通訊的短信息）為傳輸基本單位，設(shè)備的短報(bào)文通信頻度及長度由授權(quán)的北斗用戶卡決定。系統(tǒng)設(shè)計(jì)使用北斗RDSS系統(tǒng)3類非加密用戶卡，該類卡最快每分鐘傳送一次短報(bào)文，報(bào)文長度為78.5 B[2]。

1 數(shù)據(jù)傳輸系統(tǒng)組成

船岸數(shù)據(jù)傳輸系統(tǒng)由船端多卡機(jī)、船端采集發(fā)送計(jì)算機(jī)、岸端北斗通信終端（以下簡稱指揮機(jī)）、岸端工作計(jì)算機(jī)、傳輸軟件等組成。實(shí)現(xiàn)由船端向岸端傳輸“船舶位置、船舶生產(chǎn)報(bào)表、疏浚過程數(shù)據(jù)、疏浚設(shè)備工況、船機(jī)設(shè)備工況、船舶管理相關(guān)文件”等信息。并實(shí)現(xiàn)部分信息由岸端發(fā)至船端。

船端多卡機(jī)是為了增大北斗傳輸數(shù)據(jù)量而專門開發(fā)的設(shè)備，可以理解為多個(gè)北斗單卡機(jī)共用1個(gè)衛(wèi)星傳輸通道的設(shè)備。多卡機(jī)在使用20張3類非加密用戶卡的前提下通過總線控制多個(gè)用戶ID輪詢，支持19個(gè)用戶ID分時(shí)發(fā)送短報(bào)文通信，1個(gè)用戶ID接收短報(bào)文通信，這樣船到岸傳輸19×78.5=1.49kB/min，岸到船傳輸78.5B/min?？紤]到傳輸編碼和校驗(yàn)的字節(jié)開銷，船到岸實(shí)際信息傳輸率大約為1.2 kB/min。

多卡機(jī)和船端采集發(fā)送計(jì)算機(jī)通過串口連接。船端采集發(fā)送計(jì)算機(jī)通過以太網(wǎng)絡(luò)采集船舶定位定向系統(tǒng)、疏?？刂葡到y(tǒng)、機(jī)艙報(bào)警系統(tǒng)、管理文件、圖片等數(shù)據(jù)，將這些數(shù)據(jù)分類、壓縮、編碼、打包后通過串口發(fā)送給多卡機(jī)。

多卡機(jī)通過北斗衛(wèi)星向其地面接收總站請求短報(bào)文服務(wù)，允許后數(shù)據(jù)通過北斗衛(wèi)星轉(zhuǎn)發(fā)至岸端指揮機(jī)，指揮機(jī)也通過串口連接岸端工作電腦。

指揮機(jī)使用秒級北斗用戶卡，最快傳送短報(bào)文1次/min。除了具有普通用戶機(jī)的所有功能外，還可監(jiān)收其下屬用戶機(jī)（不超過1 000臺）的通信信息，并向下屬用戶機(jī)通播指揮信息[3]。

岸端的工作電腦負(fù)責(zé)把指揮機(jī)收到的各種數(shù)據(jù)包解包、分類、存儲以及提供應(yīng)用程序的調(diào)用、察看和分析等功能。

2 傳輸軟件設(shè)計(jì)

系統(tǒng)核心為傳輸軟件?？紤]到疏浚工程船舶的特殊性，軟件需要解決以下問題：

1）工程船舶原有疏浚監(jiān)控系統(tǒng)開發(fā)商各不相同，信號輸出方式、信號清單差異很大，需要與它們都能正常通信，可靠獲得工況數(shù)據(jù)，并整合為統(tǒng)一的信號表[4]；

2）工程船舶類型不同，耙吸挖泥船、絞吸挖泥船、抓斗挖泥船等船型疏浚數(shù)據(jù)內(nèi)容千差萬別。同一船型的疏浚船舶主要設(shè)備配置不同，也會造成數(shù)據(jù)內(nèi)容、數(shù)據(jù)順序不同，需要分別處理；

3）能對上述信息實(shí)施分類、分級傳輸，并能在北斗短報(bào)文傳輸帶寬范圍內(nèi)達(dá)到傳輸頻率可調(diào)，內(nèi)容可選；

4）實(shí)施數(shù)據(jù)傳輸前的甄選、編輯、壓縮，減少文件和工況數(shù)據(jù)傳輸量；

5）在信號源數(shù)據(jù)刷新率范圍內(nèi)，對各類信息可以按需進(jìn)行采集密度選擇，以滿足工程數(shù)據(jù)挖掘、船位數(shù)據(jù)、潮位數(shù)據(jù)、水深數(shù)據(jù)等各類數(shù)據(jù)對信息刷新率的要求。

基于北斗RDSS功能的傳輸軟件包括船端、岸端兩部分。設(shè)計(jì)的基本思路是通過編制各船型、各主要設(shè)備信號分類傳輸表格，將所有信號分為70 B大小的傳輸表格以適應(yīng)北斗短報(bào)文長度，保證每個(gè)給定船舶有適用于自己的表格清單，并據(jù)此傳輸，岸端軟件與船端使用同樣的表格接收數(shù)據(jù)，避免對每個(gè)信號的定義都要傳輸，從而減少占用短報(bào)文字節(jié)[5]。

根據(jù)上述原則，耙吸挖泥船、絞吸挖泥船、抓斗挖泥船的通用傳輸分類表數(shù)量分別為13、14、8個(gè)，具體到各船，因?yàn)橹饕O(shè)備的配置不同，其傳輸表格為7～14個(gè)不等，具體傳輸哪些表格由岸端指令控制，即可以點(diǎn)餐式傳輸指定的內(nèi)容。傳輸軟件以高頻率采集工況數(shù)據(jù)并本地存儲，發(fā)送同一采集時(shí)間獲得的信號，保證傳輸?shù)男盘栐谠疾杉瘯r(shí)間上的一致性。當(dāng)指定傳輸?shù)谋砀裎凑紳M多卡機(jī)19張卡通信能力時(shí)，系統(tǒng)將根據(jù)剩余帶寬重復(fù)傳輸指定表格的信號，從而提高信號傳輸頻次。高時(shí)間密度的數(shù)據(jù)可用于專項(xiàng)分析疏浚工況或分析特定設(shè)備的運(yùn)轉(zhuǎn)狀態(tài)。

2.1 船端傳輸軟件

船端軟件包括采集通信、壓縮存儲、傳輸控制、多卡機(jī)通信、船端顯示等模塊。

2.1.1 采集通信模塊

采集通信模塊與疏浚監(jiān)控系統(tǒng)或重要船機(jī)系統(tǒng)通信，采集實(shí)時(shí)疏浚工況、船機(jī)數(shù)據(jù)；與其他船舶信息管理軟件通信，獲得相應(yīng)需傳輸?shù)奈募Ｄ壳吧虾：降谰止こ檀氨O(jiān)控系統(tǒng)軟件由多家疏?？刂葡到y(tǒng)集成商開發(fā)，采集通信模塊與監(jiān)控軟件之間的通信解決方案為由監(jiān)控軟件集成商提供API（應(yīng)用程序接口）函數(shù)，采集通信軟件應(yīng)適用于不同疏浚監(jiān)控系統(tǒng)，并完成對所有信號點(diǎn)進(jìn)行標(biāo)準(zhǔn)化配置。與船舶信息管理文件通信采取指定路徑的直接文件讀取方式。

采集后的數(shù)據(jù)先實(shí)施分類。船位信息、生產(chǎn)信息、疏浚機(jī)具工況、船機(jī)工況依據(jù)《中交物資設(shè)備編碼規(guī)范》、《耙吸挖泥船疏浚監(jiān)控系統(tǒng)信號源定義》、《絞吸挖泥船疏浚監(jiān)控系統(tǒng)信號源定義》、《抓斗挖泥船疏浚監(jiān)控系統(tǒng)信號源定義》劃分成幾個(gè)大類，信息管理系統(tǒng)文件也分為一個(gè)大類。暫定信息分類使用6個(gè)bit編碼，即不超過64大類。每類信息按照重要程度分為3級，以便實(shí)現(xiàn)信息分等級傳輸。

2.1.2 船端壓縮存儲模塊

船端壓縮模塊依據(jù)給定的壓縮策略實(shí)施數(shù)據(jù)/文件壓縮，壓縮后根據(jù)給定的存儲策略存儲到指定區(qū)域。

對于船位、船機(jī)工況、疏浚機(jī)具工況的數(shù)據(jù)流，高精度數(shù)據(jù)用8個(gè)字節(jié)表示，采用IEEE 754標(biāo)準(zhǔn)中的double型編碼，數(shù)據(jù)范圍在1.7E-308～1.7E+308；一般精度模擬量數(shù)據(jù)用2個(gè)字節(jié)采用科學(xué)計(jì)數(shù)法的形式表示，高12位表示數(shù)據(jù)長度，低4位表示10的指數(shù)，其中，第15位表示數(shù)值的正負(fù)號，第3位表示指數(shù)的符號；布爾型數(shù)據(jù)用二進(jìn)制位來表示，從而減少傳輸字節(jié)數(shù)。文件壓縮采用rar格式無損壓縮引擎處理。

采用SQL2008對數(shù)據(jù)進(jìn)行存儲。其中，對實(shí)時(shí)工況數(shù)據(jù)在數(shù)據(jù)庫表進(jìn)行存儲；壓縮后的文件按照上節(jié)分類原則分別存儲在本地磁盤不同路徑下，文件的路徑存儲在數(shù)據(jù)庫中。

設(shè)定歷史數(shù)據(jù)保存時(shí)間段，超出該時(shí)間段的數(shù)據(jù)自動刪除，防止長時(shí)間運(yùn)行數(shù)據(jù)庫過大造成的影響。由于監(jiān)控系統(tǒng)已經(jīng)保存上述數(shù)據(jù)，本地存儲只是為了方便糾錯(cuò)重發(fā)或指定內(nèi)容高頻次發(fā)送。采集發(fā)送計(jì)算機(jī)保存時(shí)間可以不超過1 h，其數(shù)據(jù)量約為4.8 MB。

2.1.3 船端傳輸控制模塊

船端傳輸控制模塊為北斗信息系統(tǒng)，是疏浚企業(yè)核心模塊，需要實(shí)施加密處理，授權(quán)使用。實(shí)現(xiàn)傳輸內(nèi)容、頻次控制、糾錯(cuò)控制、編碼、校驗(yàn)等功能。

根據(jù)給定的傳輸策略選擇傳輸內(nèi)容或傳輸頻率，給定的傳輸策略可以由岸端指令調(diào)整，模塊將自動判斷系統(tǒng)傳輸能力并給出反饋。傳輸內(nèi)容沒有用完字節(jié)量時(shí)，應(yīng)能根據(jù)給定的策略，反復(fù)發(fā)送指定的傳輸內(nèi)容，達(dá)到加大指定信息的刷新率的效果。

傳輸控制模塊根據(jù)傳輸不同的信號內(nèi)容，實(shí)施不同的糾錯(cuò)策略，對不同文件/數(shù)據(jù)實(shí)施重發(fā)、多次重發(fā)或舍棄操作。對于工況數(shù)據(jù)，傳輸失敗將直接丟棄。對于文件傳輸，在文件的包編碼上附加傳輸校驗(yàn)碼。傳輸失敗后，由岸端通過岸-船用戶卡發(fā)送指令重新發(fā)送，確保文件能夠恢復(fù)。

傳輸控制模塊實(shí)施數(shù)據(jù)流或超過70 B文件的切割，生成符合北斗通信規(guī)范的短報(bào)文數(shù)據(jù)包，并依據(jù)給定的編碼策略對數(shù)據(jù)包編碼；編碼策略的目的是在信息包傳輸時(shí)根據(jù)其編碼，即可知道其傳輸信息的來源、種類、數(shù)量及批次，同時(shí)盡可能少占用有效傳送字節(jié)。編碼策略決定了系統(tǒng)的容量，為保證傳輸?shù)挠行нM(jìn)行，必須再添加控制字、包編號、校驗(yàn)碼等輔助字節(jié)。每個(gè)數(shù)據(jù)由報(bào)頭、數(shù)據(jù)區(qū)、包結(jié)束符（或者包連接符）和校驗(yàn)碼四部分組成。使用發(fā)送卡ID作船舶身份識別。

每個(gè)數(shù)據(jù)包的最后一個(gè)字節(jié)用于時(shí)間標(biāo)簽及重要文件的傳輸校驗(yàn)。傳輸時(shí)同一批次傳送的數(shù)據(jù)其采集時(shí)間一致。其中傳輸校驗(yàn)用2個(gè)bit，時(shí)間標(biāo)簽實(shí)際上為批次標(biāo)識，防止多個(gè)大文件的不同信息包，因系統(tǒng)傳遞延誤造成錯(cuò)位，無法拼裝。

2.1.4 多卡機(jī)通信模塊

傳輸控制模塊依據(jù)北斗多卡機(jī)的通信協(xié)議與其通信。船端采集發(fā)送計(jì)算機(jī)通過串口與多卡機(jī)通信，多卡機(jī)給出一個(gè)設(shè)備ID，外設(shè)使用這個(gè)ID依次發(fā)送、接收數(shù)據(jù)包。具體真實(shí)使用哪個(gè)北斗用戶通訊卡，由多卡機(jī)自行分配。每個(gè)數(shù)據(jù)包的發(fā)送均會返還一個(gè)通信回執(zhí)，告訴用戶通信成功與否，便于糾錯(cuò)和重發(fā)。為保證用戶實(shí)時(shí)了解多卡機(jī)內(nèi)部卡的數(shù)量及健康狀況，便于控制傳輸節(jié)奏，多卡機(jī)定時(shí)發(fā)送所有用戶通訊信息給外設(shè)。

2.1.5 船端顯示模塊

船端顯示模塊接收并顯示岸段生產(chǎn)調(diào)度指令、氣象海浪、潮位等信息，并通過局域網(wǎng)或串口送到指定船舶上的其他工作站。系統(tǒng)使用控制指令數(shù)據(jù)包實(shí)現(xiàn)岸—船通信。通信協(xié)議為岸—船控制指令集。船—岸控制指令包設(shè)置1個(gè)字節(jié)編碼，即256種指令類型，分別對應(yīng)于生產(chǎn)指令、調(diào)度指令、氣象海浪、潮位等施工支持管理信息，及傳輸內(nèi)容控制指令。如指定只傳輸某船耙臂工況，并以盡可能高的傳輸頻次傳輸?；蛘咧付▊鬏斈硞€(gè)管理信息系統(tǒng)的文件，及用于通信控制的傳輸控制指令。

2.2 岸端傳輸軟件

2.2.1 岸端傳輸控制模塊

岸端傳輸控制模塊根據(jù)收到的數(shù)據(jù)包編碼，組裝獲得所需完整數(shù)據(jù)/文件。實(shí)施文件傳輸失敗的發(fā)送重發(fā)請求及確認(rèn)，依據(jù)編碼策略、壓縮策略依次恢復(fù)數(shù)據(jù)/文件，最后將數(shù)據(jù)/文件存儲在指定路徑。

2.2.2 岸端通信模塊

岸端通信模塊與信息中心服務(wù)器中的數(shù)據(jù)庫操作軟件通信，后者將接收到的數(shù)據(jù)/文件存儲到數(shù)據(jù)庫中。岸端發(fā)向船端的數(shù)據(jù)處理方式與船端軟件一致，不再贅述。

3 結(jié)語

經(jīng)過實(shí)船驗(yàn)證，上述船岸北斗通信系統(tǒng)較好地克服了北斗短報(bào)文通信帶寬窄、工程船舶信息復(fù)雜多樣的困難，實(shí)現(xiàn)了用戶對疏浚船舶施工數(shù)據(jù)傳輸內(nèi)容、傳輸頻度各異的需求，增加新的施工船型也只要另行編制對應(yīng)的傳輸表格即可。為解決疏浚工程船舶位置、施工信息回傳難題開辟了嶄新的途徑，擁有十分廣闊的行業(yè)應(yīng)用前景。

未來通過岸端發(fā)送指令，可以實(shí)現(xiàn)對目標(biāo)船船端跨設(shè)備類別的傳輸表格訂制，滿足管理部門的專項(xiàng)故障診斷、工藝分析或其他特殊需求。

[1] 王磊，宋蕾.利用北斗短信功能實(shí)現(xiàn)海上測量信息的回傳[J].海洋測繪，2011，31（3）：25-27.WANG Lei,SONG Lei.Equipment status information returned using compass SMS[J].Hydrographic Surveying and Charting,2011,31(3):25-27.

[2]姚作新.基于北斗衛(wèi)星短信通信方式的無人值守自動氣象站網(wǎng)[J].氣象科技，2012（3）:340-344.YAOZuo-xin.Unmanned automatic weather station network based on Beidou Satellite SMS[J].Meteorological Science and Technology,2012(3):340-344.

[3] 向貴虎，卞樹檀，劉生林，等.基于“北斗一號”衛(wèi)星系統(tǒng)的野外車輛行動監(jiān)控系統(tǒng)[J].兵工自動化，2009，28（1）：51-53.XIANGGui-hu,BIAN Shu-tan,LIU Sheng-lin,et al.Movement monitoring system of field vehicles based on satellite system of′TrionesNo.1′[J].Ordnance Industry Automation,2009,28(1):51-53.

[4] 諸葛瑋，張戟，凌穆峰.基于WEB疏浚施工實(shí)時(shí)遠(yuǎn)程監(jiān)測、回放分析系統(tǒng)實(shí)現(xiàn)[J].水運(yùn)工程，2010（11）：1-8.ZHUGE Wei,ZHANGJi,LINGMu-feng.Development to a webbased remotedredgingsupervision and playback analysissystem[J].Port&Waterway Engineering,2010(11):1-8.

[5] 李科，王智明，李勝全，等.海上導(dǎo)航信息遠(yuǎn)程傳輸監(jiān)控技術(shù)研究與應(yīng)用[J].海洋測繪，2013，33（1）：22-25.LI Ke,WANG Zhi-ming,LI Sheng-quan,et al.Research and application of thetechniquefor monitoringand remotetransmission of maritime navigation information[J].Hydrographic Surveying and Charting,2013,33(1):22-25.