中船航海科技有限責任公司 李松霖 胡春洋 王鴻顯 鄭鵬宇
由于船舶自動化程度的提高,各種傳感器也隨之增加。為提高操船人員的工作效率,而自然地產生了信息綜合顯示需求,因此在上世紀60年代末誕生了第一代的綜合船橋產品——挪威Norcontrol公司的“數據橋”,該系統能將導航、操舵、雷達目標等信息進行綜合集中顯示。它一經面世就得到廣泛關注,各航運大國也開始研制自己的船橋系統。后來隨著自動操舵儀、電子海圖、網絡通訊、計算機技術的引入,船橋系統開始步入快速發展的道路。
1996年,IMO通過決議MSC.64(67),給出了綜合船橋系統的定義及性能標準:船橋系統由多個互聯互通,但又功能獨立的子系統組合而成,它通過工作站不僅能集中顯示傳感器信息,還能對其發出控制指令,其設計目的在于提高船舶航行安全性及管理效率。船橋系統需要實現以下功能中的兩種或者更多:(1)航路規劃、航路監視、航跡控制;(2)通訊;(3)機械控制;(4)裝貨、卸貨、克令吊控制;(5)安全保障。
總的看來,綜合船橋系統的發展呈現出模塊化、標準化、網絡一體化的趨勢。
當前我國的船橋系統正處于發展過程中,各船舶總體所也陸續開展了相關的研發工作,但是因為相關設備如ECDIS、導航雷達、自動舵、導航傳感器等分別由不同的設備廠家獨立研制,缺乏統一的模塊化、標準化設計,互操作接口沒有做到開放化、網絡化,因此在進行系統集成時有接口對接困難,設備間的連接關系復雜、不易維護,缺乏調試手段等問題,從而導致項目周期變長,維護成本高。所以,亟需對船橋系統尤其是軟件系統進行總體設計,使系統內設備具有統一的互聯互通接口,加強系統集成能力,提高開發、聯調和維護的效率,降低成本。

圖1 綜合船橋系統體系結構
目前,國際上比較優秀的船橋系統有: Sperry的VisionMaster FT TotalWatch、Raytheon的Synapsis、Kongsberg的K-Bridge、Kelvin Hughes的MantaDigital、Furuno的Voyager。這些船橋系統普遍采用圖1所示的體系結構,都是以工作站為核心,集成ARPA雷達、ECDIS、CONNING的多功能顯示(MFD,Multi-Function Display),并對傳感器進行集中訪問及控制。多個工作站可互為備份,但是每臺工作站都有一個主功能,并為此提供相應的人機接口。船橋系統主要通過雙冗余網絡進行數據交換,但是重要的控制信息,比如操舵、操車的信號要通過CAN總線傳遞。傳感器則通過CAN/串口通道連接到統一的接口適配器,轉換為網絡數據分發給各工作站。
與綜合船橋系統相關的標準主要由四個組織制定:國際海事組織IMO,國際電工委員會IEC,國際航道測量組織 IHO,美國國家海洋電子協會NMEA。IMO以會議決議、通函的形式通過各項航海公約及設備標準,IHO 則負責制定電子海圖數據(ENC)相關的標準,IMO和IHO還成立了ECDIS協調小組。 IEC則以二者的標準為依據,對系統或設備擬定進一步的試驗及檢測方法。NMEA制定的接口標準是用來傳遞GPS定位數據的,而由于GPS在船舶導航領域的巨大成功,該標準也因此被IEC采納,廣泛應用于船用導航設備間接口通訊。
IEC標準具有良好的可操作性,是各大船級社型式認證的主要依據,常用的船橋系統IEC標準如表 1所示。

表1 常用IEC標準及其依據
船橋系統主要信息通道類型有:串口、CAN、以太網。
串口傳輸性能最差,但是它有著成本低廉、技術成熟、便于施工的特點,目前仍有較為廣泛的應用。
CAN總線可靠性最高,但是兼容性、可擴展性較差。由于每個節點上都需要一個控制器來控制收發,所以在編程中都需要SDK的支持。其可靠性保證機制是針對每一個數據幀,對超出8字節的數據比如雷達圖像,要保證傳輸可靠性就需要進行應用層編程。此外,總線采用仲裁機制避免沖突,以廣播的方式發送數據,導致帶寬利用率不高,而且隨著節點數量的增加,帶寬利用率會越來越低,實時性也會變差。
以太網具有兼容性好、易于擴展的特點,但是在網絡負載大的情況下,以太網傳輸會出現丟包現象,可靠性比CAN總線要差,但有很多提高可靠性的辦法。比如IEC61162-450規定了報文的“標簽塊(TAG BLOCK)”中應包含報文計數器,用于檢測丟包現象,并還規定了應采用“圖像發送-應答”的方式來保證在圖像發送失敗的情況下重新傳送圖像。此外,還有增加網絡帶寬,加裝專門的視頻網絡等方法。
由于成本方面的考慮,商船船橋系統一般采用串口、CAN總線、以太網等多種方式混合組建網絡。在軍用艦艇上,出于數據共享、互備互切、快速部署、方便擴展的需求,導致艦橋系統的性能升級主要是以軟件更新換代的形式來體現,而軟件多以網絡作為主要信息通道,所以艦橋系統的發展呈網絡一體化趨勢。比如美國海軍新型多任務驅逐艦DDG-1000的關鍵技術之一全艦計算環境(TSCE[1]),它具有3 層結構:核心層、適配層和表示層。核心層負責提供統一的計算資源;適配層通過分布式適配處理器DAP收集傳感器、武器、機電設備等前端設備信息并發送到全艦主干網上;表示層的顯示終端具有靈活部署、人機交互友好的優點,只具備有限的運算性能。顯示終端負責程序的輸入與輸出,后臺大部分運算在核心層完成,從而實現了計算與顯示的分離。
綜合船橋軟件應具有統一的數據收發接口,并能動態調整接收報文的解析方法和發送報文的組裝方法,能處理串口、CAN、網絡等不同通道的數據,能檢測信息交互狀況;具備高速的動態繪圖能力;具備統一的核心模塊,有良好的可擴展性,可衍生出多樣化的應用軟件。軟件在.Net平臺上采用C#[2]語言進行開發。
根據上述功能需求,以及各模塊間相互獨立,數據處理與具體業務分離的原則,將通用型船橋系統軟件劃分為三層:基本數據層、業務層、UI層,軟件結構如圖 2所示。
基本數據層負責報文數據的收發,并包含一個用于構建UI界面的基本控件庫。

