基于OpenADR規范的智能船舶數據采集與傳輸系統

吳 軍周嘯偉魯 楊

（1.常熟瑞特智能船舶裝備研究院有限公司 常熟215500；2.常熟瑞特電氣股份有限公司 常熟215500）

基于OpenADR規范的智能船舶數據采集與傳輸系統

吳 軍1周嘯偉2魯 楊2

（1.常熟瑞特智能船舶裝備研究院有限公司 常熟215500；2.常熟瑞特電氣股份有限公司 常熟215500）

為使智能船舶的底層數據采集和傳輸達到完整和規范，文章基于物聯網技術，參考美國OpenADR通訊規范，以自動需求相應平臺硬件和軟件的開發設計思路和框架，設計和實現了一套針對智能船舶的數據采集和傳輸系統，從而為智能船舶上層的應用平臺奠定良好的基礎。

智能船舶；物聯網；數據采集與傳輸；數據平臺

引 言

近年來，物聯網技術有了突飛猛進的發展，在飛機、汽車、電力等領域均獲得廣泛應用，但在船舶領域，尤其是在國內造船領域，智能船舶似乎遇到了瓶頸。這其中的一個核心問題就是數據采集和傳輸的規范化。

本文以物聯網和自動需求相應（OpenADR）規范為開發思路和理念，通過具體的實施方案將美國自動需求相應規范［1］應用于現代智能船舶之中，對智能船舶的理念及實施作些有益的探索。

1 背 景

為了規范和引領國內的智能船舶建設，中國船級社（CCS）《智能船舶規范》［2］針對智能船舶作如下描述：智能船舶系指利用傳感器、通信、物聯網、互聯網等技術手段，自動感知和獲得船舶自身、海洋環境、物流、港口等方面的信息和數據，并基于計算機技術、自動控制技術和大數據處理和分析技術，在船舶航行、管理、維護保養、貨物運輸等方面實現智能化運行的船舶，以使船舶更加安全、更加環保、更加經濟、更加可靠。

現代船舶的自動化設計包括無人機艙和一人橋樓等，僅局限于船舶或系統本身，其借助物聯網和互聯網的智能化水平較低。究其原因，是由于目前我國造船還沒有實現標準化設計、采購和生產，船舶制造還停留在定制階段；即使同一船東的同一系列船型，制造時的分段劃分、設備和材料的采購、系統原理都不能做到完全相同。由于設備和系統的多樣性和獨立性，其數據接口水平不一，在實施數據統一采集、處理、顯示和控制時非常困難。

基于以上原因，本文通過參考自動需求相應（OpenADR）規范實現采集終端與數據服務器的連接，期望能使底層數據采集和設備控制更加規范化。

2 智能船舶的數據需求分析

《智能船舶規范》針對常規的軸系柴油機推進的運輸商船提出有關智能的六大基本符號，概括為：

i-ship（N） 智能航行/Navigation

i-ship（H） 智能船體/Hull

i-ship（M） 智能機艙/Machinery

i-ship（E） 智能能效/Energy

i-ship（C） 智能貨控/Cargo

i-ship（I） 智能集成平臺/Integration

以智能機艙為例，CCS要求的基本功能為：對機艙內的主推進發動機、輔助發電用發動機、軸系的運行狀態進行監測；根據狀態監測系統收集的數據，對機械設備的運行狀態和健康狀況進行分析和評估；根據分析與評估結果，提出糾正建議，為船舶操作提供決策建議；同時對主機等監測點也提出了具體要求。

對照發現，CCS要求的監測點大多數在現有AIS系統里均已包括，只有少量監測點需要增加（如內燃燒狀態、溫度和震動等）。我們認為，不能遺漏監測點的同時也應該避免數據重復采集，在設計和采購之初就應該全盤考慮，例如，要求AIS供應商開放數據串口、增加數據采集點；機艙智能平臺的數據統一從AIS獲得；然后按照統一的元數據框架標準上傳數據服務器。

