姜 斌,厲運周,陳永華

(1.中國科學院 海洋研究所,山東 青島 266071; 2.山東省科學院 海洋儀器儀表研究所,山東 青島266061)

隨著海洋科學技術的不斷發(fā)展,氣象水文浮標成了海洋探索中不可缺少的一部分[1]。原有的海洋監(jiān)測需要人工輔助,監(jiān)測范圍和時長受限較多。氣象水文浮標使用了傳感器、控制、電源管理、通信等多方面技術,是一個包含廣泛的綜合性應用[2-4]。通過自動化技術,使氣象水文浮標的探測變得簡單,通過無線通信系統(tǒng)與后臺通信服務器相連,實現(xiàn)數(shù)據(jù)的自動采集、標識和傳輸,無需人工值守就能全天候、更廣范圍地了解到海洋氣象和水文要素。氣象水文浮標的應用,推動了海洋科學技術的發(fā)展。 基于單片機的浮標采集系統(tǒng),擴展的端口有限,部分單片機未使用操作系統(tǒng),無法并發(fā)采集氣象水文數(shù)據(jù)[5]。為了同時獲取更多種類的氣象、水文連續(xù)穩(wěn)定的觀測數(shù)據(jù),作者設計并實現(xiàn)了基于Linux的氣象水文浮標采集系統(tǒng)。

1 總體設計方案

基于Linux的氣象水文浮標采集系統(tǒng)搭載1個溫濕壓風傳感器模塊、1個GPS定位模塊、1套耦合溫鹽傳感器模塊和1套無線通信模塊,其中,溫濕壓風傳感器模塊用來采集氣象數(shù)據(jù),溫度、濕度、氣壓、風速和風向參數(shù),GPS定位模塊用來采集浮標定位,耦合溫鹽傳感器用來采集水文數(shù)據(jù),不同深度的水溫和鹽度,無線通信模塊用來與岸站接收系統(tǒng)通信,將采集處理后的數(shù)據(jù)回傳。

基于 Linux的氣象水文浮標采集系統(tǒng)需要實時監(jiān)測電池電壓、浮標是否進水以及浮標艙門是否被打開這些狀態(tài)信息,并將這些信息回傳,以方便實時了解浮標目前的狀態(tài)。

基于Linux的氣象水文浮標采集系統(tǒng)采用嵌入式Linux操作系統(tǒng),Qt作為軟件開發(fā)平臺,傳感器的數(shù)據(jù)采集是多線程進行,傳感器之間工作互不影響?；贚inux的氣象水文浮標采集系統(tǒng)分工作狀態(tài)和休眠狀態(tài),根據(jù)預先設定,實時時鐘喚醒系統(tǒng)進入工作狀態(tài),進行各傳感器的數(shù)據(jù)采集工作和數(shù)據(jù)整理、回傳,工作結束后,程序通知系統(tǒng)進入休眠狀態(tài)。

2 系統(tǒng)硬件設計

基于 Linux的氣象水文浮標采集系統(tǒng)的硬件結構可以劃分為核心控制模塊、接口擴展模塊及傳感器模塊,工作功率不超過3W,休眠時功率幾乎為0。如圖1所示。

圖1 基于Linux的氣象水文浮標采集系統(tǒng)硬件結構圖Fig.1 Hardware structure diagram of the meteorological and hydrological buoy acquisition system based on Linux

核心控制模塊的接口包括1個USB接口、1個I2C接口和20個GPIO口; 接口擴展模塊將核心控制模塊的1個USB接口擴展成4個數(shù)字串口,分別用來連接溫濕壓風傳感器、耦合溫鹽傳感器、GPS定位模塊和無線通信模塊,將1個I2C接口擴展成4路模擬信號輸入,用來監(jiān)測電池電壓、進水報警和開艙報警; GPIO口控制繼電器,為溫濕壓風傳感器、耦合溫鹽傳感器、GPS定位模塊和無線通信模塊通電或者斷電。

2.1 核心控制模塊