圖2 通用型綜合船橋系統軟件結構圖
業務層內的各模塊封裝了綜合船橋系統各項業務的具體實現。基本數據層和業務層的模塊基本都是封裝好的動態鏈接庫(DLL),對外提供API接口。
UI層包含綜合船橋系統所有的軟件產品,每個產品是獨立的可執行程序,通過調用統一的底層模塊獲得了一致的數據接口和業務邏輯,并根據每型船舶的具體需求再開發相應的軟件界面(如圖 3所示),這些軟件雖然界面不同,但是共享同一個報文解析和處理模塊,通過船橋專用調試工具對信息通道連接參數和報文解析方法進行相應的配置。針對不同型號船舶的綜合船橋體系結構差異,可以利用接口適配程序將傳感器信息轉化為統一的網絡報文,使體系結構的差異限制在數據采集層,減輕其他應用程序的開發量。

圖3 不同型號船舶狀態監控軟件界面外觀比較
在綜合船橋系統數據傳遞過程中,信息傳輸通道(信道)、報文(分為接收報文和發送報文)、信號點是三個主要構成元素,三者的關系如圖4所示。

圖4 綜合船橋系統數據傳遞鏈
接收報文以字節數組的形式沿信道傳遞,當其符合預設特征時,將被揀選出來進行解析,解析方法由多個解析器串聯而成,解析結果將以ID為索引在信號點倉庫中尋找存放位置。信號點按組態軟件的常用分類方法分為模擬量、開關量、報警量。
圖5展示了一組解析器的工作過程:它由6個解析器組成,用于解析一個11字節長的報文,每個解析器的解析結果會更新至對應的若干個信號點。

圖5 報文解析方法
報文組裝是報文解析的逆過程,按照預設的模板組裝,組裝方法由多個組裝器串聯而成。對每一個字節或是填寫固定值,或者是從信號點倉庫中按ID檢索相應的信號點值填入相應的字節中。發送報文組裝完成后,再沿著預定的信道發送出去。
由于底層顯卡硬件機制的限制,繪制對象的數量會影響繪制的效果,數量多會導致畫面更新的幀數低、畫面閃爍的現象。在一副航行態勢圖像中,包含數以千記的海圖物標、運動目標、雷達視頻等對象,故在屏幕上直接繪制所有對象的方法無法滿足高速實時的要求。
要解決這一問題:(1)需減少顯存中繪制對象的數量;(2)需提高對象進入顯存的速度。針對此,系統采取了雙緩沖圖像結合顯存快速拷貝的方法。
在實際開發的時候,利用了圖層來管理要繪制的對象,底圖為海圖數據處理模塊生成的海圖背景層,其上依次放置透明態勢圖層,每次繪制時從下至上將所有圖層繪制到緩沖圖像上(見圖 6)。整幅態勢圖像的繪制頻率要等于刷新率最高的圖像頻率:如果不疊加雷達視頻圖層,態勢圖像的刷新率就是0.5Hz,如果疊加,刷新率需提高到20Hz。

圖6 繪制航行態勢圖像
將船橋系統軟件進行模塊化設計之后,不僅提高了軟件的開發和維護效率,而且利用基礎模塊可以針對不同的使用人群靈活地開發出新的軟件產品:(1)型號產品的開發、測試周期縮短了80%;(2)可為項目經理快速開發原型產品;(3)可為調試人員開發調試工具;(4)所有的船橋系統軟件具有統一的數據傳輸接口,節省了系統內部接口聯調的時間。
目前,軟件是基于.Net平臺開發的,采用了GDI/GDI+的繪圖技術,只能運行在Windows系統上。由于Windows固有的缺點,軟件實時性、穩定性較差,繪圖效率不高,所以未來可以考慮基于QT平臺進行開發,并采用OpenGL技術進行繪圖,以解決上述缺陷。
[1]董曉明,馮浩,石朝明等.美海軍DDG-1000全艦計算環境體系結構探析[J].中國艦船研究,2012,7(6):815.
[2]李銘.C#高級編程[M].北京:清華大學出版社,2014.