智能船舶的應用服務器至少應包括以下幾個層面：

（1）數據及模型層

包括數據服務器采集到的數據和來自外部的數據，如水文氣象數據、碼頭數據、航線數據等。此外，還應該包括讓所有設備執行的指令庫或者指令函數庫，需要造船工程師、航運工程師、軟件工程師、硬件工程師、設備供應商的通力合作。船舶需要采集的數據點，對于需要采集數據和執行下發指令的設備，設備供應商必須打開數據端口。此外，還需要完善預案庫，即船舶航行時的各種姿態下設備運行的設定參數，該庫需連接故障診斷系統，且能修改保存。

（2）邏輯層

包括算法、專家診斷系統以及視情維護系統，不僅需要對大量的數據進行計算和邏輯分析，而且也是一個積累的過程。不同的數據得出不同的結論，執行不同的預案，同時向顯示層傳遞結果。

（3）顯示層

人機互動的層面，可以查看和下載數據，形成各種報表，同時也應有權限管理。

從以上分析可以看出，由于設備的多樣性和獨立性，數據接口水平的參差不齊，使得按照統一的元數據框架標準采集和傳輸各類數據成為了整個系統成敗的關鍵，這其中涉及到的問題包括：標準化、可靠性、安全性、需求響應等多個方面，OpenADR標準在這方面作了詳細規范。

2002年，為解決加利福尼亞州的電力危機，勞倫斯·伯克利國家實驗室（LBNL）的需求響應研究中心（DRRC）成立了OpenADR研究項目，嘗試支持基于事件的自動需求響應機制和實時電價，優化電力供需雙方關系，提升電網的經濟性和可靠性。后來，OpenADR1.0規范被捐贈給標準組織（OASIS），在OASIS的Energy Interoperation 1.0規范基礎上形成眾多國家廣泛參與的OpenADR2.0標準。

OpenADR是一個通信數據模型，定義了電力服務提供者和消費者之間信息交換的標準和規范。OpenADR基于已有標準的通信協議（例如HTTP、XMPP），采用XML方式傳遞需求響應、價格、可靠性等信息。

借鑒OpenADR的概念和標準，我們將其應用于智能船舶中，設計和實現一個數據采集和傳輸系統。

3 系統設計與實現

按照自動需求相應（OpenADR）規范，系統從結構上可分為采集終端、數據傳輸和數據服務器等三大塊。本文并未深入涉及建于數據服務器平臺之上的應用層，例如故障診斷和視情維護等。系統的整體框圖見圖1。其中每一個數據采集終端都有三種數據源接口，終端和服務器（包括數據庫服務器及應用服務器）通過網絡相連，信息傳輸則采用HTTP協議。

3.1 采集終端

采集終端的設計對于整個物聯網系統來說至關重要，它直接連接傳感器或采集器，把接收到的信號進行處理和存儲，并且生成標準格式的報文，按照服務器的要求定時、加密傳輸到服務器；同時還能接受服務器指令，對設備進行一定的操作，例如大型設備的啟、停以及通過串口對一些設備進行軟控制等。由于現在船用設備，例如主機、副機、冷水機組等既有智能裝備的信息接口標準不統一，如果大量的數據都直接交給服務器處理，會給服務器帶來巨大的壓力，信息的第三方應用集成與二次開發相對困難。因此，由采集終端分散處理，以標準的格式傳遞給服務器顯得非常重要。

3.1.1 采集終端硬件

由于采集終端需要進行多線程編程，本文選用4核arm處理器，預裝linux系統的電腦板，用可插拔SD卡作為存儲器，主板帶有IO口和串口，可實現脈高低電平、串口以及USB總線的輸入和輸出用于數據的采集和設備的控制。電腦板內置有線網卡，可擴展無線網卡以及gprs模塊，可通過光纖、Wi-Fi以及gprs連接服務器。

