智能船舶集成平臺數據采集技術研究與實踐

林　晨，　周曉梅，　王　敏

(中遠海運科技股份有限公司，上海 200133)

0　引　言

智能船舶概念最早起源于E-Navigation[1-2]，E-Navigation對智能船舶概念的正式定義為：通過信息化的手段，對船上和岸上的海事信息進行協調一致的收集、整合、顯示及分析，以達到船舶安全、經濟航行和環境保護的目標。中國船級社以E-Navigation對智能船舶概念的定義為依據制定了《智能船舶規范》，它的構建基于E-Navigation對智能船舶概念的定義的核心，即船-船、船-岸和岸-岸間的信息流和數據流[3]，而具備模塊化和集成化的智能集成平臺搭起了船-船、船-岸的通信鏈路，是實現信息流和數據流的有效方法[4]。

要實現智能集成平臺，對各子系統的數據進行采集是第一步。各子系統所生成數據的數據結構、存儲方式及生成頻率等方面不盡相同，需尋找一種靈活有效的方式對這些系統進行集成，集成方式是既不影響子系統本身的運行，又能提升平臺開發的效率。對現有的集成方式進行分析和比選，提出采用企業級服務總線技術實現對異構子系統的數據采集。

1　船舶數據采集的研究現狀

在船端，現有最典型的對數據進行采集的系統是綜合船橋系統(Integrated Bridge System，IBS),該系統集中獲取傳感器信息，將有關導航、駕控、避碰和監視等分散設備的功能從信息融合及人機工程的角度進行集成。以Kongsberg公司開發的最新一代的船橋系統K-Bridge Integrated Navigation為例，它利用局域網將所有系統連接起來，將導航傳感器數據、船載航行數據等通過網絡分享給IBS中的所有單元(雷達系統、電子海圖與信息系統及中央駕控系統)。在這種傳統的數據采集方式中，平臺/船載和設備/子系統之間采用點對點的方式進行通訊，耦合大，且為后期的更新帶來不便，而且作為數據源的各系統之間缺乏聯動性，數據封閉[5]形成了數據孤島，不利于對船端數據的綜合利用。中國船級社提出的《智能船舶規范》中，智能集成平臺作為規范中規定的智能船舶7個重要組成部分之一，可實現數據的采集和統一存儲，被整合的數據可有效解決數據孤島的問題，為數據分析及智能應用等功能提供基礎數據。

2　智能集成平臺

2.1　平臺概述

圖1　智能集成平臺系統總體結構

智能集成平臺是船上數據與應用統一集成的平臺，能整合船上現有的信息管理系統及后續新增系統，實現對船舶的全面監控和智能化管理，并與岸基實現數據交互[6]。其系統總體結構見圖1，智能集成平臺軟件由7部分組成，以下針對數據采集部分展開研究和實踐。

2.2　關鍵問題及解決方案比選

由于船端集成平臺需接入多個異構的子系統或平臺，針對不同子系統的數據接口類型，需采取不同的傳輸協議。比如，硬件設備直接通訊時，需采用Modbus等協議來進行數據采集；與需長連接的應用系統通訊時，采用傳輸控制協議(Transmission Control Protocol, TCP)；某些應用以web service技術開放數據接口，則需要采用超文本傳輸的協議(Hyper Text Transfer Protocol, HTTP)來獲取數據；以文件形式存儲的數據需通過文件傳輸協議(File Transfer Protocol, FTP)傳遞；對數據庫的訪問，需通過數據庫連接(Java Data Base Connectivity, JDBC)協議。如何有效地整合多協議異構系統是實現數據采集功能所面對的主要問題。

針對多協議異構系統整合的問題，主流的指導思想有企業應用整合(Enterprise Application Integration，EAI)和面向服務的軟件架構(Service Oriented Architecture，SOA)。

EAI的中心思想是制定統一的數據規范和接口定義，使開發者在整合異構系統或是開發新的功能系統時，只需開放遵循接口定義的數據接口，由平臺來完成不同系統之間數據的轉換和傳遞。EAI傳統的集線器/Spoke集線器結構見圖2。Hub/Spoke架構是星型拓撲結構，由處于系統中央的Hub和連接在Hub及應用系統的多個適配器組成。適配器在Hub和應用系統之間，進行數據格式的轉換與傳輸。適配器將應用系統的數據信息轉化為Hub可識別的格式并傳遞給Hub, Hub通過消息代理管理消息路由，并將這些來自不同應用系統的數據消息按其要求的路由規則傳遞給目標應用系統的適配器。