核心控制模塊采用基于ARM11的主頻1 GHz、內(nèi)存521 MB的Broadcom BCM2835作為主芯片,設計引出20個的GPIO口、1個USB口和1個I2C口。GPIO口用來控制傳感器的上電和斷電,USB口可用來擴展數(shù)字信號,I2C用來擴展模擬信號。USB口的傳輸速率為 12 Mbps,擴展成串口后,串口最高傳輸速率為115 200 bps,所以USB口最少可以擴展成109個串口。

2.2 接口擴展模塊

接口擴展模塊主要是將核心控制模塊的USB口擴展成多個數(shù)字串口和將 I2C口擴展成多個模擬接口。首先將USB口通過USB Hub擴展成多個USB口,擴展出的USB口平分傳輸速率,USB Hub芯片選用FE1.1S,可以將1個USB口擴展成4個USB口,USB轉串口芯片選用FT232R,如果還需要擴展更多的數(shù)字接口,可以設計更多的USB Hub和串口轉換芯片,可以擴展109個數(shù)字串口。I2C接口的模數(shù)轉換芯片選用 PCF8591T,8位的轉換精度可以滿足報警兩種狀態(tài)的需要,4路模擬量輸入完全可以滿足電池電壓、開艙報警和進水報警。

2.3 傳感器模塊

傳感器模塊包括溫濕壓風傳感器、耦合溫鹽傳感器、GPS定位模塊和無線通信模塊,都是通過數(shù)字串口連接。溫濕壓風傳感器采用的是 Young公司的超聲波溫濕壓風傳感器。

耦合溫鹽傳感器采用Sea Bird公司的耦合溫鹽傳感器。感應耦合數(shù)據(jù)傳輸系統(tǒng)利用塑包引導鋼纜和周圍海水形成閉環(huán)。將收發(fā)耦合磁環(huán)分置主浮體下端和剖面測量平臺上,將塑包鋼纜從耦合磁環(huán)中心傳入,完成感應耦合通訊與數(shù)據(jù)傳輸[6]。這種傳輸方式的優(yōu)點是結構簡單、成本低; 不存在接頭和導線,可靠性高; 不受接頭的限制,傳感器的部署位置可以更加靈活。

無線通信模塊在近海浮標使用DTU(Data Transfer Unit,無線通信網(wǎng)絡 GPRS/CDMA進行傳送的無線終端設備)模塊,遠海浮標使用銥星模塊。DTU模塊通信費用低,只能在陸地或者近海的地方使用[7]; 銥星模塊通信費用高,可以在遠海的地方使用。

3 系統(tǒng)軟件設計

氣象水文浮標系統(tǒng)的軟件設計主要包括采集端的程序和岸站接收中心軟件的設計。采集端程序功能包括溫濕壓風傳感器模塊的數(shù)據(jù)采集及處理、耦合溫鹽傳感器模塊的數(shù)據(jù)采集及處理、GPS模塊的地理坐標參數(shù)采集和將所有數(shù)據(jù)整合處理發(fā)送回岸站接收系統(tǒng); 岸站接收中心軟件功能主要是接收、解析、顯示和存儲采集端的數(shù)據(jù)。

3.1 采集端程序設計

采集端軟件采用Qt作為軟件開發(fā)平臺,與數(shù)據(jù)庫結合自動備份,多線程運行滿足各傳感器同時采集數(shù)據(jù),設計流程圖如圖2所示。

圖2 采集系統(tǒng)軟件流程圖Fig.2 Software flow chart of the acquisition system