3.1.2 采集終端軟件

采集終端的編程語言可采用C、JAVA或Python等。由于Python語言的簡潔性、易讀性以及可擴展性，在國外用Python進行科學計算的研究機構日益增多，一些知名大學已經采用Python來教授程序設計課程。因此，我們以Python在Linux操作系統下編程為例，對終端的開發作說明。

終端預裝MySQL數據庫，可滾動保存30天的數據。配置頁面使用Python的FLASK開源框架，在有線網卡上虛擬一個靜態IP網口，采集終端實際上就是一個BS構架的微型Web服務器，電腦可以直接通過瀏覽器對采集終端進行配置，如：網絡連接、設備連接以及導入解析函數、ssl安全證書等的配置。將采集終端設計為WEB服務器，其目的是能夠對采集終端進行初始設置，與路由器的配置頁面類似，當電腦通過網線連接采集終端后，通過瀏覽器訪問采集終端預置的IP地址或域名，便可訪問終端服務器，如圖1所示。登錄后對終端將要連接的服務器IP地址或域名進行配置以及對所采集的數據源進行配置，圖2是終端服務器的登陸頁面。圖3為登錄后頁面。

登錄后可以對終端的網絡、目標服務器、脈沖信號源、串口信號源等進行配置，相關信息存入終端內置的數據庫，后臺程序讀取數據庫的配置信息，按照所設置的信息運行程序，啟動相應的線程，完成對數據源的采集和傳輸。

3.2 數據采集和設備控制

采集終端上共有3種數據源的數據接口，IO脈沖信號、IO串口輸出信號以及USB Modelbus 485信號。

3.2.1 IO脈沖信號

脈沖信號的輸入可通過終端后臺程序計算出相應的數據，例如通過接入智能電表的脈沖信號能計算出電表的功率和電能，按此原理同樣可以獲得軸系轉速等數據。脈沖信號的輸出可以通過二進制的組合控制輸出針腳的高低電平，例如通過2個針腳可以組合成：00、01、10、11共四種信號，每種信號可以映射不同的預案。

3.2.2 IO串口輸出信號

采集終端通過IO串口輸出，可以連接繼電器，通過一組指令實現對設備的啟、停，也可以連接帶有串口數據接口的配電板，在接到服務器平臺的指令后，自動向繼電器或配電板下發指令，以達到控制的目的。

3.2.3 USB Modelbus 485信號

通過USB Modelbus 485總線，可以向所連接的若干個地址碼發出不同指令，每個地址碼可以連接采集器或者連接帶有串口接受指令的設備，通過這種方式，可以對設備進行柔性控制，前提是設備供應商必須開放串口以及提供指令庫或指令算法。為了降低干擾，所有報文均進行crc16校驗或者根據設備商的標準算法進行校驗。考慮到采集器或設備的品牌多樣性，報文的格式也不相同，數據解析函數以及校驗方法也不同，因此在終端可預置常用品牌型號的解析函數，遇到新的品牌型號也可以通過配置頁面導入。這樣可以實現靈活接入不同的設備，并且具有記憶功能，只要導入一次，下次同樣的設備便可自動識別。

3.3 通訊安全和數據傳輸

數據的傳輸可以通過光纜、Wi-Fi或gprs為載體，分為連接層和應用層兩個層面。連接層即TCP層，應用層即http層。

3.3.1 通訊安全

數據傳輸的安全性是非常重要的，目前比較流行的是http加SSL/TLS，即https。SSL/TLS是指非對稱加密。同時還需要證書雙向認證。具體實現過程如下：

（1）終端生成一個隨機數 random-client，連同自己的證書信息、加密方式等傳到服務器端（Say Hello）。

（2）服務器隨后以權威機構頒發的CA 數字證書驗證終端的證書；確認無誤后，服務器端也生成一個新的隨機數 random-server，連同服務器的證書和加密公鑰，一起回饋給終端（I got it）。