SOA將被整合的系統視作提供一定功能的服務，可根據需求編排這些服務。當出現新的服務需求時，不需要從零開始實現，只需將已有的服務進行編排裝配來實現新業務。SOA需解決異構服務接口之間的互聯互通問題,兼容各種已有的數據和接口標準，連接已有軟件和系統。為實現上述功能，開發了企業服務總線(Enterprise Service Bus，ESB)，ESB是一個中間件技術與可擴展標記語言、Web Service等技術結合的產物，是連接服務的中樞，各項服務之間不直接進行交互，而是通過ESB交互。服務與總線之間的數據接口是通用和中立的，獨立于實現服務的硬件平臺、操作系統和編程語言。ESB的結構見圖3。

EAI和SOA都建立了統一的數據和接口定義，方便連接各異構系統。他們主要的區別在于，SOA架構中任何一種接口、通訊及協議都是遵循相應的國際標準，如標準描述語言、發現協議和消息協議等；EAI則大多使用基于需求定制的私有標準，其優點是可在一定程度上減輕EAI中間層對應用系統消息翻譯轉換的壓力，在應用系統較少的情況下可提高EAI的整體性能，但其同時也為系統整合的靈活可擴展性帶來損失，當平臺引入新的應用系統或當某個應用系統需做比較大的改動時，整個EAI的適應性將變得十分脆弱。

圖2　EAI集線器結構

圖3　ESB結構

在系統較少的情況下或是系統集成的早期階段，采用私有標準的EAI會體現出性能高及實現難度低等優點。但在需求不斷更新，新引入的系統不斷增多，系統的整合難度將因為標準的不統一而呈指數級上升。

綜上所述，EAI雖然在某些方面存在一些優點，但是從長遠角度來看，遵循SOA的設計思想，采用ESB技術是大勢所趨，船端數據集成平臺雖然不會涉及所有ESB技術所帶來的優勢，但是ESB技術的引入更適合現階段集成平臺的開發和長遠發展。

2.3　軟件設計實現

2.3.1總體設計

智能集成平臺選用Mule ESB作為ESB的實現，該軟件是基于Java的輕量級消息框架，相比于其他的ESB產品，Mule的服務組件可以是任意類型的，簡單的Java對象(Plain Ordinary Java Objoct, POJO)或其他框架實現的組件都可集成進來，而且其提供了非常豐富的組件，開發者只需集中精力在業務邏輯上，消息邏輯可通過現成的組件來實現。

采用ESB的智能集成平臺船端的軟件結構見圖4。由圖4可知，船端的所有子系統，都可通過不同協議連接到總線。根據各子系統數據生成的速率和容量，數據采集所采用的通訊協議見表1。

圖4　采用ESB的智能集成平臺船端的軟件結構

表1　子系統協議類型及數據周期

機艙監測報警系統和船舶性能監測系統具有2 000多個直接接入以太網的傳感器(測點)，為了與這些硬件進行通信，智能集成平臺選用在工業領域被廣為應用的網絡通訊協議Modbus，它是自動化工業領域的標準，這種協議采用問答式通信，具有簡單及通用性強等特點。平臺選用Modbus在以太網上進行傳輸的版本為Modbus TCP，傳輸速率可以達到1 GB/s。

Modbus 協議采用主/從式結構，數據采集端為主節點，數據源為子節點。以機艙檢測報警系統為例，數據集成平臺作為通訊的主節點，機艙監測報警系統作為數據源，具有3個子節點，每個子節點有1個IP地址，子節點中的每個監測點硬件都有1個Address ID。通訊由主節點發起，請求信息中包含傳感器的定位信息IP和Address ID，子節點獲取定位信息后將對應傳感器的數據響應給主節點完成通信。

軸系振動在線監測系統采集周期為7 d，每次上傳30 000條數據，每條數據約200個字段，智能集成平臺采用FTP的方式收取文件，在本地解析文件采集數據，避免與子系統長時間的連接導致網絡負載的降低。軸系油液在線系統及配載儀同理。智能航行系統傳輸的大多是圖像文件，因此采用FTP這種比較常規的做法。

2.3.2軟件實現

圖5　Mule ESB消息流概念圖

智能集成平臺的數據采集功能基于消息流的機制實現，Mule ESB 3.0開始引入了該機制，“流”就是消息處理事件的序列，進入“流”的每一條消息會經過各種服務組件，完成業務邏輯(見圖5)。