采集端由實時時鐘喚醒進入工作狀態(tài),首先進行 Linux系統(tǒng)的初始化,通過 GPIO口控制繼電器,為溫濕壓風傳感器模塊、GPS定位模塊、水下的耦合溫鹽傳感器模塊和無線通信模塊分別上電,同時通過溫濕壓風傳感器模塊采集溫度、濕度、氣壓和風速、風向等氣象數(shù)據(jù)并將采集數(shù)據(jù)插入對應數(shù)據(jù)庫,通過耦合溫鹽傳感器采集不同深度的水溫、鹽度等水文數(shù)據(jù)并將采集數(shù)據(jù)插入對應數(shù)據(jù)庫,通過GPS定位模塊采集定位數(shù)據(jù)并將采集數(shù)據(jù)插入對應數(shù)據(jù)庫,按照要求采集完數(shù)據(jù)后,通過GPIO口控制繼電器,分別關閉對應的溫濕壓風傳感器模塊、GPS定位模塊和水下的耦合溫鹽傳感器模塊,將采集的報警數(shù)據(jù)插入對應數(shù)據(jù)庫。當需要采集的數(shù)據(jù)全部入庫后,按照要求整合處理采集的所有的數(shù)據(jù)并壓縮,制作成本次采集需要回傳的數(shù)據(jù),同時將數(shù)據(jù)庫中需要補發(fā)的數(shù)據(jù)移動到內(nèi)存中,加上本次需要回傳的數(shù)據(jù),一共N條數(shù)據(jù)需要發(fā)送,對每一條數(shù)據(jù)嘗試發(fā)送,發(fā)送成功的數(shù)據(jù)從內(nèi)存中刪除,沒有發(fā)送成功的數(shù)據(jù)再存入補發(fā)數(shù)據(jù)庫中,當所有需要補發(fā)的數(shù)據(jù)全部嘗試發(fā)送一次之后,關閉無線通信模塊,本次的采集端的工作結束,進入休眠狀態(tài)。

3.2 無線通信模塊的選擇及通信流程

氣象水文浮標根據(jù)離岸的遠近分為近海浮標和遠海浮標,考慮到通信質(zhì)量、通信成本等因素,近海浮標大多選用GPRS或者CDMA兩種通信方式,遠海浮標通常選用衛(wèi)星通訊作為通信方式。為了兼顧近海浮標和遠海浮標,基于Linux的氣象水文浮標采集系統(tǒng)的通信端口通過一個標志位可以切換 DTU(Data Transfer Unit,無線通信網(wǎng)絡GPRS/CDMA進行傳送的無線終端設備)和銥星模塊。

近海浮標采用GPRS或者CDMA作為通信方式,通信流程如圖3所示。發(fā)送數(shù)據(jù)時,每條數(shù)據(jù)發(fā)送后等待最多3 s,接收到岸站接收系統(tǒng)回復后即為本條數(shù)據(jù)發(fā)送成功,如果沒有收到回復,將該條數(shù)據(jù)插入數(shù)據(jù)庫,并繼續(xù)發(fā)送下一條數(shù)據(jù)。遠海浮標采用銥星通訊作為通信方式,通信流程如圖4所示。首先發(fā)送AT指令,如果銥星模塊返回OK,再發(fā)送 AT+CSQ指令來獲得當前通訊的信號質(zhì)量,如果發(fā)送這兩條指令沒有返回 OK,重新發(fā)送該指令,如果沒有信號,則發(fā)送失敗后結束發(fā)送,這兩條命令在銥星模塊初始化時發(fā)送,以后發(fā)送每條數(shù)據(jù)不必再次發(fā)送這兩條命令; 當有信號時,發(fā)送AT+SBDD2指令來清空發(fā)送緩存,當返回OK后,發(fā)送AT+SBDWB= buff.size指令來指定發(fā)送數(shù)據(jù)的大小,其中 buff.size是需要發(fā)送的數(shù)據(jù)大小,如果返回READY,發(fā)送需要發(fā)送的數(shù)據(jù),將發(fā)送數(shù)據(jù)寫入銥星模塊的發(fā)送緩沖區(qū),以上指令發(fā)送后如果返回不正確或者沒有返回,都需要重新發(fā)送AT+SBDD2指令,將發(fā)送數(shù)據(jù)寫入銥星模塊的發(fā)送緩沖區(qū)后,銥星模塊如果返回0,發(fā)送AT+SBDIX指令,如果返回的status＜3,則表示發(fā)送成功,如果沒有返回或者 status＜3錯誤,則發(fā)送失敗。