（3）終端收到后，同樣先以權威機構頒發的CA 數字證書驗證服務器的證書；確認無誤后，再次生成一個隨機數，使用服務器的公鑰加密后形成premaster secret發給服務器。

（4）服務器收到后使用自己的私鑰解密premaster secret，這樣，終端和服務器都有了3個隨機數（random-client、random-server、premaster secret），此時安全通道已經建立，服務器和終端各自根據這3個隨機數以及在以上交流中確定的算法算出相同的會話密碼即 session key。以后的通訊雙方均使用session key進行加密和解密。

3.3.2 數據傳輸

雖然上述加密過程有些復雜，但卻可確保通訊安全。連接層加密通道建立后，在應用層上使用http協議進行數據傳輸，其最大優點是會話結束后便斷開連接，從而節省TCP資源，但其也有一個最大缺點，就是及時性差。http連接在一般情況下，服務器是沒有辦法找到終端的，只能由終端去找服務器。在過去的項目中，我們設定終端每隔一段時間便主動請求一下服務器，即輪詢poll。服務器收到輪詢請求后如果沒有新的指令要終端執行，則回復一個正常的回復報文response；如果有新的指令需要終端執行，則回復一個事件報文Distribute，終端收到后便會根據具體指令，通過串口或USB總線下發指令操控所連接的設備。

由此可見，如果服務器想要某個設備執行某個無法立刻做到的指令，只能等到終端下次輪詢來了才能下發指令，這種方式對于同步要求不高的陸用場景適用，但智能船舶上會有很多需要設備立刻動作的場景，因此，http傳輸不一定適用，可以考慮用XMPP服務器。

3.4 數據服務器平臺

對于物聯網數據服務器來說，不但要求運行穩定，而且更重要的是要解決終端高并發請求的問題；因此，在之前的物聯網項目中，我們選用Python一個強大的異步服務器框架TORNADO，同時配MongoDB數據庫。為了更進一步加強異步效果，采用NGINX 反向代理TORNADO服務器群，等于同時部署多臺TORNADO服務器，利用NGINX作負載均衡，我們在阿里云上進行了試驗，效果非常不錯。服務器群如圖4所示。

Tornado服務器監聽8003端口

用戶可以通過瀏覽器登錄服務器平臺管理終端、設置終端的數據報告、下載數據以及對終端發送操作指令。服務器平臺同時提供數據庫接口，可以向其他應用服務器提供數據。

4 系統數據信息的完整性

數據信息的完整性即元數據的概念。如果采集的數據信息不完整，數據將變得毫無意義。例如，當你采集到一個溫度的數值時，這一數據必須包含描述其一切屬性（包括單位、時間、設備ID編號、設備名稱、采集頻率和周期等等）。

采集終端存儲在MySQL數據表ven_info中的信息如圖5所示。

當采集終端第一次連接服務器時，終端會自動讀取以上信息，并生成注冊請求（oadrCreatePartyRegistration）的XML報文，提交給服務器，請求注冊，生成如圖6所示報文。

服務器收到請求后，將其解析成字典（見圖7）或者JSON格式，并存儲在服務器的數據庫內。

服務器在處理完以上注冊請求后，會給終端一個相應（oadrCreatedPartyRegistration）報文，格式如圖8所示。

在上述報文中，請求ID（pyld：requested）節點的值為“4027410604”，與終端請求報文中的同名節點的值相同，代表是同一次請求。同時在相應報文中增加了注冊ID（ei：registrationID）節點，注冊ID可以在以后的重新注冊中使用，以及輪詢要求（oadr：oadrRequestedOadrPollFreq），其子節點“xcal：duration”的值為“PT5M”，代表每五分鐘輪詢一次。

以上是OpenADR注冊請求的2次交互，按照OpenADR規范的要求，采集終端（VEN）和數據服務器（VTN）至少要有8組不同的交互報文，簡述如下：