利用Mule強大的消息流功能，開發者可投入更多的精力在業務邏輯的實現上，常規功能例如數據格式的轉換及消息的路由等都交由Mule自帶的組件完成，可更簡單有效地對數據和服務進行集成。針對各子系統采集功能的實現可分為服務協調和服務組開發兩部分：

(1) 服務協調。依據各個子系統數據匯集的功能流程，配置各種組件，編排消息流。消息流的編排可在Anypoint Studio中以圖形拖拽的方式完成，一些配置的細節則需在對應的XML文件中實現。相比傳統的代碼形式，圖形化的配置式更加方便。

(2) 服務組件開發。服務組件是消息流中執行數據處理的實體，根據各子系統實際需求開發包含業務邏輯的Spring bean或者POJO。Mule ESB自帶豐富的組件，例如各類消息轉換器等，也會在功能實踐中使用。

以機艙監測報警系統的數據采集為例，其需要實現2個功能模塊：

(1) 監測點信息獲取。監測點信息獲取功能的消息流配置見圖6。該功能配置了2條異步消息流，第1條消息流的輸入端是1個FTP連接器，它以輪詢的方式監聽指定的目錄，如果有文件上傳到指定目錄，則將文件下載到輸出節點，即本地文件夾中。第2條消息流的輸入端是本地文件夾，File連接器也采用輪詢的方式監聽該文件夾，發現文件則將其交由自定義的Java組件進行分析，根據分析結果再將其備份至指定的FTP目錄。自定義的Java組件采用POI程序包(Apache開源的Microsoft Office文檔處理程序包)提供的程序對測點信息表進行數據拆分。及數據校驗，最終持久化。流程見圖7。

圖6　消息流配置圖

圖7　監測點信息表導入流程

(2) 與監測點通訊采集數據。監測點通訊的消息流配置見圖8。該消息流引入了定時器，定時器調用自定義的Java組件10 s/次，Java組件包含初始化內存隊列，同步監測點設備信息，初始化Modbus Master，建立與監測點設備的通訊等功能見圖9。

2.2.3功能驗證

為了驗證監測點信息表的導入功能，將測點信息表(見表2)上傳到指定的FTP服務器目錄下，用時約為0.5 min將數據全部同步到MySQL數據庫中(見圖10)。

圖8　監測點通訊消息流配置圖

圖9　監測點通訊流程圖

IPSlaveIDAddressTag_codeTypeTag_Name_ENTag_Name_CN10.17.2.1091100004000FINISH WITH ENGINE主機完車10.17.2.1091200005000ENGINE NOT READY主機未完車10.17.2.1091300006000ALARM BLOCK(ME STOPPED)報警閉鎖(主機停車)10.17.2.1091400007000ME START BLOCKED主機啟動閉鎖10.17.2.1091500008000ME WRONG WAY主機錯向10.17.2.1091600015000LOAD PROG CANCEL FROM ACP從ACP取消負荷程序控制10.17.2.1091700016000MAIN ENGINE TRIPPED主機停車10.17.2.1091800017000ME SLOW DOWN ACTIVE主機減速10.17.2.1091900019000ME SHUT DOWN CANCELLED主機停車越控10.17.2.10911000020000ME SLOW DOWN OVERRIDE主機降速越控

圖10　MySQL數據庫中測點表數據

由于監測點數據表的導入并不經常執行，且同步的時間大都消耗在服務組件處理文件的過程中，因此采用ESB進行測點數據導入是可行的。

由于實驗室環境下沒有真實的物理設備，與監測點信息通訊功能的驗證采用Modbus Slave仿真器，該仿真器可模仿監測點設備與數據集成平臺通信。仿真器發送的數據見圖11。

圖11　Modbus Slave仿真器數據

數據集成平臺在于Modbus 仿真器通訊之后將采集到的數據存儲到關系型數據庫中(見圖12)。實驗證實采用ESB技術的集成平臺，可順利采集到數據并保證數據不會遺失，具備可靠性。

圖12　數據集成平臺獲取到的數據

3　結　語

智能集成平臺通過對子系統的數據采集，可克服信息孤島，提高數據的綜合利用率。針對船端子系統通信協議多樣及數據形式相同的問題，提出了采用企業服務總線的技術進行數據采集的方案，利用其通信協議適配及消息處理能力強大的特點，實現船端異構數據的采集。以機艙監測報警系統為例，設計了數據采集的邏輯流程，并依此對Mule ESB的消息源及消息處理器進行了編配，最終應用系統可成功獲取所需數據。