圖3 近海浮標通信流程圖Fig.3 Communication flow chart of the offshore buoy

圖4 遠海浮標通信流程圖Fig.4 Communication flow chart of the open sea buoy

3.3 岸站接收系統(tǒng)的設計及實現(xiàn)

岸站接收系統(tǒng)選用LabVIEW作為軟件開發(fā)平臺,采用CS架構,LabVIEW提供了方便的界面設計工具,CS架構將數(shù)據(jù)接收存儲和數(shù)據(jù)解析分離開,數(shù)據(jù)的接收存儲在服務器端完成,數(shù)據(jù)解析在客戶端完成,保證數(shù)據(jù)接收的穩(wěn)定性及數(shù)據(jù)解析的靈活性。

岸站接收系統(tǒng)的服務器端程序流程圖如圖5所示。服務器端程序監(jiān)聽端口,當有浮標采集器連接端口后,等待接收數(shù)據(jù),當接收到數(shù)據(jù)后,將數(shù)據(jù)存儲到數(shù)據(jù)庫中,檢測連接是否斷開,如果沒有斷開繼續(xù)等待接收數(shù)據(jù),如果連接斷開,繼續(xù)監(jiān)聽端口,在有一個連接接入端口后,不影響其他浮標的采集器接入端口,是一個并行的過程,服務器端程序簡單高效,以保證每條數(shù)據(jù)都能存儲下來。

圖5 岸站接收系統(tǒng)服務器端程序流程圖Fig.5 Flow chart of the server shore station receiving system

岸站接收系統(tǒng)的客戶端程序功能模塊組成圖如圖6所示。登錄界面輸入正確的用戶名和密碼后進入主界面,主界面由3個頁組成,最新數(shù)據(jù)、數(shù)據(jù)查詢和數(shù)據(jù)報表。在最新數(shù)據(jù)中會實時更新數(shù)據(jù)庫中最新的數(shù)據(jù)并按照解析格式解析成氣象參數(shù)、水文參數(shù)和報警信息,也可以在最新數(shù)據(jù)中根據(jù)時間查找某個時間之前的最新數(shù)據(jù); 數(shù)據(jù)查詢是選擇需要查詢的參數(shù)后,選擇起始時間和結束時間,可以得到該參數(shù)在這個時間段內(nèi)的變化曲線; 數(shù)據(jù)報表是選擇起始時間和結束時間,會將該時間段內(nèi)的數(shù)據(jù)解析完成后導出到 Excel中,以便進行進一步的科學研究。岸站接收系統(tǒng)的客戶端程序的界面如圖7所示。

圖6 岸站接收系統(tǒng)客戶端程序功能框圖Fig.6 Functional block diagram of the client shore station receiving system

圖7 岸站接收系統(tǒng)客戶端程序界面Fig.7 Interface of the client shore station receiving system

4 實驗測試

基于Linux的氣象水文浮標如圖8和表1所示,近海在威海和煙臺各布放一套,遠海在西太平洋赤道附近布放2套。威海近海浮標已經(jīng)布放半年,維護過1次,煙臺近海浮標和遠海浮標布放3個多月,目前從岸站接收系統(tǒng)中查詢數(shù)據(jù)回傳正常,數(shù)據(jù)采集和浮標狀態(tài)正常。近海浮標采用CDMA通信,遠海浮標采用銥星通信。

表1 接收數(shù)據(jù)準點率Tab.1 On-time rate of received data

圖8 基于Linux的氣象水文浮標Fig.8 Meteorological and hydrological buoy based on Linux

4.1 定時數(shù)據(jù)采集測試

煙臺近海 1號浮標由于距離陸地較遠,通信信號不是很好,因此接收數(shù)據(jù)準點率較差,原因包括發(fā)送數(shù)據(jù)慢和補發(fā)數(shù)據(jù),其他浮標通信信號比較好,都是因為補發(fā)數(shù)據(jù)造成的接收數(shù)據(jù)不準時。由于每次采集開始時間都是確定的,數(shù)據(jù)準時回傳,說明數(shù)據(jù)采集的時間是一定的。相比目前主要采用的串行數(shù)據(jù)采集,效率更高,可擴展的傳感器更多。