（1）VEN上電后立即注冊

①VEN發送oadrCreatePartyRegistration注冊請求；

②VTN發送oadrCreatedPartyRegistration建立注冊；

③VEN發送oadrRegisterReport注冊報告；

④VTN發送oadrRegisteredReport，不請求任何報告。

（2）VEN注冊后，按照服務端指定的輪詢頻率，開始發送oadrPoll輪詢

（3）VTN向設備請求數據報告

①VEN發送oadrPoll輪詢VTN；

②VTN發送oadrCreateReport；

③VEN發送oadrCreatedReport。

（4）VEN向VTN上傳數據報告

①VEN發送oadrUpdateReport上傳數據；

②VTN發送oadrUpdatedReport確認。

（5）VTN取消VEN的數據報告

①VEN發送oadrPoll輪詢VTN；

②VTN發送oadrCancelReport取消報告請求；

③VEN發送oadrCanceledReport確認取消報告請求。

（6）VTN請求設備重新注冊

①VEN發送oadrPoll輪詢VTN；

②VTN發送oadrRequestReregistration；

③VEN發送oadrResponse；

④VEN發送oadrCreatePartyRegistration；

⑤VTN發oadrCreatedPartyRegistration。

（7）VTN取消VEN注冊信息

①VEN發送oadrPoll輪詢VTN;

②VTN發送oadrCancelPartyRegistration;

③VEN發oadrCanceledPartyRegistration

（8）VTN向VEN發送事件信息

①VEN發送oadrPoll輪詢VTN；

②VTN發送oadrDistributeEvent；

③VEN發送oadrCreatedEvent；

④VTN發送oadrResponse。

以上每組報文，用戶可根據自己所需要自行制定，力求做到數據信息完整。

在將來智能船舶的元數據中，首先需要制定統一的元數據框架標準，無論數據怎樣變化，對于系統來說其框架都是相同的，變化的只是數值和屬性。這對于船舶龐大而復雜的系統來說至關重要。

5 結 論

本文首先分析智能船舶的數據采集和傳輸所面臨的問題與需求，然后，面對底層數據采集和傳輸的完整性和規范性要求，基于物聯網技術，參考美國OpenADR通訊規范，以自動需求相應平臺硬件和軟件的開發設計思路和框架，設計和實現一套針對智能船舶的數據系統，包括數據采集終端、數據傳輸和數據服務器等三大內容，并論述系統數據的信息完整性問題，最終實現規范化的數據采集、傳輸和管理，為智能船舶的上層應用平臺奠定良好的基礎。

［1］ OpenADR Alliance. OpenADR 2.0 Profile Specification B Profile［R］. 2013.

［2］ 中國船級社.智能船舶規范［S］. 2015：1-39.

Data collection and transmission system of intelligent ship based on OpenADR specif i cation

WU Jun1ZHOU Xiao-wei2LU Yang2
(1. ChangshuRuite Institute of Intelligent Ship Equipment Co., Ltd., Changshu 215500, China; 2. Changshu Ruite Electric Co., Ltd., Changshu 215500, China)

In order to make the underlying data collection and transmission of the intelligent ship complete and regulatory, this paper designs and implements a data collection and transmission system based on the technology of the internet of things. It is developed through the concept and framework of the hardware and software for the automated demand response platform with reference to the American OpenADR Specif i cation. It could provide a good foundation for the application platform of the intelligent ship.

intelligent ship; Internet of Things; data collection and transmission; data platform

U665.261

A

1001-9855（2017）04-0032-07

10.19423 / j.cnki.31-1561 / u.2017.04.032

2017-05-11；

2017-06-30

吳 軍（1967-），男，工程師。研究方向：造船工程、物聯網工程。

周嘯偉（1983-），男，工程師。研究方向：信息工程、計算機。

魯 楊（1982-），男，工程師。研究方向：自動化系統集成。