4.2 數(shù)據(jù)自動備份測試

浮標每次回傳的數(shù)據(jù)都是一段時間采集后的特征值,比如是每個時間段的平均值、最大值和最小值,如果回傳傳感器上每一個采集數(shù)據(jù),數(shù)據(jù)量太大,通信費用比較高,因此采集端需要將每個傳感器采集的數(shù)據(jù)自動備份,當浮標回收時,可以通過備份的數(shù)據(jù)還原所有的采集過程,為進一步科學研究提供數(shù)據(jù)支持。

目前,只有威海近海 2號浮標維護過,從浮標的數(shù)據(jù)庫中取出的數(shù)據(jù)經(jīng)過重新計算,與岸站接收系統(tǒng)接收到的數(shù)據(jù)是一致的,證明了回傳數(shù)據(jù)的正確性。

4.3 數(shù)據(jù)補發(fā)測試

由于海上的信號不穩(wěn)定,不能保證岸站接收系統(tǒng)能接收所有數(shù)據(jù),因此,為了保證數(shù)據(jù)的連續(xù)性,需要將每次沒有發(fā)送成功的數(shù)據(jù),在下次信號好的時候,可以一起補發(fā)到岸站接收系統(tǒng)。各個浮標的數(shù)據(jù)補發(fā)率如表2所示,煙臺近海1號浮標由于距離陸地較遠,通信信號不是很好,因此補發(fā)率較高。

表2 接收數(shù)據(jù)補發(fā)率Tab.2 Reissue rate of received data

5 總結

文章詳細闡述了基于 Linux的氣象水文浮標數(shù)據(jù)采集系統(tǒng)的設計及實現(xiàn),多線程同時采集氣象數(shù)據(jù)、水文數(shù)據(jù)和浮標狀態(tài)信息,相比無操作系統(tǒng)下串行采集傳感器數(shù)據(jù),采集效率更高,工作功率比較低; 可擴展性強,可以擴展到109個傳感器同時采集數(shù)據(jù),內(nèi)置數(shù)據(jù)庫,可以將各個傳感器每次的采集數(shù)據(jù)自動備份,保證了回收數(shù)據(jù)正確性和為進一步的科學研究提供數(shù)據(jù)支持; 實現(xiàn)了數(shù)據(jù)補發(fā)功能,由于海上信號不穩(wěn)定,數(shù)據(jù)補發(fā)可以將由于信號不好時的數(shù)據(jù)在信號好的時候再次發(fā)送,保證了岸站接收系統(tǒng)接收采集數(shù)據(jù)的連續(xù)性。近海和遠海各 2套浮標已經(jīng)運行數(shù)月,岸站接收系統(tǒng)接收的浮標數(shù)據(jù)都是正常連續(xù)的,威海近海 2號浮標的自容數(shù)據(jù)與回傳數(shù)據(jù)一致,說明基于Linux的氣象水文浮標數(shù)據(jù)采集系統(tǒng)能同時獲取氣象、水文的連續(xù)穩(wěn)定的觀測數(shù)據(jù),并且回傳數(shù)據(jù)是準確可靠的。設計還有許多不足之處,未來的工作是改善和改進,主要有以下幾點:

(1) 擴展更多的數(shù)字接口,來滿足浮標搭載更多的傳感器;

(2) 實現(xiàn)遠程控制的功能,通過岸站接收系統(tǒng)控制氣象水文浮標數(shù)據(jù)采集系統(tǒng)的采集方式;

(3) 除了目前已經(jīng)應用的太陽能供電,探索更多的供電方式,以滿足更多傳感器供電需求;

(4) 利用Linux的優(yōu)勢,將人工智能應用到氣象水文浮標數(shù)據(jù)采集系統(tǒng)中,系統(tǒng)可以根據(jù)已經(jīng)采集的數(shù)據(jù)分析后面的采集方式。